What is a risk register?
A risk register lists an organization's known risks with their ratings, owners, treatments, and status. Here's what to include and how to keep it current.
A risk register is a structured list of an organization's known risks. For each one, it records a description, an owner, ratings like likelihood and impact, the controls that reduce it, the chosen treatment (mitigate, accept, transfer, or avoid), and its status. It's the everyday tool of risk management and the basis for reporting risk to leadership.
Typical fields
| Field | Purpose |
|---|---|
| Risk ID and title | A short, stable name people can refer to |
| Risk description | What could happen and why |
| Category | Cyber, privacy, operational, vendor, compliance, and so on |
| Owner | Who is accountable |
| Likelihood, impact, velocity | How probable, how severe, and how fast |
| Inherent and residual rating | Before and after controls |
| Linked controls, assets, vendors | What mitigates it and what it affects |
| Treatment and due date | What will be done and by when |
| Status and history | Where it stands and how it changed |
An example entry
| Field | Example |
|---|---|
| Title | Unauthorized access to customer data through former employee accounts |
| Description | Accounts are not always disabled in every system when someone leaves, so a former employee could still sign in to the support tool or data warehouse. |
| Category | Cybersecurity, identity |
| Owner | Director of IT |
| Inherent rating | Likelihood 4 of 5, impact 5 of 5: High |
| Controls | Offboarding checklist, SSO for core apps, quarterly access review |
| Residual rating | Likelihood 2 of 5, impact 5 of 5: Medium |
| Treatment | Mitigate: connect the HR system to the identity provider so accounts close automatically, due end of Q3 |
| Status | In progress. Two of five apps still outside SSO. |
How to write a good risk statement
Weak risk statements name a topic ("ransomware" or "vendor risk"). Strong ones name a cause, an event, and a consequence, so the owner knows what to control and leadership knows why it matters. A common pattern is: because of cause, event could happen, which would lead to consequence.
For example: because backups are stored on the same network as production, a ransomware infection could encrypt both, which would stop order processing for several days.
Rating risks
Most registers rate likelihood and impact on a 1 to 5 scale and multiply or combine them into a rating like Low, Medium, High, or Critical. Adding velocity (how fast the impact arrives) helps separate slow-burn risks from sudden ones. Programs that report to finance often add a dollar estimate using a method like FAIR. See risk quantification.
Rate each risk twice. The inherent rating assumes no controls. The residual rating reflects the controls you have today. The gap shows how much your controls are doing, and residual ratings should rise when a control fails. See inherent vs. residual risk.
Treatment options
| Treatment | What it means | Example |
|---|---|---|
| Mitigate | Add or strengthen controls to lower likelihood or impact | Enforce MFA on all remote access |
| Accept | Live with the risk, with a named approver and a review date | Accept a legacy system until it is retired next year |
| Transfer | Shift the financial impact to someone else | Cyber insurance, or contract terms with a vendor |
| Avoid | Stop the activity that creates the risk | Stop storing card numbers and use a tokenization service |
Where risks come from
- Failed controls and findings from assessments and audits.
- Exceptions in vendor SOC 2 reports and gaps in vendor questionnaires.
- Vulnerability and configuration scan results.
- Incidents and near misses.
- New regulations, products, markets, or acquisitions.
- Workshops with business and IT leaders.
Keeping it current
Registers get out of date when they're updated by hand once a quarter. Feeding them from assessment findings, merging duplicates, and recalculating residual risk as controls change keeps them current.
Review the whole register at least quarterly with risk owners, and review individual risks whenever a linked control fails, an incident happens, or a treatment is due. Accepted risks need an expiry date so acceptance is revisited.
Reporting from the register
Leadership and the board rarely want the full register. They want the top risks against appetite, what changed since last time, treatments that are late, and accepted risks. A heat map of likelihood against impact is the most common view. A trend of residual risk over time shows whether the program is working. Frameworks like NIST IR 8286 describe how cybersecurity risk registers roll up into enterprise risk reporting.
Risk appetite and tolerance
Risk appetite is the amount and type of risk the organization is willing to take to meet its goals, usually set by the board. Tolerance turns that into limits for specific risks, for example "no critical vulnerability open for more than 15 days on internet-facing systems." A register becomes useful to leadership when every risk can be read against appetite: within it, near the edge, or beyond it and needing a decision.
A simple rating scale
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare: less than once in 10 years | Minimal: no customer or financial effect |
| 2 | Unlikely: once in 5 to 10 years | Minor: small, contained effect |
| 3 | Possible: once in 1 to 5 years | Moderate: some customers or a reportable event |
| 4 | Likely: about once a year | Major: significant loss, regulatory attention |
| 5 | Almost certain: several times a year | Severe: threatens the business or its license |
Common mistakes
- Listing topics like "cloud risk" where a risk statement belongs.
- Rating risks once and never again.
- No owner, or an owner who does not know they own it.
- Accepted risks with no expiry date.
- Findings and risks tracked in separate tools with no link between them.
- Treatment plans with no due date.
How TruOps helps
TruOps builds a live risk register from findings, SOC 2 exceptions, and scan results. Each risk is rated on likelihood, impact, and velocity, with a dollar value when you need one, and every score shows the evidence behind it. Duplicate risks are merged for review, and residual ratings move when linked controls pass or fail. People approve every rating and treatment.
What to look for
A risk register should update itself. Ask whether findings, exceptions, and scan results can become owned risks without a workshop.
Questions
Who maintains the risk register?
Usually the risk or GRC team, with risk owners across the business updating their entries.
How often should a risk register be reviewed?
At least periodically, often quarterly, and whenever something significant changes.
What is the difference between a risk register and an issue log?
A risk is something that could happen. An issue or finding is something that has already happened or is already wrong. Findings often create or raise risks, so the two should be linked.
How many risks should a register have?
Enough to cover what matters, and few enough that owners can review them. Many mid-sized programs keep 30 to 100 active risks, with detailed findings tracked separately and linked.
Can a spreadsheet work as a risk register?
For a small program, yes. It gets hard when risks need to link to controls, findings, and vendors, when ratings should change as controls fail, or when several teams edit it at once.
Related
Risks from anywhere, drafted by TruPilot, approved by a person, and tracked in ratings or dollars.
→Use casesRisk registerA live register with every rating explained, built from what you already know.
→LearnInherent vs. residual riskRisk before controls, and risk after them.
→LearnRisk quantificationExpressing risk in dollars.
→See it run on your own data.
Book 30 minutes with a GRC specialist. Bring a real document, like a SOC 2 report, risk register, or vendor list (redacted is fine), and we'll show TruOps AI working on it.