If your security risk register is completed for an audit and then ignored, check whether each entry makes the next decision clear. Record the risk, relevant controls, assessed exposure, responsible owner and action in a format people can maintain.
What a security risk register template is actually for
A register also has a second audience beyond the risk owner: whoever is deciding where budget goes next quarter. If the register can't be scanned by that person in a few minutes to see what's rated highest and why, it will get replaced in practice by a verbal briefing, and the documented version will drift further from what's actually being acted on each time that happens.
A risk register is a decision-support tool, not a compliance artefact. Its job is to let someone — a risk owner, a manager, a board committee — look at a row and know three things: how bad this could get, how likely it is given current controls, and what happens next. If a register can't answer those three questions at a glance, it has failed regardless of how complete it looks.
This matters because registers tend to accrete columns over time — added for one audit, one consultant, one board request — until updating a single risk means touching fifteen fields. Staff stop maintaining it properly, ratings go stale, and the register becomes theatre: documented, but disconnected from what's actually being managed.
The fields that earn their place
A working register needs a compact, disciplined field set. More than this and you're trading usability for the appearance of rigour.
| Field | Purpose |
|---|---|
| Risk ID | Unique reference so the risk can be tracked across reviews and reports without being re-described each time |
| Risk description | What could happen, to what, and why — written as a single sentence, not a paragraph |
| Existing controls | What's actually in place now, not what's planned |
| Consequence rating | Severity of the outcome if the risk eventuates, against a defined scale |
| Likelihood rating | Probability of that outcome given the controls that currently exist, not in their absence |
| Existing control evaluation | A judgement on whether those controls are actually working, separate from whether they exist |
| Risk rating | The combination of consequence and likelihood, against your organisation's matrix |
| Prioritisation | Where this risk sits relative to others competing for the same budget and attention |
| Risk owner | The named person accountable for treatment, not a team or a title |
| Review date | When the rating was last checked against reality |
Two of these deserve more attention than they usually get. Existing control evaluation is not the same as existing controls. Listing "access control system installed" tells you nothing about whether it's configured correctly, monitored, or bypassed daily by staff propping doors open. Rate the control's actual effectiveness, separately from its existence, or the rating above it is fiction. And likelihood must be assessed against controls as they currently operate — not as designed, and not as they'll operate once the pending upgrade is finished.
Worked example
A fictional three-site logistics firm, Coastway Freight, is registering a risk around after-hours access to its main depot.
| Risk ID | Description | Existing controls | Control evaluation | Consequence | Likelihood | Rating | Owner |
|---|---|---|---|---|---|---|---|
| SEC-014 | Unauthorised after-hours access to the main depot yard leading to theft of goods in transit | Perimeter fencing, keypad gate, CCTV (unmonitored) | Partially effective — CCTV footage reviewed only after an incident is reported, not proactively | Moderate | Likely | High | Depot Operations Manager |
The value here is in the "partially effective" judgement. A register that only recorded "CCTV installed" would understate the risk. Recording that the footage is reactive, not monitored, is what turns this from a documented control into an honestly assessed one — and it's what justifies the treatment action that follows (in this case, moving to monitored CCTV or adding a guard patrol, logged against the same risk ID for the next review).
How prioritisation should actually work
Rating alone doesn't tell you what to fund first. Two "High" risks can call for very different urgency once you weigh in cost of treatment, speed of onset, and how many other risks share a control. Coastway's depot risk might rate the same as a data-handling risk in head office, but if the depot sits on a month-to-month lease due for renewal, treatment there is time-limited in a way the other risk isn't. Prioritisation is where that judgement gets recorded, so it isn't re-litigated from memory every time the register comes up for review.
Keeping it alive between formal reviews
A register that's only ever opened at the scheduled annual review is a register that's wrong for most of the year. The review date field should trigger action, not just get noted and left. In practice this means two review rhythms, not one: a full walk-through of every risk on a fixed cycle appropriate to your operating environment, and an event-triggered update whenever something changes the picture for a specific risk — a new site, a lease ending, a control failing in an incident, a staff change in a role that owns a risk. Coastway's depot risk above shouldn't wait for the annual cycle if the lease renewal falls due in the meantime; the register needs an owner empowered to update a rating out of cycle when the facts change.
This is also where prioritisation earns its keep as an ongoing tool rather than a one-off ranking. As treatments get funded and completed, the relative order of what's left shifts, and a register that isn't revisited between formal reviews will keep directing attention to a risk that's already been substantially treated, while a newer one climbs unnoticed.
Common mistakes
- Rating likelihood against controls that don't exist yet. If the upgrade is "planned," the risk is rated as if it hasn't happened.
- Confusing control existence with control effectiveness. A control that's documented is not the same as a control that works.
- Letting the register grow past what one page can show a decision-maker. If a register needs a legend to be readable, it has too many columns.
- No named individual owner. "IT team" or "Security" as an owner means nobody is accountable when the review date passes unactioned.
- Review dates that are set once and never revisited, so a rating from two reorganisations ago still sits in the current report.
Start from a register that's built to be used
If your register keeps sliding back into a spreadsheet nobody trusts, the fix is usually the field set, not the discipline of the people filling it in. SRMBOK's free Template 13.1 Risk Register gives you the register structure from Section 13 of SRMBOK — risk ID, consequence and likelihood, existing control evaluation, risk rating and prioritisation — with completion guidance for each field, so new risk owners can populate it correctly the first time. For the standard behind machine-readable control documentation, see What Is OSCAL, and Does Your Organisation Need It?, for a structured way to work through consequence chains before you rate them, see Free Online Course: The Risk Bow-Tie Method, and if your register keeps growing scope it was never meant to cover, read Security Risk Assessment Scope Creep: Five Clauses That Prevent It.