What Is CUI and Why It Matters for CMMC Compliance

If you’ve ever wondered why one file in a shared drive is “no big deal” and another one turns into a full CUI compliance project, you’re not alone. For most DoD primes and subs I work with, the tipping point is simple: the moment Controlled Unclassified Information enters your day-to-day tools, your expectations change fast, especially in Microsoft 365, cloud infrastructure, laptops, and those “temporary” shared folders that never go away.

In this post, I’ll define CUI in plain English, show a simple way to tell CUI from FCI, and lay out practical steps I use to help small teams reduce scope, lower risk, and avoid expensive rework during Office 365 Migration and security hardening work.

Light disclaimer: this is general information, not legal advice.

What CUI is (and what it is not)

CUI is unclassified information that still requires protection because a law, regulation, or government-wide policy says it must be safeguarded or controlled. That framing comes from the National Archives CUI Program, which standardizes how the executive branch handles CUI and how it should be shared and protected in nonfederal environments (NARA CUI Program overview). The government also maintains official categories and guidance in the Registry, which is where I check labels and handling rules when teams are unsure (CUI Registry category list).

CUI is not the same as “anything sensitive” or “anything the prime doesn’t want shared.” It’s also not a catch-all for internal business secrets. It’s a defined class of information with specific controls, and the baseline rules for the CUI program are laid out in federal regulation (32 CFR Part 2002).

CUI is also not classified data. Classified info has national security classification levels (Confidential, Secret, Top Secret) and a different handling system. CUI sits in the middle: not classified, but still restricted for a reason.

Here are a few short examples I see with DoD contractors:

• A controlled technical data package for a component you manufacture or repair.
• A test report with sensitive performance details tied to a defense program.
• A vulnerability report or security configuration details for a covered system.
• A spreadsheet that includes personal identifiers for cleared personnel (privacy-related data).

CUI vs FCI, the difference that changes your CMMC level

Federal Contract Information (FCI) is information that’s not intended for public release and is provided by or generated for the government under a contract. It’s often “normal contract business,” like schedules, pricing details, or internal deliverables that shouldn’t be posted online.

CUI is different because it’s formally controlled information with safeguarding requirements tied to law or policy. That difference changes your compliance path: FCI generally aligns with CMMC Level 1 expectations, while CUI pushes you into CMMC Level 2 territory (this is where I naturally hear people say “CUI CMMC” on project calls, because the data type drives the whole readiness plan).

A simple scenario:

• An unposted bid schedule and milestone tracker is usually FCI.
• A technical drawing that falls under export controls or controlled technical information rules is CUI, and now your tools, access, and evidence requirements jump.

Common CUI types DoD contractors run into

I keep this short on purpose, because the official names and sub-categories live in the Registry:

• Controlled Technical Information (CTI) (designs, specs, performance details)
• Export-controlled technical data (often tied to ITAR/EAR obligations)
• Procurement-sensitive info (source selection, certain pricing and evaluation data)
• Privacy data (PII in HR, badging, medical, or roster workflows)

If you’re unsure, I verify the category and the dissemination controls against the CUI Registry category list and then map handling to your actual systems.

Why CUI matters for CMMC, DFARS, and NIST SP 800-171

CUI matters because it triggers stronger safeguarding and verification expectations. It’s the difference between “have some basic controls” and “prove you’ve implemented and maintained a full security program.”

For most defense contractors handling CUI, the security requirements align to NIST SP 800-171, which lays out the safeguarding requirements for protecting CUI in nonfederal systems (NIST SP 800-171 Rev. 3 PDF). You’ll still hear “110 requirements” referenced widely because that count comes from Rev. 2, which remains the common baseline cited in many contractor assessments and legacy plans. Either way, the real work is the same: implement the controls, document them, and keep evidence.

CUI also shows up in contract clauses and flow-down language. A key clause to understand at a high level is DFARS 252.204-7012, which covers safeguarding covered defense information and cyber incident reporting (DFARS 252.204-7012 text). I’m careful here because the details can get legal fast, but the operational point is clear: if an incident hits systems handling covered data, you need reporting readiness, not panic.

On the CMMC side, the DoD has formal program guidance and updates on its site (DoD CIO CMMC program page). As of January 2026, CMMC is actively rolling out in phases, and CUI work is the common driver for CMMC Level 2.

What changes when CUI enters my environment

When I find CUI in a client environment, I treat it like dye in water. It spreads unless you build boundaries.

In practical terms, here’s what changes:

• Scoping and the CUI boundary: I decide if we can contain CUI in an enclave (preferred) or if the full network becomes in scope. This is where Cloud Infrastructure design and Data Center Technology choices matter, because segmentation and identity controls can shrink scope.
• Data flow mapping: I map how CUI moves through email, Teams, shared drives, ticketing, vendor portals, and secure file transfer.
• SSP and POA&M: I document what’s in place, what’s missing, and who owns each gap.
• Access control and MFA: I lock down identity, admin roles, and enforce MFA and conditional access. This ties directly into Endpoint Security and Device Hardening on every laptop that touches CUI.
• Logging and monitoring: I turn on the right audit logs, centralize them, and make sure someone reviews alerts.
• Encryption: I require encryption in transit and at rest, including backups.
• Incident response readiness: I build the playbook and the “who calls who” list before anything happens.
• Cloud considerations: Secure Cloud Architecture and Cloud Management policies keep CUI out of unsanctioned apps and personal storage.

