Government Security
How to Write a System Security Plan That Assessors Actually Trust
A practical guide to writing a System Security Plan (SSP): structure, what assessors look for, common mistakes and how the SSP, SRMP and Statement of Applicability fit together.
A System Security Plan (SSP) is the single most important document in a government security assessment — and often the weakest. I’ve reviewed SSPs that run to hundreds of pages but can’t answer the basic question an assessor asks first: what is this system, and how is it protected?
What an SSP is for
An SSP describes a system and the security controls that protect it. Under the ISM risk management approach, it sits alongside two companion documents:
- System Security Plan (SSP) — the system, its boundary, and how each applicable control is implemented.
- Security Risk Management Plan (SRMP) — the risks to the system, their treatment and the residual risk.
- Statement of Applicability (SoA) — which controls apply, which don’t, and why.
Together they give an authorising officer what they need to make an informed decision. Separately, they’re just paperwork.
What assessors look for first
When I open an SSP, these are the first things I check:
- A clear system description — purpose, users, data, classification and business owner.
- A defined boundary — with an architecture diagram showing components, interfaces, data flows and external services.
- Control implementation statements that describe how a control is met in this system, not a copy of the control text.
- Justified exclusions — every “not applicable” backed by a risk-based reason in the SoA.
- Evidence references — where an assessor can verify each statement.
- Currency — the document reflects the system as it is today, against a current framework release.
The most common SSP mistakes
- Copy-pasting control text as the implementation statement. “The system implements multi-factor authentication” tells an assessor nothing.
- Generic templates filled with another system’s details.
- Missing cloud and SaaS components — the shared-responsibility split isn’t described.
- Writing it at the end. An SSP written after go-live documents decisions instead of shaping them.
- No owner. The SSP is updated once for the assessment, then never again.
A structure that works
A clear, assessable SSP typically includes:
- Document control and ownership
- System overview, classification and business context
- System boundary, architecture and data flows
- Roles and responsibilities (including service providers)
- Control implementation, grouped by guideline or control family
- Inherited and shared controls from platforms and providers
- Exclusions and compensating controls (referencing the SoA)
- Continuous monitoring and change management
- References to supporting evidence
Write the implementation statement as if the assessor has never seen your system — because they haven’t.
Writing better implementation statements
Compare these two statements for an MFA control:
- Weak: “MFA is implemented.”
- Strong: “All privileged and remote access to the system requires phishing-resistant MFA, enforced through the identity provider’s conditional access policies. Exceptions are prohibited by policy. Configuration is reviewed monthly and evidenced by the conditional access report (Evidence ref. IAM-04).”
The strong version tells the assessor what, how, how it’s enforced and where to verify it.
Keep it alive
An SSP is a living document. Tie updates to your change management process, review it at least annually and whenever the system or framework changes significantly, and make sure someone owns it. A current SSP makes your next IRAP assessment dramatically easier.
Frequently asked questions
How long should a System Security Plan be?
As long as it needs to be to describe the system and every applicable control clearly — and no longer. Clarity beats volume; a concise SSP with good evidence references is far more useful than a long generic one.
Who should write the SSP?
The system owner is accountable, but the SSP is best written collaboratively by the technical team that built the system and a security practitioner who understands the framework.
Do we need an SSP for cloud services?
Yes. Cloud and SaaS components are part of your system boundary. Your SSP should describe which controls the provider delivers, which you deliver, and how you verify the provider’s controls.
Need an SSP, SRMP or Statement of Applicability reviewed or written? See government assurance services or talk to my AI agent.