How should organisations prepare for isolation of critical systems during a severe attack?

Preparing to isolate a critical system without making the response worse

Isolation only works as an emergency control if it is pre-authorised, technically repeatable, and already understood by operations, security, and business owners. Organisations should decide in advance which systems can be isolated, who can trigger it, what gets disconnected first, and which essential functions must remain available after the cutover.

A useful plan separates containment from recovery. The containment step should stop lateral movement and preserve safety, while the recovery step should preserve evidence, maintain communications, and keep the minimum viable service running on an alternate path. That distinction matters because a rushed isolation can break monitoring, confuse operators, or strand teams without a safe way to coordinate.

For critical environments, isolation should be treated as a controlled operating mode, not just a last-minute shutdown. That is why Critical Infrastructure Identity Security Guide is relevant here: the decision to disconnect often depends on who has authority, which remote access paths are trusted, and how privileged access is suspended without losing control of the environment.

What the isolation plan needs to define before an attack happens

First, the organisation needs clear trigger criteria. If the criteria are vague, teams will wait too long, or isolate too early and damage operations unnecessarily. Good trigger criteria combine technical signals, such as confirmed compromise or unsafe command execution, with business thresholds, such as unacceptable propagation risk or loss of confidence in integrity.

Second, the isolation method must be specific. Network segmentation, emergency firewall rules, access revocation, and manual overrides all behave differently under pressure, so the plan should state which mechanism is used for each type of system. A production control system, for example, may need a different disconnect path from a corporate application tier or a supporting management network.

Third, the fallback operating model must be explicit. Teams need to know what still works when normal connectivity is gone, how they will communicate, and which manual safety procedures take precedence. If those procedures depend on the same network or the same administrative channel that is being isolated, they will fail at the moment they are needed most.

The biggest practical mistake is assuming that documentation alone creates resilience. A plan that has never been exercised often fails in three places at once: the people do not know their roles, the technical cutover is slower than expected, and the business discovers too late that a supposedly non-essential dependency was actually critical.

Isolation also has to account for continuity of control. If the environment contains safety-critical operations, the team may need a reduced-function mode rather than a total blackout. That is why the plan should distinguish between full disconnection, partial segmentation, and tightly constrained emergency access.

How rehearsal turns isolation into a real defensive capability

Rehearsal is what converts a written isolation plan into a usable response. Tabletop exercises help validate decision-making, but the organisation also needs technical drills that prove the disconnect actually works under real timing, logging, and access conditions. The test should include communications fallback, role handoff, and a check that manual procedures remain safe when digital controls are unavailable.

Rehearsals should also surface cross-team dependencies. Security may want to block everything, while operations may need one narrow path to preserve physical safety or evidence collection. Those trade-offs should be decided in advance so the response team is not negotiating in the middle of an active attack.

Where the environment is heavily regulated or operationally sensitive, isolation planning should be aligned with external obligations and incident handling expectations. MAS Technology Risk Management Guide is one example of how critical-system resilience is treated as a governance issue as well as a technical one, because recovery objectives, controls, and reporting expectations shape what a viable isolation plan looks like.

Prepared teams also test what happens after isolation. They verify whether logging still captures meaningful evidence, whether backups are reachable, whether a clean admin path remains available, and whether the disconnected system can be restored without reintroducing the original compromise.

Risk and Threat Considerations

Isolation reduces blast radius, but it can also expose an organisation to operational failure if the cutoff is poorly designed. The main threat is not just attacker persistence, it is losing visibility, control, or safe fallback capability at the exact moment the organisation needs them most. That is especially dangerous in critical environments where continuity and safety are tightly coupled.

Failure mechanism: Teams isolate the wrong segment, or isolate it too late, so the attacker keeps moving while defenders lose normal communications, monitoring, or administrative reach. In the worst case, emergency actions are blocked by the same dependencies that were supposed to protect the system.

Impact: The organisation may contain the compromise only partially, create avoidable downtime, or force unsafe manual workarounds. A failed isolation can also delay forensics and make it harder to prove what the attacker touched before the disconnect.

Practitioner Guidance

What to prioritise: Define the disconnect authority, the technical method, and the minimum operating state together. If those three elements are not linked, the organisation will either hesitate to isolate or isolate in a way that breaks essential functions.

What to verify: Validate that the emergency path is independent of the normal path. Confirm that communications fallback, privileged access suspension, and manual safety procedures still work when primary networks and standard tools are unavailable.

Common mistake: Treating isolation as a one-time defensive action instead of a rehearsed operating mode. The practical question is not whether the plan exists, but whether the team can execute it fast enough, safely enough, and with enough evidence preserved to recover with confidence.

Practitioner takeaway: The best isolation plans are designed for controlled degradation, not dramatic shutdown, so the organisation can stop spread while still preserving safety, coordination, and the ability to restore trust in the environment.

Related resources from NHI Mgmt Group

• How should organisations build a cyber resilience framework that keeps critical systems available during an attack?
• How should security teams build recovery procedures for identity systems so they work during an outage or attack?
• What happens when production systems and corporate IT are both exposed during a ransomware attack on a manufacturing environment?
• What happens when IoT devices are connected to the same network as critical systems without isolation?