Should resilience planning focus more on recovery or on containment in critical infrastructure?

Why containment belongs before recovery in critical infrastructure

In critical infrastructure, recovery is important but it is rarely the first decision. The immediate objective is to keep the service operating safely, contain the attacker’s reach, and prevent a local compromise from becoming a sector-wide outage. That means limiting trust, isolating affected segments, and preserving minimum viable operations while response actions unfold.

Containment matters because a “rebuild first” mindset can create a second failure: you may lose the very visibility, control, and operator access needed to sustain essential service delivery. The safer pattern is to slow the spread, keep core functions under local control, and defer full restoration until you understand what was touched and what must be rebuilt.

In practice, that often means using incident response discipline to separate emergency service continuity from later eradication and restoration work. NHIMG’s Incident Response Guide is useful here because it frames containment, incident severity, and recovery as distinct phases rather than a single rushed reset.

What resilience planning should protect first

Resilience planning should start with the functions that cannot stop without creating public harm, safety issues, or cascading operational loss. For critical infrastructure, that usually means identifying the minimum control set needed to keep power, fuel, water, transport, or communications flowing while the compromised parts are quarantined. The goal is not perfect normality, it is controlled degradation.

This is why business continuity and disaster recovery are not the same as containment. Recovery restores systems after the environment is stable enough to trust. Containment preserves enough of the environment to keep operating before that trust is rebuilt. NHIMG’s Business Continuity and Disaster Recovery Guide is relevant because it distinguishes recovery time, recovery point, and continuity decisions that depend on service criticality.

For infrastructure operators, the practical question is whether the organization can keep delivering an acceptable level of service without opening wider attack paths. If the answer is yes, containment should dominate the initial plan. If the answer is no, the planning problem is no longer just recovery design, it is resilience architecture and safe operating mode design.

How to decide when recovery can take the lead

Recovery can take the lead only when containment has reduced the blast radius enough that restoration will not reintroduce active compromise. That usually requires confidence that attacker access has been broken, persistence has been removed, and the surviving control plane can be trusted to orchestrate restart. Until then, a fast rebuild may simply recreate the attacker’s foothold faster.

The best recovery plans in critical infrastructure assume that some systems may need to remain offline, manually controlled, or functionally degraded longer than a normal enterprise environment would tolerate. For that reason, recovery decisions should be tied to safety, service continuity, and evidence that malicious activity is no longer present, not to a generic target date for return to normal.

This is also where external authority and sector guidance matter. CISA’s Industrial Control Systems resources are useful for understanding the operational realities of segmented control environments, and CISA’s cyber threat advisories help teams stay aligned with current threat patterns against critical infrastructure.

Risk and Threat Considerations

Critical infrastructure is especially exposed to damage when containment is delayed, because attackers can convert short-lived access into operational disruption, safety impact, or broader service interruption. The main risk is not simply data loss, it is that the environment may keep functioning just long enough for the attacker to widen impact while defenders are still planning restoration.

Failure mechanism: The attacker exploits shared trust, flat connectivity, or privileged operator access to move from one compromised point into the systems that keep essential services running, which makes “restore quickly” a dangerous instinct if it happens before containment is complete.

Impact: The result can be outage propagation, operator loss of control, unsafe manual workarounds, and slower recovery because rebuilding now must also remove hidden persistence and reestablish trusted control paths.

Practitioner Guidance

What to prioritise: Protect the control plane, the operator path, and the smallest set of assets required for safe minimum service before you attempt broad restoration. If a recovery action expands access or reconnects unverified systems, it is not a recovery step yet, it is a new exposure.

Decision rule: If the service can remain viable in a degraded mode, choose containment and controlled operation first; if the service cannot remain viable, isolate only the minimum necessary components and restore in layers under explicit trust checks.

What to verify: Confirm which systems still have authoritative control, which credentials or remote paths remain valid, and whether the restart path itself is clean enough to use. If you cannot answer those three questions, recovery is premature.

Practitioner takeaway: For critical infrastructure, resilience is measured by how well you can keep essential service alive while trust is being re-established, not by how quickly you can declare systems restored.

Related resources from NHI Mgmt Group

• Why do critical infrastructure environments need containment and resilience controls beyond prevention?
• What is the difference between secure-by-design requirements and resilience planning for critical infrastructure?
• Who should own cyber resilience planning across agencies and critical infrastructure organisations?
• What happens when critical infrastructure, healthcare, or financial systems are targeted without strong resilience planning?