The worst time to find out who can isolate a server is while the analyst is waiting for an answer.

Most MDR onboarding focuses on coverage: which log sources are connected, which endpoints have agents, which detections are tuned. But the question that decides how an incident actually goes is simpler, and it is often left for later. Who is allowed to do what, and when?

When that is not agreed in advance, it gets negotiated during the incident. The customer contact is asleep, traveling, or unsure they have the authority either. Minutes pass. Evidence ages. The attacker does not wait for a call back.

This article follows one fictional after-hours alert from analyst triage to the customer's decision-maker, and shows where the authority line needs to be drawn before the first alert fires.

1:47 a.m.: The Alert

A regional manufacturer with a small IT team uses an MDR provider for after-hours monitoring. At 1:47 a.m. on a Saturday, a detection fires. A service account on a file server is running an unfamiliar remote administration tool and connecting to several workstations in quick succession. One of those workstations sits on the engineering network and can reach the plant historian.

What the Analyst Knows, and What Still Needs Validation

Within minutes, some facts are clear. The service account does not normally log in interactively. The tool is not on the customer's approved software list. The connection pattern looks like lateral movement, not routine maintenance.

Still unknown: is this a vendor job someone forgot to mention? Has anything been encrypted or copied out? Did the activity reach the engineering workstation, or only attempt to?

Good triage keeps those two lists separate. The customer does not need a guess dressed up as a conclusion. They need to hear what is confirmed, what is suspected, and what the analyst recommends while validation continues.

The call trigger should be written down in advance, not left to an analyst's judgment. For example: confirmed or strongly suspected lateral movement on any system with a path to operations means a phone call, not a ticket.

Related Read: Beyond Alerts: Integrating Threat Intelligence for Smarter, Faster MDR Operations

The Authority Line

Most contracts describe this vaguely, and most customers never test it. Instead, you should sort response actions into three groups.

What the provider can do without asking. Only actions the customer has explicitly authorized in advance, in writing, as low-risk and reversible. Examples include isolating a standard user workstation, disabling a compromised user account, or blocking a known-malicious domain. List them specifically, by asset type. Check each one against operating dependencies before you authorize it. A workstation that looks standard may run an HMI client, a historian connection, or a production report someone relies on.

What needs customer approval. Actions with business impact, such as isolating a server, disabling a service account that production depends on, blocking traffic between network segments, or resetting privileged credentials across the domain. The provider recommends. The customer decides.

What the provider does not touch. Operational systems, safety systems, and plant controls. For those, the provider advises and operations acts.

Without clear authority, a provider can only recommend and wait. A provider with unlimited authority is a risk of its own. The line has to be drawn on purpose.

In our example, the service account runs the nightly backup job. Disabling it may limit the attacker's use of that credential, but it does not prove the foothold is gone. The tool, other accounts, and any persistence on the affected hosts still need to be investigated. It also stops tonight's backups. That is a customer decision.

Related Read: AI's Promise in Cyber vs. Reality: Why MDR Remains Essential

When the First Contact Does Not Answer

The analyst calls the primary contact. Voicemail. This is where many escalation plans fall apart.

The plan needs a named sequence with timing: primary contact, then secondary, then an executive with authority to approve containment, each with a time limit before moving on. It also needs a default. If no one with authority answers within the agreed window, what does the provider do? Some customers pre-approve a broader set of actions for exactly this case. Others prefer to wait. Either can be reasonable. But please, don't debate this answer at 2 a.m.

Furthermore, contact lists go stale. A list reviewed at onboarding and never again is a list that will fail you eventually.

Preserve Evidence Before Cleaning Up

Containment and evidence preservation pull in different directions. The instinct is to reboot, reimage, and restore. That can erase what investigators need to understand, including how the attacker got in and what they touched.

Agree in advance on what gets captured before any action that destroys system state: volatile data from affected systems where practical, the relevant logs, and a record of every action taken, by whom, and when. If cyber insurance or outside counsel will be involved, know their notification requirements before an incident, not during one.

One rule overrides the rest: evidence collection should never delay urgent action to protect people or the process. If a step is needed to keep people safe or the plant stable, take it first, then record what was done and when.

When Operations Joins the Decision

Once there is any sign the activity reached, or could reach, the engineering workstation, this is no longer only an IT decision. Isolating a workstation that talks to the historian may affect plant visibility. Cutting a network segment could interrupt production reporting or remote support.

Operations needs a defined seat in the escalation path, usually a plant manager or operations lead who can say what a containment action means on the floor. Their job is not to slow things down. It is to make sure the fix does not cause an unintended next incident.

An Example Authority Matrix

One page brings clarity to most scenarios. The matrix below is an example to adapt, not a standard to adopt as written. Any action a provider takes without calling first needs explicit customer authorization in your agreement, and every row should be checked against operating dependencies before sign-off. It's important to set your own time windows and confirm every row against your contract.

Take the above matrix for a 30-minute dry run spin. Before go-live, get the provider's analyst lead, your IT contacts, and an operations lead on a call. Read the 1:47 a.m. scenario aloud, with the primary contact unavailable, and walk each decision against the matrix. Note every point where someone hesitates, asks "who approves that?", or finds a wrong phone number. Those are gaps you can close this week.

30-Day 'Do This Now' Checklist

1. Pull your MDR agreement and list, in plain language, which actions the provider can take without calling you.
2. Build the authority matrix and get sign-off from IT, operations, and an executive.
3. Verify every name and number on the escalation list. Call them.
4. Run the dry run above, then repeat it at every quarterly review or major staffing change.

Decide Once, Calmly

The best time to decide who can isolate a server is in a calm, focused state. The worst time is 1:47 a.m. with an analyst on hold. Draw the authority line during onboarding, test it, and revisit it when people change. The provider knows what it can do. The customer knows who will answer. And the next after-hours alert becomes a procedure, not a negotiation.

Find the content useful? Subscribe to The Catch, our exclusive weekly LinkedIn newsletter focused on real-life experiences doing cyber right in the most highly regulated industries.