- ISO 27001 requires in Clause 9.1 the monitoring, measurement, analysis, and evaluation of ISMS performance. Without metrics, you do not meet this requirement.
- Good ISMS KPIs are measurable, comparable over time, actionable, and understandable for executive management.
- The 15 KPIs cover four areas: risk management, operational security, compliance and awareness, and incident management.
- Metrics are not an end in themselves. Every metric must be able to lead to a concrete decision or action.
- Start with 5-7 KPIs and expand gradually. Better to have a few meaningful metrics than many that nobody reads.
Why Metrics Are Essential in an ISMS
ISO 27001 is unambiguous in Clause 9.1: The organization must determine what needs to be monitored and measured, establish the methods for monitoring, measurement, analysis, and evaluation, determine when monitoring and measurement shall be performed, and determine who shall analyze and evaluate the results.
The management review (Clause 9.3) requires as input, among other things, information about information security performance, including trends. Without metrics, you have no trends. Without trends, you have no substantive management review. And without a substantive management review, you have an audit finding.
But metrics are more than an audit requirement. They are the tool with which you demonstrate the effectiveness of your ISMS, identify improvement opportunities, and show executive management that the investment in information security is paying off.
The challenge: Not every number you can measure is also a useful metric. The number of firewall events per day is a number, but it does not help executive management make a decision. The average time to remediate critical vulnerabilities, on the other hand, shows whether your patch management is working and whether you need investment in automation.
What Makes a Good ISMS Metric
Before you define metrics, it helps to know the criteria for good metrics:
Measurable: The metric must be objectively and repeatably collectible. "Our security level is good" is not a metric. "94% of critical vulnerabilities were remediated within 30 days" is.
Comparable: The metric must be comparable over time. Only then can you identify trends. If you constantly change the collection method, the values are not comparable.
Actionable: Every metric must be able to lead to a concrete decision or action. If a metric misses its target value, it must be clear what to do.
Understandable: Executive management must be able to understand the metric without needing a computer science degree. Technical details belong in the details, not in the overview.
Collectible: The data for the metric must be collectible with reasonable effort. A perfect metric that requires three work days per month to collect is worthless in practice.
The 15 KPIs in Detail
Area 1: Risk Management
KPI 1: Risk Treatment Rate
Definition: Proportion of identified risks for which a treatment plan has been defined and initiated.
Formula: (Risks with active treatment plan / Total number of identified risks) x 100
Target value: > 90%. Every identified risk should be either treated, accepted, transferred, or avoided. "Not decided" is not an acceptable status.
Collection: Quarterly from the risk register.
Why important: Shows whether your risk management process is working or whether risks are identified but not addressed. A low value indicates missing resources or lack of prioritization.
KPI 2: Overdue Risk Measures Rate
Definition: Proportion of planned risk treatment measures that have exceeded their target date.
Formula: (Overdue measures / Total number of planned measures) x 100
Target value: < 15%. Some delays are normal (resource conflicts, unforeseen complexity). But more than 15% overdue measures indicate systematic problems.
Collection: Monthly from the measures tracking system.
Why important: Shows whether planned measures are actually being implemented. A high value may indicate unrealistic planning, missing resources, or lack of commitment.
KPI 3: Average Risk Level
Definition: Weighted average of all assessed risks (by risk matrix score).
Target value: Declining over time. The absolute value depends on your risk matrix. The trend is more important than the absolute value.
Collection: Quarterly during the risk review.
Why important: Shows the overall trend of your risk level. If it rises despite measures, you need to rethink your strategy. If it falls, it confirms the effectiveness of your measures.
Area 2: Operational Security
KPI 4: Patch Compliance Rate
Definition: Proportion of systems patched within the defined timeframe.
Formula: (Systems patched on time / Total number of systems to be patched) x 100
Target value: > 95% for critical patches within 14 days. > 85% for all patches within 30 days. For OT systems, separate, longer timeframes apply (quarterly patch cycles may be appropriate).
Collection: Monthly from the patch management system.
Why important: One of the most meaningful operational KPIs. Shows whether known vulnerabilities are being closed in a timely manner.
KPI 5: Mean Time to Vulnerability Remediation (MTTV)
Definition: Average time from the publication of a vulnerability to its remediation (patch or compensating control).
Formula: Sum (Remediation date - Publication date) / Number of remediated vulnerabilities
Target value: < 14 days for critical vulnerabilities (CVSS >= 9.0). < 30 days for high vulnerabilities (CVSS >= 7.0). < 90 days for medium vulnerabilities.
Collection: Monthly, differentiated by criticality.
Why important: Shows the response speed of your vulnerability management. A rising trend indicates growing technical debt.
KPI 6: Multi-Factor Authentication Coverage
Definition: Proportion of systems and access points protected with MFA.
Formula: (Access points with MFA / Total number of relevant access points) x 100
Target value: 100% for external access (VPN, cloud, web applications). > 90% for privileged internal access (admin accounts).
Collection: Quarterly.
Why important: MFA is one of the single most effective security measures. This metric shows how consistently it is implemented.
KPI 7: Backup Success Rate
Definition: Proportion of planned backups that were successfully performed and verified.
Formula: (Successful backups / Planned backups) x 100
Target value: > 99%. Every failed backup is a potential data loss in an emergency.
Collection: Weekly from the backup system, aggregated monthly.
Why important: A backup that does not work is not a backup. This metric uncovers technical problems before they become relevant in an emergency.
KPI 8: Recovery Test Rate
Definition: Proportion of critical systems for which a successful recovery test was performed during the reporting period.
Formula: (Systems with successful recovery test / Total number of critical systems) x 100
Target value: 100% within 12 months. Every critical system should undergo a recovery test at least once a year.
Collection: Quarterly.
Why important: A backup without a recovery test is hope, not a plan. This metric ensures that recovery actually works.
Area 3: Compliance and Awareness
KPI 9: Security Awareness Training Rate
Definition: Proportion of employees who have completed their annual security awareness training.
Formula: (Trained employees / Total number of employees) x 100
Target value: > 95%. The remaining 5% can be explained by long-term illness, parental leave, or new hires. But every employee who has been with the company for more than three months should be trained.
Collection: Quarterly.
Why important: NIS2 explicitly requires training for all employees. How to build an effective security awareness program is described in a separate article. Without a demonstrable training rate, you have a compliance problem.
KPI 10: Phishing Simulation Rate
Definition: Proportion of employees who fell for a phishing simulation.
Formula: (Employees who clicked / Total number of tested employees) x 100
Target value: < 5%. The industry average is 15-20%. A value below 5% indicates an effective awareness culture.
Collection: With each simulation (recommended: quarterly).
Why important: Measures the actual resilience of employees against social engineering, not just whether they attended a training session.
KPI 11: Policy Review Rate
Definition: Proportion of ISMS policies that were reviewed and updated within the defined review cycle.
Formula: (Policies reviewed on time / Total number of policies) x 100
Target value: 100%. Outdated policies are worse than no policies because they convey a false sense of security.
Collection: Quarterly.
Why important: Shows whether the ISMS is alive or whether it was built once and then forgotten.
KPI 12: Audit Finding Resolution Rate
Definition: Proportion of audit findings (internal and external) that were resolved within the agreed timeframe.
Formula: (Findings resolved on time / Total number of open findings) x 100
Target value: > 90%. For major findings: 100% within the agreed timeframe.
Collection: After each audit, with ongoing tracking until resolution.
Why important: Open audit findings show that identified problems are not being fixed. This is a risk and a compliance problem.
Area 4: Incident Management
KPI 13: Number of Security Incidents
Definition: Total number of reported and confirmed security incidents during the reporting period, differentiated by severity.
Target value: No absolute target value. The trend is decisive. An increase may indicate a deteriorating security posture but could also indicate improved detection (which is positive). What matters is the qualitative analysis: Why did the value increase or decrease?
Collection: Monthly from the incident management system.
Why important: The most basic incident metric. Gives executive management an overview of the threat landscape.
KPI 14: Mean Time to Detect (MTTD)
Definition: Average time from the initial infection/start of the incident to detection.
Formula: Sum (Detection time - Incident start) / Number of detected incidents
Target value: < 24 hours for critical incidents. The industry average is several weeks (according to the IBM Cost of a Data Breach Report). Any improvement is significant.
Collection: For each incident as part of the incident analysis.
Why important: The faster you detect an incident, the less damage it causes. A declining MTTD shows that your detection capabilities are improving.
KPI 15: Mean Time to Respond (MTTR)
Definition: Average time from detection of an incident to complete containment.
Formula: Sum (Containment time - Detection time) / Number of detected incidents
Target value: < 4 hours for critical incidents. < 24 hours for high-severity incidents. For NIS2-obligated companies: Initial report to the BSI within 24 hours.
Collection: For each incident as part of the incident analysis.
Why important: Shows how quickly your incident response process reacts. A rising value indicates resource problems or process gaps.
Collecting and Reporting Metrics
Data Sources
Most ISMS metrics can be collected from existing systems in an automated or semi-automated manner:
| KPI | Data Source |
|---|---|
| Patch compliance | Patch management system, WSUS, Intune |
| Backup success rate | Backup software, monitoring |
| MFA coverage | Identity provider (Entra ID, Keycloak) |
| Training rate | LMS, training records |
| Phishing rate | Phishing simulation tool |
| Incident metrics | Ticketing system, SIEM |
| Risk metrics | ISMS tool, risk register |
| Policy review | ISMS tool, document management |
| Audit findings | Audit reports, measures tracking |
Reporting Frequency
Not every metric needs to be reported at the same frequency:
Monthly (operational reporting): Patch compliance, backup success rate, incident metrics, phishing simulation rate (when simulation occurred)
Quarterly (tactical reporting): All 15 KPIs as a complete overview, trend analysis, deviation analysis
Annually (management review): Summary of all quarterly reports, annual trends, target achievement, derivation of measures and resource needs for the next year
Presentation
For the management review, a one-page overview with traffic light colors is recommended:
- Green: Target value met or exceeded
- Yellow: Target value narrowly missed (within a defined tolerance)
- Red: Target value significantly missed
Supplement the traffic light overview with trend arrows (rising, stable, falling) to make the development visible at a glance. For each red traffic light, there should be a brief explanation and a proposed action.
Presenting Metrics in the Management Review
The management review is the moment when your metrics have their impact. This is where it is decided whether executive management understands the state of information security and whether they are prepared to provide the necessary resources.
Structure of the KPI Report
A proven structure for the KPI report in the management review:
Page 1: Executive Summary. The traffic light overview of all 15 KPIs with trend arrows. Plus three to five sentences summarizing the overall situation. Executive management should know within 30 seconds whether there is a problem.
Pages 2-3: Detailed analysis of notable KPIs. For each yellow or red traffic light: What is the current value? What is the target value? What is the cause of the deviation? What action is proposed? By when is improvement expected?
Page 4: Trends and year-over-year comparison. All 15 KPIs over time for the last four quarters (or twelve months). This is where it shows whether the ISMS is improving overall. A consistently rising patch compliance rate or declining response time is the strongest argument for the effectiveness of the ISMS.
Page 5: Resource requirements. Based on the metrics: What investments or resources are needed to achieve the target values? This is where the connection between metrics and budget is established.
Anticipating the Right Questions
Executive management will typically ask three questions:
-
Are we secure enough? Answer this question with the overall risk status and comparison to the previous year. Show which critical risks have been treated and which remain open.
-
Are we getting better? Answer this question with the trend lines. If the trends are positive, emphasize the effectiveness of previous measures. If they are negative, explain the causes and propose countermeasures.
-
What do you need? This is where concrete resource requirements come in: Budget for a new tool, additional person-hours for a project, approval for a training measure. Link each requirement to a specific metric that will improve as a result.
From KPIs to Actions: The Control Loop
Metrics are only useful if they lead to actions. The control loop works as follows:
Measure: Collect the metric and check it against the target value.
Analyze: Why does the actual value deviate from the target value? Is it a technical problem, a resource problem, or a process problem?
Act: Define and implement a measure. The measure must be specific, have a deadline, and be assigned to a person.
Check: Has the measure improved the metric? If yes: Document lessons learned. If no: Define an alternative measure.
This control loop corresponds to the PDCA cycle that forms the backbone of every ISMS. Without it, the metric remains a passive observation rather than an active management instrument. In ISMS Lite, the most important KPIs are automatically calculated from documented measures, risks, and incidents and visualized in the dashboard.
A concrete example: Patch compliance for critical vulnerabilities is at 72% (target: 95%). Analysis shows: 60% of the overdue patches concern systems for which the software vendor has not yet granted approval. The action: Introduce an escalation process with the vendors and define compensating controls for systems without vendor approval. Next measurement: Check in three months whether the measure is working.
Common Pitfalls
Too many metrics. If you have 50 KPIs, nobody reads the report. Start with the most important 5-7 and expand gradually. Better to have a few metrics that are regularly collected and discussed than many that gather dust in a spreadsheet.
Metrics without target values. A metric without a target value is just a number. Define a target value and a tolerance for each metric. Only then can you judge whether the result is good or bad.
Wrong incentives. If the phishing simulation rate is used as a performance indicator for department heads, department heads will start warning their employees before the simulation. Metrics should improve security, not improve reporting.
Underestimating collection effort. If a metric must be collected manually, it will no longer be collected after three months. Automate as much as possible. If automation is not possible, honestly assess the effort and decide whether the metric is worth it.
Ignoring trends. A single value says little. The trend over several quarters shows whether you are getting better or not. Always show at least the last four quarterly values.
The Starting Plan: Five KPIs to Begin With
If you are at zero today and do not know where to start: Choose these five KPIs as a starter set. They cover the most important areas, are collectible with reasonable effort, and deliver immediate value.
-
Patch Compliance Rate (KPI 4): Shows the fundamental operational state. If you do not know whether your systems are current, you know nothing about your security posture.
-
Backup Success Rate (KPI 7): Shows whether you can recover in an emergency. The most existential question after a ransomware attack.
-
Security Awareness Training Rate (KPI 9): Shows whether the human factor is being addressed. And it is a demonstrable requirement under NIS2.
-
Number of Security Incidents (KPI 13): The most basic metric. Without it, you have no overview of the threat landscape.
-
Risk Treatment Rate (KPI 1): Shows whether your risk management is working. If risks are identified but not treated, the ISMS is a facade.
With these five KPIs, you can shape a first management review substantively. After six months, once data collection is running routinely, you gradually expand to the full 15 KPIs.
Further Reading
- Building a Security Dashboard: Which Metrics Belong on the Screen
- Measuring Your ISMS Maturity: From Beginner to Optimized
- Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees
- Mastering the Management Review: Preparation, Execution, and Follow-Up