The technical response to a security breach — containment, forensics, restoration — is the CISO’s domain. Boards that try to manage the technical response typically make it worse. But the governance response in the first week is the board’s domain, and most boards get it significantly wrong.
The cost of getting it wrong is not primarily the breach itself. It is the governance failure in the first week that multiplies the regulatory exposure, extends the customer trust damage, and creates the board-level liability that regulators focus on in investigations.
I am going to describe the specific governance failures I see in the first week, because they are predictable enough to prevent.
Failure 1: The board finds out too late
The governance pre-condition for everything that follows in a breach response is that the board is informed promptly. Under NIS2, essential and important entities must notify their competent authority within 24 hours of becoming aware of a significant cybersecurity incident, with a full notification within 72 hours. GDPR requires notification of a personal data breach to the supervisory authority within 72 hours.
Neither regulation specifies that the board must be informed before the competent authority is notified. But the board is the governance body with accountability for the organisation’s regulatory compliance. If the board is informed after the notification has been submitted, it has been presented with a fait accompli rather than given the opportunity to exercise governance.
The boards that manage breach responses well typically have a standing protocol: notification to the board chair within four hours of a confirmed significant incident, with an initial briefing to the full board within 12 hours. This protocol exists before the incident, not as an improvisation during it.
The failure is common because most incident response plans focus on the technical response team and the notification obligations, without explicitly addressing board notification timing. The result: the board discovers the breach when the CISO presents the “what happened and what we are doing” update, often 24-48 hours after the incident was confirmed, at which point several governance decisions have already been made without board input.
Failure 2: Legal counsel is not in the room before the board discussion
The first board discussion of a security breach typically happens without legal counsel present. The CEO or CISO presents the incident, the board asks questions, and responses are given — all in a context where the legal privilege over subsequent communications may be compromised by what was said in the room.
Legal advice privilege and litigation privilege apply to communications between a company and its legal advisers for the purpose of giving or receiving legal advice. They do not cover general management discussions about an incident, even if legal considerations are raised informally. A board discussion about a security breach that takes place before external legal counsel is engaged — or in the presence of legal counsel who is not specifically advising on legal exposure — may produce documents and statements that are discoverable in subsequent regulatory proceedings.
The governance position: the board’s first substantive discussion of a security breach should involve external legal counsel specialising in cybersecurity regulatory matters, not as a future addition but as a precondition. The chair should not convene a full board discussion of the breach until that counsel has been briefed and is available to advise on what can be said, to whom, in what format, without prejudicing the organisation’s legal position.
This takes 12-24 hours to organise. That is why the board notification protocol needs to specify counsel engagement as part of the first response, not a subsequent one.
Failure 3: The board conflates the technical problem with the governance problem
The CISO presents an incident: “on Monday evening, we detected unauthorised access to our customer data systems; by Tuesday morning, containment was achieved; forensics are ongoing; approximately 40,000 customer records may have been accessed; we have notified the ICO under GDPR.”
This is accurate and comprehensive as a technical and compliance summary. It is the wrong starting point for a board governance discussion.
The board’s governance question is not “what happened to the systems.” It is “what does this incident tell us about the state of our cybersecurity governance, and what decisions does the board need to make?”
Specifically: Was the security governance structure that was supposed to prevent this incident in place? If yes, why did it fail? If no, why was the board not aware that it was absent? What board-level decisions are now required — on notification, on remediation, on liability, on customer communication, on regulatory engagement? What is the governance accountability picture — who is responsible to the board for the conditions that enabled this breach?
These questions are different from the CISO’s brief. They require the board to assume its governance function rather than receiving a technical briefing. The boards that fail in the first week are typically the ones that spend most of their governance meeting time understanding the technical details of the incident rather than making the governance decisions the incident requires.
Failure 4: Customer communication is improvised
The regulatory notifications — the ICO under GDPR, the competent authority under NIS2 — are typically handled by the legal and compliance team with reasonable process. The customer communication often is not.
Customer communication about a security breach has legal dimensions (what must be disclosed, to whom, when), commercial dimensions (how the communication affects customer trust and retention), and brand dimensions (what the communication says about how the organisation treats its customers and whether it is trusted to act responsibly under pressure).
The board’s governance role in customer communication is to approve the substantive content and timing before it is sent, not to review it after the fact. This requires the board to be available in the first 48-72 hours to review and approve communications that will need to go out on a tight timeline.
The failure is boards that receive a report in the next scheduled meeting that communications went out on such-and-such a date with such-and-such content. By that point, the communication decision is irreversible and the board’s governance role in it is retrospective.
What the first week should look like
Before a breach occurs, a well-governed board has a documented breach response protocol that covers: board notification timing (within four hours of confirmed significant incident), external legal counsel engagement (concurrent with board notification), initial board briefing (within 12 hours, in the presence of counsel), customer communication approval (within 48 hours of the board’s initial briefing), and regulatory notification sign-off (confirmed by board chair or delegated director before submission).
None of this is complicated. None of it is technically demanding. All of it requires the protocol to exist before the incident, so that the first week’s decisions are governed rather than improvised.
The organisations that manage breach responses well are not the ones with the most sophisticated technical response capabilities. They are the ones with the clearest governance protocols — where every person in the response chain knows their role, the board’s role, and the sequence of decisions that need to be made and by whom.
The boards that make it worse are the ones discovering what their governance protocol should have been whilst trying to manage the breach.
The Quantum Risk: What Directors Need to Know covers the cybersecurity governance structure that prevents avoidable breach responses, including the NIS2 notification obligations, personal liability provisions, and the board governance protocol for cybersecurity incidents. For boards seeking independent advisory support on cybersecurity governance, visit Quantum Security Defence or contact Steven directly.
