NIST SP 800-171 Rev 3 Is Final: What Changed and What It Means for Your SSP

NIST published the final version of Special Publication 800-171 Revision 3 in May 2024. The CMMC final rule — 32 CFR Part 170, effective December 16, 2024 — explicitly references Rev 3 as the applicable standard for Level 2. If your System Security Plan was written against Rev 2, it is now documenting the wrong version of the standard.

This isn't just a renumbering exercise. Rev 3 introduced substantive changes to several control families, added a new Planning family, and — most significantly — introduced organization-defined parameters across many requirements. The ODP mechanism changes how assessors evaluate your SSP, and contractors who treat it as a blank check to document whatever is convenient will be caught out under scrutiny.

I've updated SSPs through multiple NIST revision cycles under live DCSA scrutiny. Here is what actually changed in Rev 3 and where you need to focus your SSP update effort.

The Structural Changes

Rev 3 reorganized the control families. The family count went from 14 in Rev 2 to 17 in Rev 3 — the addition being the Planning (PL) family, which formalizes security planning requirements that were previously addressed more informally or inherited from other frameworks.

The total requirement count remains 110. NIST was deliberate about this: they reorganized and renumbered, but didn't expand the overall control count in a way that would fundamentally change the assessment scope. What changed was how requirements are grouped, how they're stated, and how much flexibility organizations are given — and obligated — to define.

The renumbering from Rev 2 to Rev 3 affects every requirement reference. If your SSP, POA&M, or internal compliance tracking uses Rev 2 requirement numbers (3.1.1 through 3.14.7 format), those references need to be updated. The mapping between Rev 2 and Rev 3 is available in NIST's official mapping document, but the work of updating a mature SSP is non-trivial — particularly if you have POA&M items tied to specific Rev 2 requirement identifiers.

Organization-Defined Parameters — What They Are and Why They Matter

Organization-defined parameters are the most consequential change in Rev 3 for SSP authors. ODPs appear throughout the standard where NIST has determined that the appropriate implementation varies by organization — and they require the organization to explicitly define the parameter as part of their control implementation.

An example: Requirement 3.1.2 (formerly AC-2 equivalent) in Rev 3 includes an ODP for the types of accounts that require management. Instead of a generic statement that you manage user accounts, you must define what account types exist in your environment, which require formal management processes, and how those processes work. The ODP forces you to be specific where Rev 2 allowed vagueness.

Another example: audit log retention. Rev 3's AU family includes an ODP for the organization-defined retention period for audit records. You can't just say "we retain logs." You must specify the period — and that period must be documented, enforced, and demonstrable to an assessor who asks.

ODPs are not a blank check. This is the mistake I see most often in SSPs being updated for Rev 3. Contractors read "organization-defined" and interpret it as permission to document whatever is most convenient. Assessors — both DCSA and C3PAO — read "organization-defined" as a commitment that requires substantiation. If you define an ODP value, you must implement it as defined, you must be able to demonstrate that implementation, and it must be a reasonable choice for your operational context.

If you write "the organization retains audit logs for 30 days," an assessor will look at your logging infrastructure and verify that logs are actually retained for 30 days. If you write "authorized users may perform any transactions required for their job function," an assessor will ask how you define and enforce that authorization — and "we trust our employees" is not an answer. Document ODPs with precision. Then implement what you document.

Key Changes by Control Family

AC — Access Control: Requirement 3.1.2 now includes explicit ODPs for account types and transactions. Requirement 3.1.3 (CUI flow control) has been tightened with clearer expectations around enforcement mechanisms, not just policy documentation. System use notification requirements (3.1.9) are more specific about what the notification must contain — generic "authorized users only" banners are no longer sufficient.

AU — Audit and Accountability: The Rev 3 AU family introduces ODPs for what must be audited (specific event types the organization defines), audit record retention period, and audit failure response actions. The audit review and reporting requirements are more explicit about frequency and responsible roles. If your current SSP says "we review audit logs periodically," that is not Rev 3 compliant — the frequency must be defined and it must match what you actually do.

