What a cyber risk register should contain
A cyber risk register should contain, for each risk, a statement written as cause, event and impact, a named owner, an inherent and a residual rating, the controls relied on, a treatment decision, a due date, and a link to the key risk indicator that tracks it. That is eight or nine columns. Registers that fail usually have plenty of columns and get one of these wrong.
The columns that matter
The example row follows one risk: a payroll vendor that holds a standing administrator account in your payroll system.
| Column | What goes in it | Example |
|---|---|---|
| Risk statement | Cause, event and impact in one or two sentences | Vendor admin account could be used to redirect staff pay |
| Owner | A named executive, not a department | Chief financial officer |
| Inherent rating | Likelihood and impact before controls | High |
| Controls | The specific controls relied on | Vendor MFA; bank-detail changes need a second approver |
| Residual rating | Likelihood and impact with controls as they operate today | Medium |
| Treatment | Reduce, transfer, avoid or accept | Reduce: replace standing access with time-bound access |
| Due date | When the treatment lands, or when acceptance expires | End of next quarter |
| KRI link | The indicator that shows the risk moving | Vendor admin sessions outside a change window |
Add a last-reviewed date and you have a register that can support a decision.
How to write a cyber risk statement
Use cause, event and impact. “Cyber attack” is not a risk statement; it names a category and gives nobody anything to act on.
Compare: “Because our payroll vendor holds a standing administrator account (cause), an attacker who compromises the vendor could change staff bank details (event), diverting salary payments and exposing staff personal information (impact).” Now the owner is obvious, the controls are obvious, and so is the indicator.
Inherent and residual ratings
Inherent risk is the rating before any controls are counted. Residual risk is the rating with your controls as they actually operate today, and it is the number decisions are made on.
The gap between the two shows how much work your controls are doing. A large gap resting on one control is a reason to test that control, because if it fails the residual rating is wrong.
Common failures in cyber risk registers
- Vague risks. “Ransomware” or “data breach” with no cause or impact. They cannot be treated, so they sit at High forever.
- No real owner. “IT” or “Security” in the owner column means nobody with budget authority has accepted anything.
- Findings logged as risks. “No MFA on the VPN” is a cause. The risk is what it lets an attacker do.
- Permanent “monitor”. A treatment with no due date is an acceptance nobody signed.
- Never reviewed. Ratings that have not changed while the business has.
How often to review a cyber risk register
Review risks outside appetite monthly with their owners, the full register quarterly, and the rating method once a year. Review early after an incident, an acquisition or a major system change.
The review is the point of the register. NIST Cybersecurity Framework 2.0 places risk management strategy in its Govern function, and a dated review record is what shows that governance happening.
Ratings only mean something against a line the board has drawn, which is what a cyber risk appetite statement provides. The indicators that go to the board are covered in cyber KRIs the board will read.
Questions we are asked
How often should a cyber risk register be reviewed?
Review risks outside appetite monthly with their owners, the full register quarterly, and the rating method once a year. Review early after an incident, an acquisition or a major system change.
Who should own a cyber risk?
The executive accountable for the business process the risk would damage. The security lead maintains the register and advises, but does not own every entry.
What is the difference between inherent and residual risk?
Inherent risk is the rating before any controls are counted. Residual risk is the rating with your controls as they actually operate today, and it is the number decisions are made on.
Should a risk register list vulnerabilities?
No. A vulnerability or a missing control is a cause. The register records the risk it creates and links to the findings that feed it. Supplier risks such as the payroll example also belong in a vendor risk management programme.
Building or rebuilding yours
We build registers, KRIs and board reporting as a cyber risk register service. Send the register you have and the reply says what would change. More writing is at writing.