How to Build a Risk Register From Scratch

Every framework — ISO 27001, SOC 2, NIST CSF — expects you to demonstrate that you’ve identified and assessed your risks somewhere. That “somewhere” is the risk register. Auditors don’t expect perfection here; they expect evidence of a repeatable process.

The minimum columns you need

At a minimum, a defensible risk register includes:

1. Risk ID — a short reference code so risks can be cited elsewhere (policies, meeting minutes, audit evidence).
2. Asset or process — what’s actually at risk (a system, a dataset, a vendor relationship).
3. Threat and vulnerability — what could go wrong, and the weakness that would let it happen.
4. Likelihood and impact — usually scored 1–5, with a documented definition for each level so scoring isn’t arbitrary.
5. Inherent risk score — likelihood × impact, before controls.
6. Existing controls — what’s already mitigating this risk.
7. Residual risk score — the score after those controls are accounted for.
8. Risk owner — a named person, not a team. Auditors will ask.
9. Treatment decision — accept, mitigate, transfer, or avoid.
10. Review date — risk registers go stale fast; this is what proves yours doesn’t.

Where teams usually go wrong

The most common gap isn’t missing columns — it’s inconsistent scoring. If “impact: 4” means something different depending on who filled in the row, an auditor will notice, and it undermines the whole exercise. Write a one-page scoring guide before you fill in a single risk, and reference it in the register itself.

The second common gap is treating the register as a one-time deliverable instead of a living document. A stale risk register with a “last reviewed” date from 18 months ago tells an auditor more about your program’s maturity than the risks themselves do.

Starting point

If you’d rather not build the scoring logic and column structure from zero, our Risk Register Template comes pre-built with the scoring guide, example rows, and formulas for inherent vs. residual risk baked in.