When NIST released Revision 3 of Special Publication 800-171 in May 2024, much of the discussion focused on changes to security requirements, new requirement families, and the introduction of organization-defined parameters (ODPs).
Those changes are important. However, comparing security requirements alone does not necessarily reveal how organizations will need to adjust their security programs or prepare for assessments.
To better understand the differences, we need to examine the assessment objectives themselves. A comparative analysis of NIST SP 800-171 and its companion assessment publication, SP 800-171A, reveals a considerable increase in the number and specificity of assessment determination statements.
The findings also highlight an important distinction: An additional assessment objective does not necessarily represent an entirely new security requirement, but it may introduce an expectation that organizations must now demonstrate more explicitly.
For defense contractors, that distinction becomes particularly important when considering the organization-defined parameters already established by the Department of Defense (DoD).
The numbers tell an interesting story
Our comparison identified the following assessment determination statements:
Revision 3 contains approximately 59% more assessment determination statements than its predecessor.
That is a substantial increase. However, it would be misleading to conclude that organizations must implement 190 entirely new security capabilities.
Some Revision 3 objectives address safeguards already present in Revision 2. Others provide additional specificity, separate previously combined expectations into individually assessable activities, or establish new requirements.
Revision 3 also introduces 88 explicit ODP determination statements. The number of determination statements is not equivalent to the number of security requirements, nor does it directly measure the effort required to achieve compliance.
The more useful question is not simply how many assessment objectives were added, but what those objectives require organizations to demonstrate.
Four ways to understand the changes
For our comparison, we developed four categories describing how Revision 3 assessment objectives relate to Revision 2.
Our preliminary analytical crosswalk produced the following classifications:
These are analytical classifications, not NIST-published determinations. Although the crosswalk inventories all determination statements, some semantic and cross-family classifications remain subject to technical review. In particular, an objective categorized as New may still relate to a broader security concept that existed in Revision 2.
The comparison nevertheless illustrates how extensively the structure and specificity of the assessment procedures have changed.
Let’s examine a few examples.
Matching objectives: Not everything needs to change
Consider wireless access protection.
Revision 2 assessment objective 3.1.17[a] requires organizations to demonstrate that wireless access is protected using authentication.
Revision 3 contains the same assessment statement under A.03.01.16.d[01].
The wording remains identical, although the objective now resides within a reorganized requirement.
For organizations already satisfying the Revision 2 objective, their existing technical implementation may continue to satisfy the corresponding Revision 3 expectation.
Organizations should still verify that system configurations and evidence remain appropriate, but a change in requirement identifier does not inherently justify redesigning an existing safeguard.
This is an important consideration for organizations maintaining security policies, procedures, System Security Plans (SSPs), and supporting evidence repositories.
Similar objectives: Different words, familiar expectations
Some assessment objectives communicate substantially the same expectation using different language.
Revision 2 assessment objective 3.1.7[d] addresses capturing the execution of privileged functions in audit logs. Revision 3 objective A.03.01.07.b states that the execution of privileged functions is logged.
The wording differs, but the essential expectation remains: organizations must demonstrate that privileged-function execution is traceable in logs. A mature Revision 2 implementation may already provide the necessary technical capability and supporting evidence. However, equivalent wording does not automatically mean that every related assessment expectation remains unchanged.
Organizations must consider the complete security requirement and its associated assessment objectives rather than evaluating an individual statement in isolation.
Expanded objectives: Where additional work may be necessary
One of the most significant findings is the increased specificity throughout Revision 3.
A particularly useful example involves the System Security Plan.
Under Revision 2, requirement 3.12.4 establishes expectations for developing and maintaining an SSP describing the system boundary, operating environment, security requirement implementations, and relationships with other systems.
Revision 3 relocates the SSP requirement to 03.15.02 within the new Planning family.
The newer assessment objectives explicitly address additional content and activities, including:
- Identifying information types processed, stored, and transmitted by the system.
- Describing specific threats of concern to the organization.
- Identifying individuals fulfilling system roles and responsibilities.
- Reviewing and updating the SSP at an established frequency.
- Protecting the SSP from unauthorized disclosure.
Some of these expectations expand upon information that organizations may already maintain. Others, such as explicitly protecting the SSP from unauthorized disclosure, introduce a separately identifiable assessment expectation.
An organization maintaining a comprehensive Revision 2 SSP might already address much of this information. Another organization may need to make meaningful additions.
Importantly, Revision 3 does not necessarily require organizations to abandon their existing SSP and start over. Instead, organizations should evaluate existing content against revised requirement language and determination statements. Keep what still applies, adapt what needs updating, and add coverage for what is new. Finally, reorganize it to align with the new requirement and determination statement numbering.
Organization-defined parameters: The DoD has already established the expectations
One of the most consequential changes in Revision 3 is the introduction of organization-defined parameters.
NIST uses ODPs to establish particular values, frequencies, conditions, roles, or other parameters that complete security requirements.
In some applications, an organization may have responsibility for defining those values. However, for organizations implementing NIST SP 800-171 Revision 3 under DoD requirements, the Department has already established the applicable ODPs.
On April 10, 2025, the DoD issued its memorandum, Department of Defense Organization-Defined Parameters for National Institute of Standards and Technology Special Publication 800-171 Revision 3.
The memorandum establishes DoD policy for the ODP values in Revision 3, providing concrete expectations for numerous security activities.
Consider the following examples:
These values are taken from the Department’s published memorandum. The table is illustrative rather than a complete listing, and individual requirements may contain additional ODPs or conditions.
This changes how organizations should approach Revision 3 comparisons.
Consider the SSP requirement again.
Revision 2 assessment objective 3.12.4[g] already requires organizations to define the frequency for updating the SSP.
Revision 3 also addresses the frequency of SSP reviews and updates. However, the DoD now establishes the specific frequency and event-related expectations.
An organization that previously defined a less frequent SSP review cycle may need to adjust its processes to satisfy the DoD-defined parameter under Revision 3.
The underlying concept of maintaining an SSP is not new, but the applicable expectation becomes more specific.
This is an important example of why a requirement might be classified as Similar when comparing wording, while the actual implementation expectations become Expanded when the DoD-defined ODP is considered.
Not every DoD-defined ODP is a numerical value
The DoD memorandum also identifies four instances where it provides guidance rather than a fixed value.
One example is Revision 3 requirement 03.16.01, Systems Security Engineering Principles.
For this requirement, the DoD provides guidance addressing documentation that supports the implementation and operation of security controls. It discusses appropriate user and administrator guidance, required configuration settings, and acceptance criteria for systems and components.
This is particularly relevant because it demonstrates that ODPs are not limited to frequencies, time periods, or numerical thresholds.
Some require organizations to translate established guidance into practical implementation requirements.
Organizations should therefore distinguish between parameters established through specific values and parameters addressed through DoD guidance. Both deserve consideration when evaluating security implementations and supporting documentation.
An ODP should not be treated as an unrestricted blank field for the contractor to complete. The DoD-defined value or guidance must inform the applicable implementation and assessment.
Read the official DoD Organization-Defined Parameters memorandum
New requirements: Not everything has a Revision 2 counterpart
Revision 3 also introduces requirements that are new to the SP 800-171 requirement structure.
One example is 03.17.01, Supply Chain Risk Management Plan.
Revision 2 addressed several security considerations associated with suppliers, external systems, and organizational dependencies. However, it did not include a dedicated Supply Chain Risk Management family or an equivalent requirement for developing and maintaining a supply chain risk management plan.
Revision 3 introduces assessment objectives addressing the development, maintenance, and protection of that plan.
The DoD also establishes the frequency for reviewing and updating the supply chain risk management plan: at least every 12 months, or when significant incidents or significant changes to risks occur.
Another example is 03.16.02, Unsupported System Components, which establishes explicit expectations concerning components that no longer receive support from developers, vendors, or manufacturers.
These examples demonstrate why organizations cannot rely exclusively on renumbering or reusing existing documentation. Certain requirements will require additional processes, responsibilities, and supporting evidence. However, an entirely new requirement number does not always mean the underlying security activity is new.
Consider Revision 3 requirement 03.04.10, System Component Inventory. Although this requirement has a new identifier, Revision 2 requirement 3.4.1 already contained assessment objectives addressing system inventories.
Revision 3 makes certain inventory maintenance and update expectations more explicit.
That is why meaningful revision comparisons must go beyond matching requirement identifiers.
What about requirements that disappeared?
Revision 3 withdraws or consolidates several Revision 2 security requirements. That does not necessarily mean the underlying security expectation has disappeared.
NIST’s transition documentation identifies multiple instances where requirements were incorporated into other requirements or addressed elsewhere. For example, Revision 2 requirement 3.1.17, concerning wireless authentication and encryption, is incorporated into Revision 3 requirement 03.01.16. An organization comparing only requirement identifiers might mistakenly conclude that a particular security expectation was eliminated.
In reality, the relevant assessment objectives continue to exist within a different requirement structure.
A complete comparative analysis should therefore work in both directions: identifying Revision 2 predecessors for Revision 3 objectives while accounting for objectives that were removed, combined, or redistributed.
What does this mean for organizations maintaining Revision 2 compliance?
Organizations already maintaining Revision 2 security programs should begin by understanding their existing implementations rather than immediately replacing documentation.
An effective comparative analysis should determine whether existing safeguards continue to meet the revised security expectations, whether documentation requires modification, and whether additional evidence is necessary.
For organizations planning to implement Revision 3 in a DoD context, the DoD’s ODP definitions must be considered the minimum expectation.
This creates several important considerations. An organization may already have a technical safeguard that satisfies a more detailed Revision 3 expectation, even though its existing policy, procedure, or SSP does not sufficiently describe the implementation.
Another organization may have documentation that adequately describes a security activity but needs to modify the activity itself to meet a specific DoD-defined parameter. In other situations, the revised requirement may introduce new processes, roles, or responsibilities.These are different types of gaps and should not all be addressed through the same corrective action.
A useful crosswalk allows organizations to distinguish among them and focus resources where meaningful changes are necessary. It also provides an opportunity to preserve investments in security capabilities and compliance documentation that remain appropriate.
A note about CMMC applicability
For defense contractors, it is important to distinguish the publication of a revised NIST standard from the requirements established through contracts and the Cybersecurity Maturity Model Certification (CMMC) Program.
As of November 2026, the Department continues to use NIST SP 800-171 Revision 2 as the applicable CMMC Level 2 assessment baseline.
On July 13, 2026, the Department announced the suspension of the planned Phase II implementation while maintaining Phase I self-assessment requirements and applicable safeguarding obligations.
The Department’s published CMMC guidance also explains that contractors may implement Revision 3, but those doing so must use the DoD-defined ODPs and address any remaining gaps against the applicable Revision 2 assessment baseline. Therefore, the DoD’s publication of Revision 3 ODPs does not, by itself, change the current CMMC assessment baseline.
Organizations should continue to follow their applicable contractual requirements while using the Revision 3 comparison to inform future planning and security program development.
What the comparison ultimately tells us
The differences between NIST SP 800-171 Revision 2 and Revision 3 extend beyond requirement numbers, additional security families, and updated terminology.
Our analysis indicates that a substantial portion of the change involves making security expectations more explicit and individually assessable. For defense contractors, the DoD-defined ODPs add another important dimension by establishing measurable expectations for many of those security activities.
More assessment objectives do not necessarily mean an equivalent increase in technical controls. Similarly, retaining comparable assessment-objective wording does not guarantee that an existing implementation will satisfy all revised expectations.
Organizations must evaluate both the requirement and the associated assessment objectives, including the values and guidance established by the applicable authority.
The goal should not be to rewrite an entire security compliance program simply because the standard has changed. It should be to understand the changes well enough to preserve what works, address what is missing, and maintain an effective security program that continues to protect Controlled Unclassified Information.