BlogThe purpose of a risk register: decisions, not a spreadsheet graveyard
GRC

The purpose of a risk register: decisions, not a spreadsheet graveyard

Most risk registers are written to pass an audit, then frozen. Why the purpose is decisions, and four moves to bring yours back to life.

Harry WestFounder & CEO4 March 20268 min read
Inside This Article
Why is "fill it in and review it once a year" the wrong standard?Why do most risk registers die after the first audit?What do ISO 27001 and ISO 31000 actually ask for?What keeps a risk register alive?What's the strongest objection to a living register?What should you do about it this quarter?The test for your register
Book a discovery call

Key takeaways

The purpose of a risk register is to support decisions: who owns each risk, what the firm chose to do about it, and whether that still holds. Registers built only to pass an audit stop being read. ISO 27001 already expects named owners, reassessment on significant change and risk results in management review.

The test
Pick any risk. Can you name who decided what to do about it, when, and what would prompt a fresh decision? If not, the register is just a record.
ISO 27001
Clause 6.1.3 asks risk owners to approve the treatment plan and accept residual risk; Clause 8.2 asks for reassessment at planned intervals and on significant change.
NCSC guidance
The NCSC treats risk management as a continuous process: revisit risk assessments and controls at regular intervals, and immediately when something significant changes.
Four habits
Owners who must decide, reviews driven by change and by the meetings that set priorities, risks wired to controls you can see, and accepted risks that expire.

The purpose of a risk register is to support decisions: who owns each risk, what the firm has chosen to do about it, and whether that is still the right call. Most registers fail that purpose. They are written to pass an audit, then left frozen at the point they were written. If your firm built its register for a first ISO 27001 or SOC 2 audit and has barely opened it since, you don't have a decision tool. You have a spreadsheet graveyard, and the first enterprise customer who asks how your risks are owned will find it.

That's a harder line than most guidance takes. Here's why I hold it, the strongest argument against it, and what I'd change this quarter.

Why is "fill it in and review it once a year" the wrong standard?

Because it treats the register as the product. The usual view is reasonable on its face: ISO 27001 asks for documented risk assessment results and a treatment plan, so you build the register, the auditor samples it, you review it once a year, and the certificate follows. But the product should be the decisions the register records, not the file.

A register built for the auditor answers the auditor's question: does a risk process exist? It doesn't answer the questions the business needs answered this month. Which risks are getting worse? Who has agreed to live with which exposure? Is the control we rely on still working? The NCSC makes the same distinction. Its risk management guidance argues for risk management that shows "the real cyber risks that are applicable to your organisation", "rather than the use of techniques which just seek to satisfy compliance requirements".

Why do most risk registers die after the first audit?

Most risk registers die because nothing after audit day makes anyone use them. There are five common reasons, and none of them is the spreadsheet. Each one cuts the register off from a decision, and a register with no decision attached stops being read.

  • It was built for the auditor. The register was written to show a process existed on audit day. Nobody designed it to be read after that.
  • The wrong person owns it. The compliance lead maintains it. The people who actually run the risk, the CTO, head of engineering or operations lead, never touch it.
  • The scores can't be defended. A risk is marked "medium" because it was medium last year. Ask why, and nobody can say what evidence would move it.
  • Risks aren't wired to controls. The register says a risk is treated by a control, but nobody can see whether that control is working today.
  • No meeting reads it. The register never appears where budget, hiring or roadmap priorities are set. So it never changes them.

I've said this before in public: risk registers are static documents in a dynamic world, frozen at the point they were written. Your systems change week to week. Your register changes once a year. The gap between the two is where your real risk sits.

What do ISO 27001 and ISO 31000 actually ask for?

The standards set a higher bar than the document most firms keep. ISO 27001 expects named risk owners, owner approval of the treatment plan and of residual risk, reassessment when significant changes happen, and risk results in management review. ISO 31000 describes risk management as dynamic. That is a living process, not a file.

Read the clauses as a sequence rather than a checklist:

  1. Clause 6.1.2 asks you to identify risk owners. An owner is a person who can decide, not a name in a column.
  2. Clause 6.1.3 asks those owners to approve the treatment plan and accept the residual risk. That is a decision with a name against it.
  3. Clause 8.2 asks for risk assessments at planned intervals and when significant changes are proposed or happen. Change is a trigger, not just the calendar.
  4. Clause 9.3.2 puts risk assessment results and the status of the treatment plan on the management review agenda. Top management is meant to see where the risks stand.

ISO 31000 frames the same idea as a principle: risks emerge, change and disappear as the context changes, and risk management should respond. The UK government's Orange Book makes the link to decisions explicit. Its Principle B says risk management "shall be an integral part of all organisational activities to support decision-making in achieving objectives".

