Measuring Resilience Without Counting Incidents

Ask how resilient the company is and someone will reach for the incident count. Zero reportable incidents last quarter. It sounds like safety. It is closer to silence: the absence of a failure tells you nothing about how the organization would absorb one.

Incident counts are lagging indicators. They move after the damage. Worse, they can improve for the wrong reason, when detection gets quieter rather than defenses getting stronger.

Resilience shows up earlier than incidents do, in the organization's ongoing ability to recover, patch, decide and close. Those capabilities are measurable today, without waiting for something to break.

TLDR

• Incident counts measure luck and detection as much as defense.

• Leading indicators move before failure: restore-test pass rate, patch latency, exception aging, exercise closure rate.

• Every resilience metric needs a named owner and a decision it informs.

• A metric that never changes a decision is decoration, not oversight.

• Report four honest numbers rather than thirty reassuring ones.

Why incident counts mislead

Three problems make incident counts weak evidence. First, small numbers carry little information: most quarters have few incidents in any company, so the count cannot distinguish good defenses from a quiet quarter. Second, the count rewards blindness. An organization that stops looking stops finding, and its incident metric improves exactly as its risk worsens. Third, the count says nothing about the failures that did not quite happen, the near misses where one tired engineer or one lucky timing gap stood between the company and a bad week.

NIST's performance measurement guidance makes the underlying point plainly: measures exist to support decisions, and a measure that cannot drive a decision has no place in the program. Incident counts rarely drive one.

Four leading indicators worth the board's attention

Each of these moves before a failure and each forces a decision when it drifts:

• Restore-test pass rate. The share of critical systems whose most recent timed restore met its recovery objective. This is the single most honest resilience number available, because it is evidence, not intent.
• Patch latency on internet-facing criticals. Median days from fix availability to deployment on the systems an attacker would reach first. Trend matters more than any single month.
• Exception aging. The count and age of open risk exceptions, weighted past due. Exceptions are accepted risk; aged exceptions are forgotten risk.
• Exercise closure rate. The share of after-action items closed with evidence, from tabletops and real events alike. It measures whether the organization learns.

Notice what these have in common: each is a capability tested on a normal week, not a disaster counted on a bad one.

The leading-indicator panel

One page, four indicators, each with an owner, a direction, and the decision it feeds. The example below is fictional and illustrative.

Indicator	Current	Direction	Owner	Decision it informs
Restore-test pass rate	4 of 5 systems	Improving	IT Director	Fund the fifth system's fix or re-promise its RTO
Patch latency, internet-facing criticals	21 days median	Worsening	Security Lead	Add maintenance windows or accept exposure openly
Exceptions past due	3, oldest 8 months	Flat	Risk Owner per exception	Retire, renew or remediate each one
Exercise closure rate	60% at 90 days	Improving	COO	Escalate the two oldest open items

The last column is the discipline. If an indicator's decision column stays empty quarter after quarter, drop the indicator. A smaller panel of decision-driving numbers beats a dashboard of wallpaper.

Keep the board out of the engine room

Directors should see the four numbers, the trend, and the decisions taken. Management owns the dials underneath. When the board pack mixes the two layers, meetings burn time on patch counts and miss the question that matters: is our capacity to absorb failure improving?

That framing pairs naturally with the metrics discipline in the five that matter and the five that mislead, and with the broader board view of operational resilience versus business continuity.

Frequently asked questions

What is a leading indicator of cyber resilience?

A measure of a capability that moves before failure: restore-test pass rate, patch latency on critical exposure, exception aging, exercise closure rate. Each is testable on a normal week, unlike incident counts, which only move after damage.

Are zero incidents a good sign?

Not by itself. Zero incidents is consistent with strong defenses, good luck or weak detection. Pair any incident number with at least one capability measure before treating it as reassurance.

How many resilience metrics should a board track?

Few enough that each one has a named owner and a decision it informs, usually three to five. A metric that never changes a decision should be retired from the board pack.

How often should resilience indicators be reported?

Quarterly for the board, monthly for management, with the trend shown against the prior periods. A point-in-time number without a direction invites false comfort.

A Defensible Next Step

Take the last board pack and mark every security number as either lagging (counts what happened) or leading (measures a capability). If the page is all lagging, add one leading indicator this quarter, starting with the restore-test pass rate. Book a Decision-Clarity Call to build the panel around the decisions your board actually makes.