Chapter 2
What Is a System Security Plan (SSP)?
What is a System Security Plan?
A System Security Plan, called an SSP, is a written description of how you protect a system. It names the security controls you use and explains how each one works.
Policies say what you intend to do. The SSP says what you actually do, system by system. That difference is why assessors read it first.
NIST defines the SSP as describing the purpose of the system. It covers the state of the chosen controls and the duties of everyone who runs or uses the system. NIST SP 800-18 Rev. 2
Who writes it?
The security team usually writes it. In a small company, one person may own the whole thing. Larger firms split it across system owners.
The author needs access to the real systems. Interviews with admins fill the gaps. Secondhand guesses do not belong in an SSP.
Leadership must approve the final version. The plan carries weight only when management stands behind it. An unsigned draft is just notes.
Outside help is common. Consultants can draft, but your team must own the facts. Nobody knows your systems better than you do.
What goes inside?
An SSP starts with a system overview. It says what the system does, where it lives, and who is responsible for it.
The core is the control section. For each requirement, the SSP states whether it is met. It then describes how it is met in plain terms.
It also lists what is not yet met. Open items point to a Plan of Action and Milestones, the POA&M. That list tracks each gap, its owner, and its fix date.
Diagrams help a lot. A network diagram shows where data flows. One simple drawing can replace three pages of text.
NIST published the current guide as Rev. 2 in June 2026, replacing Rev. 1 from 2006. NIST SP 800-18 Rev. 2 NIST SP 800-18 Rev. 1
How do assessors use it?
Assessors read the SSP before they look at anything else. It tells them where to focus and which claims to test.
They check every claim against proof. If the SSP says access is reviewed quarterly, they ask for the reviews. Each statement needs evidence behind it.
A clear SSP speeds the assessment up. A vague one slows it down. Clarity here saves weeks later.
How often should it change?
An SSP is a living document. Update it when systems change. New tools, new staff, and new networks all belong in it.
Review it at least once a year. Many teams review it quarterly. Regular reviews keep it honest.
Treat changes as normal, not as failures. A plan that never changes is probably out of date. The current NIST guide treats the plan as something you maintain, not something you write once. NIST SP 800-18 Rev. 2
Can one SSP cover several systems?
Sometimes, if the systems share controls and boundaries. One plan can describe a common environment, with a boundary section for each system.
Systems with different risks deserve separate plans. Forcing them together creates confusion. When in doubt, split them.
PolicyCortex collects live configuration evidence from Azure, so each SSP statement points to current proof instead of last quarter's screenshots.
Sources
- NIST SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
- NIST SP 800-18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems (withdrawn June 30, 2026)
Next step
A strong SSP starts with knowing what you actually run today. Write from facts, not memory.