The easiest way to understand a risk register is to look at one row. Everything else, from scoring methods to review cycles, exists to keep rows like this accurate and acted upon. Below is a realistic information security entry for a mid-sized SaaS company.
Sample risk register entry
Why the risk statement is written that way
A good statement names a cause, an event, and a consequence. Vague entries such as insider threat or cloud risk cannot be scored consistently or assigned to anyone, so they sit untouched. The cause-event-consequence pattern also points directly at a treatment: here, the cause is a manual process, so the fix is automation. Note the score is recorded three times, as inherent, residual, and target, so progress is visible.
The life of an entry
- Identified through a risk assessment workshop, an incident, an audit finding, or a vendor review.
- Analyzed using the likelihood and impact scales defined in your methodology, so two assessors reach similar scores.
- Treated with one of four decisions: mitigate, transfer, avoid, or accept. Each links to a named owner and a date.
- Linked to the controls that reduce it, which is how the register connects to your compliance evidence.
- Reviewed on a set cadence and whenever something material changes, with the date recorded.
- Closed or accepted once the target is reached or the residual level is formally signed off by the risk owner.
Mistakes that show up in audits
- Risks owned by a team or by the security function in general rather than a named person
- Scores that never change between reviews, suggesting nobody looked
- Treatment plans with no due date, or due dates long past with status still open
- Accepted risks without a record of who accepted them and when
- No written methodology, so scores cannot be reproduced
- Hundreds of near-duplicate entries copied from a generic threat catalogue
Where it fits
For ISO 27001, the register is the working record behind clause 6.1.2 risk assessment and 6.1.3 risk treatment, and it drives which Annex A controls appear in your Statement of Applicability. SOC 2 expects a documented risk assessment under the Common Criteria as well. Start with the free risk register template and risk assessment methodology, then follow building a risk register for the full process.
In Asurvo, the risk register sits in the Risk Management product with inherent, residual, and target scoring, treatment plans with owners and deadlines, and heatmaps to show movement over time.