System Security Plan (SSP) Outline

Structured outline for a NIST SP 800-171 compliant System Security Plan. The SSP is the single most important document for CMMC assessment.

The SSP is typically the first document a C3PAO assessor requests. An incomplete or inaccurate SSP is one of the most common reasons organizations fail CMMC assessments. Invest the time to make it thorough and keep it current.

The outline: 8 major sections, 52 subsections to complete.

1. System Identification

Basic identification of the system and its purpose.

• System name and unique identifier
• System categorization (Moderate for CUI)
• System owner name, title, and contact
• Authorizing official name, title, and contact
• System operational status (Operational / Under Development / Major Modification)
• General system description and mission/business purpose

2. System Environment

Where the system operates and what it connects to.

• Physical locations (data centers, offices, cloud regions)
• Cloud service providers and FedRAMP authorization level
• GCC High / IL4+ environment details (if applicable)
• Network architecture (VLANs, subnets, DMZ)
• System interconnection table (external systems, ISAs/MOUs)
• Ports, protocols, and services in use

3. System Boundary

Defines exactly what is in scope for the assessment.

• Authorization boundary diagram (network topology with all components)
• Hardware inventory (servers, workstations, network devices, mobile devices)
• Software inventory (OS, applications, security tools, databases)
• CUI data flow diagram - showing where CUI enters, is processed, stored, and exits
• Boundary justification - why specific components are included/excluded
• Shared services and inherited controls documentation

4. CUI Data Types & Handling

What types of CUI the system processes and how.

• CUI categories and subcategories handled (per NARA CUI Registry)
• CUI marking requirements and procedures
• CUI handling procedures (creation, storage, transmission, destruction)
• CUI access authorization process
• Data retention and disposal requirements
• FCI vs CUI delineation (if system handles both)

5. Personnel & Roles

Who has access and what their security responsibilities are.

• User categories and privilege levels (admin, privileged user, general user)
• Security roles and responsibilities (ISSO, ISSM, System Admin, etc.)
• Personnel screening requirements
• Access authorization process
• Training requirements by role
• Third-party / contractor access policies

6. Control Implementation Narratives

The core of the SSP - how each NIST SP 800-171 control is implemented.

• One narrative per control (110 for Rev 2 / 97 for Rev 3)
• Implementation status: Implemented / Partially Implemented / Planned / Not Applicable
• Describe HOW the control is implemented (technology, process, policy)
• Identify responsible role/team for each control
• Reference supporting policies and procedures by document name and section
• For shared/inherited controls, identify the provider and agreement
• For "Not Applicable" controls, provide documented justification

7. Continuous Monitoring

How the organization maintains security posture over time.

• Ongoing assessment schedule and methodology
• Vulnerability management program (scanning frequency, remediation SLAs)
• Configuration monitoring and change control
• Audit log review procedures and frequency
• POA&M management process and review cadence
• SSP review and update schedule (at least annually)
• Incident detection and response capabilities

8. Attachments & References

Supporting documents referenced throughout the SSP.

• Network architecture diagram (high-resolution)
• CUI data flow diagram
• Hardware and software inventory (can reference CM tool exports)
• Interconnection Security Agreements (ISAs)
• POA&M (current version)
• Policy and procedure documents (referenced by control narratives)
• Previous assessment reports
• ATO/authorization letters

SSP Writing Tips

• Be specific, not generic. "We use access controls" fails. "Access to CUI is enforced via Azure AD Conditional Access policies requiring MFA, compliant device, and group membership in SG-CUI-Users" passes.
• Name the technology. Assessors want product names, versions, and configuration details. Generic references to "our firewall" aren't sufficient.
• Reference supporting docs. Every control narrative should point to the specific policy, procedure, or configuration that implements it.
• Keep diagrams current. The #1 assessor complaint is boundary diagrams that don't match reality. Update them every time infrastructure changes.
• Version control the SSP. Maintain a revision history table. Assessors want to see that the document is actively maintained, not written once and forgotten.

The Suite complements your SSP: the pre-assessment workbook tracks control-by-control implementation status for Section 6, and the template library populates the policies and procedures the SSP references. CMMC Operator publishes documentation templates and planning resources for informational purposes only; nothing here is a compliance determination.

Get the matching CMMC template

Use the CMMC Operator template library to move from checklist items to working policy, procedure, SSP, and POA&M documentation.

Browse CMMC templates