NIST published Revision 3 of SP 800-171 in May 2024. It is a substantial rewrite: different numbering, different families, fewer requirements, and a new mechanism for organization-defined values. Revision 2, from February 2020, has not gone away, because contracts and the CMMC program still point to it.
That leaves contractors with an awkward question: which one do you build to? This article sets out what changed, which revision your obligations most likely reference, and how to prepare for Rev. 3 without redoing work you need for Rev. 2 today. The governing answer for any particular company is in its contract, so read this alongside yours.
Which revision applies to you
The revision you must meet is the one your contract requires. A standard does not take effect on its own.
For DoD contractors, two facts matter. DFARS 252.204-7012 refers to the version of 800-171 in effect at the time of the solicitation, which would have meant Rev. 3 for new solicitations. DoD issued a class deviation so that contractors continue to implement Rev. 2 under that clause for now. Separately, the CMMC program rule in 32 CFR Part 170 incorporates Rev. 2 by reference for Level 2.
So for most DoD work, Rev. 2 is the requirement and Rev. 3 is the direction of travel. When DoD will move its requirements to Rev. 3 is not something to assume. Other agencies may reference 800-171 differently in their own contracts. Check your contract clauses and current DoD or agency guidance, and ask your contracting officer when the text is unclear.
What changed structurally
| Rev. 2 | Rev. 3 | |
|---|---|---|
| Published | February 2020 | May 2024 |
| Requirements | 110 | 97 |
| Families | 14 | 17 |
| Numbering | 3.1.1 | 03.01.01 |
| Requirement types | Basic and derived | One type |
| Organization-defined parameters | None | Used throughout |
| Assessment procedures | NIST SP 800-171A | NIST SP 800-171A Rev. 3 |
| Source | 800-53 Rev. 4 | 800-53 Rev. 5 |
Rev. 3 adds three families: Planning, System and Services Acquisition, and Supply Chain Risk Management. Rev. 2's Security Assessment family becomes Security Assessment and Monitoring.
The numbering change looks cosmetic but has practical effects. Every crosswalk, system security plan heading, and plan of action reference keyed to "3.5.3" needs a new key. Do not renumber your documents until you are actually implementing Rev. 3, or you will maintain two sets of references for no benefit.
Fewer requirements, not less work
The drop from 110 to 97 does not mean Rev. 3 asks for less. Many Rev. 2 requirements were consolidated into broader Rev. 3 requirements, and some were withdrawn with their content moved elsewhere. At the same time, Rev. 3 makes explicit several things Rev. 2 assumed.
Rev. 2 was tailored from the 800-53 Moderate baseline using a set of criteria. One criterion removed controls that a nonfederal organization would be expected to have anyway, such as security policies and procedures. Rev. 2 listed these in an appendix and did not state them as requirements. Rev. 3 refined the tailoring criteria, and some of that expected-anyway material now appears as explicit requirements, for example in the new Planning family.
The new families bring their own work:
Planning brings policy and procedures, the system security plan, and rules of behavior into explicit requirements.
System and Services Acquisition covers topics such as security engineering principles, unsupported system components, and external system services.
Supply Chain Risk Management asks for a supply chain risk management plan and related acquisition practices.
If you have operated a mature program under Rev. 2, much of this exists in some form. The work is in confirming it meets the specific Rev. 3 wording.
Organization-defined parameters
The most significant change for day-to-day implementation is the introduction of organization-defined parameters, borrowed from 800-53. Where Rev. 2 said "periodically," Rev. 3 often asks for a defined frequency. Where Rev. 2 left a time period open, Rev. 3 names it as a parameter to be assigned.
Rev. 3 allows the federal agency to specify parameter values. Who sets them for your contract, and what values apply, is a question for current DoD or agency guidance. Where no value is assigned, you will need to choose one and document it.
Parameters make assessment more precise, because there is a value to test against. They also make inconsistency more visible. If your policy says one frequency, your system security plan another, and your practice a third, an assessor working from Rev. 3 procedures will find it. Our article on tailoring 800-53 controls covers how to set parameter values you can defend, and the same principles apply here.
Assessment changes
NIST SP 800-171A Rev. 3 accompanies the new revision. It keeps the examine, interview, and test methods and expresses each requirement as determination statements an assessor checks. Rev. 3's organization-defined parameters appear in those statements, so the assessment checks your assigned values directly.
For CMMC, Level 2 assessments follow the Rev. 2 requirements and the CMMC assessment guidance that DoD publishes. If your contract calls for CMMC Level 2, prepare against that, not against Rev. 3 procedures.
What does not change
Much of the program you build for Rev. 2 carries straight across. It helps to be clear about what stays the same, so effort goes where the differences are.
What CUI is. The definition comes from the federal CUI program and your contract, not from 800-171. A revision does not change what you must protect.
The scoping rule. Requirements still apply to components that process, store, or transmit CUI, and to the components that protect them.
The contract obligations around it. Incident reporting, image preservation, and flow-down under DFARS 252.204-7012 are set by the clause, not by the revision of the standard.
The core security outcomes. Multi-factor authentication, audit logging, boundary protection, media protection, and validated cryptography remain. Wording and grouping change; the controls you operate mostly do not.
The documents. You still need a system security plan and plans of action. Their content grows, but their purpose is the same.
How to prepare without wasted work
A sensible sequence for a DoD contractor today:
Meet Rev. 2 fully. It is the requirement in your contract and in CMMC Level 2. Do not divert effort from open Rev. 2 gaps into Rev. 3 preparation.
Build a crosswalk. Map each Rev. 2 requirement to its Rev. 3 counterpart, noting where requirements merged, split, or were withdrawn. NIST published supporting material on the changes that helps here.
Identify the net-new work. Mostly the new families and the parameter values. Estimate it, and put it on your roadmap rather than your plan of action, since it is not a current deficiency.
Choose parameter values early. Where Rev. 3 introduces a parameter, see whether your current practice already implies a value. Write it down.
Write new controls to both. When you implement something new, such as a supply chain risk management plan, write it so it satisfies Rev. 3 wording while meeting Rev. 2.
Revisit scope. Rev. 3 does not change the basic scoping rule, but a transition is a good moment to check that your CUI boundary still holds.
Our NIST 800-171 framework page has the family structure for both revisions, and our article on protecting CUI in practice covers the Rev. 2 requirements that take the most work.
How TrustLynce helps
TrustLynce maps controls across frameworks, so a control implemented once can be traced to its Rev. 2 requirement and its Rev. 3 counterpart, with evidence shared between them. See control mapping.