Boards have spent years debating whether they should hire a Chief Digital Officer. They've hired consultants to help them understand AI risk. And yet most boards are completely unprepared for the thing most likely to test their governance in real time: a significant cybersecurity incident.
A ransomware attack. A data breach. A third-party supplier compromised. These aren't hypotheticals. They happen to well-run companies with capable technology teams. And when they happen, the board's role is not to fix the technical problem, it's to govern through a crisis they almost certainly didn't rehearse.
Why boards are usually unprepared
The most common failure mode is this: the board is told that "we take cybersecurity seriously," cyber risk appears on the risk register, and there's a brief mention of it at the annual strategy away day. Nobody on the board has read the incident response plan. Nobody has asked who specifically would call whom if something happened at 11pm on a Saturday.
This is not negligence, it's a structural gap. Boards are asked to oversee cyber risk without being given a framework for what that oversight actually looks like under pressure. The result is boards that understand cyber risk in the abstract but have no muscle memory for acting on it when it's real.
A significant incident also moves faster than most board processes. Decisions that would normally take a board meeting, whether to pay a ransom, when to notify regulators, how to communicate with customers, need to happen in hours. If the governance structures aren't built in advance, you'll be improvising them during the crisis.
Before: what good preparation looks like
Good cyber governance starts long before any incident. The board's job in the preparation phase is primarily about asking the right questions and ensuring the right structures are in place.
- Who is the CISO or equivalent, and does the board have a direct relationship with them, not just through the CEO?
- Has the board reviewed and approved the incident response plan, and does it include board-level escalation criteria?
- What are the regulatory notification requirements, and who owns that decision when time is short?
- Has the organisation run a tabletop exercise that includes board members?
- What cyber insurance coverage exists, and has the board verified that it would actually apply to the most likely scenarios?
The tabletop exercise is the piece most boards skip. It feels like an overhead, a whole afternoon of simulating something that probably won't happen. But it's the only way a board discovers in advance whether its decision-making process can handle compressed timelines and incomplete information.
During: the board's actual role
When an incident is live, the board's primary job is to enable management to respond, not to manage the incident itself. This distinction is easy to state and genuinely difficult to practise under pressure.
Concretely, this means:
- Establishing a clear communication rhythm so the board is informed without overwhelming the response team
- Providing decision authority for choices that exceed management's normal remit, ransom payments, emergency expenditure, decisions to notify before the facts are fully established
- Coordinating with legal counsel on regulatory obligations, which vary significantly by jurisdiction and type of data involved
- Managing external communication, particularly if the incident becomes public, where the board's credibility may be needed
The chair of the board typically has a specific role here: maintaining composure and communication with major stakeholders, including investors, while the management team focuses on the technical response. If the company is publicly listed, the interaction with financial markets communications becomes another immediate complexity.
The ransom decision
Ransomware incidents create a particularly acute governance challenge. The question of whether to pay a ransom is one that boards need to have a pre-agreed position on, because under the pressure of an active attack, with systems down and operations halted, the argument for paying can feel compelling even if it isn't the right call.
The considerations are complex, regulatory prohibitions in some jurisdictions, the question of whether payment guarantees restoration, the precedent it sets, the reputational implications. But the point is that this decision should not be made in the heat of an incident by people who haven't thought through it in advance. The board needs a position before it needs it.
After: review and accountability
The post-incident review is where board governance is most commonly neglected. It's tempting to declare the incident over once systems are restored and move on. But the review phase is where boards actually learn, and where they determine whether the incident reflects a governance failure, a management failure, or genuinely bad luck.
A proper board-level post-incident review asks:
- Was the incident response plan effective, and where did it break down?
- Was the board's decision-making process adequate given the time pressure?
- Were there early warning signals that should have been escalated sooner?
- What changes to risk management and investment are now required?
- If regulators are involved, how is the remediation plan being managed?
The review should produce concrete changes, not just to technical infrastructure, but to governance processes. If the board discovered during the incident that it didn't know who to call or what authority it had, that's a governance gap that needs to be closed before the next one.
What this requires of board members
None of this requires board members to be cybersecurity technicians. It requires them to ask hard questions in advance, participate in scenario planning, understand the company's regulatory obligations, and be clear about what decisions they reserve for themselves versus delegate to management.
The CISO relationship matters more than most boards realise. The CISO needs to trust that they can escalate a genuine concern to the board without it being filtered or minimised at the executive layer. And the board needs enough of a direct relationship with the CISO to assess whether the assurances they're receiving are well-founded.
Cyber risk has moved from a technology issue to a governance issue. The boards that manage it well have treated it that way before anything went wrong.