What Is an SSP? System Security Plans Explained for CMMC
- Brandon Alsup
- Jun 2
- 5 min read
With so many acronyms and shorthand in the arena of Cybersecurity Maturity Model Certification (CMMC) we are taking a look at some of the most common to clear up the language and understanding. So, without further preamble, here is SSP.
A System Security Plan, usually called an SSP, is one of the most important documents in a CMMC Level 2 readiness effort.
It is also one of the most misunderstood.
Many organizations treat the SSP like a paperwork requirement: something to assemble near the end of the project so an assessor has a document to review. That approach creates problems. A strong SSP is not just a form. It is the operating map of your compliance environment.
In plain English, the SSP explains:
what systems are in scope,
where the system boundary is,
how security requirements are implemented,
how the environment operates,
and how the system connects to other systems, vendors, or service providers.
NIST SP 800-171 requirement 3.12.4 specifically calls for organizations to “develop, document, and periodically update” system security plans that describe system boundaries, operating environments, implementation of security requirements, and relationships or connections to other systems.
An SSP Is the Story of Your Security Environment
For CMMC, the SSP should describe the actual environment that processes, stores, transmits, or protects Controlled Unclassified Information (CUI). It should not describe an idealized future version of the company.
If your SSP says one thing but your systems, users, vendors, or evidence show something else, the document becomes a liability instead of a strength. A useful SSP should be accurate enough that someone can understand how your environment is secured, where the boundaries are, and how the required controls operate.
The current CMMC program rule defines an SSP as the formal document that provides an overview of the security requirements for an information system or security program and describes the controls in place or planned for meeting those requirements. It also says the SSP describes system components, the operating environment, how requirements are implemented, and relationships or connections to other systems.
That is why the SSP sits at the center of CMMC readiness.
It connects scope, controls, documentation, evidence, vendors, and operations.
Why the SSP Matters for CMMC Level 2
CMMC Level 2 currently uses the security requirements in NIST SP 800-171 Revision 2. The CMMC rule states that Level 2 security requirements are identical to the requirements in NIST SP 800-171 Rev. 2.
The SSP matters because it helps show how those requirements are implemented in your environment.
It is not enough to say, “We have MFA,” or “We use endpoint protection.” The SSP should help explain how those controls apply to the systems in scope, who is responsible for them, whether they are inherited from a provider, and how they are supported by policies, procedures, and evidence.
A good SSP gives structure to the assessment conversation.
A weak SSP forces everyone to hunt for answers.
What Should an SSP Include?
There is no single required SSP format. NIST notes that there is “no prescribed format or specified level of detail” for system security plans, as long as the required information in 3.12.4 is conveyed. NIST also explains that security plans do not have to be a single document; they may be a collection of documents with references to policies, procedures, specifications, and other supporting materials.
In practice, a CMMC-focused SSP often includes:
system name and purpose,
CMMC assessment scope,
CUI data flows,
system boundary description,
network and data-flow diagrams,
asset categories,
users and roles,
external connections,
cloud services and external service providers,
control implementation descriptions,
inherited controls,
policies and procedures,
and references to evidence.
The key is not page count. The key is clarity.
An SSP should help answer:
What is in scope, how is it protected, and how do we know the controls are operating?
The SSP and the Compliance Boundary
The SSP is where your compliance boundary becomes concrete.
For CMMC Level 2, the assessment scope can include more than obvious user workstations and servers. The rule identifies asset categories such as CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out-of-Scope Assets. Several of these categories require documentation in the asset inventory, the SSP, and the network diagram.
This is where many organizations get delayed.
They think the SSP is just a control narrative. It is not. It is also the place where the organization explains what is in scope, what is out of scope, and why.
If a system can process, store, or transmit CUI, it needs careful review. If a tool protects the CUI environment, it may also matter. If a vendor or MSP supports the environment, its role may need to be documented.
The CMMC rule specifically addresses External Service Providers. If an ESP is used in a Level 2 environment, the use of that provider, its relationship to the organization, and the services provided must be documented in the SSP and described in the provider’s service description and customer responsibility matrix.
That makes the SSP a shared-responsibility document, not just an internal IT document.
Common SSP Mistakes
The most common SSP mistake is writing the document too late.
If the SSP is created after remediation, it often becomes a reverse-engineered explanation of decisions that were never properly recorded. That creates gaps.
Other common mistakes include:
describing tools instead of control operation,
leaving vendors or MSPs out of the picture,
failing to explain what is out of scope,
using generic language that does not match the real environment,
failing to keep the SSP updated as systems change,
and treating the SSP as separate from evidence collection.
A strong SSP should be maintained as the environment changes. It should evolve with new systems, new vendors, new CUI workflows, and new control decisions.
Final Takeaway
An SSP is not just paperwork for CMMC.
It is the documented explanation of how your organization protects CUI within a defined environment.
A good SSP helps leadership, IT, vendors, and assessors understand the same reality. It connects the compliance boundary to the controls, the controls to evidence, and the evidence to daily operations.
The goal is not to make the SSP look impressive.
The goal is to make it accurate, current, and defensible.
If your SSP does not reflect how your organization actually operates, it needs work before assessment readiness can be taken seriously.
Sources and Official References
1. NIST SP 800-171 Revision 2
NIST publication page:
Direct PDF:
Note: NIST SP 800-171 Rev. 2 has been withdrawn by NIST and superseded by Rev. 3, but the current CMMC Level 2 rule still references Rev. 2. NIST’s PDF shows the withdrawal/supersession notice, while 32 CFR Part 170 incorporates NIST SP 800-171 R2 for CMMC Level 2.
2. 32 CFR Part 170 — CMMC Level 2 Requirements
eCFR Part 170 § 170.14(c)(3):
The relevant language says: “The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2.”
Disclaimer
The information contained in this communication is intended for limited use for informational purposes only. It is not considered professional advice, and instead, is general information that may or may not apply to specific situations. Each case is unique and should be evaluated on its own by a professional qualified to provide advice specifically intended to protect your individual situation. TK Compliance is not liable for improper use of this information.
Comments