Quick answerA risk register is the structured, living list of identified risks an organisation is tracking – with severity, likelihood, owner, treatment plan and review date. It is the central artefact of operational risk management and the input to almost every risk-related conversation: board reporting, audit, insurance, due diligence and incident response.
Definition and purpose
A risk register is a structured catalogue of risks the organisation has identified, scored, assigned and is actively managing. It is not a list of incidents (those are an incident register), and it is not a list of issues (issues are realised risks). It is the live picture of what could go wrong, how bad it would be, how likely, who’s responsible, and what’s being done.
What good registers contain
- Risk description – what could happen, what is the cause, what is the impact
- Category – operational, financial, strategic, compliance, security, privacy, AI, reputational
- Inherent score – likelihood × severity before controls
- Existing controls – what reduces the risk today
- Residual score – likelihood × severity after controls
- Risk owner – named accountable individual
- Treatment plan – accept, mitigate, transfer, avoid
- Linked actions and remediation tasks
- Review date – when this risk is next reassessed
Inherent vs residual risk
Inherent risk is the risk score before any controls are applied – what the risk would be in a world with no mitigations. Residual risk is the score after the controls in place are accounted for. The gap between the two demonstrates the value of the control framework. Reporting both is standard practice; reporting only one misleads.
Likelihood and severity scoring
Qualitative
Low / Medium / High or 1-5 scales. Simple, fast, intuitive. Limited precision but adequate for most organisations.
Quantitative
Expected loss in money terms, expected frequency in events per year. More rigorous but requires data that’s often missing.
Hybrid
Qualitative scales backed by quantitative anchors (‘High = likely to occur once every 5 years’). Most practical for mid-sized organisations.
Register hygiene
Three rules:
- Every risk has an owner. No owner means no management – delete it or assign it.
- Every risk has a review date. Risks expire. Re-review on the schedule.
- Treatment plans produce actions, not aspirations. ‘We should improve X’ is not a plan – ‘X owner will complete Y by date Z’ is.
Common pitfalls
- Listing risks at inconsistent granularity – some at programme level, some at activity level
- No owner, no review date, no treatment plan – risks that exist for documentation, not management
- Tracking risks without tracking the controls that mitigate them
- Inherent-only reporting (‘this is a high risk’) without residual reporting (‘after our controls, it is moderate’)
- Annual register reviews instead of continuous oversight
How PrivIQ supports risk registers
PrivIQ provides configurable risk registers across privacy, AI, third-party, operational and tailored domains. Each risk links to controls and assessments. Inherent and residual scoring is captured. Owners, treatment plans and review dates are first-class fields. Risks roll up into board-facing reporting.
- A risk register is the live catalogue of what could go wrong and what’s being done about it.
- Inherent and residual scoring should both be reported.
- Every risk needs an owner, a review date and a treatment plan. Otherwise it’s documentation, not management.
- Risks expire. Reassessment cycles matter as much as the initial entries.
PrivIQ helps organisations and consultants put this into practice — with policies, controls, evidence, tasks, registers and reporting that survive audit.
More on GRC & Operational.
What’s the difference between a risk register and an issue log?
Risks are things that could go wrong. Issues are risks that have materialised – already happening. Most organisations maintain both, with issues feeding back into the risk register to inform residual scoring.
How many risks should be in a register?
For an operational risk register, typically 30-150 in a mid-sized organisation. Fewer suggests the register is incomplete; many more suggests inconsistent granularity. Quality matters more than count.
Should AI risks be in the main risk register?
Yes – and often as a dedicated section. AI risks have distinct dynamics (model drift, hallucination, behavioural changes) but they should live alongside other operational risks for board reporting.
Who should own the risk register?
The risk function (Chief Risk Officer or equivalent) typically owns the register as a whole. Individual risks are owned by accountable business owners. The risk function curates, the business owns each entry.
How often should the risk register be reviewed?
Continuously, but with formal review cycles: tier-1 risks monthly or quarterly, tier-2 risks twice a year, tier-3 annually. Plus event triggers – incidents, material changes, new regulation.