DAT-026 Customer Transition and Switching Execution
Description
Each customer switch or exit has a record naming the date the request was received, the destination the customer elected, the assistance given to the customer and to any third party the customer authorised, the point at which the transition completed and the point at which the data was erased. Service levels, support entitlements and feature availability run unchanged for a customer in transition, and continuity risks known to the organisation that fall inside the transition window are disclosed to that customer in writing. Where the transitional period the contract states cannot be met, the record carries the notification sent within the period the contract gives, the technical ground and the alternative period offered within the contractual ceiling. The security controls that apply to the data in service also apply to it in transfer and for as long as it is held for retrieval. Published transition terms state the period during which the service continues after notice of termination whichever party gave it, how that period is set against the complexity of the service, the migration support available and the points at which data and digital assets are returned and then deleted, and a transition runbook names the handover steps, the data and configuration handed over and the roles on both sides and is exercised at defined intervals, including against a scenario in which the organisation cannot continue operating, with the result recorded.
Rationale
A contract term is worth what the transition is worth. The failures this control is written against breach no clause: a departing tenant moved to a slower support queue, a migration partner refused a technical contact because it is not the contracting party, a deprecation notice that lands mid-transition and is never mentioned, an export staged on a bucket whose tenant controls went with the account. Once the customer has gone, an assessor has nothing to test but the record. The terms apply whichever party gave notice because a provider that terminated for the customer's breach still owes the transition, and the period is sized on the complexity of the migration rather than on the notice the organisation would otherwise offer. The provider-failure exercise is the one an export interface cannot answer, since the interface is the thing that goes away. Boundaries. VND-013 holds what the contract promises; this control holds what happened. DAT-023 holds the export capability and the format, tested by producing an export; DAT-027 holds who can reach the interfaces and on what terms. BCM-001 holds continuity during a disruption nobody chose; this holds continuity during a transition the customer chose. BCM-010 is the same discipline pointed at the services the organisation itself buys. MON-010 holds the status channel for degradation that has occurred, while the disclosure limb here covers a risk that has not. DAT-004 holds encryption in transit as a general matter; this requires it to hold across the switch and the retrieval window. DAT-021 holds the customer key and the behaviour on withdrawal, which severs access rather than moving it.
Applicability (9 profiles)
Exit is executed by the provider on the customer's behalf, because the customer cannot run the transition on infrastructure it does not control.
The deployer is the party switching, not the party executing the switch. BCM-010 and VND-008 hold its side: the exit plan over the services it buys and the offboarding of a departing supplier.
Condition: deployment_model in cloud-saas, cloud-single-tenant
Exit is executed by the provider on the customer's behalf, because the customer cannot run the transition on infrastructure it does not control. Conditional since 1.1: the profile lists every deployment model and this row is a commitment of a hosted service, so a provider that publishes weights or runs on infrastructure the customer controls has no hosted service to carry it (ADR-046 amendment, 2026-09-16).
Exit is executed by the provider on the customer's behalf, because the customer cannot run the transition on infrastructure it does not control.
The deployer is the party switching, not the party executing the switch. BCM-010 and VND-008 hold its side: the exit plan over the services it buys and the offboarding of a departing supplier.
Art. 25(2)(a) runs the transition for 30 calendar days with the service contract still applicable, and Art. 25(4) gives a second clock: 14 working days from the switching request to notify technical unfeasibility, with a justification and an alternative period capped at seven months. Silence past 14 working days leaves the 30 days in force. Art. 27 binds the destination provider as well, so the record of the exchange is what evidences good faith on this side of it.
Art. 30(3)(f) makes the transition period mandatory, so the provider cannot decline it even where it terminated for the customer's breach, and sizes it on the complexity of the service rather than on the notice it would otherwise offer. RTS 2024/1773 Art. 10 builds the customer's exit plan on three scenarios, one of them the provider's own failure, which is the scenario the runbook exercise has to cover. Art. 28(8) is the customer's duty this control serves.
Exit is executed by the provider on the customer's behalf, because the customer cannot run the transition on infrastructure it does not control.
Exit is executed by the provider on the customer's behalf, because the customer cannot run the transition on infrastructure it does not control.
Framework Mappings (10)
| DORA-Art.28.8 | Exit strategies for ICT services supporting critical or important functions | informative |
| DORA-Art.30.2.d | Access, recovery and return of data on insolvency or termination | informative |
| DORA-Art.30.3.f | Exit strategies and the mandatory transition period | full |
| DORA-RTS-2024/1773-Art.10 | Exit plan requirements and scenarios | partial |
| EU-DA-Art.25.2.a.i | Switching Assistance to the Customer | full |
| EU-DA-Art.25.2.a.ii | Business Continuity During the Transitional Period | full |
| EU-DA-Art.25.2.a.iii | Information on Known Continuity Risks | full |
| EU-DA-Art.25.2.a.iv | Security of Data During Transfer and Retrieval | full |
| EU-DA-Art.25.4 | Technical Unfeasibility Notification and Alternative Period | partial |
| EU-DA-Art.27 | Good Faith Cooperation in Switching | full |
Evidence (3)
Switching record for each customer that left the service in the period, giving the request date, the elected destination, the assistance given, the completion point and the erasure point.
Example: Switching records for the four customers that exited between January and June 2026, including record SW-2026-002 for Halden Logistics, closed 11 May 2026.
Test: Take every customer whose contract ended in the review period and request the switching record for each. Verify: (1) a record exists for each, (2) it names the date the switching request was received and the destination the customer elected, (3) assistance given to the customer and to third parties the customer authorised is recorded, with the third-party route used rather than described, (4) the transition completed inside the period the contract states, or a notification of technical unfeasibility was sent inside the period the contract gives and carries a technical ground and an alternative period within the contractual ceiling, (5) any continuity risk known to the organisation and falling inside the window was disclosed to that customer in writing, (6) the erasure date is recorded and falls after the retrieval period the contract states.
Published transition terms with the transition runbook and the record of its most recent exercise.
Example: Published transition and exit terms v2.0 of 15 February 2026, runbook TRB-EXIT-03 and the exercise report of 9 April 2026 run against a provider-failure scenario.
Test: Verify: (1) the published terms state the period during which the service continues after notice, how it is set against the complexity of the service, the migration support available and the return and deletion points, (2) the terms apply whichever party gave notice, (3) the runbook names the handover steps, the data and configuration transferred and the roles on both sides, (4) an exercise is recorded inside the stated interval, (5) the exercise covered a scenario in which the organisation cannot continue operating and the result records what a successor actually received rather than what it would have received, (6) any gap the exercise found carries an action with an owner and a date.
Entitlement, support tier and transfer configuration for tenants in transition, read from the systems that enforce them, with the access policy of any staging location used for a retrieval.
Example: Entitlement export tenant-entitlements-2026-05.json and bucket policy export for the exit staging account, both dated 20 May 2026.
Test: Verify: (1) a tenant with an open switching request carries the same plan entitlement, support tier and feature flags as before the request, read from the enforcing system rather than from a ticket, (2) no automated deprovisioning, throttle or feature disablement is triggered by the switching request state, (3) the transfer used the encrypted transport the service uses in normal operation, (4) any staging location holding data for retrieval is access-controlled to the same standard as the tenant it came from and its retention matches the contractual retrieval period, (5) access to the staging location is logged and the log shows only the customer and the parties it authorised.
Questions (3)
Is a switching record kept for every customer that leaves the service?
One record per departing customer, whether it moved to another provider, moved to its own infrastructure or asked for erasure. A closed support ticket counts only where it holds the elements the control lists.
What does the switching record capture?
Answer on the records for customers that have actually left. An element the runbook says will be captured but that no record holds does not count.
How is the transition runbook exercised?
Options run from the strongest exercise to the weakest. The first two differ in the scenario, not in the discipline: a scenario the organisation runs while it is still operating cannot test the handover a successor would receive if it were not.