Free template · Markdown or Word · no email gate
NIST 800-171 SSP template
A System Security Plan (SSP) is the document NIST SP 800-171 requirement 3.12.4 makes mandatory: it describes your system boundary, the environment of operation, how each of the 110 requirements is implemented, and connections to other systems. Without a current SSP, no CMMC assessment can be completed — and 3.12.4 can never sit on a POA&M.
Skip to the free template ↓What 3.12.4 requires your SSP to contain
The requirement text is short and complete: develop and periodically update a plan that covers four things. Everything else in an SSP exists to make these four auditable.
| Required element | What assessors look for | In the template |
|---|---|---|
| System boundary | Which networks, servers, workstations, cloud tenants, and sites are inside the environment where CUI lives — and what is explicitly outside it. | Section 1.1 |
| Environment of operation | How the system runs: on-premises, cloud, or hybrid; the platforms by name; who administers them. | Section 1.3 |
| How each requirement is implemented | An implementation statement for each of the 110 NIST SP 800-171 requirements — status plus the mechanism, in your environment's terms. | Section 3 (14 family sections) |
| Connections to other systems | Relationships with and connections to other systems: managed-IT tooling, cloud services, partner links — what data moves and under what agreement. | Section 1.4 |
Source: NIST SP 800-171 Rev 2, requirement 3.12.4. Verified June 2026.
What assessors flag first
From our running log of why compliance artifacts fail scrutiny — the same checks our engine applies to every draft it produces:
Template prose
Sections that could describe any company — no system names, no roles, no customer-specific mechanisms. Generic boilerplate is the first thing assessors flag, which is why a downloaded template is a skeleton, not an answer.
Overstated implementation
"Implemented" with no described mechanism, or absolute words ("all," "always") nothing in your environment supports. Beyond failing the assessment conversation, overstatement in documents tied to SPRS submissions is False Claims Act exposure.
Missing N/A justifications
Marking a requirement "not applicable" without a written applicability argument the assessor can evaluate. N/A is a claim, and it needs evidence like any other.
SSP/POA&M drift
POA&M items that never appear in the SSP narrative, or a stated score that does not recompute from the stated statuses. The two documents must tell one story.
Scope confusion
A CUI boundary described one way in section 1 and a different way in the requirement narratives — or enclave claims the environment description contradicts.
Stale rule citations
Pre-final-rule language — old POA&M rules, "CMMC 1.0" practice IDs — that signals the document came from an outdated source.
The 3.12.4 gate: no SSP, no assessment
3.12.4 is the one requirement the DoD Assessment Methodology leaves unscored — zero points deducted when it's missing. That's not leniency; it's the opposite. Without a current SSP, no assessment can be completed at all: there is nothing to assess against, so the engagement cannot conclude (DoD Assessment Methodology v1.2.1 Annex A; 32 CFR 170).
And it is never POA&M-able: under 32 CFR 170.21, "write the SSP later" is not an open item you can carry into conditional Level 2 status. A self-assessed 110 in SPRS with no SSP behind it is a number you can't take to an assessor. If the SSP is your gap, it's the first gap — start there.
Download the blank SSP template
A complete skeleton, free and ungated: system identification, boundary, environment, and connections sections, then all 14 requirement families with a per-requirement block — verbatim requirement text, a status line, and an implementation-description placeholder — for every one of the 110 requirements. Fill the brackets with your environment's specifics; the instructions inside repeat the conservative-language rule: mark "Implemented" only when you can name the mechanism.
A blank template is the slow way: every placeholder is an hour of writing. The free assessment asks you the questions instead and drafts the SSP from your own answers — same structure, your specifics already in place.
Straight answers
What must an SSP contain under NIST 800-171?
Requirement 3.12.4 requires a system security plan that describes the system boundary, the environment of operation, how each of the 110 security requirements is implemented, and the relationships with or connections to other systems. In practice that means an identification section, a boundary and environment description, a connections inventory, and an implementation statement per requirement.
Is the SSP scored in the SPRS calculation?
No — 3.12.4 is the one unscored requirement in the DoD Assessment Methodology. It carries no point value because it is more serious than points: without a current SSP, no CMMC assessment can be completed at all (DoD Assessment Methodology Annex A; 32 CFR 170).
Can "develop an SSP" sit on a POA&M?
Never. 3.12.4 is one of six requirements that are never POA&M-eligible under 32 CFR 170.21 (with 3.1.20, 3.1.22, 3.10.3, 3.10.4, and 3.10.5). A missing SSP cannot ride along as an open item — it has to exist before an assessment can conclude.
Is there a mandated SSP format?
No. NIST SP 800-171 mandates the content (boundary, environment, implementation of each requirement, connections), not a form. Assessors expect to find those elements and statements specific to your environment. A Word document or markdown file with the structure in the free template below covers it.
Sources: NIST SP 800-171 Rev 2; DoD Assessment Methodology v1.2.1 Annex A; 32 CFR 170.21. Verified June 2026. Related: how every number is computed, on the scoring methodology page.
Or skip the blank page entirely
Generate your SSP draft from your own answers in the free assessment — your boundary, your systems, your statuses, conservatively worded, ready for your review and approval.
Start the free assessment