Building a System Security Plan That Passes a C3PAO Assessment
By Leonard Esere, Founder — AeoliTech
April 2026
Abstract
The System Security Plan (SSP) is the central artifact of every CMMC Level 2 certification assessment. It is the document that tells assessors what your environment looks like, how you have implemented each of the 110 NIST SP 800-171 Rev 2 security requirements, and where any remaining gaps are documented in a Plan of Action and Milestones (POA&M). A well-constructed SSP is not merely a compliance artifact — it is a technical record of your security posture that must withstand expert scrutiny from a Certified CMMC Assessor.
The gap between organizations that pass C3PAO assessments and those that accumulate findings is almost always found in the quality of the SSP, not the quality of the underlying security controls. A contractor can have MFA deployed, logs centralized, and network segmentation enforced — and still receive NOT MET findings because the SSP describes these controls vaguely, fails to map them to the specific assessment objectives in NIST SP 800-171A, or does not reference the evidence that demonstrates implementation.
This guide provides a comprehensive, practitioner-level methodology for SSP development. It covers the regulatory requirements for SSP content under 32 CFR Part 170, how to structure the document, what each control narrative must contain to satisfy NIST 800-171A assessment objectives, common SSP defects that generate findings, the relationship between the SSP and POA&M, version control practices, and a sample SSP outline that organizations can use as a starting template.
Table of Contents
1. The Legal Basis for the SSP
2. What the SSP Must Contain: 32 CFR Part 170 Requirements
3. NIST 800-171A and the Assessment Objective Framework
4. SSP Structure: The Recommended Outline
5. Writing Control Implementation Narratives That Pass Scrutiny
6. Evidence Mapping: Connecting Statements to Proof
7. Common SSP Defects and How to Avoid Them
8. The SSP-POA&M Relationship
9. Version Control and Document Governance
10. Roles and Ownership
11. About the Author
12. References
1. The Legal Basis for the SSP
The requirement for an SSP is not a best practice or an industry convention. It is a codified requirement in multiple regulatory instruments:
- NIST SP 800-171 Rev 2, Requirement 3.12.4: "Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems."
- 32 CFR § 170.x (CMMC Program Rule): The SSP is explicitly referenced as a prerequisite for CMMC assessment. Per the eCFR, "OSAs must have a System Security Plan (SSP) (CMMC security requirement CA.L2-3.12.4) in place at the time of assessment to describe each information system within the CMMC Assessment Scope."
- DFARS 252.204-7012: Contractors safeguarding covered defense information are required to have an SSP; it is the foundational document for any DoD cybersecurity assessment.
- DoD Assessment Methodology (for SPRS scoring): The methodology states explicitly: "If this plan is absent, the assessment cannot be conducted."
The SSP is not submitted to DoD — it is not emailed to a contracting officer and reviewed by a program manager. It is the document that C3PAO assessors examine in the field. Its accuracy is legally significant: the affirming official's attestation of CMMC status implicitly attests to the accuracy of the SSP on which the assessment was based.
2. What the SSP Must Contain: 32 CFR Part 170 Requirements
The CMMC Level 2 Assessment Guide (DoD CIO, Version 2.13) and the CMMC Scoping Guide define what the SSP must document. At minimum, the SSP must include:
System Description Components
| Component | Description |
|---|---|
| System name and identifier | Unique identifier for the information system(s) in scope |
| System owner and authorizing official | The individual(s) accountable for the system and CMMC certification |
| System purpose and functionality | What the system does and how it supports contract performance |
| System boundaries | The CMMC Assessment Scope — all in-scope assets per the five asset categories |
| Data types | CUI categories processed, stored, or transmitted, with NARA CUI Registry references |
| Operating environment | Description of the technical environment (cloud, on-premises, hybrid) |
| System interconnections | All connections to other systems, including external systems, cloud services, and ESPs |
| Network architecture | Network diagram reference and narrative description |
| Data flow | How CUI enters, moves through, and exits the system |
| Roles and responsibilities | All personnel roles with security responsibilities and their privileges |
Security Requirements Documentation
For each of the 110 NIST SP 800-171 Rev 2 requirements, the SSP must document:
- Implementation status (Implemented, Partially Implemented, Not Implemented, Not Applicable)
- Implementation narrative: how the requirement is satisfied in the specific system environment
- Responsible role or system component
- Evidence references: pointers to artifacts that demonstrate implementation
- For NOT MET items: reference to the POA&M entry
3. NIST 800-171A and the Assessment Objective Framework
Understanding NIST SP 800-171A is essential to writing an SSP that actually passes assessment. 800-171A is the companion assessment methodology to 800-171 — it takes each of the 110 requirements and expands them into 320 individual assessment objectives (also called determination statements). C3PAO assessors do not evaluate your SSP against the 110 high-level requirements; they evaluate it against the 320 assessment objectives.
Example: Expanding a Single Requirement
NIST SP 800-171 Rev 2 Requirement 3.5.3 (IA.L2-3.5.3):
> "Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts."
NIST SP 800-171A Rev 2 breaks this into multiple assessment objectives, including:
- [a] Multifactor authentication is implemented for local access to privileged accounts
- [b] Multifactor authentication is implemented for network access to privileged accounts
- [c] Multifactor authentication is implemented for network access to non-privileged accounts
An SSP implementation narrative that says "We use MFA" satisfies none of these objectives on its own. A narrative that says "Multi-factor authentication is enforced for all local console access to privileged accounts via [specific MFA solution], all remote access to privileged accounts via [VPN + MFA solution], and all network-authenticated access to non-privileged accounts via [specific policy configuration]" — with evidence references pointing to configuration screenshots and policy documents — satisfies all three objectives.
The Practical Rule
For every control in your SSP, review the corresponding assessment objectives in 800-171A Rev 2. Your narrative must address every applicable objective. If an objective does not apply to your environment (e.g., a requirement about local access to privileged accounts, but all privileged account access is remote), document why it is Not Applicable and the basis for that determination.
4. SSP Structure: The Recommended Outline
The following outline reflects the structure expected by C3PAO assessors and aligns with DoD CIO guidance, the CMMC Assessment Guide, and NIST SP 800-18 (Guide for Developing Security Plans):
`
1. Document Control
1.1 Version history
1.2 Document owner and approver
1.3 Distribution list and access controls
1.4 Review and update schedule
2. System Identification
2.1 System name and unique identifier
2.2 System owner, ISSO, and authorizing official
2.3 Assignment of responsibility for SSP maintenance
2.4 System status (operational, under development, major modification)
2.5 System categorization and sensitivity
3. System Description
3.1 System purpose and mission role
3.2 Types of users and privilege levels
3.3 Hardware inventory (servers, workstations, network devices)
3.4 Software inventory (OS, applications, security tools)
3.5 Network architecture narrative and diagram reference
3.6 Data types and CUI categories handled
3.7 Operating environment (on-premises, cloud, hybrid)
3.8 System interconnections (name, owner, interface type, data type exchanged)
4. CMMC Assessment Scope
4.1 Asset categorization table (CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, Out-of-Scope Assets)
4.2 CUI data flow description and diagram reference
4.3 Physical locations in scope
4.4 Personnel in scope (roles, not individuals)
5. Security Requirements Implementation
[For each of the 14 NIST SP 800-171 Rev 2 control families, organized by family:]
5.1 Access Control (AC) — Requirements 3.1.1 through 3.1.22
5.2 Awareness and Training (AT) — Requirements 3.2.1 through 3.2.3
5.3 Audit and Accountability (AU) — Requirements 3.3.1 through 3.3.9
[... through all 14 families ...]
[For each individual requirement:]
- Requirement number and title
- Implementation status
- Implementation narrative (how, where, who, with what tool or configuration)
- Responsible role
- Evidence artifacts (list with filenames or version references)
- POA&M reference (if not fully implemented)
6. Plans of Action and Milestones (POA&M) Summary
6.1 Overview of open POA&M items
6.2 Current SPRS score basis
6.3 POA&M closure schedule
7. External Service Providers and Cloud Services
7.1 ESP inventory with service description and CUI involvement
7.2 FedRAMP authorization status for CSPs
7.3 Customer Responsibility Matrix (CRM) references
8. Appendices
A. Network Architecture Diagram
B. CUI Data Flow Diagram
C. Asset Inventory
D. Interconnection Agreements (MOU/ISA)
E. Applicable Contracts and DFARS Clauses
F. Policy Document Index
`
5. Writing Control Implementation Narratives That Pass Scrutiny
The implementation narrative is the most important — and most often poorly written — element of an SSP. These guidelines apply to every control narrative in the document.
The Five Elements of a Strong Implementation Narrative
1. What is implemented: The specific technology, tool, configuration, or process that satisfies the requirement.
2. Where it is implemented: The specific systems, network segments, or locations where the control applies.
3. How it is configured: Sufficient technical detail that an assessor could verify the configuration without assistance from the SSP author.
4. Who is responsible: The role (not necessarily the named individual) responsible for implementing and maintaining the control.
5. What evidence exists: References to specific artifacts that demonstrate the control is in place.
Example: Weak vs. Strong Narrative
Requirement 3.3.1 (AU.L2-3.3.1): Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
Weak narrative (generates findings):
> "We log all system activity and retain logs for 90 days. Our SIEM collects logs from all systems."
Strong narrative (passes assessment):
> "Audit logging is enabled on all in-scope CUI assets including Windows servers ([list or reference to asset inventory]), Linux workstations, and network devices. Windows audit policy is configured via Group Policy Object [GPO name] to capture Security, System, and Application event logs. Linux systems forward syslog via rsyslog to the centralized SIEM. Network devices (Cisco ASA, Fortinet FortiGate) forward syslog via UDP/514 to the SIEM. The SIEM (Splunk Enterprise, version x.x, hosted on [server name]) retains logs for 90 days in hot storage and 12 months in cold storage on [storage system]. Log integrity is protected by [integrity control]. The IT Security team (ISSO role) reviews SIEM alerts daily per the Audit Log Review Procedure [reference]. Evidence: [SIEM screenshot showing log sources], [GPO export], [log retention policy document]."
The difference is specificity. Assessors are evaluating whether your implementation actually satisfies the assessment objectives in 800-171A. A vague narrative gives them nothing to evaluate and defaults to NOT MET.
Handling "Not Applicable" Determinations
Some requirements may genuinely not apply to your environment. A contractor with no portable storage devices in the CUI environment may have a strong basis for marking certain Media Protection controls as Not Applicable. However, "Not Applicable" must be documented:
- State the basis for the Not Applicable determination
- Describe the environmental or operational condition that renders the requirement inapplicable
- Reference any DoD CIO guidance or compensating approvals, if relevant
Assessors will scrutinize Not Applicable determinations. Unsupported or implausible Not Applicable designations generate findings.
6. Evidence Mapping: Connecting Statements to Proof
The evidence vault is the collection of artifacts that support every implementation narrative in the SSP. The SSP references evidence; it does not contain it. The evidence vault is organized separately and presented to assessors during the document review phase.
Evidence Types by Assessment Method
| Assessment Method | Evidence Type | Examples |
|---|---|---|
| Examine | Policy documents | Access control policy, IR plan, configuration management plan |
| Examine | Technical configurations | GPO exports, firewall rule exports, MFA configuration screenshots |
| Examine | Process records | Training completion records, vulnerability scan reports, patch logs |
| Examine | System documentation | Network diagrams, asset inventories, data flow diagrams |
| Interview | Personnel demonstrations | Walk-throughs of processes, incident response tabletop |
| Test | Technical verification | Live MFA challenge, network scan from non-CUI system, log query |
Evidence Vault Structure
Organize the evidence vault by control family and requirement number, mirroring the SSP structure:
`
/evidence-vault/
/AC-Access-Control/
/3.1.1/
- access-control-policy-v2.3.pdf
- ad-group-policy-export-2025-10.txt
- user-access-review-Q4-2025.xlsx
/3.1.2/
...
/AU-Audit-Accountability/
/3.3.1/
- siem-log-source-screenshot.png
- log-retention-policy-v1.1.pdf
- splunk-configuration-export.txt
`
Evidence Currency
Evidence must be current. An assessor who finds that the most recent vulnerability scan report in the evidence vault is 14 months old will question whether the vulnerability scanning requirement is actually being met on the required cadence. Collect fresh evidence within 30–60 days before the scheduled assessment.
7. Common SSP Defects and How to Avoid Them
Based on patterns across CMMC Level 2 assessments and parallel frameworks including FedRAMP and FISMA ATOs, the following defects are the most frequently observed:
Defect 1: Generic, Framework-Copied Language
Many organizations populate SSP templates with language copied directly from NIST 800-171 or the CMMC Assessment Guide. The narrative says what the control requires, not what the organization actually does. Assessors read dozens of SSPs; they recognize boilerplate immediately.
Fix: Write every narrative in the first person ("AeoliTech implements...") and describe specific technologies, configurations, and processes unique to your environment.
Defect 2: Missing Evidence References
Narratives claim implementation but provide no reference to evidence artifacts. The assessor cannot verify the claim.
Fix: Every narrative must conclude with a list of evidence artifacts: filename, version, and date.
Defect 3: Inconsistency Between SSP Sections
The network diagram shows three servers in the CUI enclave, but the asset inventory lists five. The SSP claims CUI is protected by a specific firewall, but the network diagram does not show it.
Fix: Cross-reference all SSP sections before submission. Contradictions generate findings even when the underlying implementation is sound.
Defect 4: Scope Mismatch
The SSP describes implementation for systems that are not in the documented CMMC Assessment Scope, or fails to document implementation for systems that are in scope.
Fix: Build the security requirements section from the asset inventory. Every in-scope asset must be addressed in every applicable control narrative.
Defect 5: POA&M Items Not Reflected in the SSP
A control is listed as "Implemented" in the SSP but there is an open POA&M item for the same control. This is a direct contradiction that raises credibility concerns.
Fix: For every control with an open POA&M item, the SSP status must reflect "Partially Implemented" or "Not Implemented" with a POA&M cross-reference.
Defect 6: Stale SSP
The SSP was written two years ago and has not been updated to reflect system changes: new servers, new cloud services, changes in personnel roles, new network segments. The SSP describes a system that no longer exists.
Fix: Implement a change management process that triggers SSP updates whenever in-scope systems change. Conduct a formal annual SSP review.
Defect 7: Vague Responsible Parties
"IT" or "management" is listed as responsible for dozens of controls. Assessors will ask who, specifically, is accountable for each control, and "the IT department" is not a satisfying answer.
Fix: Define specific roles (ISSO, System Administrator, Network Engineer, CISO) and assign each control to a named role. The SSP should include a roles and responsibilities table with contact information for each defined role.
8. The SSP-POA&M Relationship
The POA&M (Plan of Action and Milestones) is the companion document to the SSP. It tracks every security requirement that is not fully implemented at the time of assessment. The two documents must be tightly synchronized.
POA&M Requirements Under 32 CFR Part 170
| Element | Requirement |
|---|---|
| Item identification | Unique identifier for each not-met requirement |
| Requirement reference | NIST 800-171 Rev 2 requirement number |
| Description of weakness | Specific gap between required and current implementation |
| Resources required | Personnel, budget, tools needed to remediate |
| Scheduled completion date | Realistic milestone dates; must close within 180 days for conditional C3PAO certification |
| Responsible party | Named role accountable for remediation |
| Status | Current implementation status at time of last update |
| SPRS impact | Point value of the gap (1, 3, or 5 per DoD methodology) |
POA&M Eligibility Under CMMC
Not every control gap is POA&M-eligible for conditional CMMC Level 2 (C3PAO) status:
- The SPRS score at assessment must be ≥ 88 (gaps totaling ≤ 22 points may be in POA&M)
- Only 1-point controls may be in POA&M at time of conditional certification
- Controls weighted at 3 or 5 points — including MFA, FIPS-validated encryption, and incident reporting — must be fully implemented for conditional or final certification
- All POA&M items must close within 180 days; the C3PAO conducts a POA&M closeout assessment
SSP-POA&M Synchronization Checklist
- Every NOT MET item in the SSP has a corresponding POA&M entry with the same requirement number
- Every POA&M item has a corresponding SSP notation (status = Not Implemented or Partially Implemented)
- The SPRS score reflects the sum of all implemented controls minus deductions for all not-implemented controls
- POA&M completion dates are realistic based on available resources
9. Version Control and Document Governance
The SSP is a living document. It must be updated whenever the assessed system changes, and a version history must demonstrate that updates have been made on a defined schedule. Assessors review the version history; a document that has never been revised since its initial creation raises questions about whether it reflects the current system state.
Version Control Requirements
| Practice | Implementation |
|---|---|
| Version numbering | Semantic versioning (e.g., v2.1.3) with major versions for significant boundary changes, minor versions for control updates, patches for corrections |
| Change log | Each version documents what changed, who made the change, and why |
| Approval workflow | Changes must be reviewed by the ISSO and approved by the system owner or authorizing official before release |
| Storage and access control | SSP must be stored in a controlled location; access limited to personnel with need to know |
| Retention | Retain all versions for the duration of the CMMC certification period (3 years) plus any audit retention requirements |
| Distribution | Maintain a record of who has received current and prior versions |
Recommended Review Cadence
- Triggered reviews: Any significant system change, new contract with CUI requirements, change in external service providers, security incident affecting CUI systems
- Scheduled reviews: Annually at minimum, per NIST 800-171 Rev 2 requirement 3.12.4
10. Roles and Ownership
A common failure mode is an SSP with no clear ownership — documents written by a consultant and never internalized by the organization's staff. Assessors will ask personnel to describe how controls work. If employees say "that's in the SSP, but I don't really know how it works," the assessment goes poorly.
SSP Roles and Responsibilities
| Role | SSP Responsibility |
|---|---|
| System Owner | Overall accountability for SSP accuracy; authorizes significant changes; signs attestation |
| Information System Security Officer (ISSO) | Day-to-day SSP maintenance; coordinates evidence collection; manages POA&M |
| Information System Security Manager (ISSM) | Oversight of ISSO activities; reviews SSP completeness before assessment |
| System Administrator(s) | Provides implementation details for technical controls; maintains evidence artifacts |
| Network Engineer | Documents and maintains network architecture sections; provides firewall and segmentation evidence |
| IT Security Analyst | Monitors audit logs; maintains SIEM evidence; supports incident response documentation |
| Legal / Contracts | Ensures contract CUI requirements are accurately reflected in system description |
| Affirming Official | The senior company official who attests under penalty of law to CMMC compliance |
For small organizations where one person covers multiple roles, document which individual fulfills each role and ensure that person has the time and knowledge to support assessor interviews for their assigned controls.
My experience running full ATO programs — at Los Alamos National Laboratory and in other classified environments — established that the quality of the SSP is directly proportional to the degree to which the people writing it are the same people implementing the controls. An SSP written entirely by an external consultant and handed to an organization on the eve of an assessment is a liability, not an asset. Own your SSP.
About the Author
Leonard Esere is the Founder of AeoliTech, a cybersecurity and compliance advisory firm serving the Defense Industrial Base. Leonard brings DoD Secret and DoE Q clearances and direct experience developing ATOs and System Security Plans in classified and CUI environments, including Los Alamos National Laboratory and MITRE's CMMC-related work. He holds deep expertise in NIST RMF, FISMA, FedRAMP, and CMMC frameworks, and has guided organizations through assessments conducted by demanding government assessors and third-party auditors. He has seen what fails — and what passes.
References
1. NIST SP 800-171 Revision 2 — Protecting CUI in Nonfederal Systems and Organizations
2. NIST SP 800-171A Revision 2 — Assessing Security Requirements for CUI
3. 32 CFR Part 170 — CMMC Program Rule (eCFR)
4. CMMC Assessment Guide Level 2, Version 2.13 — DoD CIO
5. DoD CIO CMMC Documentation Page — Scoping Guides and Assessment Guides
6. NIST SP 800-18 — Guide for Developing Security Plans for Federal Information Systems
7. SPRS NIST SP 800-171 Assessment Module — DISA
8. Federal Register — CMMC Final Rule, October 15, 2024
9. Cyber AB — CMMC Ecosystem Overview and C3PAO Requirements
10. DFARS 252.204-7020 — NIST SP 800-171 DoD Assessment Requirements
> Need help building or reviewing your CMMC SSP?
>
> AeoliTech provides SSP development, gap-to-narrative mapping, evidence vault organization, and pre-assessment SSP review services — designed to produce documentation that passes C3PAO scrutiny the first time.
>
> - Schedule a CMMC Gap Assessment → /services/cmmc-gap-assessment