What Is a System Security Plan (SSP)? Structure, Sections, and Best Practices

In our experience, the System Security Plan is where most compliance programs either succeed or fail. Organizations that invest in a thorough, accurate SSP find that the rest of their compliance activities — assessments, audits, continuous monitoring — flow naturally. Those that treat the SSP as a paperwork exercise inevitably face painful assessment findings.

A System Security Plan (SSP) is the foundational document of any compliance program built on NIST standards. It provides a comprehensive description of an information system — its boundaries, components, data flows, users, and interconnections — along with detailed explanations of how the organization implements each required security control. For defense contractors subject to NIST 800-171 and CMMC, the SSP is the single most important compliance artifact. For FedRAMP cloud service providers, it forms the core of the security authorization package. And for organizations subject to FISMA, it is the basis for their Authority to Operate.

This guide explains what an SSP contains, why each section matters, how assessors use it during evaluations, and best practices for creating and maintaining an SSP that accurately reflects your security posture.

Why the SSP Matters

The SSP serves multiple critical purposes beyond simply satisfying a documentation requirement.

Assessment Foundation

For CMMC Level 2 and Level 3 assessments, the SSP is the starting point for every assessor. Before they examine any technical evidence, assessors read the SSP to understand your environment — what systems are in scope, how data flows through them, and how you claim to implement each control. If the SSP is incomplete, inaccurate, or vague, the assessment starts with a credibility deficit that is difficult to overcome.

Operational Reference

A well-maintained SSP serves as the authoritative reference for how security controls operate in your environment. When a new team member needs to understand the access control process, when an incident responder needs to know which systems process CUI, or when a system administrator needs to verify logging requirements, the SSP provides the answer.

Regulatory Requirement

The SSP is explicitly required by:

• NIST 800-171 — 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"
• CMMC — Assessed as part of the Security Assessment (CA) domain
• FedRAMP — Core component of the security authorization package
• FISMA — Required for all federal information systems and the basis for ATO decisions

For a comprehensive guide to NIST 800-171 controls, see our NIST 800-171 compliance guide.

Key Sections of a System Security Plan

While the exact structure varies depending on the framework and template used, every SSP should contain the following major sections.

System Identification and Overview

This section introduces the information system and provides context for everything that follows.

Element	Description	Example
System name	Official name of the information system	"CUI Processing Environment"
System identifier	Unique identifier for tracking	"CPE-001"
System owner	Individual with authority over the system	Chief Information Officer
ISSO	Information System Security Officer	Director of Security
Operational status	Current lifecycle phase	Operational
System description	Narrative overview of system purpose and functions	"Cloud-based engineering environment used to process, store, and transmit CUI under DoD contracts..."
Information types	Categories of information processed	CUI — Controlled Technical Information, CUI — Export Controlled

System Boundary

The system boundary definition is arguably the most critical section of the SSP because it determines the scope of your compliance obligations. Everything inside the boundary must comply with the applicable security controls. Everything outside the boundary is excluded.

A well-defined system boundary includes:

• Hardware inventory — Servers, workstations, laptops, network devices, mobile devices within the boundary
• Software inventory — Operating systems, applications, middleware, databases, and cloud services within scope
• Network boundary — IP address ranges, VLANs, cloud VPCs, and network segments that comprise the system
• Cloud services — Specific cloud provider accounts, subscriptions, and services included in the boundary (e.g., "AWS Account 123456789012, us-east-1 region, EC2, S3, RDS, and Lambda services")
• Physical locations — Offices, data centers, and remote work locations where system components operate

What to Include vs Exclude

Defining the boundary requires balancing completeness with practicality. What we tell clients:

Include in the boundary:

• Any system that processes, stores, or transmits CUI
• Systems that provide security protections for CUI systems (e.g., a SIEM that monitors CUI systems)
• Network segments that carry CUI traffic
• Endpoints used to access CUI systems

Exclude from the boundary (with justification):

• Corporate systems that never touch CUI (HR systems, marketing tools) if properly segmented
• Guest WiFi networks with no access to CUI systems
• Development environments that use only synthetic data