None of these texts asks for a document you dust off once a year. A register that passes the audit but drives no decision meets the letter of ISO 27001 and misses its point.

What keeps a risk register alive?

A risk register stays alive when each entry is tied to a decision someone has to make. That means four habits: owners who must decide, reviews driven by change and by the meetings that set priorities, risks wired to controls you can see, and accepted risks that expire.

Owners who must decide. Give each risk to the person who controls the budget or the system it depends on. That person accepts, treats or escalates it, and their name sits against the choice.

Reviews driven by change. The NCSC's basic risk method says to revisit risk assessments "at regular intervals and immediately when something significant changes". A significant change in the business should reopen the register. The anniversary of the last audit shouldn't be the only trigger.

Risks wired to controls you can see. The question isn't whether your controls are working. It's whether you'd know if they stopped. Link each serious risk to the control that treats it and to an indicator that shows that control's state. Key risk indicators are how you build that early warning.

Accepted risks that expire. Accepting a risk is a legitimate choice. Accepting it forever is not. Give each acceptance a review date, so it comes back for a fresh decision instead of fading into the background. Acceptance is one of the treatment options. It should be the most closely watched, not the least.

What's the strongest objection to a living register?

The strongest objection is time. Picture a 40-person tech firm with no risk team. The CTO is also running engineering, and the compliance lead is also running IT. A spreadsheet reviewed once a year is the honest level of effort a firm that size can sustain. Anything more sounds like enterprise overhead.

It's a fair point, and I'd accept it if the alternative were more paperwork. It isn't. The spreadsheet is not the problem. The missing decision is. A spreadsheet with ten risks, each with an owner, a linked control and a date, is a living register. A platform with two hundred risks that nobody reads is a graveyard with better formatting.

A small firm usually has fewer risks that matter and shorter paths to the people who decide. That makes a living register easier for a 40-person firm, not harder. What it takes is a slot on an agenda that already exists, not a new process. Run the register to cadence, not to panic. The panic version costs far more, usually in the weeks before a surveillance audit or a customer's security review.

What should you do about it this quarter?

Four moves, in order:

  1. Cut the register to the risks someone would act on. If a risk would never change a decision, archive it. A shorter register that people read beats a long one that they don't.
  2. Put a deciding owner against every remaining risk. Use the person who holds the budget or the system, not the person who maintains the spreadsheet. Ask each owner to confirm their treatment choice in writing.
  3. Put the register on an agenda that already sets priorities. Use the leadership meeting, the quarterly planning session or the management review. Bring the risks that moved, the acceptances that are due and the controls that failed. Check each against your risk appetite.
  4. Date every acceptance and wire every serious risk to a visible control. When an acceptance expires, the owner decides again. When a control fails, the risk it treats goes back to its owner straight away, not at the next annual review.

None of this needs a new tool. It needs decisions, written down, with a name and a date against each one.

The test for your register

Open your register and pick any risk. Can you name the person who decided what to do about it, when they decided, and what would make them decide again? If you can, the register is doing its job. If you can't, it's a record of what you knew on audit day.

For the column-by-column how-to, from risk statements to the link with your Statement of Applicability, our risk register guide covers it, alongside the rest of our risk management guides.

Profile image for Harry West, Founder and CEO of GRCMANA
Author

Harry West

Harry is the founder of GRCMANA, he helps regulated service providers close the enterprise trust gap — turning GRC, cyber resilience and AI governance from paperwork exercises into shippable systems.

GRCMANA
  • About
  • Insights
  • Contact
Ask the Trust ArchitectBook a Call →
  • About
  • Insights
  • The Vault
    Compliance VaultCyber Essentials→ISO 27001→SOC 2→ISO 42001→
    Domain VaultGRC Fundamentals→Risk Management→AI Governance→GRC Engineering→
    Other ResourcesFree Tools→Templates→Newsletter→
  • Contact
Book a Call →Ask the Trust ArchitectFixed fee. ISO 27001 in as few as six weeks.
GRCMANA

Helping high-growth B2B tech startups close the Enterprise Trust Gap through security, governance, and AI resilience.

ISO 27001ISO 42001ISO 9001Cyber EssentialsEU AI Act ReadyNIST AI RMF

The Vault

GRC EngineeringAI GovernanceISO 27001ISO 42001All Vault Resources

Resources

BlogFree ToolsTemplatesNewsletter

Company

About GRCMANAContactPrivacy PolicyTerms & ConditionsCookie Policy
© 2025 GRCMANA · All rights reservedRegistered in England & Wales under company registration 16810805. VAT Registration 506308024