CUI Data Flows & Business Applications

Every CMMC assessment begins with a question the assessor will not answer for you: what is in scope? Anything that processes, stores, or transmits CUI is in scope. This scoping 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 or Intune policy, 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.

Identifying CUI: The COPR Framework

Before mapping how CUI flows, decide what counts as CUI in the first place. The default assumption, that everything from the government is CUI, is the single largest driver of excessive audit scope and cost in CMMC programs. A helpful approach is the COPR framework. One test decides scope: Possession. The other three settle adjacent points.

• Creation (your own output counts): CUI status follows the content, not the author. Government-furnished CUI and the derivative work you build from it, such as analyses or drawings, qualify.
• Ownership (authority and flow-down): Legal ownership can sit with the agency, prime, or subcontractor, but never reduces your duty to protect CUI you possess.
• Possession (the one scope gate): Is the CUI stored on, processed by, or transmitted through your systems or your people? If any one of those happens, even briefly, it is yours to protect. A single CUI-containing Teams call pulls your systems into scope, regardless of whose system holds the master copy.
• Regulation (how you must handle it): The CUI category set the controls layered on top of the baseline. CUI Basic gets baseline 800-171 handling; CUI Specified categories (the SP- markings) carry extra rules. Export-controlled CUI (CUI//SP-EXPT) mandates US-person-only access and often mandates being in GCC High.

The practical consequence: a precise inventory of what you possess, plus a deliberate architecture that prevents systems from taking possession unnecessarily, dramatically reduces audit surface area. The AVD enclave patterns in Phase 3 and the shared-services tenant architecture in Phase 1 each exist to shrink the set of systems that take possession of CUI.

Attribution

The COPR framework as presented here is drawn from Ryan Bonner (DEFCERT), whose Identifying CUI roundtable at CS5 2026 expanded on the mental model in detail.

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 the most overlooked flow: a contract manager who downloads a ZIP of CAD drawings from a DoD portal onto a personal laptop has moved CUI across the boundary with no IT involvement. Once inside, it propagates: an email attachment becomes a SharePoint file becomes an ERP record becomes a Teams message, each hop a new system that must be within the assessed boundary. Outbound flows to non-certified subcontractors raise flow-down issues. And CUI at rest is easily missed: retention policies, litigation holds, and eDiscovery collections can cause it to persist in Exchange archives and SharePoint version history 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 needs to be accurate, current, and auditable.

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 receiving party, whether CMMC certified (and at what level), and the transfer mechanism.

Step 4: Mark the authorization boundary

The authorization boundary must include systems that process, store, or transmit CUI, plus the assets that protect them:

• 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)
• Security Protection Assets & Data: your SIEM, Intune/MDM, identity and firewall management, their logs and configurations, and the admins or MSP who run them are in scope even when no CUI flows through them, because they protect CUI assets. See External Service Provider Management for cloud SIEMs, MSPs, and CSPs.

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.

Scope is not binary: the "process, store, or transmit" test

The DoD CMMC Scoping Guide — Level 2 (32 CFR § 170.19) sorts every asset into five categories. Four are in the assessment scope. The trigger for the fully-assessed category, CUI Assets, is whether an asset processes, stores, or transmits (PST) CUI:

• Process: access, entry, editing, generating, or printing
• Store: at rest on the asset (disk, memory, or paper)
• Transmit: movement between assets (physical or digital transport)

One exception: An endpoint connecting to AVD with KVM-only access is an Out-of-Scope Asset, the reason for the AVD secure enclave. The carve-out holds only while access stays KVM-only: turn on microphone or camera redirection and the connecting endpoint can be found in scope.

Source: DoD, CMMC Scoping Guide — Level 2, v2.13 (Sept 2024), per 32 CFR § 170.19.

GCC High

In M365 GCC High, the cloud authorization boundary is the tenant boundary itself: Microsoft runs GCC High physically separated from commercial M365, giving the SSP a defensible hard boundary for the cloud.

• Inside: Exchange Online, SharePoint Online, OneDrive for Business, Teams, and Entra ID (all GCC High)
• Outside by default: consumer OneDrive, commercial M365 tenants, personal Gmail, Zoom (unless separately assessed), any SaaS not in the GCC High tenant

Personal devices must be evaluated: a user who reads CUI email on a personal iPhone has put that device in contact with CUI. Either bring it into scope (managed and compliant) or block unmanaged-device access with a Conditional Access compliant-device policy, the standard way to keep those endpoints out of scope.

Cross-cloud flows cross the boundary. Document any GCC High to commercial flow (forwarding rules, Teams federation, SharePoint external sharing) as an outbound flow, and block most of them by policy.

tip

Record the GCC High tenant ID in the SSP. Assessors verify the in-scope tenant matches Microsoft's FedRAMP High authorization.

Commercial

On a commercial M365 tenant pursuing NIST SP 800-171, the boundary cannot rely on physical separation: it is defined entirely by policy and technical controls.

NIST SP 800-171 3.12.4 requires the SSP to describe the boundary and every component that processes, stores, or transmits CUI. In a commercial tenant, that means:

• Dedicate the tenant to CUI work, or isolate CUI within it using sensitivity labels, Conditional Access, and SharePoint site architecture
• Document guest accounts, external sharing, and cross-tenant collaboration as boundary-crossing mechanisms
• Evaluate any SaaS app connected via OAuth or API (e.g., Salesforce, DocuSign) that can reach CUI-tagged content

The risk is boundary creep: CUI leaking into personal OneDrive, consumer email via forwarding, or third-party apps with broad Graph permissions. Back the SSP boundary statement with technical controls that enforce it, not just policy.

---

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. People assume an unmanaged personal laptop is out of scope, but the moment CUI is stored on it, it is a CUI Asset in scope, documented or not. That undocumented in-scope asset is exactly what an assessor finds. (Don't confuse this with government-furnished equipment (a government-owned laptop or test rig), which is a Specialized Asset: in scope, but SSP-documented and reviewed rather than assessed against every practice.)
• 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	Develop, document, and periodically update system security plans describing the system boundary, environment of operation, and how requirements are implemented	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.