The key is documentation. If a system is excluded from the boundary, the SSP should explain why and describe the controls that prevent CUI from reaching that system.

Data Flow Diagrams

Data flow diagrams visually represent how information moves through the system. Assessors use these diagrams to verify that all data paths are protected and that CUI does not flow to unprotected systems.

Effective data flow diagrams show:

• Data sources — Where CUI enters the system (email from DoD, file transfers, API integrations)
• Processing nodes — Systems that transform or process CUI
• Storage locations — Databases, file shares, cloud storage where CUI resides at rest
• Transmission paths — Network connections, encrypted tunnels, API calls between components
• Data exits — How CUI leaves the system (deliverables to the government, transfers to subcontractors)
• Encryption status — Whether each transmission path and storage location uses encryption

Network Architecture Diagrams

Network architecture diagrams complement data flow diagrams by showing the technical infrastructure:

• Network topology — Subnets, VLANs, VPCs, and their interconnections
• Security boundaries — Firewalls, security groups, network access control lists
• External connections — Internet gateways, VPN concentrators, dedicated links to partners
• Security appliances — IDS/IPS, web application firewalls, proxy servers
• Management networks — Separate management planes for infrastructure administration

Authorization Boundary Diagram

The authorization boundary diagram combines elements of data flow and network diagrams into a single view that clearly delineates what is inside and outside the system boundary. This diagram is particularly important for FedRAMP authorizations where the boundary between the CSP's responsibilities and the customer's responsibilities must be unambiguous.

Control Implementation Descriptions

The control implementation section is the largest portion of the SSP, typically consuming 60-70% of the document. For each required control, the SSP must describe:

• How the control is implemented — Specific, detailed description of the implementation, not a restatement of the control requirement
• Who is responsible — Roles responsible for implementing and maintaining the control
• What tools or technologies are used — Specific products, configurations, and settings
• Implementation status — Fully implemented, partially implemented, planned, or not applicable
• Shared responsibility — For cloud environments, which aspects the cloud provider handles versus the organization

Writing Effective Control Descriptions

Poor control implementation descriptions are the most common SSP weakness we see. Here is the difference between a weak and strong description:

Weak (restates the requirement):

"The organization employs multi-factor authentication for network access to privileged accounts."

Strong (describes actual implementation):

"All privileged accounts (domain administrators, database administrators, cloud infrastructure administrators) are required to authenticate using Okta MFA with phishing-resistant FIDO2 hardware security keys. MFA is enforced through Okta conditional access policies that block authentication attempts without a second factor. The policy (Policy ID: MFA-PRIV-001) is configured to require MFA for every authentication event, with no trusted device exceptions for privileged accounts. Compliance is monitored through weekly Okta admin reports reviewed by the ISSO, with non-compliant accounts disabled within 24 hours of detection."

The strong description tells the assessor exactly what is deployed, how it is configured, and how compliance is monitored. This level of detail enables the assessor to verify the implementation rather than simply accepting a vague claim.

Roles and Responsibilities

This section defines the security roles within the organization and their responsibilities relative to the information system:

• System Owner — Authority over the system, accountable for risk acceptance decisions
• ISSO (Information System Security Officer) — Day-to-day security management, SSP maintenance, POA&M tracking
• ISSM (Information System Security Manager) — Oversight of the security program, policy enforcement
• System Administrator — Technical implementation and maintenance of system components
• Users — Employees and contractors who use the system, their security responsibilities
• Authorizing Official — Individual who accepts the risk of operating the system (primarily in federal and FedRAMP contexts)

Interconnections

The interconnections section documents all connections between your system and external systems. For each interconnection:

Field	Description
Connected system name	Name of the external system
Connected system owner	Organization that owns the external system
Connection type	VPN, API, SFTP, dedicated circuit, internet
Data exchanged	What information crosses the boundary
Security protections	Encryption, authentication, access controls on the connection
Agreement type	Interconnection Security Agreement (ISA), MOU, or contractual agreement

Continuous Monitoring Strategy

The SSP should describe how the organization maintains ongoing awareness of its security posture:

