CUI Data Flows & Business Applications

Every CMMC assessment begins with a question the assessor will not answer for you: what is in scope? The answer is determined entirely by where Controlled Unclassified Information flows. You cannot protect what you have not traced, and you cannot claim a system is out of scope if CUI touches it — even briefly. Data flow mapping is not a compliance checkbox. It is the prerequisite that determines the size and cost of every other control you implement.

CUI data flow diagrams are a required artifact for the System Security Plan (SSP) under CMMC Level 2. NIST SP 800-171 3.12.4 requires a description of the system boundary and the information flows crossing that boundary. Before configuring a single Conditional Access policy or Intune profile, architects must produce a defensible map of where CUI enters the organization, how it moves between systems, and where it exits. Everything in this guide assumes that map exists.

The Four CUI Flow Categories

All CUI movement in a DIB organization falls into one of four categories. Scoping the CMMC assessment requires accounting for all four.

Category	Description	Common Mechanisms
Inbound CUI	CUI received from external parties and entering the organization's boundary	Email (SAFE/AMRDEC), SFTP, DoD portals (PIEE, Procurement Integrated Enterprise Environment), physical mail with CD/USB
Internal CUI	CUI stored, processed, or transmitted between systems within the boundary	M365 (Exchange, SharePoint, Teams), ERP (Deltek Costpoint, SAP), PDM/PLM (SolidWorks PDM, Windchill), shared network drives
Outbound CUI	CUI leaving the organization to external parties	Submissions to government portals, reports to prime contractors, sharing with subcontractors, deliverable transmittals
CUI at Rest	CUI persisted in storage systems, regardless of active use	SharePoint document libraries, Exchange Online mailboxes, OneDrive for Business, endpoint local disks, removable media

Inbound CUI is typically the most overlooked flow. Government-furnished information (GFI) — drawings, specifications, contract attachments — arrives through channels the IT team may not monitor. A contract manager who downloads a ZIP file of CAD drawings from a DoD portal onto a personal laptop has moved CUI across the boundary without any IT involvement.

Internal CUI is where complexity compounds. Once CUI enters, it propagates. An email attachment becomes a SharePoint file becomes an ERP record becomes a Teams message. Each hop is a new system that must be within the assessed boundary.

Outbound CUI requires particular attention because it involves third parties. Sharing CUI with a subcontractor who is not CMMC certified is a flow-down requirement issue. The prime contractor's data flow diagram must capture where CUI exits and to whom.

CUI at Rest in Exchange archives and SharePoint version history is frequently missed. Retention policies, litigation holds, and eDiscovery collections can cause CUI to persist long after the active project ends.

---

Mapping Business Applications to CUI

The table below maps application types commonly found in DIB organizations to their CUI exposure. Every cell in this table represents a system boundary decision: is this application inside the CMMC assessment scope?

Application	CUI Type	Flow Direction	M365 Touchpoint
Email (Exchange Online)	Contract data, GFI, export-controlled content	Inbound, Internal, Outbound	Exchange Online (GCC High)
Document management (SharePoint / OneDrive for Business)	Technical drawings, SOPs, contract deliverables	Internal, At Rest	SharePoint Online, OneDrive for Business (GCC High)
ERP (Deltek Costpoint, SAP)	Contract cost data, labor charging, procurement records	Internal	Integration via API or manual export; may feed Teams/email notifications
PDM / PLM (SolidWorks PDM, Windchill, Teamcenter)	ITAR/EAR-controlled technical data, manufacturing drawings	Internal, Outbound	Typically standalone; transmittals may use email or SharePoint
Project tracking (Microsoft Teams / Planner)	Program schedules, action items referencing CUI	Internal	Teams (GCC High); channels, chats, files tab
Government file exchange (SAFE, AMRDEC)	GFI, contract deliverables, test reports	Inbound, Outbound	None (external system); landing point is email or local drive
Video conferencing (Teams)	CUI discussed verbally or via screen share	Internal, Outbound	Teams meetings (GCC High); recordings land in OneDrive/SharePoint
Removable media (USB, CD/DVD)	Any CUI type — often GFI from government systems	Inbound, Outbound	None; physical transfer; endpoint is the boundary touchpoint

warning

