Rev. 2 to Rev. 3: What Changes for a Small Enclave

Coverage of the proposed FAR CUI rule has focused on the parts that generate headlines: a new clause set, a new standard form, a 72-hour reporting window. Those are real. They are also the parts a competent contracts person absorbs in an afternoon.

The part with a long tail is a single reference buried in the clause text. Proposed FAR 52.240-7 would require contractor systems handling Controlled Unclassified Information — CUI — to meet the security requirements of NIST SP 800-171 Revision 3. The Department of War still enforces Revision 2, and the July 13 suspension of CMMC Phase II did nothing to change that.

Same standard. Different revision. Potentially both at one company. That is the most durable question in this series, because it outlives whatever happens to any particular rulemaking.

Why the two sides sit on different revisions

NIST published Revision 3 of SP 800-171 in May 2024. The gap that opened afterward isn't disagreement about security. It's a difference in what each side had to do to move.

One further signal is worth knowing about precisely because it's easy to over-read. In 2025 the Department published its own set of organization-defined parameters for Rev. 3 — the values a contractor would fill in if Rev. 3 ever became the defense baseline. That changed nothing about what anyone owes today. What it tells you is that preparation for a revision change has been underway for a while, which is more useful than a prediction.

What changed between the revisions — structurally

This article won't walk you through the differences requirement by requirement. That belongs in the standard itself, it would be stale within a year, and a blog post pretending to substitute for NIST SP 800-171 does you a disservice. What's worth understanding is the shape of the change, because the shape determines how much work the delta represents.

Four structural shifts matter more than any individual requirement:

The count went down; the work didn't

Roughly a third of the Rev. 2 requirement numbers are marked withdrawn in Rev. 3. Very few disappeared as obligations — most were absorbed into adjacent requirements or consolidated into broader ones. Reading “97 instead of 110” as a reduction in effort is the most common misread of this revision.

Organization-defined parameters arrived

Rev. 3 embeds bracketed values inside the requirement text — frequencies, thresholds, time periods — that the organization specifies. They appear in roughly half the 97 requirements. These are not configuration tasks. They are decisions, each needing a rationale, an approver, and a place to live in your documentation. For a small contractor without a security committee, this is the least technical and most underestimated part of the delta.

Assumed controls stopped being assumed

Rev. 2 leaned on a category of controls expected of any competent organization and therefore not spelled out. Rev. 3 largely drops that convenience, aligning to NIST SP 800-53 Rev. 5 as the single authoritative source and eliminating the old basic-versus-derived split. Practically: policy and planning documentation that used to be implied is now explicit — which is why the new Planning family shows up.

The assessment got more granular

The companion assessment publication grew from 320 determination statements to 422. Same broad control territory, finer-grained proof. An evidence set built to answer 320 questions will answer some of the 422 and not others.

What “working the delta” concretely involves

Here is what surprises people: at small-enclave scale, most of the delta is paperwork and decisions, not architecture. A contractor who built a properly scoped CUI enclave to Rev. 2 does not tear it down. The controls are recognizably the same controls. What changes is how they're described, parameterized, and proved.

Scope decides how big the delta is

Every item on that list is priced per unit of scope. That is the whole argument.

Crosswalking artifacts, setting parameters, and re-baselining evidence all scale with the number of systems, users, and locations inside your protected boundary. A contractor who confined CUI to a defined enclave works the delta once, across a small footprint. A contractor who hardened the whole company for CUI living on one contract works the same delta across every laptop, mailbox, and file share in the business — and then, on a mixed portfolio, maintains two revision baselines across all of it.

That multiplication is the real cost of an unscoped posture, and it stays invisible until a revision changes. The proposal leans the same way: it clarifies that certain assets would sit outside scope, which only helps a contractor who drew a boundary in the first place. This is what Volume 2 of the CMMC Practical Guides spends its scoping chapters on — enclave scope is a decision you make once and collect on repeatedly, at every assessment, every platform change, and every revision of the standard. The 110 practices across 14 domains don't get easier. The surface you apply them to is the variable you control.

NIST SP 800-172, scoped accurately

