Ask ten early-stage teams for their risk register and you'll get ten spreadsheets, most of them last touched the week before an audit. Both SOC 2 (Common Criteria CC3) and ISO 27001 (clauses 6.1.2 and 8.2) expect something better: a risk assessment you actually maintain, with a repeatable method behind the numbers. Here's how to build one that holds up.

Start with a scoring method, not a list

The mistake is jumping straight to listing risks. Start instead with how you'll score them, because a register where every risk is "high" tells an auditor nothing. The standard approach is likelihood × impact:

  • Likelihood: how probable is this, on a fixed scale (e.g. Rare, Unlikely, Possible, Likely, Almost certain).
  • Impact: how bad if it happens, on a matching scale (Insignificant → Severe).

Multiply the two and you get a score that sorts your register by what actually deserves attention. A 5×5 matrix gives you enough resolution without false precision. Plot every risk on that grid and the heat map does the triage for you. The top-right corner is where your quarter goes.

Write risks as scenarios, not categories

"Cybersecurity" is not a risk. "An attacker gains access to production through a former employee's un-revoked credentials" is. Good risk statements name a threat, an asset, and a consequence, specific enough that someone could actually do something about it. Aim for 15–40 real scenarios to start; you can always add more as you learn.

Assign a treatment and an owner to every risk

For each risk, pick a treatment:

  • Mitigate: reduce it with controls (the common case).
  • Accept: acknowledge and live with it, with sign-off.
  • Transfer: insurance, or push it to a provider.
  • Avoid: stop doing the thing that creates it.

Then give it an owner. A risk with no owner is a risk nobody is managing, and auditors notice.

Link risks to the controls that treat them

This is the step that turns a list into a program. Every mitigated risk should point to the controls that bring it down, and those controls carry their own evidence. Now your story is complete: here's the risk, here's what we do about it, here's proof we do it. When you assess the residual (post-treatment) risk, a well-mitigated item visibly drops out of the high band, which is exactly what a reviewer wants to see.

Keep it alive

A register is a living document. Revisit it on a cadence (quarterly is common), when something changes materially, and after any incident. The spreadsheet version rots because updating it is a chore; the version that lives next to your controls and evidence stays current because it's part of the work.

How Keel helps

Keel's risk register does the mechanical parts for you: a 5×5 likelihood × impact heat map that uses your effective (residual) score, treatments and owners, and a direct link from each risk to the controls that mitigate it. If you're staring at a blank register, Keel's AI will draft a set of concrete, pre-scored risks from your business context to get you started, and you keep the ones that apply and discard the rest.

Because the same controls are crosswalked across SOC 2, ISO 27001, and every other framework you enable, the risk work you do once counts everywhere.

Start free (no credit card) and turn your risk spreadsheet into a living register auditors accept.