Skip to content
Skip to main content
First Response & Preservation Operational Explainer

When should network isolation be considered?

Consider network isolation when continued connectivity creates a credible risk of ongoing harm, evidence destruction, data loss or wider compromise. The decision should address a defined threat rather than follow automatically from any suspicious alert.

Isolation has both benefits and costs

Disconnecting a route can interrupt remote control, exfiltration, encryption or lateral movement. It can also terminate useful sessions, stop central logging, disrupt authentication or safety systems and remove visibility of the activity being investigated. Isolation does not necessarily revoke cloud sessions, disable compromised credentials or close alternative connections.

Define the observed risk first: what is happening, which systems are affected and what is likely to happen if connectivity remains. Record alerts, active sessions, current connections, services and time before intervention where the delay is tolerable.

Choose the smallest effective boundary

The proportionate measure may be one account, device, interface, service or network segment rather than an entire site. Map dependencies such as logging, cameras, communications, cloud access and critical operations, and obtain network or incident-response advice for complex environments.

Record the authority, exact method, time and consequences of isolation, including what remained connected and how success will be checked. If serious harm requires immediate action, document why waiting was unreasonable and what evidence could not first be preserved.

Key takeaway

Isolate against a specific active risk, using the narrowest effective boundary and documenting the evidence, dependencies and resulting changes rather than assuming disconnection resolves the incident.

Reference: FRP-145First Response & Preservation