Operational Resilience, Third-Party Dependency, and Controlled Disengagement
Introduction
DORA Article 28 requires financial entities to manage risks arising from ICT third-party service providers, including cloud platforms, CI/CD SaaS providers, artifact registries, and other critical digital services.
A central — and often underestimated — requirement is the ability to exit a third-party arrangement without disrupting critical operations.
Exit strategy is not a contractual clause alone.
It is a tested, operational capability embedded into architecture, governance, and disaster recovery planning.
This article explains:
- What DORA Article 28 expects regarding exit strategies
- How exit capability connects to DR (Disaster Recovery) and BCP (Business Continuity Planning)
- How to test exit readiness in CI/CD and cloud-dependent environments
- What auditors and regulators will assess
1. Why Exit Strategy Is a Core DORA Requirement
Under DORA, financial entities must:
- Avoid excessive concentration risk
- Ensure continuity of critical functions
- Maintain the ability to terminate ICT contracts safely
- Prevent vendor lock-in from compromising resilience
An exit strategy ensures that:
- A provider failure does not paralyze delivery
- A contract termination does not break operations
- A cyber incident at a vendor does not cascade into systemic disruption
Exit readiness is therefore a resilience control, not just a procurement clause.
2. Exit Strategy vs Disaster Recovery vs Business Continuity
These concepts are related but distinct:
Exit Strategy
Controlled disengagement from a third-party provider and transition to an alternative solution.
Disaster Recovery (DR)
Restoration of systems and services after disruption.
Business Continuity Planning (BCP)
Maintaining critical business functions during and after disruptions.
Under DORA Article 28, exit strategy intersects with DR and BCP when:
- A cloud provider becomes unavailable
- A CI/CD SaaS platform is compromised
- A critical ICT provider fails or is sanctioned
- A contract termination requires migration
Exit capability must therefore be technically aligned with DR and BCP mechanisms.
3. Exit Risk in CI/CD and Cloud Architectures
Modern financial institutions rely on:
- Git hosting SaaS (GitHub, GitLab, Bitbucket)
- CI/CD platforms
- Artifact registries
- Cloud IaaS/PaaS
- SaaS-based security tools
- Dependency proxies
Each represents a potential single point of failure.
Exit risk scenarios include:
- Loss of access to CI/CD control plane
- Inability to retrieve pipeline configurations
- Dependency on proprietary artifact formats
- Locked-in infrastructure automation
- Loss of audit logs hosted by vendor
Exit strategy must therefore be built into:
- Architecture design
- Data portability
- Configuration export
- Backup mechanisms
4. Core Components of a DORA-Compliant Exit Strategy
A robust exit strategy includes:
4.1 Asset and Dependency Mapping
Organizations must identify:
- Which critical functions depend on which ICT providers
- Data hosted externally
- Configuration ownership
- Integration points
Without this mapping, exit testing is impossible.
4.2 Data Portability and Export
Critical questions include:
- Can repositories be exported in standard formats?
- Can CI/CD configurations be retrieved?
- Are artifact histories portable?
- Can logs be exported for compliance retention?
If logs and pipeline history cannot be exported, regulatory evidence may be lost during exit.
4.3 Alternative Solution Readiness
Exit requires more than cancellation.
Organizations must assess:
- Is an alternative provider pre-evaluated?
- Can pipelines be redeployed elsewhere?
- Are Infrastructure-as-Code templates cloud-agnostic?
- Are dependencies containerized or portable?
Vendor lock-in is a resilience risk under DORA.
4.4 Contractual Clauses
Contracts must include:
- Exit assistance clauses
- Transition support timelines
- Data handover requirements
- Retention guarantees
- Sub-processor transparency
Auditors will review whether these clauses are enforceable and aligned with operational plans.
5. Exit Strategy Testing in Practice
DORA expects exit strategies to be tested, not assumed.
Testing approaches may include:
5.1 Tabletop Exercises
Scenario-based workshops testing:
- Cloud provider outage
- CI/CD SaaS compromise
- Vendor insolvency
- Sanctions affecting provider
The goal is to validate decision processes and timelines.
5.2 Technical Migration Simulation
Controlled tests such as:
- Exporting repositories and rehosting them
- Rebuilding pipelines in a secondary environment
- Restoring artifacts from independent backups
- Deploying applications from an alternative registry
These tests reveal hidden dependencies.
5.3 DR + Exit Combined Testing
A mature approach integrates exit strategy into DR testing:
Example scenario:
“Primary CI/CD SaaS becomes unavailable for 72 hours.”
Test elements:
- Can deployments continue?
- Can emergency fixes be released?
- Are pipeline templates portable?
- Is audit evidence preserved?
This moves exit strategy from theoretical to operational.
6. Evidence of Exit Strategy Testing
From an audit perspective, organizations must produce:
- Exit strategy documentation
- Provider risk classification
- Dependency mapping records
- Test reports (tabletop and technical)
- Identified gaps and remediation plans
- Management approval of exit readiness
Evidence must show:
- Tests were performed
- Weaknesses were identified
- Improvements were implemented
Testing without documented outcomes is not considered sufficient.
7. What Auditors Will Assess
Auditors typically verify:
- Whether critical ICT providers are identified
- Whether exit strategies are defined per critical provider
- Whether exit plans are realistic and technically feasible
- Whether testing is periodic and documented
- Whether data portability is validated
- Whether BCP integrates third-party failure scenarios
Common audit findings include:
- Exit plans limited to contract clauses
- No technical validation
- No alternative provider identified
- Lack of CI/CD export capability
- Missing log retention during provider transition
8. Common Failure Patterns
Organizations often fail because:
- CI/CD pipelines are fully vendor-managed with no export process
- Artifact registries are proprietary with no backup
- Infrastructure automation depends on provider-specific APIs
- Exit scenarios are never rehearsed
- Responsibilities during exit are unclear
Exit strategy fails when architecture was not designed with portability in mind.
9. Designing CI/CD for Exit Readiness
To align with DORA Article 28, CI/CD architectures should:
- Use Infrastructure-as-Code
- Store pipeline configurations in version control
- Maintain independent backups
- Avoid hard-coded provider dependencies
- Support reproducible builds
- Preserve compliance evidence outside vendor-controlled systems
Exit readiness should be an architectural principle, not a recovery afterthought.
Conclusion
Under DORA Article 28, exit strategy is a resilience control tied to:
- Third-party risk management
- Operational continuity
- Regulatory accountability
It is not enough to state that exit is possible.
Organizations must prove that:
- Exit is technically feasible
- Dependencies are understood
- Alternative paths exist
- Tests have been performed
- Evidence is retained
In regulated environments, resilience includes the ability to leave.
Related Articles
- DORA Article 28 — Architecture
- DORA Article 28 — Auditor Checklist
- DORA Article 28 — Evidence Pack
- DORA Article 28 — CI/CD Controls Mapping
