Building a risk register that your team will actually use
How to design, score, and run an information security risk register, with field definitions, a scoring model, ISO 27001 links, and a 30-day plan.
Most risk registers fail the same way: they're built for auditors, not operators. They become static spreadsheets that nobody updates between audits. This guide shows how to build one that delivers ongoing value.
A register that works is a decision tool. It tells leadership which risks are outside what the organization is willing to carry, tells owners what they are on the hook for, and tells auditors how risk drives the controls you operate. Everything in this guide serves one of those three purposes. If a field or step doesn't, leave it out.
If you'd rather start from a working file, download our risk register template and adapt it as you read.
Design principles
- One methodology for the whole org. Inconsistent scoring is worse than no scoring.
- Plain-language risks. "Insufficient access controls for production database" beats "A.9.2.3".
- Explicit owners. Every risk has a name next to it.
Three more principles are worth adding once you've seen registers fail in practice:
- Risks are not controls, and they are not findings. "No MFA on VPN" is a control gap. The risk is what could happen because of it: "Attacker uses stolen credentials to access the internal network via VPN, leading to data theft." Write the risk; list the gap as a contributing cause.
- Fewer, better risks. A register of 40 well-described risks that are actively managed beats 400 rows copied from a threat catalog. If two risks always share the same owner, controls, and treatment, merge them.
- Scoring should drive a decision. If a score doesn't change what anyone does, the scale is wrong or the thresholds are missing.
A useful way to write risk statements is cause, event, consequence: "Because of [cause], [event] may occur, resulting in [consequence]." It forces specificity and makes it obvious which controls address which part of the chain.
The minimum fields
A register should capture at least:
- Risk ID and title
- Description (what, where, how)
- Likelihood and impact (inherent)
- Existing controls
- Residual likelihood and impact
- Treatment decision
- Owner
- Review date
Those eight fields are the core. The table below expands them with the supporting fields most mature registers add, and an example for each.
| Field | Purpose | Example |
|---|---|---|
| Risk ID | Stable reference that never changes, even if the title does | R-014 |
| Title | Short, plain-language name | Customer data exposed via misconfigured cloud storage |
| Description | Cause, event, and consequence | Because storage permissions are set manually, a bucket holding customer exports may be made public, exposing personal data and triggering breach notification obligations |
| Category | Groups risks for reporting | Data protection |
| Asset or process | What is affected | Customer data export pipeline, production cloud account |
| Threat and vulnerability | What could exploit what | Opportunistic scanning; manual permission changes without review |
| Inherent likelihood and impact | Rating before existing controls | 4 and 5 |
| Inherent score | Likelihood × impact | 20 |
| Existing controls | Controls in place today, by reference | Encryption at rest; access logging |
| Residual likelihood and impact | Rating with existing controls working | 3 and 5 |
| Residual score | Likelihood × impact after controls | 15 |
| Treatment decision | Accept, mitigate, transfer, or avoid, with rationale | Mitigate: residual score exceeds appetite for data protection risks |
| Treatment plan | Specific actions, owners, and due dates | Enforce block-public-access at account level; add policy-as-code check in deployment pipeline |
| Target likelihood and impact | Expected rating after treatment | 1 and 5 |
| Target score | Score the treatment should achieve | 5 |
| Risk owner | Person accountable for the risk and authorized to accept it | Head of Platform Engineering |
| Status | Where the risk is in its lifecycle | Treatment in progress |
| Last reviewed / next review | Evidence the register is maintained | 2026-08-01 / 2026-11-01 |
Resist adding more columns until you have a use for them. Every field someone must fill in is a reason not to update the register.
Scoring: likelihood × impact
A 5×5 matrix is the most common approach, and for good reason: it is granular enough to separate risks and simple enough that owners score consistently. What makes it consistent is defining each level in concrete terms your organization recognizes. Write these definitions into your risk assessment methodology so the same risk gets the same score regardless of who assesses it.
| Rating | Likelihood | Impact |
|---|---|---|
| 1 – Rare | Not expected in the next 5 years | Negligible: no customer impact, handled within normal operations |
| 2 – Unlikely | Could happen once in 2 to 5 years | Minor: limited internal disruption, no reportable incident |
| 3 – Possible | Could happen once in 1 to 2 years | Moderate: short customer-facing disruption or limited data exposure without regulatory reporting |
| 4 – Likely | Expected within the next year | Major: significant outage, reportable breach, or material customer loss |
| 5 – Almost certain | Expected several times a year | Severe: extended outage, large-scale breach, regulatory action, or threat to the business |
Multiplying gives a score from 1 to 25. Then set bands that trigger action, for example:
- 1–5 Low: accept and review annually.
- 6–11 Medium: owner decides; treatment optional, review every six months.
- 12–19 High: treatment required, or explicit acceptance by senior management.
- 20–25 Critical: immediate treatment and escalation to leadership.
Impact can have multiple dimensions: financial, operational, legal and regulatory, reputational, and harm to individuals. A common rule is to score each dimension and take the highest, which prevents a severe privacy impact from being averaged away by low financial impact.
A worked example
| Risk | Inherent (L × I) | Existing controls | Residual (L × I) | Treatment | Target (L × I) |
|---|---|---|---|---|---|
| R-022: Former employee retains access to SaaS tools after leaving, allowing data exfiltration | 4 × 4 = 16 | SSO for most apps; HR notifies IT of leavers by email | 3 × 4 = 12 | Mitigate: automate deprovisioning from the HR system to the identity provider; quarterly access review for apps outside SSO | 1 × 4 = 4 |
Notice that impact doesn't move. Most controls reduce likelihood; if a former employee does exfiltrate data, the consequence is the same no matter how unlikely it was. Impact typically only drops with controls that limit the blast radius, such as data minimization, segmentation, or encryption. If your residual scores show large impact reductions from preventive controls, revisit them.
Inherent, residual, and target risk
These three views of the same risk answer three different questions:
- Inherent risk: how serious is this if our controls didn't exist or failed? It shows which controls are carrying the most weight and deserve the most testing.
- Residual risk: how serious is this today, with our current controls operating as designed? This is the number compared to appetite and the basis for the treatment decision.
- Target risk: where will this sit once planned treatment is complete? It turns a treatment plan into a measurable objective and lets you check whether the plan is sufficient before funding it.
Two practical cautions. First, residual risk assumes controls are working, so tie it to evidence that they are: a control that failed its last test should not reduce the score. Second, if target risk still exceeds appetite, the plan is not enough. Either strengthen it or escalate for formal acceptance.
Risk appetite and tolerance
Scoring without appetite leaves every conversation ending with "so is 12 bad?" Appetite gives the answer.
- Risk appetite is the amount and type of risk the organization is willing to pursue or retain in pursuit of its objectives. It is set by leadership and usually expressed as statements per category, for example: "We have a low appetite for risks that could expose customer personal data" or "We accept moderate risk in adopting new tooling to increase engineering speed."
- Risk tolerance is the practical threshold that operationalizes appetite, often expressed as a maximum residual score per category. Using the bands above, low appetite for data protection might translate to a tolerance of 8, while a moderate appetite for operational risk might tolerate up to 12.
The register then flags any risk whose residual score exceeds tolerance for its category. That flag drives the treatment decision and makes escalation automatic rather than political.
Get appetite approved by leadership in writing. Without that sign-off, risk owners have no authority to accept anything, and every acceptance is open to challenge.
Treatment options
Every risk has four possible treatments: accept, mitigate, transfer, or avoid. Document which one you're choosing and why — auditors ask this question every time.
| Option | What it means | When to use it | Example |
|---|---|---|---|
| Accept | Retain the risk as it is, with no further action | Residual risk is within tolerance, or treatment costs more than the risk warrants | Accept the risk of a short outage of an internal wiki |
| Mitigate | Implement or improve controls to reduce likelihood or impact | Residual risk exceeds tolerance and cost-effective controls exist | Enforce phishing-resistant MFA for administrator accounts |
| Transfer | Share the financial or operational consequences with another party | The impact is mainly financial or can be contractually shifted | Cyber insurance; contractual liability with a vendor |
| Avoid | Stop the activity that creates the risk | The risk is unacceptable and no treatment brings it within tolerance | Stop storing full payment card numbers by using a tokenization provider |
Three things auditors and good reviewers look for:
- Transfer never transfers accountability. Insurance pays for some consequences of a breach; it does not remove your obligations to customers or regulators. Keep a residual score after transfer.
- Acceptance needs the right authority. A risk above tolerance should be accepted by someone senior enough to own the consequence, with a rationale and an expiry date.
- Mitigation needs a plan, not an intention. Each action should have an owner, a due date, and a link to the control it creates or improves.
Ownership and review cadence
The risk owner is the person with the accountability and authority to manage the risk, usually the leader of the function where the risk lives, not the security team by default. Security facilitates the process, challenges scores, and advises on controls. Owners decide.
Separate the risk owner from the owners of individual treatment actions. The Head of Platform Engineering may own a cloud misconfiguration risk while three engineers own the actions.
Set review frequency by severity:
| Residual rating | Review frequency |
|---|---|
| Critical | Monthly, and reported to leadership each cycle |
| High | Quarterly |
| Medium | Every six months |
| Low | Annually |
Also define events that trigger an out-of-cycle review: a security incident, a significant change to systems or suppliers, a new regulation, an acquisition, a failed control test, or a finding from an internal or external audit. Reviews should actually re-score the risk and confirm the treatment status, not just update the date.
Linking risks to controls
This link is where a register stops being a list and becomes the backbone of your security program.
- Each risk references the controls that reduce it. When a control fails testing or its evidence expires, you can immediately see which residual scores are no longer reliable.
- Each control traces back to at least one risk or requirement. Controls with no risk and no legal or contractual requirement behind them are candidates for removal.
- Treatment actions create or strengthen controls. When an action completes, the new control is added to the control library and linked back to the risk.
For ISO 27001, this traceability is what justifies your Statement of Applicability: the controls you include and exclude should be explainable by your risk treatment decisions and your obligations. It also makes multi-framework work easier, because a single control can reduce several risks and satisfy several frameworks at once.
Reporting: heatmaps and top risks
Leadership doesn't need the full register. They need to know what is outside appetite, what is changing, and what decisions are needed. A good quarterly risk report fits on two or three pages:
- Heatmap. A 5×5 grid showing the count of risks in each cell, ideally residual next to inherent, or current next to last quarter. Heatmaps show distribution at a glance but hide detail, so never present one alone.
- Top risks. The top 5 to 10 residual risks, each with owner, score, trend arrow, treatment status, and target date.
- Risks outside tolerance. Every risk exceeding tolerance, with the decision requested: approve treatment funding, or formally accept.
- Movement. New risks, closed risks, and significant score changes since the last report, with a one-line reason each.
- Overdue items. Treatment actions past due and risks past their review date.
The trend matters more than the snapshot.
How ISO 27001 connects to the register
ISO 27001 is explicit about risk management, and the register is the main record auditors examine. For the wider context, see our complete ISO 27001 guide.
- Clause 6.1.2 (Information security risk assessment) requires you to define and apply a risk assessment process that establishes risk criteria, including risk acceptance criteria and criteria for performing assessments, and produces consistent, valid, and comparable results. It requires you to identify risks related to loss of confidentiality, integrity, and availability, identify risk owners, analyze likelihood and consequences, determine levels of risk, and evaluate and prioritize risks against your criteria. Your methodology document and scoring definitions are the evidence here.
- Clause 6.1.3 (Information security risk treatment) requires you to select treatment options, determine the controls needed, compare them with Annex A to confirm nothing necessary has been omitted, produce a Statement of Applicability, formulate a risk treatment plan, and obtain risk owners' approval of the plan and acceptance of residual risks.
- Clause 8.2 requires you to perform risk assessments at planned intervals or when significant changes are proposed or occur, and to retain documented results.
- Clause 8.3 requires you to implement the risk treatment plan and retain documented results of treatment.
In an audit, expect to be asked to walk through a single risk end to end: how it was scored, why that treatment was chosen, which controls address it, who accepted the residual risk and when, and evidence that it was reviewed on schedule. If your register can answer all of that for any row, you are in good shape.
Keeping it alive
The hardest part isn't building the register. It's keeping it current. Asurvo automates review cadences, flags overdue risks, and turns treatment plans into tracked tasks.
Whatever tool you use, the habits that keep a register alive are the same:
- Put risk review on the agenda of an existing meeting, such as a monthly security or operations review, instead of creating a new one.
- Make updating a risk part of closing an incident, completing an audit finding, or onboarding a critical vendor. Vendor risks identified through a vendor risk program should land in the same register with the same scoring.
- Report overdue reviews and actions by owner. Visibility does more than reminders.
- Retire risks that no longer apply, and record why.
Spreadsheets can work for a small register, but they struggle with ownership, history, and links to controls and evidence as the program grows. Our comparison of Asurvo versus spreadsheets covers where that line usually falls. Asurvo's Risk Management module provides a risk register with inherent, residual, and target scoring, treatment plans with owners and deadlines, and heatmaps and trends, so the practices above run on schedule rather than on memory.
Common mistakes
- Copying a generic risk list. A catalog of threats is a useful prompt, but risks must describe your assets, your processes, and your exposure.
- Writing control gaps as risks. "Lack of logging" is a cause. Describe what could happen because of it.
- Scoring by gut feel. Without defined scale levels, scores reflect who was in the room, not the risk.
- Residual scores that ignore control effectiveness. Controls that are not tested or evidenced should not reduce risk.
- Everything owned by the CISO. Security can't accept risks on behalf of the business functions that create them.
- No appetite statement. Without it, treatment decisions are arbitrary and acceptances are indefensible.
- Acceptances that never expire. Every accepted risk needs a review date.
- Updating only before the audit. Review dates that all fall in the same week tell an auditor how the register is really maintained.
Your first 30 days
| Week | Focus | Activities | Output |
|---|---|---|---|
| Week 1 | Method | Draft the methodology: likelihood and impact scales, score bands, review cadence, treatment options, and who can accept which risk levels; draft appetite statements per category | Draft methodology and appetite statements |
| Week 2 | Identify | Run short workshops with engineering, IT, HR, legal, finance, and customer-facing teams; review past incidents, audit findings, vendor dependencies, and key assets; write risks as cause, event, consequence | 25 to 50 draft risks with proposed owners |
| Week 3 | Assess | Score inherent and residual risk with each owner; link existing controls; compare to tolerance; get leadership approval of methodology and appetite | Scored register, approved methodology and appetite |
| Week 4 | Treat and operate | Decide treatment for every risk above tolerance; write treatment plans with actions, owners, dates, and target scores; record formal acceptances; schedule reviews; produce the first heatmap and top-risks report | Treatment plan, acceptance records, review calendar, first leadership report |
After 30 days you won't have a perfect register, but you will have a working one: consistent scores, named owners, approved appetite, and a review cycle in motion.