Defining Your CUI Boundary: A Practical Guide for Contractors

The single most important decision in your CMMC Level 2 journey has nothing to do with firewalls, MFA, or SIEM tools. It's defining your CUI boundary — the authorization boundary that determines which systems, networks, people, and processes are in scope for assessment. Get this wrong, and you'll either protect too much (expensive and slow) or too little (assessment failure).

This guide walks through the practical steps of CUI boundary definition, the common mistakes we see, and how to document your boundary in a way that assessors can validate.

What is CUI and why does the boundary matter?

Controlled Unclassified Information (CUI) is information the government creates or possesses, or that an entity creates or possesses on behalf of the government, that requires safeguarding or dissemination controls per law, regulation, or government-wide policy. It's not classified, but it's not public either.

For defense contractors, CUI typically includes:

• Technical data — engineering drawings, specifications, manufacturing processes
• Export-controlled information — ITAR technical data, EAR-controlled technology
• Procurement-sensitive data — cost/pricing data, source selection information
• Controlled technical information (CTI) — research and engineering data with military or space applications
• Naval nuclear propulsion information (NNPI) — specific to naval contracts

The boundary matters because every system that processes, stores, or transmits CUI — and every system that provides security protection for those systems — is in scope for your CMMC assessment. A broader boundary means more systems to secure, more evidence to produce, and a more expensive assessment. A narrower boundary means less work, but you must actually enforce the boundary.

Step 1: Identify your CUI sources

Start with your contracts, not your systems. Review every active contract and subcontract for:

1. DFARS 252.204-7012 (Safeguarding Covered Defense Information) — this clause triggers NIST 800-171 requirements. Use our DFARS Identifier to check your contracts.
2. CUI markings on received data — look for "CUI," "FOUO," "Controlled Technical Information," and specific CUI category markings.
3. Contract Data Requirements Lists (CDRLs) — these specify the data deliverables and often indicate CUI status.
4. DD Form 254 (Contract Security Classification Specification) — for contracts involving classified, this form also identifies CUI categories.

Step 2: Map CUI data flows

Once you know what CUI you handle, trace how it moves through your organization:

• Ingestion: How does CUI enter your environment? Email? File transfer? Web portal? Direct network connection?
• Processing: Which applications and systems process CUI? CAD software? ERP systems? Email clients? Collaboration tools?
• Storage: Where does CUI reside at rest? File servers? Cloud storage? Local workstations? Backup tapes?
• Transmission: How does CUI move between systems? Internal network? VPN? Cloud sync? USB drives?
• Output: How does CUI leave your environment? Deliverables to the government? Shared with subcontractors? Printed documents?

Document every path. This data flow map becomes the basis for your authorization boundary diagram and your SSP's system description.

Step 3: Draw the authorization boundary

Your authorization boundary includes three categories of systems:

CUI Assets (in scope)

Systems that directly process, store, or transmit CUI. These are obviously in scope — they're the reason you need CMMC in the first place.

Security Protection Assets (in scope)

Systems that provide security services to CUI assets, even if they never touch CUI directly. Examples:

• Firewalls and network security appliances separating CUI networks
• SIEM servers collecting logs from CUI systems
• Identity providers (Active Directory, Okta) authenticating users to CUI systems
• Vulnerability scanners that scan CUI systems
• Backup systems that store copies of CUI data

Out-of-Scope Assets (not in scope)

Systems that are completely separated from CUI processing and CUI protection. Examples:

• Guest Wi-Fi networks with no access to CUI systems
• Marketing workstations that never handle CUI
• HR systems that don't manage access to CUI assets
• Production/manufacturing systems that handle non-CUI work

Step 4: Minimize the boundary (the enclave approach)

The most effective cost-reduction strategy is minimizing your CUI boundary before implementing controls. Less scope = fewer systems = less work = lower cost.

The enclave approach works like this:

1. Create a dedicated CUI enclave — a separate network segment (physical or virtual) specifically for CUI processing
2. Move all CUI processing into the enclave — dedicated workstations, dedicated servers, dedicated storage
3. Enforce the boundary technically — firewall rules, network segmentation, access controls that prevent CUI from leaving the enclave
4. Keep everything else out of scope — corporate IT, guest networks, non-CUI business systems stay outside the boundary

This is not trivial to implement, but it dramatically reduces your assessment scope. A 500-employee company might have 200 endpoints, but if only 40 people handle CUI and they do it on dedicated workstations in a segmented network, your assessment covers 40 endpoints and the enclave infrastructure — not 200 endpoints and the entire corporate network.

Step 5: Document the boundary

Your SSP must include a clear description of your authorization boundary. At minimum, document:

• System boundary diagram — network topology showing the CUI enclave, security protection assets, and out-of-scope systems with the boundary line clearly drawn
• Hardware inventory — every device inside the boundary with make, model, role, and IP address
• Software inventory — every application running on in-scope systems
• User inventory — every person with access to systems inside the boundary, with their role and access level
• Data flow diagrams — showing how CUI enters, moves through, is processed by, and exits your boundary
• Interconnection agreements — for any connections between your boundary and external systems (including cloud services)

Common CUI boundary mistakes

Mistake #4: Making the boundary too big

If your entire corporate network is in scope because "everyone might see CUI sometimes," you're protecting everything and you'll pay for it in assessment time and remediation costs. The fix: segment CUI processing into an enclave and limit who has access.

Mistake #5: Forgetting about cloud services

If your CUI lives in Microsoft 365, that instance is in scope. If it's in an AWS S3 bucket, that account is in scope. Cloud services that process or store CUI are part of your boundary. The shared responsibility model means you're responsible for your configuration, and you need evidence of it.

Mistake #6: Overlooking mobile and remote access

If employees access CUI from home laptops via VPN, those laptops are in scope. If CUI can be accessed from a personal phone via email, that phone is in scope. The fix: enforce access controls that limit CUI access to managed devices in controlled environments.

Mistake #7: Ignoring subcontractor flow-down

If you share CUI with subcontractors, their environments are part of the CUI ecosystem. DFARS 252.204-7012 requires flow-down to subcontractors. Document these connections and verify your subs have their own CMMC compliance in place.

Automate the boundary definition

Manual boundary definition works for small organizations, but it doesn't scale. We built a tool that helps you map your CUI boundary interactively:

Once your boundary is defined, the next step is mapping controls to evidence for every system inside it. Our compliance pipeline does this automatically — generating OSCAL-formatted component definitions for each in-scope system with evidence chains assessors can trace. Book a 30-minute scan to see it in action against your environment.

See also: DFARS Identifier · CMMC Assessment Checklist · SPRS Score Explained · CMMC Cost Guide