There is a conversation that repeats every year in budget committees and that almost no one talks about. The head of technology presents the annual security report. There were no breaches, no outages, no ransom to pay. And someone at the table, with no ill intent, asks the question that undoes everything: if nothing happened, do we really need to spend the same amount next year?
As Chief Innovation Officer, my job is to look at services from the business side, and that moment strikes me as the most revealing in the industry. The year without incidents, which is the goal of all the work, is also the year the budget is most exposed. Not because of anyone’s bad faith. Because of a measurement problem.
Why does the report always tell the same story?
The NIST Cybersecurity Framework, which is the reference almost everyone says they follow, organizes the work into six functions: govern, identify, protect, detect, respond, and recover.
Now open the last security report you received and count how many of those six functions it covers.
Almost always two: respond and recover. Incidents handled, response time, services restored. The other four, which are where the work that prevents incidents is done, appear at most in one line at the end.
The reason is dull and human: responding and recovering leave a trail. There is a ticket, a start time, an end time, someone who called at three in the morning. Protecting and detecting well leave nothing. And what leaves no trail does not make it into the report, does not make it into the conversation, and does not make it into the budget.
The same work, told the other way around
Before looking for new metrics, it is worth seeing how far you get just by changing the wording. This is a sample monthly report in its two versions, with exactly the same facts behind it:
| How it is written today | How the committee reads it |
| 14 incidents were handled this month. | Fourteen problems. Isn’t this supposed to prevent them? |
| How it should be written | How the committee reads it |
| 1,200 signals were reviewed. Fourteen required human intervention. None reached production. | The service did its job twelve hundred times. |
The work did not change. What changed was which part of the work was chosen to be counted. And that difference decides renewals.
Four metrics that actually measure prevention
Rewriting the report helps, but it is not enough. You need numbers that measure what was prevented, not what was handled. These four can start being measured this quarter without buying anything.
1. Exposure window. How many days pass between the publication of a vulnerability that affects your company and the moment it is closed on all your systems. Not most of them. All of them. It is the most honest metric there is, because during those days you were exposed and you knew it.
2. Real coverage. What percentage of your assets is truly under monitoring. Almost every company discovers, when it measures this, that the figure is considerably lower than it thought, and that what is missing tends to be the oldest. The MITRE ATT&CK catalog lets you turn the question around: of all the known techniques an attacker uses, how many would you detect today?
3. Signals resolved before escalation. How many alerts were closed without becoming an incident, and how quickly. This is the one that turns the invisible into something countable. It is literally the record of what did not happen.
4. Dwell time. How long someone could have been inside your network before anyone noticed. If that figure drops quarter after quarter, your prevention is improving, even if not a single incident has occurred. In fact, especially if none has occurred.
None of the four requires a new tool. They require the decision to measure them and to put them on the first page of the report, not the last.
And why can’t this be fixed with automation?
Because automation does not decide what deserves to be counted. Daniel Medina put it in a line I kept thinking about for several days: “AI can turn an expert into an entire team. It can also turn a fool into an entire department.”
The data points in the same direction. The IBM Cost of a Data Breach report for 2026 found that one in four malicious breaches already involves artificial intelligence, and that those breaches cost around one million dollars more than the global average, which stood at 4.99 million. The tool is already on both sides. The difference is still made by who uses it.
A security operations center with good tools and no judgment produces more alerts, not more security. And it produces longer reports, which is not the same as more useful reports. The tool multiplies the judgment that already exists, in the direction it is already heading.
The question to ask your provider
If you contract managed security, there is one question that frames the entire conversation: what will it show me in the month when nothing happens?
If the answer is a report with an empty incident table, you are buying insurance that only becomes noticeable on the day something has already broken. And insurance is always the same: it seems expensive until you need it, and on that day it can no longer be purchased. If the answer includes exposure window, coverage, and resolved signals, you are buying continuous monitoring and you will also be able to defend that budget next year.
It is the same logic we apply when discussing the risk inherited from vendors: what is not measured is not managed, and what is not counted is not funded.
Peace of mind is not the absence of work. It is the result of work that was done well and that no one bothered to count.
