Almost nine months after the EU Data Act started applying, the picture is clearer about where the real work sits. The gap between a data-residency diagram and a working exit strategy is wider than most teams expected when they first read the Regulation.
The Data Act has applied since 12 September 2025. DORA since 17 January 2025. NIS2 national measures were due by 17 October 2024, with varying levels of national transposition across Member States. The pressure these instruments create overlaps in ways that make compartmentalizing the legal workstream a risky strategy. The Commission's June 2026 Cloud and AI Development Act proposal does not amend the Data Act, but it reinforces the same operating reality: cloud capacity, switching, energy efficiency, and AI infrastructure are now policy-linked board topics rather than background hosting choices.
THE_RESIDENCY_DIAGRAM_IS_NOT_ENOUGH
Most teams initially answered data-governance questions with a storage region selector and a subprocessor list. That answered the GDPR-era question: where does the data live? The Data Act asks something different: can you move it, can you prove it, and can you exit without destroying the service?
The real friction sits in export quality. A portability export that is complete, machine-readable, and usable without interpretation is genuinely hard to produce for most complex products. Logs, backups, analytics copies, and support tooling often contain customer data and operational context that nobody governed as carefully as the primary database. Those are the pathways that tend to fail in a portability exercise.
"If you cannot move the data cleanly, you do not really control the service."
WHAT_PORTABILITY_MEANS_IN_PRACTICE
Article 23 of the Data Act requires data holders to take reasonable technical measures to ensure portability. The practical consequence is that export needs to be a first-class product feature, not a migration script someone last tested in 2023. Export jobs need to run at production scale. The output needs to be documented. The handover boundary between controller and processor roles needs to be explicit before anyone requests a porting.
Teams that have run switching exercises recently find the same pattern: the primary data moves without much trouble, but the operational context does not. Configuration, support history, access logs, restoration state — those are the parts that make a real exit painful and slow.
WHERE_DORA_AND_NIS2_CREATE_EXTRA_PRESSURE
DORA adds a resilience dimension for financial entities and their ICT supply chains. ICT third-party risk registers, contractual resilience requirements, and evidence of tested recovery paths are now obligatory rather than best practice. NIS2 does something analogous for covered entities under national implementation, particularly around supply chain risk and incident evidence chains.
- Keep a current and auditable map of where customer data, backups, logs, and support access actually live — not where they are supposed to live according to the architecture diagram.
- Run export tests against production-scale data, not a sanitized subset. Partial exports are not an exit strategy.
- Document provider dependencies, fallback routes, and who owns cutover decisions before an event forces the answer under pressure.
- Treat incident evidence, restoration runbooks, and communication duties as part of the same operating model — not as separate compliance artifacts.
THE_PRACTICAL_NEXT_STEP
Start with the three provider relationships that would be hardest to exit under pressure. Map what you would need to have produced, tested, and documented to make that exit plausible within 90 days. That exercise surfaces the real risk faster than any compliance gap analysis, and it gives product, engineering, and operations a concrete shared picture of where the gaps actually are.
WHAT_A_REAL_PORTABILITY_EXERCISE_LOOKS_LIKE
A portability exercise starts with a production-scale data sample and ends with a completed handover package — not with confirming that the export job ran without errors. The difference matters because most export failures are not process failures, they are content failures: the exported data is incomplete, in a format that requires interpretation unavailable to the receiving party, or missing the operational context needed to resume the service.
The gaps that surface most reliably are: configuration state that lives outside the primary database, access and audit logs stored in a different system from the data they describe, support ticket history attached to user accounts in a third-party tool, and restoration state that assumes specific infrastructure present only in the current environment. None of these are unusual. All of them turn up in portability exercises as blockers that were not visible in the architecture diagram.
Running the exercise against a staging environment with realistic data volume gives a better signal than running it against a curated sample. The exercise should produce a documented handover package with a format specification, a completeness checklist, and a list of manual steps required to restore service from the exported state. That package is the test artefact — if it cannot be read and executed by a team with no prior knowledge of your system, the portability work is not finished.
- Export at production scale, not from a sanitized sample. Size-related failures are common and are not visible until the actual data volume is in play.
- Include configuration exports, not just data. The configuration required to run the service is part of the data portability obligation, not an optional addition.
- Document the format specification and any interpretation required, so the receiving party does not depend on institutional knowledge held only by the originating team.
- Treat the handover package as a versioned artefact that is retested after every significant data model change.
STRUCTURING_THE_ICT_THIRD_PARTY_RISK_REGISTER
DORA's third-party risk register requirements are specific: it is not a list of suppliers. It is a register of ICT third-party service providers with classification by criticality, documentation of substitutability, and evidence that concentration risk has been assessed at an entity level. Concentration risk under DORA is assessed at the group level and across the relevant market — not just by counting how many critical providers a single firm uses.
The register needs to be maintained in a form that can be produced on request to a supervisory authority. That means it is a living document, not a point-in-time snapshot. When a critical provider relationship changes — new scope, changed architecture, different sub-service topology — the register entry needs to reflect it before the next supervisory review cycle, not at the next annual refresh.
Substitutability documentation is where most organizations find the hardest questions. For cloud infrastructure and large SaaS platforms, realistic substitution timelines are measured in months to years, not days. Documenting that honestly — with a realistic transition plan that accounts for data migration, configuration re-implementation, and staff retraining — is what the regulation requires. An optimistic substitutability estimate that could not survive a post-incident review serves no useful purpose and creates regulatory risk if tested.