In information security, the management maxim holds true: what isn't measured can't be managed. Without metrics, the function becomes an opaque cost center, unable to prove value, justify investment or demonstrate that risk is under control. With poorly chosen metrics, it drowns in numbers that impress but don't guide decisions. This guide shows how to measure security with actionable indicators, structure OKRs and translate technical risk into business risk to speak the language of the board.
Why measure security
Security is, at its core, risk management under uncertainty. Leadership needs to answer concrete questions: are we safer than last quarter? Where should we invest the next dollar of the budget? What is our exposure if ransomware hits operations tomorrow? None of these questions can be answered with intuition. They are answered with consistent data, collected over time and compared against targets.
Measurement serves three functions. First, diagnosis: it reveals where controls fail before an incident exposes the flaw. Second, management: it allows you to set targets, track progress and prioritize resources where risk is greatest. Third, accountability: it gives the CISO the foundation to talk to the board in business terms, not technical jargon. NIST SP 800-55 (Performance Measurement Guide for Information Security) and ISO/IEC 27004 formalize this discipline: measurement isn't collecting everything the tool exports, it's collecting what supports a decision.
KPI, KRI and operational metric: don't confuse them
Three categories coexist in a mature program, and treating them as synonyms is the leading cause of confusing dashboards.
- An operational metric is the raw data that operations consume day to day: number of alerts, correlated events, tickets opened. It serves to diagnose and tune the engine, but in isolation it tells leadership nothing.
- A KPI (Key Performance Indicator) measures the performance of a process against a target. MTTR for critical incidents is a KPI: there is a goal, and the number tells you whether the response process is within it or not.
- A KRI (Key Risk Indicator) is anticipatory. It signals that exposure is growing before it becomes an incident. A drop in patch coverage, an increase in privileged accounts without MFA, or growth in the number of unmonitored assets are KRIs: none is an incident yet, but all raise the probability of one.
The rule of thumb: a KPI looks at the past and present of performance; a KRI looks at the future of risk; an operational metric feeds both. A good executive dashboard is dominated by KPIs and KRIs, not by operational counters.
The essential metrics
There are hundreds of possible metrics. Those that follow cover detection, response, hygiene and maturity, and form a core that serves small companies through to large operations.
| Metric | What it measures | Target / reference benchmark |
|---|---|---|
| MTTD (Mean Time to Detect) | Average time between the start of an attack and its detection | Hours, not days; the lower the better |
| MTTR (Mean Time to Respond) | Average time to contain and respond after detection | < 4h for critical incidents |
| MTTC (Mean Time to Contain) | Time to effective containment of the threat | Minimize the window of active exposure |
| Patch coverage | % of assets with fixes applied within the deadline | > 95% on critical systems |
| Critical vulnerabilities within SLA | % of critical vulns remediated within the defined deadline | 100% within the agreed SLA |
| Simulated phishing rate | % of employees who fall for simulations | Downward trend; target < 5% |
| MFA coverage | % of accounts (especially privileged) with MFA enabled | 100% on privileged and remote access |
| Dwell time | Time an attacker remains undetected | Reduce to a few days or hours |
| Maturity (NIST CSF) | Level of control implementation (Tiers 1 to 4) | Advance in a planned way between tiers |
| Residual risk | Remaining risk after applied controls | Within the approved risk appetite |
A few notes on using this core correctly. MTTD, MTTR and MTTC form the response trio: together they describe how long the organization takes to perceive, react to and stop a threat. Dwell time is especially revealing because it measures what the attacker can do unnoticed; reducing it is often cheaper and more effective than trying to block every intrusion at the edge.
The simulated phishing rate should be read as a trend, not as punishment. A high number in the first cycle is normal; the value lies in the downward curve over the course of training. MFA coverage is perhaps the highest return-on-effort indicator: the absence of MFA on privileged accounts is a factor in most compromises. And the maturity level anchored in the NIST Cybersecurity Framework tiers (from Partial to Adaptive) gives the board a view of the journey, showing that security is planned evolution, not a binary state.
Finally, residual risk is the indicator that connects everything to the risk appetite approved by leadership. It answers the question that matters most: is the risk left over after all controls within what the organization decided to tolerate?
Security OKRs: ambition with measurement
Metrics tell you where you are; OKRs tell you where you're going. An OKR (Objectives and Key Results) combines a qualitative, inspiring Objective with a set of measurable Key Results. The model's strength lies in separating the aspiration (what we want) from the evidence (how we'll know we got there). Unlike compliance targets, which are binary and ongoing, OKRs are quarterly, ambitious and reviewed on a cadence.
Concrete examples of security OKRs:
- Objective: Drastically reduce the internet-exposed attack surface.
KR1: raise MFA coverage from 78% to 98% of accounts. KR2: remediate 100% of critical vulnerabilities within SLA. KR3: reduce exposed assets without monitoring from 40 to 0. - Objective: Make incident response fast and predictable.
KR1: reduce MTTR for critical incidents from 12h to 4h. KR2: reduce average MTTD from 5 days to 1 day. KR3: run 3 tabletop response exercises with revised playbooks. - Objective: Build a risk-aware security culture.
KR1: reduce the click rate on simulated phishing from 18% to 5%. KR2: train 95% of employees in security. KR3: increase voluntary reporting of suspicious emails by 50%.
Note that each Key Result is a number with an origin and a destination. This turns the rhetoric of "we want to improve security" into an auditable trajectory. OKRs don't replace KPIs and KRIs; they put them at the service of a quarterly strategic direction.
Reporting to the board: translating technical risk into business risk
The most common mistake technical teams make is bringing terminal language to the board. A board doesn't decide based on CVEs, alert counts or tool names. It decides based on three dimensions: financial impact, regulatory exposure and reputational risk. The CISO's job is to bridge the technical detail and those dimensions.
The most robust path to this is risk quantification. Models like FAIR (Factor Analysis of Information Risk) allow you to express exposure in monetary ranges: the expected annual loss of a ransomware scenario, for example, estimated in dollars with optimistic and pessimistic cases. Instead of saying "three hundred open vulnerabilities," say "estimated exposure of $4.2 million in downtime scenarios, reduced by 35% this quarter." The first number scares without guiding; the second connects security to an investment decision.
Three principles for executive reporting. First, tie each risk to a business process — revenue, operations, customer service — so the impact is tangible. Second, show trend: a single number is noise; the curve over quarters tells the story of improvement or deterioration. Third, link each metric to a decision: if the board can't act on a number, it doesn't belong on the executive slide.
Dashboards and cadence
Different audiences require different levels of detail, but all should drink from the same source of truth. You don't rewrite numbers per meeting; you change the lens.
- SOC and operations: real-time or daily dashboards, rich in operational metrics and alerts.
- Security leadership: weekly or biweekly review of KPIs and KRIs, focused on deviations and trends.
- Executive committee: monthly summary, with residual risk, OKR progress and investments.
- Board: quarterly view, centered on financial exposure, risk posture against appetite, and pending decisions.
An effective executive dashboard fits on one screen: three to five top indicators, each with current value, target and trend arrow. The depth lives in the levels below, available on demand.
Pitfalls: beware of vanity metrics
Vanity metrics are numbers that impress but don't guide decisions. Total attacks blocked by the firewall, millions of spam emails filtered, terabytes inspected: all of these always go up and don't tell you whether risk went down. Worse, they create a false sense of security and divert attention from what matters.
The test of a useful metric is simple: if this number changes, does any decision change? If the answer is no, it doesn't deserve space in the report. Other frequent pitfalls include measuring activity instead of outcome (number of training sessions versus reduction in phishing clicks), chasing too many indicators until analysis is paralyzed, and optimizing the metric instead of the risk — when the team closes tickets quickly just to lower MTTR, without actually solving the root cause. Periodically review the set of indicators and retire without mercy those that don't guide action. Frameworks like the CIS Controls and ISO/IEC 27004 help anchor the selection in what demonstrably reduces risk.
Best practices to sustain the program over time
Building the first dashboard is easy; keeping it relevant for years is the real challenge. A few practices separate programs that endure from those that become forgotten slides.
- Automate collection. Metrics extracted by hand from spreadsheets age and lose trust. Integrate the sources — SIEM, vulnerability scanner, identity management, EDR — so the numbers reach the dashboard without human intervention and without the bias of whoever is reporting.
- Assign an owner to each metric. Every indicator needs someone responsible who understands what makes the number go up or down and who can act on it. A metric without an owner is a metric no one improves.
- Establish risk appetite before targets. KPI and KRI targets derive from the level of risk leadership is willing to accept. Without that prior agreement, each area negotiates its own target and the set loses coherence.
- Tell a story, not an inventory. In executive reporting, connect the numbers to a narrative: what improved, what got worse, why and what decision is being asked for now. Data without narrative doesn't move budget.
- Reassess the set every year. Maturity changes, threats change, and metrics that made sense at the start become noise. Schedule an annual review to promote, demote and retire indicators.
The ultimate goal isn't to have the prettiest dashboard, but to sustain a cycle of continuous improvement in which, each quarter, the organization understands its own risk better and reduces it demonstrably — the cycle NIST SP 800-55 calls decision-oriented measurement.
How Decripte measures security for you
Turning security into something measurable and reportable is exactly what Decripte delivers. As a B2B cybersecurity company serving from 1 to over 100,000 employees, we translate technical operations into a security score and dashboards that speak both to the technical team and to the board — with MTTD, MTTR, control coverage, residual risk and trend consolidated into a single source of truth. You stop guessing and start managing with data, anchored in recognized frameworks like NIST CSF, CIS Controls and ISO 27004.
Want to see where your organization stands today? Start free through our Intelligence Center and get an initial read on your exposure. When you're ready to measure and evolve continuously, explore our plans and choose the right size for your operation.