The obligation behind every program name
Under the program acronyms, the obligation is the same across the federal market: protect Controlled Unclassified Information on your systems, implement NIST SP 800-171, document it in an SSP, and be able to prove it. DoD verifies it through CMMC and GSA through an authorization process, while NASA and DOE impose it through their own directives.
The engineering is the same under all of them, and that is what we sell. Programs pause, phase in, and change names, but the contractual duty to protect CUI stays, and so does the False Claims Act exposure for misrepresenting it.
What the program covers, end to end
- Federal CUI applicability. We work out which of your contracts, agreements, and flow-downs impose CUI obligations, and which version of 800-171 each one incorporates.
- Contract and agreement review. A clause-level reading of DFARS 252.204-7012/7019/7020, agency CUI clauses, prime flow-downs, and any assessment or authorization conditions.
- CUI categories and data-flow discovery. We find which categories you hold and where they enter, travel, and rest. Discovery identifies the boundary you can defend, and where it falls depends on your data flows and security dependencies.
- System boundary definition. Every architecture, budget, and assessment decision depends on this scope document.
- SSP and POA&M development. Both are written from the live environment against the revision your contracts require, and structured so they can be converted or dual-tracked as baselines change.
- Microsoft architecture. The six security planes (Entra ID, Intune, Purview, Defender, WDAC, audit and logging) are engineered as one system in GCC High and Azure Government. See GCC High Migration and Azure Government.
- Evidence collection. Artifacts are gathered at the assessment-objective level using SP 800-171A, because objectives are what assessors and authorizing officials test.
- Assessment readiness. We run a mock assessment against the applicable methodology before any C3PAO, government reviewer, or authorizing official sees the package.
- Continuous monitoring and sustainment. Evidence refresh, control validation, and POA&M management continue under managed compliance.
We proved this delivery model in our own CMMC Level 2 assessed environment, with objective-level evidence for the assessed boundary, and on Allyon's June 2026 certification. We now apply the same engineering and evidence standard to federal CUI at DoD, GSA, NASA, DOE, and other agencies. See agency CUI programs.
Questions contractors ask us
Does NIST SP 800-171 only apply to DoD contractors?
No. NIST SP 800-171 is the government-wide standard for protecting CUI on nonfederal systems. DoD imposes it through DFARS 252.204-7012, but GSA, NASA, DOE, and other agencies apply it through their own clauses, policies, and authorization processes. If your contracts involve CUI, some form of 800-171 obligation is almost certainly attached. What you need to establish is which version applies and how it is imposed.
Which revision of 800-171 applies to us, Rev. 2 or Rev. 3?
Your contracts and agreements decide. NIST finalized Rev. 3 in May 2024, but the publication date does not change your obligation: you follow the version incorporated into each contract, agreement, or agency policy. DoD work generally still points at Rev. 2, while some civilian processes are moving to Rev. 3. We inventory your contractual baselines before changing anything. See the Rev. 2 vs. Rev. 3 guide.
Is this the same thing as CMMC?
No. CMMC is one assurance mechanism layered on top of 800-171 for DoD work. The obligation underneath is to protect CUI and implement the standard, and CMMC, agency authorization, government review, and independent assessment are the different ways customers verify it. We build the operational program once, then point it at the assurance outcome your contracts require. For the DoD lane, see CMMC Readiness.
What if different customers impose different requirements?
That is the normal case. One customer wants a Rev. 2 SPRS score, another references Rev. 3 with agency-defined parameters, and a third has its own CUI clauses. A single well-engineered control implementation with objective-level evidence can satisfy all of them, which is the premise of the Factory model.
Map your CUI obligations across every contract.
Tell us which agencies and clauses you work under and where your program stands. A practitioner will map your applicability, your baseline versions, and the shortest path to a defensible program. Or email rj@indirectit.com directly.