What Is a System Security Plan?
A System Security Plan (SSP) is a formal document that describes how an organization implements security controls to protect Controlled Unclassified Information (CUI). For CMMC Level 2, the SSP must address all 110 NIST SP 800-171 requirements — explaining exactly what your organization does, how it's implemented, who is responsible, and what evidence supports it.
The SSP is the primary documentation artifact in your C3PAO assessment. Assessors review it before arriving on-site and use it as their roadmap during the assessment. It tells them where to look, who to interview, and what evidence to request. A well-written SSP makes the assessment smoother and faster. A weak SSP creates doubt and generates additional scrutiny.
Required SSP Sections
A complete CMMC Level 2 SSP should contain these sections. 1TEN generates all nine automatically from your assessment data:
| # | Section | Content |
|---|---|---|
| 1 | Executive Summary | High-level description of the organization, assessment scope, and current compliance status including SPRS score. |
| 2 | System Identification | System name and description, CUI types processed, network diagram, system boundary definition, system interconnections. |
| 3 | Roles & Responsibilities | Key personnel with security responsibilities — ISSO, system owners, privileged users, and their security-relevant roles. |
| 4 | Tools & Technologies | Inventory of security-relevant tools, software, and systems used to satisfy requirements. Tied to specific controls. |
| 5 | Control Implementation | The core of the SSP — an implementation statement for every one of the 110 requirements, describing how the control is satisfied in your specific environment. |
| 6 | Training Program | Description of security awareness training — who receives it, frequency, content, completion tracking methodology. |
| 7 | Plan of Action & Milestones | Documentation of unmet requirements, root cause, planned remediation, responsible party, and target completion dates. |
| 8 | Evidence Index | Catalog of supporting evidence documents organized by requirement — policies, screenshots, logs, configuration exports. |
| 9 | Appendices | Acronyms list, reference documents (NIST publications, CMMC Assessment Guide), and supplementary materials. |
Writing Strong Implementation Statements
The implementation statements in Section 5 are the most critical part of your SSP. For each of the 110 requirements, your statement must clearly answer:
- What specifically does your organization do to satisfy this requirement?
- How is it implemented — what tools, processes, or configurations are in place?
- Who is responsible for this control?
- Where can evidence of this implementation be found?
Weak implementation statements use vague language like "we use industry best practices" or "management ensures compliance." Strong statements name specific tools, describe specific configurations, reference specific policies, and identify specific personnel.
Strong: "Aircraft Tubular Components implements MFA for all non-local access to systems within the CUI boundary using Cisco Duo Security. All 12 staff accounts require Duo push approval in addition to Active Directory password authentication before accessing any CUI system. MFA is enforced via Cisco Duo's policy engine with no bypass provisions. Configuration is documented in Duo Admin Console and Active Directory group policy."
How 1TEN Generates Your SSP
1TEN synthesizes data from multiple sources across the platform to generate each SSP section automatically:
- Control Implementation (Section 5) — generated from your requirement interview responses, selected tools, and documented implementation details
- Roles & Responsibilities (Section 3) — populated from personnel entered in your assessment and training records
- Tools & Technologies (Section 4) — assembled from tools selected during requirement documentation across all 14 domains
- Training Program (Section 6) — drawn from your Training Center completion records and course assignments
- POA&M (Section 7) — generated from requirements marked Not Met with linked POA&M items
The result is an SSP that reflects your actual environment, not a template filled with placeholder text. Export to Word or HTML for immediate use in your C3PAO assessment.
Common SSP Mistakes That Fail Assessments
C3PAO assessors review hundreds of SSPs. These are the patterns that consistently generate findings or force deeper investigation:
1. Vague implementation statements. Phrases like "we follow industry best practices" or "management ensures compliance" tell an assessor nothing. Every implementation statement must name specific tools, describe specific configurations, and reference specific policies.
2. Copy-pasted language across requirements. If your AC.L2-3.1.1 and AC.L2-3.1.2 statements read nearly identically, assessors assume neither is specific enough. Each of the 110 requirements has distinct objectives — your statements should reflect that.
3. No evidence index. An SSP without Section 8 (Evidence Index) forces assessors to ask for every artifact individually. This slows the assessment and creates the impression that evidence collection was an afterthought.
4. Tools listed without context. Stating "we use CrowdStrike" doesn't satisfy a requirement. Assessors want to know how it's configured, what it monitors, who reviews alerts, and how findings are acted on. The tool name is the starting point, not the answer.
5. SSP doesn't match reality. The biggest risk. If your SSP claims MFA is enforced everywhere but the assessor finds bypass provisions during testing, you've created a False Claims Act exposure and a NOT MET finding simultaneously.
How Long Should an SSP Be?
A thorough CMMC Level 2 SSP is typically 100–200+ pages. This isn't padding — it's a function of the content required. Each of the 110 requirements needs a specific implementation statement (typically a paragraph each), the system identification section requires network diagrams and boundary definitions, and the evidence index catalogs every supporting artifact.
If your SSP is under 50 pages, it's almost certainly lacking the specificity assessors require. If it's over 300, you may be including unnecessary detail that makes the document harder for assessors to navigate. The goal is comprehensive but focused — every page should serve a purpose.
Your SPRS score appears in the Executive Summary (Section 1), and your POA&M is Section 7. Both are among the first things assessors review.
More Weak vs. Strong Statement Examples
Strong: "User accounts are managed in Active Directory by the IT Administrator. New accounts require written approval from the department manager and the ISSO. Accounts are reviewed quarterly using the AD Users report — the last review was completed January 15, 2026. Terminated employee accounts are disabled within 24 hours per the Offboarding Checklist (HR-OB-001). Privileged accounts are limited to 2 IT staff and require separate credentials from standard user accounts."
Strong: "All CUI boundary systems forward logs to the Wazuh SIEM server (192.168.1.50). Windows Event Logs capture logon/logoff, privilege use, object access, and policy changes via GPO 'CUI-Audit-Policy.' Linux systems use auditd with rules targeting authentication, file access to /cui directories, and sudo usage. Logs are retained for 12 months on the SIEM and reviewed weekly by the IT Administrator using saved Wazuh dashboards. Alert rules trigger email notifications for failed login attempts exceeding 5 in 10 minutes."
Frequently Asked Questions
What is a System Security Plan?
A System Security Plan (SSP) is a document that describes how an organization's information system is configured and how security controls are implemented. For CMMC Level 2, the SSP must address all 110 NIST SP 800-171 requirements with specific implementation details for your environment.
Is an SSP required for CMMC certification?
Yes. The SSP is a mandatory artifact for CMMC Level 2. It is the primary document your C3PAO assessor reviews and is explicitly required by NIST SP 800-171 requirement CA.L2-3.12.4 (System Security Plan).
Can I use an SSP template?
You can start with a template for structure, but the implementation statements must be specific to your organization. Assessors immediately recognize generic template language and will probe harder during interviews when the SSP lacks specificity.
How often should the SSP be updated?
Your SSP should be updated whenever there is a significant change to your system boundary, security controls, personnel, or tools. At minimum, it should be reviewed annually. An outdated SSP that no longer reflects your environment creates assessment findings.
What format should the SSP be in?
C3PAO assessors typically expect Word or HTML format. The document should be clearly organized with a table of contents, consistent section numbering, and an evidence index that maps artifacts to specific requirements.