ERP and PDM/PLM systems are almost always on-premises or hosted in commercial cloud environments. If these systems process CUI, they are in scope for the CMMC assessment. Excluding them requires demonstrating that CUI never enters them — a difficult position to defend for a manufacturer or program office.

---

Creating the CUI Data Flow Diagram

The SSP data flow diagram does not need to be produced in a formal diagramming tool. It needs to be accurate, current, and auditable. A Visio file, a draw.io export, or even a structured Mermaid diagram embedded in the SSP is acceptable. What matters is that it reflects reality.

Step 1 — Start with inbound flows

Identify every mechanism by which CUI first enters the organization. For most DIB contractors, this is:

• Email (Exchange Online): contract awards, GFI attachments from primes, DCSA correspondence
• Government portals: PIEE, SAFE/AMRDEC downloads, DIBBS
• Physical media: CD/USB delivered with government-furnished equipment
• Prime contractor systems: extranet portals, SFTP drops, SharePoint external sharing invitations

For each inbound mechanism, document: the external party, the transfer mechanism, the first internal system that receives the data, and the user account involved.

Step 2 — Trace internal paths

Follow the data as it moves. A contract award PDF arrives via email (Exchange). The contracts manager saves it to SharePoint. The program manager copies sections into a project brief in Teams. The estimating team pulls scope into Deltek Costpoint. Each of these is a new node in the diagram.

Map the path, not just the endpoints. Assessors look for undocumented lateral movement — a file share that nobody mentioned, a legacy on-premises server that still holds archived drawings.

Step 3 — Identify outbound paths

Document where CUI leaves the boundary and to whom. Common outbound flows:

• Deliverable submissions to PIEE or SAFE
• Technical data packages shared with subcontractors (email, SharePoint external sharing, SFTP)
• Reports and CDRLs transmitted to the prime contractor
• Warranty or repair data sent to OEMs

For each outbound flow, document the receiving party, whether that party is CMMC certified (and at what level), and the transfer mechanism.

Step 4 — Mark the authorization boundary

Draw a line. Everything inside that line is assessed. The authorization boundary in a CMMC context must include every system that processes, stores, or transmits CUI. This includes:

• The cloud services (M365 tenant, Azure subscriptions)
• On-premises infrastructure that stores CUI (file servers, ERP databases)
• Endpoints that access CUI (managed workstations, mobile devices)
• Network infrastructure that carries CUI (switches, firewalls, VPN concentrators)

Systems outside the boundary are out of scope only if there is a documented mechanism preventing CUI from entering them. "We don't think anyone would save CUI there" is not a mechanism.

GCC High

In M365 GCC High deployments, the authorization boundary for cloud services is defined by the tenant boundary itself. Microsoft operates GCC High in a physically separated environment from commercial M365. This provides a defensible hard boundary for the cloud portion of the SSP.

• Inside the boundary: Exchange Online (GCC High), SharePoint Online (GCC High), OneDrive for Business (GCC High), Teams (GCC High), Azure AD / Entra ID (GCC High)
• Outside the boundary by default: Consumer OneDrive accounts, commercial M365 tenants, personal Gmail, Zoom (unless separately assessed), any SaaS tool not in the GCC High tenant

Personal devices accessing GCC High services must be evaluated. If a user reads CUI email on a personal iPhone, that device has touched CUI. Either the device is brought into scope (managed, compliant) or CUI access from unmanaged devices is technically blocked via Conditional Access. A Conditional Access policy requiring a compliant device is the standard mechanism for keeping unmanaged endpoints out of scope.

Cross-cloud flows are a boundary-crossing event. Any flow from the GCC High tenant to a commercial tenant — forwarding rules, Teams external federation to commercial tenants, SharePoint external sharing to commercial accounts — must be documented as an outbound flow crossing the authorization boundary. Most of these should be blocked by policy.

tip

Document the GCC High tenant ID in the SSP. Assessors will verify that the tenant in scope matches the FedRAMP High authorization held by Microsoft.

Commercial

For organizations pursuing NIST SP 800-171 compliance on a commercial M365 tenant, the authorization boundary cannot rely on physical infrastructure separation. The boundary is defined entirely by policy and technical controls.

NIST SP 800-171 3.12.4 requires the SSP to describe the system boundary, including all components that process, store, or transmit CUI. In a commercial tenant, this means:

