CMMC scoping confusion persists as DoD revises FAQs again

At a glance

What this is: The DoD’s latest CMMC FAQ revision clarifies recurring scoping mistakes across joint ventures, paper-only CUI, significant change, and encryption boundaries.

Why it matters: It matters because scoping errors can drive failed assessments, contract risk, and evidence gaps, especially where CUI flows across systems, people, and suppliers.

By the numbers:

• The DoD released Revision 2.3 of the CMMC FAQs, the fifth revision since the updated program’s initial rollout in 2024 and the third update in less than six months.
• From November 2025 to May 2026, those three updates alone added 11 new FAQs to the document.

👉 Read Secureframe's full guide on the latest CMMC FAQ changes and scoping clarifications

Context

CMMC scoping is the boundary-setting problem at the heart of defence contractor compliance. If teams cannot define which systems process, store, or transmit FCI and CUI, they cannot reliably decide what is in scope, what evidence matters, or which changes trigger reassessment. That makes the topic relevant not only to compliance leads, but to identity and access teams responsible for controlling who and what can touch sensitive defence data.

The latest FAQ revision shows that the real issue is not whether the framework exists, but whether organisations can keep their scope accurate as environments change. That intersects with IAM, PAM, and NHI governance because service access, system boundaries, and approval chains all influence whether CUI stays within the assessed control plane.

For DIB organisations, this is a governance problem as much as a technical one. The article’s starting position is typical for late-stage compliance programmes: teams often understand the rule set, but still struggle to keep the operational boundary aligned with the assessed boundary.

Key questions

Q: What breaks when CMMC scoping is wrong?

A: Wrong scoping breaks the whole compliance chain because the organisation cannot prove which systems, users, and workflows are actually handling CUI. That can lead to failed assessments, contract ineligibility, and evidence gaps even when individual controls exist. The fix is to define scope from real data flows and update it whenever the operating environment changes.

Q: Why do joint ventures complicate CMMC compliance?

A: Joint ventures complicate CMMC compliance because scope depends on the systems used during contract performance, not the legal structure of the venture. A JV may inherit coverage only if the assessed systems truly handle the CUI in question. If the JV introduces new systems, those systems need their own documented and defensible treatment.

Q: How do teams know whether a change is significant enough to trigger reassessment?

A: Teams should treat a change as significant when it affects the previously assessed scope or removes support for a required control. Routine patching usually does not qualify, but major functionality changes, new architecture, or altered security design often do. The deciding test is whether the assessed boundary still matches the live environment.

Q: Who is accountable when CMMC scope decisions are wrong?

A: Accountability sits with the organisation’s compliance leadership and the Affirming Official who signs the determination, especially when the decision affects assessment scope or contract eligibility. That is why scope changes need documented review, change control, and evidence that the final decision was made against current system reality.

Technical breakdown

CMMC scoping depends on the actual systems handling CUI

CMMC scope is determined by the systems that process, store, or transmit FCI or CUI during contract performance, not by organisational structure alone. That means a joint venture, a subcontractor, or a parent company cannot assume coverage simply because another party is certified. Unique identifiers, documented boundaries, and evidence that matches real data flows are what make the scope defensible. In practice, the hard problem is tracing which assets, users, and workflows actually touch controlled data across shared environments.

Practical implication: map data flows to in-scope systems before contract submission, then verify that assessed boundaries match actual usage.

Encryption reduces exposure but does not create logical separation

Encryption protects data content, but it does not by itself enforce a scope boundary. Logical separation depends on architectural controls such as firewall rules, VLANs, routing restrictions, and other enforcement points that prevent uncontrolled movement between zones. In CMMC terms, an encrypted environment can still be fully in scope if systems, admins, or network paths allow CUI to traverse beyond the intended boundary. This distinction matters because scoping is about control of interaction, not just confidentiality of data at rest or in transit.

Practical implication: demonstrate segmentation with enforceable network and system controls, not with encryption claims alone.

Significant change turns compliance into a continuous control problem

A significant change is any change that affects the previously assessed scope. That includes major functionality changes, new security designs, or modifications that remove support for a CMMC requirement. Routine maintenance, such as patching, is different because it preserves the security posture already assessed. The practical challenge is that many organisations treat assessment as a checkpoint, then let architecture drift over time. Once the environment no longer matches the SSP, the next assessment becomes a forensic exercise instead of a routine verification.

Practical implication: tie change management to reassessment triggers and keep the SSP synchronized with the live environment.

NHI Mgmt Group analysis

Scoping drift is the governance failure CMMC keeps exposing. The article shows that many organisations understand individual FAQ answers but still lose the thread between proposal time, assessment time, and ongoing operations. That is a governance failure, not a documentation problem. The boundary must be managed as a living control, or the assessed environment and the real environment will diverge. Practitioner conclusion: treat scope ownership as continuous programme governance, not an audit-season task.

