How to Write a System Security Plan (SSP)

The System Security Plan (SSP) is the single document that describes a system, how it's categorized, and, most importantly, how every security control is actually implemented. It's the first thing an assessor reads and the backbone of an authorization package. A vague SSP fails assessment; a specific, testable one passes.

• System identification: name, owner, ISSO, authorizing official, operating status, and the authorization boundary (what's in and out of scope).
• Categorization: the FIPS 199 impact level (C/I/A and the overall high-water mark).
• System description & environment: what it does, the data it holds, where it runs, and interconnections.
• Control implementation: for every selected control, a statement of *how* it's implemented on this system.
• Roles & responsibilities: who owns, operates, and oversees the controls.

An implementation statement an assessor can test names six things: (1) what is done, (2) the system/tool that does it, (3) the configuration/parameter, (4) the policy it traces to, (5) the evidence you could produce, and (6) the owner and review cadence.

'Accounts are managed appropriately' fails. 'Manager approval is required via the access-request workflow before provisioning; access is reviewed quarterly by the ISSO; evidenced by the signed review and SIEM logs' passes, because every claim is specific and testable.