System Security Plan (SSP) Guide
Your SSP is the single most important document for CMMC Level 2 assessment. It describes your security boundary, how each of the 110 controls is implemented, and who is responsible.
The Foundation
What is a System Security Plan?
Understanding the purpose, scope, and role of the SSP in your compliance program
A System Security Plan (SSP) is the master document that describes how your organization protects Controlled Unclassified Information (CUI). It's not a policy — policies define governance (what you shall do). The SSP is an implementation document (how you actually do it, on which specific systems, with which specific tools).
For CMMC Level 2, your SSP must address all 110 NIST SP 800-171 Rev 2 controls. For each control, you write a narrative explaining how you've implemented it in your specific environment. Generic statements like "we encrypt data" won't pass — assessors want specifics.
The SSP is a living document. It must be reviewed annually, updated whenever your environment changes, and stored securely (the SSP itself contains sensitive security architecture details and should be treated as CUI).
Who Needs an SSP?
- ● Level 2 (CUI): Comprehensive SSP covering all 110 controls. Required for C3PAO assessment.
- ● Level 1 (FCI): Simplified SSP covering 15 foundational controls. Used for self-assessment.
Assessor Tip
C3PAO assessors read your SSP before they arrive on site. A well-written SSP reduces the number of questions and clarifications needed during the assessment, saving you time and money.
Understanding the Relationship
SSP vs. Policies vs. Evidence
Three distinct document types that work together to demonstrate compliance
Policies
Governance documents that define what your organization shall do. High-level rules and requirements.
15 policies covering all 14 NIST domains
View Policies →SSP
Implementation document that describes how you actually implement each control, on which systems, using which tools.
1 SSP with 110 control narratives
Evidence
Artifacts that prove your policies and SSP narratives are real. Screenshots, logs, exports, configuration files.
Collected per control during assessment
Evidence examples per control →Document Outline
SSP Structure — Section by Section
A complete CMMC Level 2 SSP follows this structure. Section 7 (Control Narratives) is the bulk of the document.
System Identification
System name, unique identifier, system owner, ISSO, operational status, and authorization date.
System Description
What the system does, business functions supported, general architecture, and why it processes CUI.
System Boundary
Network diagram showing all in-scope components: servers, workstations, cloud services, network devices, and enclave boundaries. This defines what the assessor evaluates.
Data Flow Diagram
How CUI enters, moves through, and exits the system. Storage locations, transmission paths, processing points, and encryption at each stage.
System Interconnections
External systems, APIs, SaaS platforms, and third-party services. Include ISAs/MOUs for each external connection.
Applicable Laws & Regulations
DFARS 252.204-7012, NIST SP 800-171 Rev 2, ITAR (if applicable), state breach notification laws, and contract-specific requirements.
Security Control Narratives — 110 Controls
This is the core of your SSP and typically 80% of the document. For each of the 110 NIST 800-171 controls, you provide: implementation status, a specific narrative, responsible parties, and supporting evidence references. Our practice pages include SSP guidance for every control.
POA&M
For each control not fully implemented: gap description, risk level, planned remediation, milestone dates, and responsible party.
Roles & Responsibilities
System Owner, ISSO, ISSM, system administrators, and users. Include names, titles, and specific security responsibilities.
The Hard Part
Writing SSP Control Narratives
Each of the 110 controls needs a narrative. Here's what makes a good one.
Every Narrative Must Include
Implemented, Partially Implemented, Planned, or Not Applicable (with justification)
Specific tools, configurations, processes, and settings. Name names.
Role or name of the person maintaining this control
The specific systems, networks, or enclaves this applies to
What artifacts prove this control is working (screenshots, logs, exports)
Example Narrative
Control CUI Flow
Status: Implemented. CUI flow is controlled using Microsoft Purview Data Loss Prevention (DLP) policies applied to Exchange Online, SharePoint Online, and Teams. DLP policies detect and block CUI based on sensitivity labels (CUI, CUI//SP-CTI) applied by users or auto-classification rules. Outbound email containing CUI is encrypted using Office Message Encryption. USB storage is blocked on all managed endpoints via Intune Device Configuration Profile "Block USB Storage". Quarterly DLP incident reports are reviewed by the IT Security Manager. Evidence: DLP policy configuration export, sensitivity label settings, Intune device configuration profile, DLP incident report (Q4 2025).
Tip: Each of our 110 practice pages includes tailored SSP narrative guidance with examples for cloud, on-prem, and hybrid environments.
By Domain
SSP Controls Across 14 Domains
Click a domain to explore its controls and find SSP guidance for each one
Avoid These
5 Most Common SSP Mistakes
Issues that cause delays, findings, or failed assessments
Generic Narratives
Writing "We use encryption" instead of "We use BitLocker with TPM 2.0 on all Windows 11 endpoints, enforced via Intune compliance policy 'Require Encryption'." Assessors will ask for specifics anyway.
Stale System Boundary
Boundary diagram doesn't reflect current architecture. New cloud services added after the SSP was written. A single missing system can invalidate your entire assessment scope.
Empty POA&M
Gaps identified but no remediation timeline or responsible party assigned. POA&M must be actively maintained — stale milestones are a red flag for assessors.
SSP Not Treated as CUI
Your SSP describes your security architecture in detail — it's sensitive. Store it encrypted, limit access, and apply the same CUI handling procedures to the SSP itself.
No Version Control
SSP must be reviewed annually at minimum. Include version number, last review date, next review date, and a change log. Environment changes trigger immediate updates.
Pro Tip
Write your SSP in a tool that supports version control (Git, SharePoint with versioning, etc.). Keep it in markdown or a structured format — Word documents become unwieldy at 100+ pages.
Ready to Build Your SSP?
Start by exploring our practice pages — each one includes SSP narrative guidance tailored to that specific control. Then download the SSP template to structure your document.