Are you measuring success or activity?
Every CISO I meet can show me a dashboard. Number of blocked attacks. Number of completed security training sessions. Number of closed tickets in the ticketing system. The figures look impressive. The graphs point upward.
But the question nobody asks is: do these figures tell us anything about how secure the organisation actually is? The answer is almost always no.
Most security KPIs measure activity, not impact. Your firewall blocking 50 million requests per month tells you nothing about whether the 50 requests that got through were the ones that mattered. That 100% of staff completed security training tells you nothing about whether they’ve actually changed behaviour.
The fundamental question: If your primary security metric is “number of blocked attacks” you’re measuring fire brigade success by number of fire engines — not lives saved.
Vanity metrics: Numbers that look good but don’t drive decisions
Measures volume, not risk. A high number means you have lots of traffic, not that you're secure. The most sophisticated attacks are designed not to be blocked by standard defences.
Measures participation, not learning. 100% completion on an e-learning course everyone clicks through in 10 minutes tells you nothing about how employees behave when it matters.
Measures throughput, not quality. A team can close hundreds of tickets per month and still miss critical vulnerabilities — because they prioritise volume over severity.
99.9% uptime sounds good — but tells you nothing about security itself. A system can have perfect uptime whilst being completely compromised by an APT actor lying in wait.
KPIs that actually matter
Effective security KPIs share three characteristics: they’re linked to business risk, they’re measurable over time, and they drive action. If a metric doesn’t lead to a question (“what should we do about this?”) it has no value.
Exposure: How quickly do you detect and remediate?
| KPI | What it measures | Why it matters |
|---|---|---|
| MTTD (Mean Time to Detect) | Average time from breach to discovery | The longer an attacker is inside, the more damage they can do |
| MTTR (Mean Time to Respond) | Average time from detection to containment | Rapid response dramatically limits damage scope |
| Patching time | Time from vulnerability disclosure to implementation | Shows your ability to handle known threats in reasonable time |
| Exposed assets | Number of internet-exposed systems without full protection | Direct measure of your visible attack surface |
Maturity: How well does your security programme work?
| KPI | What it measures | Why it matters |
|---|---|---|
| Implementation rate | % of required controls that are fully implemented | Shows where gaps exist — and how quickly you’re closing them |
| Compliance gap | Distance to full NIS2 Directive compliance | Gives the board a clear picture of regulatory risk |
| Exercise frequency | Number of incident response exercises per year | A never-practised plan is a wishlist, not preparedness |
| Supplier coverage | % of critical suppliers that have undergone security assessment | Measures control over your supply chain |
Business impact: What does it cost?
Express risk in terms the board understands
Board members don’t make decisions based on CVE numbers or CVSS scores. They make decisions based on business impact.
Instead of: “We have 47 critical vulnerabilities in our externally-exposed infrastructure”
Say: “We have vulnerabilities in the customer system that, if exploited, could lead to 3–5 days downtime with an estimated cost of £2–4 million. The fix costs £200,000 and takes two weeks.”
Now the board has a basis for decision-making.
The trap: Measuring what’s easy instead of what’s important
Most organisations fall into the trap of measuring whatever their SIEM system happens to generate automatically. Number of logged events, number of rule hits, number of false positives. It’s available data — but it’s not necessarily meaningful data.
Really valuable KPIs often require manual processing, contextual understanding and connection to business objectives. It’s more work — but it’s work that actually generates decision support.
Ask yourself for every metric:
- What does this tell us about our actual security?
- If this number changes, what should we do differently?
- Can the board understand and act on this?
If the answer to any question is “don’t know” — measure something else.
Build a dashboard that drives decisions
- Choose 5–8 KPIs — no more A dashboard with 30 metrics drives no decisions. Focus on the key indicators that reflect your biggest risks and most important improvement areas. Tailor the selection to your risk profile.
- Show trends, not snapshots A number without context is meaningless. Show how MTTD has developed over recent quarters, how compliance gaps are shrinking (or growing), and how patching time is changing. Trends give the board a picture of direction.
- Include both leading and lagging indicators Lagging indicators (number of incidents, cost per incident) show what happened. Leading indicators (exercise frequency, patching time, training quality) show where you're heading. The board needs both.
- Link each KPI to a target If MTTR is 48 hours — what's the target? 24 hours? 4 hours? Without targets the number provides no guidance. And targets should be based on your risk appetite and industry standards — not what happens to be technically easy to achieve.
Measure to improve, not to impress
KPIs showing everything is perfect are probably wrong. The most mature organisations have metrics that highlight deficiencies — because that’s how you know where to focus improvement efforts. An honest dashboard showing gaps and trends is infinitely more useful than a green dashboard nobody trusts.
If your security work is to be driven by decisions, those decisions need to be driven by the right data. Measure what matters.
Securapilot’s dashboard functionality brings together your most important security KPIs in an overview designed for leadership — with trends, compliance status and risk exposure that drives action instead of just informing.
Frequently asked questions
Which KPIs should a CISO report to the board?
Focus on metrics the board can act upon: risk exposure in monetary terms, time to detection and remediation (MTTD/MTTR), compliance status as percentage, and trend lines showing improvement or deterioration over time.
Why is number of blocked attacks a poor metric?
It measures volume, not effectiveness. Your firewall blocking millions of requests daily tells you nothing about whether your organisation is actually protected against threats that matter. It's like measuring fire brigade success by number of fire engines instead of lives saved.
How often should security KPIs be reported?
Operational KPIs (MTTD, patch status, vulnerability levels) should be tracked weekly or monthly internally. Strategic KPIs to the board should be reported quarterly. Extraordinary reports for incidents or significant changes.
What's the difference between lagging and leading KPIs?
Lagging KPIs measure what has already happened (number of incidents, cost per breach). Leading KPIs measure readiness and trends (time to patch, training effectiveness, compliance gaps). A good dashboard needs both, but leading KPIs provide better decision support.
