Risk Register Template
Risks scored by impact and likelihood, each with a response and an owner.
Details
risk register templateUploads
Your logo
A photo or picture
Goes on this page only. Drag it anywhere and pull its corner to resize it.
Your signature
Draw it with a finger, a mouse or a trackpad, and it goes on the page like a picture.
Pictures and signatures stay on this device. Nothing is uploaded to a server.
Red highlights mark what is still blank. Click anything on the page to change it. Your draft is kept on this device as you work.
| Project | [project] |
| As at | [date] |
| Risk | Impact | Likelihood | Score | Response | Owner |
|---|---|---|---|---|---|
| [add one risk per line] |
Score is impact × likelihood, where impact runs low(1) to critical(4) and likelihood runs rare(1) to almost certain(5). Anything scoring 9 or above should have a named owner and a date, not just a response.
What is a Risk Register?
A risk register lists what could go wrong on a project or in an organisation, scores each item by how much damage it would do and how likely it is, and puts one named person against it. Without it risks stay in individual heads: three people have privately worried about the same single supplier, nobody has priced the alternative, and the first time anyone writes it down is in the post-incident report.
Project managers keep one for the length of a project and a programme office consolidates them across a portfolio. Beyond projects, boards and trustees keep a standing register of risks to the organisation itself — funding concentration, key-person dependency, cyber intrusion, regulatory change. Certification schemes expect one too: an information security management system built to ISO 27001 and a quality system built to ISO 9001 both rest on documented risk assessment. Small organisations use the same columns as large ones, with fewer rows and a shorter review cycle.
Whether a register is compulsory depends on what you are and where you operate. Listed companies face governance requirements on risk oversight — the UK Corporate Governance Code, risk management committee rules under India's Companies Act and listing regulations, the ASX principles in Australia, and internal control reporting duties in the United States. Financial firms and critical service providers face more specific operational resilience rules, including the EU's DORA and NIS2 regimes. ISO 31000 is a standard, not law. Check what your regulator, listing rules or funder actually requires before assuming a spreadsheet satisfies it.
A register records risks, not issues. A risk has not happened yet and carries a probability; the moment it materialises it belongs in the issue log and is managed differently. The register is also not a control — writing down that the office could flood does nothing until someone moves the servers. And it does not replace the specific statutory assessments many places require in their own prescribed format, such as fire risk, manual handling, hazardous substances or data protection impact assessments, which cannot be folded into a project spreadsheet.
What to put in a Risk Register
These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.
| Field | What goes in it |
|---|---|
| Issuing organisation | For example: Maple Grove Homeowners Association |
| Organisation address | For example: 1420 Kinnear Road, Columbus, OH 43212 |
| Project | For example: Warehouse management system rollout |
| As at date | Free text |
| Risks | One per line: Risk | Impact | Likelihood | Response | Owner |
How to write a Risk Register
Write each risk as cause, event, effect
One line in three parts: because billing runs on a single legacy server, it could fail during the month-end run, and invoicing would stop for several days. Compare that with a register entry that says only Billing system. The first tells the reader what to fix, when the danger peaks and what it costs; the second tells them nothing they can act on.
Score impact and likelihood on one scale
Fix the scale before you score anything — a five-point range with each level written out in words, so a 4 for impact means the same thing to the finance lead and the site manager. Define impact in your own units: money, days lost, people affected, regulatory exposure. Score the risk as it stands today, before mitigation, and score it again afterwards if you want to show the mitigation working.
Give every risk one named owner
The owner is the person who can actually change the exposure, not the person who spotted it and not the project manager by default. One name, not a department: Operations cannot be chased. The owner keeps the mitigation moving and says when the score has changed. If nobody in the room can own a risk, that is itself a finding worth escalating.
Choose a response and cost it
For each risk pick one of four: avoid it by changing the plan, reduce it by acting on cause or effect, transfer it through insurance or a contract term, or accept it deliberately and say so. Accepting is a legitimate choice; accepting by silence is not. Write the specific action, its cost and its date, so the response can be tracked like any other piece of work.
Set a review date and record movement
A register reviewed once is a document; reviewed monthly it is a control. Give each row a next-review date and keep the previous score visible so you can see direction of travel — a risk climbing for three months is a different conversation from a static one. Close rows explicitly, with a reason and a date, rather than deleting them.
Common mistakes
- Recording risks as bare nouns — budget, staffing, weather — which produces a list nobody can score, mitigate or close.
- Scoring the residual risk after mitigation but presenting it as the raw exposure, so the board never sees what the project is actually carrying.
- Assigning ownership to a department, which means the risk is chased by nobody until it becomes an issue.
- Filling the register in at kickoff and never reopening it, so it describes a project that stopped existing two months ago.
- Mixing issues that have already happened into the risk rows, which inflates the register and buries the things that could still be prevented.
Frequently asked questions
What is the difference between a risk and an issue?
A risk might happen; an issue already has. The register holds risks and carries a probability against each. Once the event occurs the row moves to the issue log, where the question changes from how do we prevent this to who is fixing it and by when. Keeping both in one sheet is the fastest way to lose track of the risks still worth preventing.
What should a risk register contain?
As a minimum: a reference number, the risk written as cause, event and effect, an impact score, a likelihood score, the resulting rating, the chosen response, the named owner, the action with its date, and the next review date. Anything beyond that earns its place only if someone reads it. Registers fail from being too long far more often than from being too short.
How do you score impact and likelihood?
Use one fixed scale across the whole register and write out what each level means in your own terms — a 5 for impact might be a stoppage of more than a week or a reportable breach. Combine the two scores into a rating, then sanity-check the top rows against instinct. If the ranking looks wrong to the people who know the work, the definitions are wrong.
Who owns the risk register?
One person maintains the document, usually the project manager or the risk lead, but each row belongs to the individual who can influence it. The distinction matters when something goes wrong: the maintainer is accountable for the register being current, the row owner for the exposure itself. Write both roles at the top of the sheet so neither assumes the other is watching.
How often should a risk register be reviewed?
Common practice is a full review at each project board or monthly management meeting, with high-rated rows checked more often and the whole register reworked at any major change of scope, supplier or funding. What matters more than the interval is that the review is minuted, so there is a record of the decision to accept a risk that later materialises.
This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.