From Heat Maps to Decisions

A written walk-through of the talk I gave at V2 Security Copenhagen — what’s broken in how most organizations do GRC today, and what replaces the heatmap. Long-form, ~1,800 words. If you were in the room, this is the written record. If you weren’t, the talk is the artifact this article describes — you don’t need to have seen it.

---

Before I started the talk, I asked the audience three questions.

Is your security posture aligned with where the organization is going?

Can your GRC program tell you which threats actually matter to your specific business strategy?

Can it give leadership the data to make informed security decisions?

For most organizations, the honest answer is no. Not because of a lack of effort — but because compliance has become the dominant lens. That’s what the talk was about, and that’s what this article is about. The shape of the argument is a story. Let me tell you about Maria.

Maria’s First Meeting

It’s a Tuesday afternoon in October. Quarterly risk review. You know this meeting.

Maria is a GRC analyst. She’s been preparing for two weeks. She’s consolidated input from six analysts across IT security, legal, and operations. She’s updated the risk register — forty-seven risks, all scored on the standard likelihood-by-impact matrix. The heatmap is ready. The executive summary is written. Twelve risks in red. Eight in amber. The rest in green and yellow.

The problem is not Maria. Maria is the competent version of everyone in this room. The problem is the system she’s working in.

The CFO opens with the count. “We had eleven red risks last quarter. Now we have twelve. Are we getting worse?” Maria explains. One new risk added based on emerging threat intelligence. Two reassessed up. But she can feel the energy shift in the room — because the question behind the question is, so what do we do about it?

The CISO follows. “I have budget for one initiative this quarter. Which one?” Four risks are clustered in that top-right corner, all rated critical. Maria can offer her professional judgment, and it’s good judgment. But the heatmap doesn’t help her answer. All four risks have the same rating. The matrix has collapsed four meaningfully different situations into the same red cell.

The meeting ends with continue-monitoring on three of the four, and the one the loudest voice championed gets funded. Two weeks of work produced a compliance artifact — not a decision.

After the meeting, Maria is at her desk. She knows something the heatmap didn’t show. She knows that the external database attack — the one in red — is well-controlled. The infrastructure team patched aggressively. Access is tightly managed. The exposure surface is small. Her analysts told her this. But the matrix asked for likelihood and impact as separate ratings, and the theoretical impact of a database breach is always going to be severe. So it stayed red.

She also knows that the BEC risk — sitting in amber — is actually getting worse. Finance team members have reported increasingly targeted phishing. Two mailbox compromises in the last year. Legacy authentication is still enabled for some accounts. But each individual incident felt moderate, so the impact rating stayed moderate. The matrix doesn’t aggregate frequency.

She has the information. Her analysts have the information.

The process destroyed the information.

Three Structural Problems

Maria’s story isn’t unusual. It’s Tuesday for most of us. It shows three structural problems with how we do GRC today.

One: compliance has become the dominant lens. Quarterly risk reviews exist because regulations and standards require them. The process is optimized to produce evidence of assessment — not quality of decision. Maria’s heatmap proves the organization assessed its risks. Whether it improved any decision is a separate question that nobody asks.

Two: assessment without data. Maria’s analysts are treated as the sole data source. Their judgment is valuable. But the organization’s own environment is generating data constantly — posture scores, exposure metrics, incident logs, access patterns, threat intelligence. None of it flows into the risk assessment. The analysts are making calibrated guesses about things the infrastructure is already measuring.

Three: a tool that compresses instead of clarifying. The matrix takes whatever information does make it into the process and compresses it into a five-by-five grid. Meaningfully different risks get the same rating. Frequency and magnitude get separated. Distributions become points. Controls become invisible.

The Decision Quality Reframe

This is where the talk pivots — and where I borrow from someone outside the GRC world.

Carl Spetzler has been writing about Decision Quality since the 1970s. His framework says a quality decision needs six things: an appropriate frame (what we’re deciding and why); creative alternatives (multiple options, not single defaults); relevant and reliable information; clear values and tradeoffs; sound reasoning; and commitment to action. His core principle:

A decision is only as strong as its weakest link.

Map this to Maria’s BEC risk — the amber one that was actually getting worse — and the picture is brutal. The frame was wrong: BEC was framed as generic phishing rather than wire fraud against the finance team. The alternatives were missing: “continue monitoring” is not an alternative, it’s a non-decision. The information existed but was never used: mailbox compromise data, phishing telemetry, legacy authentication coverage were all measurable. The values and tradeoffs were invisible: amber means nothing in financial terms. The reasoning was a single rating with no decomposition into frequency and impact. And the commitment was nothing: no owner, no date, no budget.

Six factors. Six gaps. Each one made the heatmap weaker. Together they made the decision impossible.

This reframe is the move that matters most in the talk. Once you see it through the decision-quality lens, you stop arguing about whether heatmaps are good or bad and start asking which link in your chain is weakest — and that becomes your roadmap.

