Security metrics for executives: why virus counts are a bad KPI
How to talk about information security in terms of risk and resilience, rather than technical counters that tell a manager nothing meaningful.
At the quarterly security review, the executive sees a table: 4,712 viruses blocked, 38,000 spam messages rejected, 17 vulnerabilities closed. The numbers are large and look convincing. But they do not answer the question "how well protected is the company?"
That is not a problem with the executive failing to understand technology. It is a problem with reporting that measures activity instead of state.
What is wrong with event counters
The number of blocked viruses tells you the antivirus is running. It does not tell you whether any virus got through. The number of closed vulnerabilities does not show how many remain open or how critical they are. The number of incidents depends on what the company decides to call an incident and how well it can detect them.
The most dangerous conclusion from this kind of report is: "everything is fine, because the numbers are big." In practice, large counters often only mean that the system generates a lot of noise.
Three questions worth asking
Instead of technical counters, I suggest executives ask three questions about the actual security state.
First: if something goes wrong - how quickly will we notice?
This is detection time. In most companies it is measured not in hours but in days or weeks. Companies that learn about a breach from external sources rather than their own monitoring are not the exception - they are the norm. Detection time is a metric an executive can understand and track over time. The starting point for that detection capability is treating logs as operational material rather than background noise.
Second: what scenario would hurt us most?
Not "what could happen" in general, but specifically: a customer database leak, a production system going down, financial accounts being compromised. For each such scenario it is worth understanding whether the company has the capability to detect and stop it. That is more honest than a general "security maturity score".
Third: what could we not recover from if a serious incident did happen?
Resilience is a separate question from prevention. A company with no working backups of critical data is exposed regardless of how many viruses the perimeter blocked.
What a useful security report looks like
A good report for an executive is not a table of events. It is a short answer to three questions:
- What changed in the risk profile during the period - new threats, vulnerable systems, incidents worth reviewing?
- What was done about the priority scenarios - were critical gaps identified, was recovery capability tested?
- What needs a business-level decision - resources, priorities, process changes?
That fits on one page. If the report does not fit, it is probably written for a technical specialist, not for a director.
A simple test for any executive
There is one question I recommend asking the person responsible for security once a quarter: "If someone gains access to our customer database tomorrow morning - how long until we know about it?"
If the answer is confident and specific, that is a good sign. If the answer is vague or amounts to "well, we would probably notice" - that is the real security state worth discussing, not the count of blocked emails.