DORA · ICT third-party risk
Give your exit plan technical evidence.
Make the tested workload, scenario, target and result understandable to engineering, risk and the people who approve the plan.
What to connect to your programme
DORA Article 28(8) addresses exit strategies and reviewed, tested plans for ICT services supporting critical or important functions. Delegated Regulation (EU) 2024/1773, Article 10, develops the exit-plan policy requirements.
| Question | Technical record | Your organisation still owns |
|---|---|---|
| What supports the service? | A reviewed workload boundary and observed dependencies. | Business-service mapping, criticality and contract ownership. |
| What was tested? | Versioned criteria, package identity, execution method and time. | Scenario selection, risk appetite and whether the test is sufficient. |
| What remains unresolved? | Failed checks, unsupported paths and recorded limitations. | Remediation decisions, resourcing and management approval. |
Current reference evidence demonstrates synthetic contract tests. Original-application execution, data movement and a stressed production exit require further tests. PortabilityLabs does not certify DORA compliance or generate/submit the register of information.
A worked portability result
A synthetic example with the test scope and limitations visible.
Inspect the evidence →Understand the distinctionRegister versus exit test
Governed contractual reporting and executable technical evidence have different roles.
Read the article →Control the dataDeployment choices
Customer-hosted and sovereign architectures for controlled environments.
Compare options →Start with the technical evidence.
No regulatory questionnaire is required to discover a workload. Agree any regulatory mapping separately with your risk and legal owners.