Grounding Risk in Data

Quantification isn’t about precision. It’s about clarity. We move from ordinal categories — high, medium, low — to ranges of probable loss in financial terms. To build that, we need data from three sources, each answering a different question. The data source model draws directly upon Tony Martin-Vegue’s highly recommendable book “From Heatmaps to Histograms” (2026).

External data answers: what happens to organizations like ours? Industry base rates, peer experience, the accumulated record of what’s happened across the sector. This is where most analyses should start, anchored in empirical reality.

Internal data answers: what actually happens here? Your specific environment, control posture, incident history, exposure surface. Internal data narrows the external estimate toward your reality.

SME input answers: what’s likely to happen next? A planned cloud migration. A newly deployed zero-trust architecture. An emerging threat actor. SME input is the only source that can account for forward-looking change. It’s also where cognitive bias lives, which is why calibration training and structured elicitation matter.

Here’s the part of the argument I think is most novel — and it’s the part most CRQ pitches skip.

Most of the internal data you need is already being generated. Entra ID, Defender, Purview, Sentinel — and equivalents in any modern stack — produce posture data, identity signals, exposure paths, and control coverage telemetry continuously. Continuous Threat Exposure Management adds attack-path analysis. The data is there.

Back to Maria’s BEC. Pull last quarter from Entra: twenty-eight phishing-resistant MFA challenges in the finance team. Twenty-three successful. Five fell back to legacy authentication. Pull Defender: eight phishing emails reached inboxes after the gateway. Two led to credential entry. Zero completed compromise. In risk language: frequency of attempt is measurable, not estimated. Control effectiveness is partial — the legacy auth fallback is the gap. Likelihood of materialization is anchored in real numbers, not a one-to-five rating.

The data was sitting in Maria’s environment the whole time. The risk process never asked for it.

Maria’s Second Meeting

Same organization. Same meeting in two weeks. Different preparation.

First, Maria stops browsing a flat list of forty-seven risks. She surfaces strategic objectives at the top level and ties security risks to the objectives they threaten. That’s the frame.

Then she opens the BEC risk — not as a row in a register, but as a scenario. External threat actor, financially motivated. Asset: finance team mailboxes. Loss type: wire fraud, unauthorized payment. Attack path: legacy authentication, credential entry, fraudulent payment instruction.

Frequency is anchored in external base rates, narrowed by internal telemetry — those Entra and Defender numbers. Impact is informed by SME estimates of the financial loss range if a wire fraud succeeded. Three sources, one refined range. Then she runs the simulation.

This is what Maria shows the CFO instead of an amber dot. It’s a loss exceedance curve. The way to read it: probability that annual loss exceeds a given amount. The curve passes through twelve percent at twenty-five million kroner — above the organization’s stated moderate-loss appetite. The CFO no longer has to ask, are we getting worse? They can see the exposure directly. They can see the appetite line we agreed to. The conversation moves from a colour to a number.

And then — the CISO’s question.

Three treatment options, modelled against the same scenario. Option A — disable legacy auth org-wide — reduces expected loss meaningfully for a small implementation cost. Option B — phishing-resistant MFA across the finance team — reduces it more, costs more. Option C — email gateway upgrade — barely shifts the curve at this scenario.

The trade-off is visible, not intuited. “Budget for one initiative” becomes a defensible decision. Maria recommends Option A, with reasoning that anyone in the room can audit.

And finally the decision record. Decision: disable legacy authentication across finance by Q3. Owner: Anna Sørensen, IAM Lead. Timeline: target completion September. Budget: 150,000 kroner. Acceptance criteria: zero successful legacy auth from finance accounts. Monitoring metric: weekly coverage report from Entra.

A decision has an owner, a date, a budget, and a way to know if it worked. Otherwise it’s not a decision — it’s a wish.

Three Shifts for Monday Morning

You don’t have to rebuild everything to start. Three shifts.

One: start from objectives, not the register. What is the organization trying to achieve, and what threatens that? Tie risks to strategic objectives instead of cataloguing them in a flat list.

Two: make your weakest Decision Quality link your roadmap. Run your current process through the six factors. Whichever factor is weakest — Frame, Alternatives, Information, Tradeoffs, Reasoning, Commitment — that’s where you fix first. Don’t try to fix all six at once.

Three: let the data you already have count the risk. Your Verify layer — Defender, Entra, Purview, Sentinel, your SIEM, your CTEM tooling — is producing it continuously. Pick one material risk. Pull the telemetry. Ground the estimate. Compare the answer to what the heatmap said.

---

Where is your process weakest? If you ran your last quarterly risk review through Spetzler’s six factors, which one would fail first — and what would it take to fix?

---

Talk slides: From heat maps to decisions (PDF). Questions, push-back, or your own data: [email protected].