Your Board Doesn't Want a Heat Map

Somewhere in most quarterly board packs is a five-by-five grid with a scatter of coloured squares. It has survived two decades of criticism because it looks like a summary, it fits on a slide, and nobody has to defend a number. It also collapses at the exact moment it is supposed to help.

The failure is not imprecision — everyone in the room knows the estimate is rough. The failure is structural: the output cannot be used for the operation the board is about to perform.

Three things a heat map cannot do

It cannot be aggregated

Fourteen amber risks do not sum to anything. There is no arithmetic that turns a set of ordinal ratings into a portfolio position, which means the board cannot be told what the organisation's total cyber exposure is. Every other risk category on the agenda — credit, market, operational — arrives with a total. Cyber arrives with a picture.

It cannot be compared across categories

Is a high-likelihood, medium-impact vendor risk worse than a low-likelihood, high-impact ransomware scenario? The grid places them in different cells and stops. Any actual answer requires a common unit, and colour is not one.

It cannot be traded off against cost

This is the one that matters. When the CISO asks for ₹8 crore to fund an identity programme, the board is performing a return calculation whether or not anyone says so out loud. Moving a square from red to amber is not a return. It cannot be compared against the same ₹8 crore spent on distribution, hiring, or debt reduction — so the request gets decided on narrative and the confidence of whoever is presenting.

A heat map answers “how worried should we be?” The board is asking “how much should we spend, and on which thing first?”

What boards actually ask

Strip away the phrasing and directors are asking three questions, consistently, across every organisation:

1. What could this cost us? Not the worst case reported in the press — the plausible range for us, given our size, sector and controls.
2. Are we spending the right amount? Too little is negligence. Too much is capital that should have gone somewhere else. Both are failures of governance.
3. Is it getting better or worse? A direction of travel, measured the same way each quarter, that survives a change of CISO.

None of these can be answered in colour. All three can be answered in currency.

What replaces the grid

The substitute is not a single number — a point estimate invites an argument about the last digit and deserves one. It is a loss exceedance curve: for any given loss amount, the probability that annual losses exceed it.

That one artefact answers all three questions. It gives a range with probabilities attached rather than a worst case. It lets a proposed control be evaluated by how much it shifts the curve, against what it costs. And re-run each quarter with the same method, its movement is a genuine trend rather than a change in how anxious the author was that month.

A worked shape, not a benchmark

Consider a mid-sized financial services firm modelling a ransomware scenario against its core processing environment. The decomposition might produce something like: an event roughly once every eight years; when it happens, a 90% confidence range of ₹12 crore to ₹85 crore in combined response, downtime, regulatory and customer-attrition losses; a long tail driven by the possibility of a multi-week outage during a settlement period.

The figures are illustrative — your own decomposition will produce different ones, and should. What matters is the shape of what the board now has. A ₹6 crore segmentation project that halves the probability of the multi-week tail is no longer a technical request. It is a proposition with a return, arguable on the same terms as any other capital allocation, and refusable on those terms too.

Getting there without a two-year programme

The most common way this fails is over-scoping. A team decides to quantify the entire risk register, spends eight months building a model nobody has asked for, and presents it to a board that has lost interest. A better sequence:

• Pick three scenarios. The ones the executive team already worries about out loud. Ransomware on the crown-jewel system, a major third-party failure, and a data exposure involving regulated personal data is a common opening set.
• Decompose before you estimate. Break each into frequency and magnitude, then into their components, so estimates are made about things people actually know rather than about “risk” in the abstract.
• Use ranges, and calibrate the estimators. Ninety-percent confidence intervals from people trained to produce them. The training takes half a day and improves everything downstream.
• Show the assumptions on the same page as the answer. A model whose inputs are hidden gets attacked as a black box. One whose inputs are visible gets argued with — and arguing with it is the point.
• Re-run it quarterly, unchanged. Method stability is what converts a one-off analysis into a trend line.

The real change is who gets to decide

There is a version of this argument that is purely about rigour. It is not the important one. The important consequence is political: a security function that reports in currency is participating in capital allocation, and one that reports in colour is asking to be trusted.

Being trusted works until it does not — until a cost programme, a change of CFO, or a competing investment case arrives with numbers attached. The teams that keep their funding through those moments are the ones that already speak the language the decision is being made in.

If you want to see what the output looks like against your own environment before committing to anything, our lightweight quantification tool produces a FAIR-based estimate in about five minutes, and the maturity self-assessment shows where the gaps are that would undermine the model.