DORA ICT Exit Strategies with ISO 27001 Controls

At 07:42 on a Monday, a fintech operations lead receives the message no one wants to read: the company’s cloud-based transaction monitoring provider has suffered a severe regional outage. By 08:15, the Chief Risk Officer is asking whether the affected service supports a critical or important function. By 08:40, Legal wants to know whether the contract gives the firm transition assistance, data export, deletion, and audit rights. By 09:05, the CISO is looking for evidence that the exit plan was tested, not merely written.

In another financial services firm, Sarah, the CISO of a fast-growing fintech platform, opens a pre-audit information request for a DORA compliance assessment. The questions are familiar until she reaches the section on ICT third-party service providers supporting critical or important functions. The auditors are not asking whether the company has a supplier policy. They are asking for documented, tested, and viable exit strategies.

Her mind jumps to the core cloud provider that hosts the platform, then to the managed security service provider that monitors threats around the clock. What if the cloud provider suffers a geopolitical disruption? What if the MSSP is acquired by a competitor? What if a critical SaaS provider becomes insolvent, terminates service, or loses customer trust after a major incident?

The uncomfortable answer in many firms is the same. There is a supplier risk assessment, a business continuity plan, a contract folder, a cloud inventory, and perhaps a backup report. But there is no single audit-ready DORA ICT third-party exit strategy connecting business criticality, contractual rights, technical portability, continuity plans, backup evidence, privacy obligations, and management approval.

DORA changes the tone of supplier management. Under Regulation (EU) 2022/2554, financial entities must manage ICT third-party risk as part of the ICT risk management framework. They remain fully responsible for compliance, maintain a register of ICT service contracts, distinguish ICT arrangements supporting critical or important functions, assess concentration and subcontracting risks, and maintain exit strategies for critical ICT third-party dependencies. DORA applies from 17 January 2025 and sets uniform EU requirements for ICT risk management, incident reporting, resilience testing, information sharing, and ICT third-party risk management across a broad range of financial entities.

A DORA exit strategy is not a paragraph in a supplier contract. It is a control system. It must be governed, risk assessed, technically feasible, contractually enforceable, tested, evidenced, and continuously improved.

Clarysec’s approach combines the Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, enterprise policy templates, and Zenith Controls: The Cross-Compliance Guide Zenith Controls to turn that Monday morning question into a prepared answer.

Why DORA exit strategies fail in real audits

Most DORA ICT exit strategy failures are structural before they are technical. The organization has a vendor owner, but no accountable risk owner. It has backup jobs, but no restoration evidence. It has a supplier due diligence questionnaire, but no documented decision on whether the provider supports a critical or important function. It has contract termination language, but no transition period aligned to the business continuity plan.

DORA forces these pieces together. Article 28 sets the general principles for ICT third-party risk management, including the need to manage the risk of ICT third-party service providers throughout the lifecycle and maintain appropriate exit strategies. Article 30 sets detailed contractual requirements for ICT services supporting critical or important functions, including service descriptions, locations of data processing, security protections, access and audit rights, incident assistance, cooperation with competent authorities, and termination rights.

The regulation is also proportionate. Articles 4 and 16 allow certain smaller or exempted entities to apply a simplified ICT risk management framework. But simplified does not mean undocumented. Smaller financial entities still need documented ICT risk management, continuous monitoring, resilient systems, prompt identification of ICT incidents, identification of key ICT third-party dependencies, backup and restoration, business continuity, response and recovery, testing, lessons learned, and training.

A small fintech cannot say, “We are too small for exit planning.” It can say, “Our DORA exit strategy is scaled to our size, risk profile, and service complexity.” The difference is evidence.

For entities that also appear in NIS2 national scoping, DORA operates as the sector-specific Union legal act for overlapping cybersecurity obligations in the financial sector. NIS2 still matters across the broader ecosystem, especially for managed service providers, managed security service providers, cloud providers, data centres, and digital infrastructure entities. NIS2 Article 21 reinforces the same themes: risk analysis, incident handling, business continuity, supply chain security, secure acquisition, effectiveness assessment, training, cryptography, access control, asset management, and authentication.

Supervisors, customers, auditors, and boards may ask the question differently, but the core issue is consistent: can you exit a critical ICT provider without losing control of service continuity, data, evidence, or customer impact?

Make the exit strategy part of the ISMS

ISO/IEC 27001:2022 provides the management system backbone for DORA exit planning.

