Security reporting usually fails in the same direction: it grows. Each quarter another chart is added, none is ever retired, and the pack that reaches the board becomes long, comprehensive and unreadable. Better visualisation does not fix that. A rule about what earns a place in the pack does.
A metric has exactly one purpose: to prepare a decision. Anything that does not serve that purpose is reporting volume. The test is blunt: if nobody can name a person who would act differently at a given value, the metric does not belong in the report.
What clause 9.1 actually asks for
ISO/IEC 27001 requires you to determine what is monitored and measured, by which methods, when and by whom, and when the results are evaluated. It prescribes no metrics whatsoever. What gets audited is therefore not your choice of indicators but whether that choice is reasoned and the process behind it is defined and followed. An auditor who finds five well-run metrics with evidence of evaluation is satisfied; one who finds forty metrics and no evaluation record is not, however impressive the dashboard.
Metric, KPI, KRI
| Term | Question it answers | Character |
|---|---|---|
| Metric | What is the case? | A raw measurement, such as the number of open findings |
| KPI (key performance indicator) | Are we meeting our objective? | A measurement with a target value and a named owner |
| KRI (key risk indicator) | Is our risk rising? | A leading indicator that signals a development before damage occurs |
The distinction is not academic. A KPI evaluates performance in hindsight; a KRI points at a trend. Measure performance only, and you find out about the problem after it has happened.
Six statements make a metric usable
Every metric needs the same six: the base measure together with its population, the target or threshold, the data source, the measurement interval, the recipient, and the consequence of a breach in either direction. Without the population, a value cannot be interpreted — twelve open vulnerabilities mean one thing across two hundred systems and something quite different across eight.
The data source deserves equal attention, and gets it far less often. A metric that has to be assembled by hand each quarter rarely survives three of them.
Three layers: implementation, process, outcome
- Implementation: how far have agreed measures actually been rolled out? The share of systems in the central inventory, say, or the coverage of a hardening baseline. Easy to collect, and silent on effectiveness.
- Process quality: are the processes running as designed? Time to remediation by severity, the share of access requests handled within the agreed period, the proportion of emergency changes among all changes.
- Outcome: is the result changing? The number and severity of security incidents, the share of incidents detected internally rather than reported from outside, the results of recovery tests.
The third layer is the most informative and the least often reported, because it is the one that can make the function look bad. A board pack should carry a few metrics from each layer rather than many from the first.
Perverse incentives
Any metric people are measured against changes their behaviour, including where that was never intended. Report the number of incidents raised as a negative and the reporting rate falls, not the incident rate. Measure the closure rate of audit findings and findings start being written smaller.
Two things work against this. Paired metrics make the side effect visible: reported incidents alongside time to detection, closure rate alongside the share of findings reopened. And a stated position that raising an issue is evidence of a functioning organisation rather than evidence of failure. That position has to come from management, and it has to survive the first quarter in which the numbers look worse than before.
Where the numbers land
Metrics belong in a fixed cadence and in the management review, where they are assessed alongside audit results, incidents and the status of the risk treatment plan. What carries the argument is the time series: a single value describes a state, only the trend shows whether the management system is working. That argues for a small, stable set that stays comparable across years, rather than a fresh selection whenever the reporting template is revised.
When a customer's due diligence questionnaire or an acquirer's data room asks how you measure security, this is what they are asking for. Not the list of indicators, but evidence that someone looks at them on a schedule and acts on what they show.
Where the numbers in Rizzqo come from
Most security metrics fail on their provenance: they are gathered for the report and age between two meetings. In Rizzqo they arise as a by-product of execution. An asset's coverage follows from its finalised requirement answers, category and framework figures aggregate above that, and a daily snapshot freezes the values so a trend appears instead of a single moment.
Alongside coverage, the risk side sits in the same data: exposure in euros, movement over time, the distribution of treatment decisions and where accountability lies. Because both are computed from the same objects, a management report cannot diverge from the operational picture; there is no second source for it to quote.