Verizon’s 2026 DBIR links ransomware to 48% of breaches. Unclear authority to take systems offline exposes response plans; 3 NIST-aligned fixes close the gap.
I have sat in on a version of the same incident post-mortem in three sectors over the past two years. The script does not vary much. At 4:47 a.m. on a Saturday, an on-duty SOC analyst sees a ransomware payload spreading across three servers in the data center. The playbook says isolate. They hit the switch. Sixteen minutes later the CFO is on the phone: Those three servers were the production payment gateway. The malware would likely have reached a dozen more endpoints. The isolation took down revenue for fourteen hours. The Monday morning question from the board is not how the attacker got in. It is who, in the organization, was authorized to make a decision of this commercial magnitude at 4:47 in the morning.
This is the question most incident response programs avoid putting in writing. The plan is documented. The SOC has it open on the second monitor. What is missing is the answer to a single question: Tho decides that a business-critical system goes offline and who carries the operational and financial consequences of that decision? In most playbooks I have reviewed, that authority is not assigned. It sits implicitly with whichever SOC analyst is on shift — typically someone who neither owns the affected business process nor can fully see the downstream consequences of the action they are about to take.
This piece is about the gap between technical incident response and operational accountability. It introduces the containment paradox, the no-touch register as a governance instrument, a RACI structure for containment decisions and the answer to the most common objection — that a veto right will simply slow you down while attackers move.
Why “isolate first” stopped being the safe default
The classical incident response doctrine comes out of enterprise IT. It carries a reflex that used to be safely correct: When in doubt, isolate. A suspicious endpoint comes off the network. A compromised server is taken down. A flagged account is disabled. Fast action reduces dwell time, and reduced dwell time reduces damage. That logic is the spine of every SOAR default configuration and most IR runbooks.
The doctrine breaks once isolation itself becomes the loss event. A disconnected workstation costs a knowledge worker a productive hour. A disconnected payment gateway, ERP backbone, identity provider, manufacturing line or trading platform costs revenue, contract penalties, regulatory exposure and trust — sometimes within minutes. The containment measure becomes the damage. It is no longer mitigation; it is escalation by another route. Verizon’s 2026 Data Breach Investigations Report, drawing on more than 31,000 incidents across 145 countries, finds ransomware now present in 48 percent of all breaches — but also that 69 percent of victims chose not to pay and the median ransom dropped to $139,875. Read against incident-response practice, those numbers say two things: The trigger event is more common than ever, and the decisions that follow it carry more commercial weight than ever.
Colonial Pipeline in May 2021 is the case study every CISO already knows but few have internalized correctly. The DarkSide ransomware was on the corporate billing system, not on the pipeline control network. Colonial shut down the pipeline anyway, because they could not guarantee the ransomware would stay on the IT side. The outage lasted six days, hit 17 states plus the District of Columbia and triggered the largest fuel supply crisis on the US East Coast in decades. The intrusion compromised a network. The response disabled a region. JBS followed the same pattern weeks later. A major US consumer goods manufacturer pursued a vendor lawsuit in 2023 arguing that the contractor had extended recovery time and was liable for the resulting downtime. Recovery duration is now an attributable damage figure in litigation. That shift was unthinkable a few years ago.
The accountability and authority asymmetry
In most enterprises, the executive responsible for the availability of a business service — the head of payments, the head of trading, the plant manager, the head of clinical systems — does not have the authority to prevent that service from being taken offline during an incident. The SOC has the authority. The business owner has the accountability. These are different people, often in different reporting lines, and the asymmetry only becomes visible when something is actually shut down. NIST’s SP 800-61 Revision 3, finalized in April 2025 by Amy Nelson, Shanée Rekhi, Murugiah Souppaya and Karen Scarfone, restructures the entire incident response model around the NIST Cybersecurity Framework 2.0 — moving the framing explicitly from “tactical execution” to “strategic alignment with broader risk management.” That shift is exactly the gap I am describing. The new doctrine treats incident response not as a SOC function but as an organizational risk-management activity in which the business owner is a named participant.
This is not a problem that goes away with better SOC training. It is a governance problem. The asymmetry exists because the IR playbook was written by the security function, for the security function and never went through the legal and operational review that would have surfaced it. A SOC analyst at 4 a.m. on Saturday is not the right person to decide whether the company should lose fourteen hours of payments to prevent four hours of attacker dwell time. That decision belongs to a named operational owner — and if that owner cannot be reached in time, the playbook should specify a pre-agreed safe-state action, not let the analyst improvise.
The no-touch register: A second reading of your crown jewels list
Most security programs already maintain a crown jewels register — the inventory of systems whose loss would be existential. In its standard reading, the register drives investment, patch cadence, backup frequency and monitoring depth. That reading is right but incomplete. The same list has a second function that is at least as important: It is the inventory of systems your SOC must not touch without confirmation from a named business owner.
I call this second function the no-touch register. It is not a separate database. It is the same crown jewels list with one additional column: For each asset, which containment actions are pre-authorized for the SOC to execute, and which actions require operational confirmation. The split looks something like this:
| Asset class | SOC pre-authorized actions | Veto-protected actions |
| Payment gateway | Detect, analyze, preserve evidence, monitor, restrict outbound traffic. | Isolate from network, take service offline, force credential reset of operational accounts. |
| Identity provider (IdP) | Detect, enrich logs, alert on session anomalies, raise additional MFA. | Disable federated trust, mass-revoke active sessions, force tenant-wide logout. |
| Manufacturing control system | Detect, passively monitor, escalate. | Any action that could interrupt continuous process or trigger safety response. |
| Clinical EHR backend | Detect, restrict admin access, enhance logging. | Take system offline, block clinician access, suspend data feeds to bedside devices. |
| Standard endpoint (laptop, dev workstation) | Full containment — isolate, image, re-provision. | None. |
The point of the table is not the rows. It is the discipline of filling it out. In every engagement where I have run this exercise, the meeting itself produces the value: Business owners hear, often for the first time, that the IR playbook authorizes the SOC to take their service offline; the SOC hears, often for the first time, what the downstream cost of that action actually is. Most of the no-touch register is consensus once the conversation has happened. The artifact then makes that consensus enforceable.
RACI for containment decisions
Once a no-touch register exists, the RACI for veto-protected actions becomes straightforward. The model below aligns with the four-role logic that the Institute for Security and Technology’s Ransomware Task Force — a coalition of more than 60 organizations across government, industry and law enforcement — has repeatedly recommended in its progress reports: Containment authority belongs to the operational owner, not the security function alone.
| Role | RACI | Reason |
| Business asset owner | Accountable | Holds both the availability mandate and the downstream commercial, safety or regulatory consequences of taking the service offline. Delegates operational confirmation to a named on-call lead but retains strategic responsibility. |
| Security Operations Center | Responsible | Executes the containment measure once confirmation arrives or the defined escalation window elapses and the pre-agreed safe-state fallback applies. |
| CISO / Head of Security | Consulted | Sets the methodological guardrails but is not the single-incident decision maker. Escalates to Accountable for enterprise-wide coordination on systemic incidents. |
| Executive leadership / board | Informed | Receives a structured notification, not a real-time consultation. The Informed status is what makes post-incident reconstruction defensible in audit, regulatory review and litigation. |
In most enterprises this RACI line has never been filled in. The cost of that omission is invisible in normal operations and becomes existential during incident reconstruction — when an internal lessons-learned, a regulator, or a plaintiff asks who decided to take the system offline, on what basis and with what authority.
The objection: Does this slow you down while attackers move?
Every workshop on this topic produces the same pushback. If the SOC has to wait for a business owner’s confirmation, dwell time goes up, damage probability goes up and the veto right has effectively disarmed the response. Stated generally, this objection is correct. Stated about the no-touch register, it rests on three misunderstandings.
The veto applies to a narrow asset class. The register covers the crown jewels — typically a small number per business unit, not the entire estate. Containing a compromised laptop is not veto-protected. Containing the identity provider that laptop authenticates against is. The veto-protected set is the intersection of assets whose loss is existential and actions that produce exactly that loss.
The veto is time-bounded. A serviceable playbook defines the escalation chain with hard windows and a deliberate fallback action if the chain runs out. The structure looks like this:
| Step | Escalation role | Max wait | Action if no response |
| 1 | On-call service owner (primary contact for the asset) | 5 minutes | Escalate to business asset owner. |
| 2 | Business asset owner | 10 minutes | Escalate to executive on call. |
| 3 | Executive on call (head of service line or COO delegate) | 15 minutes | Apply pre-agreed safe-state fallback — not unilateral isolation. |
The pre-agreed safe-state fallback is the design point most playbooks skip. It is not the original containment action executed unilaterally after the window closes. It is a separate, deliberately-designed action that brings the asset to a manageable state without forcing the SOC to improvise under pressure — degraded mode, read-only access, traffic restriction or whatever the business owner has pre-authorized in writing for exactly this case.
The veto applies to actions, not detections. The SOC retains full authority to detect, enrich, preserve evidence, intensify monitoring and isolate every system not on the no-touch list. What is veto-protected is the small class of actions that would induce an unplanned outage of a continuous business service. Modern SOAR platforms handle this branching natively. CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, published under Executive Order 14028 and intended explicitly for private-sector adaptation, model exactly this kind of branched decision tree. The reason most enterprise implementations do not is not technical. The IR governance never asked them to.
Three steps to implement, and one meeting that produces most of the value
Implementing a no-touch register requires no new software, no additional headcount and no separate budget line. It requires four hours in a room with the right people and a willingness to write down decisions that were previously implicit.
- Build the register. Sit down with the business asset owners and identify the systems whose unplanned outage would be more damaging than the worst plausible cyber incident on those same systems. The list is shorter than most CISOs expect. The conversation is the actual outcome; the table is the artifact.
- Embed the security stop in the playbook that the SOC actually runs — not the playbook in the audit folder. Before any containment action against a register asset, insert a checkpoint: Confirmation by a named business role, defined escalation chain, defined maximum window, defined safe-state fallback if the window expires.
- Fill in the RACI. For containment of register assets: Business owner Accountable, SOC Responsible, CISO Consulted, executive leadership Informed. In most organizations this column has never been completed. Completing it is the precondition for being able to answer, after the incident, who decided what on which basis.
The 4:47 a.m. test
If I run only one diagnostic on a current IR program, this is the one. I ask: At 4:47 a.m. on a Saturday, with a credible ransomware payload spreading on three crown-jewel systems, is the SOC analyst authorized to take those systems offline on their own judgment? If yes, the governance has not yet caught up to the cost of that decision. If no, can the analyst reach a named accountable owner within a defined window, and is there a pre-agreed safe-state fallback if that window expires? If both answers are yes, the no-touch register exists in practice, even if it has not been named. If either answer is no, the gap is governance, not technology.
The containment paradox is not solved by faster automation or by adding humans to the loop after the fact. It is solved by writing down, in advance and in plain language, who is authorized to take which business service offline — and what the response is when that person cannot be reached. The artifact is one page. The conversation that produces it is several hours. The cost of not having it is measured in the language of board reports, regulatory filings and discovery requests.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?