How to Write a System Security Plan (SSP) for CMMC Level 2: A Step-by-Step Guide
March 20, 2026 · 14 min read
Your System Security Plan is arguably the single most important document in your CMMC Level 2 assessment. It’s the roadmap that tells assessors exactly how your organization implements each of the 110 NIST SP 800-171 security requirements. A well-written SSP can make the difference between passing and failing your C3PAO assessment — and yet, it’s the document most contractors struggle with the most.
What Is a System Security Plan?
A System Security Plan (SSP) is a formal document that describes how an organization implements its security controls. For CMMC Level 2, the SSP must address all 110 security requirements in NIST SP 800-171 Rev 2, organized across 14 control families.
Think of it as a comprehensive blueprint of your security environment — it describes your system boundaries, the people and technology involved, and specifically how each requirement is satisfied within your organization.
Essential SSP Components
Every CMMC Level 2 SSP should include the following sections:
1. System Identification
Name of the information system, system owner, authorizing official, and other key personnel. Include a unique system identifier and the date of the most recent revision.
2. System Description & Purpose
A narrative describing what the system does, what types of CUI it processes/stores/transmits, and which DoD contracts it supports. Be specific about the business function.
3. System Boundary & Architecture
Define what’s in scope. Include a network architecture diagram showing how CUI flows through your environment — servers, workstations, network devices, cloud services, and connections to external systems.
4. CUI Data Flow
Map where CUI enters your system, how it moves between components, where it’s stored, and how it exits. Include both digital and physical data flows (email, file shares, printed documents, removable media).
5. Roles & Responsibilities
Identify all personnel with security roles: system administrator, ISSO, ISSM, security awareness trainer, incident response lead. Define their specific responsibilities.
6. Control Implementation Descriptions (The Core)
For each of the 110 NIST SP 800-171 requirements, describe HOW your organization implements that control. This is where most of your SSP content lives. Be specific — name the tools, configurations, and procedures you use.
Writing Effective Control Descriptions
The control implementation section is where assessors spend 90% of their time. Here’s how to write descriptions that demonstrate compliance:
The “Who, What, How, When” Framework
For every control, answer these four questions:
Who is responsible for implementing and maintaining this control?
What technology, policy, or procedure is used to satisfy the requirement?
How does it work in your specific environment?
When is it applied? (Continuously, daily, quarterly, on specific triggers?)
Example: Access Control (AC.L2-3.1.1)
Requirement: Limit system access to authorized users, processes, and devices.
Good implementation description: “Access to the CUI environment is managed through Microsoft Active Directory (AD) and Azure AD. All user accounts require approval by the IT Director and the employee’s direct manager before provisioning. Accounts are created based on role-based access control (RBAC) groups defined in the Access Control Policy (ACP-001). Multi-factor authentication via Microsoft Authenticator is enforced for all users accessing the CUI environment. Inactive accounts are automatically disabled after 30 days by a scheduled PowerShell script. Access reviews are conducted quarterly by the ISSO using the Account Review Checklist (form AC-01).”
The 14 Control Families You Must Address
Top 5 SSP Mistakes to Avoid
1. Copy-paste boilerplate without customization. Assessors can immediately spot generic templates. Every description must reflect YOUR actual environment and procedures.
2. Describing what you plan to do instead of what you actually do. The SSP documents current implementation. Future plans belong in the POA&M.
3. Missing or inaccurate network diagrams. Your architecture diagram must match reality. Outdated diagrams raise red flags.
4. Incomplete CUI scoping. Failing to identify all systems that touch CUI means your SSP doesn’t cover your full environment.
5. No evidence mapping. For each control, you should have corresponding evidence (screenshots, policy documents, logs) that backs up your description.
How Long Should an SSP Be?
There’s no magic number, but a thorough CMMC Level 2 SSP typically runs between 150-300 pages. Quality matters more than quantity. Each control description should be detailed enough that someone unfamiliar with your organization could understand how the requirement is met. At minimum, aim for 3-5 sentences per control — but complex controls like multi-factor authentication or audit logging may require a full page each.
Need SSP Templates?
Our CMMC Complete Toolkit includes a professionally-written SSP template with example content for all 110 controls.