The EU Digital Operational Resilience Act (DORA) applies from 17 January 2025. It creates a broad framework for ICT risk management in financial entities, including digital operational resilience testing and management of ICT third-party risk.
One part is unusually direct for cloud exit work. Article 28(8) says financial entities must put exit strategies in place for ICT services supporting critical or important functions. Those strategies must account for provider failure, deterioration, disruption, material risk and termination.
Three phrases matter
“Without disruption”
DORA says financial entities should be able to exit arrangements without disruption to business activities, limits on regulatory compliance or detriment to continuity and quality of client services. A provider inventory cannot demonstrate that outcome by itself.
“Sufficiently tested”
The Regulation says exit plans should be comprehensive, documented, sufficiently tested and periodically reviewed. The word tested shifts the centre of gravity from a static document toward technical and operational evidence.
“Alternative solutions”
Article 28 also refers to identifying alternative solutions and developing transition plans that can remove services and relevant data from a provider and transfer them securely and integrally to another provider or in-house.
Where workload assurance can help
A workload-level model can connect an important service to its technology boundary, make provider-specific dependencies visible, and keep evidence attached to a precise scope. A change-aware loop can then flag when the estate or provider has changed enough to justify review or re-testing.
This is complementary to—not a replacement for—business-service mapping, contracts, governance, impact tolerances, continuity planning, legal analysis or a complete DORA programme.
PortabilityLabs does not determine DORA applicability or certify compliance. It is being designed to produce technical evidence that may support parts of a wider, appropriately governed operational-resilience programme.
Testing should be proportionate
DORA itself uses proportionality and risk-based language. A sensible technical implementation follows that pattern: cheap inventory and policy evaluation often; integration checks when relevant inputs change; heavier synthetic or destructive tests only when the value justifies the cost and risk.