What is a risk register?

What is a risk register?

A risk register is the log of risks an organisation has identified, each carrying an owner, an assessment of likelihood and impact, a treatment decision, and a residual score after treatment. It is the central artifact of a risk management programme and usually the first thing an auditor asks for under SOC 2 CC3 or ISO 27001 clause 6.1. Its purpose is to show that risks were identified, decided on, and owned, not merely listed.

The fields that matter

Field	Why it is there
Risk description	What could go wrong, stated specifically enough to act on
Asset or objective affected	What it threatens
Owner	A named person, not a team
Inherent likelihood and impact	Exposure before controls
Treatment	Avoid, reduce, transfer, accept, or share
Controls applied	What actually mitigates it
Residual likelihood and impact	What remains after treatment
Review date	When it was last looked at

The failure auditors find most often

Blank inherent and residual scores. A register with well-written risks, assigned owners, and sensible treatment plans, and no numbers, is extremely common in young programmes. It fails because without both scores you cannot show that treatment changed anything, and the whole point of recording residual risk is to evidence that the controls did something.

The second most common: acceptance with no record of who accepted it. Accepting a risk is a legitimate treatment and auditors see it constantly. What fails is an undocumented acceptance, because from the outside it is indistinguishable from having missed the risk.

Scoring without overengineering

A 5x5 likelihood-by-impact matrix is the common default and is entirely sufficient. What matters is that the scale is defined somewhere and applied consistently, not that it is sophisticated. An auditor will ask what a 4 means. "High" is not an answer; "more likely than not within 12 months" is.

Quantitative methods exist and are rarely worth it below a certain size. A qualitative matrix, applied consistently and reviewed on schedule, passes every audit a small company will face.

What the register connects to

• Treatments come from the five options: avoid, reduce, transfer, accept, share. See what are the five risk mitigation strategies.
• Controls implemented as treatment are the same controls your framework tests.
• Vendors are a risk category of their own, usually tracked in a separate register. See what are the 5 stages of third party management.

Where frameworks require it

Framework	Requirement
SOC 2	CC3 series, risk identification and analysis
ISO 27001	Clause 6.1, plus a documented risk assessment methodology
HIPAA	Security Rule risk analysis, the most cited enforcement gap
NIST 800-53	RA family

ISO is the strictest: it wants the methodology documented, not just the output, so that the assessment is repeatable by someone else.