This page gives you a risk register you can use today: the reasoning first, then the columns, then a CSV you can open in any spreadsheet. If you only want the file, download the CSV. If you want to know why each column exists, read on, because a register that is filled in without a method tends to produce a long list that nobody uses.
What a risk register is for
A risk register is the record of the risks an organisation has identified, who owns each one, how serious it is judged to be, and what has been decided about it. NIST describes a risk register as a repository of risk information, including what is understood about risks over time. Its guidance on integrating cybersecurity and enterprise risk management, NIST IR 8286 Rev. 1, covers using risk registers to set out cybersecurity risk so that it can be compared and rolled up alongside other business risks.
The register has one job: to support decisions. It should let a director, client or owner see what could go wrong, how bad it would be, what is already in place and what is being done next. It is not a task list, a vulnerability scan export or an audit finding log, although all three may feed it. For a longer explanation, see what a risk register is.
The UK National Cyber Security Centre says that better business outcomes should drive cyber risk management, and favours approaches that reflect real exposure over box-ticking. That is a useful test for a register: if a row does not help someone decide something, it probably does not belong.
The fields a register needs
Every field below exists to answer a question a decision-maker will ask. Keep the set small. A register with twenty columns is rarely maintained.
- Ref: a stable identifier, so a risk can be discussed and tracked across reviews even when its wording changes.
- Risk title: a short label that describes an event, not a topic. “Ransomware” is a subject; “ransomware encrypts the file server” is a risk.
- Scope: the system, supplier, site or service affected. This stops one broad risk being mistaken for the whole estate.
- Risk description: the cause, the event and the consequence in one sentence. Writing all three makes the rating more consistent.
- Owner: a named person who can make the treatment decision. This is normally a business owner, not whoever runs the tool.
- Likelihood (1-5) and Impact (1-5): your scored judgement, using the scales in the next section.
- Current score: likelihood multiplied by impact, with the existing controls in place. Use this meaning every time so scores can be compared between reviews.
- Existing controls: what already reduces the risk. This lets a reviewer challenge whether the score reflects them.
- Treatment decision: treat (mitigate), accept, transfer or avoid. These are common risk response options; NIST SP 800-30 Rev. 1 names acceptance, avoidance, mitigation, sharing and transfer.
- Planned actions and Target date: what will change and by when, if the decision is to treat.
- Residual score: the expected score after the planned treatment is complete. For an accepted risk, it equals the current score.
- Status: open, accepted, closed or transferred.
- Last reviewed and Next review: dates that show the row has been looked at, and when it will be again.
How to score likelihood and impact
Scoring is a way of ordering risks so attention goes where it matters. It is a structured judgement, not a measurement. NIST SP 800-30 Rev. 1 treats risk as a function of likelihood and impact and describes qualitative and semi-quantitative scales that run from very low to very high. A five-point scale is a common, practical way to apply the same idea. You should adapt the descriptions to the client or organisation and write them down before scoring anything.
A simple starting scale is below. The wording is illustrative, not taken from a standard.
| Score | Likelihood (over the next 12 months) | Impact (on the organisation) |
|---|---|---|
| 1 | Very unlikely | Minor inconvenience, handled within normal work |
| 2 | Unlikely | Limited disruption or cost, recovered quickly |
| 3 | Possible | Noticeable disruption, cost or client impact |
| 4 | Likely | Serious disruption, regulatory attention or significant cost |
| 5 | Almost certain | Severe or prolonged harm to operations or clients |
Multiply the two numbers to give a score from 1 to 25. Then agree bands with the owner. For example, 1 to 4 might be low, 5 to 9 medium, 10 to 16 high and 20 to 25 critical. The bands matter less than agreeing them in advance and applying them consistently.
Link the score to a decision rule, for example: critical risks go to senior leadership for a decision, high risks need a funded plan, medium risks are owned and monitored, and low risks may be accepted by the owner. When impact is expressed in money, hours of downtime or numbers of clients affected, the scale becomes easier to defend. If you do not have that data, say that the score is a judgement and do not imply precision that you do not have.
The risk register template
Copy these columns into a spreadsheet, or download the CSV, which contains the header row and the three example rows shown below.
| Column | What to enter |
|---|---|
| Ref | Unique identifier, such as R-001 |
| Risk title | Short description of the event |
| Scope | System, supplier, site or service affected |
| Risk description | Cause, event and consequence in one sentence |
| Owner | Named person accountable for the decision |
| Likelihood (1-5) | Score from the agreed scale |
| Impact (1-5) | Score from the agreed scale |
| Current score | Likelihood multiplied by impact, with existing controls in place |
| Existing controls | Controls already in place |
| Treatment decision | Treat, accept, transfer or avoid |
| Planned actions | What will be done to change the risk |
| Target date | When the actions are due |
| Residual score | Expected score after the planned treatment is complete |
| Status | Open, accepted, closed or transferred |
| Last reviewed | Date of the latest review |
| Next review | Date of the next review |
If you track them, “Category” and “Linked controls” are sensible extra columns; they are left out here to keep the register small.
Example rows
These three rows are illustrative only. They are labelled as examples in the CSV, and the scores are not benchmarks for any real organisation. Replace them with your own.
| Ref | Risk title | Owner | L | I | Current score | Treatment decision | Residual score |
|---|---|---|---|---|---|---|---|
| R-001 (EXAMPLE) | Lost unmanaged laptop | Head of Operations | 3 | 4 | 12 | Treat: enforce encryption and remote wipe | 6 |
| R-002 (EXAMPLE) | Supplier outage of finance system | Finance Director | 2 | 3 | 6 | Accept: review at renewal | 6 |
| R-003 (EXAMPLE) | Phishing leads to mailbox takeover | IT Manager | 4 | 4 | 16 | Treat: enforce MFA and training | 8 |
Notice that R-002 is accepted, not ignored. It has an owner, a score and a review date. An accepted risk with a record is a decision; an unrecorded one is an oversight.
Review cadence
There is no single correct rhythm, and the NCSC’s guidance is not prescriptive. Choose one that suits how quickly the organisation changes, and write it into the register. Many teams review the highest-rated risks more often than the rest, and review the whole register at least once a year. Bring a risk forward whenever something material changes: an incident, a new supplier, a major system change, a change in regulation or a failed control test. Always update the Last reviewed and Next review columns so the register shows its own currency.
Common mistakes
- Treating it as a to-do list. Actions belong in a tracker. The register records risks and decisions.
- Vague risks. Topics cannot be scored. Describe a specific event and its consequence.
- No owner, or IT owns everything. Business risk needs a business owner.
- Everything rated high. If every row is high, the register cannot guide priorities.
- Scores with no scale behind them. Two reviewers should reach similar scores from the written descriptions.
- Accepting risk silently. Record who accepted it and when it will be revisited.
- Never updating it. A stale register is worse than none because it appears to give assurance.
Quality check before you share it
- Can each row be understood without the author present?
- Does every open risk have a named owner, a decision and a date?
- Are the scoring scales and bands written down and agreed?
- Would the scores change if a different reviewer used the same descriptions?
- Has anything happened since the last review that should move a row?
Where GetCybr fits
A spreadsheet is a sound way to start. If you maintain registers for several clients, GetCybr can keep each register, its owners, linked controls and review dates in one place. The judgement about which risks to accept stays with the client and the practitioner.
Sources
Standards and guidance referenced on this page were read in November 2026. This page paraphrases them and does not reproduce their text.
- NIST, Guide for Conducting Risk Assessments, SP 800-30 Rev. 1, September 2012.
- NIST, Integrating Cybersecurity and Enterprise Risk Management, IR 8286 Rev. 1, December 2025. NIST also publishes its own risk register template and schemas as supplemental material.
- UK National Cyber Security Centre, Risk management.