CMMC 2.0 System Security Plan
Required Components, Structure, and Compliance Obligations
A System Security Plan (SSP) is the foundational compliance document required of every defense contractor subject to the Cybersecurity Maturity Model Certification (CMMC) 2.0 framework. It is not an administrative formality. An SSP is the primary artifact that assessors examine to determine whether a contractor’s cybersecurity posture meets the standards necessary to handle Controlled Unclassified Information (CUI) on behalf of the Department of Defense.
This white paper details every required component of a CMMC 2.0 SSP, organized by regulatory origin, assessment function, and implementation level. It addresses the specific evidence assessors require, the legal consequences of inaccurate documentation, the obligations of contractors using cloud or managed service providers, and the ongoing maintenance requirements that apply after an SSP is first completed.
- The SSP mandate originates in DFARS 252.204-7012 and is codified for CMMC 2.0 in 32 CFR Part 170. All contractors subject to CMMC Level 2 or Level 3 must maintain a complete, accurate SSP.
- An SSP must document the current implemented state of controls — not intended or aspirational states. Describing what a control will do rather than what it does is a primary assessment finding.
- System boundary definition is the single most consequential SSP component. An understated boundary that excludes assets which process, store, or transmit CUI is both a compliance failure and a source of legal liability.
- The SSP and Plan of Action and Milestones (POA&M) must be formally cross-referenced. Every control marked partially or not implemented requires a corresponding POA&M entry with remediation timeline.
- Contractors using external cloud services or managed security providers must document control inheritance formally, including customer responsibility matrices from each provider.
- Executive attestation of SSP accuracy creates False Claims Act exposure. The DoJ’s Civil Cyber-Fraud Initiative has established that knowingly submitting an inaccurate SSP in connection with a federal contract may constitute fraud.
The requirement to maintain a System Security Plan predates the CMMC framework by more than a decade. Understanding the full regulatory lineage is essential to understanding what the SSP must contain and why.
Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012, titled “Safeguarding Covered Defense Information and Cyber Incident Reporting,” is the primary contractual mechanism requiring defense contractors to implement NIST SP 800-171 controls and maintain documentation of that implementation. This clause has been mandatory in covered DoD contracts since December 2017.
CMMC 2.0, codified through 32 CFR Part 170 (interim final rule, 2024), formalizes the SSP requirement into a structured three-level framework:
| CMMC Level | Control Set | SSP Assessment Context |
|---|---|---|
| Level 1 — Foundational | 15 controls (FAR 52.204-21) | Annual self-assessment; SSP documentation expected but not C3PAO-verified; no formal SSP template mandated. |
| Level 2 — Advanced | 110 practices (NIST SP 800-171 Rev 2) | Triennial C3PAO assessment (critical programs) or annual self-assessment; complete SSP required and is the primary assessment artifact. |
| Level 3 — Expert | NIST SP 800-172 overlay (130+ practices) | Government-led assessment by DCSA; full SSP plus enhanced documentation; heightened evidence standards. |
While CMMC does not mandate a specific SSP format, NIST SP 800-18, Rev. 1 defines the canonical structure that assessors expect. Contractors deviating significantly from this structure face increased risk of findings related to documentation completeness rather than control implementation.
System boundary definition is the most consequential structural decision in SSP development. The boundary determines which assets, users, networks, and processes are subject to CMMC controls. An incorrectly defined boundary — whether too narrow or insufficiently documented — is the most frequently cited finding in CMMC assessments.
The system boundary must include every asset that processes, stores, or transmits CUI. This is not limited to servers and workstations.
- All hardware that touches CUI: endpoints, servers, networking equipment, removable media, printers, and mobile devices
- All software: operating systems, applications, collaboration tools, and utilities that process or access CUI
- All cloud services: SaaS platforms (including email), IaaS environments, and managed services that handle CUI
- All network segments through which CUI transits, including VPNs and remote access infrastructure
- All users: employees, contractors, and third-party personnel with access to CUI systems
- All physical locations from which CUI systems are accessed
A complete CMMC 2.0 SSP, aligned with NIST SP 800-18 and the CMMC Assessment Process (CAP), contains a defined set of mandatory components. Each component serves a specific evidentiary function in the assessment process.
This is the substantive core of the SSP and the section that assessors examine most intensively. For each of the 110 NIST SP 800-171 security requirements (at Level 2), the SSP must contain an implementation statement describing how that specific control is currently implemented.
The three implementation status designations are:
- System Owner — executive accountability for the system and SSP accuracy
- Information System Security Officer (ISSO) — day-to-day security management
- System Administrator(s) — technical implementation and maintenance
- Authorizing Official — the individual who signs the Plan of Action and accepts residual risk
- Data Owner — responsibility for the CUI handled by the system
The SSP does not stand alone. Assessors expect a defined set of supporting artifacts that substantiate the claims made in the SSP’s control implementation statements. An SSP without supporting artifacts is considered incomplete regardless of the quality of its prose.
| Supporting Document | Required Content |
|---|---|
| Information Security Policy | The governing policy establishing the organization’s security objectives, executive commitment, and compliance obligations. Must reference NIST 800-171 and applicable CMMC level. |
| Configuration Baseline Documentation | Documented secure configuration standards for each major asset class. Must reference a recognized standard such as CIS Benchmarks or DISA STIGs. |
| Access Control Policy and Procedure | Describes how access to CUI systems is granted, reviewed, modified, and revoked. Must address least privilege and separation of duties. |
| Incident Response Plan | A documented procedure for detecting, responding to, and reporting cybersecurity incidents. Must include DFARS 252.204-7012 reporting timelines (72-hour DoD notification). |
| Contingency / Business Continuity Plan | Documentation of backup procedures, recovery time objectives, and testing cadence for systems handling CUI. |
| Risk Assessment | A current risk assessment identifying threats, vulnerabilities, and accepted residual risks. Must be updated at minimum annually for Level 2. |
The Plan of Action and Milestones is a companion document to the SSP that is inseparable from it for assessment purposes. The SSP describes what is implemented; the POA&M documents what is not yet implemented, why, and on what timeline remediation will occur.
Every POA&M entry must be traceable to a specific SSP section or control statement. Assessors verify this linkage explicitly. An SSP that describes a control as “partially implemented” but has no corresponding POA&M entry is itself a compliance finding.
The widespread use of cloud infrastructure, managed security services, and SaaS platforms has introduced one of the most complex documentation challenges in CMMC compliance: control inheritance. When a third party implements a control on the contractor’s behalf, the SSP must formally document both the inherited control and the boundary of contractor responsibility.
Cloud providers operating under FedRAMP publish a Customer Responsibility Matrix (CRM) — a document identifying, for each NIST control, whether the provider, the customer, or both share responsibility. The contractor’s SSP must include or reference the applicable CRM and must explicitly describe how the contractor is fulfilling its share of each shared responsibility.
An SSP is not a point-in-time document. It must reflect the current state of the environment at all times. An SSP that accurately described an organization’s controls eighteen months ago but has not been updated since is not a compliant SSP — it is evidence of a maintenance failure.
- Significant changes to the system architecture, including new systems, decommissioned systems, or changes to network topology
- Addition or removal of external service providers or cloud services
- Changes to personnel in key security roles (system owner, ISSO, authorizing official)
- Implementation of a new security control or modification of an existing one
- Closure of a POA&M item (requires updating the corresponding control implementation statement)
- Discovery of a previously undocumented asset within the CUI environment
The legal dimensions of SSP documentation represent one of the most significant and underappreciated risk areas in CMMC compliance. The consequences of a materially inaccurate SSP extend beyond failed assessments into federal fraud liability and executive personal exposure.
The False Claims Act (31 U.S.C. § 3729) imposes civil liability on any person or entity that knowingly submits a false claim to the federal government. A contractor that submits an SSP it knows to be inaccurate — and certifies compliance with DFARS cybersecurity requirements — is presenting a potentially false certification in exchange for federal payment. The Department of Justice formalized this enforcement posture with the launch of the Civil Cyber-Fraud Initiative in October 2021.
The CMMC SSP requirements were designed with the full range of defense contractors in mind, but the compliance burden falls disproportionately on small businesses — companies with fewer than 50 employees, limited IT staff, and no dedicated cybersecurity function.
The most practical approach for small contractors is rigorous CUI scoping. If the organization can segregate CUI handling to a defined subset of systems — a dedicated CUI enclave — the SSP scope can be significantly reduced. This is legitimate architectural design that reduces compliance burden while maintaining control effectiveness.
- Using a dedicated CUI-handling workstation or virtual desktop as the only in-scope endpoint
- Using a CMMC-compliant cloud enclave (such as Microsoft 365 GCC High) for all CUI processing, limiting in-scope on-premise assets to authentication infrastructure
- Implementing network segmentation that isolates CUI systems from general business IT
Citations follow Chicago author-date format.