They needed the decision from someone with the authority to make it. The incident response plan listed three executives as responsible for major incident decisions. None of them were reachable within the first forty minutes. The plan did not specify who made the decision if none of them were available.
Distributed Ownership and the Accountability Vacuum
Governance frameworks encourage shared ownership of risk. Cross-functional risk committees, joint accountability between the CISO and business unit leaders, shared responsibility models for cloud environments. Shared ownership distributes the burden of risk management and aligns the people with operational context alongside the people with risk expertise. It is a legitimate governance design.
The failure mode of shared ownership is the accountability vacuum: when the risk materializes, everyone who owns it collectively finds that the ownership did not include a clear answer to the question of who decides and who acts. The risk register said the risk was owned jointly. The incident at 12:30am needed one person with the authority to make a call, a number that would be answered, and a response that would be acted on. Shared ownership produced none of these.
What the Incident Revealed
Post-incident review of the 12:30am decision gap produced several specific findings that are instructive beyond this particular organization. The incident response plan had been last updated fourteen months before the incident. The executive contacts listed had changed: one had left the organization, one had moved to a different role. The plan had not been updated when either change occurred.
The escalation protocol required that the CISO be notified before any executive contact was made. The CISO was traveling in a different time zone. The protocol did not specify a backup escalation path if the CISO was unreachable within a defined timeframe. The security operations team waited twenty-two minutes attempting to reach the CISO before escalating to the next level. Twenty-two minutes of contained dwell time during an active incident.
The business unit whose systems were affected had a separate incident response contact list that had not been integrated with the security operations team's escalation protocol. The business unit leader who could have authorized the containment decision was reachable and was not contacted because the security operations team did not know they were an authorized decision-maker for this system.
The incident response plan documented who owned the risk under normal governance conditions. It did not document who made decisions when the risk became an incident, at what escalation threshold, and what happened when the primary contacts were unavailable. These are different documents. Most organizations have only the first.
The Architecture of Real Accountability
Accountability in incident conditions is different from accountability in governance conditions. Governance accountability is distributed, deliberate, and committee-based — appropriate for the pace of governance decisions. Incident accountability is individual, immediate, and authority-based — required by the pace of incident response. Building governance accountability without building incident accountability leaves a gap that every significant incident will fall into.
Real accountability architecture has specific characteristics. It identifies, by name and by backup, who has the authority to make specific categories of decisions in an incident: containment decisions that affect business operations, breach notification decisions that have regulatory implications, vendor and law enforcement engagement decisions. It specifies the conditions under which each decision type escalates to each level. It includes reachability requirements — on-call rotations, backup contacts, defined response time expectations — that apply to the named decision-makers.
It is tested. Tabletop exercises that test whether the named contacts are actually reachable, whether the escalation protocol produces a decision within the required timeframe, and whether the decision-making authority is understood by the people who need to act on it reveal the gaps before an incident does. Most tabletop exercises assume that the named contacts are reachable. The incidents that produce decision gaps often start with the named contacts being unreachable.
What Boards Should Be Asking About This
If the incident that requires an immediate decision affecting business operations occurs tonight at midnight, who receives the first call, what is their backup if they are unreachable, and what is the maximum time before a decision is made? Every board that governs an organization with material cyber risk should know the answer to this question. Most do not, because the governance reporting they receive addresses risk management processes rather than operational accountability architecture.
The board that has approved an incident response plan without testing whether that plan produces accountable decisions under realistic conditions has approved a document. It has not assured itself that the organization can respond effectively to a significant incident.
The Practical Fix
The fix is not complicated. It is administratively unglamorous work that most organizations deprioritize because it requires coordinating across functions, maintaining contact information as personnel changes occur, and running exercises that deliberately test failure modes rather than confirming that the plan works under favorable conditions.
Identify by name, not by title, who authorizes each category of incident decision. Build a backup chain of at least three people for each decision category. Test reachability quarterly — not in a scheduled exercise where participants know they will be called, but through unannounced contact attempts that test whether the on-call structure actually functions. Document the results. Fix the gaps before the incident does it for you.
Distributed risk ownership is good governance design. It requires a companion design for who acts when the risk becomes real.
Name the person. Test the number. Make sure they answer. The incident does not care about the ownership model in the risk register.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.