Clauses 4.1 to 4.4 require the organization to define its context, interested parties, legal, regulatory and contractual requirements, ISMS scope, interfaces, dependencies, and processes. This is where a financial entity identifies DORA, customer commitments, outsourcing expectations, cloud dependencies, privacy obligations, subcontractors, and ICT services inside the ISMS boundary.

Clauses 5.1 to 5.3 require leadership, policy, resources, role assignment, and accountability. This aligns with DORA’s governance model, where the management body defines, approves, oversees, and remains responsible for ICT risk management, including ICT business continuity, response and recovery plans, ICT audit plans, budgets, resilience strategy, and ICT third-party risk policy.

Clauses 6.1.1 to 6.1.3 convert exit planning into risk treatment. The organization defines risk criteria, performs repeatable risk assessments, identifies risks to confidentiality, integrity, and availability, assigns risk owners, evaluates consequences and likelihood, selects treatment options, compares controls with Annex A, produces a Statement of Applicability, prepares a risk treatment plan, and obtains risk owner approval and residual risk acceptance.

Clause 8.1 then requires operational planning and control. The organization must plan, implement, and control ISMS processes, maintain documented information showing that processes were carried out as planned, manage changes, and control externally provided processes, products, or services relevant to the ISMS.

ISO/IEC 27005:2022 strengthens this approach. Clause 6.2 advises organizations to identify requirements of interested parties, including ISO/IEC 27001:2022 Annex A controls, sector-specific standards, national and international regulations, internal rules, contractual requirements, and existing controls from prior risk treatment. Clauses 6.4.1 to 6.4.3 explain that risk criteria should consider legal and regulatory aspects, supplier relationships, privacy, operational impacts, contract breaches, third-party operations, and reputational consequences. Clauses 8.2 to 8.6 support a control library and treatment plan that can combine ISO/IEC 27001:2022 Annex A with DORA, NIS2, GDPR, customer commitments, and internal policies.

The operating model is straightforward: one requirements inventory, one supplier risk register, one Statement of Applicability, one risk treatment plan, and one evidence pack for each critical exit scenario.

The ISO/IEC 27001:2022 controls that anchor DORA exit planning

DORA exit strategies become audit-ready when supplier governance, cloud portability, continuity planning, and backup evidence are treated as one connected control chain.

Clarysec’s Zenith Controls maps ISO/IEC 27001:2022 Annex A controls to control attributes, audit evidence, and cross-compliance expectations. It is not a separate control framework. It is Clarysec’s cross-compliance guide for understanding how ISO/IEC 27001:2022 controls support audit, regulatory, and operational outcomes.

For a DORA ICT third-party exit strategy, the audit trail should show:

• The supplier is classified and linked to business processes.
• The service is assessed for support of a critical or important function.
• The exit risk is recorded with an accountable risk owner.
• Contract clauses support transition, access, audit, data return, data deletion, cooperation, and continuity.
• Cloud portability and interoperability have been validated.
• Backups and restoration tests prove recoverability.
• Temporary substitution or alternative processing has been documented.
• Exit testing results have been reviewed, remediated, and reported to management.

Contract language is the first continuity control

A contract should be the first continuity control, not a barrier to continuity. If the provider can terminate quickly, delay exports, restrict log access, charge undefined transition fees, or refuse migration support, the exit strategy is fragile.

In Zenith Blueprint, the Controls in Action phase, Step 23, Control 5.20, explains that supplier agreements should include the practical security requirements that make exit possible:

Key areas typically addressed in supplier agreements include:

✓ Confidentiality obligations, including scope, duration, and third-party disclosure restrictions;

✓ Access control responsibilities, such as who can access your data, how credentials are managed, and what monitoring is in place;

✓ Technical and organizational measures for data protection, encryption, secure transmission, backup, and availability commitments;

✓ Incident reporting timelines and protocols, often with defined timeframes;

✓ Right to audit, including frequency, scope, and access to relevant evidence;

✓ Subcontractor controls, requiring your supplier to pass on equivalent security obligations to their downstream partners;

✓ End-of-contract provisions, such as data return or destruction, asset recovery, and account deactivation.

That list bridges DORA Article 30 contract expectations and ISO/IEC 27001:2022 Annex A control A.5.20.

Clarysec’s enterprise policy language makes the same point operational. In the Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, section “Implementation Requirements,” clause 6.4.3 states:

Technical Fallbacks: Ensure data portability and interoperability to support service transition if required (e.g., regular backups in standard formats from a SaaS provider to enable migration).

