How should large organisations adapt cyber resilience planning when legacy systems and cloud platforms must coexist?

Large organisations should plan for hybrid reality, not assume a clean cloud transition. The core controls still matter: access management, data management, resilience, and system availability. Teams need to map where legacy applications create architectural fragility, then align identity, recovery, and operational controls so the same control objective is enforced across old and new platforms.

Design for two operating models, not one migration story

Large organisations usually fail at resilience when they treat cloud adoption as a replacement program instead of an operating reality. Legacy platforms often remain tied to batch jobs, fixed network paths, long change windows, and brittle dependencies, while cloud services introduce elastic capacity, shared responsibility, and faster configuration drift. The resilience plan has to account for both models at once, with one control objective expressed differently in each environment.

This means the planning unit should be the business service, not the hosting platform. If a service spans mainframes, virtual machines, and cloud-native components, resilience assumptions need to follow the service end to end. Otherwise recovery time, backup coverage, and change tolerance will be designed per platform, but fail in production as soon as a workflow crosses the boundary between old and new systems.

Hybrid planning also changes how you assess fragility. A legacy system may be technically stable but operationally fragile because few people understand its dependencies or recovery sequence. A cloud workload may be easy to redeploy but fragile because identity, networking, or data protections are misaligned across environments. The point is to identify where the weakest link sits in the path that delivers the service, then harden that path rather than assuming one environment is inherently more resilient.

Keep access, recovery, and data controls aligned across environments

cyber resilience in a mixed estate depends on whether the same control objective can be enforced consistently, even when the implementation differs. Access management is a good example: legacy applications may rely on local accounts or embedded trust, while cloud services depend on federated access, roles, or workload permissions. The organisation should be able to answer the same question in both places, namely who can act, what they can reach, and how that access is reviewed or revoked.

Data management is just as important. If the same business data exists in a legacy database, a replicated data lake, and a cloud application, resilience planning must define which copy is authoritative, how backup and restore are tested, and which encryption, retention, and recovery rules apply. Without that clarity, recovery can restore the wrong version of the data, or restore it into an environment that cannot use it safely.

Operational controls need similar treatment. Monitoring, incident response, and restoration procedures should not assume that every platform exposes the same telemetry or supports the same automation. The practical goal is not identical tooling, but comparable control coverage, so that service restoration, integrity checks, and operator approvals work predictably across old and new platforms.

Use resilience planning to expose architectural debt before it becomes outage debt

The main resilience risk in coexistence environments is hidden dependency. Legacy systems often carry tightly coupled integrations, older authentication paths, and scheduled processes that cloud teams do not see. Cloud platforms can add new failure modes through misconfiguration, permission sprawl, or brittle integration points back to on-premise systems. That combination creates a false sense of modernisation: the front end changes, but the outage path stays inherited.

One useful test is to trace a critical service from user request to data commit and recovery point, then mark every place where the flow crosses trust boundaries, administrative domains, or recovery domains. If a single manual bridge still exists, for example a file transfer, a privileged account, or a one-off sync job, that bridge becomes a resilience dependency. At scale, those dependencies are often what turn a local failure into a broad business interruption.

Coexistence planning should also account for platform obsolescence and patch asymmetry. Legacy estates may not support the same hardening pace as cloud services, which means resilience and vulnerability management have to be planned together rather than as separate workstreams. For a current threat view of what attackers actively exploit in operational environments, see ENISA Threat Landscape and CISA Known Exploited Vulnerabilities Catalog.

Risk and Threat Considerations

Mixed legacy and cloud estates create a resilience risk because attackers and outages both exploit the seams. If identity, backup, configuration, and monitoring are not consistent across environments, a compromise or technical failure in one side can undermine recovery on the other. The highest-risk condition is usually not the weakest platform in isolation, but the unmanaged dependency between two differently governed platforms.

Failure mechanism: Shared services, stale access paths, replicated data sets, and manual handoffs create hidden coupling, so a problem in one platform blocks detection, containment, or restoration in the other.

Impact: Recovery becomes slower and less reliable, blast radius grows, and the organisation may restore service into a state that is insecure, incomplete, or out of sync with the business process.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC-01 — Cyber Supply Chain Risk Management	Hybrid resilience depends on third-party and inter-platform dependencies.
	PR.AA-05 — Identities and credentials are issued, managed, verified, revoked, and audited	Access consistency across legacy and cloud is central to hybrid resilience.
	RC.RP-01 — Recovery Plan Execution	The question is fundamentally about restoring services in a mixed estate.
Recommendation — Map shared-service dependencies and enforce recovery expectations across suppliers and platforms. Align access lifecycle controls across legacy and cloud systems. Test recovery execution for end-to-end services that span both environments.
NIST SP 800-53 Rev 5	CP-2 — Contingency Plan	Hybrid estates need a contingency plan that reflects mixed dependencies and recovery paths.
	AU-6 — Audit Record Review, Analysis, and Reporting	Cross-platform resilience depends on detecting failures and anomalies in both environments.
Recommendation — Document service-level contingency plans that include legacy and cloud dependencies. Centralise log review so legacy and cloud signals support the same recovery decisions.
ISO/IEC 27001:2022	A.5.29 — Information security during disruption	Resilience planning must preserve security during outages and recovery across environments.
	A.8.14 — Redundancy of information processing facilities	The subject concerns continuity when critical services span multiple platforms.
Recommendation — Define disruption procedures that keep security controls effective during restore and failover. Provide redundant processing paths and validate that failover works across platform boundaries.

Practitioner Guidance

What to prioritise: Start with the highest-value business services, then map their dependencies across legacy and cloud components. Resilience improvements should be driven by service criticality and cross-platform failure paths, not by whichever platform is currently receiving the most budget.

What to verify: Confirm that backup, identity recovery, and restore testing cover the full workflow, including the legacy-to-cloud handoff points. If you cannot restore a service end to end in a test environment, you do not yet have a credible hybrid resilience plan.

What good looks like: The organisation can prove that the same control objective, such as access review, recovery validation, or integrity checking, is enforced in both environments even when the technical implementation differs.

Practitioner takeaway: Hybrid resilience is not about making old and new systems identical, it is about making their failure modes visible and their control objectives consistent enough that the service can survive either platform failing first.