Download a Free CMMC System Security Plan (SSP) Template
What Is A System Security Plan (SSP)
A System Security Plan (SSP) is a foundational document that describes how an organization implements the security requirements of NIST SP 800-171 to protect Controlled Unclassified Information (CUI). It documents the systems, technologies, policies, and security controls used to safeguard sensitive information across the organization.
For organizations pursuing CMMC Level 2 certification, the SSP is one of the most important assessment artifacts. C3PAO assessors use it as a roadmap to understand the environment, determine the scope of the assessment, and validate how security requirements have been implemented. The SSP should clearly describe where CUI resides, how it is protected, and how each applicable control is enforced.
An SSP is not just a document created for an audit, it must accurately reflect your organization’s actual security posture. As systems, processes, and technologies evolve, the SSP should be updated to ensure it remains current, supports audit readiness, and demonstrates ongoing compliance.
Define Scope & Boundary
Inventory CUI
Document Controls
Identify Gaps (POA&M)
Maintain & Update
SSP vs. Plan of Actions & Milestones (POA&M)
In addition to the System Security Plan (SSP), organizations implementing NIST SP 800-171 or pursuing CMMC certification are expected to maintain a Plan of Action and Milestones (POA&M). A POA&M is a document used to track security gaps, deficiencies, and planned remediation activities. It identifies controls that are not yet fully implemented, the actions required to address them, the individuals responsible, and target completion dates.
While the SSP documents the security controls currently in place, the POA&M serves as a roadmap for improving security and achieving compliance. Together, these documents provide a comprehensive view of an organization’s current security posture and its plan for addressing any remaining compliance gaps.
System Security Plan
Describes what you have implemented. Primary C3PAO assessment artifact. Must reflect actual posture. Includes architecture, roles, and control descriptions. Living document with version history.
Plan of Action & Milestones (POA&M)
Documents gaps not yet implemented. Each gap requires immediate timeline. Owner must be assigned to every item. Reviewed and updated continuously. Submitted alongside SSP at assessment.
What an SSP Must Include
System Identification & Description
Every SSP begins with basic identifying information — the system name, unique identifier, owner, and authorizing official — along with a plain-language description of the system's purpose, functions, and mission role.
Information Types and Categorization
This element documents what kinds of data the system handles and applies a formal impact rating (typically FIPS 199) across confidentiality, integrity, and availability to arrive at an overall system classification.
User Roles and Responsibilities
All system users, administrators, and privileged accounts are enumerated here, with each role's security responsibilities clearly defined. This establishes accountability and supports access control auditing.
System Environment and Inventory
Hardware, software, firmware, and operating environments (cloud, on premises, or hybrid) are fully inventoried. Physical locations and hosting arrangements are also documented to support asset management and scoping.
Security Policies and Procedures
The SSP should reference or incorporate the organizational policies and procedural documentation that govern system operation, covering areas like incident response, access management, configuration control, and media handling.
Plan of Action and Milestones (POA&M)
Any security gaps, open findings, or controls not yet fully implemented are tracked here with remediation owners, target dates, and interim mitigations. For CMMC assessments, a clean or well managed POA&M is critical.
System Boundary and Architecture
The authorization boundary defines exactly what is in scope. This section includes network and data flow diagrams that show how the system is structured and where data moves, both internally and across boundaries.
Applicable Laws, Regulations and Standards
The SSP must identify every compliance obligation that governs the system — whether that's NIST 800-171, CMMC, FedRAMP, HIPAA, or contractual requirements — so reviewers understand the full regulatory context.
Control Implementation Statements
The heart of any SSP. For each applicable security control, this section explains how it is implemented, whether at the system level, inherited from a provider, or handled as a hybrid, along with who owns it.
Interconnections and External Dependencies
Any system that exchanges data with external services, APIs, or third party providers must document those connections here, including the nature of the data shared and any governing agreements such as ISAs or MOUs.
Contingency and Recovery Planning
Business continuity and disaster recovery provisions belong in the SSP, including backup procedures, recovery time objectives, and how the system would be restored following an outage or incident.
Document Control and Approval
The SSP is a living document and must include version history, review cadence, and formal approval signatures from the system owner and authorizing official to establish its authority and currency.
Common SSP Mistakes to Avoid
Documenting Aspirational Controls
Your SSP should describe security controls that are currently implemented and operational—not controls you plan to deploy in the future. Unimplemented controls should be tracked in a POA&M rather than presented as compliant.
Defining the Wrong Scope
An SSP that is scoped too broadly increases compliance costs and complexity, while a scope that is too narrow may exclude systems, users, or services that handle CUI. Clearly defining the CUI boundary is critical to a successful assessment.
Failing to Maintain Version Control
Many organizations treat the SSP as a one-time document and fail to track revisions. Maintaining version history helps demonstrate governance and ensures assessors are reviewing the most current information.
Not Updating the SSP as the Environment Changes
Technology environments evolve over time. New systems, cloud services, applications, and processes should be reflected in the SSP to ensure it accurately represents the organization’s current security posture.
Missing Supporting Evidence
An SSP should not exist in isolation. Security controls documented in the SSP should be supported by policies, procedures, screenshots, system configurations, logs, tickets, and other evidence that demonstrates the controls are operating effectively.
Unclear CUI Data Flows
Organizations often fail to document where CUI is stored, processed, or transmitted. Assessors need to understand how CUI moves through the environment and what protections are in place at each stage.
Incomplete System Inventory
Every in-scope asset should be identified and accounted for. Missing endpoints, servers, cloud services, or applications can create assessment findings and raise questions about the accuracy of the SSP.
Overlooking External Service Providers
Cloud providers, MSPs, MSSPs, and other third parties that support the environment should be documented. The SSP should clearly describe their role and how shared security responsibilities are managed.
Using Generic Template Language
Many organizations start with a template but never customize it to their environment. Generic descriptions that do not reflect actual systems, processes, and controls can undermine credibility during an assessment.
Download the Espresso Labs SSP Template
- Format: Microsoft Word (.docx) and Google Docs compatible
- Mapped To: NIST SP 800-171 Rev 2 / CMMC Level 2
- Includes: Control descriptions, evidence prompts, POA&M worksheet
- Maintained By: Espresso Labs compliance team, updated with regulatory changes