CUI scoping for the small contractor: a practical guide to drawing the boundary

The first question in any CMMC Level 2 engagement is also the most consequential. Scope determines everything else. Where Controlled Unclassified Information lives in your environment is the seed for every downstream decision: the boundary of your in-scope systems, the cost of remediation, the duration of your assessment window, whether the engagement is tractable in months or stretches across years.

Among small and mid-size DIB contractors, the answer is rarely obvious. CUI enters organizations through narrow channels: a contract addendum, a specifications package from a prime, a technical drawing released without an obvious CUI marking, an addendum to a recompete that nobody flagged for security review at the time it was signed. From there it propagates through everyday operational systems in ways no one fully tracks. Email. Shared drives. ERP modules. Engineering tools. Contractor laptops. Vendor portals. Each is a candidate for in-scope status, and the answer for any given contractor depends on operational specifics rather than category-wide rules.

Begin with contracts, not systems

Most scoping starts wrong. The team begins with the IT environment and asks where CUI might live. The better starting point is the contract portfolio: every CUI obligation in your environment originates from a contract clause, typically DFARS 252.204-7012, that names the categories of information and triggers the handling requirements before any IT decision matters.

Pull contracts first. Build the inventory before opening any technical document. For each active contract with a 7012 clause or its equivalents, identify the specific deliverables, technical packages, drawings, specifications, and program documentation that would qualify as CUI under that contract’s particular terms. Contracts vary widely in their CUI definitions, ranging from permissive to narrow, sometimes shaped by addenda that changed the definition mid-engagement, sometimes inherited from primes who did not document the original CUI categorization clearly enough for the subcontractor to follow. The contractual language governs in every case.

The exercise is rarely quick. It surfaces contracts the security team did not know contained CUI obligations. It surfaces contracts the contracts team did not realize had been signed under modified terms. It surfaces gaps in the handoff between contracting and engineering that have probably been creating compliance exposure for years. All of these are findings worth having early in the engagement rather than late.

Trace the information flow

With the contract-level inventory in hand, the next step is to trace each category of CUI through the lifecycle of an actual program: how it arrives, who receives it, what they do with it, where it gets stored, what derivatives are produced, who has access to those derivatives, and where the derivatives end up.

The most useful interview is not with the IT team. It is with the engineer or program manager who handles the information daily. Their description of the flow reveals systems that are not on the IT team’s radar: personal cloud storage being used as a workaround, vendor portals that hold drawings indefinitely past contract close, contractor email accounts that retain copies of specifications, plotter queues on shared print servers that never get cleared. Each is a potential in-scope system if CUI passes through it, and each is the kind of system that fails an SSP boundary description because the SSP author did not know it existed.

We have yet to conduct a CUI flow analysis that did not surface at least one system nobody had previously considered. The pattern is reliable enough that you should plan for it rather than be surprised by it.

Distinguish processing from incidental contact

Not every system that briefly touches CUI is in scope at the same level of control. A network switch that routes encrypted traffic containing CUI sits in a different position from a file server that stores CUI at rest. CMMC and NIST 800-171 recognize this distinction through asset categorization. In-scope assets are typically classified as those that process, store, or transmit CUI, with further refinement around security protection assets, contractor-managed assets, specialized assets, and out-of-scope assets that sit adjacent to the boundary without crossing it.

Classify each in-scope system specifically. The classification determines which controls apply with full force and which apply in attenuated form. A system that routes encrypted CUI under TLS does not require the same control posture as a system that stores plaintext CUI on local disk.

This is the place where many scoping exercises overreach. Treating every system that has any conceivable connection to CUI as fully in-scope inflates remediation cost dramatically and is rarely required by the actual control specifications. A disciplined classification narrows scope without weakening compliance.

Decide how to handle each in-scope system

For each in-scope system identified in the analysis, four options apply.

The first option is to bring the system into compliance by implementing the full applicable control set. This is the right choice for systems whose CUI handling is operationally essential and where the cost of compliance is reasonable in light of the system’s role.

The second option is technical isolation. The system is restructured so that CUI flows through a different path or is segregated by enclave. Email is the most common candidate for this approach, typically through introduction of a CMMC-compliant email tenant for CUI-containing communications while general business email remains outside scope. The economic case for isolation is strong whenever the in-scope system’s operational role is small relative to its compliance footprint.

The third option is operational restructuring. CUI is routed away from the system through changes in process rather than through new technology. A contractor might decide that engineering drawings will only be reviewed in a controlled enclave rather than emailed, that vendor uploads will go through a portal rather than into a shared drive, or that field laptops will not be issued to roles whose work does not require CUI access in the first place. The change is procedural, but the boundary effect is the same as a technical solution.

The fourth option is removal. The system stops touching CUI entirely. CUI is purged from it, and operational practice changes to keep CUI out. This is rarely the right answer for primary business systems, but it is often correct for legacy storage, contractor laptops outside the corporate environment, or peripheral tools whose role does not justify their compliance cost.

The choice among these four options is an economic question as much as a technical one. Bringing a system into compliance has a cost. Isolating has a different cost. Restructuring has a third. Removing has a fourth. The right answer for any given system is determined by the trade-off rather than by ideology.

Document the boundary deliberately

The output of the scoping exercise is a documented system boundary that will be referenced in your SSP, in your network and data flow diagrams, and in your assessor’s review of both. The boundary description has to be specific. It should name the in-scope systems, classify each system’s relationship to CUI, identify the in-scope users and roles, describe the data flows between in-scope and out-of-scope systems, and call out any assumptions that the description rests on.

Vague boundary descriptions are a frequent SSP failure mode (we wrote about this in detail in another piece). A boundary description that reads “our CUI environment includes our corporate IT infrastructure” is not a boundary description. A boundary description that reads “our CUI environment consists of our Microsoft GCC High tenant for email and SharePoint, our engineering file server eng-file-01, our PDM system, and the controlled workstations issued to designated CUI-handling personnel, with no flows into or out of the boundary that bypass the documented controls” is a boundary description.

A practical caution about scope creep

Once a boundary is established, the work of maintaining it begins. CUI scope tends to creep. New contracts arrive with CUI obligations the team did not anticipate. New tools are adopted without scope evaluation. New personnel are added to CUI-handling roles without documented onboarding. New vendors are engaged without a contractual review for security clauses. Each is a small change that, accumulated over time, can move the practical boundary substantially away from the documented one.

The mechanism that prevents this is a defined process for evaluating scope impact whenever a new contract, system, vendor, or personnel change occurs. The evaluation does not need to be elaborate. It does need to be consistent. Most contractors who maintain CMMC compliance over multiple assessment cycles do so because they treated scope as an ongoing operational concern rather than a one-time project deliverable.

---

Tagged: CMMC Level 2, CUI, NIST 800-171, Scoping