OT Metrics for the Board: Turning Industrial Security into Decision-Ready Numbers

The problem with compliance metrics in OT

The OT manager or CISO who has to present the security posture of the plants to the board of directors or to ownership often faces a translation problem. The metrics available are technical: number of vulnerabilities detected, obsolete firmware versions, configured firewall rules. The audience wants to know whether it is safe, whether it is investing in the right way, whether it can sleep soundly.

The most common gap is the one between compliance metrics and risk metrics. A NIS2 checklist that marks "compliant" on ten items gives an indication of process, not of real risk. A board that sees a list of green checks can reasonably conclude that the situation is under control, even when the plant's critical devices have had critical vulnerabilities left unresolved for years.

The point is not that compliance is irrelevant: it is that, on its own, it does not answer the question that truly interests management, namely "if something happens, how much does it cost us?". The metrics that are useful for the board must connect the technical posture to the operational impact: potential downtime, production lines at risk, cost per hour of outage.

Fundamental KPIs: what to measure and how

A set of KPIs for OT security must be limited (the board has no time for twenty indicators) and must be stable over time to allow comparison between different periods. Five or six metrics, updated monthly, are worth more than a crowded dashboard.

Percentage of OT assets with unmitigated critical vulnerabilities. This indicator measures how many devices in the OT inventory have at least one CVE with a critical score (CVSS >= 9.0 or EPSS > 0.5) for which no documented compensating control has been implemented. It does not count vulnerabilities in absolute terms, but those for which no explicit decision has been made. A device with a critical CVE for which the team has documented "cannot be patched, isolated in a dedicated VLAN with ACLs" is not in the same category as a device that is vulnerable and completely ignored.

Number of OT assets not recorded in the inventory. The difference between the number of devices that passive monitoring sees on the network and the number of devices in the official register. Every uncatalogued device is a blind spot: we do not know whether it is authorized, we do not know its firmware version, we do not know whether it has vulnerabilities. A positive delta (I see more devices than I have recorded) is a warning sign to investigate.

Monitoring coverage per OT network zone. What percentage of the OT zones defined in the architecture has passive monitoring coverage? Expressed per zone and per criticality: a critical zone without coverage weighs differently from an unmonitored peripheral zone. This KPI measures known blind spots: we know that we cannot see, and we know where.

Mean Time to Detect (MTTD) for OT anomalies. The average time that passes between the moment an anomalous behavior becomes detectable (a new device appears on the network, a communication outside the baseline begins) and the moment it is picked up by an analyst. In OT this indicator is particularly significant because the most sophisticated attacks move slowly: an MTTD of hours instead of days radically changes the ability to contain.

Percentage of OT devices with firmware on a vendor-supported version. Distinct from the KPI on critical vulnerabilities: this measures how many devices are outside the vendor's support cycle, meaning they will not receive new security patches regardless of specific CVEs. End-of-life devices in OT environments tend to accumulate silently over the years.

KRIs: early warning signals of deterioration

KPIs measure the current state. KRIs (Key Risk Indicators) signal trends that, if not corrected, will lead to a deterioration. For the board, KRIs are often more useful than KPIs because they enable proactive rather than reactive decisions.

Unexplained monthly variation in the inventory. How many new devices have appeared on the network in the current month compared to the baseline, excluding those expected from work orders or expansion projects. A steady increase suggests that the change management processes are not working: devices are being connected without going through the authorization process.

Trend of unmitigated critical vulnerabilities. Not the absolute number, but the direction: is the number of unmitigated critical vulnerabilities growing, staying stable, or decreasing? A steady increase, even starting from low numbers, indicates that the remediation process (or the process of assessing and accepting residual risk) is not keeping pace with the discovery of new vulnerabilities.

Remote access outside hours or outside procedure. The number of remote access sessions to OT systems that occur outside authorized maintenance windows or without an associated ticket. In OT, unauthorized remote access is one of the most frequent compromise vectors; monitoring its trend over time reveals whether the controls on remote access are working.

OT alerts closed without investigation. How many alerts generated by the monitoring system are closed automatically or with a "noise" resolution without any real analysis? A growing rate can indicate two things: the detection rules are generating too many false positives (and need to be reviewed), or the analysts are overloaded and are closing alerts without examining them (and resources need to be added). Both are risk situations.

How to present the metrics to the board

The format matters as much as the numbers. A few practical pointers for making OT metrics accessible to a non-technical audience.

Link every metric to a concrete operational impact. Not "30% of assets have unmitigated critical CVEs" but "the 30% of assets includes four PLCs on lines A, B, and C: an attack on these devices could stop production for an estimated X hours, at a cost of X euros". The link to operational risk requires preliminary assessment work with the operations team, but it transforms the metric from technical to decision-ready.

Use temporal comparison. A metric in isolation says nothing. The same metric three months later tells you whether the situation is improving or worsening. The trend is the most useful figure for the board: not "we are at 30%" but "we were at 45% three months ago, we are at 30% today, the target by year-end is 15%".

Apply traffic lights with explicit thresholds. Defining in advance the green, yellow, and red thresholds for each KPI eliminates interpretive ambiguity and reduces the tendency to present everything as "under control". The thresholds must be discussed and approved by management: when MTTD exceeds X hours, you are in yellow; when it exceeds Y hours, you are in red and a specific procedure is triggered.

Separate operational reporting from strategic reporting. The SOC or the OT team needs granular and frequent metrics. The board needs four or five summary indicators, once a quarter, with a clear interpretation of what they mean and what is being done. Do not bring the list of 200 open CVEs to the board: bring the percentage of critical assets covered by a remediation plan with a deadline.

Common mistakes to avoid

Metrics that always trend toward the good. If every metric presented to the board shows quarter-after-quarter improvement, the board should ask questions. A real security posture in a real environment has periods of deterioration, spikes during plant changes, regressions. A dashboard that shows only steady progress is probably miscalibrated or selective.

Metrics without a denominator. "We detected 150 anomalies this month" says nothing without knowing how many anomalies were investigated, how many were real threats, how many were false positives. Absolute metrics without context create the wrong expectations.

Compliance KPIs as a surrogate for risk. Having completed the NIS2 self-assessment questionnaire, having produced the asset register required by IEC 62443, having updated the written procedures: all of this is necessary but does not measure real risk. An organization can be formally compliant and substantially exposed. The board must understand the difference.

Ignoring documented residual risk. If the team has documented that ten devices have unmitigable critical vulnerabilities and has adopted compensating controls, these vulnerabilities must not disappear from the metrics as if they did not exist. They must be visible as "residual risk knowingly accepted with compensating measures". The difference between accepted risk and ignored risk is crucial for responsible governance.

The MON5 angle

Uncatalogued assets, unmitigated critical vulnerabilities, monitoring coverage, MTTD: the KPIs and KRIs in this article exist only if something measures them continuously. MON5 produces them as a by-product of its operation: continuous asset inventory highlights the delta between devices seen on the network and devices recorded, while the correlation of CVEs with EPSS scores and real exposure distinguishes managed risk from ignored risk.

The modular path lets you start small and expand the metrics in phases, from a single site to a multi-plant group. To establish the baseline for the first dashboard to bring to the board, start with an OT assessment.