If you’ve spent any time preparing for a NIST SP 800-171 or CMMC assessment, you’re probably intimately familiar with the System Security Plan (SSP). It’s one of the first documents assessors want to see, and for good reason. The SSP is supposed to explain what you’re protecting, where the boundaries of your environment exist, and how your organization implements the security requirements intended to protect Controlled Unclassified Information (CUI).
When NIST released Revision 3 in May 2024, it made several changes to the SSP requirement. Some are relatively straightforward, while others raise interesting questions about how organizations should document their security programs.
The SSP requirement moved from 3.12.4 under the Security Assessment family to 03.15.02 under the new Planning family. More importantly, NIST changed the language describing what should be included in the SSP and expanded the associated assessment objectives.
One change stands out: Revision 2 expects organizations to document how security requirements are implemented. Revision 3 instead calls for descriptions of the safeguards in place or planned to meet those requirements.
That might seem like a minor wording change, but it raises an important question. How much detail does an organization actually need in its SSP?
Before getting into the differences, there’s one point worth clarifying.
Revision 2 Is Still the CMMC Baseline
Although NIST published Revision 3 in 2024, it does not automatically replace Revision 2 for organizations subject to CMMC Level 2 or other obligations such as DFARS 252.204-7012.
The Department of Defense’s July 13, 2026, announcement suspended CMMC Phase II requirements and future implementation milestones while the Department reviews the program. Existing Phase I self-assessment requirements remain in effect, and the Department continues enforcing NIST SP 800-171 Revision 2 through self-assessments and selected government-led assessments.
For now, defense contractors should continue following their applicable contractual requirements rather than assuming the latest NIST publication has replaced the established assessment baseline.
That doesn’t mean Revision 3 should be ignored. Understanding the differences now can help organizations improve their documentation and prepare for future changes without rebuilding their SSPs unnecessarily.
What Revision 2 Actually Requires
Under NIST SP 800-171 Revision 2, requirement 3.12.4 directs organizations to develop, document, and periodically update SSPs describing system boundaries, operating environments, how security requirements are implemented, and relationships or connections to other systems.
The corresponding assessment procedure in NIST SP 800-171A breaks the requirement into eight assessment objectives.
These address whether:
- An SSP has been developed.
- The system boundary and operating environment are described.
- Security requirements approved as non-applicable are identified.
- Methods of implementing security requirements are documented.
- Relationships or connections to other systems are described.
- The organization has defined and followed an SSP update frequency.
There’s nothing particularly complicated about the basic expectation. An organization should be able to explain its environment and how it addresses applicable security requirements.
However, developing an SSP that contains enough useful information can be more challenging than it first appears.
Consider an organization that uses Microsoft 365 GCC High to process CUI. Its SSP might identify Microsoft Entra ID as the identity management solution, Microsoft Intune for endpoint management, and Microsoft Defender for endpoint protection.
That’s useful information, but does it explain how the organization implements the applicable security requirements?
Not necessarily.
Simply identifying a product doesn’t tell an assessor which settings are configured, what restrictions are enforced, or how the implementation satisfies a particular requirement.
This distinction becomes especially important when examining Revision 2 assessment objective 3.12.4[e], which specifically evaluates whether the method of implementing security requirements is described and documented.
The SSP doesn’t need to contain every technical configuration or procedural detail. It does, however, need to provide enough information, either directly or through referenced materials, to explain how requirements are addressed.
There’s also a difference between documenting an implementation and demonstrating that it works.
A well-written SSP may help an assessor understand how multifactor authentication is configured, but the assessment of the underlying MFA requirement still requires sufficient evidence to determine whether it has been implemented correctly.
An accurate description and an effective implementation should support each other. Neither substitutes for the other.
What Revision 3 Wants to Know About Your Environment
Revision 3 takes a somewhat different approach.
Instead of concentrating primarily on the system boundary, operating environment, and implementation methods, requirement 03.15.02 identifies eight specific elements that should be included in the SSP.
The accompanying assessment procedure expands these into twelve determination statements, including the organization-defined review and update frequency.
Here’s how the expectations compare.
| SSP topic | Revision 2 | Revision 3 |
| System description | Describe system boundaries | Define the system’s constituent components |
| Information | No separate SSP objective to identify information types | Identify types of information processed, stored, and transmitted |
| Threats | No explicit SSP objective for threats | Describe specific threats of concern |
| Operating environment | Describe the operating environment and system connections | Describe the environment, dependencies, and connections |
| Security implementation | Describe methods of implementing security requirements | Provide a requirements overview and describe safeguards |
| Responsibilities | No distinct SSP objective | Identify individuals fulfilling system roles and responsibilities |
| Updates | Define and follow an update frequency | Define the review and update frequency and perform both activities |
| SSP protection | No distinct SSP objective | Protect the SSP from unauthorized disclosure |
A few of these differences deserve closer attention.
Knowing What’s Inside Your Security Boundary
Revision 2 emphasizes describing the system boundary. Revision 3 explicitly requires organizations to define the constituent components of the system.
These concepts are closely related, but they aren’t identical.
Think about a defense manufacturer operating a dedicated CUI environment. Its SSP may include a network diagram identifying the protected network, connected manufacturing equipment, servers, workstations, and external service connections.
That diagram may effectively establish the security boundary.
However, it might not provide sufficient information about the components that make up the system.
Revision 3 makes that component-level description an explicit SSP expectation.
For organizations already maintaining accurate inventories and architecture documentation, this may require little additional effort. Referencing an existing inventory might provide the needed information.
The important part is making sure the SSP clearly identifies the components included within the environment.
This also doesn’t mean system boundaries are no longer important. Organizations still need to establish which components are subject to applicable security requirements.
What Information Are You Actually Protecting?
Revision 3 also requires the SSP to identify the types of information processed, stored, and transmitted by the system.
This is an interesting addition because many SSPs identify the environment as handling CUI without describing the types of information involved.
Consider an engineering company supporting multiple defense programs.
One program might involve controlled technical information, while another involves export-controlled information. Both may involve CUI, but the information may originate from different customers, move through different business processes, or reside in different applications.
An SSP that simply states “the environment processes CUI” doesn’t provide much insight into those differences.
Revision 3 places greater emphasis on understanding what information the system handles, rather than relying solely on the general designation of CUI.
This information can also help an organization better understand where its protection responsibilities begin and end.
Identifying Threats That Matter to Your Organization
Another addition is the requirement to describe specific threats to the system that are of concern to the organization.
Notice the wording. NIST isn’t asking organizations to reproduce every cybersecurity threat they can imagine.
The emphasis is on threats relevant to the system.
For a defense contractor, those concerns might include unauthorized access to technical information, compromised credentials, malicious activity involving remote access, or the exposure of CUI through an external service provider.
A manufacturer might have additional concerns involving legacy equipment, specialized manufacturing systems, or production technologies that cannot support conventional security mechanisms.
The SSP should reflect threats that matter to the environment being described.
Organizations already conducting risk assessments may have much of this information available. They can incorporate the relevant descriptions or reference existing risk documentation.
The change doesn’t necessarily require a new risk assessment framework. It requires the SSP to communicate the threats of concern.
Has NIST Changed How We Should Describe Security Implementation?
This is probably the most interesting part of the comparison.
Revision 2 assessment objective 3.12.4[e] evaluates whether the method of security requirement implementation is described and documented in the SSP.
Revision 3 assessment objective A.03.15.02.a.06 evaluates whether the SSP describes the safeguards in place OR planned for meeting the security requirements.
The wording changes from describing methods of implementation to describing safeguards.
Does that mean organizations no longer need detailed, requirement-by-requirement implementation descriptions?
Not quite.
First, neither revision mandates a specific SSP format. Revision 2 doesn’t explicitly require a separate narrative for every assessment objective, and Revision 3 doesn’t prohibit that approach.
Second, the discussion accompanying Revision 3 explains that an SSP should contain enough information to support a system design and implementation consistent with the plan.
That suggests organizations still need to describe their security environment with sufficient accuracy and detail.
But the change raises an interesting possibility.
Organizations may need to update their current SSP format to most effectively communicate how their environments are secured.
An Example Using Multifactor Authentication
Consider the requirement to implement multifactor authentication.
An SSP written under Revision 2 might describe the authentication methods used, the account categories requiring MFA, how MFA is enforced, and any conditions or exceptions affecting its implementation.
That approach directly addresses the method of implementing the security requirement.
Under Revision 3, the SSP might describe the identity management and authentication safeguards used to meet the applicable requirements, supported by configuration documentation, diagrams, or implementation records.
Both approaches can provide useful information.
The difference may lie less in the amount of documentation than in how the information is organized and presented.
A consolidated description of identity and authentication safeguards could support multiple security requirements. Alternatively, separate implementation narratives might make it easier to trace individual requirements to the organization’s security mechanisms.
There are advantages to both approaches.
The problem arises when organizations mistake documentation structure for compliance.
A lengthy SSP isn’t necessarily a good SSP. Likewise, a short SSP isn’t necessarily inadequate.
What matters is whether the documentation provides sufficient information to understand the system and evaluate the applicable requirements.
Should Organizations Stop Using Requirement-by-Requirement Narratives?
I wouldn’t recommend abandoning that approach simply because Revision 3 uses different language.
Requirement-by-requirement narratives remain useful, especially for organizations preparing for assessments under Revision 2.
They provide a straightforward way to connect individual requirements with the policies, procedures, systems, and technologies used to satisfy them.
They can also simplify documentation maintenance by making it easier to identify which portions of the SSP need attention when an implementation changes.
However, there’s no reason that supporting documentation cannot be organized around common safeguards, processes, or technologies.
For example, an organization might maintain a consolidated description of its identity management environment while using individual SSP narratives to explain how that environment addresses access control and authentication requirements.
The organization avoids unnecessary duplication while preserving the traceability needed for assessments.
Revision 3 provides a good opportunity to examine whether existing SSPs communicate useful information or have simply become collections of repetitive statements written to match assessment objectives.
What Happened to the Non-Applicable Requirements Objective?
One of the less obvious differences concerns security requirements that have been identified and approved as non-applicable.
Revision 2 includes assessment objective 3.12.4[d], which requires those requirements to be identified in the SSP.
Revision 3 does not include an identically worded SSP assessment objective.
That doesn’t mean exceptions or applicability decisions no longer matter.
NIST SP 800-171 Revision 3 still recognizes that certain specialized systems may have limitations affecting their ability to implement security requirements.
Section 3 specifically discusses using the SSP to describe enduring exceptions, while individual, isolated, or temporary deficiencies are addressed through plans of action and milestones.
For example, a manufacturer may operate specialized production equipment that cannot support certain conventional security capabilities.
Documenting the limitation, the surrounding environment, and any relevant safeguards can help establish how the organization manages the situation.
However, simply describing an exception in the SSP doesn’t automatically make the exception acceptable.
Organizations must still follow the applicable contractual, regulatory, and assessment rules governing exceptions, alternative safeguards, and unimplemented requirements.
This is an important distinction, particularly for organizations that have previously interpreted an SSP exception as equivalent to approval.
Your SSP Needs Attention After It’s Written
One of the more practical changes in Revision 3 involves maintaining the SSP.
Revision 2 requires organizations to define an update frequency and update the SSP according to that frequency.
Revision 3 explicitly addresses both reviewing and updating the SSP.
The Department of Defense’s April 2025 Organization-Defined Parameters memorandum establishes the frequency for 03.15.02(b) as at least every 12 months, or when significant incidents or significant changes to risks occur.
This is more specific than the Revision 2 SSP requirement, which allows the organization to define its update frequency.
But the frequency itself is only part of the issue.
Consider what happens when an organization migrates a system to a different cloud environment, implements a new security service, or establishes an additional connection with an external provider.
Those changes may affect the accuracy of the SSP.
An organization that updates its SSP only when an assessment approaches, might discover that the document no longer describes the environment it actually operates.
That creates problems beyond documentation quality. An outdated SSP can make it difficult for system administrators, security personnel, consultants, and assessors to understand which safeguards are supposed to be implemented.
Reviewing the SSP should be part of the organization’s normal security management activities.
That doesn’t mean the entire document needs to be rewritten every year. A documented review may confirm that much of the content remains accurate.
When changes are necessary, the affected information should be updated, and the organization should maintain enough history to establish what changed and when.
The SSP Itself Needs Protection
Revision 3 also introduces an explicit requirement to protect the SSP from unauthorized disclosure.
This makes sense when you consider what an SSP can reveal about an organization.
A detailed SSP may describe internal network architecture, security technologies, system components, administrative responsibilities, external connections, and other information that could be useful to an attacker.
Organizations should consider where SSPs are stored, who can access them, and how they are shared with consultants, assessors, and external service providers.
Access-controlled document repositories, appropriate sharing restrictions, and effective authentication mechanisms can help protect the information.
Not every SSP is automatically CUI simply because it describes a CUI environment. Any CUI designation must be based on the information’s applicable classification and handling criteria.
Nevertheless, protecting detailed security documentation from unnecessary disclosure is a sensible practice, and Revision 3 makes it an explicit assessment expectation.
Do You Need to Rewrite Your SSP for Revision 3?
Probably not from scratch.
If your organization has an SSP that accurately describes its environment and how security requirements are implemented, you may already have much of the information necessary to address Revision 3.
The first step should be comparing your current documentation against the revised assessment objectives.
You might discover that your system inventory already identifies constituent components, your risk assessment contains the relevant threat information, and your existing policies establish security responsibilities.
In that case, updating the SSP may involve adding descriptions or references rather than creating entirely new documents.
The same principle applies to security implementation information.
If your existing SSP contains clear implementation narratives, there may be little benefit in removing them simply because Revision 3 refers to safeguards.
Those narratives may continue to serve as valuable documentation, especially while Revision 2 remains applicable.
One caution is worth emphasizing: the SSP’s description of a safeguard does not prove that the safeguard has been implemented.
Revision 3 explicitly permits descriptions of safeguards that are in place or planned. That makes the SSP useful for documenting the organization’s intended security posture, but planned safeguards should not be mistaken for completed implementations.
Assessors must still evaluate the applicable security requirements to determine whether the necessary protections are actually implemented.
What Does This Mean for Your SSP?
If you’re maintaining an SSP today, the differences between Revision 2 and Revision 3 provide a useful opportunity to examine whether your documentation is doing what it’s supposed to do.
Does it accurately describe your system? Can someone unfamiliar with the environment understand which components are included, how CUI is handled, and what safeguards protect it? Can your personnel explain the implementation methods described in the SSP and demonstrate that those methods are actually being followed?
Those questions are worth asking regardless of which revision applies.
Revision 3 introduces additional expectations, but it doesn’t necessarily mean organizations need substantially larger SSPs or more complicated documentation programs.
What may need to change is how organizations think about the information they’re documenting.
An SSP shouldn’t exist merely to satisfy an assessment. It should be a useful representation of the environment and the safeguards an organization relies on to protect CUI.
For organizations that have spent years writing detailed implementation narratives against Revision 2 assessment objectives, there’s no reason to discard that work. A well-maintained SSP can support both the current assessment requirements and many of the expectations introduced in Revision 3.
The objective isn’t to produce more documentation. It’s to make sure the documentation you maintain accurately reflects the environment you’re responsible for protecting.