NIST 800-171 Rev 2 vs Rev 3: What Changed

NIST 800-171 Rev 3 is not Rev 2 with thirteen requirements removed. It is a new evidence map.

The headline count fell from 110 requirements to 97. That invites the wrong conclusion. Revision 3 adds 19 requirements, introduces organization defined parameters, moves outcomes between families, combines some requirements, removes the basic and derived distinction, and aligns the structure more closely with NIST SP 800-53 Revision 5.

A contractor that edits the old system security plan line by line will miss the real work. The transition needs a new requirement crosswalk, approved parameter values, a fresh boundary review, revised implementation statements, and evidence tests that match the new wording.

One point comes first: publication is not the contract trigger. Confirm which revision applies, to which system, by which date, under which clause and customer direction. Then migrate with evidence.

The NIST 800-171 and CUI Security hub connects this comparison to the broader program. Use the complete NIST 800-171 guide for the operating foundation and the assessment guide for proof design. GS Consulting applies the same discipline through secure AI automation.

NIST 800-171 Rev 2 vs Rev 3: The Short Answer

NIST published SP 800-171 Revision 3 in May 2024. The final publication has 97 active requirements across 17 families. Revision 2 has 110 requirements across 14 families.

Revision 3 adds Planning, System and Services Acquisition, and Supply Chain Risk Management as requirement families. It also uses organization defined parameters, or ODPs, so the organization sets values that were once fixed in the text or left elsewhere.

The official NIST Revision 3 FAQ explains the other structural shifts. The basic and derived requirement distinction is gone. Nonfederal organization items are gone. Organization responsible for control decisions are gone. Redundant requirements were removed, related requirements were combined, and some requirements were added because the source controls changed.

These are not cosmetic edits. They change how the contractor assigns ownership and proves that the security outcome exists in the covered environment.

The Contract Gate Comes Before the Crosswalk

NIST publishes the security requirements. The contract tells a contractor what applies. That distinction matters now because several federal and defense programs still reference Revision 2 while organizations prepare for Revision 3.

The August 2025 NIST SP 1318 small business primer says that CMMC was based on Revision 2 at publication and tells contractors to check their contract. Current DoD CMMC program information still describes Level 2 as the 110 Revision 2 requirements. It also states that DoD suspended Phase II on July 13, 2026 while Phase I self assessments continue.

Do not turn that pause into a reason to ignore Revision 3. It is a reason to keep two facts separate. Current contract execution may still require Revision 2. Future customer direction, new clauses, civilian work, or a direct contract requirement may trigger Revision 3. Preparation is prudent. Applicability is specific.

Keep a trigger record with the contract or subcontract, clause, required publication and revision, customer interpretation, affected system, due date, and decision owner. Update it when terms change. If the answer is unclear, ask the contracting officer or prime in writing and preserve the response.

Where Revision 3 Changes Structure and Scope

Revision 3 focuses the requirements on components that process, store, or transmit CUI and the components that protect them. This can support a deliberate enclave, but it does not make scope automatic. The contractor still needs a data flow, component inventory, user map, provider map, and rationale for protective components.

Scope decisions should be visible enough for an assessor, customer, engineer, and system owner to reach the same conclusion. If four people draw four boundaries, the system is not ready.

GS Revision 3 Transition Work Index

GS Consulting analyzed the official NIST Revision 2 to Revision 3 change workbook. We counted significant changes, new requirements, active requirements with a new ODP, active requirements, and withdrawn mapping rows for each Revision 3 family.

The base model weights significant changes at 30 percent, new requirements at 25 percent, requirements with a new ODP at 20 percent, active requirement count at 15 percent, and withdrawn mapping count at 10 percent. Each metric is divided by the highest family value. The final result is indexed to the highest raw family score at 100.

Access Control scores 100.0 in the base model. Configuration Management scores 91.5. Physical and Environmental Protection scores 63.7, Audit and Accountability scores 63.0, and Identification and Authentication scores 62.4.

The first two families stand apart because they combine broad active sets with many significant changes, ODP decisions, or new requirements. They also touch the system boundary, account model, configuration baseline, remote access, privileged activity, and evidence sources that other families rely on.

The sensitivity case shifts weights to 25 percent significant changes, 30 percent new requirements, 25 percent ODPs, 10 percent active count, and 10 percent withdrawn mappings. Configuration Management moves to first and Access Control moves to second. The exact leader is sensitive. The first pair is not.

This index is a sequencing aid. It is not a NIST score, an assessment result, or a statement that a lower family is less important. One missing requirement can still matter more than an entire family for a specific system or contract.

Read the Official Change Counts Correctly

The official workbook contains 130 analysis rows: 97 non-withdrawn Revision 3 requirement rows and 33 rows marked withdrawn. Among the 97 non-withdrawn rows, NIST classifies 46 as significant changes, 19 as new, 18 as having no significant change, and 14 as minor changes. The workbook contains a fifteenth minor-change flag on one row that is also marked withdrawn, so the raw category flags should not be added as though they were 98 active requirements.

Forty nine active requirements contain at least one new ODP. That count overlaps the four change categories. It is a separate implementation signal, not a fifth category.

