What a good Security Management Plan actually does

The Security Management Plan is one of the most requested and least loved artefacts in government and enterprise delivery. It is frequently produced late, frequently copied forward from an unrelated contract, and frequently read only by the person who has to approve it. That is a waste, because the questions it exists to answer are the right ones.

The purpose, stated plainly

A Security Management Plan should let a competent outsider understand what is being protected, who is accountable, what will be done, how it will be evidenced, and what happens when something goes wrong. If a new delivery manager could pick it up and run the service safely, it works. If it functions only as a compliance receipt, it does not.

Why most disappoint

• They describe policy intent rather than the controls actually in place on this service.
• They list controls without naming the person accountable for each one.
• They are written once, at the gate, and never reconciled with what got built.
• They avoid stating residual risk, which is the one thing the approver most needs.
• They are long. Length is usually a substitute for decisions that have not been taken.

The structure I keep returning to

Scope first, and honestly: the service, its boundaries, its data, its users, its dependencies, and explicitly what is out of scope and who owns that instead. Most disputes later trace back to a vague scope section early.

Then roles with names, not job families. Then the controls, expressed as what is implemented rather than what is aspired to, each with the evidence that demonstrates it and the frequency at which that evidence is refreshed. Then risk: what remains, who has accepted it, and until when. Then the operational reality — logging and what is actually reviewed, change, patching, third parties, and the incident path with real contact routes.

The test of the document is not whether it satisfies the framework. It is whether it would help on the worst day.

Write for three readers

• The approver, who needs residual risk, accountability and proportionality in the first two pages.
• The engineer, who needs to know precisely which control they own and what evidence looks like.
• Your successor, who needs the reasoning behind the decisions — especially the deliberate exceptions.

Writing for the third reader is what separates a plan from paperwork. Record why a control was tailored, why a risk was accepted, and what would change that decision. Unexplained decisions get reversed by the next person, usually at cost.

Keeping it alive

Tie the plan to the delivery cycle rather than the assurance cycle. Review it when architecture changes, when a supplier changes, when an acceptance expires, and after any incident. A plan reviewed on those triggers stays true; a plan reviewed annually is accurate for about a fortnight.

Done this way, the document stops being a tax on delivery and becomes the clearest single statement of how a service is kept safe — which is, after all, what everyone signing it hoped they were getting.