Since January 2025, the Digital Operational Resilience Act applies to banks, insurers, investment firms, payment institutions and most of their critical ICT providers across the EU. DORA is often discussed as a cybersecurity regulation. In practice, a large share of its requirements lands directly on your data platform, because that is where critical information lives, moves and gets transformed.
What DORA actually asks of a data platform
Strip away the legal language and four demands remain:
1. Know and control your ICT third parties. Article 28 requires a register of all ICT service arrangements and a hard look at concentration risk. A data platform that locks you into one non-European provider, with no realistic exit, is exactly the dependency DORA tells you to manage.
2. Prove operational resilience. You must understand how a failure propagates, recover within defined objectives, and test that recovery. That requires knowing precisely which datasets feed which critical functions: in other words, lineage.
3. Keep an audit trail that satisfies a supervisor. When the regulator asks who accessed what, when, and what was done with it, “we can pull the logs from a ticket” is not an answer. Continuous, queryable, exportable audit is.
4. Have a credible exit strategy. Article 28(8) is explicit: critical ICT contracts need documented exit plans. If your data is trapped in a proprietary format inside a vendor’s perimeter, your exit plan is fiction.
The exit strategy test
The fastest way to assess a platform against DORA is to ask one question: what happens on the day you decide to leave?
- If the answer involves a multi-year migration project, proprietary export tools and vendor goodwill, you have a concentration risk to report.
- If the answer is “our tables are open Apache Iceberg on our own object storage, any engine can read them tomorrow”, you have an exit plan you can actually write down.
Open formats are not a technical preference under DORA. They are a compliance instrument.
A practical DORA checklist for your data stack
| DORA expectation | What to look for |
|---|---|
| ICT register & concentration risk | Bring-your-own-cloud, European operating entities, no single point of jurisdictional failure |
| Resilience & recovery | Snapshots and time travel on tables, reproducible runs, documented RTO |
| Audit | Complete action log with actor and timestamp, exportable to storage you own |
| Lineage | Captured automatically from queries and jobs, not maintained by hand |
| Exit strategy | Open table formats, data on your own bucket, documented offboarding |
Where Polnor fits
Polnor was designed with these answers built in rather than bolted on. The platform runs on your own OVHcloud or Scaleway account, so the infrastructure dependency stays under your contract and your jurisdiction. Every action lands in an audit log you can export hourly to your own S3. Column-level lineage is recorded automatically from every query, job and notebook. And because your tables are open Iceberg on your bucket, the exit strategy chapter of your DORA file writes itself.
If DORA is on your roadmap this year, request a demo: we will map your critical data flows against the checklist above.