A risk register is a structured, living record of every identified risk to a system or organisation — each one scored, assigned an owner, and tracked through to mitigation or formal acceptance. It's the artifact that turns "we found some threats" into something a security team, an auditor, and a leadership team can all actually use.
Quick definition: A risk register is a tracked list of risks, each with a description, a likelihood and impact score, an owner, a status, and a mitigation plan — reviewed and updated on an ongoing basis, not written once and filed away.
The fields a real risk register needs
- Description — what the risk actually is, specific enough to act on ("SQL injection possible via the search endpoint's sort parameter," not "database security").
- Likelihood & impact — typically scored on a simple scale (e.g. 1-5 each), multiplied together to get an overall severity used for prioritisation.
- Owner — a named person or team responsible for driving the risk to closure. A risk with no owner rarely gets fixed.
- Status — open, in progress, mitigated, or formally accepted. "Accepted" is a legitimate outcome for a low-severity risk that isn't worth the engineering cost to fix — as long as it's a deliberate decision, not silence.
- Mitigation / controls — what's being done (or already in place) to reduce the risk, ideally mapped to a recognised control framework (e.g. NIST, ISO 27001 Annex A) for audit purposes.
- Linked evidence — where the risk came from: the specific attack-tree node or DFD element it traces back to, so anyone reviewing it later can see the reasoning, not just the conclusion.
Want to try this yourself? Grab our free Risk Register template — all the columns above, plus six worked example rows, no signup required.
Risk register vs. a raw list of threats
A brainstormed list of threats from a workshop is a snapshot. A risk register is a living document: it gets reviewed on a cadence, updated as the system changes, and used to actually track work to completion. The difference matters most during an audit — SOC 2 and ISO 27001 assessors specifically want to see continuous risk management, not a spreadsheet last touched during onboarding.
The most defensible risk registers aren't built from scratch in a spreadsheet — they're generated directly from a threat model. Every leaf node in an attack tree that's scored above your threshold becomes a risk-register entry automatically, which keeps the register grounded in actual system analysis instead of whatever risks happen to be top of mind that quarter.
Who actually uses it
A good risk register serves three audiences at once: the security/engineering team uses it as a prioritised backlog of what to fix next; auditors use it as evidence of continuous risk management for SOC 2, ISO 27001, or PCI-DSS; and leadership uses the rolled-up severity counts to understand overall exposure without reading every individual entry.
For a full walkthrough of turning a completed threat model into a living risk register — and keeping it alive as the system evolves — see From Threat Model to Risk Register — Closing the Loop with ThreatTree.