The System Security Plan is the most important document in your CMMC program. It is also the most commonly deficient one.
Every Level 2 organization must have an SSP. CA.L2-3.12.4, the SSP requirement, is the only hard gate in the CMMC assessment process: if your SSP is Not Met, SPRS returns "No Score" and the assessment cannot proceed. There is no certification path without a completed, accurate SSP.
This article explains what the SSP must contain, how to build one that holds up to C3PAO scrutiny, and the most common SSP failures that derail assessments.
The SSP is a formal document that describes your information system, defines the boundary of what is being protected, and documents how each of the 110 NIST SP 800-171 requirements is implemented. For C3PAO assessors, the SSP is the primary reference document for understanding your environment and evaluating your controls.
The SSP serves several functions simultaneously:
The SSP is a living document. It must be updated whenever the system environment changes, when new requirements are implemented, or when the implementation approach for an existing requirement changes.
A complete CMMC SSP addresses eight core components:
Describe the information system being documented: its name, purpose, and role in supporting business functions. Identify the data types processed (FCI, CUI, commercial), the criticality of the system, and the business processes it supports.
Define the CMMC Assessment Boundary: the set of systems, components, and users included in the assessment. The boundary description should include:
The boundary section is where assessors start their review. If the boundary is vague, incomplete, or inconsistent with the technical evidence they find, it generates findings.
For each of the 110 NIST SP 800-171 Rev 2 requirements, the SSP documents:
Implementation Status: One of four designations:
Implementation Description: A specific, concrete description of how the requirement is satisfied. Not a restatement of the requirement. Not a generic statement. A description of your actual implementation.
Example of a weak implementation description:
"The organization implements multi-factor authentication for all users."
Example of a strong implementation description:
"Multi-factor authentication is enforced through Azure Active Directory Conditional Access Policy 'Require MFA - All Users,' applied to all user accounts in the CUI-Users security group. MFA is enforced at the Azure AD tenant level for all authentication to CUI-scope applications including SharePoint GCC High, VPN (Cisco AnyConnect with Azure AD SAML integration), and administrative portals. Exemptions require written approval from the ISSO and are documented in the access exception log. The policy prevents any authentication without MFA completion, including legacy authentication protocols which are blocked by Conditional Access Policy 'Block Legacy Authentication.'"
The second version tells an assessor exactly what is in place, how it is enforced, which specific policy or configuration implements it, and what exceptions exist.
For each requirement, identify the role responsible for implementation and ongoing management. This does not need to be an individual's name (people change roles), but should be a specific, titled role: System Administrator, ISSO, HR Director, Facilities Manager.
Assessors will interview the people in these roles. If the SSP says the ISSO is responsible for access reviews but the ISSO is not aware of the access review process, that generates an interview finding.
Document all connections to systems outside the CMMC boundary:
For each external connection, document the data flows (what goes where), the security controls governing the connection, and whether the external party has been assessed.
The SSP should reference the specific policies and procedures that support each control area. For access control, reference your access control policy. For incident response, reference your incident response plan. These referenced documents do not need to be included in the SSP itself, but they must exist and must be available as evidence.
Requirements marked Partially Implemented or Planned should have corresponding POA&M entries. The SSP and POA&M must be consistent: if the SSP says a requirement is Partially Implemented, there should be a POA&M item documenting what is incomplete and when it will be resolved.
The SSP must show evidence of formal review and approval. This includes the date of the current version, the approving official, and a record of prior review dates. An SSP that has never been formally reviewed or approved by leadership does not satisfy the administrative requirements of the control.
The most common SSP failure is aspirational documentation. The SSP describes what the organization plans to implement, not what is currently in place. Phrases like "the organization will implement," "plans are in place to," or "is in the process of deploying" are indicators that the control is Planned, not Implemented.
An assessor will test the environment as it exists today, not as described in future plans. If the technical testing finds that a control described as Implemented in the SSP is not actually in place, every instance of that discrepancy is a finding.
A meaningful number of organizations attempting CMMC compliance have never built an SSP. Without it, no assessment can proceed. If you do not have an SSP, building one is the first priority.
SSPs built from templates without customization to the specific environment are a problem. Assessors have seen enough generic SSP text to recognize it immediately. Generic language ("the organization employs boundary protection") without specifics about what boundary protection mechanism is deployed, where it is deployed, and how it is configured, does not give an assessor what they need to make a Met determination.
Every implementation description should name the specific technology, reference the specific configuration or policy, and describe how the specific implementation addresses the specific requirement in your specific environment.
An SSP written 18 months ago that has not been updated to reflect a cloud migration, a new office location, a new MSP, or personnel changes describes a system that no longer exists. Assessors will identify discrepancies between the SSP description and the actual environment, and those discrepancies are findings.
If the SSP marks a requirement as Implemented but the POA&M includes a remediation item for the same requirement, there is an internal inconsistency. Assessors will flag this. The SSP and POA&M must be aligned: Implemented requirements have no POA&M entry; Partially Implemented or Planned requirements have corresponding POA&M entries.
For organizations building an SSP for the first time, the process is most efficient in this order:
The Department of Defense (redesignated the Department of War by executive order, September 2025) (DoD) provides an SSP template in the CUI SSP Template package. This template is aligned to the NIST 800-171 requirement structure and is a reasonable starting framework. However, the template is a starting point, not a final product. Every implementation description must be customized to your actual environment.
The eMASS Pre-Assessment Template also provides guidance on the format expected for SSP submission in the eMASS system.
For the full CMMC program overview, see the CMMC 101: The Complete Guide to CMMC Compliance for Defense Contractors.
Related articles in this series:
Need an SSP built to DIBCAC standards? NR Labs writes System Security Plans that assessors can actually evaluate. No generic templates, no aspirational language. Contact us to discuss your SSP requirements.
