I walked into the risk management review and the register had 212 rows. Forty-seven columns. A colour-coded heat map that required a legend to read. The risk owner column listed fourteen different people across thirty rows. Nobody in the room had looked at it since the last audit.
The organisation had spent four months building it. They had hired a consultant. They had purchased a GRC platform. They were, by every measurable input, serious about risk management. And they had produced something that was completely useless for making decisions. Here is why.
In 35+ GRC engagements, the organisations that built the most complex risk registers produced the least useful risk intelligence. The pattern is consistent enough that I can now identify the failure from the first meeting. This article is about that pattern, what drives it, and the simpler approach that produces better decisions, better board reporting, and fewer audit surprises.
Why Risk Management Gets Overcomplicated
Risk management is the most feared discipline in GRC. Not because it is technically difficult. Because of a specific psychological pattern that plays out in almost every organisation I have worked with: people with enough intelligence to do risk management well convince themselves they are not competent enough to do it — not by lack of knowledge, but by choice. The word "risk" signals responsibility. Responsibility signals accountability. Accountability in a regulated environment signals liability.
So instead of building and owning a risk programme, practitioners stay in knowledge-gathering mode indefinitely. They attend trainings, read frameworks, collect templates — and then hand everything to a consultant because they have decided the actual work is too hard for them. The consultant then feeds the fear. Because a consultant whose work cannot be understood cannot be questioned. And a consultant who cannot be questioned stays engaged.
The result: a risk framework that is 47 columns wide. A risk library overloaded with hundreds of generic risks copied from templates, dressed up with unnecessary terminologies, and filed under categories nobody in the organisation can map to their actual operations. A risk management process so complicated it takes three days to run — producing equal or less useful output than a simpler process would have produced in three hours. This is the most absurd outcome in GRC. More complexity. More effort. Same or worse result.
A risk register with 20 well-understood, actively managed risks is worth more than a register with 200 risks nobody reads. Complexity and rigour are not the same thing.
The actual objective of risk management is disarmingly simple: get an accurate picture of the organisation's risk scenario and present it to management so they can make decisions — with the ultimate goal of smooth business operation with a minimum set of managed risks. Everything that does not serve that objective is noise. Most risk libraries are mostly noise.
The practitioner who builds the right risk register is not the one with the most comprehensive framework. It is the one with the confidence to say: "This is enough. This is what we need. Nothing else." That confidence comes from understanding what the register is actually for.
What a Risk Register Actually Needs to Contain
After naming the fear, the antidote is straightforward. A risk register needs exactly six things per risk. Not fourteen. Not forty-seven. Six. Everything beyond this is optional scaffolding — add it only if it genuinely improves decision-making for your specific organisation. If you add it because a consultant told you to, question it.
What could happen, in plain language. One or two sentences. No jargon. If a senior manager outside IT cannot understand it, rewrite it.
One person. Not a department. Not a committee. One named individual who is accountable for monitoring and treating this risk.
Simple 1–5 scale. Not a 47-variable calculation. The person assigning the score must be able to describe the specific scenario they are scoring.
To operations, to finances, to reputation — stated plainly. Connect it to business consequence, not just technical severity.
What is already in place to reduce this risk. Existing, verified controls only. "Policy exists" is not a control unless the policy is enforced and evidenced.
What is being done next. With a deadline. With an owner. A treatment action without both is not an action — it is a placeholder.
Everything else — inherent risk, residual risk, risk velocity, secondary owners, control maturity scores, framework mapping columns — is optional. It may be appropriate for a large financial institution with a mature risk function. It is rarely appropriate for a mid-market organisation building a risk register for the first time. Start with six. Add only when you can explain exactly which decision the additional column improves.
The Four Failure Patterns
In every engagement where risk management was broken, it was broken the same way — and it started before the first row of the risk register was written. The four patterns below account for nearly every non-functional risk register I have reviewed. Each one is observable before you open the spreadsheet.
Too Many Risks, None of Them Owned
A register with 200 risks and 14 owners. Owners who are responsible for 40 risks each are responsible for none of them. The register contains every conceivable risk the organisation could face — generic risks copied from templates, risks that have not been reviewed in two years, risks tagged to categories that don't map to anything the organisation actually does.
Triage is a skill. Most organisations treat triage as incompleteness. The result is a register that is comprehensive in the way a telephone directory is comprehensive — it contains everything and helps you find nothing.
Cut the register to the risks that matter. Every risk must have one named owner who knows they own it. If you cannot assign a meaningful owner, the risk is either too generic to be actionable or genuinely out of scope. Remove it or rewrite it.
Likelihood and Impact Scores Disconnected from Reality
Scoring a risk "Likelihood 2, Impact 4" without connecting it to a real scenario the organisation has experienced or credibly faces. The score is assigned because the template requires a score. Nobody can describe the specific event they are scoring.
Calibration matters. A likelihood score that cannot be tied to a specific threat scenario, a historical incident, or an observed vulnerability is fiction dressed as analysis. I have reviewed risk registers where the same risk received a "Likelihood 5" at one bank and a "Likelihood 2" at an organisation with almost identical controls — because nobody had agreed what the scale actually meant.
Before assigning a score, write one sentence describing the specific scenario. What happens? To which system? Under what conditions? If you cannot write that sentence, you do not yet understand the risk well enough to score it.
Treatment Actions That Never Move
"Implement MFA" has appeared on risk registers I have reviewed for three consecutive years. Same risk. Same action. Same status: In progress. A treatment action without a deadline, an owner, and a review cycle is not an action. It is a wish.
A risk register that takes three days to update will be updated twice a year. That is not a risk register. That is a compliance artefact. The treatment column in most registers I have reviewed is a graveyard of intentions. Open yours and count how many treatments have been "in progress" for more than six months.
Every treatment action must have three things: a named owner, a deadline, and a next review date. If a treatment has been open for more than six months, escalate it or formally accept the risk. There is no third option.
No Connection to Business Consequence
Every risk in the register is described in technical terms. "Inadequate patch management." "Insufficient access controls." "Weak encryption standards." These descriptions are accurate. They are also invisible to anyone outside the IT function.
A risk described entirely in technical terms will be managed by technical people and ignored by everyone else. The consequence is that risks which require business-level decisions — budget allocation, process change, third-party contract renegotiation — never reach the people who can make those decisions.
Every risk entry must include at least one sentence connecting it to business outcome: regulatory exposure, revenue impact, customer trust, or operational continuity. If you cannot write that sentence, you do not yet understand the risk well enough to put it in the register.
The Board Reporting Problem
The failure patterns all share one consequence: the risk register fails in the board room. Not because management doesn't care about risk — but because nobody made the translation between the technical risk and the business consequence management already cares about.
Here is the honest truth: management will hear what they want to hear. This is not a criticism of management — it is the operating reality. Senior management are business people. They think in revenue, reputation, and regulatory consequence. They were never trained to read a heat map. They will not engage with a presentation that asks them to learn a new language mid-meeting.
A presentation full of likelihood scores and heat maps, delivered in technical language, will get filed. Every time. Not because management doesn't care about risk — but because nobody translated it into terms they can act on. The practitioner's job is not to educate management about IT risk. It is to translate IT risk into the language management already uses — and end every presentation with a decision, not an update.
What that translation looks like in practice:
How risk is usually presented
- Privileged access management weakness — Likelihood 4, Impact 4, Heat map: Red
- Patch management gap — 47 systems unpatched beyond policy window — Risk score: High
- Third-party vendor access — control deficiency identified — likelihood and impact assessed as medium-high
How risk gets decisions made
- If an insider with elevated system access acts maliciously or carelessly, estimated exposure is [amount] in transaction fraud and [timeline] of operational disruption. Decision needed: approve quarterly access review budget or formally accept this risk.
- 47 systems outside the patch window. The three highest-severity unpatched vulnerabilities have publicly available exploits. Decision needed: approve emergency patching sprint this quarter or accept the documented residual risk.
- Two third-party vendors have direct access to the payment processing environment with no session monitoring in place. Decision needed: mandate session logging in next contract renewal or implement compensating controls before renewal.
Three elements every board risk summary must contain: the risk in one plain sentence with no technical jargon; the business consequence in money, reputation, or regulatory exposure; and the specific decision management needs to make. Without the third element, the first two are informational. With it, they are actionable.
For the broader control framework that underpins risk treatment decisions, the ISO 27001 framework reference covers Annex A controls in the context of how risk treatment options connect to specific control requirements. The
The Enough Principle: When to Stop Adding
Most risk management guidance tells you to add more: more columns, more scoring dimensions, more treatment options, more review cycles. This is wrong. A risk register is not more rigorous because it is more complex. It is more rigorous when it is more used. And registers that are used are registers that are simple enough to maintain without heroic effort.
The practitioners who build the most effective risk programmes are not the ones who knew every methodology. They are the ones who knew when to stop. The enough principle is the practitioner skill that no certification teaches and no template can give you. Here is how to apply it.
Three tests. If your risk register passes all three, it is the right size. If it fails any one of them, it is too complex — regardless of how comprehensive it is.
- Every risk has one named owner who knows they own it — and can describe the risk in their own words without reading the register entry.
- Every treatment action has a deadline that is being actively tracked — not "in progress" with no date attached.
- Management can read the executive summary in under 10 minutes and identify a specific decision they need to make.
Tap each step as you prepare. Progress saves in your browser.
If your register fails the third test, the problem is usually the board reporting translation — covered in Section 4. If it fails the first or second, the problem is scope and ownership. Cut the register until every remaining risk passes all three tests. Then — and only then — consider whether additional complexity adds value.
The same principle applies to the risk treatment options ISO 27001 Clause 6.1 defines: accept, avoid, transfer, and mitigate. Each option requires a documented decision. If you cannot point to a documented decision for every high-rated risk in your register, the register is not functioning — regardless of how well-formatted it is. For the NIST Risk Management Framework parallel, the NIST RMF applies equivalent structure to federal information systems and provides a useful cross-reference for organisations that operate under both ISO and NIST guidance.
A risk register is not a document you build to satisfy an auditor. It is a tool you maintain to help management make better decisions. If it is not doing the second thing, it is failing at the first.