It usually fails at the handoff between policy and proof. Organisations may know what CUI is, but they cannot maintain a current inventory of where it lives, who can reach it, and whether each access path still has a valid justification. When that evidence is missing, compliance becomes hard to defend and harder to sustain.
Why CMMC Level 2 Breaks at the CUI Boundary
CMMC Level 2 usually fails when organisations can describe their CUI policy but cannot prove operational control. The weakness is rarely the control family on paper; it is the evidence trail. If you cannot show where CUI resides, who can reach it, and why each access path still exists, the programme is difficult to defend and even harder to sustain.
That gap matters because CUI governance is not only about classification, it is about traceability across systems, users, and exceptions. A control that cannot be demonstrated in current state is treated as fragile, even if the written policy looks complete.
What the Handoff Between Policy and Proof Really Requires
The handoff fails when policy language is not converted into inventory, ownership, and access evidence. In practice, that means the organisation lacks a living map of CUI locations, a current list of approved readers, and a repeatable way to confirm that access paths still match business need.
Current-state proof usually needs more than a document. It needs a defensible record of data placement, system boundary decisions, exceptions, and periodic review. When those records are fragmented across teams, the control becomes performative: declared, but not operationally testable.
One useful way to think about the problem is through governance maturity. An NHI Governance Maturity Model is about non-human identity, but the underlying maturity logic is similar here: inventory, ownership, access, lifecycle, and monitoring have to exist together or the programme stalls at the “we think we know” stage.
Where Practitioners Usually Miss the Control
Most failures cluster around three omissions. First, the CUI inventory is incomplete, so data lives in file shares, collaboration tools, exports, and downstream systems that are not all captured. Second, access review focuses on entitlements rather than actual data reachability, so people approve accounts without verifying whether those accounts can still touch CUI. Third, exceptions become permanent because no one owns expiry and recertification.
That is why technical controls alone do not close the gap. The control objective is not simply to restrict access, but to maintain a current, auditable justification for that access. If a reviewer cannot connect a user, system, and business purpose back to a current CUI location, the governance model is already weak.
For CUI specifically, the same discipline used in the NIST SP 800-53 Rev 5 Security and Privacy Controls around access control, auditability, and configuration management is the practical baseline. The point is not the framework name, it is the operational demand that access, review, and evidence stay aligned.
Risk and Threat Considerations
The main risk is uncontrolled CUI exposure through stale access paths, shadow repositories, and weak exception handling. When inventory and justification drift, the organisation may believe it has governed CUI while quietly expanding the number of places where sensitive information can be read, copied, or forwarded.
Failure mechanism: Policy exists, but no one can continuously reconcile the authoritative CUI inventory, the systems that actually store or transmit it, and the access approvals that justify who can reach it.
Impact: Audit evidence becomes inconsistent, access decisions become hard to defend, and a compromise or misrouted file can create broader disclosure than the written control set suggests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Current CUI governance depends on current approved users and access paths. |
| AU-6 — Audit Record Review, Analysis, and Reporting | CUI proof depends on auditable evidence of access and handling. | |
| CM-8 — System Component Inventory | CUI governance fails when the organisation cannot inventory where protected data lives. | |
| Recommendation — Review and revoke CUI access that lacks a current business justification. Use audit review to verify who accessed CUI and whether access remains justified. Maintain a current inventory of systems and repositories that store or process CUI. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | CUI location and ownership depend on a current asset and information inventory. |
| A.5.15 — Access control | CUI governance requires enforcing who may reach protected information and why. | |
| Recommendation — Keep the information inventory current enough to support CUI location and ownership decisions. Apply access control so CUI access remains limited to current business need. | ||
Practitioner Guidance
What to prioritise: Start with the smallest defensible CUI register you can keep current, not with a perfect policy rewrite. If the inventory is not trusted, every downstream review is built on sand.
What to verify: For each CUI location, verify the owner, the system boundary, the approved reader set, and the review cadence. If any one of those is missing, treat the control as incomplete even if the document set looks polished.
Common mistake: Treating annual attestation as proof of ongoing governance. A once-a-year signoff does not tell you whether access still matches current business need.
Practitioner takeaway: CMMC Level 2 fails when governance is document-complete but evidence-poor, so the real test is whether you can prove current CUI location, current access, and current justification without reconstructing the story by hand.