Executive Cyber Metrics: What to Stop Reporting

Most executive cyber dashboards measure effort. They report how much the security team did, how many alerts it processed and how many patches it applied. A board cannot act on any of that. What it needs to know is whether the organization is more or less likely to suffer a damaging event than it was last quarter, and what it should decide because of the answer.

That gap is the reason to stop reporting some things. Every metric on a board pack costs attention, and attention is the scarce resource. A metric that does not change a decision is not neutral. It crowds out one that would.

A test for every metric

Before a measure goes into an executive report, ask one question: if this number moved sharply, what would leadership do differently? If the honest answer is “nothing,” or “ask us to explain it,” the measure belongs in the security team’s operating reviews, not in front of the board.

The test is deliberately blunt. It removes most volume metrics at once, because volume rises and falls with things outside the security team’s control, such as the number of internet-facing systems, the size of the workforce and the noise level of the tools.

What to stop reporting, and what to report instead

None of these measures is useless. They help the security team run its operation. The mistake is promoting them to a different audience with a different job.

Why the board’s job should drive the metrics

Board duties are specific, and in some regimes they are written down. In the United States, the Securities and Exchange Commission’s cybersecurity disclosure rules require public companies to describe the board’s oversight of cybersecurity risk and management’s role in assessing and managing it. They also require a Form 8-K disclosure within four business days of determining that a cybersecurity incident is material.

That second requirement has a quiet consequence for reporting. A board that may need to support a materiality determination quickly needs to have seen, in advance, the information that determination depends on: which systems matter most, what an outage or data loss would cost the business, and how fast the organization can scope an incident. If your regular metrics say nothing about those things, the first time the board sees them will be during a crisis.

The same logic applies outside the US. The UK National Cyber Security Centre’s Cyber Governance Code of Practice sets out five areas for boards: risk management, strategy, people, incident planning, response and recovery, and assurance and oversight. NIST’s Cybersecurity Framework 2.0 gives oversight its own category within Govern. Different regimes, same expectation: leadership should be able to show it understood the risk and checked that controls were working. Check which regimes bind your organization before assuming any of them do.

What good looks like

A short pack tends to work better than a thorough one. Aim for a page and a half of content built around decisions.

• Exposure that matters. Your most important systems and the paths to them that are currently open. Link each to a business consequence in money, downtime or regulatory exposure, using ranges, not false precision.

• Control effectiveness, tested. Evidence from exercises, red-team work or recovery tests that controls do what you claim. A control that has never been tested is an assumption.

• Response and recovery capability. Time to detect, scope and contain on realistic scenarios, and whether critical systems can be restored within the time the business requires.

• Risk against appetite. Where current risk sits relative to the level leadership has agreed to accept, and what it would take to close the gap.

• Decisions required. Explicit asks, each with options, cost and consequence. If a pack has no asks, ask whether it needs to be a pack.

Retiring metrics without losing trust

Removing a number a board has seen for years can feel like hiding something. Handle it openly. Tell the board what you are removing, why it does not support a decision, and where it will still be tracked. Keep the operational detail available on request. Boards usually welcome the change once they see that the replacement gives them something to decide.

Expect pushback inside the security team too. A metric that makes the team look busy is comfortable. One that shows an unresolved exposure on a crown-jewel system is not. That discomfort is the point.

Where this can go wrong

• Replacing vanity metrics with precise-looking risk numbers. Quantified risk is valuable when the inputs are defensible. A dollar figure built on guesses is the heat map in a different suit. State the range and the confidence.

• Measuring what is easy to export. The data a tool produces by default is rarely the data a decision needs. Be willing to collect some measures by hand until they prove their value.

• Letting a metric become the goal. When a measure is tied to targets or bonuses, people optimize the measure. Pair every metric with a check that it still reflects reality.

Sources

• U.S. Securities and Exchange Commission, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (final rule): Form 8-K Item 1.05 and Regulation S-K Item 106. sec.gov

• UK National Cyber Security Centre, Cyber Governance Code of Practice: five board-level principles. ncsc.gov.uk

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: Govern function, including oversight. csrc.nist.gov