Seven 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_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.