Download a System Security Plan (SSP)
Your SSP is the foundation of CMMC compliance. Here’s what it is, what it must contain, and how to get started.
What Is A System Security Plan (SSP)
A System Security Plan (SSP) is a formal document that describes how your organization implements the security requirements in NIST SP 800-171. It’s the primary artifact assessors review during a C3PAO assessment, and it must accurately reflect your actual security posture.
1
Define Scope & Boundary
2
Inventory CUI
3
Document Controls
4
Identify Gaps (POA&M)
5
Maintain & Update
SSP vs. Plan of Actions & Milestones (POA&M)
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 versino 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
| Writing aspirational controls | Describe what you actually do, not what you plan to do. Assessors verify against reality. |
| Scope too broad or too narrow | Broad scope inflates your attack surface. Narrow scope creates assessment failures. |
| No version control | Your SSP must be a living document with dated revisions and change history. |
| Missing supporting evidence | Controls need artifacts: screenshots, configurations, policies, and logs. |
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, and updated with regulatory changes
Ready to Get Started?
Your SSP is the first thing a C3PAO assessor asks for. Make sure it is ready and accurate. Espresso Labs builds and maintains SSPs as part of every managed compliance engagement.