NIST 800-171 System Security Plan (SSP) Template for CMMC
A System Security Plan (SSP) is the document that describes your CUI environment and explains, for each of the 110 NIST SP 800-171 requirements, how your company meets it. It is required by requirement 3.12.4, it can never go on a POA&M, and without a current one a CMMC assessment cannot be completed.
Key facts
- Required by NIST SP 800-171 Rev 2, requirement 3.12.4, and relied on by DFARS 252.204-7012 and 7019.
- No point value, but a missing or out-of-date SSP means an assessment "could not be completed" under 32 CFR 170.24.
- Excluded by name from the POA&M you can use for Conditional Level 2 status.
- Covers 110 requirements in 14 families; assessors test them through 320 objectives in NIST SP 800-171A.
- Must document the responsibilities of any cloud or managed IT provider that handles CUI or your security tools.
What must a NIST 800-171 SSP contain?
An SSP must describe your system boundary, the environment it operates in, how each security requirement is implemented, and how the system connects to other systems. Requirement 3.12.4 puts it in one sentence:
“Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.”
In practice, a complete SSP includes:
- System name, owner, CAGE codes and the contracts it supports.
- The boundary: which people, locations, networks and assets store, process or transmit CUI, and which are out of scope and why.
- A network diagram and CUI data flows.
- Connections to other systems, such as a customer portal, a managed IT provider or a cloud tenant.
- Roles, plus the customer responsibility matrix (CRM) from each external service provider.
- An implementation statement for all 110 requirements, with status (met, not met or not applicable) and where the evidence lives.
- Enduring exceptions, a reference to the POA&M, version history and management approval.
How do assessors read an SSP?
Assessors use the SSP as the map and then check the territory. For each requirement they examine documents and settings, interview the people named and test that the control works, following the methods in NIST SP 800-171A.
They look for three things. Specificity: who does it, with what tool, where and how often. Consistency: the SSP, the policy, the configuration and the interview answers all say the same thing. Currency: a plan that names a firewall you replaced last year tells the assessor the document is not maintained.
What does a good implementation statement look like?
A good statement is short, specific and checkable. A weak statement repeats the requirement back. Here is requirement 3.5.3 (multifactor authentication) for Harborline Precision Machining, a fictional 38-person shop:
| Weak | Good |
|---|---|
| “Harborline uses multifactor authentication in accordance with company policy.” | “All 38 user accounts in the CUI enclave require MFA at sign-in: password plus push approval on a company-issued phone. The two administrator accounts are separate from daily-use accounts and require a hardware security key for local and network sign-in. The IT lead reviews the MFA exceptions report monthly and records the review in the access review log. Keystone Managed IT (fictional) administers the identity service under the CRM.” |
The good version names the scope, the method, privileged versus standard users, the review frequency and the evidence. An assessor can verify every clause in minutes. The weak version can only be verified by asking every question it failed to answer.
How do you write an SSP in three weeks?
For a small, contained environment, one person who can give it most of their time can produce a solid first SSP in about three weeks. Larger or messier environments take longer.
- Week 1, days 1–2: Set scope. Confirm which contracts involve CUI, list every asset and person that touches it, and draw the network diagram and data flows.
- Week 1, days 3–5: Collect provider documents. Get the CRM from your cloud and managed IT providers and note which requirements they meet, which you meet and which are shared.
- Week 2: Draft statements. Work through the 14 families. Write what is true today. Mark gaps as not met and move them to the POA&M.
- Week 3, days 1–3: Check against evidence. For each statement, open the setting or record it describes. Fix the statement or the control until they match.
- Week 3, days 4–5: Review and approve. Walk leadership through the boundary, the score and the POA&M, then approve, date and schedule the next review.
Which SSP template option is right for you?
Buy the SSP alone if you already have a score and a POA&M. Choose a bundle if you are starting from scratch.
- NIST 800-171 System Security Plan (SSP) Template ($99): the SSP on its own, as an editable Word document.
- CMMC Level 2 Starter Bundle ($175, was $207): the SSP plus the Assessment Workbook with SPRS score calculator and the POA&M Template & Tracker.
- CMMC Level 2 Compliance Toolkit ($279, was $336): everything above plus policies and procedures for all 14 families.
A template gives you structure and prompts; the content must describe your own system. It helps you prepare and cannot promise a passing assessment. For the wider picture, see CMMC in 2026: what still applies.
Last reviewed: 29 September 2026. CMMC rules are still moving. Check your contract, your prime's flowdown and the current rule before you rely on any date.
Frequently asked questions
Is a System Security Plan required for CMMC Level 1?
No. Level 1 covers the 15 FAR 52.204-21 requirements, and none of them calls for an SSP. A short written description of your FCI systems, users and safeguards is still good practice. It makes the annual self-assessment faster and gives the person who affirms in SPRS something concrete to rely on before they sign.
How long should a NIST 800-171 SSP be?
There is no required length. What matters is a clear boundary and a specific statement for every one of the 110 requirements. Companies that keep CUI in a small, contained environment usually end up with a shorter plan than those with CUI spread across many systems. Generic filler makes a plan harder to verify, not stronger.
Can our managed IT provider write the SSP for us?
They can help, and they should document what they handle in a customer responsibility matrix. But the SSP describes your organization, and your Affirming Official stands behind it. Someone inside the company must understand and own every statement, because assessors interview your people, and a plan nobody internal can explain tends to fall apart under questions.
How often should an SSP be updated?
Requirement 3.12.4 says periodically, without a fixed interval. A sensible rhythm is a full review before each annual affirmation, plus an update whenever the environment changes: a new system, a new provider, an office move, a new contract bringing CUI, or a closed POA&M item. Keep a version history so you can show what changed and when.
Can a requirement be marked not applicable in the SSP?
Yes, where it genuinely does not apply, with the reason written down. The CMMC rule's own example is 3.13.5, separating publicly accessible systems, when none are in scope. An objective assessed as not applicable counts the same as met, so assessors will ask why. Never use it to hide a gap.
Not ready to buy? Start with the free CMMC Level 1 checklist
15 plain-English questions, one per FAR 52.204-21 requirement, to find the gaps before you affirm in SPRS.