SYSTEM SECURITY PLAN TEMPLATE

System Boundary · Authorization Context · Control Implementation · Inheritance · Evidence Index

Table of Contents

1. Purpose and Use
2. Template Instructions
3. SSP Cover Page
4. System Boundary
5. System Environment
6. CUI Data Flow
7. Roles and Responsibilities
8. Control Implementation Matrix
9. Inherited Controls
10. External Providers and Interconnections
11. Open Items and POA&M Linkage
12. Evidence Index
13. Approval and Maintenance
14. Document Control

1. Purpose and Use

This template creates a System Security Plan (SSP) for a system that stores, processes, transmits, or protects Controlled Unclassified Information (CUI). It is designed to be copied into a system-specific artifact and completed by the system owner, technical owners, and CMMC / Federal Compliance Manager.

The SSP explains the system boundary, CUI data flow, implemented security controls, inherited controls, external dependencies, open gaps, and evidence locations. It supports CMMC readiness, federal customer assurance, and internal authorization decisions.

An SSP Is a Control Story, Not a Form Dump

A useful SSP tells a reviewer what the system is, where CUI moves, which controls protect it, which controls are inherited, where the evidence lives, and what remains unfinished. If a control answer cannot be tied to evidence or a POA&M item, the SSP is not ready.

2. Template Instructions

1. Copy this template and rename the copy for the specific system.
2. Replace bracketed fields such as [System Name] with system-specific content.
3. Do not delete sections that are not applicable. Mark them Not Applicable and explain why.
4. Use asset IDs from CERG-STD-AM-001 wherever possible.
5. Link all open control gaps to CERG-TMPL-CUI-002 POA&M entries.
6. Link material residual risks to CERG-PRC-RM-001 risk-register entries.
7. Store evidence in the evidence library governed by CERG-PRC-AUD-001.
8. Review the completed SSP annually and when the system boundary changes.

3. SSP Cover Page

4. System Boundary

4.1 Boundary Narrative

Describe the system boundary in plain language.

[Insert system boundary narrative. Include major components, users, locations, cloud accounts, network zones, and excluded components.]

4.2 Boundary Components

4.3 Boundary Exclusions

5. System Environment

6. CUI Data Flow

6.1 Data Categories

6.2 Data Flow Narrative

[Describe how CUI enters, moves through, exits, and is retained or deleted from the system.]

6.3 Data Flow Diagram Reference

7. Roles and Responsibilities

Use canonical CERG roles from CERG-GOV-OM-001.

8. Control Implementation Matrix

Create one row per applicable requirement or control.

Implementation statements must be specific enough that an assessor can understand what exists without interviewing the whole team.

9. Inherited Controls

Inherited controls are valid only when the system still satisfies the conditions required to inherit them.

10. External Providers and Interconnections

Vendor and interconnection risks are linked to CERG-PRC-TPRM-001 and CERG-PRC-RM-001.

11. Open Items and POA&M Linkage

No known control gap may remain only in narrative text. Every gap must have a POA&M item, risk-register entry, or documented not-applicable rationale.

12. Evidence Index

13. Approval and Maintenance

14. Document Control

Revision History

Review Triggers

• System boundary change
• CUI data-flow change
• Authorization or assessment event
• Material control implementation change
• POA&M or residual-risk change requiring SSP update
• Direction from the CISO

Source: templates/CERG-TMPL-CUI-001_System_Security_Plan_Template.md · Download .md · View on GitHub