If you have been asked to build a risk register and do not know where to start, begin with the decisions it needs to support. A short register with clear risks, owners and actions is more useful than a large spreadsheet nobody can maintain.
What building a risk register is actually for
A risk register is a working list of the things that could stop your organisation doing what it needs to do, what you are doing about each one, and who owns that action. That is the whole job. It is not a compliance artefact you produce once for an auditor. If nobody opens it between audits, it has already failed, regardless of how many columns it has.
A register earns its place on your desk by answering three questions at a glance: what are we worried about, what have we decided to do about it, and is that being done. Everything else is optional until you have a reason to add it.
The minimum field set that works
Most first registers fail because they start too big. People add columns for inherent likelihood, residual likelihood, velocity, risk appetite alignment and a five-point control-effectiveness rating before they have a single risk written down properly. Start with the fields that force a decision, not the fields that look sophisticated.
| Field | Purpose |
|---|---|
| Risk ID | So you can refer to it in meetings without re-describing it |
| Risk description | Cause, event, consequence — in that order |
| Category | Groups risks for reporting (security, safety, operational, etc.) |
| Current controls | What is actually in place now, not what the policy says should be |
| Likelihood and consequence | Your organisation's rating scale, applied consistently |
| Risk rating | The output of the above, used to set priority |
| Treatment | The specific action being taken, not "monitor" |
| Owner | One name, not a team |
| Due date | For the treatment, not for the risk |
| Status | Open, in progress, closed, overdue |
These ten fields are a starting point. Add or adapt fields where your decisions, obligations or operating context require them. If you are aligning to a framework like ISO 31000, this field set maps cleanly onto its risk assessment and treatment cycle without needing to bolt on extra columns just to look compliant — see ISO 31000 Explained on One Page (Free Download) if you want the underlying logic in one page.
Writing a risk description that means something
The single most common defect in a first register is a risk description that is really just a hazard: "cyber attack", "fire", "insider threat". A risk description needs a cause, an event and a consequence, in that order, so anyone reading it six months later understands the actual exposure without you in the room.
Compare:
- Weak: "Cyber attack on customer database."
- Working: "Unpatched customer-facing web application allows unauthorised access to the customer database, resulting in data breach notification obligations and reputational damage."
The second version tells you where to look for controls (patching, application hardening), what the consequence actually is, and gives a treatment owner something concrete to act on. If you are using an AI tool to help draft these descriptions faster, be careful what you paste into it — see Is It Safe to Paste This Into ChatGPT? A Thirty-Second Test before you copy anything from an internal document into a public chat interface.
Worked example: a first register for a fictional water utility
Take Coorabin Water, a fictional regional water utility with around 90 staff and three treatment sites. It has never had a risk register. The security coordinator — who also runs facilities — is asked to produce one before the next board meeting.
A realistic first pass might contain 15 to 25 risks, not 200. Two entries might look like this:
| Risk ID | Description | Category | Rating | Treatment | Owner | Due |
|---|---|---|---|---|---|---|
| R-04 | Perimeter fencing at the northern treatment site has degraded, allowing unauthorised pedestrian access to chemical storage | Security | High | Arrange immediate interim access protection; confirm a dated repair plan and verify chemical-store access controls | Facilities Manager | Interim action now; repair date agreed at triage |
| R-11 | Contractor access remains active after project completion, allowing unauthorised entry and potential loss or disruption | Security | Medium | Link access withdrawal to the end of the authorised work and verify it; review existing permissions | Security Coordinator | Agree dates at triage based on access exposure |
These are abbreviated, illustrative entries, not assessed ratings or universal deadlines. In a real register, add current controls, rating rationale and agreed action dates; address urgent exposure through the operational response process. Neither entry needs a maturity model or a control library to be useful. Each one is specific enough that a stranger could pick it up and know what to do next. That is the bar for a first register: specific, owned, and dated.
Where treatment plans fit
A register should record what has been decided about each risk, including a reasoned decision to retain it where appropriate. New treatment is not required for every entry, but the decision, authority and review arrangements should be clear. A treatment needs to be a discrete action with an owner and a date — "improve access control" is not a treatment, it is a direction. "Install a card reader on the chemical store door by end of quarter" is a treatment.
Keep treatment tracking in the same document as the register, at least at the start. Splitting them into separate spreadsheets before you have a working habit of updating either one is a common way for both to go stale.
Getting a stakeholder view without a second document
Board members and executives do not want to read 20 rows of causes and consequences. They want to know how many high-rated risks are open, how many treatments are overdue, and whether the trend is improving. Rather than building a separate report, add a simple summary view driven off the same register: a count by rating band, a count of overdue treatments, and the three or four items that would embarrass the organisation if they were not being managed. Keeping the summary and the working register in the same file means the number the board sees is always the number the register actually contains, not a snapshot someone forgot to update.
Set a review cadence before you present the register for the first time, not after. Monthly suits an organisation still building the habit; quarterly suits one where the register has stabilised and treatments run over longer periods. Whatever you pick, put the next review date on a calendar the day you finish the first version. A register with no scheduled review date is a register that will be rediscovered, out of date, the next time something goes wrong.
Common mistakes
- Starting with someone else's 40-column template. Strip it back to the fields that force a decision before you add anything else.
- Writing hazards instead of risks. "Fire" is not a risk description. Cause, event, consequence.
- Treatments with no owner or date. An unowned treatment is a wish, not a plan.
- Rating risks before controls are properly identified. You cannot rate residual risk honestly if you have not listed what is actually protecting you now, as opposed to what the policy says should be.
- Building it once for the auditor and never opening it again. A register that isn't reviewed on a set cadence — monthly or quarterly is common — will be wrong by the time anyone needs it.
Get the starter pack
You do not need to build the spreadsheet from a blank sheet. The SRMBOK Risk Register Starter Pack is a deliberately simple risk register and treatment plan template with customisable fields, integrated treatment tracking and a summary view for stakeholders, built to get a first register started without the 40-column detour. It is free.