If staff cannot find the decisions and responsibilities in your risk policy, separate the governing principles from the detailed procedures. A concise policy can make expectations easier to find, provided the supporting instructions remain accessible.
What a policy is actually for
A risk policy has one job: to state, briefly enough that people remember it, what the organisation believes about risk-taking and what it expects of people at every level. It is not a procedure manual, a risk assessment methodology, or a register of controls. Those documents matter, and they can run to whatever length they need. The policy that sits above them is different — it is meant to be read, understood and recalled by someone under pressure making a fast decision, not consulted like a reference text.
Once you separate "policy" from "procedure" cleanly, the case for brevity becomes obvious. Nobody needs to memorise a procedure. Everybody needs to internalise a policy, and nobody internalises twenty pages.
The case against comprehensiveness
The instinct behind a long risk policy is usually good governance gone wrong: cover every scenario, reference every standard, anticipate every question an auditor might ask. The result is a document that reads like a legal disclaimer, satisfies the audit checklist, and changes nobody's behaviour. Comprehensiveness and effectiveness pull in opposite directions here. A document that tries to answer every question ends up answering none of them memorably.
There is also a subtler cost. A long policy invites long review cycles, heavy legal input, and reluctance to touch it once approved, because revisiting it is expensive. A one-page policy can be reviewed and updated as often as the organisation's risk appetite actually changes, which is closer to what governance is supposed to look like.
What actually needs to be on a one page risk policy
A one-page security risk management policy earns its length by including only what genuinely belongs at policy level:
- A policy statement. One or two sentences committing the organisation to managing security risk systematically, aligned to a recognised standard such as ISO 31000:2018.
- A philosophy statement on risk-taking. Whether the organisation treats security risk as something to be eliminated wherever possible, or manages it as an input to intelligent, deliberate risk-taking in pursuit of objectives. This single paragraph does more to shape day-to-day decisions than any procedure document, because it tells people how to think when a situation is not covered by a procedure at all.
- Application guidance. Who and what the policy covers — all staff, contractors, specific facilities or systems — stated plainly enough that nobody can claim it did not apply to them.
- Performance metrics. A short reference to how the organisation will know the policy is working — incident trends, audit findings, assessment completion rates — without turning the policy itself into a reporting document.
- Role responsibilities. A line each for staff, managers, the security or risk function, and the CEO or board, stating what each is accountable for. This is usually the section that reveals whether a policy has ever actually been thought through, because vague responsibilities at this level cascade into vague accountability everywhere else.
A worked example: before and after at Halden Manufacturing
Halden Manufacturing is a fictional mid-size manufacturer. Its original risk policy ran to eighteen pages, including a full risk assessment methodology, a fourteen-item control catalogue, and three appendices. Almost nobody outside the risk team had read it end to end.
| Element | Eighteen-page version | One-page version |
|---|---|---|
| Policy statement | Buried on page 3, after a table of contents and definitions | First paragraph, two sentences |
| Risk appetite / philosophy | Not stated explicitly; implied across several sections | One paragraph: risk is managed to enable operations, not eliminated at the cost of the business |
| CEO's accountability | Referenced once, in a signature block | Named explicitly as a line item alongside staff, managers and the security function |
| Where the assessment methodology lives | In the same document | Moved to a separate procedure, referenced by a link, not duplicated |
| Staff recall (informal test, six months later) | Effectively none | Most managers could state the risk philosophy paragraph in their own words |
Nothing of substance was lost. The methodology, the control catalogue and the appendices still exist — they simply live in the documents suited to their length, while the policy does the one job a policy needs to do.
Common mistakes
- Merging policy and procedure into one document. This is the single biggest reason risk policies grow past the length anyone will read.
- Stating requirements without stating philosophy. A list of rules with no explanation of the organisation's actual stance on risk-taking leaves people guessing when a situation is not explicitly covered.
- Leaving the CEO or board out of the responsibilities section. A policy whose accountability chain visibly stops below the executive level signals, correctly, that risk is someone else's job.
- Writing it once and never revisiting it. A one-page policy is cheap enough to review annually. There is no excuse for it being older than your last strategy refresh.
- Assuming shorter means less rigorous. A one-page policy grounded in ISO 31000:2018 and backed by proper procedures underneath it is more rigorous than a long document nobody can actually apply, not less.
Who should own the page
A one-page policy needs a clear owner, and it should not default to whoever is easiest to schedule. Ownership belongs with whoever is accountable for the organisation's overall risk posture — often a chief risk officer, a security manager reporting to the executive, or in smaller organisations, the CEO directly. The owner's job is not to write the page alone. It is to make sure the philosophy paragraph reflects what the organisation actually believes about risk-taking, not what sounds good in a governance document, and to bring it back for review on a cycle short enough to matter — annually is reasonable for most organisations, sooner if risk appetite genuinely shifts, such as after a merger, a new regulatory obligation, or a material incident.
This ownership question is where many organisations quietly fail even a well-written one-page policy. A page with no clear owner drifts out of date the same way a twenty-page document does, just more slowly, because there is less of it to notice going stale.
Getting buy-in for something this short
Shortening a policy is sometimes read internally as watering it down, particularly by whoever wrote the long version. It helps to frame it explicitly as a restructure, not a reduction in rigour — the content that mattered moves to where it belongs, and the policy becomes the one document everyone is actually expected to know. If you are also fielding the broader argument that risk management is bureaucratic paperwork rather than a decision-making discipline, Explaining Risk Management to Colleagues Who Think It's Paperwork tackles that conversation directly. And because a policy this visible often needs to say something about how information is classified and shared, Traffic Light Protocol Explained: TLP:RED to TLP:CLEAR is a useful reference if your policy needs to touch on that. If your organisation has never formally worked through how a specific risk's causes and consequences interact, Bow-Tie Analysis Explained in 15 Minutes is a good primer before your next policy review.
Get the template
The SRMBOK Security Risk Management Policy Template is a one-page policy aligned to SRMBOK and ISO 31000:2018, with a policy statement, a philosophy of intelligent risk-taking, application guidance, performance metrics and role responsibilities from staff to CEO. Download the SRMBOK Security Risk Management Policy Template and replace whatever document is currently unread on your intranet.