The goal of the register
An ISO 27001 risk register should help teams decide what to do next, not just prove that a workshop happened once. The register is a living decision tool: it captures what could go wrong, how serious it is, what controls already exist, and what the organization will do about it.
The most useful registers are simple enough to maintain and structured enough to support management review. If the register becomes a dumping ground, teams stop trusting it. If it is too shallow, leadership cannot use it to prioritize treatment.
Keep each entry lightweight
At minimum, track:
- Risk statement
- Affected asset, system, or process
- Likelihood and impact
- Current controls
- Treatment decision
- Owner and target date
- Residual risk after treatment
- Status
- Review date
- Evidence or control links
Use consistent scoring
Pick a scoring model that stakeholders understand. A three-level scale can work better than a complex formula if the team uses it consistently.
For likelihood, define what low, medium, and high mean in your environment. For impact, define effects on confidentiality, integrity, availability, customer trust, legal exposure, and operations. The definitions matter more than the math.
Avoid false precision. A risk score should help compare priorities, not pretend that risk can be measured perfectly.
Treatment decisions should be explicit
Every risk needs a treatment decision:
- Mitigate: add or improve controls.
- Accept: formally accept the risk with a rationale.
- Avoid: stop the activity or change the process.
- Transfer: use insurance, contract terms, or a provider to shift part of the risk.
Link risks to controls
The register becomes much more useful when each risk links to relevant controls. This helps the team answer:
- Which controls reduce this risk today?
- Which controls need improvement?
- Which risks share the same treatment action?
- Which controls exist without a clear risk rationale?
Where teams overcomplicate it
They add too many scoring dimensions before they have consistent review discipline. Start with a scoring method your stakeholders will actually use.
Common overcomplications include:
- Long risk taxonomies that nobody understands
- Scores with decimals and no decision impact
- Duplicate risks for every system
- Treatment plans without owners
- Accepted risks without expiration or review
- Registers reviewed only before an audit
Review cadence
Revisit critical and high risks monthly. Review the full register quarterly. Tie updates to management review so the register stays alive.
During each review, ask:
- Has the risk changed?
- Is the treatment still appropriate?
- Are treatment actions overdue?
- Has a new system, vendor, or process changed the risk?
- Is the residual risk acceptable?
- Does leadership need to make a decision?
A maintainable structure
A practical row looks like this:
| Field | Example |
|---|---|
| Risk statement | Privileged access may remain active after role changes |
| Asset or process | Production identity provider |
| Existing controls | HR offboarding, access review, MFA |
| Likelihood / impact | Medium / High |
| Treatment | Automate access reconciliation |
| Owner | IT lead |
| Due date | End of quarter |
| Residual risk | Medium after automation |
| Status | In progress |