Flow-down to subcontractors, the supply chain is part of my scope

If I’m a prime, I flow requirements down to subs that touch CUI. If I’m a sub, I expect to be asked for proof, not promises. That proof usually means an SSP, policies, and assessment results or readiness evidence.

This gets real during shared-tool projects: Office 365 Migration work, file sharing, ticketing systems, and even vendor remote support. I’ve seen subs inherit scope just because they were invited into a Teams channel with CUI in it. Right-sizing scope is part of my IT Strategy for SMBs work, because it protects contracts and keeps costs controlled.

How I identify, handle, and protect CUI without blowing up scope

I treat CUI like a controlled chemical in a lab. You don’t ban it, you control where it goes, who touches it, and how you clean up after.

That mindset shapes my Cybersecurity Services and day-to-day delivery, from endpoint builds to Business Continuity & Security planning.

Step-by-step workflow, how I determine if data is CUI

1. Check the contract, SOW, and deliverables for data types and handling notes.
2. Look for CUI, CDI, DFARS, or security requirement references in the contract package.
3. Ask the prime or contracting officer for clarification if the data type is unclear.
4. Verify the category and controls against the NARA CUI Registry.
5. Confirm markings and any dissemination controls, keep originals intact.
6. Map where the data is stored, synced, emailed, printed, or uploaded.
7. Decide the system boundary (CUI enclave vs full network).
8. Document decisions in the SSP, track gaps in the POA&M.

Tip for Small Business IT teams: contracts owns steps 1 to 3, program owns steps 4 to 6, IT and security own steps 6 to 8. I make those owners explicit so nothing falls between teams.

Marking and handling basics I put in place right away

I start with habits that prevent accidental spread:

• Preserve markings, and mark derived documents when required.
• Restrict access by need-to-know, enforce least privilege.
• Use secure sharing, avoid open links and personal accounts.
• Handle printouts with care (clean desk, locked storage, proper disposal).
• Configure Microsoft 365 tenant controls, MFA, and conditional access, then validate secure file transfer paths.

Common pitfalls that derail CUI CMMC efforts (and how I avoid them)

• Not knowing where CUI lives, I fix this with data discovery and quick interviews.
• Mixing CUI with general email and shared drives, I fix this with a scoped enclave and clear rules.
• Personal devices and unmanaged endpoints, I fix this with Endpoint Security baselines and Device Hardening.
• Missing SSP and POA&M, I fix this by building them alongside technical work, not after.
• Ignoring subcontractors, I fix this by defining flow-down early and validating tools used to share data.

This is where Infrastructure Optimization pays off. Every control you automate is one less fire drill later.

Practical checklist for CUI and CMMC Level 2 readiness

• Identify: CUI inventory, contract review, category confirmation
• Scope: boundary definition, data flows, enclave decision
• Protect: MFA, least privilege, logging, encryption, backups, vuln management
• Prove: SSP, POA&M, policies, evidence collection plan
• Maintain: patch cadence, alert review, incident drills, supplier checks

If you’re moving fast and juggling delivery work, this is when Technology Consulting and a Business Technology Partner can cut weeks off the timeline, especially when cloud infrastructure and data center technology decisions affect scope.

FAQs DoD contractors ask me about CUI

Is everything in a DoD contract CUI? No. Many files are FCI, and some are public. CUI is defined and tied to control rules.

Can CUI live in Microsoft 365? Yes, if the tenant is configured and managed correctly, and your security controls match your requirements.

What if the prime doesn’t mark it? I don’t assume “unmarked means safe.” I ask for clarification and validate against the Registry and contract language.

Do restaurants or retail tools like Restaurant POS Support ever touch CUI? Usually no. The risk shows up when a shared network or shared admin accounts connect Kitchen Technology Solutions, back-office PCs, and CUI workloads without segmentation.

Do I need CMMC if I only have FCI? Many will still need Level 1. The moment you handle CUI, Level 2 preparation becomes the practical path.

What documents do assessors expect? At minimum, an SSP, a POA&M, policies, and evidence that controls are operating.

Conclusion

CUI is unclassified information that still has required safeguards, and it’s the trigger that pushes most DoD contractors toward CMMC Level 2 work aligned to NIST SP 800-171. In my experience, the fastest win isn’t buying another tool, it’s scoping: define the CUI boundary, control handling, and keep CUI from spreading into every laptop, mailbox, and shared drive.

If you want a quick next step, I recommend a short CUI discovery and data flow review. It’s the foundation for Tailored Technology Services and Innovative IT Solutions that protect contracts, support Digital Transformation, and reduce risk without dragging your whole company into scope. Light reminder: this is general guidance, not legal advice.