How should critical infrastructure operators measure cyber resilience when budgets, staffing, and legacy systems are all constrained?

How to measure resilience when you cannot measure everything

For constrained critical infrastructure environments, the measurement problem is usually not a lack of data, but a lack of usable data. Cyber resilience becomes most meaningful when operators measure a small set of decision-grade signals: what matters most, what is exposed, what is changing, and whether recovery can still meet the business and safety need. That is why a layered view is more useful than a single dashboard or a perfect asset inventory.

The most practical layer is criticality. Operators should be able to identify the systems, processes, and dependencies that would create disproportionate operational impact if they failed, including upstream suppliers and shared services. A resilience measure that ignores interdependencies can look healthy while masking concentrated failure paths, especially in legacy-heavy environments where one platform or remote-access path supports many functions.

The second layer is exposure over time. Continuous monitoring does not need to mean full telemetry everywhere; it means enough reliable evidence to show whether critical assets are changing, whether important controls are drifting, and whether the operating picture is getting better or worse. In practice, that often combines automated control checks, event monitoring, and periodic manual validation so that scarce staff spend time on exceptions rather than routine collection.

What layered measurement should actually tell you

Layered measurement works when each layer answers a different resilience question. Security ratings can provide a coarse external view, but they should be used as directional input, not as proof of resilience. Internal monitoring should answer whether key systems are protected, visible, and recoverable. Dependency mapping should answer where a single failure could cascade. Recovery testing should answer whether the organisation can restore critical services within a tolerable window.

For operators under budget pressure, the key is to avoid treating maturity as the same thing as resilience. A site can have old technology, limited staffing, and still be resilient if it knows its critical assets, has a realistic recovery path, and can detect when assumptions have changed. The measurement set should therefore include leading indicators, such as patch backlog on critical systems, privileged access exceptions, and time to recover from tested outages, alongside lagging indicators such as incident frequency.

That is also why Cyber Resilience Guide is useful here: it frames resilience around impact tolerance, recovery testing, and progress metrics rather than around a perfect perimeter view. For critical infrastructure, that mindset is usually more realistic than trying to instrument every legacy component equally.

How to keep the measurement model credible under constraint

Credibility comes from consistency and scope discipline. Measure the same critical services over time, use the same definitions for availability and recovery, and be explicit about what is excluded. If a team cannot instrument a legacy segment well, it should say so and compensate with stronger compensating controls, targeted walkthroughs, and periodic evidence reviews. Hidden blind spots are worse than known gaps because they create false confidence.

Operators also need to distinguish between control coverage and service resilience. A well-controlled environment can still be brittle if dependencies are poorly understood or recovery has not been exercised. Conversely, a technically imperfect environment may still be acceptably resilient if service restoration is demonstrable, exceptions are contained, and high-risk paths are tightly managed. Measurement should therefore track whether the organisation can function through disruption, not just whether it has control artifacts.

Where staffing is tight, measurement should also help prioritise work. If a metric cannot inform a decision, escalation, or remediation choice, it is probably not worth the operational overhead. The better test is whether the measure helps identify which assets need attention first, which risks are tolerable for now, and which weak points require funded remediation or procedural compensation.

Risk and Threat Considerations

Constrained organisations are most vulnerable to hidden concentration risk, stale dependencies, and overreliance on manual judgment. If the measurement model is too broad, teams cannot maintain it; if it is too narrow, attackers and operational failures can hide in the gaps between monitored and unmonitored systems. That makes resilience failure more likely to appear first as an operational surprise rather than a visible control breakdown.

Failure mechanism: Legacy systems, third parties, and shared services create blind spots unless operators explicitly model critical dependencies and measure change over time. When those dependencies are not tracked, a single weakness can propagate across multiple services before the organisation recognises the loss of resilience.

Impact: The operator may overestimate recovery capability, mis-rank remediation priorities, and discover only during a disruption that critical services cannot be restored within the needed window. In critical infrastructure, that can turn a containable technical event into a service outage with business, safety, or regulatory consequences.

Practitioner Guidance

What to prioritise: Start with the assets and services whose failure would create the largest operational consequence, then add the minimum measurement needed to see their exposure, drift, and recovery readiness. Do not try to build equal visibility for every system when the real objective is decision support for the most critical ones.

What to verify: Confirm that each metric leads to a specific action, such as remediation, exception approval, recovery testing, or supplier follow-up. If a metric is interesting but not decision-grade, remove it or move it lower in the measurement stack.

What good looks like: The organisation can explain its most important dependencies, show whether those dependencies are changing, and demonstrate that recovery assumptions are tested rather than assumed. The measure of success is not completeness, it is whether leadership can make a justified priority call with limited time and staff.

Practitioner takeaway: Under constraint, resilience measurement should be selective, comparative, and operationally useful, because the point is to reveal where failure would matter most and where recovery confidence is weakest.

Related resources from NHI Mgmt Group

• Guide: Hong Kong Protection of Critical Infrastructures Ordinance Guide
• How should critical infrastructure operators build a SOCI-aligned risk management program for cyber resilience?
• How should critical infrastructure operators use national cyber strategy requirements to strengthen resilience before major incidents occur?
• How should critical infrastructure operators respond when a cyber incident forces port systems offline before the attack is fully understood?
• Who should own AI-era cyber defense hardening when risk spans government, vendors, and critical infrastructure operators?