In the last two years, I have witnessed the same drama over and over again in companies across different sectors. The script barely varies: at 4:47 AM on a Saturday, a SOC analyst detects a ransomware payload spreading across three data center servers. The protocol says to isolate them. They flip the switch. Sixteen minutes later, the CFO calls: those servers were part of the production payment gateway. The isolation caused fourteen hours of revenue loss. On Monday, the board doesn't ask how the attacker got in, but who was authorized to make such a decision at 4:47 AM.

The Containment Paradox: Power Without Responsibility

This is the question that most incident response plans avoid answering. The plan is documented, the SOC has it open on the second monitor. But a key piece is missing: who decides that a business-critical system goes offline, and who bears the consequences? In most playbooks, that authority implicitly falls on the duty analyst, someone who is neither responsible for the affected business process nor can see the full impact of their action. This asymmetry between technical authority and operational responsibility is what we call the containment paradox.

NIST SP 800-61 Revision 3, finalized in April 2025, restructures the incident response model around the NIST Cybersecurity Framework 2.0, shifting the focus from tactical execution to strategic alignment with risk management. This shift recognizes that incident response is not just a SOC function, but an organizational risk management activity where the business owner must be a named participant. Cyber resilience as a business compass is key to understanding this change.

The "Do Not Touch" Register: How to Protect the Crown Jewels

Most security programs maintain a "crown jewels" register: systems whose loss would be existential. But that list has a second equally important function: it is the inventory of systems that the SOC must not touch without confirmation from a business owner. We call this the non-intervention register. It is not a new database, but the same list with an additional column: for each asset, what containment measures are pre-authorized and which require operational veto.

RACI for Containment Decisions: Assigning Responsibilities

Once the non-intervention register exists, the RACI model for protected actions becomes clear. Following the recommendations of the Institute for Security and Technology's Ransomware Task Force, containment authority rests with the operational owner, not just security.

In most companies, this RACI matrix has never been completed. The cost of that omission becomes evident when a regulator or plaintiff asks who decided to disconnect the system and with what authority. Ethical hacking and penetration testing help identify these governance gaps before an incident occurs.

The Objection: Does This Slow Down Response While Attackers Act?

In every workshop, the same resistance arises: if the SOC has to wait for confirmation, dwell time increases. But this objection is based on three misunderstandings:

• The veto applies to a very specific class of assets. Not the entire IT estate, only the most valuable assets. Containment of a compromised laptop is not vetoed.
• The veto has a limited duration. An escalation chain with fixed deadlines and a fallback action is defined. For example: 5 minutes to contact the service owner, 10 minutes to the asset owner, 15 minutes to the duty executive, who applies a pre-agreed safe-state contingency plan.
• The veto applies to actions, not detections. The SOC retains full authority to detect, enrich, preserve evidence, and monitor. What is vetoed is the set of actions that would cause an unplanned disruption of a critical service.

Three Steps to Implement the Non-Intervention Register

No new software or extra budget is needed. Just four hours in a room with the right people and the willingness to put in writing decisions that were previously implicit.

1. Create the register. Meet with business asset owners and identify systems whose unplanned disruption would be more damaging than the worst plausible cyber incident. The list is shorter than CISOs expect. The conversation is the real outcome; the table is the document.
2. Incorporate the measure into the SOC playbook. Before any containment action against a registered asset, insert a checkpoint: confirmation from a designated business function, escalation chain, maximum deadline, and safe-state contingency plan.
3. Fill in the RACI matrix. For containment of registered assets: business owner as Responsible, SOC as Accountable, CISO as Consulted, executive management as Informed. Filling in this column is the prerequisite to be able to answer, after the incident, who decided what and on what basis.

For efficient management of these processes, tools like NEXGestión allow automating the tracking and governance of these agreements. Additionally, the evolution towards low-code platforms with AI can facilitate the implementation of these decision flows.

The 4:47 AM Test

If I had to make a single diagnosis of an incident response program, it would be this: at 4:47 AM on a Saturday, with ransomware spreading, is the SOC analyst authorized to disconnect critical systems on their own? If the answer is yes, governance has not yet caught up with the cost of that decision. If no, can they contact a designated responsible person within a defined timeframe, and is there a pre-agreed contingency plan? If both answers are affirmative, the non-intervention register exists in practice. If either is negative, the gap is in governance, not technology.

The containment paradox is not resolved by faster automation or adding people after the fact. It is resolved by establishing in writing, in advance and in plain language, who is authorized to disconnect which business service and what the response is when that person cannot be reached. The document is one page. The conversation takes hours. The cost of not having it is measured in board reports, regulatory documents, and information requests.

Original source: ComputerWorld. Analysis and adaptation by ForgeNEX.