Cybersecurity Compliance | | 18 min read
How to Build a CUI Data Flow Map for CMMC
Key Takeaways
AI adoption has to move fast and stay controlled.
Start With Mission Value
Prioritize use cases tied to measurable business, delivery, or mission outcomes.
Protect the Data Boundary
Define what data AI tools can touch before selecting vendors or architectures.
Keep Humans Accountable
Use AI to support workflows while retaining trained review and escalation paths.
Document the Controls
Maintain inventories, testing evidence, monitoring plans, and risk decisions.
For government contractors preparing for CMMC, one of the most important questions is also one of the hardest to answer: where does Controlled Unclassified Information actually go inside your business?
Many contractors know they handle CUI. Fewer can clearly show where it enters, where it is stored, who accesses it, which systems process it, which cloud tools touch it, which subcontractors receive it, and how it is archived or destroyed.
That gap creates real risk. A contractor cannot accurately define its CMMC scope without understanding its CUI data flows. It cannot build a reliable System Security Plan, determine which assets are in scope, evaluate cloud, SaaS, MSP, or AI tools, or prepare for assessment with a defensible evidence package.
Need help mapping CUI before a CMMC assessment?
GS Consulting helps government contractors map CUI, define CMMC scope, update SSPs, evaluate cloud and AI tools, review subcontractor data flows, and prepare practical assessment evidence.
Request a CUI Mapping AssessmentA CUI data flow map turns a vague statement like "we handle CUI" into a structured picture of how sensitive federal information moves through the company.
Why a CUI Data Flow Map Matters for CMMC
CMMC scoping starts with understanding where Federal Contract Information and CUI are processed, stored, or transmitted. For CMMC Level 2, scoping addresses CUI assets, security protection assets, contractor risk managed assets, specialized assets, and out-of-scope assets.
That means CMMC readiness is not just about having cybersecurity tools. It is about knowing which systems and assets matter because of the data they touch.
For contractors, a CUI data flow map helps answer critical assessment and leadership questions: where does CUI enter, which contracts generate or provide it, which systems process it, who can access it, which providers touch it, which subcontractors receive it, and what evidence supports the company’s compliance claims?
What Is a CUI Data Flow Map?
A CUI data flow map is a visual and written representation of how Controlled Unclassified Information moves through an organization.
It should show the full lifecycle of CUI: how it is received, created, stored, processed, accessed, transmitted, shared with third parties, backed up, logged, retained, returned, destroyed, or decontrolled.
A good CUI data flow map is more detailed than a network diagram. A network diagram shows infrastructure. A CUI data flow map shows information movement.
Step 1: Confirm the Contract and Data Drivers
Do not start by drawing systems. Start with the contract.
Review current contracts, target opportunities, prime contractor flow-downs, task orders, attachments, CDRLs, DD Form 254s where applicable, CUI markings, security classification guides, and customer instructions.
The goal is to identify whether the company handles Federal Contract Information, CUI, Covered Defense Information, controlled technical information, export-controlled information, PII, procurement-sensitive information, or other restricted data.
- Contract number or opportunity name.
- Customer or prime contractor.
- Applicable clauses and required CMMC level if known.
- Types of CUI expected and how CUI will be received.
- Agency-specific handling rules and subcontractor flow-down requirements.
This prevents the CUI map from becoming a generic IT diagram disconnected from actual contract requirements.
Step 2: Identify the CUI Categories and Markings
The next step is to identify what kind of CUI the company handles. Common CUI types may include controlled technical information, export-controlled information, engineering drawings, system specifications, vulnerability information, procurement-sensitive information, program data, personally identifiable information, or other government-furnished information.
Do not rely only on file banners. Some CUI may be clearly marked. Some may be identified in the contract. Some may be generated by the contractor during performance.
- CUI category, source contract, and customer.
- Whether the information is received or contractor-generated.
- Required handling rules and authorized users.
- Authorized systems, sharing methods, and third-party restrictions.
Step 3: Map Where CUI Enters the Company
CUI may enter through more channels than leadership expects, including government portals, prime contractor portals, encrypted email, secure file transfer, customer-furnished systems, shared cloud folders, engineering repositories, program kick-off packages, support tickets, scanned documents, or subcontractor-provided materials.
For each entry point, document the receiving system, receiving owner, authentication method, file storage location, and whether the data is automatically copied, synced, indexed, backed up, or routed into another tool.
This step often reveals hidden problems. A company may believe CUI is stored only in a secure SharePoint site, but employees may receive it first through email, save local copies to laptops, discuss it in chat, upload it into a ticketing system, and attach it to proposal files.
Step 4: Map Where CUI Is Created or Derived
CUI is not always received from the government. Contractors can create it during performance through engineering analysis, test reports, technical drawings, cybersecurity findings, vulnerability reports, inspection records, design documents, meeting minutes, operational data, analytical products, or deliverables that incorporate government-furnished information.
Teams often track customer-provided CUI but miss contractor-generated CUI. If a work product includes CUI from a government source, derives from CUI, includes controlled technical information, contains sensitive vulnerability or system information, becomes a contract deliverable, or will be shared with the government, a prime, or a subcontractor, that workflow belongs on the map.
Step 5: Identify Every System That Stores CUI
Storage locations are usually the easiest place to start, but they are also where sprawl becomes visible.
CUI may be stored in email mailboxes, SharePoint, OneDrive, Teams channels, Google Drive, file-sharing platforms, network shares, engineering repositories, source code repositories, ticketing systems, CRM tools, proposal repositories, backups, endpoint devices, databases, security tools, AI prompt or output history, vector databases, search indexes, and archives.
For each system, record whether it is approved for CUI, who owns it, who administers it, what access controls exist, whether MFA is enforced, whether logging exists, where data is backed up, how long data is retained, and whether the system is included in the SSP.
Step 6: Identify Every System That Processes CUI
Processing is broader than storage. A system processes CUI when it transforms, analyzes, indexes, summarizes, scans, renders, compiles, converts, searches, or otherwise uses the information.
Examples include managed workstations, CAD and modeling tools, analytics platforms, document management systems, email security tools, DLP tools, EDR tools, SIEM tools, ticketing platforms, contract lifecycle management tools, AI summarization or search tools, OCR tools, build pipelines, and backup platforms.
Step 7: Map How CUI Is Transmitted
Transmission includes any movement of CUI between people, systems, organizations, or environments. Common paths include email, secure file transfer, customer portals, prime contractor portals, API integrations, collaboration platforms, chat tools, ticket attachments, remote access, database replication, backup replication, cloud synchronization, subcontractor exchanges, printing, scanning, physical handoff, uploads, and downloads.
For each path, document the source system, destination system, data type, user or process initiating transfer, authentication method, encryption method, approval requirement, logging capability, retention or copy behavior, and subcontractor or third-party involvement.
Step 8: Identify Users, Roles, and Access Paths
A CUI data flow map should show who can access CUI and how. Document user groups such as executives, program managers, engineers, analysts, contracts staff, proposal teams, IT administrators, security staff, help desk personnel, MSP administrators, subcontractors, auditors, and customer users.
Then identify direct file access, role-based application access, privileged administrator access, remote access, shared mailboxes, guest accounts, service accounts, API access, break-glass accounts, and support access by external providers.
This helps answer a core CMMC question: are access controls aligned to actual data exposure?
Step 9: Identify External Service Providers, Cloud Providers, and Subcontractors
External parties are often the most important part of the CUI map. This includes cloud service providers, managed service providers, managed security service providers, IT support providers, SaaS vendors, AI vendors, data analytics providers, subcontractors, consultants, prime contractors, government-furnished systems, incident response providers, backup providers, and compliance platforms.
Capture the service, data types, access method, administrator privileges, FedRAMP status where applicable, and customer responsibility matrix.
Capture sharing method, CMMC status expectations, contract flow-downs, retention terms, and incident reporting obligations.
Step 10: Classify Assets for CMMC Scoping
Once the data flows are understood, classify assets for CMMC scoping.
These assets are central to the Level 2 assessment boundary and should be documented in the asset inventory, SSP, and network diagram.
These systems provide security functions or capabilities to the assessment scope and need clear ownership and evidence.
Policies, procedures, and practices should show why CUI is not intended to flow to these assets.
Specialized assets and out-of-scope assets should also be documented where applicable. Each system on the map should be assigned an asset category and cross-referenced to the SSP, asset inventory, network diagram, and evidence repository.
Step 11: Convert the Map Into an SSP Update
The CUI data flow map should not sit in a folder as a one-time exercise. It should directly improve the System Security Plan.
Use the map to update the system boundary, asset inventory, network diagrams, data flow diagrams, CUI types and categories, user roles, external service provider descriptions, cloud responsibility matrices, inherited controls, control implementation statements, incident response procedures, subcontractor handling procedures, AI tool governance, and evidence references.
A strong SSP should show that the company understands not only what controls exist, but why they apply to the systems in scope.
Step 12: Use the Map to Prioritize Remediation
A CUI data flow map almost always reveals gaps. That is a good thing.
Common remediation findings include CUI stored in unapproved locations, transmitted through unmanaged email or chat, copied to local devices unnecessarily, backed up to unapproved systems, included in ticketing systems without review, shared with subcontractors without documented flow-downs, accessible to too many users, indexed by search or AI tools without approval, protected by undocumented inherited controls, touching cloud tools without FedRAMP or responsibility review, or missing from the SSP and asset inventory.
Use the map to prioritize remediation based on risk and scope impact. High-priority issues usually include unauthorized CUI storage, unapproved cloud or AI tools, weak access controls, missing MFA, unmanaged endpoints, lack of audit logging, unclear external provider responsibilities, and uncontrolled subcontractor sharing.
What a Simple CUI Data Flow Map Should Include
A practical CUI data flow map does not need to be beautiful. It needs to be accurate.
Track the data source, CUI category, receiving system, storage location, processing system, transmission path, backups, archives, and final disposition.
Track roles, cloud providers, AI tools, subcontractors, contract clauses, asset categories, SSP references, evidence, and open gaps.
Example: CUI Flow for an Engineering Support Contractor
A simplified CUI flow might begin with a DoD customer uploading controlled technical information to an approved government portal. The contractor’s program manager downloads the files to an approved CUI storage environment. Engineers access the files from managed workstations and perform technical analysis using approved engineering software.
Draft deliverables are stored in a controlled project repository. A subcontractor receives a limited set of files through approved secure transfer. The final deliverable is uploaded to the government portal. Related evidence, access logs, and transmission records are retained according to contract and company policy. AI tools are prohibited for the workflow unless specifically approved for CUI.
That simple flow can then be expanded into a system boundary, asset inventory, access model, SSP language, subcontractor flow-down review, and evidence checklist.
Common Mistakes to Avoid
The first mistake is treating a network diagram as a data flow map. Infrastructure matters, but CMMC scoping depends on how FCI and CUI move through the environment.
The second mistake is ignoring contractor-generated CUI. Deliverables, reports, analysis, drawings, test results, and vulnerability information may become CUI even if they were created internally.
The third mistake is missing email, chat, tickets, and collaboration tools. These platforms often contain more CUI than leadership realizes.
The fourth mistake is overlooking backups and logs. If backup systems, SIEM tools, EDR platforms, or ticketing systems contain CUI or security protection data, they may affect scope.
The fifth mistake is forgetting AI and search tools. If a tool indexes CUI, creates embeddings from CUI, stores prompts containing CUI, or generates outputs derived from CUI, it must be reviewed.
The sixth mistake is failing to maintain the map. A CUI data flow map should be updated when the company adds a contract, changes cloud platforms, introduces AI tools, brings in a new subcontractor, changes storage locations, or modifies delivery workflows.
CUI Data Flow Map Checklist
Use this checklist to evaluate whether your map is ready to support CMMC planning.
- Does the asset inventory match the CUI map?
- Does the network diagram match the CUI map?
- Does the SSP match the CUI map?
- Can we explain why each asset is in scope, limited scope, or out of scope?
- Have we identified unauthorized CUI locations, weak transmission paths, over-permissioned users, and unapproved tools?
A 30-60-90 Day CUI Mapping Plan
Review contracts, identify CUI categories, interview program teams, collect system lists, identify storage locations, and document how CUI enters and leaves the organization.
Create the data flow diagram, update the asset inventory, identify external providers, classify assets under CMMC scoping categories, and compare the map against the current SSP.
Remove CUI from unauthorized locations, restrict access, update cloud and AI tool policies, document subcontractor flows, update the SSP, and build evidence references.
By the end of 90 days, leadership should be able to answer: What CUI do we handle? Where does it enter? Where does it live? Which systems process it? Who can access it? Which providers and subcontractors touch it? Which assets are in the CMMC scope? What gaps must be remediated before assessment?
The Bottom Line
A CUI data flow map is one of the most valuable artifacts a government contractor can build for CMMC readiness.
It helps define scope, strengthen the SSP, identify unauthorized data movement, evaluate cloud and AI tools, manage subcontractors, prioritize remediation, and prepare defensible evidence. More importantly, it gives leadership visibility into the actual path of sensitive government information across the business.
GS Consulting helps government contractors map CUI, define CMMC scope, update SSPs, evaluate cloud and AI tools, review subcontractor data flows, prepare assessment evidence, and build practical remediation roadmaps aligned to contract requirements.
Ready to map where CUI moves through your organization?
Contact GS Consulting for a GovCon CUI Data Flow and CMMC Scoping Assessment.
Contact GS ConsultingSuggested Future Reading
- GovCon Cybersecurity & Compliance Hub: CMMC, NIST, CUI, Cloud, and AI-Enabled Readiness
- CMMC Readiness Checklist for Small and Mid-Sized Government Contractors
- NIST SP 800-171 Compliance: What GovCon Leaders Need to Know
- How DoD Contractors Can Use AI Without Putting CUI at Risk
- Secure Cloud Architecture for Federal Contractors Handling CUI