NIST 800-171 Rev. 3: What Changed and How to Comply

Why NIST 800-171 Rev. 3 Matters

NIST Special Publication 800-171 establishes the security requirements for protecting Controlled Unclassified Information (CUI) in non-federal systems. It is the foundation underlying CMMC certification, DFARS 252.204-7012 compliance, and a growing list of state and agency-specific contracting requirements. When NIST revises 800-171, the downstream impact reaches every defense contractor, federal subcontractor, and many commercial organizations that handle CUI under federal flow-down clauses.

Rev. 3 was published in final form in May 2024. The revision was substantive: not a renumbering exercise but a structural rebalancing of the security requirements, the addition of new requirements aligned with current threat realities, and the introduction of a tailored requirements model that lets organizations adjust protection levels for specific data categories. CMMC Level 2 assessments transition to Rev. 3 over an announced schedule, and contractors with active 800-171 obligations need to plan the migration carefully.

This guide walks through what changed between Rev. 2 and Rev. 3, what the new tailored requirements model means in practice, and how to operationalize Rev. 3 compliance through continuous monitoring.

Structural Changes from Rev. 2 to Rev. 3

NIST 800-171 Rev. 2 had 110 security requirements organized in 14 families. Rev. 3 retains the 14-family structure but reorganized the requirements, consolidating some and adding others. The headline numbers:

Rev. 2: 110 requirements

Rev. 3: 108 requirements (after consolidation) plus an Organization-Defined Parameters (ODP) framework that lets contractors specify implementation-specific details

The reduction is not a relaxation. Several requirements that were separate in Rev. 2 were consolidated into more comprehensive single requirements in Rev. 3, while new requirements were added in domains where threat intelligence drove updates.

The 14 Families Are Preserved

Family Code Rev. 2 count Rev. 3 count

Access Control AC 22 20

Awareness and Training AT 3 3

Audit and Accountability AU 9 8

Configuration Management CM 9 10

Identification and Authentication IA 11 9

Incident Response IR 3 6

Maintenance MA 6 6

Media Protection MP 9 8

Personnel Security PS 2 2

Physical Protection PE 6 6

Risk Assessment RA 3 8

Security Assessment CA 4 4

System and Communications Protection SC 16 14

System and Information Integrity SI 7 8

The families with notable expansion: Incident Response (3 → 6) and Risk Assessment (3 → 8). The added IR requirements address incident handling sophistication, integration with broader response capability, and reporting. The added RA requirements bring threat hunting, vulnerability response, and risk monitoring discipline that was implicit in Rev. 2 but is now explicit.

What's New: Notable Rev. 3 Requirements

Several requirements appear for the first time in Rev. 3:

RA-05 Vulnerability Monitoring and Scanning elevates vulnerability management from an implicit expectation to a defined practice. Contractors must monitor for vulnerabilities, scan on a defined cadence, and remediate within defined timelines.

RA-07 Risk Response requires documented response actions for identified risks, with risk acceptance, mitigation, or transfer decisions captured formally.

SI-05 Security Alerts, Advisories, and Directives requires that contractors monitor external sources of vulnerability and threat intelligence and act on them in a defined way.

IR-04 Incident Handling is expanded from a single requirement in Rev. 2 to a more comprehensive incident management capability covering preparation, detection, analysis, containment, and recovery.

CM-08 System Component Inventory appears more explicitly: contractors must maintain an accurate, current inventory of system components, with the inventory available for assessment.

SC-08 Transmission Confidentiality and Integrity is restructured to explicitly address both confidentiality and integrity protection during transmission, not just one or the other.

The Organization-Defined Parameters (ODP) Framework

The most consequential conceptual change in Rev. 3 is the introduction of Organization-Defined Parameters. Many requirements in Rev. 3 are written with placeholders where contractors specify implementation parameters appropriate to their environment and risk posture.

For example, a requirement might state: "The organization establishes the frequency of [organization-defined frequency] for security control assessments." The contractor specifies the frequency (monthly, quarterly, annually) based on their risk assessment and documents the rationale.

The ODP model has two implications:

Implementation flexibility. Contractors can tailor implementations to environment realities, rather than being forced into a single prescribed cadence or threshold that may not fit their risk profile.

Documentation discipline. Every ODP value must be documented in the System Security Plan (SSP), with the rationale for the chosen value. Assessors will evaluate whether the chosen value is defensible given the contractor's risk environment.

For a complex environment, the SSP gains significant length under the ODP model. For a smaller environment, the discipline of documenting each parameter formally is a meaningful operational lift.

Tailored Requirements for Specific Data Categories

Rev. 3 introduces an additional capability: contractors can request to tailor specific requirements based on the protection needs of the specific CUI category they handle. The tailoring framework is structured: tailoring decisions must be documented, justified, and accepted by the requiring agency.

This is meaningful for contractors handling CUI categories where some Rev. 3 requirements are demonstrably not relevant. A contractor handling only Controlled Technical Information for a specific weapons system may not face the same data exfiltration risk as a contractor handling broad personnel information across the DIB. Rev. 3 acknowledges that distinction in a structured way.