CM — Configuration Management: Stronger baseline configuration requirements with explicit ODPs for the configuration change approval process — who approves changes, what constitutes a change requiring approval, and how emergency changes are handled differently. Software usage restrictions under CM are tightened: the expectation is a defined authorized software list, not a policy statement that users shouldn't install unauthorized software.

IR — Incident Response: Incident handling capability requirements become more specific. The ODP for incident reporting timelines matters: you must define how quickly you report incidents internally and externally, to whom, and through what mechanism. The DFARS 252.204-7012 reporting requirement (72 hours to DoD/DIBNet) already establishes an external reporting obligation; Rev 3's ODP requires you to explicitly document this obligation in your SSP and define your internal processes that feed it.

PL — Planning (new family): The Planning family formalizes security planning requirements. The core requirement is a security plan for the system — which most contractors address through their SSP itself. The distinction Rev 3 draws is that the SSP must be actively maintained, reviewed on a defined schedule (ODP), and updated when system changes occur. An SSP that was written three years ago and hasn't been touched since is not compliant with the PL family, regardless of what it says.

SA — System and Services Acquisition: Rev 3 adds substantive supply chain risk management requirements that were minimal in Rev 2. You must have processes for evaluating the security of external systems and services you acquire. This directly affects cloud services, third-party applications, and any externally provided service that is part of your CMMC-scoped environment. The SCRM requirements will catch contractors who have never seriously evaluated the security posture of their SaaS vendors and cloud providers.

What Legacy SSPs Need to Update

If your SSP was written for Rev 2, the update scope is significant. Here is the structured approach I recommend:

1. Renumber all control references to the Rev 3 numbering scheme. Use NIST's official Rev 2 to Rev 3 mapping. Update your SSP, POA&M, and any linked evidence documentation.
2. Identify all ODPs in your applicable requirements and fill them in explicitly. Don't leave any ODP blank or with placeholder language. Review each ODP against your actual implementation and document the value that reflects what you actually do — not what you aspire to do.
3. Add the Planning (PL) family requirements. If your SSP has no explicit section addressing the PL family, add one. Document your SSP review frequency, your process for updating the SSP when system changes occur, and who owns the SSP.
4. Review the AC, AU, CM, IR, and SA families for substantive changes, not just renumbering. Each of these families has requirements that changed in ways that may not be reflected in a Rev 2 SSP even after renumbering.
5. Add or update your POA&M to reflect any new gaps introduced by Rev 3 requirements that weren't present in Rev 2. The SA family additions around supply chain risk management are the most common source of new gaps in legacy SSPs.

Common Rev 3 Gaps in Legacy SSPs

Based on SSP reviews I've conducted since Rev 3 finalized, these are the gaps that appear most consistently in SSPs written for Rev 2:

ODPs left blank or with placeholder language. "Organization-defined" in the SSP text with no actual value filled in. This is an immediate finding — it means the control hasn't been implemented, it's been copied from a template.

No audit log retention period documented. The AU family ODP for retention period is frequently absent or stated as "per policy" without a reference to an actual policy that defines the period. Document the number. Verify the implementation matches it.

System use notifications not updated to Rev 3 expectations. Generic "authorized users only" banners that were marginally acceptable under Rev 2 don't satisfy Rev 3's more specific notification content requirements. Update your banner text and document the content in the SSP.

Supply chain risk management requirements missing entirely. The SA family's SCRM requirements under Rev 3 are new territory for contractors whose Rev 2 SSPs addressed SA with a few paragraphs about acquisition procedures. A Rev 3-compliant SA section requires documented processes for evaluating external service providers — not just a statement that you follow procurement procedures.

No explicit documentation of privileged access roles. Several ODPs in the AC and CM families reference organization-defined privileged roles. Rev 2 SSPs often addressed privileged access generically. Rev 3 requires the roles to be defined, documented, and enforced through your access management processes.