The SSP is the single artifact that tells an assessor what a system is, where its authorization boundary lies, and how every applicable security control is implemented. It is the anchor for the authorization decision.
1 · System identification
The first block an assessor reads. Every downstream artifact must reference the same system name and version.
2 · Authorization boundary
The boundary is what the DSO is being asked to authorize. Everything in the boundary is assessed here; everything out is assessed elsewhere and inherited by reference. Boundary drift between the SSP and the TRA is the most common cause of ATO rework.
3 · System description
What the system does, who uses it, and how the parts fit together. An assessor should be able to reason about the SRTM after reading this section without asking a follow-up question.
4 · Roles and responsibilities
A RACI at role level, not name level. Named individuals belong in the operational runbook and change as staff rotate; the SSP records the accountable role.
5 · Security control implementation
The heart of the SSP. For every control in the profile, record who implements it, how it is implemented, and where the evidence lives. Inherited controls state the source and stop there. The starter template scaffolds this family-by-family across the twenty NIST SP 800-53 families.
6 · Plan of action and milestones
Every deficiency the assessor flags, or that the team self-identifies, gets an entry here with an owner, a target date, and a residual-risk statement while it is open.
7 · Continuous monitoring plan
How the control posture is kept current between authorizations. Vulnerability scanning, drift review, log review, access recertification, tabletop exercises, and DR tests — each with a cadence, an owner, and an evidence source.
8 · Appendices
The SSP itself stays short. Detail belongs in appendices — architecture and data-flow diagrams, the SRTM workbook, the TRA, the SoS, the PIA, the incident-response runbook, the contingency and DR plan, and the list of interconnection security agreements.
Approvals
The signatures below confirm that the responsible parties have reviewed this document, that its contents accurately reflect the system, and that the recorded decisions are authorized.
| Role | Purpose of signature |
|---|---|
| System security officer (SSO) | Prepared this SSP and confirms the control-implementation statements are current. |
| System owner / delegate | Confirms the boundary, description, and roles reflect the system as operated. |
| IT Security lead | Confirms the control profile is appropriate for the categorization and that inheritance claims are valid. |
| Departmental Security Officer (DSO) | Grants the authorization based on this SSP, the TRA, and the SoS. |