Industry

DORA in Practice: What Resilience Really Asks of Your Stack

TuniCyberLabs Team
7 min read

A year into DORA enforcement, the hard parts are clear: the register of information, threat-led penetration testing, and exit strategies that hold up.

DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — has applied since 17 January 2025, and the grace period is over. Financial entities have submitted their registers of information, supervisors are asking follow-up questions, and the first threat-led penetration testing cycles are underway. What looked like a compliance filing exercise in year one is turning into an operating-model question in year two: can your organization actually demonstrate resilience, and can your vendors?

That second question matters because DORA is unusual among EU regulations: it reaches through the regulated entity into its ICT supply chain. If you build or operate software for banks, insurers, investment firms, or payment institutions, DORA is your problem even though you are not a financial entity.

Five pillars, one operating model

DORA organizes obligations into five areas: an ICT risk management framework, incident classification and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. The mistake is treating these as five separate documents. In practice they form one loop — the risk framework defines critical functions, testing validates them, incidents feed back into the framework, and third-party management extends all of it to vendors.

The register of information is harder than it sounds

Every financial entity must maintain a register of all contractual arrangements with ICT providers, mapped to the functions they support, their criticality, and the subcontracting chain beneath them. This is fundamentally a data quality problem. Procurement knows the contracts, engineering knows the dependencies, and the two rarely agree on what supports a critical or important function. Spreadsheets collapse under the maintenance burden; you need a system of record with an owner, refreshed on every new contract and every architecture change. Vendors should expect to be asked for their own subcontractor maps — fourth-party risk is explicitly in scope.

TLPT is not a pentest with a fancier name

Threat-led penetration testing under DORA aligns with the TIBER-EU framework: intelligence-led scenarios, executed against production systems, with the defending teams unaware, at least every three years for designated entities. The scoping is done with regulators, and the point is not a vulnerability list — it is evidence that detection and response work under realistic pressure. Two consequences for engineers: production must tolerate adversarial testing, which forces honesty about blast radius and rollback; and providers supporting critical functions can be pulled into the scope of their customers' tests, contractually and operationally.

If you sell software to financial entities, read Article 30

DORA prescribes contractual provisions for ICT services supporting critical functions: audit and inspection rights, full service level descriptions, incident assistance, data locations, and — the one that surprises vendors — documented exit strategies. Your customer must be able to leave you without breaking their critical functions. That means you need real answers on data export formats, migration timelines, and escrow arrangements before the negotiation, not during it. Providers designated as critical ICT third parties fall under direct EU oversight with a lead overseer — the large cloud platforms are already in that regime.

A readiness checklist for providers:

1. Classify your services against the critical-or-important functions of your customer segments. 2. Build a contract clause library aligned to Article 30 so negotiations start from a compliant baseline. 3. Map your own subcontractors and their locations; you will be asked, in structured format. 4. Rehearse incident communication against customer timelines — financial entities must classify and report within hours, and they will need data from you fast. 5. Accumulate testing evidence deliberately: failover drills, restore tests, chaos experiments, and their results. 6. Assign an owner for the exit-strategy answer, including a tested data export path.

The forward-looking case is straightforward: resilience is becoming a procurement criterion, not a compliance afterthought. Financial entities are consolidating vendor lists around providers who make DORA easy — clean registers, ready-made clause sets, credible testing evidence. Teams that invest now are not just avoiding contract friction; they are building the artifact set that shortens every future enterprise sales cycle in the most demanding regulated market in Europe.

TAGS
DORAFinancial ServicesOperational ResilienceThird-Party RiskEU Regulation

Need help with
this topic
?

Our team specializes in the technologies and strategies discussed in this article. Let's talk about how we can help your business.

Get in Touch