• The tenant must be dedicated to CUI work, or CUI must be isolated within the tenant using sensitivity labels, Conditional Access policies, and SharePoint site architecture
• Guest accounts, external sharing, and cross-tenant collaboration configurations must be documented as boundary-crossing mechanisms
• Any SaaS application connected to the tenant via OAuth or API (e.g., Salesforce, DocuSign) that can access CUI-tagged content must be evaluated for scope inclusion

The risk in commercial environments is boundary creep. CUI can easily flow into personal OneDrive accounts, consumer email (via forwarding rules), or third-party apps with broad Graph API permissions. The SSP boundary statement must be supported by technical controls that enforce it — not just policy statements.

---

Common CUI Entry Points to Audit

The following entry points consistently produce undocumented CUI flows in DIB organizations. Audit each before finalizing the SSP boundary.

• Email attachments without CUI markings: Government senders do not always mark CUI correctly. An unmarked PDF of a contract SOW is still CUI. Filtering on markings alone misses a significant volume of inbound CUI.
• Government-furnished CAD files on unmanaged workstations: Engineers routinely copy GFI drawings to personal laptops for convenience. If the workstation is not managed, it is out of scope — but the CUI is on it.
• Contract PDFs stored in consumer OneDrive: Users who have both a consumer Microsoft account and a work GCC High account sometimes accidentally save to the wrong OneDrive. Consumer OneDrive is outside the CMMC boundary.
• Screen shares of CUI via Zoom or personal Teams accounts: Teams meetings in the GCC High tenant are inside the boundary. A meeting in Zoom, Google Meet, or a personal (consumer) Teams account is not. Screen-sharing a drawing or contract in those platforms is an undocumented outbound flow.
• USB transfers from government systems: Program offices frequently hand off USB drives containing GFI at kickoff meetings. The drive is received by an employee whose workstation may or may not be managed. This is an inbound flow with no digital audit trail.
• Collaboration with primes via commercial SharePoint: Prime contractors sometimes extend SharePoint access using commercial tenant guest accounts. If a DIB subcontractor's user signs in with their GCC High credentials to a commercial SharePoint site, that is a cross-boundary flow.
• ERP system integrations: Deltek Costpoint installations that pull data from SharePoint or push notifications to Exchange may be moving CUI through an integration account that is not in the SSP.

---

CUI Data Flows — Compliance Control Mapping

GCC High

The following CMMC Level 2 practices directly require data flow artifacts as evidence. The SSP data flow diagram, combined with the boundary documentation, satisfies the bulk of these requirements.

CMMC Practice	Requirement	Data Flow Artifact
AC.L2-3.1.3 — Control CUI Flow	Control the flow of CUI in accordance with approved authorizations	Inbound and outbound flow diagrams identifying authorized transfer mechanisms and parties
CA.L2-3.12.4 — System Security Plan	Develop, document, and periodically update system security plans	SSP data flow diagram; authorization boundary diagram; list of in-scope systems
MP.L2-3.8.1 — Media Protection	Protect system media containing CUI, both paper and digital	Removable media flows documented; physical media inventory; media sanitization records
SC.L2-3.13.1 — Boundary Protection	Monitor, control, and protect communications at the external boundary	Authorization boundary definition; firewall/proxy rules aligned to documented flows; cross-boundary flow controls

The AC.L2-3.1.3 and SC.L2-3.13.1 requirements together demand that the boundary is technically enforced, not just documented. A flow diagram without corresponding technical controls (Conditional Access, DLP policies, firewall rules) will not satisfy these practices.

Commercial

For organizations using NIST SP 800-171 Rev. 3 on a commercial M365 tenant, the following requirements are directly supported by data flow documentation.

Requirement	Description	Data Flow Artifact
3.1.3 — Information Flow Control	Control the flow of CUI in accordance with approved authorizations	Inbound/outbound flow diagrams; documented authorized transfer mechanisms
3.8.1 — Media Protection	Protect system media containing CUI	Removable media flow documentation; media handling procedures
3.12.4 — System Security Plan	Periodically assess security controls; develop and implement plans of action	SSP data flow diagram; authorization boundary diagram; component inventory

NIST SP 800-171 Rev. 3 introduced more explicit requirements around system-level boundary documentation compared to Rev. 2. Organizations assessed against Rev. 3 should ensure the SSP includes a component inventory tied directly to the data flow diagram — not just a narrative boundary description.