Making cyber risk useful in the boardroom

Most boards are not under-informed about cyber security. They are over-supplied with information and under-supplied with decisions. This paper sets out the approach I use to close that gap: five moves, each of which can be made independently, and none of which requires a new tool.

The problem with the standard cyber update

The conventional board pack contains a maturity score, a heat map, a patching percentage and a list of incidents. Every item is defensible in isolation. Collectively they answer a question nobody asked: how is the security team doing? What the board needs to answer is different: are we carrying more risk than we said we would, and what are we going to do about it this quarter?

Three symptoms tell you a board pack has drifted: the discussion is about the numbers rather than about choices; the same risks appear unchanged for three cycles; and no agenda item ever ends in a funded action or a formal acceptance.

Move 1 — Anchor risk to services, not systems

Boards own services and outcomes, not infrastructure. Reframe the top of your risk picture around the handful of things the organisation cannot afford to lose: the payments run, the claims service, the clinical system, the customer platform. Then express technical exposure as a threat to those.

This single change usually reduces the reported risk count by an order of magnitude and increases engagement dramatically, because every remaining line has an obvious business sponsor.

Move 2 — Set appetite in refusable terms

"Low appetite for cyber risk" is not appetite; it is a sentiment. Usable appetite statements are specific enough that somebody could breach them, notice, and be required to escalate.

• We will not run internet-facing services with unremediated critical vulnerabilities beyond 14 days.
• We will not onboard a supplier with access to personal data without an assurance outcome recorded.
• We accept up to four hours of recovery time for Service A; anything above that requires board approval.

Appetite defined this way turns your reporting into an exception report, which is the only kind of report a board can process at speed.

Move 3 — Report exposure, tolerance and trajectory

For each critical service, three things belong on the page: where we are, where we said we would be, and which way we are moving. Trajectory matters most. A high risk that is closing on schedule needs no board time; a medium risk that has worsened for two quarters needs all of it.

I would rather present six lines with honest direction of travel than a forty-page annex with a flattering average.

Move 4 — Attach cost, owner and date to everything

Every item that reaches a board should carry four attributes: the exposure, the accountable executive, the cost of the proposed treatment, and the date by which the position changes. Where the answer is to accept, the acceptance is minuted with a review date and a named accepter. This is the discipline that stops risk registers becoming archives.

A risk that cannot be funded, owned or accepted is not a risk item. It is an unfinished piece of analysis.

Move 5 — Rehearse the bad day

Nothing improves board understanding of cyber risk faster than ninety minutes of a realistic scenario in which they, not the security team, have to make the calls: pay or not pay, disclose or wait, keep trading on degraded systems or stop.

Run it once a year with the executive team and the communications lead in the room, and capture the decisions that turned out to be unmakeable because of a missing capability. Those gaps are your investment case, written by the board itself.

A reporting structure that holds up

• One page: critical services, exposure against tolerance, direction of travel.
• One page: decisions requested this cycle, each with cost, owner and date.
• One page: breaches of appetite since last meeting, with what was done.
• Annexes: everything else, available and rarely read — which is fine.

Cadence

Quarterly to the board, monthly to an executive risk group, continuous to delivery teams. The board's job is direction and money; the executive group's job is unblocking; the delivery team's job is closure. Reporting fails when one forum is asked to do all three.

How to tell it is working

• Cyber items leave the meeting with decisions rather than noting.
• Risk acceptances are explicit, owned and time-bound instead of implied by inaction.
• Investment requests are traceable to a service the board already cares about.
• The security team spends less time explaining its scores and more time closing exposure.

None of this is exotic. It is the difference between reporting on security and governing it — and in my experience it is worth more than the next tool on the roadmap.