What is new in NIST 800-171 Rev 3 and does it apply to my contract?
NIST's change analysis classifies 19 requirements as new in Rev. 3, and that is the number to check against your contract. Before you plan any work, confirm which revision the contract names. Under the DoW Class Deviation 2026-O0025, Revision 3, contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and a 13 July 2026 DoW CIO memorandum requires baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A FAR overhaul proposed rule would move contractors handling CUI to Rev. 3, but it was not final as of October 2026. If your contract names Rev. 2, the 19 new requirements do not apply to that award yet. If it names Rev. 3 or a proposed rule is cited, they do.
Most of the new requirements are foundational rather than technical. They include the policy and procedures requirements for each family (03.15.01 among them), the planning and system security plan work in the Planning family, the component inventory requirement at 03.04.10, the information location requirement at 03.04.11, the unsupported system components requirement at 03.16.02, the external system services requirement at 03.16.03, and the supply chain risk management plan at 03.17.01. Your team owns the decision on each control and the written evidence behind it. An independent assessor decides whether each requirement is met, and it helps to ask early which parameters and assessment procedures they will apply.
Start with a gap check: map your current documents against the new requirement IDs and ask whether each has a written owner, a review date and recent records. Ask your contracting officer or prime contractor which revision and which organization-defined parameter values they expect. Because the Rev. 2 and Rev. 3 requirement sets do not line up one for one, a gap that is closed for Rev. 2 can still be open under Rev. 3. Confirm the revision in writing before you scope the work or request a quote from any implementation partner, and reread the NIST SP 800-171 Rev. 3 publication for the exact wording of each new requirement.
Which three families did Rev. 3 add, and why?
Rev. 3 adds three families and changes how foundational controls are treated, so the same baseline now lines up with the SP 800-53B moderate baseline. The cards below cover the new families, the renamed assessment family, and the two structural changes that make Rev. 3 read differently from Rev. 2.
Planning family (03.15)
The Planning family holds the policies and procedures behind the other families, the system security plan and rules of behavior for system users. Rev. 2 had no matching requirement, because the policy and procedures controls were treated as expected practice. Under Rev. 3, you need written, reviewed policies for each family and an SSP that a reviewer can test. Check that every family has a named owner and a review date.
System and services acquisition (03.16)
This family covers security engineering principles, replacing unsupported components, and security requirements for external service providers. It matches the SP 800-53B moderate baseline, which is why NIST added it. For a Rev. 2 program, the work is mostly contract and inventory review: which components have vendor support, and which external providers touch systems that store or process CUI. Ask engineering to list end-of-support dates for each component.
Supply chain risk management (03.17)
The supply chain risk management plan requirement asks for a documented plan covering research and development, design, manufacturing, acquisition, delivery, integration, operations, maintenance and disposal of systems, components and services. The plan must be reviewed on a defined schedule and protected from unauthorized disclosure. Many organizations hold this plan with procurement rather than IT, so confirm who owns it before assessment.
Security assessment and monitoring
Rev. 2's Security Assessment family is now called Security Assessment and Monitoring. The rename signals that periodic assessment alone is no longer enough, and continuous monitoring is part of the family's scope. Teams that treated assessment as a yearly exercise should plan recurring checks and a record of how findings were tracked to closure. Confirm your plan of action and milestones process covers monitoring results, not only assessment findings.
Basic and derived requirements merged
Rev. 2 separated basic requirements from derived requirements. Rev. 3 drops that split, so every requirement is stated the same way and assessed on its own terms. Mapping old Rev. 2 controls to new Rev. 3 requirements therefore requires checking each requirement's full text, not its label. Expect some Rev. 2 items to appear under different wording, and some to split or combine.
No more NFO tailoring
Rev. 2 had a category for controls expected to be implemented without being specified (NFO). Rev. 3 removes that category and turns foundational controls, such as policy and procedures, into explicit requirements. Rev. 3 also adds an ORC category for controls covered by other related controls. Organizations that relied on unwritten practice must now document it, because an assessor will test for the written artifact.
Why NIST added these requirements and what the 19 mean for an assessment
The 19 new requirements did not appear at random. They come from two sources. Requirement 03.04.11 (Information Location) traces to an SP 800-53 control that was newly added to the SP 800-53B moderate baseline, so NIST had no Rev. 2 requirement to carry forward. Requirements 03.15.01 (Policy and Procedures) and 03.16.03 (External System Services) trace to controls that Rev. 2 had tailored out as NFO, meaning nonfederal organizations were expected to implement them without NIST specifying how. Rev. 3 removed that category and turned those foundational expectations into testable requirements. The same logic explains 03.04.10 (System Component Inventory), 03.16.02 (Unsupported System Components) and 03.17.01 (Supply Chain Risk Management Plan). For an assessor, the practical change is that a policy, a procedure or an inventory no longer passes on the strength of being implicit. Each has determination statements in SP 800-171A Rev. 3 that an assessor will examine and interview against.
Because CMMC Level 2 assesses the 110 Rev. 2 requirements, none of these 19 has a matching requirement ID in that assessment. That does not make them optional for a contract that cites Rev. 3. Before planning work, confirm which revision your contract, DFARS clause or prime contractor specifies, since the current DoD position described in the sibling sections may differ from a future FAR rule. If you are preparing for Rev. 3, start by checking whether you already have a written policy and procedure for each of the 17 families, a current component inventory, and a documented view of unsupported components and external service providers.
Rev. 3 also introduced organization-defined parameters (ODPs), which several of these requirements depend on. Where NIST leaves a value open, the nonfederal organization may have to set it to complete the requirement. Examples include how often a supply chain risk management plan is reviewed or how often an inventory is updated. Confirm with the federal agency or prime contractor whether it has published ODP values, because an assessor will look for a defined value, not just a stated practice. Any decision you make on a value should be written down, approved by a named owner, and kept with the policy it sets, since the values become part of your evidence.
What the new requirements change for the executive, the compliance lead and the engineer
The executive question is which revision your contract names, because that decides which requirements you will be assessed against and how much new work lands on the organization. Rev. 3 keeps 97 requirements, but its 19 new requirements have no Rev. 2 counterpart, so a program built only to Rev. 2 will not cover them. Current DoD direction and the proposed civilian direction point in different places, so the answer can change during the life of a contract.
- Rev. 2 contract: The September 2026 DFARS class deviation has contracting officers name SP 800-171 Revision 2 explicitly, and DoD's July 2026 CIO memorandum requires baseline compliance with Rev. 2 while CMMC Phase 2 is suspended.
- Rev. 3 contract: A proposed FAR rule would require contractors handling CUI to comply with Rev. 3 using organization-defined parameter values published by the DoW CIO. It was not final as of October 2026.
- Deadline exposure: Timing depends on the revision and on when the rule is finalized, so ask the contracting officer for the date that applies to your contract in writing.
- Budget: The new requirements add policy, inventory and supplier work. Ask any implementation partner for a quote that separates Rev. 2 baseline work from Rev. 3 additions.
Confirm the revision and clause date in the solicitation and in any modification before approving spend, because the cost of each path depends on it.
The compliance lead inherits most of the new documentation. Several Rev. 3 requirements ask for a written artifact that Rev. 2 did not name as a requirement, and assessors test those artifacts in the same way as technical controls. SP 800-171A Rev. 3 gives each requirement determination statements that an assessor checks through the examine and interview methods, and it adds a test method for 93 of the 97 requirements. Organization-defined parameters add a further check that each parameter value is defined.
- Policy and procedures (03.15.01): A new requirement that turns the policy and procedures behind the other families into something you must have, approve and keep current.
- Component inventory (03.04.10): A maintained record of system components that the assessor can compare against the boundary and the system security plan.
- Information location (03.04.11): A record of where CUI is stored, processed and transmitted, which the assessor uses to test the scope you claim.
- Supply chain risk management plan (03.17.01): A plan covering research and development through disposal, reviewed at a defined frequency and protected from unauthorized disclosure.
Before assessment, have each new document dated, approved by a named owner, and linked to the determination statements it supports. Check the Rev. 3 requirement text against your own parameter values, because a missing value fails the check even when the control works.
The engineer's share of the new requirements is mostly about producing accurate, current data about the system. Inventory, location and component lifecycle records are only as good as the tooling and processes that generate them, and assessors will ask how the records were produced and when they were last checked. The work also reaches external services and suppliers, which is where many environments hold gaps that were never documented.
- Inventory tooling (03.04.10): Use discovery and configuration data from the actual boundary to build the component inventory, and reconcile it against cloud accounts, virtual machines, network devices and endpoints.
- Unsupported components (03.16.02): Track end-of-support dates for every component, replace those that lose developer, vendor or manufacturer support, and document risk mitigation or alternative support for any that cannot be replaced.
- External system services (03.16.03): Review each external service that touches the boundary, including managed services and hosting providers, and record the security terms that apply to it.
- Information location (03.04.11): Tag data stores and flows that hold CUI so the location record matches the running environment.
Before assessment, run the inventory against the live environment and confirm the list of unsupported components and external services matches what the compliance lead has documented.
How to map the 19 new requirements into an existing Rev. 2 program
This sequence takes an organization that already runs a Rev. 2 program and extends it to cover the requirements that exist only in Rev. 3, ending with an updated system security plan that reflects the full set. Each step produces a record that the next step depends on.
Download and read the NIST change analysis
Start with NIST's Rev. 2 to Rev. 3 change analysis spreadsheet alongside the Rev. 3 publication. Your compliance lead or security architect should filter for the 33 withdrawn Rev. 2 requirements and the 19 new Rev. 3 requirements, then note which Rev. 2 requirements carry over with significant changes. The output is a working mapping sheet with one row per Rev. 3 ID, marked as carried over, new, or withdrawn. You know this step is done when every Rev. 3 requirement has a row and an owner for the review.
Confirm which revision the contract cites
Before you change any controls, check the contract, the DFARS clause version, and any contracting officer direction to see which SP 800-171 revision applies. Current DoD direction names Revision 2 for contract purposes, while a proposed FAR rule would move civilian contractors to Revision 3. Record the revision, the clause date, and the source document in the program file. The output is a written scope statement that names the governing revision, so the team knows whether the Rev. 3 gap work is a current obligation or a planned transition.
Map existing evidence to Rev. 3 identifiers
Take the evidence you already hold for each Rev. 2 requirement and link it to its Rev. 3 counterpart using the change analysis. Carried-over requirements usually keep their evidence with updated wording, while the 19 new requirements have no Rev. 2 match and need fresh evidence. Your compliance lead should run this with the control owners, who confirm that each artifact still reflects how the system operates. The output is an evidence index keyed to Rev. 3 IDs, with a gap list naming every new requirement that has no artifact yet.
Draft the missing policies and plans
Several new requirements turn foundational expectations into named obligations, including the policy and procedures requirement in 03.15.01 and the supply chain risk management plan in 03.17.01. Write these documents for your environment, with the review frequency and protection rules that the requirement text and its assessment procedure call for. Approval should come from an accountable executive, and the approval date should be recorded. The output is a set of approved, versioned documents, each tied to its Rev. 3 identifier in the evidence index.
Build the inventory and information location records
Requirements 03.04.10 and 03.04.11 ask you to maintain a system component inventory and to know where CUI resides within your systems. Engineering and IT operations should export asset data from configuration management and cloud tooling, then reconcile it against the system boundary and the CUI data flows. Each CUI location should be recorded with its system, storage type, and owner. The output is a current inventory and a CUI location register, and the check is that a reviewer can trace any CUI store back to an inventory entry.
Review external services and unsupported components
Requirement 03.16.03 covers external system services, and 03.16.02 covers unsupported system components. Procurement and system owners should list every external provider that touches CUI systems, confirm the security terms in each agreement, and identify any component whose developer, vendor, or manufacturer no longer provides support. For unsupported items, record either a replacement plan or a documented risk mitigation with an alternative source of support. The output is a provider register and an unsupported-component decision log, both reviewed by the security lead before the next step.
Update the system security plan
Revise the system security plan so it reflects the Rev. 3 identifiers, the new policies, the inventory and CUI location records, the external service decisions, and the supply chain plan. Confirm the organization-defined parameter values you have assigned, and state them in the plan, because Rev. 3 requires them to complete several requirements. Have the system owner and the accountable executive sign the revised plan. The output is a dated, signed SSP that cross-references each new requirement to its evidence, and the check is that every entry in the gap list from the mapping step now points to an artifact.
Where each new requirement sits and what Rev. 2 or CMMC Level 2 has instead
This table lists six of the 19 requirements that Rev. 3 adds, with the family each one sits in and whether CMMC Level 2 has a matching requirement ID. CMMC Level 2 assesses the 110 Rev. 2 requirements, and NIST maps no Rev. 2 requirement to any of these six, so an organization assessed under CMMC must build each one from its own documentation. The other 13 new requirements are not listed here, so check them against NIST's change analysis before planning the transition.
| Requirement ID | Short name | Rev. 3 family | CMMC Level 2 matching ID |
|---|---|---|---|
| 03.04.10 | System component inventory | 03.04 Configuration management | None (no Rev. 2 requirement mapped) |
| 03.04.11 | Information location | 03.04 Configuration management | None (no Rev. 2 requirement mapped) |
| 03.15.01 | Policy and procedures | 03.15 Planning | None (no Rev. 2 requirement mapped) |
| 03.16.02 | Unsupported system components | 03.16 System and services acquisition | None (no Rev. 2 requirement mapped) |
| 03.16.03 | External system services | 03.16 System and services acquisition | None (no Rev. 2 requirement mapped) |
| 03.17.01 | Supply chain risk management plan | 03.17 Supply chain risk management | None (no Rev. 2 requirement mapped) |
Common questions about the new NIST 800-171 Rev 3 requirements
Does CMMC Level 2 assess the new Rev 3 requirements?
No. CMMC Level 2 assesses the 110 Rev. 2 requirements, and 32 CFR 170.14(c)(3) makes its requirements identical to Rev. 2. The 19 new Rev. 3 requirements, including 03.04.10, 03.04.11, 03.15.01, 03.16.02, 03.16.03 and 03.17.01, have no matching requirement ID in CMMC Level 2. That does not mean they can be ignored. Your contract's named revision determines what you must meet, and the organization owns its controls and their evidence whichever revision applies. Confirm the current CMMC scope in the eCFR text of 32 CFR Part 170 and with your contracting officer.
Which NIST 800-171 revision do DoD contracts name as of October 2026?
As of October 2026, DoW Class Deviation 2026-O0025, Revision 3, has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly. The deviation cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. Separately, a proposed FAR overhaul rule published 23 June 2026 would require contractors handling CUI to comply with Rev. 3 using ODP values published by the DoW CIO, but it was not final as of October 2026. Read the contract clause itself, because it controls which revision applies to your work. Review the DoW class deviation memo for the exact wording.
Can we skip the new Rev 3 requirements if our contract cites Rev 2?
Not as a planning assumption. If your contract cites Rev. 2, the 110 Rev. 2 requirements define what you must meet today, and the new Rev. 3 requirements do not change that obligation. However, the proposed FAR rule would move contractors to Rev. 3, and the revision named in a future contract may differ from the one in your current agreement. Many of the Rev. 3 additions cover planning, acquisition and supply chain work that takes time to build, so an organization that starts later faces a harder transition. Ask your contracting officer which revision applies to each contract, and use NIST's change analysis to map the gaps before a revision change is announced.
Who sets ODP values when an agency does not specify them?
The nonfederal organization must assign them. NIST does not assign organization-defined parameter values, and if a federal agency does not specify them, the organization must set them to complete the requirement. NIST's OSCAL catalog defines 88 ODPs across 50 of the 97 requirements, so this affects a large share of the work. The proposed FAR rule would instead have the DoW CIO publish the values, which would reduce that burden if it is finalized. Until then, document each value you choose, the reason for it and the approval it received, because an assessor will check that every parameter is defined. Confirm with your contracting officer whether published values apply to your contract.
How much work do the new policies need, and what must the organization provide?
The effort depends on how many policies and procedures already exist and how well they match the requirements. Requirement 03.15.01 turns the policy and procedures controls, which Rev. 2 treated as expected but unspecified, into explicit requirements. The organization must provide written policies and procedures for each family in scope, evidence that they were reviewed and approved, and proof that staff know them. Requirement 03.17.01 adds a supply chain risk management plan covering development through disposal, which is a new document for many organizations. Cost drivers include the number of systems in scope, the state of existing documentation, and whether staff or an outside implementation partner write the material. Ask any partner to list each document and its owner in a written scope before work starts.
Who issues the assessment result for these requirements?
Only an independent assessor or the government assessing body issues the result. An assessment result is not produced by the organization or by its implementation partner. Under the DoD framework, assessments may be run by the Government through DCMA DIBCAC or by a CMMC third-party assessor, depending on the program rules in force. The organization owns its controls and is responsible for showing that they operate. An implementation partner can prepare systems, the system security plan and evidence, but cannot sign or issue the assessment outcome. Confirm which assessing body your contract requires before you engage anyone, and check the CMMC rule in 32 CFR Part 170 for the assessment roles it defines.
Where an implementation partner helps and where an assessor decides
The organization owns its policies, plans and controls. The three requirements that are new in Rev. 3 for policy and procedures (03.15.01), the system component inventory (03.04.10) and information location (03.04.11) all need written decisions that only the organization can make: who approves the policies, which components count as in scope, and where CUI actually lives. An implementation partner such as DeployOpen can prepare the working material behind those decisions, including a draft of the policy set, a component inventory built from discovery data in the organization's own environment, and a map of the repositories, backups and endpoints where CUI is stored. Final approval and sign-off stay with the organization's leadership.
The partner's role also covers the newer acquisition and supply chain requirements. For 03.16.02 (unsupported system components) and 03.17.01 (supply chain risk management plan), a partner can build a list of end-of-support software and hardware, document replacement or risk-mitigation options, and draft the supply chain plan for the organization to review and adopt. For 03.16.03 (external system services), it can help collect the security terms in each cloud and service contract. Confirm with the assessor, before work starts, which artifacts they will expect and in what form.
Only an independent assessor or the Government's assessment process issues a result. Under the DoD's assessment process, a CMMC third-party assessor or a DCMA DIBCAC assessment decides whether a requirement is met, and the contracting agency is responsible for compliance under NIST's FAQ. A partner cannot score the organization's own work or post a score on its behalf. Agree the scope of readiness work in writing before it starts, covering the systems and sites included, the artifacts to be produced, who reviews them, and what happens to open findings. Ask for the same written scope from any other consultant you consider.
How DeployOpen prepares Rev. 3 systems and evidence
DeployOpen works on the new Rev. 3 requirements as part of a fixed-scope engagement inside your own infrastructure. We prepare the systems, policies and evidence that the new requirements call for, and an independent assessor makes the judgment on whether they are met.
How we scope
- We agree in writing which of the 19 new requirements apply to your CUI systems, including 03.04.10, 03.04.11, 03.15.01, 03.16.02, 03.16.03 and 03.17.01.
- We confirm which systems, cloud accounts and data centers hold or protect CUI, so the new requirements are scoped to the right boundary.
- We record which organization-defined parameter values your contracting agency has specified and flag any values you must assign yourself.
How we build
- We configure the open-source platforms in your environment to produce component inventory and unsupported-component records the new requirements expect.
- We draft the policy and procedures documents behind the Planning and Supply Chain Risk Management requirements for your review and approval.
- We build the information location mapping that shows where CUI is stored, processed and transmitted across your systems.
How we hand over
- We deliver the written scope, configuration records, policy drafts and evidence artifacts in a form your assessor can examine and interview against.
- We map each new requirement to the SP 800-171A assessment procedure and the artifacts that support it, so gaps are visible before the assessment.
- We transfer administration of the systems and documentation to your team, with a record of what was changed and why.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so evidence stays current as platforms and suppliers change.
- We can review updates to the supply chain risk management plan and inventories at the frequency your own plan defines.
- Any change to contract requirements, such as a move from Rev. 2 to Rev. 3, can be scoped as a new fixed-scope piece of work.
