When a Cyber Incident Stops Operations, Who Has Decision Authority?

When a cyber incident stops operations, the first question is rarely technical. It is organizational: who has the authority to act?

Containment decisions, continuity trade-offs, and recovery authorizations each require a named decision-maker. In a crisis, the absence of that clarity costs time the organization cannot afford.

This brief addresses the governance structure that makes incident response executable: defined authority, documented alternates, and pre-authorized thresholds.

The decision gap most organizations carry

Most organizations have incident response plans. Fewer have resolved the authority questions those plans depend on. A plan that says "escalate to leadership" without naming who, under what conditions, and with what pre-authorization is a plan that will stall at the moment it is needed most.

The gap is not a technology problem. It is a governance problem. Technology teams can isolate a system. They need organizational authority to isolate one that supports patient care, financial transactions, or regulated operations. That authority must be established before the incident, not negotiated during it.

NIST SP 800-61r3 frames incident response as a coordinated organizational capability, not a technical function. The coordination it describes requires authority that is defined, communicated, and tested in advance. ^[1]

Three decisions that require pre-defined authority

Every cyber incident involves three categories of decision that cannot wait for a committee to convene.

1. Containment

Containment decisions determine which systems are isolated, which connections are severed, and which processes are suspended. These decisions carry operational consequences. Isolating a compromised server may also interrupt a clinical workflow, a payment process, or a supply chain dependency. The authority to make that trade-off must be assigned to a named individual with a defined alternate.

2. Continued operation

Continued operation decisions determine whether a degraded system remains in service, whether manual procedures are activated, and what risk the organization accepts while recovery proceeds. These decisions require a business owner, not only a technology owner. The person who understands the operational consequence of downtime must be part of the decision, and their authority must be documented.

3. Recovery authorization

Recovery decisions determine when systems are restored, which backups are used, and whether restored data can be trusted. Restoring from a backup that may itself be compromised is a risk decision. Returning a system to service before the incident is fully understood is a risk decision. Both require named authority and a record of the decision made.

The healthcare scenario that tests the point

A ransomware event encrypts the electronic health record system at 2:00 a.m. The on-call IT team can isolate the affected servers. They cannot authorize the activation of downtime procedures across clinical departments. They cannot approve the decision to continue operating on paper records. They cannot determine when the system is safe to restore.

Each of those decisions belongs to a named executive or clinical leader. If those leaders have not been identified, briefed, and given pre-authorization thresholds, the incident response team will spend the first critical hours making calls, waiting for approvals, and managing uncertainty that governance could have resolved in advance.

The Joint Commission's emergency management standards require healthcare organizations to define command structures for emergencies. A cyber incident that disrupts clinical operations is an emergency. The authority structure must reflect that. ^[2]

Test the point where containment affects safety. If the answer to "who decides?" is unclear, the governance work is not finished.

What the authority structure requires

Defining decision authority is not a one-time documentation exercise. It is an operational commitment that must be maintained, tested, and updated as the organization changes.

A functional authority structure includes:

• 1Named decision-makers for each category of incident decision, with documented alternates.
• 2Pre-authorized thresholds that define when each authority can act without further escalation.
• 3A communication chain that ensures decision-makers can be reached and briefed within a defined timeframe.
• 4A record of each decision made during the incident, including who authorized it, when, and on what basis.
• 5A post-incident review that assesses whether the authority structure performed as intended.

HHS guidance on cybersecurity for healthcare organizations emphasizes that response capability depends on pre-established roles and responsibilities, not improvised coordination. ^[3]

Illustrative decision authority framework

The following table illustrates the structure of a decision authority framework. Organizations should adapt it to their governance model, operational context, and regulatory requirements.

What the record must show

Decision authority is not only an operational requirement. It is an evidentiary one. Regulators, insurers, and boards will ask who authorized each significant action during an incident, when that authorization was given, and what information the decision-maker had at the time.

An organization that cannot answer those questions has a governance gap that will be visible in every post-incident review, regulatory inquiry, and insurance assessment that follows.

The record does not need to be elaborate. It needs to be contemporaneous, attributed, and preserved. A decision log that captures the decision made, the authority who made it, the time, and the basis for the decision is sufficient. The absence of that log is not.

Organizations subject to HIPAA should note that the Security Rule's administrative safeguard requirements include documented procedures for responding to security incidents. Documentation of decision authority is part of that requirement. ^[3]

Continue the Exploration

The governance questions in this brief connect directly to the operational frameworks in Cyber Incident Leadership & Crisis Management (Volume 13), The vCSO Cybersecurity Operations Manual™ (Volume 2), and Healthcare Security Toolkit (Volume 5) from The vCSO Series™.