System Security Plan Writing Guide

The System Security Plan (SSP) describes the system being secured and how each applicable security control is implemented. It is the primary document the assessor reads cover-to-cover. For CMMC Level 2, the SSP covers the 110 NIST 800-171 practices. For FedRAMP, it covers 125-421 NIST 800-53 controls depending on impact level.

SSP structure typically includes:

• System identification (name, owner, type, status)
• System description and architecture
• System boundary and authorization boundary
• Roles and responsibilities
• Information types and data flows
• Control implementation narratives (one per control)
• Appendices: diagrams, policies, agreements

SSP page count: 200-400 pages for CMMC Level 2; 800-1500 pages for FedRAMP Moderate. The control narratives drive the page count. Cross-reference the documentation module for SSP templates and patterns.

The system description sets the context for everything that follows. A weak description leads to confused assessors and poorly-targeted control narratives.

Strong system description includes:

• Purpose: What does the system do? Who uses it? For what?
• Architecture: How is the system constructed? Cloud-native, hybrid, on-premises?
• Components: What are the major subsystems and how do they interact?
• Boundary: What is in scope? What is explicitly out of scope?
• Interfaces: How does the system communicate externally?
• Data flows: How does sensitive data move through the system?
• Users and roles: Who has access and at what privilege levels?
• Hosting environment: Where does the system run? Which cloud providers, regions, accounts?

Include diagrams: high-level architecture, data flow, authorization boundary, network topology. Diagrams should match the prose; inconsistencies are red flags.

Each control gets a narrative. The narrative must address every assessment objective for that control. Vague narratives fail; specific narratives pass.

Effective control narrative structure:

1. Restate the control: What does the control require?
2. Implementation summary: How does the system meet the requirement?
3. Specific implementation details: What systems, configurations, or processes operate the control?
4. Evidence: What artifacts prove operation?
5. Roles: Who is responsible for the control?

Strong narrative example for an MFA control:

The system enforces multi-factor authentication for all privileged access through Okta Identity Cloud. The MFA policy requires possession factor (TOTP authenticator app or hardware security key) for all admin role members across production environments. Configuration is enforced via Okta sign-on policy applied to the production AD group. Compliance is monitored through the daily Okta usage report which flags any privileged login without MFA factor. The Identity team reviews exceptions weekly and tracks them in Jira issue ID-MFA. Evidence: Okta sign-on policy export, daily MFA report sample, privileged role membership export.

Five mistakes that consistently appear in weak SSPs:

1. Restating the control without describing implementation: "The organization implements multi-factor authentication" tells the assessor nothing about how.
2. Listing controls without specificity: "We use Okta for identity" without describing the configuration, policy, and enforcement.
3. Inconsistency with evidence: SSP says one thing, evidence shows another. Assessors compare.
4. Boilerplate language: Same paragraph reused across multiple controls signals copy-paste rather than actual implementation analysis.
5. Missing role assignments: Control narratives without identified owners cannot be operated.

Strong narratives are specific to your environment, traceable to evidence, and consistent with the actual implementation. They take time to write but pay back in audit speed and quality.

The SSP is not a one-time deliverable. Maintain it through:

• Quarterly review: Walk through changes since last review. Update narratives that no longer reflect current state.
• Change-driven updates: Significant system changes (new components, new data types, architecture changes) trigger SSP updates within 30 days
• Annual full review: Read the SSP cover-to-cover. Catch drift that quarterly reviews missed.
• Pre-audit refresh: 60-90 days before each audit, refresh the SSP to current state. Capture remediations completed since last audit.
• Version control: Track SSP versions with date, change summary, approver. Make older versions accessible for trend analysis.

An SSP from 18 months ago that has not been touched is a finding waiting to happen. Build SSP maintenance into the security operations cadence so updates happen continuously rather than as a panic before audit.