How should defence contractors scope CMMC Level 2 requirements before implementing controls in a complex environment?

Scoping CMMC Level 2 Around the CUI Boundary, Not the Org Chart

CMMC Level 2 scoping should begin with where Controlled Unclassified Information flows, where it is stored, and where it can be accessed, not with a blanket assumption that every business unit or endpoint is automatically in scope. In a complex defence contractor environment, the real challenge is separating systems that directly process, transmit, or protect CUI from systems that merely support the business around them. That distinction drives what must be assessed, what can be segmented, and what evidence must be gathered.

Assessment readiness improves when contractors first identify contract types, enclave boundaries, trusted interconnections, and external dependencies before selecting controls. If the scope is too broad, teams waste time hardening assets that do not affect certification outcomes. If it is too narrow, assessors will find unexamined access paths, shared services, or supplier connections that expand the boundary later. NIST’s control guidance is most useful here when it is applied after scope is defined, not before; see NIST SP 800-53 Rev 5 Security and Privacy Controls for the kind of control rigor that scoping ultimately has to support. In practice, many security teams discover their true CMMC boundary only after a shared service, admin path, or contractor-managed connection has already complicated the evidence set.

How CMMC Scoping Decisions Turn Architecture Into an Assessment Boundary

CMMC Level 2 scoping is really an exercise in translating architecture into assessable responsibility. The first question is not which controls to implement, but which assets can influence the confidentiality of CUI and therefore belong inside the boundary. That usually includes systems that store CUI, systems that route or transform it, the identities that can reach those systems, and any supporting infrastructure whose compromise would affect the confidentiality outcome.

In a complex environment, the scoping work should cover at least four layers:

• Data layer: where CUI is created, received, stored, processed, or archived.
• Access layer: which users, service accounts, external partners, and administrators can reach those assets.
• Infrastructure layer: endpoints, servers, directories, network segments, cloud services, and shared platforms that support the boundary.
• Dependency layer: third-party tools, managed providers, SaaS services, and interconnections that can alter the trust boundary.

That structure helps teams avoid a common mistake: treating the assessment scope as a technical inventory exercise rather than a question of control reach and trust exposure. A contractor may own only part of the environment, but any externally managed component that can affect CUI handling still matters to scope. Likewise, segmentation only helps if it is real and enforceable; paper boundaries do not reduce scope when privileged access crosses them. The strongest scoping decisions are the ones that can be defended with diagrams, access paths, data flow mapping, and clear justification for exclusions.

One useful test is to ask whether a failure in a given system would change the organisation’s ability to protect CUI. If the answer is yes, that system is usually either in scope or tightly tied to an in-scope control set. If the answer is no, the system may remain out of scope, but only if the access and data path analysis is complete. For contractors using shared identity platforms, remote administration, or common logging stacks, the scoping challenge often sits in the dependencies, not in the obvious CUI repository. That is where detailed traceability matters most, because assessors will expect the boundary to reflect actual operational relationships rather than a simplified network diagram.

The guidance breaks down when organisations cannot prove where CUI enters and exits the environment, or when third-party access cannot be separated from the protected boundary.

When Scope Decisions Get Harder in Mixed, Shared, or Supplier-Heavy Environments

Tighter scoping often reduces certification effort, but it also increases the burden of proving that exclusions are real, durable, and enforced. In mixed environments, that tradeoff matters because a single shared service can pull otherwise separate assets into the same assessment story.

Where teams should be cautious is in three situations. First, shared identity or admin platforms can broaden scope if they govern access to in-scope systems, even when they do not store CUI themselves. Second, managed service providers and cloud tenants can create hidden dependencies if the contractor cannot evidence who administers what, when, and with which privileges. Third, engineering and test environments often drift into scope when production CUI is copied for troubleshooting or validation. There is no universal rule that every adjacent system is in scope, but there is also no safe assumption that adjacent means irrelevant.

Guidance versus consensus matters here. The general consensus is that scoping should be right-sized and evidence-led. The less settled part is how aggressively to include shared services that indirectly support in-scope assets; contractors should expect assessor scrutiny and be ready to justify each exclusion rather than rely on a blanket architecture claim. For complex programs, the practical answer is often to scope the smallest boundary that can still be defended across data flow, access, and dependency analysis. That usually means treating supplier connections, central administration, and common security tooling as first-class scoping inputs, not afterthoughts.

For contractors with multiple contracts or business units, the best indicator of a sound scope is whether the boundary can survive an assessor asking, system by system, “Why is this inside or outside?” If that answer depends on assumptions instead of evidence, the scoping exercise is not finished.

Practitioner Guidance

What to prioritise: Build the scope around CUI flow first, then test every shared service, admin path, and supplier connection against that boundary. The main failure mode in complex environments is not missing a control, but misclassifying an asset that silently affects in-scope confidentiality.

What to verify: Confirm that exclusions are supported by data-flow diagrams, access-path evidence, and an inventory of third-party dependencies. If a system is excluded, the team should be able to show why it cannot influence CUI handling or assessment evidence.

Practitioner takeaway: The strongest CMMC scope is the one that aligns technical boundaries, operational ownership, and assessor evidence into a single defensible story rather than a convenience-based inventory.

Related resources from NHI Mgmt Group

• How should DoD contractors align IAM controls to CMMC requirements?
• How should defense contractors scope systems and users for CMMC Level 1 when FCI flows across vendors and internal tools?
• What breaks when CMMC Level 1 controls are only partially implemented across an environment?
• How should defence contractors identify Controlled Unclassified Information across hybrid data estates before CMMC audits?