Your Board Doesn't Care About T1078: A Detection Coverage Model in the Language of Business Risk
216 technique IDs are not a decision surface. Translate detection coverage into named threats against crown-jewel assets, in dollars, with drill-down.
Picture the slide. A MITRE ATT&CK heatmap, fourteen tactic columns, a wall of cells, some green, some yellow, most an ambiguous gray. You are three minutes into a board update and you have just asked a group of people who allocate capital to reason about T1078 versus T1550.002. They will nod. They will not act. And they will leave the room no more confident that the money they gave you last quarter bought anything real.
They are right to be unconfident. Gartner surveyed 330 non-executive directors in 2025 and found that 90% of them lack a measure of confidence in the value of their cybersecurity investments: only one in ten expressed strong confidence that they have the right balance of protection and cost [1]. The analyst who ran the study, Kristin Moyer, put the cause bluntly: “Dashboards and compliance updates can confuse rather than reassure, leaving non-executive directors uncertain about whether their organization is truly more secure” [1].
That is not a measurement problem. Your detection team can measure coverage to three decimal places. It is a communication-architecture problem. The heatmap is a precise answer to a question the board never asked, delivered in a language they do not speak, at an altitude they cannot use. This post is about building the layer that fixes it: a translation from technique IDs to threat-to-asset coverage expressed in dollars, with every claim traceable back down to the evidence. Not dumbed down. Re-aimed.
216 Technique IDs Are Not a Decision Surface
Start with the scale problem, because it is worse than the heatmap makes it look. MITRE ATT&CK Enterprise v17, released April 2025, defines 14 tactics, 211 techniques, and 468 sub-techniques: close to 700 distinct IDs [2]. Even if your program has an honest, tested detection for every one of them, you cannot put 700 IDs in front of a board and expect a decision to come out. There is no capital-allocation choice a director can make from “we are green on T1059.001 and yellow on T1059.003.”
The framework was never built to be a board metric. It is an engineering ontology: a shared vocabulary for the people who write, test, and maintain detections. It is superb at that job. It is catastrophic as a communication surface for anyone above the detection team, and the failure mode is specific: the more complete the heatmap, the more it implies coverage that does not exist. Green means “a rule exists,” not “we would catch this.” I made the measurement case for that gap in The Detection Funnel: how 80% ATT&CK coverage compounds down to roughly a 6% real catch rate once you account for broken rules, uninvestigated alerts, and false positives. I am not re-arguing that math here. I am taking it as given and asking the next question: once you know your real coverage, how do you say it to people who fund it?
Because here is what the board actually wants, and it is not the heatmap. The board wants a small number of top-level health metrics and a small number of actionable items, delivered as a story that hangs together: here is where we are strong, here is the one place we are exposed, here is what we are doing about it, here is what it costs. They are asking one question (“does the overall health story hold together, and what do we do about it?”) and the technique table answers a completely different one. Minimal technical detail. Maximum decision relevance. The heatmap inverts both.
Fidelity and Audience Are Different Axes
The instinctive objection from good detection engineers (and I have made it myself) is that the moment you leave the technique layer you start lying. Collapse 468 sub-techniques into “we cover 80% of ransomware risk to the payments platform” and you have buried exactly the sub-technique gaps that get you breached. Abstraction hides. Hiding kills. So keep it concrete, keep it at T-number resolution, and make the board deal with it.
That objection conflates two things that are actually independent: fidelity and audience. Fidelity is how much detail a representation preserves. Audience is who it is built for. The mistake is assuming that lowering the altitude for the board means lowering the fidelity of the system. It does not, if you architect it correctly. You keep a full-fidelity, technique-resolution model as the auditable backing layer that engineers own and operate. You derive the board view from it. The board sees a low-detail, high-relevance summary; the summary is a query against a high-detail, high-fidelity store. Nothing is thrown away. It is re-aimed.
This is the same discipline as financial reporting, and the analogy is exact enough to be useful. A board does not read the general ledger. They read an income statement. The income statement is not a lie about the ledger. It is a faithful, lower-resolution view of it, and every number on it is traceable down to individual journal entries when someone asks. Nobody argues that summarizing revenue into a single line “hides” the transactions. The transactions are still there, still auditable, still owned by the people whose job is the ledger. The summary is more honest than dumping 40,000 rows on the board, because the rows create an illusion of rigor while communicating nothing.
Your heatmap is the general ledger. You have been handing the board the ledger and calling it transparency.
Say It In Dollars, Because Everything the Business Does Is In Dollars
Here is where I will lose some of the room, so let me be direct about my position: express detection coverage in dollars. Not as a gimmick, not as false precision, as the only unit the business actually runs on.
Every other function that reports to the board translates itself into money. Sales reports pipeline in dollars. Ops reports cost per unit. Finance is dollars end to end. Security is the one function that shows up with a native-language artifact (the heatmap) and asks the board to learn our dialect instead of speaking theirs. That is not rigor. That is a refusal to do the translation work, and it is precisely why 90% of directors cannot tell whether your budget bought them anything [1]. If you cannot express what you protect in the unit the business uses to decide what is worth protecting, you have lost the plot on what security is for. Security exists alongside the business that funds it. A detection program that cannot articulate its value in the funder’s currency is not more principled. It is unsustainable.
The tooling for this already exists and it is not vendor fluff. The FAIR model (Factor Analysis of Information Risk) decomposes risk into two quantities: loss event frequency (how often a loss event happens) and loss magnitude (what it costs when it does), and multiplies them into risk expressed in dollars [3]. Crucially, FAIR does not produce a single fake-precise number. It produces a range of probable outcomes, explicitly to represent uncertainty [3]. That last part is what makes it honest rather than theatrical: you are not telling the board “our ransomware exposure is exactly $4.2M.” You are telling them “our modeled annual loss exposure to ransomware against the payments platform is $2M to $9M, and the detection investment we are proposing moves the frequency term down by roughly this much.”
And you can anchor the magnitude side in hard data, not vibes. IBM’s 2025 Cost of a Data Breach report found that organizations which detected a breach internally saved about $900,000 versus those who first learned of it from the attacker [4]. That is a number a board can hold. “The detection capability we are asking you to fund is, on the evidence, worth roughly $900K per material incident in reduced impact, before we count the reputational and regulatory tail.” That sentence does more work in a boardroom than a fully-populated ATT&CK matrix ever will. Gartner’s own read of what earns board confidence says the same thing from the other direction: the CISOs who win are the ones who translate cybersecurity complexity “into business value such as revenue, cost and shareholder impact” [1].
The Translation Layer, Concretely
So what does the actual pipeline look like? Three layers, top to bottom, and the whole point is that they are linked, not separate documents.
Board layer: threats to crown jewels, in dollar ranges. The unit is not a technique. It is a named threat scenario against a named high-value asset, with a coverage claim and a loss range. “Ransomware against the payments platform: modeled exposure $2M-$9M annually, detection coverage of the relevant attack paths at roughly 85%, one gap under active work.” Five to eight of these lines is the security section of the board deck. Every organization has a short list of crown-jewel assets (the payments system, the customer PII store, the source-code repository, the domain controllers) and a short list of threats that actually target organizations like yours. That cross-product is small. It is a decision surface.
Threat-model layer: scenarios decomposed into attack paths. Each board-level scenario expands into the specific paths an adversary would take against that specific asset, mapped to the techniques those paths use. This is where “ransomware against payments” becomes “initial access via valid accounts (T1078) → privilege escalation → lateral movement → impact,” and where you assess whether each step is covered. This layer is owned by detection engineering, not exec comms, and it is the join between business language and technique language.
Technique layer: the auditable backing store. The full-resolution model: every technique, every detection, its health, its last tested date, its recall from the last purple-team run. This is the ledger. It is exactly the artifact I argued for in Detection-as-Code Scales Without You: detections as version-controlled, tested, owned code, with a queryable record of what exists and whether it works. If you already run detection-as-code, you already have the backing store; you just have not been deriving the board view from it. If you do not, this is the load-bearing reason to build it: without a real technique-layer store, the dollar ranges on top have nothing under them and become the fabrication the skeptics fear.
The direction of travel matters. You do not write the board number and then hunt for technique evidence to justify it. You aggregate up from the technique layer. The dollar range is a computed rollup of the coverage assessed at the paths, weighted by the modeled loss. When a director asks “why are we only 85% covered on payments ransomware?” the answer is one drill-down away: this attack path, this technique, this detection is untested since the schema changed. That traceability is the entire game.
A worked example: the crown jewel nobody instrumented
Take a scenario I have watched play out. Your crown jewel is the Salesforce org holding every customer record. The named threat is OAuth token abuse against SaaS: the shape of the Salesloft Drift compromise, where attackers used legitimate OAuth refresh tokens to pull data from hundreds of organizations’ Salesforce tenants. I walked through why this is a detection blind spot in Non-Human Identities Are Your Biggest Detection Blind Spot: the credential is valid, the permission was granted, the posture dashboard is green, and the only thing that gives it away is behavior: a trusted integration suddenly querying far more than it ever has.
At the board layer, this is one line: “Customer data exfiltration via trusted SaaS integration: modeled exposure $5M-$20M, current detection coverage low: this is our named gap this quarter, and here is the funded plan to close it.” That is a sentence a board can act on. They can approve the plan or accept the risk in writing. What they could never have done is notice, from a heatmap, that the cell for T1550 was gray for non-human identities specifically. The technique layer had the gap. The heatmap displayed the gap. But displaying is not communicating, and the gap sat there, green-adjacent and invisible, until it was a headline.
The Steelman: Traceable Abstraction Beats a Wall of Green
Let me put the strongest version of the objection back on the table, because it deserves a real answer and not a dismissal. The argument is: translating to business risk is abstraction, and abstraction is lying: the moment you collapse 468 sub-techniques into “80% of ransomware risk to payments,” you have hidden the one untuned sub-technique detection that the actual attacker will walk straight through. The dollar number launders a gap into a green line. Better to keep it concrete and make everyone stare at the uncomfortable matrix.
The answer is that this objection is aimed at the wrong target. It assumes the alternative to abstraction is honesty, when the alternative you are actually running today is a different abstraction that is worse. The wall-of-green heatmap is not high-fidelity truth. It is an abstraction that maps “a rule exists” to “protected”, and that mapping is the actual lie, because it silently folds untuned, untested, vendor-default, and log-source-broken detections into the same green as your best work. The heatmap hides more than the dollar model does. It just hides it behind an aesthetic of technical rigor, which is more dangerous because it fools the people producing it.
Traceable abstraction is strictly more honest than that, for one structural reason: it carries its uncertainty and its evidence with it. A FAIR range says “$2M-$9M” out loud: the width of the range is the disclosure of what you do not know [3]. A drill-down path means the 85% is not a claim, it is a checksum: anyone can descend to the technique layer and audit every input. The heatmap’s green offers no range and no descent. It is a terminal assertion. “Abstraction means lying” is only true of abstraction that severs itself from its backing. Abstraction that stays joined to its backing (that is what a well-run financial statement is, that is what a coverage rollup should be) is not lying. It is the only way a complex system communicates with the people who govern it without either drowning them or deceiving them.
And the honest part cuts both ways, which is why engineers should want it. The traceable model is what keeps you honest too. The day you have to roll a technique’s real, tested recall up into a dollar-weighted board number is the day “we have a rule for that” stops being good enough, because a rule that has never fired in a test contributes zero to the number it is supposed to support. The backing layer disciplines the summary; the summary creates the pressure to make the backing layer real.
This Is the Outward Problem, Not the Inward One
One boundary worth drawing, because it is easy to blur. This is a communication problem: how the program represents itself upward and outward. It is not the same problem as engineering the metrics themselves. Choosing leading indicators your team can actually move week to week (the inward, operational discipline of not steering by lagging outcomes) is its own discipline, and I covered it in MTTD Is a Lagging Indicator. That post is about what the detection team measures to run itself. This one is about what the program says to the people it reports to. They are companions: you need real leading metrics underneath, or the dollar ranges are built on sand; and you need the translation layer on top, or the best metrics in the world die unfunded in a heatmap nobody understood.
Do not confuse the two and try to solve communication by adding more technical rigor to the deck. The board’s problem is never that your heatmap lacked detail. It is that it had nothing but detail.
What to Do Monday
Build the three-layer model, top-down in design and bottom-up in computation. Concretely:
Name your crown jewels and your real threats. Five to ten assets, five to ten threat scenarios that actually target you. This is the whole decision surface and it fits on one page. If you cannot name them, that gap is your first finding.
Map each scenario down to attack paths and techniques, and assess coverage at that resolution using tested recall, not rule inventory. This is the join. It is also where you will discover which of your green cells were never real.
Attach a loss range to each scenario using FAIR: loss event frequency times loss magnitude, as a range, anchored in hard numbers like the $900K internal-detection delta where you have them [3][4]. Resist the urge to produce single points. The range is the honesty.
Make the technique layer the source of truth and the board view a derived query. Detection-as-code gives you the store; the rollup gives you the deck. The board sees eight lines and a story. The engineer sees 700 IDs and a test log. Same system, two altitudes, one thread of traceability running between them.
The heatmap was never wrong. It was just talking to the wrong audience in the wrong unit, and the 90% of directors who cannot tell whether security is working are the receipt for that mistake [1]. Keep the technique model: own it, test it, audit it. But stop shipping it upward. Translate it into the language the business runs on, in the currency the business decides in, with a wire back down to the evidence. That is not softening the truth for the board. That is finally telling them the truth in a form they can act on.
Resources
- Gartner Survey Finds 90% of Non-Executive Directors Lack a Measure of Confidence in Cybersecurity Value. Gartner, Nov 2025 (330 non-executive directors surveyed Apr-May 2025; 90% lack confidence in cyber value; Moyer on translating to revenue, cost, shareholder impact).
- MITRE ATT&CK Enterprise v17. MITRE, Apr 2025 (14 tactics, 211 techniques, 468 sub-techniques).
- Best Practices for Communicating Cyber Risk Using FAIR. FAIR Institute (loss event frequency × loss magnitude; risk as a range of probable outcomes, not a single value).
- 2025 Cost of a Data Breach Report: Navigating the AI Rush. IBM, 2025 (organizations detecting breaches internally saved ~$900K versus attacker-disclosed).