// Capability Statement — Download PDF
Insights / SSP
SSP

The SSP: the document your whole package is judged through.

What separates SSPs assessors accept from placeholders — true boundaries, specific implementation statements, and automation that keeps them current.

Ausper Technology · July 20, 2026 · Insight · SSP · Documentation

The System Security Plan (SSP) is the spine of every authorization package: the document that says what the system is, where its boundary sits, and how every applicable control is implemented. Assessors read it first and judge everything else through it. A weak SSP taxes the entire package; a strong one makes assessment almost boring.

What a good one contains

A boundary that is true. Diagrams matching reality, data flows included, inheritance explicitly drawn. Half of all assessment churn traces to boundary ambiguity. Implementation statements with specifics. 'AC-2: Account management is performed' is a placeholder. 'Accounts are provisioned via ServiceNow workflow X with approval Y, reviewed quarterly per SOP Z, evidence at location W' is a statement. Current facts. Versions, owners, interconnections — stale SSPs signal unmanaged systems.

Keeping it alive

The SSP dies between assessments unless it's wired to reality: generated and updated from the systems of record — CMDB, control tracker, pipeline — rather than hand-edited annually. The same automation spine powers continuous ATO, which is why we treat SSP generation as an engineering problem, not a writing assignment.

Common questions

What is a System Security Plan?
The document that describes the system, draws its authorization boundary, records its categorization, and states how every applicable control is implemented. It is the lens the whole package is judged through: assessors read the SSP first, and every artifact that follows is checked against what the SSP claimed.
What makes an SSP fail review?
Three things, repeatedly. Implementation statements that restate the control instead of describing this system — “the organization employs multifactor authentication” tells an assessor nothing. A boundary diagram that does not match the architecture that was actually built. And inherited controls claimed without naming the provider or producing the customer responsibility matrix that says which half is yours.
How do you keep an SSP current?
Generate what can be generated. Inventory, ports and protocols, data flows and baseline configuration should come out of the systems that already know them, not out of someone’s memory a month before assessment. Then tie the narrative sections to change control, so an architecture change that invalidates a paragraph updates it at the same time.

Related reading

The ATO, explained POA&M management eMASS vs Xacta FedRAMP, RMF, ICD 503 AccelSecure™
Put this to work

Need it done, not just explained?

This is the work we do every day. Tell us where your program stands and we'll give you a straight answer.

Talk to Ausper