Scoping CUI: How to Shrink Your Compliance Boundary

Two companies of the same size can face very different compliance bills for the same contract. The difference is usually scope. One lets Controlled Unclassified Information (CUI) spread across every laptop, file share and email mailbox, so all 110 NIST SP 800-171 requirements apply to the entire company. The other confines CUI to a defined environment used by the people who need it, and applies the full requirements only there.

Scoping is not a trick to avoid security. It is good architecture: sensitive data concentrated where it can be protected well.

Start with the data, not the network

Before drawing any boundary, find out where CUI actually is and how it moves. For each contract:

• What CUI do you receive? Drawings, specifications, test data, program documents, export-controlled technical data.
• How does it arrive? Email, customer portals, secure file transfer, removable media, in person.
• Where is it stored and processed? File servers, engineering workstations, PLM or ERP systems, cloud storage, printers.
• Who uses it? Engineers, program managers, contracts staff, subcontractors.
• Where does it go? Deliverables back to the customer, subcontractors, test facilities.

Ask the people who do the work, not only IT. CUI frequently lives in places no one planned: an engineer's desktop, a shared drive, a personal folder in a collaboration tool.

The CMMC asset categories

The CMMC Level 2 scoping guidance sorts assets into categories, each with different treatment.

• CUI assets process, store or transmit CUI. They are assessed against all applicable requirements.
• Security protection assets provide security functions or capabilities to the environment, such as identity providers, firewalls, log collection and endpoint protection, whether or not they touch CUI. They are assessed against the relevant requirements.
• Contractor risk managed assets can, but are not intended to, process, store or transmit CUI because of policies, procedures and practices in place. They are documented in the asset inventory and System Security Plan (SSP) and reviewed by assessors.
• Specialized assets include IoT and operational technology, government-furnished equipment, restricted information systems and test equipment. They are documented, but not assessed against every requirement.
• Out-of-scope assets cannot process, store or transmit CUI and are physically or logically separated from CUI assets.

Enclave strategies

Most organizations that handle CUI in a limited part of the business benefit from an enclave: a defined environment for CUI work.

Dedicated on-premises enclave

A separate network segment, with its own systems and tightly controlled access, used only for CUI work. Strong isolation, but you operate everything.

Cloud-based enclave

A government cloud tenant with suitable authorization for CUI, used for email, file storage and collaboration by the people who handle CUI. This can simplify many technical requirements, but you still own configuration, identity, endpoints and your share of every requirement. Make sure you understand the provider's customer responsibility matrix.

Virtual desktop enclave

Users reach CUI only through a virtual desktop hosted in a controlled environment, so CUI does not land on their local devices. This can shrink the endpoint footprint considerably, but the endpoints used to reach the virtual desktop still need careful treatment in your scope and documentation.

Hybrid approaches

Many organizations combine these, for example cloud collaboration plus a small on-premises engineering segment for large design files.

Boundary design checklist

• Identity: Are CUI users and administrators managed centrally, with multifactor authentication?
• Segmentation: Is traffic between the enclave and the rest of the network denied by default and allowed by exception?
• Data movement: Are the approved ways CUI enters and leaves the enclave defined, controlled and logged?
• Endpoints: Which devices can reach CUI, and are they managed and hardened?
• Security tooling: Are the tools that protect the enclave themselves treated as in scope?
• External providers: Are managed service providers and cloud services documented, with responsibilities clear?

Common scoping mistakes

• Scoping by intention. Declaring a system out of scope because "it should not have CUI," without controls that prevent it.
• Forgetting email. If CUI is emailed in, the mail system is in scope unless a controlled alternative is enforced.
• Ignoring backups. Backups of CUI systems contain CUI.
• Leaving out the protectors. The identity provider, SIEM and management servers are security protection assets.
• Undocumented exceptions. A single engineer with a local copy of CUI on an unmanaged laptop can expand scope significantly.

Scope is a living decision

New contracts, new tools and new people change where CUI flows. Revisit scope whenever you win work with new CUI, adopt a new collaboration or engineering platform, or reorganize teams, and update the SSP, network diagrams and asset inventory to match.

A worked example

A 150-person manufacturer supports two defense programs. Today, engineering drawings marked as CUI arrive by email, are saved to a company-wide file share, and are opened on engineers' laptops, which also access everything else. As a result, every system in the company is in scope.

A redesigned approach:

• A government cloud tenant is set up for the 30 people who work on the defense programs. Customer CUI is received through the tenant's email and file services only, and users are trained on the new process.
• Engineering work on large CAD files happens on 12 dedicated workstations in a segmented network zone, with access only through the tenant's identity provider and multifactor authentication.
• The rest of the company, including finance, HR and commercial work, stays on the existing environment, with controls that prevent CUI from being stored there.
• The identity provider, endpoint management, logging and the firewall between zones are documented as security protection assets.

The enclave is smaller, the controls are concentrated where they matter, and the System Security Plan describes an environment that can actually be defended and assessed.

Frequently asked questions

Can we declare a system out of scope because no CUI is stored on it? Only if it genuinely cannot process, store or transmit CUI, and is separated from CUI assets. Policy alone is usually not enough; there should be technical or physical separation.

Do our managed service provider's tools count? If they provide security functions for the environment or can access CUI assets, they are likely in scope. Document their role and responsibilities.

Does moving to the cloud remove requirements? No. It shifts some implementation to the provider, but you remain responsible for your share, including identity, configuration, endpoints and user behavior.

How CDT can help

CDT maps CUI flows, designs enclaves and builds them as part of our CMMC and NIST SP 800-171 readiness and secure systems engineering services, so the boundary is both defensible and practical for the people working inside it.

Sources

• CMMC Level 2 Scoping Guidance (DoW CIO)
• 32 CFR 170.19, CMMC scoping (eCFR)