Identity and access controls are part of scoping, not separate from it. When a JV, enclave, or shared service is used to process CUI, the question is not only where the data sits, but who can reach it and under what authorisation model. That makes IAM, PAM, and service account governance relevant to CMMC boundary decisions, especially where privileged admins or non-human identities can cross environments. Practitioner conclusion: align access governance with assessed boundaries before the assessor asks for evidence.

Logical separation is the more precise concept behind CMMC enclosure claims. Encryption can protect payloads, but it does not answer whether systems are operationally isolated. The article reinforces a named concept worth carrying forward: scope boundary illusion, where teams mistake a control description for a defensible boundary. Practitioner conclusion: prove segmentation with technical enforcement, not with policy language.

Continuous compliance is now the real operational requirement. The new FAQ set does not simply clarify edge cases, it signals that the DoD expects organisations to keep scope current as environments evolve. That has implications for how often teams review UIDs, SSPs, and change records. Practitioner conclusion: build recurring scope validation into normal governance cycles, not just pre-assessment readiness.

Assessment readiness and contract readiness are no longer interchangeable. The article shows that a technically compliant environment can still fail if the proposal, the system boundary, and the post-award operating model do not line up. That matters because CMMC now shapes competitive eligibility, not just audit outcomes. Practitioner conclusion: align contractual commitments, operational architecture, and evidence collection before bidding.

What this signals

Scope drift behaves like identity drift: it starts as a documentation problem and becomes an exposure problem. DIB teams should expect scoping evidence, system boundaries, and approval records to diverge unless they are continuously reconciled. Where privileged access or service credentials bridge enclaves, the boundary question becomes an IAM and PAM question as well as a compliance one.

Continuous validation is the operating model CMMC is pushing toward. The article signals a shift from point-in-time certification to ongoing proof that the live environment matches the assessed environment. That means change control, SSP maintenance, and system ownership need to be managed together rather than handed off to separate teams.

The broader lesson for identity programmes is that control boundaries fail first at the seams. When access paths, shared services, or non-human identities cross a declared scope, the organisation needs evidence that the boundary is still real, not merely documented.

For practitioners

• Map CUI flows to named systems before bid submission Document exactly which systems, enclaves, and shared services will process, store, or transmit FCI or CUI, then tie them to the CMMC UIDs used in the proposal. Do not assume a partner’s assessed status covers new assets that were never evaluated.
• Validate logical separation with enforceable controls Review segmentation through firewalls, VLANs, routing policy, and access enforcement, then prove that CUI cannot move outside the intended boundary through ordinary administration paths. Use encryption as supporting protection, not as the scoping argument.
• Operationalise significant change triggers Define which architectural changes force reassessment, which require remediation planning, and which remain routine maintenance. Include the Affirming Official in the decision path and keep those decisions attached to change records.
• Synchronise SSPs with live infrastructure Update the System Security Plan whenever systems, controls, or dependencies change, then reconcile it against actual configurations before the next affirmation cycle. Evidence drift is what turns a manageable change into an assessment failure.
• Reassess enclave assumptions for joint ventures If a JV uses shared systems, verify whether those systems were actually in scope for the relevant CUI handling model. If not, treat the JV as needing its own documented status rather than relying on inheritance.

Key takeaways

• The latest CMMC FAQ revision shows that scoping confusion is still a live governance problem, not a solved compliance detail.
• The practical risk is mismatch between the assessed boundary and the real environment, which can turn routine changes into assessment failures.
• Teams that align change control, SSPs, and access governance with actual data flows will be better positioned for continuous compliance.

Key terms

• CMMC Scoping: CMMC scoping is the process of defining which systems, users, and workflows are inside the compliance boundary for handling FCI or CUI. It is based on actual data processing, storage, and transmission paths, not on organisational charts or assumptions about inherited coverage.
• Significant Change: A significant change is an environmental or architectural change that affects the previously assessed CMMC scope or alters whether a required control still applies. In practice, it is the point at which routine change management becomes reassessment planning.
• Logical Separation: Logical separation is the technical segregation of environments so that sensitive data and the systems handling it remain constrained to a defined boundary. Encryption can protect content, but enforceable network and system controls are what create a defensible separation for scoping purposes.
• Affirming Official: An Affirming Official is the person responsible for reviewing and confirming CMMC-related compliance assertions and change decisions. The role carries accountability for whether the organisation’s stated scope and operating reality still match at the point of affirmation.

What's in the full article

Secureframe's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step CMMC scoping examples for joint ventures, paper-only CUI, and changing system boundaries
• Detailed FAQ-by-FAQ breakdown of C-Q11, C-Q12, F-Q5, and the encryption scoping clarification
• Practical examples of what counts as significant change versus routine maintenance
• Automation guidance for keeping SSPs, evidence, and scope boundaries aligned over time

👉 Secureframe's full post covers the FAQ revisions, scoping edge cases, and continuous compliance implications in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners responsible for access boundaries. It helps teams connect identity controls to broader security and compliance programmes without losing operational detail.