The same policy, clause 6.8.2, requires:

A right to transition assistance (exit assistance clause) where a provider change is required, including continued service during a defined transition period.

This clause often decides whether an exit strategy survives audit. It turns exit from a cliff-edge event into a managed transition.

For smaller entities, the Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, section “Governance Requirements,” clause 5.3.6, requires:

Termination terms, including secure data return or destruction

For enterprise environments, the Third party and supplier security policy Third party and supplier security policy, section “Policy Implementation Requirements,” clause 6.5.1.2 requires:

Return or certified destruction of all organization-owned information

Those policy requirements should trace directly to contract clauses, supplier procedures, exit runbooks, and audit evidence.

Cloud exit: test portability before you need it

Cloud services are where DORA exit strategies often become vague. The firm assumes it can export data, but nobody has tested the format. It assumes deletion will happen, but the provider’s retention model includes backups and replicated storage. It assumes an alternative provider can receive the data, but schemas, identity integrations, encryption keys, secrets, logs, APIs, and rate limits make migration slower than the impact tolerance allows.

ISO/IEC 27001:2022 Annex A control A.5.23 addresses this lifecycle problem by requiring information security controls for acquisition, use, management, and exit from cloud services.

Clarysec’s Cloud Usage Policy-sme Cloud Usage Policy - SME, section “Policy Implementation Requirements,” clause 6.3.4 requires:

Data export capability confirmed before onboarding (e.g., to avoid vendor lock-in)

Clause 6.3.5 requires:

Confirmation of secure deletion procedures before account closure

These requirements belong at the beginning of the supplier lifecycle. Do not wait until termination to ask whether data can be exported. Do not wait until account closure to ask whether deletion evidence exists.

A practical DORA cloud exit test should include:

1. Export a representative dataset in the agreed format.
2. Validate completeness, integrity, timestamps, metadata, and access controls.
3. Import the dataset into a staging environment or alternative tool.
4. Confirm encryption key handling and secrets rotation.
5. Confirm log export and audit trail retention.
6. Document provider deletion procedures, including backup retention and deletion certification.
7. Record issues, remediation actions, owners, and deadlines.
8. Update the supplier risk assessment, Statement of Applicability, and exit plan.

Portability is not a procurement promise. It is a tested capability.

A one-week sprint for an audit-ready DORA exit plan

Consider a payment institution using a SaaS fraud analytics provider. The provider ingests transaction data, customer identifiers, device telemetry, behavioural signals, fraud rules, scoring outputs, and case notes. The service supports a critical fraud detection process. The firm also uses a cloud data warehouse to store exported analytics results.

The CISO wants a DORA ICT third-party exit strategy that can survive internal audit and supervisory review. A one-week sprint can expose the gaps and build the evidence chain.

Day 1: classify the supplier and define the exit scenario

Using Zenith Blueprint, Controls in Action phase, Step 23, Action Items for Controls 5.19 to 5.37, the team starts by reviewing and classifying the supplier portfolio:

Compile a full list of current suppliers and service providers (5.19), and classify them based on access to systems, data, or operational control. For each classified supplier, verify that security expectations are clearly embedded in contracts (5.20), including confidentiality, access, incident reporting, and compliance obligations.

The supplier is classified as critical because it supports a critical or important function, processes sensitive operational data, and affects transaction monitoring outcomes.

The team defines three exit triggers:

• Provider insolvency or service discontinuation.
• Material security breach or loss of confidence.
• Strategic migration to reduce concentration risk.

Day 2: build the requirements inventory and risk record

The team creates one requirements inventory covering DORA ICT third-party risk, ISO/IEC 27001:2022 supplier and cloud controls, GDPR obligations for personal data, customer contract commitments, and internal risk appetite.

Under GDPR, the firm confirms whether transaction identifiers, device IDs, location signals, and behavioural analytics relate to identified or identifiable individuals. GDPR Article 5 principles, including integrity, confidentiality, storage limitation, and accountability, become part of the exit evidence requirement. If the exit involves transfer to a new provider, the legal basis, purpose, minimisation, retention, processor terms, and safeguards must be documented.

The risk record includes the following:

Day 3: fix contract gaps

Legal and procurement compare the contract against Clarysec’s supplier clauses. They add transition assistance, continued service during a defined transition period, audit and evidence access, subcontractor notification, data export format, secure deletion certification, incident cooperation, and recovery time commitments.

The Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy, section “Policy Implementation Requirements,” clause 6.5.1 states:

