What Is a System Security Plan (SSP)? A Plain-Language Guide for Small DIB Teams

What an SSP is

A System Security Plan (SSP) is a document that describes your environment and how your organization addresses each security requirement that applies to it. NIST SP 800-171 expects you to maintain one. In plain terms: it is the written picture of your systems, your boundary, who is responsible for what, and how you protect the information you handle.

This article is generic and educational. It does not interpret the requirements for you or determine whether your SSP is sufficient — that is for your qualified internal personnel or an authorized advisor. Read the requirements at the source and write the plan in your own words.

Why it matters

The SSP is usually the first thing anyone wants to see, because it is the map of your program. Your evidence — screenshots, exports, logs, records — only makes sense against a narrative that says this is our system, this is our boundary, and this is how we handle each area. Without that narrative, a binder of evidence is just a pile of files.

What goes in an SSP

A workable structure for a small DIB team:

• System identification — name, owner, author, date, version.
• Purpose and scope — what information you handle (FCI and/or CUI) and what the plan covers.
• System description and boundary — the components, network, and what is in scope versus out of scope.
• Roles and responsibilities — who owns security tasks, including anything shared with an MSP.
• Data types handled — the FCI and the CUI categories you handle (for CUI categories, see the National Archives CUI Registry at archives.gov/cui).
• Connections and external service providers — cloud services, MSPs, and whether they handle your covered information.
• Control implementation summary — for each of the 14 NIST SP 800-171 families, a description, in your own words, of how your organization addresses it and where the evidence lives.
• Plan of Action & Milestones reference — a pointer to your POA&M.
• Review history — the date, reviewer, and changes each time you update it.

Common mistakes

• Pasting control text from NIST instead of describing your own implementation. The SSP is about what you do.
• Letting it go stale. Date it and review it on a cadence; an SSP that describes last year’s environment is not accurate.
• No owner. Assign someone to keep it current.
• Treating it as one-and-done. It is a living document that changes as your systems change.

Where to read the requirements

• NIST SP 800-171 Rev. 2 — the control baseline: https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final
• 32 CFR Part 170 — the CMMC Program Rule: https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170

See the full regulatory sources guide for more.

Writing yours

You can write an SSP starting from a blank document and the structure above. If you would rather start from a ready-made outline — already organized by the 14 families, with prompts so you fill in your own implementation — the DIBStack Evidence Binder includes a blank SSP starter outline. It helps you structure and organize the plan; it does not write it for you or determine whether your organization is compliant.