System Security Plan (SSP) for CMMC Compliance
Last reviewed · By Chad Griffith
The System Security Plan (SSP) is the primary documentary artifact required for CMMC Level 2 and 3 compliance. The SSP describes how each NIST SP 800-171 control is implemented in the contractor's environment, including system boundaries, control implementation details, responsible parties, and any deviations or compensating controls. An incomplete or vague SSP is among the most common findings during C3PAO assessment.
What an SSP Must Include
NIST SP 800-171 requires the SSP to include: system identification (system name, system boundary, environment of operation); system description (mission, business function, hosting and ownership details); information types processed with FIPS 199 categorization; control implementation for each of the 110 controls describing what the control means for this specific system, who is responsible, and how implementation is verified; system interconnections; operational environment; and plan maintenance procedures.
System Boundary Definition
The system boundary defines what's in scope of the SSP — typically all systems and components that process, store, or transmit CUI plus any systems that provide security functions for CUI-handling systems. Common boundary mistakes: excluding cloud services that handle CUI, excluding personal devices used for CUI access, including too-broad enterprise-wide systems unnecessarily, or failing to identify all CUI processing locations across the organization.
Control Implementation Detail
Each of the 110 controls requires specific implementation language in the SSP. Best practice is to address each control with: (1) what the control is doing in this environment, (2) who performs the control activities, (3) what evidence demonstrates the control is operating, and (4) any compensating measures or accepted residual risks. Vague implementation language ('we follow industry best practices') is frequently flagged as inadequate during assessment.
Common SSP Findings
Frequent C3PAO assessment findings: control implementation language too generic to evaluate; system boundary missing CUI-handling components; outdated SSP not reflecting current system state; missing or weak responsible-party assignments; inadequate description of cloud service responsibilities (shared responsibility model not addressed); missing FIPS 199 categorization; inconsistencies between SSP and observed implementation. Best practice is to update the SSP whenever significant system changes occur, with annual full review.
Frequently Asked Questions
How long is a typical CMMC SSP?
SSP length depends on system complexity but typically runs 80-200 pages for a mid-market defense contractor. Each of the 110 controls requires specific implementation language. Larger enterprise environments with multiple system boundaries can produce 500+ page SSPs across consolidated systems.
Can the SSP cover multiple systems?
Yes. NIST 800-171 allows a single SSP to cover multiple systems if they have common security characteristics and ownership. Larger organizations often maintain a single enterprise SSP with system-specific addenda. C3PAO assessors evaluate whether the consolidation accurately reflects implementation across systems.
Who writes the SSP?
Typically the contractor's IT security team or compliance lead, often with consultant support. The senior official who attests the SSP must understand the document well enough to defend it. Common practice is internal security-and-IT collaboration with a registered consultant or RPO (Registered Provider Organization) providing review and gap analysis.
How often must the SSP be updated?
NIST 800-171 requires the SSP to be updated whenever significant changes occur in the system, environment, or threats. Best practice is full annual review with continuous updates as significant system changes are made. C3PAO assessors will flag SSPs that don't reflect the actual system state at time of assessment.
Authoritative sources