• Vulnerability scanning — Frequency, tools, scope, and remediation timelines
• Configuration monitoring — How baseline configurations are verified and drift detected
• Log monitoring — What events are logged, how logs are reviewed, and alerting thresholds
• Access review — Frequency and process for reviewing user access rights
• Assessment schedule — Planned self-assessments and third-party assessments

Framework-Specific SSP Requirements

NIST 800-171 / CMMC SSP

For CMMC assessments, the SSP must address all 110 NIST 800-171 controls across 14 families. The DoD provides an SSP template (NIST SP 800-171A Appendix D) that many organizations use as a starting point. Key CMMC-specific considerations:

• Every control must have a detailed implementation description, not just "implemented" or "not implemented"
• The SSP must clearly define the CUI boundary and how CUI is identified and marked
• Controls that are not fully implemented must have corresponding entries in the POA&M
• The SSP must be version-controlled with evidence of periodic review

For complete CMMC requirements, see our CMMC requirements guide.

FedRAMP SSP

FedRAMP SSPs are based on the NIST 800-53 control catalog and follow a specific template provided by the FedRAMP PMO. The FedRAMP SSP is significantly more detailed than a NIST 800-171 SSP because:

• It must address a larger number of controls (156 for Low, 325 for Moderate, 421 for High)
• It requires detailed descriptions of the shared responsibility model between CSP and customer
• It must include a complete inventory of all system components with their security configurations
• The authorization boundary must clearly delineate the CSP's responsibility from customer responsibilities

RMF / FISMA SSP

For federal information systems governed by the Risk Management Framework, the SSP follows NIST 800-18 guidelines and supports the Authorization to Operate (ATO) process. The RMF SSP is the most detailed variant, requiring:

• System categorization per FIPS 199
• Control selection from NIST 800-53 based on categorization
• Detailed implementation descriptions for all selected controls
• Risk assessment integration
• Continuous monitoring strategy aligned with NIST 800-137

SSP Maintenance Best Practices

An SSP is only valuable if it accurately reflects the current state of the system. Stale SSPs are worse than no SSP because they create a false sense of compliance.

Triggers for SSP Updates

Update the SSP when any of the following occur:

• System changes — New hardware, software, cloud services, or network segments added or removed
• Control changes — New security tools deployed, existing tools reconfigured, processes modified
• Organizational changes — New roles, responsibilities reassigned, personnel changes in key security positions
• Boundary changes — Systems added to or removed from the compliance boundary
• Regulatory changes — New requirements, updated framework versions, or changed compliance obligations
• Assessment findings — Assessor recommendations or findings that require SSP modifications
• Scheduled review — At minimum, annual comprehensive review regardless of changes

Version Control

Maintain strict version control for the SSP:

• Use a document management system or version-controlled repository (not loose files on a shared drive)
• Record the date, author, and description of every change
• Maintain a revision history table at the beginning of the document
• Require formal approval for substantive changes
• Keep previous versions accessible for audit trail purposes

Review Process

Establish a regular review cadence:

• Monthly: ISSO reviews for accuracy against recent changes
• Quarterly: Control owners verify their respective sections
• Annually: Comprehensive review with formal re-approval by the System Owner
• Event-driven: Immediate review after significant incidents, major system changes, or assessment findings

Common SSP Mistakes

Copying template language verbatim. Assessors can immediately tell when control descriptions are copied from a template rather than describing your actual implementation. Every description should be specific to your environment.

Undefined or overly broad boundaries. An SSP that defines the boundary as "the entire corporate network" creates unnecessary compliance scope. Conversely, an SSP that excludes systems that clearly handle CUI will face assessment challenges.

Missing interconnections. Organizations frequently forget to document connections to SaaS platforms, cloud services, or partner systems that handle CUI. If CUI flows through it, it needs to be in the SSP.

Stale content. An SSP that describes last year's infrastructure while current systems have changed significantly undermines credibility. Assessors check for consistency between the SSP and the actual environment.

Inconsistency with other documents. The SSP, POA&M, and risk assessment must be internally consistent. If the SSP says a control is fully implemented, there should not be a POA&M entry for the same control.