How should organisations scope CMMC Level 2 without overexpanding the assessment boundary?

Start by mapping where CUI is created, stored, processed, and transmitted, then include only the systems, users, and environments that materially affect those paths. The best scope is narrow but defensible. If you use an enclave, make sure supporting identities, integrations, and third parties are still visible in the boundary.

Why This Matters for Security Teams

Scoping CMMC Level 2 is not just an exercise in drawing a clean boundary. It determines which assets must meet the 110 NIST SP 800-171 requirements, which teams will be assessed, and how much evidence must be maintained. Overexpanding the boundary can turn a manageable compliance program into a costly inventory problem, while under-scoping creates an audit gap that assessors will challenge.

The practical risk is usually not the obvious production server. It is the forgotten integration, admin path, or identity used to move CUI between systems. That is why boundary decisions need to be anchored in data flow, not org charts. The NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful as a control reference for access, logging, configuration, and monitoring expectations, while NHIMG’s Ultimate Guide to NHIs – Key Challenges and Risks highlights why service accounts, API keys, and automation paths often become hidden scope drivers. In practice, many organisations discover boundary creep only after evidence collection starts and every connected system turns out to be “temporary” or “out of scope” on paper but operationally inseparable from CUI handling.

How It Works in Practice

Start by mapping where CUI is created, stored, processed, and transmitted. That means identifying the authoritative sources, the collaboration tools, the file stores, the build systems, the ticketing and messaging platforms, and every integration that can move controlled data. The boundary should then include only the systems and identities that can materially affect those flows. That usually includes privileged admins, enclave operators, service accounts, API keys, CI/CD agents, and any third-party connectivity that touches CUI-related workflows.

A defensible scope usually follows four steps:

• Define the CUI data paths and classify each system by direct, indirect, or no material effect on those paths.
• Separate enterprise-wide tools from enclave-specific tools, but keep shared identities and federated access visible.
• Document trust boundaries for SaaS, cloud, and managed services, especially where logging or admin access remains outside the enclave.
• Prove exclusion decisions with rationale, not convenience, so assessors can see why a system does not affect CUI handling.

For control expectations, CMMC Level 2 aligns closely to the NIST SP 800-171 family, and NIST guidance on access control and auditability helps teams justify why a component belongs inside the assessment scope. The OWASP Non-Human Identity Top 10 is especially relevant when automated jobs, bots, or integrations sit on the CUI path, because those identities often have broader reach than human users and are easy to overlook during boundary definition. NHIMG’s research on Ultimate Guide to NHIs – Key Challenges and Risks is useful here because it frames why lifecycle control, visibility, and privilege reduction matter when the enclave depends on machine-to-machine access. These controls tend to break down when CUI is exchanged through shared SaaS tenants and centrally managed identities because the boundary becomes logically clear but operationally hard to separate.

Common Variations and Edge Cases

Tighter scoping often reduces assessment cost and evidence burden, but it increases the need for discipline around integrations, identity governance, and change control. Organisations have to balance a narrow boundary against the operational reality that CUI frequently crosses tools, teams, and vendors.

One common edge case is the enclave model. It can simplify the assessment surface, but only if supporting identities, jump hosts, logging pipelines, and remote administration are explicitly included where they influence CUI handling. Another is the hybrid environment, where development, test, and production share identity providers or secrets stores. Current guidance suggests those shared services should be in scope if they can affect the confidentiality or integrity of CUI, even when the CUI itself never lands there. There is no universal standard for every integration pattern, so the best practice is to document the reasoning and revisit it whenever architecture changes.

Third-party services deserve special attention. If a supplier can administer, process, back up, or troubleshoot CUI-connected systems, the boundary decision must account for that access path. NHIMG has repeatedly shown that non-human identities are a hidden expansion vector, and the same logic applies to CMMC scoping: if a service account or API key can reach CUI, it is part of the assessment story whether or not it appears in the org chart.

Related resources from NHI Mgmt Group

• How can organisations use a security assessment without turning it into a vanity metric?
• How should organisations scope a CMMC enclave before building it?
• How can organisations reduce AI agent blast radius without blocking adoption?
• How should organisations govern AI agent access without losing operational speed?