This might be the biggest question right now: with the program under federal review, is continued investment worth it?

There's real uncertainty about how CMMC's third-party certification piece will shake out. What isn't uncertain is NIST SP 800-171 itself.

Most contracts carry the DFARS 252.204-7012 clause, and 7012 alone means self-attestation to 800-171 is required, regardless of what happens with CMMC's timeline or structure. That obligation doesn't disappear while the program is under review. The clause that brings in third-party certification is 7021, and it's the piece still working through changes. Waiting to see how 7021 shakes out is a reasonable instinct. Treating that same uncertainty as a reason to pause work on 800-171 itself is not, since that requirement already applies under 7012 and isn't going anywhere.

Scoping is a major source of confusion because it depends on how an asset interacts with CUI, not which category it seems to fall into.

Start by mapping the data flow: where CUI enters, where it's stored and processed, how it moves between systems, and which systems provide security functions. A few patterns worth knowing:

• VDI and remote-access endpoints can stay out of scope, but only if the local device is genuinely restricted to keyboard, video, and mouse interaction, with no local storage, processing, or transmission of CUI.
• Encryption doesn't take the surrounding infrastructure out of scope. A laptop transmitting encrypted CUI to the cloud still puts every switch, firewall, and wireless component it passes through in scope, since they're carrying that traffic.
• Enclaves suit word processing and tend to strain under anything heavier — CAD work, software development, physical build documentation. One hole in the boundary, such as a jump box bridging on-prem and cloud, can pull the network on the other side back into scope.

To decide whether something belongs in your boundary, ask: Can it store, process, or transmit CUI? Does it provide a security function for something that does? And if architecture is doing the work of limiting scope, can you trace the data flow and explain why CUI can't cross it?

Accurate scoping starts with knowing what you're protecting, and CUI is rarely as obvious as expected.

Sometimes the confusion runs backwards. A contract with DFARS 252.204-7012 but not 7019, 7020, or 7021 leads some contractors to assume 800-171 doesn't apply. It still does. The 7012 clause alone establishes that information from the government could potentially be CUI, so self-attestation is required regardless.

The reverse problem shows up too: information gets marked CUI when it doesn't look sensitive.

• An email stamped "CUI" might contain nothing more than a meeting time. Honor the label until you get clarification, even if it turns out to be over-marking.
• Part numbers on an RFQ can go either way. One issued by the government under a specific contract is likely FCI at minimum; one generated internally usually isn't.
• Geolocation data from a workforce app is typically a company privacy concern rather than CUI, unless the person tracked is a federal or military employee rather than a contractor.

When status is genuinely unclear, ask the organization that provided the information rather than guess. Getting it right early keeps uncertainty from spreading into scope, asset inventory, and technology decisions.

Cloud providers, MSPs, consultants, and fractional employees all affect a CMMC environment differently, depending on what they can touch.

• Access, not title, defines consultants and fractional roles. A fractional CISO who logs in monthly to review policies can be named system owner in an SSP, held to the same standard as any other user with potential CUI access. A consultant who only reviews documentation generally doesn't need to be listed at all.
• "FedRAMP authorized" doesn't guarantee every feature is covered. Additional modules can sit outside the original ATO, nullifying coverage for that functionality. Baseline level matters too, since FedRAMP Moderate isn't sufficient for data requiring FedRAMP High, like naval nuclear information, ITAR, or EAR.
• FedRAMP equivalency claims deserve scrutiny. A provider claiming equivalency must meet 100% of FedRAMP Moderate controls at all times, with zero permitted POA&Ms, which is stricter than FedRAMP authorization itself. They owe you an SSP, a Security Assessment Report from an independent third party, and a customer responsibility matrix. Missing any of those documents means an assessor will fail you for storing CUI there.
• A non-authorized tool touching CUI is an incident, even briefly and even by accident. Quick cleanup doesn't remove the reporting requirement.

Before adopting any tool or provider that touches CUI, confirm what's actually covered and ask for documentation rather than taking "FedRAMP" or "equivalent" at face value.

Sometimes CUI has to leave its normal environment: a customer site, a location without internet, removable media.

One real scenario: a team needed CUI CAD drawings at a client site with no internet. An encrypted USB drive was the right instinct, but only part of the answer. The rest included:

• Confirming the drive was validated to the correct FIPS standard (140-2 is sunsetting in favor of 140-3).
• Training on who's authorized to use the media.
• A process for tracking possession.
• Rules for transport and for what happens to the data once the work is done.

For any workflow that moves CUI outside your normal environment, nail down the device or media, the encryption standard, who's authorized to use or transport it, how possession is tracked, and where the data can and can't go. A documented process only helps if employees know when they can use the technology and what's expected of them.

Assessment readiness means evidence that your controls function as documented, not just paperwork on file.

• Your SSP should describe the environment you operate today.
• Data flow diagrams should match the real architecture.
• If CUI can't leave a VDI session, your configuration should enforce that.
• If a third party owns part of a requirement, you should be able to show where their responsibility ends and yours begins.

This matters most for scoping. In a complex, segmented environment, the strength of your scoping argument comes down to whether you can trace and explain how CUI actually moves through the architecture, not just assert that it doesn't cross a boundary.