If you have been asked to write a security plan, start with the outcomes the organisation needs and the resources it can commit. Turn the risk assessment into objectives, actions, responsibilities and a timetable.
The confusion matters because a security plan gets read by people who don't want to wade through a risk assessment to find out what's actually being done. A site manager, a finance approver, or a new security coordinator picking up the role needs a document that tells them the objectives, the actions, and the timetable without also explaining the underlying risk methodology.
How to write a security plan: what it's for, and what it isn't
A risk assessment identifies and analyses risk. A risk register records it. A security plan is the operational document that says, given that risk picture, here's what we're doing about it, by when, and with what resources. If your security plan and your risk register look identical, one of them is redundant — usually the plan, because it's just repeated the register's contents without adding the decisions.
The outline below uses eight sections. Adapt the structure to your organisation’s needs, keeping context before objectives and objectives before actions. Required emergency, regulatory or operational documents may need additional detail.
The eight sections
1. Introduction. Brief context: what the plan covers, the site or function it applies to, and why it exists. A paragraph, not a page.
2. Statement of purpose. The plan's reason for being, in a sentence or two — what security outcome the organisation is trying to secure by having this plan.
3. Security environment. A description of the current context: the threats and vulnerabilities relevant to this site or function, described at a level a non-specialist reader can follow. This draws on your risk assessment without reproducing all of it.
4. SMART objectives. Specific, measurable, achievable, relevant, time-bound statements of what the plan will achieve. "Improve site security" is not an objective. "Within three months, verify that every loading-dock access permission has an approved owner and expiry, and test the response to an unapproved access attempt" is.
5. Strategies and actions with responsibilities. For each objective, the specific actions that will achieve it, who owns each action, and by when. This is where the plan becomes assignable work rather than intent.
6. Residual risks. An honest statement of what risk remains after the planned actions are implemented, and why it's considered acceptable, escalated, or tolerated for now. Omitting this section is the most common way a plan overstates what it will actually achieve.
7. Timetable. A schedule for the actions in section five, ideally against dates rather than vague quarters, so progress can actually be tracked.
8. Resources. What budget, staff time, or external support the plan needs, stated honestly enough that whoever approves the plan knows what they're committing to.
Worked example: a three-site logistics firm
Here's how sections four and five might look for a fictional three-site logistics company, Dunraven Freight, addressing perimeter and access control risk at its main depot.
| Objective (SMART) | Action | Owner | Due |
|---|---|---|---|
| Test and demonstrate the agreed after-hours detection and response standard within 6 months | Install perimeter lighting and CCTV at the two identified blind spots | Facilities manager | Month 3 |
| Assign an accountable owner and review date to every authorised yard access permission within 4 months | Replace shared gate code with individual access fobs | Site security coordinator | Month 4 |
| Achieve 100% visitor sign-in compliance within 3 months | Install visitor kiosk at main reception and retire the paper log | Operations manager | Month 2 |
Installing equipment does not prove that an objective has been achieved. Define and test the required performance, and compare incident reports with evidence about detection and reporting; zero recorded incidents is not proof of zero exposure. These illustrative timeframes require adjustment to the actual urgency and interim controls. Each row ties an objective to a specific, ownable, dated action. Compare that to a plan that just says "improve perimeter security" — nobody can be held to that, and nobody can report progress against it either.
The residual risk section for this example might note that individual access fobs reduce but don't eliminate the risk of a lost or shared fob, and that this residual risk is accepted for now pending a review of fob deactivation procedures — a specific, honest statement rather than a claim the risk has been eliminated.
How this fits with your other documents
A security plan doesn't stand alone. It sits below the security risk management policy, which states the organisation's intent and appetite in general terms and doesn't change often. It sits alongside the risk register, which is the working record of identified risks and their ratings, updated far more frequently than the plan itself. And it feeds into the risk treatment schedule, which tracks the detailed status of individual treatments in a way the plan's summary table doesn't need to.
Getting this hierarchy wrong is what produces the two common failure patterns at the start of this article. Write the plan as if it were the policy, and it becomes too abstract to assign work against. Write it as if it were the register, and it becomes a list of risks with no stated objectives or ownership. The plan's job is the layer in between: turning the policy's intent and the register's risk picture into a dated, resourced, ownable programme of work for a defined period — typically twelve months, though a higher-risk site or function may warrant a shorter cycle.
That also means a security plan has a natural expiry. It's written against a specific security environment and a specific set of objectives for a stated period. When that period ends, the plan should be reviewed and reissued against the current risk picture, not quietly extended by changing the date on the cover page. A plan still in force three years after it was written has almost certainly stopped describing the actual security environment it claims to cover.
Who should write it, and who should approve it
The person best placed to draft a security plan is usually the one closest to the risk — a site security coordinator, facility manager, or operational risk owner — because sections three, four and five need enough operational detail to be assignable, not just aspirational. But drafting and approving should be separate steps. Whoever approves the plan is committing the resources in section eight and accepting the residual risk in section six, so approval should sit with someone who has the authority to actually commit both — typically the site or business unit manager, not the person who wrote the plan.
Common mistakes
Writing a risk register with a plan's title. If every line in your plan is a risk with a rating, you've written a register. A plan needs objectives and dated actions, not just identified risks.
Vague objectives with no measure. "Improve access control" can't be reported against. "Reduce tailgating incidents to fewer than two per quarter" can.
No named owner per action. An action assigned to "management" or "the team" is an action nobody is accountable for delivering.
Skipping residual risk. A plan that implies all risk will be eliminated by its actions is either wrong or dishonest. State what's left over.
Scope that keeps growing after approval. A plan approved for one site's perimeter risk gradually absorbing every security topic on the property is a plan that will never be finished or funded properly. Keep the scope the plan was approved against, and start a new plan for new scope.
Get the outline template
SRMBOK Template 13.5 Outline Security Plan gives you this eight-section structure ready to populate: introduction, statement of purpose, security environment, SMART objectives, strategies and actions with responsibilities, residual risks, timetable and resources. Before you start drafting, Security Risk Assessment Scope Creep: Five Clauses That Prevent It is worth reading so your plan's scope doesn't expand mid-draft, and Why Your Risk Policy Should Fit on One Page covers the policy layer that should sit above this plan, not inside it. Once the plan is approved, the free Cybersecurity Awareness Posters help communicate the parts of it that depend on staff behaviour.