In practice, most contractors will not pursue tailoring on most requirements. The default Rev. 3 baseline applies broadly. Tailoring is the exception, requiring deliberate justification.

The CMMC Transition to Rev. 3

CMMC Level 2 assessments are tied to NIST 800-171. As Rev. 3 was finalized in May 2024, the CMMC ecosystem began the transition. The transition is phased:

New assessments continue on Rev. 2 during a defined transition period

Re-assessments and new contracts transition to Rev. 3 as the program guidance specifies

Contractors that completed Level 2 against Rev. 2 do not lose certification but face Rev. 3 at their next triennial assessment

The contractor implication: a new CMMC Level 2 program should plan against Rev. 3, not Rev. 2. A contractor currently certified against Rev. 2 should plan the Rev. 3 gap assessment well before the next assessment cycle.

Mapping Rev. 2 to Rev. 3 in Practice

For contractors with an existing Rev. 2 program, the migration is a structured mapping exercise:

1. Identify renamed or renumbered requirements. Some Rev. 2 requirements are present in Rev. 3 with different identifiers. The mapping is published by NIST and the Cyber AB.

2. Identify consolidated requirements. Where Rev. 2 had separate requirements that Rev. 3 consolidated, the implementation must satisfy the consolidated requirement, not just the prior components.

3. Identify new requirements. Plan implementation for requirements that did not exist in Rev. 2 (vulnerability monitoring, risk response, security alerts, expanded incident handling).

4. Identify ODP values. Specify the contractor's chosen value for every ODP and document the rationale in the SSP.

5. Update the System Security Plan. The SSP is the central artifact; it must reflect Rev. 3 requirement identifiers, ODP values, and implementation descriptions.

6. Update the POA&M. Open findings transition with their resolution plans intact, but the requirement they map to may have changed.

7. Re-validate evidence pipelines. Some evidence sources adequate for Rev. 2 may need expansion to satisfy Rev. 3 (e.g., expanded incident handling evidence).

Allow 60-120 days for a full Rev. 2-to-Rev. 3 migration in a mid-sized contractor environment. Larger environments take proportionally longer.

Common Rev. 3 Compliance Gaps

Early experience with Rev. 3 readiness assessments surfaces recurring gaps:

Vulnerability management depth. Rev. 3 requirements around vulnerability monitoring and scanning are more rigorous than the implicit expectation in Rev. 2. Many contractors run scans but lack the closed-loop process Rev. 3 demands.

Incident response sophistication. The expanded IR family requires more than a written plan; it requires demonstrated capability through tabletop exercises and real-incident response.

Risk response documentation. Contractors typically assess risk informally. Rev. 3's RA-07 demands documented response decisions with risk acceptance authority defined.

Asset inventory accuracy. Many contractors maintain inventories that are demonstrably incomplete. Rev. 3 expects a current, accurate inventory with assessment-ready availability.

Configuration baseline enforcement. Baselines may be defined but not enforced. Rev. 3 expects active enforcement and drift detection, not just documented baselines.

Audit log retention and review. Logs are generated but retention and review practices are inconsistent with Rev. 3 expectations.

The common thread: Rev. 3 closes interpretation gaps that Rev. 2 left open. Where Rev. 2 left room for "we have a policy," Rev. 3 expects evidence the policy operates.

How Continuous Compliance Supports Rev. 3

The Rev. 3 expectations around vulnerability monitoring, configuration management, incident handling, and risk monitoring all align with continuous compliance operating models. The discrete checkpoint model of annual self-attestation against Rev. 2 is incompatible with Rev. 3's evidence expectations.

What continuous compliance produces for Rev. 3:

Configuration baseline evidence: per-host, per-day pass/fail against CIS benchmarks mapped to CM and SC family requirements

Drift evidence: every regression timestamped, mapped to the requirement it violated

Vulnerability evidence: scan results with remediation tracking aligned to RA-05 expectations

Audit log evidence: per-host audit policy configuration aligned to AU family requirements

Asset inventory evidence: real-time inventory of in-scope systems aligned to CM-08

Exception evidence: documented waivers with approval and expiry, aligned to risk response expectations

The contractor presenting continuous compliance evidence at Rev. 3 assessment time spends the assessment confirming the evidence rather than constructing it.

How CISGuard Supports NIST 800-171 Rev. 3

CISGuard's NIST 800-171 mapping covers Rev. 3 directly:

22 CIS benchmarks mapped to the relevant Rev. 3 requirements with per-requirement evaluation status

Per-host scan history with timestamped baseline comparisons, satisfying CM, SI, and AU family evidence expectations

Drift detection and alerting aligned to Rev. 3's continuous monitoring expectations

Asset inventory with classification to support CM-08 and CUI boundary management

POA&M-formatted reporting with status, owner, target date per finding

ODP-aware reporting: parameters such as scan frequency, remediation SLA, and review cadence are configurable per environment and reflected in evidence reports

Air-gapped and AWS GovCloud / Azure Government deployment for CUI environments

See NIST 800-171 mapping in CISGuard or request a Rev. 3 gap assessment.