Security metrics (KPIs)

ISO/IEC 27001:2022 clause 9.1 requires the organisation to determine what needs to be monitored and measured, including information security processes and controls; the methods, which should produce comparable and reproducible results to be considered valid; when monitoring and measurement are performed and who performs them; and when and by whom the results are analysed and evaluated. The results must be retained as documented information and are an input to management review (9.3.2). ISO/IEC 27004:2016 gives guidance on building such measures, and NIST SP 800-55, revised in December 2024 as Volume 1 (identifying and selecting measures) and Volume 2 (developing a measurement programme), replaced the 2008 Revision 1.

A well-specified measure has a documented definition: purpose, formula, data source, collection frequency, owner, target and thresholds for action. Common types are implementation measures (share of endpoints with EDR, share of accounts with MFA), effectiveness or efficiency measures (median time to remediate critical vulnerabilities, mean time to detect and to respond, share of phishing simulations reported within ten minutes) and impact measures (incidents with business impact, downtime, cost). Leading indicators predict future problems (backlog of unpatched internet-facing systems), while lagging indicators confirm what already happened (incidents). Key risk indicators (KRIs) track exposure against the risk appetite, whereas KPIs track how well a process performs; a board dashboard usually needs both.

Measurement design is where most programmes fail. Averages hide tails, so vulnerability remediation is better reported as percentiles or as the share closed within the SLA, split by asset criticality. Denominators must be stable: "percentage of servers patched" is meaningless if the inventory is incomplete, which ties metrics to asset management. Goodhart's law applies fully: when click rate in phishing tests becomes a target, simulations get easier; reporting rate and time-to-report are harder to game. Activity counts (courses held, scans run, alerts closed) describe effort, not effect.

Metrics also serve legal duties. NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of the risk-management measures, and ISO/IEC 27002 control 5.35 calls for independent review of information security. Unlike a maturity rating, which describes how established a process is, a metric describes what the process achieves, and the two are most useful when reported side by side with a trend line rather than as single snapshots.