The Document That Makes Boards Feel Safe While Achieving Nothing
Every quarter, audit committees across Australia receive a cyber risk report. It contains a colour-coded matrix — greens, ambers, reds arranged in a grid — and someone from IT or security presents it with confidence. The board asks a few questions, notes that the red items have remediation plans attached, and moves on. Governance box: ticked.
The problem is that the document is largely fiction, and the people producing it often know it. iTnews recently covered Luke Irwin’s argument that traditional cyber risk assessment is broken. He’s right, but the more important question — the one rarely asked — is who benefits from keeping the broken system in place.
Where the Heatmap Actually Came From
The risk heatmap was borrowed from occupational health and safety, where it works reasonably well. If you’re assessing the likelihood of a forklift striking a pedestrian in a warehouse, you have historical incident data, injury statistics, and a controlled physical environment. Likelihood and impact can be estimated with genuine empirical grounding.
Cyber risk has none of that. When a CISO assigns a “likelihood: medium” to a ransomware event, that number comes from intuition, industry reports with selection bias built in, and a desire not to alarm the board unduly. When they assign “impact: high,” they’re guessing at operational disruption, recovery costs, regulatory exposure, and reputational damage simultaneously — and aggregating those guesses into a single colour. The methodology looks rigorous. It isn’t.
None of that is a criticism of CISOs. It is a criticism of a tool that was never fit for this domain. Nobody can reliably quantify the probability of a capable threat actor compromising a specific organisation in a specific quarter, and anyone claiming otherwise has something to sell.
The Liability Shield Function
What the heatmap reliably produces is a paper trail showing the organisation was thinking about cyber risk. That is its real function — not guiding resource allocation, and not reducing risk, but evidencing that governance occurred.
Which is genuinely useful, in litigation, to a regulator asking whether a board discharged its duties, and to an auditor signing off controls. CPS 234, SOCI obligations and the Privacy Act’s accountability principle all require boards to show they considered cyber risk, and a heatmap with remediation actions attached discharges that neatly. Whether those remediation actions mean anything is a separate question, and it is not usually on the agenda.
The result is a compliance theatre loop: security teams produce the document because it satisfies the board, the board accepts it because it looks credible, and neither party interrogates whether the underlying methodology tells them anything useful about actual exposure.
What Audit Committees Are Approving
When a board receives a heatmap and approves the remediation plan for a red-rated risk, they are approving a response to a number that was invented, scaled against an impact assessment that was also invented, prioritised against other invented numbers. The decisions about where to spend money, where to accept risk, and what to escalate all flow from this foundation.
This matters beyond process hygiene. APRA-regulated entities are required under CPS 234 to maintain an information security capability commensurate with the size and extent of threats. If the threat assessment is methodologically unsound, the capability decisions built on it are unsound by extension. The OAIC’s enforcement posture under the Privacy Act has also shifted — attributing a breach to inadequate risk assessment is no longer a theoretical liability, it’s a live one.
Boards who have relied on heatmaps as governance evidence may find, in a post-breach environment, that regulators are less impressed by the document than they expected.
What a Credible Alternative Looks Like
Structured risk assessment is worth keeping. What has to go is the pretence that qualitative estimates rendered in colour amount to quantitative analysis.
Ask for scenario-based discussion instead of matrix outputs. A ransomware event taking core systems offline for a fortnight. Exfiltration of customer records at scale. A compromise arriving through a critical supplier. Each of those gives a board something concrete to push on: what does recovery cost, which notifications are triggered, and what would we actually do on the morning it happens? Those questions surface the gaps a heatmap smooths over.
Boards should also ask what assumptions underpin the likelihood ratings. If the answer is “industry benchmarks and professional judgement,” the follow-up question is what specific threat intelligence or historical data those benchmarks are derived from. Vague answers are informative — they tell you the number has no empirical foundation.
The organisations doing this well are separating their compliance reporting from their actual risk discussion. They produce what regulators need to see, and they separately ask hard operational questions in a different forum, with different documentation standards.
The Uncomfortable Ask
If you’re an audit committee director reading this, the ask is direct: the next time a cyber risk report is presented to your board, don’t assess it by whether it looks comprehensive. Assess it by whether it would change any decisions if the numbers were different.
If moving a risk from amber to red would change investment or strategy, the tool is doing something. If the response to every rating is that management is monitoring it, what you have is a record that a conversation took place, and a fairly thin one.
The heatmap is not going anywhere. Regulators implicitly endorse it, auditors accept it, and it is far too embedded in reporting cycles to pull out quickly. Boards that read it as a genuine picture of their exposure are making decisions on attractive guesswork, and knowing that is most of the remedy. The rest is asking questions the document was never designed to answer.