If your team is unclear about who can accept a security risk, start with a short policy that defines responsibilities and decision authority. A security risk management policy should help people act consistently, with detailed procedures supporting it where needed.
A policy is not a procedure. A procedure tells someone how to do a task. A standard sets a technical bar. A policy does neither — it states intent, and it sits above both. If your "policy" has step-by-step instructions in it, you've written a procedure with a policy's letterhead.
What a security risk management policy template actually needs to say
Strip it back and a working policy has five components, and all five fit on one page if you resist the urge to explain yourself.
A policy statement. One or two sentences committing the organisation to managing security risk as part of normal business, not as a compliance afterthought. This is usually the only sentence anyone quotes back to you later, so it needs to survive being read out of context.
A statement of risk appetite or philosophy. This is the part most policies skip, and it's the part that does the actual work. A policy that says "we will manage risk" tells staff nothing about how much risk is acceptable. A policy that says something closer to intelligent risk-taking — that the organisation accepts risk deliberately in pursuit of its objectives, and expects staff to identify and escalate risk rather than avoid it by inaction — gives people a decision rule they can actually use on a Tuesday afternoon.
Application guidance. A sentence or two on scope: who this applies to, and roughly how it connects to the organisation's broader risk framework. This is where you'd reference ISO 31000:2018 if the organisation has adopted it, without pretending the policy is the framework itself. ISO 31000 sets out principles, a framework, and a process for managing risk generically; your policy is the organisational commitment that sits above that process, not a restatement of it.
Performance metrics. How the organisation will know the policy is working. Not "zero incidents" — that measures luck, not risk management. Better metrics are things like the proportion of risk assessments completed on schedule, the number of risks with an assigned and overdue treatment owner, or whether risk registers are reviewed at the frequency the policy commits to.
Roles and responsibilities. Named accountability from the board or CEO down to individual staff, stated in a sentence or two per level, not a RACI chart. The chief executive owns the policy. A risk or security manager administers it. Line managers are accountable for risk in their area. Staff are responsible for identifying and reporting risk. If your policy doesn't say who does what, it's a values statement, not a policy.
Worked example: a one-page policy in outline
Here's how those five elements might read for a fictional mid-size water utility, Cardgrove Water:
| Section | Content (abbreviated) |
|---|---|
| Policy statement | Cardgrove Water manages security risk as an integral part of how it delivers safe, reliable water services, not as a separate compliance function. |
| Philosophy | Cardgrove Water takes risk deliberately. Staff are expected to identify, assess and escalate security risk rather than avoid decisions to eliminate it. |
| Application | This policy applies to all employees, contractors and third parties operating on Cardgrove Water sites or systems, and is implemented through the risk management framework aligned to ISO 31000:2018. |
| Performance metrics | Percentage of business units with a current risk register; percentage of risk treatments completed by their due date; annual review of this policy by the executive. |
| Responsibilities | CEO: owns this policy. Executive team: own risk within their portfolios. Security manager: administers the risk framework and reports to the executive quarterly. All staff: identify and report security risk through the register. |
Notice what isn't there: no control lists, no incident response steps, no named systems. That detail belongs in procedures and standards that sit underneath the policy and can change without the CEO re-signing anything.
Why the one-page limit is a design decision, not a compromise
A one-page policy can feel too short, but the relevant test is whether it states the necessary decisions and responsibilities clearly. A policy that runs to fifteen pages has usually absorbed content that belongs in a standard, a procedure, or a risk management plan, and in doing so it has made itself impossible to maintain. Every time a system changes, someone has to remember to update the fifteen-page document, and eventually nobody does. A one-page policy that only ever states intent, appetite, metrics and roles rarely needs to change, because none of that content is tied to a specific technology or process. You can replace your access control system twice without touching a word of it.
The length constraint also forces clarity. If you can't fit the risk appetite statement into two sentences, it's not a decision yet — it's still a discussion. Push that discussion to conclusion before it goes in the policy, not after.
Getting it signed is the easy part
A policy that sits in a document management system unread does no work. Three things make the difference between a policy that gets followed and one that gets filed.
First, the CEO or accountable executive needs to visibly own it — their name on the signature line, and ideally a sentence or two from them at induction or in an all-staff communication when it's issued or reviewed. Where signing is delegated, make the approval authority and executive accountability clear; a signature alone does not establish how actively a policy is supported.
Second, it needs to be visible where decisions actually happen, not just where compliance can point to it. A laminated copy in the project room or site office does more than a link in an intranet policy library that nobody browses voluntarily.
Third, it needs a review date that's actually kept. A policy reviewed "as required" is a policy reviewed never. Put a specific interval in the metrics section — annually is common — and treat a missed review as a finding in its own right.
Common mistakes
Writing the policy as a procedure. If a document tells staff which form to fill in, it has stopped being a policy. Split it.
No stated risk appetite. A policy that never says how much risk is acceptable leaves every judgement call to whoever is in the room, which is precisely the inconsistency a policy exists to prevent.
Metrics that measure absence of bad luck. "No breaches this year" is not evidence the policy is working. It might just mean nobody has tried yet.
Responsibilities without names or roles. "Management is responsible for risk" assigns responsibility to nobody. Name the role, not just the function.
Treating the policy as permanent. A policy that hasn't been reviewed since it was written is a policy the organisation has stopped believing in. Put a review date on it and mean it.
Get the free one-page template
The SRMBOK Security Risk Management Policy Template gives you this structure already built: a policy statement, the intelligent risk-taking philosophy, application guidance, performance metrics, and role responsibilities from staff through to CEO, aligned to SRMBOK and ISO 31000:2018, formatted to fit on one page. If you want the broader method this policy sits inside, read What Is RMBOK? A Practitioner's Introduction first, and if you're documenting a formal risk framework alongside it, What Is OSCAL, and Does Your Organisation Need It? is worth reading before you commit to a format. For the version of this policy your team can actually see, print the free Security Risk Management Wall Chart for the project room.