InfoSec Made Easy
OT Security Leadership | NCSC Guidance Series
The plan you hope you never need — and why having it ready is non-negotiable in OT security
Every other principle in this series has focused on preventing compromise, detecting threats, and limiting the spread of attacks that do occur. Principle 8 addresses the scenario that all of those controls are designed to avoid: a confirmed compromise serious enough that the OT environment needs to be isolated from external influences to prevent further damage, contain the threat, or allow secure recovery. It is the last resort — the plan you execute when other defenses have not been sufficient, or when the threat is serious enough that isolation is the only prudent response.
Principle 8 of the NCSC's Secure Connectivity Principles for Operational Technology is about ensuring that when that moment comes, your organization has a plan, has tested that plan, knows it will work without causing additional operational harm, and can execute it quickly enough to be effective. Organizations that wait until a crisis to think about isolation often discover that isolating an OT environment is far more complex than they anticipated — with dependencies on external systems that prevent isolation, contractual obligations with third parties that must be managed, and operational consequences that have not been fully considered.
For security leaders, Principle 8 is the culmination of the security program described in the preceding seven principles. An organization that has implemented all eight principles has built connectivity that is risk-assessed, exposure-limited, standardized, protocol-secured, boundary-hardened, compartmentalized, and monitored. When that organization needs to isolate, it knows exactly what connections to sever, has the controls to do so selectively if possible, and can maintain some operational and monitoring capabilities even while isolated. That is a very different position from an organization that has not implemented these principles — and the difference matters enormously when the pressure of an active incident is driving every decision.
When Isolation Becomes Necessary
The NCSC guidance identifies the circumstances that might require OT isolation: increased threat levels, confirmed compromises in connected systems, or active intrusion into the OT environment itself. The common thread is that continued connectivity would either enable an ongoing attack to cause more damage, provide an attacker with continued access to the environment, or allow compromise in a connected system to spread to the OT network.
The decision to isolate is rarely simple. Isolation has operational consequences — the connections being severed may carry data or control signals that OT processes depend on. In critical infrastructure, those operational consequences can cascade: a water treatment facility that loses connectivity to remote pump stations cannot verify that those stations are operating safely; an electrical substation that loses connectivity to the control center cannot receive operational instructions. The isolation decision must balance the security risk of remaining connected against the operational risk of disconnecting — and that balance may shift depending on whether the threat is a confirmed active compromise or a precautionary response to elevated threat intelligence.
This complexity is why the isolation plan must be developed and tested before a crisis, not improvised during one. When an incident is actively unfolding, the combination of operational pressure, incomplete information, and the urgency of the situation creates exactly the conditions where poor decisions are made. A well-tested isolation plan that has been developed with both security and operations input, that has considered the operational consequences of isolation, and that has been rehearsed through regular testing is the only reliable defense against crisis-driven mistakes.
💡 Pro Tip: The isolation plan should be integrated with your incident response playbooks from the start, not treated as a separate document that gets consulted separately during an incident. The incident response playbook for high-severity OT security events should include explicit decision criteria for when to invoke the isolation plan, who has the authority to authorize isolation, and what operational notifications must be made before isolation occurs. Integrating these documents ensures that isolation decisions are made within the established incident response process, with the right people involved and the right information considered — rather than as an improvised reaction to an unfolding crisis.
Three Isolation Strategies: Matching Response to Architecture
One of the most practically useful elements of the NCSC guidance on Principle 8 is its description of three distinct isolation strategies. The appropriate strategy depends on the architecture of the OT environment — specifically, the security controls and segmentation that have been implemented. This is a direct connection back to the preceding principles: the investment in architecture described in Principles 2 through 6 directly determines which isolation strategies are available to you when an incident occurs.
Site isolation is the strategy for environments built on flat networks with limited security controls. In this scenario, the options are primarily confined to removing all external network connections — either physically disconnecting network links or modifying network rules at a hardened, current boundary device to block all external traffic. This is the most disruptive form of isolation, because it cannot distinguish between connections that are part of the threat and connections that are not. Everything external is cut off simultaneously. This blunt instrument may be the only available option in an environment with limited architecture, but it comes with significant operational consequences — including the loss of vendor support, remote monitoring, and business system integration for the duration of the isolation.
Application and service-specific isolation is available to organizations that have implemented the secure connectivity architecture described in the preceding principles. With well-defined, centralized connectivity and a just-in-time access model, it becomes possible to isolate specific affected services and network routes while maintaining others. If a third-party vendor whose remote access has been compromised is identified, their access can be revoked while all other vendor connections remain active. If a specific service integration is implicated in a compromise, that connection can be severed without affecting other integrations. This selective isolation minimizes operational impact while still containing the threat — and it is only possible because the connectivity architecture provides the granularity needed to make targeted isolation decisions.
Site isolation with hardware-enforced trusted communications represents the most sophisticated form of isolation, available to organizations that have implemented hardware-enforced data flow controls such as data diodes. In this strategy, the hardware-enforced connections — which by their physical nature cannot be used to inject threats into the OT environment — can safely remain operational during isolation, while software-configured connections are severed. An organization using data diodes to forward telemetry and logging data from the OT environment to the security monitoring platform can maintain that visibility even while isolating all other external connections. This allows the organization to continue monitoring the OT environment during the incident response — a capability that significantly improves the quality and speed of incident investigation and recovery decision-making.
📋 Example: Isolation Strategy Selection in Practice
Two similar industrial facilities discover on the same day that a shared SCADA software vendor has been compromised, and that the attacker may have used the vendor's remote access capability to access customer OT environments. Facility A has implemented centralized vendor access through a just-in-time access model with specific per-vendor access scopes. Its response: revoke the affected vendor's access credentials immediately, maintain all other operations and vendor connections, preserve full monitoring visibility, and initiate forensic review of the vendor's session logs from the last 90 days. Facility B has vendor access implemented through a standing VPN tunnel that terminates in the OT network and provides broad access to the environment. Its response: disconnect the VPN, which also disconnects monitoring telemetry, remote historian access, and two other vendor support connections that were not implicated. Operations continue but with significantly degraded monitoring visibility and a two-day delay in restoring unaffected vendor access. The difference in response capability is a direct consequence of the difference in connectivity architecture — Facility A's investment in Principles 2 and 3 determined which isolation strategy was available when Principle 8 was needed.
Planning for Large-Scale Isolation
For organizations managing multiple sites — utilities with distributed infrastructure, manufacturers with multiple production facilities, transportation operators with dispersed assets — isolation planning has an additional dimension that goes beyond individual site response. The NCSC guidance calls for comprehensive strategies that address large-scale isolation scenarios, including situations where a common infrastructure component is compromised and could enable lateral movement across all sites simultaneously.
Large-scale isolation planning requires identifying critical data flows that must remain operational across the organization, even during a widespread security event. Some data flows — safety monitoring signals, emergency communications, national-level reporting — may have dependencies that mean they cannot be severed even during an active compromise, because losing those flows would create safety risks or national-level operational impacts that exceed the risk of maintaining the connection. Technical controls, including data diodes, can allow these critical flows to safely continue during a compromise by enforcing the unidirectionality that prevents the connection from being used as an attack path.
The guidance also emphasizes that isolation plans for multi-site organizations must be coordinated — a site-level isolation that inadvertently severs connectivity needed by another site, or that creates a national-level impact by removing a service that other organizations depend on, could cause harm that exceeds the benefit of the isolation. This coordination requirement means that isolation plans need to be developed with input from operations, engineering, and in some cases national coordination bodies, not just the security team working in isolation.
What the Isolation Plan Must Address
Beyond the three isolation strategies, the NCSC guidance identifies several specific requirements that a complete isolation plan must address. These reflect the operational and contractual complexity of modern OT environments.
Business continuity integration: The isolation plan must be linked to and part of the wider business continuity plan. Isolation is not just a security action — it is a business continuity event that affects the organization's ability to deliver its services. The business continuity plan should account for isolation scenarios, and the isolation plan should include the business continuity actions that accompany isolation: customer communications, regulatory notifications, manual procedure activation, and recovery timeline management.
Third-party and supplier contractual requirements: Isolation plans must account for the contractual arrangements with third parties and suppliers. Isolating an OT environment may change the support model for critical systems — a vendor that normally provides remote support may need to send engineers on-site instead, which requires advance notice, travel time, and potentially accommodation. Contracts should be reviewed to understand what obligations arise when remote access is revoked, and the isolation plan should include the steps needed to manage those obligations during an isolation event.
Regular testing: The isolation plan must be regularly tested to ensure it works as intended and does not have unintended consequences. Testing should be as realistic as possible — paper exercises identify logical gaps, but only operational testing reveals the practical issues that arise when isolation is actually executed. Organizations that have tested their isolation plans regularly report that testing almost always reveals gaps or unexpected consequences that could not be anticipated without operational experience of what isolation actually looks like.
Design for isolation from the start: OT systems that provide critical functions should, where possible, be designed to facilitate isolation — able to function independently of external dependencies for a meaningful period. This is an architectural requirement that needs to be considered during system design, not added as an afterthought. Systems that are fundamentally incapable of operating without external connectivity cannot be isolated without disrupting the critical functions they provide. Building isolation capability into the design of new OT systems, and progressively adding it to existing systems during lifecycle upgrades, is a long-term investment in operational resilience that pays dividends when isolation is needed.
💡 Pro Tip: Schedule an annual isolation exercise that goes beyond a tabletop. At minimum, exercise the decision-making process: bring together security, operations, legal, and executive leadership and walk through a realistic scenario where isolation is being considered. Force the group to actually make the decision — what information do they need? Who authorizes the action? What notifications must be made before, during, and after? The most common finding in these exercises is that the decision-making process is unclear and that the operational consequences of isolation are poorly understood by the security team. Both findings are valuable to discover in an exercise rather than an actual incident.
The Security Investment Equation: Architecture Enables Isolation
There is a powerful argument embedded in Principle 8 for the broader security investment described in this series. The isolation strategies available to an organization during a crisis are directly determined by the security architecture that organization has built before the crisis. A flat-networked OT environment with broad vendor access and no hardware-enforced controls has one isolation option: disconnect everything. An organization that has invested in the architecture described across all eight principles has options: selective service isolation, maintained monitoring capability, continued critical data flows, and a faster path to recovery.
This means that the investment in Principles 2 through 7 is not just about preventing incidents or detecting them earlier — it is about preserving operational capability and recovery speed when an incident does require isolation. The additional cost of deploying just-in-time access instead of standing vendor VPNs, of implementing data diodes for monitoring telemetry, of building a segmented architecture with defined zone boundaries, pays dividends not just in reduced likelihood and impact of compromise, but in reduced operational disruption and faster recovery when isolation becomes necessary.
For security leaders who struggle to make the business case for OT security investment, this framing — that security architecture determines operational resilience during crisis response — provides a powerful connection between security investment and business continuity outcomes that operational leaders and executives can understand and act on.
📋 Key Ideas: What Strong Principle 8 Implementation Looks Like
- A documented isolation plan exists, is current, and is integrated with the incident response playbook and business continuity plan.
- The plan covers all three isolation strategies — site isolation, application-specific isolation, and hardware-enforced isolation where applicable — matched to the organization's actual architecture.
- Critical data flows that must continue during isolation are identified, and technical controls (data diodes, hardware-enforced unidirectional links) are in place to allow those flows to safely remain operational.
- Contractual arrangements with third parties are documented in the isolation plan, with specific actions identified for managing those arrangements during an isolation event.
- The isolation plan is tested regularly — at minimum through tabletop exercise, and periodically through operational testing of the technical isolation mechanisms.
- For multi-site organizations, large-scale isolation scenarios are explicitly addressed, with coordination requirements and critical flow exemptions documented.
- New OT system designs explicitly consider isolation capability as a design requirement, not an afterthought.
Regulatory and Compliance Expectations
Regulators overseeing critical infrastructure organizations increasingly expect to see evidence that organizations have planned and tested their incident response capability, including isolation procedures. Frameworks such as NIS2 in Europe, the TSA Security Directives for transportation, and sector-specific standards for energy and water infrastructure all include requirements for incident response planning and cyber resilience that encompass isolation planning.
For compliance professionals, the isolation plan is also a key document in demonstrating organizational resilience to auditors and regulators. An organization that can present a tested, current isolation plan — with documented testing results, identified lessons learned, and evidence of integration with business continuity planning — is in a strong position to demonstrate that it has done the organizational work needed to respond effectively to a major cyber incident. That demonstration is increasingly what regulators want to see, in addition to the technical control evidence that has traditionally been the focus of compliance assessments.
Bringing the Eight Principles Together
As the final principle in the NCSC's framework, Principle 8 brings into focus the coherence of the full eight-principle architecture. The principles are not independent controls that can be implemented in isolation — they build on each other in a logical progression that begins with risk governance (Principle 1), reduces exposure (Principle 2), standardizes architecture (Principle 3), secures communication (Principle 4), hardens the boundary (Principle 5), limits blast radius (Principle 6), enables detection (Principle 7), and prepares for the worst-case response (Principle 8).
An organization that has implemented all eight principles has built an OT security program that is coherent, resilient, and defensible — both to adversaries who will find it significantly harder to achieve their objectives, and to regulators and auditors who will find clear evidence of mature, risk-informed security governance. The principles are designed to be goals rather than minimum requirements — aspirational standards that organizations work toward systematically, prioritizing the highest-risk gaps first, rather than treating as a compliance checklist to be achieved at the lowest possible standard and forgotten.
For security leaders, that framing is an invitation to honest assessment: where is your OT security program against each of these eight principles today? Where are the most significant gaps? Which gaps create the most risk? And what is the plan to close them, in what sequence, over what timeframe? Those questions — asked honestly and answered specifically — are the foundation of an OT security improvement program that will make a genuine difference to the safety and resilience of the systems your organization operates.
💠Final Thought
The eight NCSC principles for secure OT connectivity are not a compliance exercise. They are a framework for building OT security that genuinely protects the physical processes, the people, and the communities that depend on operational technology to function safely and reliably. Principle 8 — the isolation plan — is the clearest expression of that intent: it prepares the organization to do the hardest possible thing, under the worst possible circumstances, as effectively as possible. The organizations that invest in that preparation are the ones that will respond to major incidents without causing additional harm in the process. Start from Principle 1, build methodically through all eight, test regularly, and review honestly. That is how OT security programs that genuinely protect critical infrastructure are built — one deliberate, documented, maintained principle at a time.
This article is part of the InfoSec Made Easy series on the NCSC Secure Connectivity Principles for Operational Technology. Read the full series at www.infosecmadeeasy.com.