System security plan (SSP) template

What a system security plan is

A system security plan is the document that says what your system is and how it meets each security requirement. Part 170 defines it as the document that "describes the system components that are included within the system, the environment in which the system operates, how the security requirements are implemented, and the relationships with or connections to other systems." For a contractor under NIST SP 800-171 it is requirement 3.12.4, and it is the first thing an assessor reads: without an up-to-date SSP at the time of assessment, the assessment cannot be completed.

NIST adds that "security plans need not be single documents": a plan can point to policies, procedures and diagrams you already keep. That is how this template is built. It gives you the spine, and each line can name the document that holds the detail, such as your policies or the per-requirement notes in the NIST SP 800-171 checklist.

How to use this SSP template

1. 01System. Name the company, the system and the assessment the plan is for.
2. 02Boundary. Write where the line is, describe the building, then sort your assets into the Part 170 categories.
3. 03CUI flow. List the CUI you hold and follow it hop by hop from arrival to exit.
4. 04Roles. Name the owner, the person who keeps the plan, the IT provider and the users.
5. 05Connections. List every outside system, cloud provider and ESP, with where its responsibility matrix sits.
6. 06Families. Write one implementation statement per family, starting from the starter line.
7. 07N/A and review. Mark what does not apply, describe exceptions, set the review interval and record the approval.

The plan saves in your browser as you type, so you can close the tab and come back. Copy it as Markdown into your document system, download it as a .md or .txt file, or print it for signature. Then score the gaps in the SPRS score calculator and put the ones the rule allows on a POA&M; the SSP itself can never go there.

What the assessor checks

NIST SP 800-171A breaks 3.12.4 into eight assessment objectives, and the DoD's Level 2 assessment guide repeats them word for word. Each one must be MET or not applicable for the requirement to be MET. The SSP check under the builder runs the same eight against what you typed.

The guide also says what goes in, and it is shorter than most templates make it. Contractors "are free to choose the format of their SSP", and there is no requirement to list every asset in it; the asset inventory does that.

Worked example: a 14-person machine shop

The builder opens on the plan of Kestrel Machine Works, an invented CNC shop that machines parts to a prime's drawings. Its owners chose an enclave: the drawings live in one government cloud tenant and on five machines, and the front office never touches them. That one decision is what keeps the plan short, the same trade-off our enclave comparison walks through.

Three lines carry most of the weight. The cloud tenant holds CUI, so its customer responsibility matrix is referred to in the plan, as Part 170 requires for a cloud provider. The managed service provider holds only security data, so it is in scope as a Security Protection Asset rather than a CUI holder; our MSP comparison covers what to ask one for. And the inspection PC that cannot be patched is written up as an enduring exception with its mitigation, which Part 170 says is assessed as MET when the SSP describes it.

Where SSPs fail an assessment

These rules come from Part 170 and the DoD assessment guide. Whether a contract asks you for a CMMC status at all is a separate question, and the program is mid-reform. The SSP requirement itself comes from NIST SP 800-171, which DFARS 252.204-7012 still applies; the Level 2 requirements guide covers the other 109.

Questions about SSPs

Writing the policies your plan points to? Start from the CMMC policy templates, and if the cloud tenant is still undecided, the GCC High alternatives page reads each option against the rule.