A risk register is the structured record of the risks an organization has identified, who owns them, how they are rated, and what is being done about them. Every governance framework requires one. Most organizations have one that nobody uses between review cycles.
A description specific enough to be measurable. “Cyber risk” is not a risk. “Ransomware encrypts production systems and disrupts customer service for more than four hours” is.
An owner, from the business rather than from security, since the business carries the consequence.
Inherent and residual ratings, with the reasoning for the difference recorded rather than implied.
The measures relied on to reduce it.
The indicators that would show exposure changing. See KRI.
A review date and a record of what changed at the last review.
The ratings never move. A register where every entry has held the same rating for three years is not tracking anything. It is documenting an opinion formed once.
The entries are too abstract to measure. If a risk cannot be connected to an observable indicator, its rating can only ever be a judgement, and judgements do not update on their own.
Ownership sits with security. A register owned entirely by the security function is a security function’s list of concerns, not the organization’s record of what it is carrying.
And review becomes ceremonial. Quarterly meetings that confirm the ratings are unchanged train everyone that the register is an artifact rather than a tool.
Attach indicators to entries and let the indicators move the conversation. A risk whose KRIs have deteriorated for two quarters should not be rated the same as one whose have not, and the register should show that without anyone having to argue for it.
Record what changed and why at each review, so the register carries a history rather than only a current state.
Tie thresholds back to the appetite statement, so escalation is driven by the organization’s own stated position rather than by the security team’s concern.
From the blog