CMMC System Security Plan (SSP) Template
System Security Plan (SSP) Template
Download the branded CMMCAssessment.ai working SSP template. Email is optional — you can also download it instantly.
Prefer no form? Skip the form — download instantly.
The System Security Plan is the strangest requirement in the standard. It is worth zero points — the only unscored requirement of the 110. And yet without it, the DoD Assessment Methodology treats the assessment as impossible to complete for want of information, which means you do not get a low score. You get no valid score at all.
It is also the document an assessor reads first. Everything else gets tested against what it claims, so a vague SSP produces findings across the whole assessment rather than in one place.
The structure below explains the template, and the downloadable version gives you a branded working document to complete. You can share your work email if you want the support team to know what you downloaded, or skip the form entirely.
What an SSP has to contain
32 CFR and the NIST guidance between them require the plan to describe the system boundary, the environment of operation, how each requirement is implemented, and the relationships with or connections to other systems. In practice that breaks into seven sections.
| Section | What goes in it | Most common failure |
|---|---|---|
| 1. System identification | Name, owner, contract references, the DFARS clauses that apply | Omitting which contracts drive the requirement |
| 2. System boundary | Every system that processes, stores or transmits CUI, plus security-service systems | Forgetting backups, identity providers and mobile devices |
| 3. Environment of operation | Physical sites, hosting, cloud tenancy, remote working | Describing head office and ignoring a second site |
| 4. CUI data flow | How CUI enters, moves, rests and leaves | No diagram, or one that does not match the boundary |
| 5. Control implementation | All 110 requirements, written to objective level | Restating the requirement instead of describing your implementation |
| 6. Connections and providers | Cloud services, MSPs, shared-responsibility matrices | Assuming the provider covers controls it does not |
| 7. Review and maintenance | Who owns it, review cadence, change history | A plan dated two years ago with no revision record |
The control implementation section
Section 5 is the bulk of the work — 110 entries, one per requirement, organised by family. For each one, an assessor is looking for four things:
- What you do — the actual mechanism, named specifically. “Entra ID Conditional Access enforces MFA on all interactive sign-ins” rather than “MFA is enabled.”
- Where it applies — which systems in the boundary, and any exceptions.
- Who is responsible — a role, and where relevant the provider under a shared-responsibility model.
- What evidence exists — the artefact that proves it, mapped to the objective rather than the requirement.
Structure by family
Organise section 5 in the standard’s own order so an assessor can navigate it without a map. The requirement counts per family are fixed:
| Family | ID range | Entries | Points at stake |
|---|---|---|---|
| AC Access Control | 3.1.1–3.1.22 | 22 | 54 |
| SC System and Communications Protection | 3.13.1–3.13.16 | 16 | 42 |
| CM Configuration Management | 3.4.1–3.4.9 | 9 | 33 |
| SI System and Information Integrity | 3.14.1–3.14.7 | 7 | 31 |
| IA Identification and Authentication | 3.5.1–3.5.11 | 11 | 27 |
| MP Media Protection | 3.8.1–3.8.9 | 9 | 23 |
| AU Audit and Accountability | 3.3.1–3.3.9 | 9 | 19 |
| MA Maintenance | 3.7.1–3.7.6 | 6 | 18 |
| PE Physical Protection | 3.10.1–3.10.6 | 6 | 14 |
| CA Security Assessment | 3.12.1–3.12.4 | 4 | 13 |
| AT Awareness and Training | 3.2.1–3.2.3 | 3 | 11 |
| IR Incident Response | 3.6.1–3.6.3 | 3 | 11 |
| RA Risk Assessment | 3.11.1–3.11.3 | 3 | 9 |
| PS Personnel Security | 3.9.1–3.9.2 | 2 | 8 |
Why objective level matters so much
NIST SP 800-171A decomposes the 110 requirements into 320 assessment objectives. A requirement is only satisfied when every objective under it is. This is the single largest gap between a self-assessment and a real one, and it is why scores fall when someone competent looks properly.
Write the plan to that level and two things follow: your SSP survives scrutiny, and your SPRS score becomes defensible rather than optimistic.
Before you start writing
An SSP is downstream of scoping. If you are not certain where CUI lives, the plan will describe a boundary you cannot defend — start with finding CUI in your environment, and the control families for what each section has to cover. If you would rather have it produced alongside a scored gap analysis, that is part of a readiness assessment.
Frequently asked questions
Is an SSP required?
Yes. NIST SP 800-171 requirement 3.12.4 requires a system security plan. It is the only unscored requirement in the standard, but its absence means an assessment cannot be completed, which leaves you with no valid score at all.
How long should an SSP be?
Long enough to describe your environment and how each of the 110 requirements is met in it. For a small contractor with a tight enclave that may be thirty pages; for a complex estate it can run to hundreds. Length is not the measure — specificity is.
Can I reuse a template without changing it?
No. A template gives you structure, not content. An SSP that describes a generic environment rather than yours will fail on the first question an assessor asks about your actual systems.
What is the difference between an SSP and a POA&M?
The SSP describes what you have implemented. The POA&M lists what you have not, with a plan and a date. Under 32 CFR 170.21 only one-point requirements may generally be deferred to a POA&M, so the two documents are not interchangeable.
Do I write it at control level or objective level?
Objective level. NIST SP 800-171A breaks the 110 requirements into 320 assessment objectives, and assessors make determinations against those. An SSP written at control level — "we use MFA" — fails when the objectives underneath are tested.