The 33 withdrawn mappings need equal care. A withdrawn row does not always mean the security outcome vanished. Some content moved, combined, or became redundant. Trace the former requirement to its Revision 3 destination and document where its proof now lives.

The practical rule is simple: never close a Rev 2 row because the workbook says withdrawn until the team records the surviving outcome, the new owner, the implementation effect, and the evidence effect.

Organization Defined Parameters Need Owners

An ODP turns a requirement into a local decision. The organization may need to set a frequency, event, role, duration, scope, or other value. Leaving the field blank is not neutral. It leaves engineering, policy, and assessment working from different rules.

Create one ODP register. For every parameter, record the requirement, value, unit, basis, risk or contract source, system scope, implementation owner, approval role, approval date, evidence source, review event, and current version.

A parameter should pass five tests:

1. Explicit. The value is stated in plain language with a unit or event.
2. Authorized. A named role approved it under a defined decision process.
3. Implemented. The system, procedure, or operating schedule uses the same value.
4. Testable. An assessor can determine whether the value was met.
5. Maintained. A trigger or review cadence keeps the decision current.

Do not scatter ODP values across policy files and tool screens without a common register. The record should point outward to implementation. It should not force an assessor to infer the governing value from conflicting artifacts.

The NIST 800-171 Rev 3 Migration Path

1. Confirm the trigger. Record the contract, clause, required revision, effective date, customer direction, affected system, and accountable owner.
2. Rebuild the crosswalk. Map every Rev 2 requirement to each active Rev 3 outcome, including moves, combinations, new requirements, ODPs, owners, and proof.
3. Set every ODP. Approve explicit values before policy, configuration, procedure, and assessment teams build from different assumptions.
4. Change controls and evidence. Update the CUI boundary, system security plan, procedures, configurations, provider responsibilities, evidence sources, and test cases.
5. Run a readiness review. Test the exact scope against the relevant assessment procedures. Preserve exceptions, decisions, retests, and approvals.

Use a change register that separates document work from implementation work. A rewritten system security plan can be complete while the configuration, provider contract, evidence period, and test result remain open.

Six Transition Failures to Stop Early

Counting instead of mapping. Ninety seven sounds smaller, so the team estimates less work. New requirements, ODPs, moves, and combinations disappear.

Leaving ODPs vague. Policy says one value, a tool uses another, and the assessor has no approved criterion.

Relabeling old evidence. The artifact name changes, but the proof does not address the revised outcome or assessment objective.

Assuming the whole network is in scope. The program becomes needlessly expensive because CUI paths and protective components were never mapped.

Outsourcing responsibility. A provider supplies a capability, but the contractor still lacks customer configuration, operating records, incident coordination, and proof.

Starting without a trigger. The team follows headlines while the actual contract revision and due date remain unresolved.

A Practical First 90 Days

Days 1 through 15: confirm applicability, assign the transition owner, collect contract direction, freeze the source list, and define the CUI boundary baseline.

Days 16 through 35: complete the requirement crosswalk, classify each change, assign family owners, identify provider dependencies, and create the ODP register.

Days 36 through 60: approve priority ODPs, update Access Control and Configuration Management first, revise the system security plan, and connect each implementation statement to evidence.

Days 61 through 75: update procedures, configurations, provider records, training, logs, test cases, and remaining family evidence.

Days 76 through 90: run a focused readiness review, record exceptions, retest fixes, resolve crosswalk gaps, and issue a signed transition decision with open work and dates.

Ninety days may not complete the transition. It should produce a controlled program with a defensible boundary, complete mapping, approved parameter decisions, sequenced implementation, and visible evidence gaps.

The Minimum Transition Evidence Packet

• Contract trigger record: clause, revision, date, scope, direction, and owner.
• Requirement crosswalk: Rev 2 source, Rev 3 destination, change type, ODP, owner, status, and evidence effect.
• ODP decision register: parameter, value, basis, scope, approver, implementation, test, and review date.
• Boundary and data flow: CUI stores, paths, users, devices, services, providers, and protective components.
• Implementation record: configuration, procedure, provider duty, owner, change date, and approval.
• Evidence crosswalk: requirement, objective, artifact, period, location, owner, and reviewer.
• Test and exception record: method, result, gap, decision, retest, and acceptance.
• Readiness decision: open work, risk, owner, due date, approval, and next review.

Research Method and Sources

The research package separates public source observations from GS analyst assumptions. It includes the official NIST change workbook, source register, public signal table, family inputs, derived scores, sensitivity analysis, data dictionary, figure data, methodology, and editable figures.

• NIST SP 800-171 Revision 3
• NIST Revision 2 to Revision 3 Change Analysis
• NIST Revision 3 FAQ
• NIST SP 1318 Small Business Primer
• DoD CMMC Program Information

GS Consulting Original Research. The GS Revision 3 Transition Work Index is a derived planning tool based on cited public sources and documented assumptions. It is not a NIST score, legal advice, contract interpretation, assessment result, security approval, or compliance determination. Verify obligations and timing against current contract terms and agency direction.

Frequently Asked Questions

Related Reading

• NIST 800-171 and CUI Security Hub
• NIST SP 800-171 Explained
• NIST SP 800-171A Assessment Guide
• NIST System Security Plan Guide
• Automating NIST 800-171 Evidence
• CMMC Compliance Hub
• Secure AI Automation