What an SSP is
A System Security Plan (SSP) is the document that describes your in-scope environment and how you meet each security requirement. NIST SP 800-171 requirement 3.12.4 calls for one that describes:
- the system's boundaries,
- its environments of operation,
- how each security requirement is implemented, and
- its relationships with or connections to other systems,
and it must be updated periodically.
Think of it as the map an assessor uses to understand your environment before they look at anything else.
Why it matters so much for Level 2
- No SSP, no assessment. Under the CMMC scoring rules, an assessment cannot be completed without a current SSP.
- It cannot be deferred. The SSP requirement is one of the few that may not be placed on a plan of action. It has to exist at assessment time.
- Scoping lives in it. Your asset categories, including any assets you treat as contractor risk managed or specialized, must be documented in the SSP, along with your network diagram.
Level 1 does not require an SSP, though a short written description of your scope and practices still makes the annual self-assessment easier.
What goes in it
There is no mandatory template. Most SSPs cover:
- System description and scope: what the environment is for, which contracts it supports, and where its boundary sits.
- Asset inventory: hardware, software, and services in scope, each with its CMMC asset category.
- Network diagram and data flows: how CUI moves in, through, and out.
- External service providers: who they are, what they do, and the customer responsibility matrix showing who covers which requirement.
- Roles and responsibilities: who owns security, who administers systems, who the Affirming Official is.
- An implementation statement for every requirement: how you meet it, in your environment, with references to the policies, procedures, and evidence that back it up.
- Requirements not yet met, cross-referenced to your plan of action.
Writing implementation statements that hold up
Each statement should let an assessor know what to look for. Good ones are:
- Specific: which system, which setting, which team, how often.
- Present tense: "Accounts are reviewed quarterly by the IT lead", not "We will review accounts".
- Traceable: they point to the procedure that describes the activity and the record that proves it happens.
Common mistakes
- Template boilerplate that describes a generic company, not yours.
- Aspirational language that describes what you plan to do.
- Drift: the SSP describes last year's environment. New laptops, a new cloud service, or a departed administrator make it wrong.
- Missing providers: an IT company or cloud service that touches CUI but is not in the SSP.
- Statements with no evidence behind them. If you cannot show it, an assessor cannot score it as met.
Keeping it current
Treat the SSP as a living document. Update it when you add or remove systems, change providers, change who does what, or fix an item from your plan of action, and review it on a set schedule even if nothing seems to have changed.