One more publication belongs here, and it's routinely inflated in vendor marketing, so precision matters.

NIST SP 800-172 is a supplement to SP 800-171, not a replacement. It provides enhanced requirements aimed at advanced persistent threats, for CUI associated with a critical program or a high-value asset. NIST finalized Revision 3 of it in May 2026, expanding the objective from confidentiality alone to confidentiality, integrity, and availability.

The proposed rule contemplates that for contracts involving critical programs or high-value assets, an agency could layer selected 800-172 controls on top of the Rev. 3 baseline. That's the accurate statement. Four qualifiers keep it from becoming something it isn't:

• It's selective, not wholesale. NIST is explicit that there's no expectation agencies will require all of the enhanced requirements; they're picked against mission risk.
• It applies only when an agency invokes it. Nothing in 800-172 self-executes. It arrives in a contract or it doesn't exist for you.
• The trigger is narrow. Critical programs and high-value assets are a small slice of federal work.
• The defense analogue is tiny. Under 32 CFR Part 170 the Department selected a subset of the original 800-172 requirements as the basis for CMMC Level 3 — well under one percent of the defense industrial base, assessed by the government rather than by self-assessment.

If you're a five- to fifty-person contractor with limited CUI on a services contract, the honest expectation is that this never touches you. Know the term, recognize it in a solicitation, and don't budget for it on spec.

📚 The method behind the argument

This article covers one revision change. The full method — scoping the boundary, building the artifact set, and running the self-assessment — runs to two volumes.

CMMC Level 1: A Practical Guide for Small to Medium GovCon Contractors

All fifteen practices, FCI versus CUI, scoping, the system description, evidence, and the annual affirmation — written for the 5- to 50-employee contractor.

CMMC Level 2: A Practical Guide for Small to Medium GovCon Contractors

CUI enclave scoping, the 110 practices across 14 domains, the system security plan, POAM framework, and risk register — without assuming an enterprise IT department.

Overwatch Press. Kindle, paperback, and hardcover — Kindle from $12.99. See the series on Amazon →

Build once, map twice

The mixed-portfolio contractor — defense work under DFARS 252.204-7012 and civilian work that would fall under the proposed clauses — has the most interesting problem here. Two regimes, two revision numbers, one company.

The answer is not two enclaves. It's one enclave and a documentation set built to be mapped twice — a few habits that cost almost nothing adopted early and a great deal retrofitted:

• Organize artifacts by what they do, not by the requirement number they satisfy. An access control policy is an access control policy. Filing it as “3.1.1” welds it to one revision's numbering.
• Keep a crosswalk column. One spreadsheet column per applicable standard, mapping each artifact to the requirement it answers under each. When a revision changes, you update a column, not a library.
• Write parameters as named values. Put your chosen frequencies and thresholds in one register that the procedures reference, rather than hardcoding numbers into a dozen documents.
• Separate the description of the environment from the mapping. What your enclave is doesn't change when a revision does. Keep that description standalone so it survives.

None of this is exotic. It's the same discipline that lets a Level 1 system description survive a platform migration, applied one level up. Worth noting: the proposal would renumber the familiar FAR 52.204-21 basic safeguarding clause as well — another reason to anchor documentation to function rather than to citation.

Why lead time is the right frame

Here is the asymmetry that makes this worth acting on even though the rule is only a proposal.

Running a gap assessment against Rev. 3 produces a document. If the rule shifts, changes revisions, or slips a year, you've spent modest effort and you own a current, honest picture of your environment — useful for the defense side, for a prime's questionnaire, and for your own risk decisions. There is no version of the future in which knowing your gaps is wasted.

If it finalizes roughly as written, the Council expects to complete the Overhaul rules before the end of 2026, with no anticipated phase-in once clauses are inserted into contracts. Under the proposal, an offeror who can't meet every requirement at proposal time would disclose the gaps and provide a POAM. Workable — and dramatically more workable when that POAM comes from an assessment you already ran rather than one you're drafting in the last week of a proposal.

That's the case. Cheap if nothing happens, months saved if something does. The work takes the same time either way; the only variable is whose calendar it runs on.