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 precision manufacturer, Carrick Precision:
| Section | Content (abbreviated) |
|---|---|
| Policy statement | Carrick Precision manages security risk as an integral part of how it delivers reliable production and protects customer designs, tooling and staff, not as a separate compliance function. |
| Philosophy | Carrick Precision 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 Carrick Precision 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.
Seven lines the policy could actually say
This is an illustrative statement for Carrick Precision, to be approved against its actual delegations and risk criteria:
We manage security risk to protect our people, customer designs and continuity of production.
This policy applies to staff, contractors, sites and systems supporting our work.
Managers assess material security risks and keep an owned record of controls and decisions.
Risk may be accepted only within documented delegations and agreed criteria; decisions outside them go to the executive.
Treatment owners receive resources, due dates and a defined test of completion.
Staff report incidents and control failures promptly through the approved channels.
The chief executive owns this policy and reviews it annually, informed by quarterly reviews of overdue actions and control performance.
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.
Free working resource
Draft a policy people can use
The free one-page Security Risk Management Policy Template is an editable Microsoft Word document. It provides policy, philosophy, application, performance and responsibility sections. Adapt the authority and acceptance rules to your organisation before approval.
Download the free one-page Word policy
Opens the SRMBOK product page. Add the free item to your cart and complete the $0 order to receive the download. Check the newsletter choice at checkout.