Building a Risk Register That Survives Contact With an Audit

Almost every organisation pursuing ISO/IEC 27001 or a similar framework builds a risk register at some point in the project. Far fewer keep it alive afterward — and an auditor can usually tell within the first ten minutes of review which category yours falls into.

The tell-tale signs of a register built only for the audit: risk ratings that haven’t changed since the original assessment; treatment plans with no owner, no target date, or an owner who left the organisation eighteen months ago; and risks that were “accepted” with no documented rationale or re-review date. None of this is necessarily dishonest — it’s what happens by default when a risk register is treated as a one-time deliverable rather than an operating tool.

What a living risk register actually requires:

• A defined review cadence — monthly or quarterly, not “as needed.” “As needed” reliably means “not reviewed.”
• Named ownership per risk, not per category. “IT” is not an owner; a person with the authority to act on the risk is.
• Risk scoring that reflects both likelihood and business impact, not a generic severity label copied from a vulnerability scanner. A finding rated Critical by CVSS on an isolated development server is a different business risk than a Medium-rated finding on a system holding customer payment data.
• A closed loop with technical testing. Findings from penetration testing, internal audit, and vendor risk assessments should land in the same register — not three separate spreadsheets that never reconcile.
• Evidence of management review, not just the register itself. An auditor will ask to see minutes or sign-off showing leadership actually looked at the top risks, not just that a document exists.

Why this matters beyond the audit. A risk register that’s actually maintained is one of the few artefacts that gives leadership an honest, current view of where the organisation is exposed — which is the entire point of running an ISMS in the first place. A register that only gets opened once a year, right before the surveillance audit, tells you the certification is current but tells leadership almost nothing useful about actual risk posture in between.

The practical fix for most organisations isn’t a better spreadsheet — it’s a defined operating rhythm: who reviews the register, how often, what triggers an off-cycle update (a new penetration test finding, a new regulatory requirement, a significant infrastructure change), and who signs off that the review happened. That operating rhythm is usually the difference between a register that’s a compliance artefact and one that’s a governance tool.