Should operational resilience focus on recovery after an attack or continuity during one?

Why resilience is a live-service problem, not just a recovery problem

operational resilience is earned while the attack is still unfolding. Recovery matters after containment, but the stronger test is whether the organisation can keep delivering the critical service at an acceptable level while parts of the environment are isolated, slowed, or disconnected. The practical question is not whether you can rebuild later, but whether the mission survives the period when rebuilding is impossible.

That framing changes how teams think about downtime. A recovery-only model often assumes the safest response is to stop everything, cleanly restore, and then resume. In real incidents, that can destroy the very service you are trying to protect. Resilience depends on preserving the minimum viable business function, even if that means degraded features, manual workarounds, tighter network boundaries, or temporary loss of nonessential dependencies.

For a useful working definition, Cyber Resilience Guide treats resilience as an engineering and operating posture, not a post-incident activity. That is the right lens for continuity during an attack, because it forces teams to design for containment without service collapse.

What continuity during an attack actually requires

Continuity during an attack depends on isolation, degradation, and dependency management. If a suspicious segment must be quarantined, the organisation should already know which services can keep running, which ones can move to a reduced mode, and which ones must fail closed. That means the continuity plan is built around service tiers and impact tolerance, not around a single global restore event.

Three capabilities matter most. First, critical services need graceful degradation, so a partial outage does not become a total outage. Second, dependencies must be mapped well enough to understand what breaks when a provider, platform, or control plane is cut off. Third, teams need tested manual or alternate operating modes for the narrow window when automation, connectivity, or trusted integrations are no longer safe.

This is also where resilience testing becomes meaningful. A tabletop that only walks through restoration misses the harder question of whether the organisation can keep functioning when containment interrupts normal access paths. The test should confirm that isolation does not destroy the service dependencies on which business continuity depends.

For teams building that operating model, the Business Continuity and Disaster Recovery Guide is useful because it ties business impact analysis, RTO, RPO, and continuity testing to the real problem of operating through disruption rather than only restoring after it.

Why recovery still matters, but only after survivability is assured

Recovery is the second half of resilience, not the first. Once the organisation has preserved essential service delivery and contained the attack, it can focus on restoration, eradication, and full return to normal architecture. But if recovery is treated as the primary goal from the start, responders can make brittle choices, such as overfitting to rebuild speed, ignoring residual compromise, or pulling dependencies back online before trust has been re-established.

That sequencing matters because the fastest rebuild is not always the safest one. A system can be restored quickly and still remain operationally unsafe if the attack path is still open, if compromised credentials still exist, or if the restored environment immediately reconnects to the same dependencies that were abused. Continuity first gives responders room to make better recovery decisions.

In regulated environments, especially financial services, this distinction is explicit. The EU Digital Operational Resilience Act (DORA) is focused on keeping ICT services resilient under disruption, which is why continuity, testing, and incident handling are central rather than optional.

Risk and Threat Considerations

When organisations optimise for recovery only, they create a fragile response model: containment can force a full shutdown, and the shutdown itself becomes the outage. Attackers also benefit when defenders cannot keep a critical service operating in degraded mode, because the organisation is pushed into a larger business interruption than the original compromise may have required.

Failure mechanism: Critical services depend on shared connectivity, shared identity infrastructure, or shared control planes that cannot be safely isolated without collapsing normal operations. If those dependencies are not mapped and tested, containment actions can trigger mission failure even when the attacker has not fully destroyed the environment.

Impact: The organisation loses both availability and decision space. It may be unable to maintain customer service, regulatory operations, or internal control functions while it investigates, and the resulting pressure can lead to unsafe restoration choices or premature reconnection of compromised components.

Practitioner Guidance

What to prioritise: Start with the services whose interruption would create the largest business or safety consequence, then define what “still usable” means for each one under isolation, degraded connectivity, and partial loss of trust. The point is to set survivability thresholds before an incident forces the decision for you.

What to verify: Test whether the service can continue when one critical dependency is removed, when a key network segment is quarantined, and when operators must work with reduced automation. If the answer requires “full restore first,” the resilience design is too recovery-centric.

Practitioner takeaway: The best resilience posture assumes the attack is already happening, and designs the service so it can keep operating long enough to survive containment, not merely to be rebuilt afterward.

Related resources from NHI Mgmt Group

• How should security teams design for operational continuity during an attack?
• What is the difference between attack surface management and NHI governance?
• When do NHI access reviews create more value than a one-time cleanup?
• When does NHI compliance become an operational security issue?