TL;DR: CMMC is aimed at unclassified government data that still requires protection, especially Controlled Unclassified Information, rather than classified material, according to Secureframe. The practical issue is scope: defence contractors must know what data they handle, where it lives, and which systems actually need safeguards.
At a glance
What this is: This article explains the government data hierarchy and shows that CMMC is designed to protect unclassified information that still requires safeguards, especially CUI.
Why it matters: IAM and security teams supporting defence contractors need clear data scoping because the real control problem is not classification alone, but which systems handle protected unclassified data and therefore fall into compliance scope.
Context
CMMC is often misunderstood because people equate protection requirements with classified information, but the real governance problem is scoping unclassified data that still has federal handling requirements. In practice, the control question is not only what the data is called, but where it resides, who can access it, and which systems are allowed to process it.
For defence contractors, that creates an identity and access management challenge as much as a compliance one. Systems that store or transmit Controlled Unclassified Information need permissions, auditability, and boundary control that match the sensitivity of the data, even when the data is not classified. The article is typical of a recurring contractor confusion point rather than an edge case.
Key questions
Q: How should defence contractors scope systems that handle CUI?
A: Start by identifying the exact systems, users, and workflows that store, process, or transmit CUI, then draw the compliance boundary around those assets. Scope should follow data flow and access reality, not organisational convenience. That keeps controls targeted and avoids both under-scoping and over-scoping.
Q: Why does unclassified data still create CMMC obligations?
A: Unclassified data can still be sensitive enough to require federal safeguards, especially when it includes technical information, export-controlled material, or contract-related content. CMMC exists because the protection requirement is driven by handling need, not by whether the data is classified. Security controls therefore have to follow the data, not the label.
A: Treating all data the same way creates friction, weakens adoption, and can push teams toward unsafe workarounds. It also makes it harder to distinguish sensitive customer information from routine operational data, which leads to either over-restriction or under-protection. In practice, that means slower decisions, poorer collaboration, and weaker control over the data that matters most.
Q: How do enclaves help with CMMC compliance?
A: Enclaves help by isolating the systems that handle CUI so the rest of the environment does not inherit those requirements. They only work when the boundary is technically and operationally enforced across identity, storage, and connectivity. Otherwise, the enclave becomes a paper boundary rather than a real one.
Technical breakdown
How the government data hierarchy shapes CMMC scope
CMMC sits in the middle layer of the government data hierarchy, not at the top secret end. Classified data is protected primarily through accredited facilities and isolated networks, while unclassified data with no special handling needs little or no federal safeguarding. The important middle category is Controlled Unclassified Information, which is unclassified but still requires protection under law, regulation, or policy. That distinction matters because scope is driven by handling requirements, not by whether the data is stamped classified or not. The technical consequence is that contractors must map data flows, system boundaries, and access paths before deciding which environments are in scope.
Practical implication: Map which systems store, process, or transmit CUI before applying controls so you scope the right environment.
Why unclassified data still needs access controls and logging
Unclassified does not mean low risk. Technical data, export-controlled information, contractor data, and personal information can all sit outside classified networks while still creating legal, operational, and security exposure if mishandled. CMMC therefore relies on commercial-environment controls such as access restriction, encryption, audit logging, and configuration management rather than physical isolation alone. That is a very different protection model from classified systems. The governance challenge is that the organisation must enforce consistent control behaviour in shared cloud, endpoint, and collaboration tooling where protected data actually lives.
Practical implication: Apply least privilege, logging, and encryption to CUI-bearing systems even when the data is not classified.
What scoping and enclave design do in practice
Scoping is the process of identifying which systems, users, and workflows touch CUI so that the organisation does not overextend CMMC controls across the entire estate. Enclaves are one way to reduce scope by isolating CUI-handling systems from the broader business environment. This is less about turning the enterprise into a classified network and more about creating a defensible boundary around protected unclassified data. The real architectural issue is whether the boundary is consistently enforced across identity, access, storage, and transmission paths.
Practical implication: Use enclave-style boundaries only where they genuinely reduce CUI scope and keep the boundary enforceable.
NHI Mgmt Group analysis
Scope drift is the real CMMC failure mode. Most contractor confusion comes from treating classification labels as the control boundary, when the actual obligation is tied to where sensitive unclassified data is handled. That creates a governance problem, not just a compliance one, because mis-scoped systems either miss required protections or absorb unnecessary control overhead. Practitioners should treat data classification and system scoping as separate decisions.
CUI governance is inseparable from identity governance. Once protected unclassified data lives in commercial systems, its security depends on how identities are authorised, monitored, and limited across cloud, collaboration, and engineering tools. That makes access review, permission design, and auditability core parts of CMMC readiness, not adjacent activities. The practical conclusion is that identity controls become the operating layer for safeguarding unclassified government data.
CMMC is really a boundary-management standard for commercial environments. It does not try to recreate classified infrastructure inside contractor estates. Instead, it asks whether the organisation can consistently identify protected data, confine it to the right systems, and demonstrate that the chosen boundary is controlled. For security leaders, the lesson is that policy language matters less than the enforceable access and system boundary around CUI.
The strongest named concept here is CUI scope discipline: the discipline of identifying exactly which systems and workflows handle Controlled Unclassified Information and limiting controls to that boundary. Without that discipline, organisations either underprotect CUI or over-scope the whole environment, and both outcomes weaken the programme. Practitioners should make scoping evidence-driven, not assumption-driven.
What this signals
CUI scope discipline: contractors need a defensible way to identify where protected unclassified data lives, because the control burden belongs to the boundary, not the whole enterprise. That makes data flow mapping and system ownership central to CMMC readiness.
Identity governance becomes part of CMMC execution whenever CUI sits in shared cloud or collaboration platforms. Access reviews, privilege limitation, and auditable entitlement changes are the operational controls that keep unclassified government data inside scope without overextending the programme.
For practitioners
- Define the CUI boundary first Build a current inventory of systems, users, and workflows that store, process, or transmit CUI before assigning CMMC controls.
- Separate classified and unclassified handling paths Document which environments are reserved for classified material and which commercial systems are authorised for CUI so teams do not mix protection models.
- Apply access controls to CUI-bearing systems Tighten permissions, review entitlements, and log access for cloud, endpoint, and collaboration platforms that carry protected unclassified data.
- Use enclaves only where they reduce scope If you isolate CUI into an enclave, make sure the boundary is technically enforceable and does not simply move the scoping problem elsewhere.
Key takeaways
- CMMC is about protecting unclassified government data that still requires safeguarding, not about managing classified material.
- The main implementation risk is scoping error, because contractors must know exactly which systems handle CUI and therefore need controls.
- Identity and access controls are part of the compliance boundary when CUI lives in commercial systems, cloud services, or collaboration tools.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CMMC scope depends on how permissions are assigned around CUI-bearing systems. |
| Recommendation — Apply PR.AA-05 to restrict CUI access to the minimum set of authorised users and systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's scope question depends on governed user and service account access to protected data. |
| Recommendation — Use CIS-5 to inventory and control accounts that can reach CUI systems. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central to limiting who can access unclassified but protected government data. |
| Recommendation — Enforce AC-6 so only explicitly authorised identities can access CUI repositories and workflows. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Privileged access to contractor systems determines whether CUI boundaries stay enforceable. |
| Recommendation — Review privileged access rights for any system that stores or transmits CUI. | ||
Key terms
- Controlled Unclassified Information: Controlled Unclassified Information, or CUI, is sensitive federal information that must be protected according to defined handling rules outside federal systems. For practitioners, the key issue is not only storage security but also proving that every system, identity, and data path in scope preserves those rules.
- 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.
- Enclave Architecture: An enclave architecture isolates a specific data set, user group, or workload into a more controlled environment than the wider enterprise. For CUI, it limits blast radius and reduces scope, but it only works when the boundary, identity paths, and administrative controls are tightly managed and continuously evidenced.
- Data Hierarchy: A data hierarchy is a structured way of ranking page content by urgency and operational value. In identity administration, it separates information that must appear immediately from information that can load later. This approach helps teams balance usability, response time, and scalability as datasets grow.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity control design to the wider security and compliance programmes they run.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org