Contracts with critical vendors shall include continuity obligations and recovery time commitments.

For SMEs, the Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, section “Risk Treatment and Exceptions,” clause 7.2.1.4 requires teams to:

document temporary vendor or partner substitution plans

That clause turns “we will migrate” into an actionable fallback: which provider, which internal workaround, which manual process, which data extract, which owner, and which approval path.

Day 4: test data portability and backup recoverability

The technology team exports fraud rules, case data, transaction scoring outputs, logs, configuration, API documentation, and user access lists. They test whether the data can be restored or reused in a controlled environment.

The Backup and Restore Policy-sme Backup and Restore Policy - SME, section “Governance Requirements,” clause 5.3.3 requires:

Restore tests are conducted at least quarterly, and the results are documented to verify recoverability

The enterprise Backup and Restore Policy Backup and Restore Policy, section “Enforcement and Compliance,” clause 8.3.1 adds:

Periodically audit backup logs, configuration settings, and test results

In Zenith Blueprint, Controls in Action phase, Step 19, Control 8.13, Clarysec warns why this matters:

Restoration testing is where most organizations fall short. A backup that cannot be restored in time, or at all, is a liability, not an asset. Schedule regular restore drills, even if only partial, and document the outcome.

The team discovers that exported case notes do not include attachments, and API rate limits make a full export too slow for the defined recovery objective. The issue is logged, assigned, and remediated through a contract addendum and technical export redesign.

Day 5: run the exit tabletop and evidence review

The team performs a tabletop exercise: the supplier announces termination in 90 days after a major incident. Operations must continue fraud monitoring while data is migrated.

In Zenith Blueprint, Controls in Action phase, Step 23, Control 5.30, Clarysec explains the test standard:

ICT readiness begins long before disruption occurs. It involves identifying critical systems, understanding their interdependencies, and mapping them to business processes.

The same section adds:

The recovery time objectives (RTOs) and recovery point objectives (RPOs) defined in the business continuity plan must be reflected in technical configurations, contracts, and infrastructure design.

The evidence pack includes supplier classification, risk assessment, contract clauses, exit runbook, data export results, backup restore evidence, deletion procedure, alternative provider assessment, tabletop minutes, remediation log, management approval, and residual risk decision.

The CISO can now answer the board’s question with evidence, not optimism.

Cross-compliance: one exit plan, multiple audit lenses

A strong DORA exit strategy reduces duplicated compliance work across ISO/IEC 27001:2022, NIS2, GDPR, NIST, and COBIT 2019 governance expectations.

The important point is not that one framework replaces another. The value is that a well-built ISMS lets the organization generate evidence once and reuse it intelligently.

Clarysec’s Zenith Controls helps teams prepare for these audit lenses by connecting ISO/IEC 27001:2022 controls to audit evidence and cross-framework expectations.

A common audit failure is evidence fragmentation. The supplier owner has the contract. IT has backup logs. Legal has the data processing agreement. Risk has the assessment. Compliance has the regulatory mapping. Nobody has the full story.

Clarysec solves this by designing the evidence pack around the exit scenario. Every document answers one audit question: what service is being exited, why it is critical, what data and systems are affected, who owns the risk, what contract rights make exit possible, what technical mechanisms make migration possible, what continuity arrangements keep the business running, what test proves the plan works, what issues were remediated, and who approved the residual risk.

The Clarysec DORA exit strategy checklist

Use this checklist to turn a DORA ICT third-party exit strategy from a document into an auditable control set.

Turn exit planning into a board-ready resilience control

If your DORA exit strategy is only a contract clause, it is not ready. If your backup has never been restored, it is not ready. If your cloud provider can export data but nobody has validated completeness, it is not ready. If your board cannot see the residual risk decision, it is not ready.

Clarysec helps CISOs, compliance managers, auditors, and business owners build DORA ICT third-party exit strategies that are practical, proportionate, and audit-ready. We combine the Zenith Blueprint Zenith Blueprint for implementation sequencing, Zenith Controls Zenith Controls for cross-compliance mapping, and policy templates such as the Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, Cloud Usage Policy - SME Cloud Usage Policy - SME, Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME, and Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy to create a complete control-to-evidence chain.

Your next step is simple and high value: select one critical ICT supplier this week. Classify it, review its contract, test one data export, verify one restore, document one substitution plan, and create one evidence pack.

That single exercise will show whether your DORA exit strategy is a real resilience capability or just a document waiting to fail under audit.