How to build a risk register people actually use

The risk register is meant to be the centre of an information security program. It's the reason controls exist, the place decisions get recorded, and the first thing a good auditor asks for. In most small and mid sized companies it is also the least used document in the program.

A long generic register is worse than a short honest one. Twenty real risks with owners and linked controls will run your security program. A hundred and twenty template rows will only pass an audit, and barely.

I've built and audited risk registers for ISO 27001 programs in fintech and healthcare, and the useful ones always fit on a single screen.

What the standards require

ISO 27001 clause 6.1.2 requires a defined risk assessment process with criteria for accepting risk, consistent and comparable results, identified risk owners, and analysis of likelihood and consequence. Clause 6.1.3 requires a treatment plan and the Statement of Applicability. Clause 8.2 requires assessments at planned intervals and when significant changes occur.

SOC 2's common criteria CC3.1 to CC3.4 ask the same things in different words: specify objectives, identify and analyse risks, consider fraud risk, and identify changes that could affect the control system.

Neither standard asks for 120 rows. Both ask for a process people follow.

How registers go wrong

They start from a template library and keep every row. "Earthquake" is scored for a company with no office. "Pandemic" from 2020 is still there.

Scoring becomes theatre. On a 5 by 5 matrix, everything drifts to the middle, likelihood 3 and impact 4, because nobody wants to defend a 5 or admit a 1.

Risks don't connect to controls. A risk says "unauthorised access to customer data" and nothing in the register says which controls reduce it or whether they work. The same request appears on open source GRC trackers, users asking for risks to link to the controls that are actually applied.

Nobody reviews it between audits. If you've ever updated the "last reviewed" date on your register without changing anything else, you've done the most common risk management activity in the industry.

Building one that works

Start from your business, not a library. What would hurt most: customer data exposed, a regulator's finding, a key system down for a day, a large customer lost after a security review? Write those as risks in plain language.

Keep it to fifteen to twenty five risks. Merge the near duplicates.

Give each risk an owner who can make decisions about it, not just the security person.

Link each risk to the controls that treat it, so a failing control shows which risks just got worse.

Write down what would trigger a review: a new vendor with customer data, a new product, an incident, a new regulation. Review the top risks every quarter and the whole register yearly.

That link between risks and controls matters: a failing control and the risks it was holding down should be visible together. It is the difference between a register and a list.

A risk register nobody opens is an inventory of things you've agreed not to think about.