Where the SSP comes from
The classic guide is NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems. For contractors handling CUI, the obligation lands through NIST SP 800-171 requirement 3.12.4. Cloud providers pursuing FedRAMP maintain an SSP in the FedRAMP format as the core of their authorization package (fedramp.gov).
What an SSP contains
- System identification — name, owner, points of contact.
- System boundary — what is in scope, with a network diagram.
- Environment of operation — where and how the system runs.
- Data flows — where CUI enters, is processed, stored and leaves.
- Asset inventory — hardware, software and services in the boundary.
- External services and inheritance — what cloud or managed providers cover.
- Requirement-by-requirement implementation statements — how each of the 110 NIST SP 800-171 requirements is met.
- Referenced policies and procedures — by name and version.
- Revision history — dates, changes, approvers.
Example implementation statement (fictional)
Each requirement gets a short, specific statement. Example for one requirement:
3.5.3 — Multifactor Authentication. Example: All remote access to the corporate network requires MFA through the organization's identity provider. VPN and cloud email sign-in both enforce MFA; local administrator accounts use hardware tokens. MFA enrollment is verified at onboarding and reviewed quarterly.
Assessors look for statements that are specific, current and backed by evidence — not copies of the requirement text.
SSP vs POA&M
The SSP says how requirements are implemented; the POA&M tracks the ones that are not yet. They work together: gaps identified against the SSP feed the POA&M, and closing a POA&M item means updating the SSP.
The CMMC-specific outline
For the CMMC Level 2 view — asset categories, scoping rules and what an assessor expects — see the CMMC SSP template. Athena's SSP automation builds the document from your live scope, enclave and assessment data.