What is a risk register?
A risk register is a living record of the risks an organization has identified, each scored on likelihood and impact, assigned an owner and a treatment, and tracked over time. It is the backbone of a risk-management program and a requirement of frameworks like ISO 27001 and SOC 2.
Definition
A risk register is a structured, continuously maintained inventory of risks. For each risk it captures a description, the likelihood and impact, an owner, the treatment (accept, mitigate, transfer, or avoid), the controls that reduce it, and its status over time.
Background
Risk registers are central to every serious risk-management approach and are explicitly expected by standards such as ISO 27001, SOC 2, and the NIST frameworks. A good register distinguishes inherent risk (before controls) from residual risk (after the controls you have in place), so you can see how much your program actually reduces exposure. Scoring is usually a likelihood × impact scale (often 5×5) that plots each risk on a heat map.
Why it matters
Auditors ask to see how you manage risk, and a maintained register is the evidence. More importantly, it turns “we should probably do something about that” into owned, prioritized, tracked work, so the biggest exposures actually get addressed.
Step by step
- Identify risks from real sources: assets, threats, incidents, audits, and vendor assessments.
- Describe each risk clearly, in terms of what could happen and to what.
- Score inherent likelihood and impact on a consistent scale.
- Assign an owner and choose a treatment: accept, mitigate, transfer, or avoid.
- Link the controls that reduce the risk, then score residual likelihood and impact.
- Review on a cadence and after incidents or major changes, keeping the register current.
Examples
- A company records “Loss of customer data via compromised admin account,” scores it high/high inherent, links MFA and access reviews as controls, and lowers the residual score.
- A vendor going out of business is logged as a risk with a treatment to maintain a documented exit and backup plan.
Common mistakes
- Building the register once for the audit and never updating it, so it goes stale.
- Scoring inconsistently, so risks aren’t comparable.
- Recording risks with no owner or treatment, so nothing actually happens.
FAQ
What fields should a risk register have?
At minimum: a description, likelihood, impact, owner, treatment, linked controls, and status. Distinguishing inherent from residual risk makes it far more useful.
What is the difference between inherent and residual risk?
Inherent risk is the exposure before any controls; residual risk is what remains after the controls you have in place. The gap between them shows how much your program reduces risk.
Do I need a risk register for SOC 2 or ISO 27001?
Effectively yes. Both expect a maintained risk assessment, and a living risk register is the standard way to demonstrate it.
Do this in Keel, not a spreadsheet
Keel is the AI-native GRC platform for SMBs: one control-and-evidence graph across SOC 2, ISO 27001, HIPAA, PCI DSS, NIST CSF, and more. Start free, no credit card.
Start free