DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — has applied across the EU since 17 January 2025. It takes what used to be scattered, supervisor-by-supervisor guidance on technology risk in finance and turns it into a single binding regulation, organised around five pillars. It is not a framework you choose to adopt: it is law, with supervisory powers and penalties behind it. Here is what each pillar actually requires, and why the fourth reaches well beyond banks.
Pillar 1 — ICT risk management (Articles 5–16)
This is the governance backbone the other four sit on. A financial entity must run a documented ICT risk-management framework that covers the full cycle: identify and classify every ICT asset and its dependencies; protect them through access control, encryption and patching; detect anomalous activity; and respond to and recover from incidents with tested backups, ICT business-continuity plans and restoration procedures. The framework has to include a “learning and evolving” loop, so findings from incidents and tests feed back into it rather than being filed away.
The change DORA forces is about accountability. The management body — the board — approves the framework, allocates the budget, keeps its own knowledge current, and is formally responsible for it. Technology risk can no longer be quietly delegated to whoever runs IT and forgotten. The framework must be reviewed at least once a year and after any major incident.
Pillar 2 — Incident management, classification and reporting (Articles 17–23)
Entities need a process to detect, manage and log ICT-related incidents, and to classify them against defined criteria: the number of clients or financial counterparts affected, data losses, the duration and downtime, geographical spread, and the economic impact. Those criteria decide whether an incident counts as “major”, and major incidents carry mandatory reporting.
Reporting to the competent authority happens in three stages: an initial notification within hours of classifying the incident as major, an intermediate report as the picture develops, and a final report with root-cause analysis roughly a month later. There is also a voluntary channel for flagging significant cyber threats. The practical consequence is easy to miss: you cannot report what you cannot see, so this pillar quietly assumes real detection and monitoring underneath it, not just a written procedure.
Pillar 3 — Digital operational resilience testing (Articles 24–27)
Every in-scope entity runs a testing programme sized to its risk profile: vulnerability assessments and scans, network security assessments, gap analyses, scenario-based tests, and tests of ICT continuity and backups. Critical systems are tested at least once a year, and the results are not the end point — they feed back into the pillar 1 framework.
The largest and most systemically important entities have to go further, with Threat-Led Penetration Testing (TLPT): intelligence-led red-team exercises against live production systems, run at least every three years under the TIBER-EU framework. Critical ICT providers that support the tested services can be pulled into those exercises too. This is where DORA stops being paperwork and starts checking whether the defences actually hold.
Pillar 4 — ICT third-party risk management (Articles 28–44)
This is the pillar that catches companies that are not financial entities at all. A financial entity has to manage the risk of its ICT providers across the whole relationship, not just at signing. It must keep a Register of Information cataloguing every ICT contractual arrangement — a deliverable supervisors can ask for directly — carry out due diligence before contracting, and assess concentration risk when too much depends on one provider.
The contracts themselves must carry mandatory clauses: full audit and access rights, security and data-handling requirements, incident-assistance obligations, conditions on sub-outsourcing, agreed service levels, and documented exit strategies so the entity can leave a provider without disrupting its own service. Providers that support “critical or important functions” get the strictest version of all of this. On top of that, the European Supervisory Authorities designate the most systemic providers — large cloud and infrastructure firms — as Critical ICT Third-Party Providers (CTPPs), under direct EU oversight that can issue recommendations and fines; the first were named in November 2025.
For a SaaS or infrastructure vendor, this is the mechanism that matters. Even if you are not a financial entity and never become a CTPP, your banking and insurance customers are obliged to push these requirements down to you by contract — audit rights, security clauses, exit plans, a line in their Register. That is how DORA arrives on your desk without the regulation ever naming you.
Pillar 5 — Information sharing (Article 45)
The one voluntary pillar. DORA encourages financial entities to exchange cyber-threat intelligence — indicators, tactics, techniques — within trusted communities, and gives good-faith sharing a measure of legal cover. Nobody is compelled to take part, but its presence signals the regulation’s direction of travel: resilience treated as a shared problem across the sector, not only an individual obligation.
Who DORA actually applies to
DORA binds financial entities — roughly 22,000 across the EU, spanning some 21 categories: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, trading venues, fund managers, credit-rating agencies and more. It applies with proportionality, so the smallest entities and microenterprises follow a lighter, simplified risk-management regime rather than the full weight of it. What it does not do is directly regulate every supplier of every bank: a normal software vendor is not a “financial entity” and is not automatically in scope.
So there are two distinct ways a technology company gets pulled in. The first is by contract, as an ICT provider to financial entities, inheriting the pillar 4 clauses through your customers. The second is by designation, as a CTPP supervised directly by the EU. Working out which of the two — if either — applies to you is the first useful question, because the two paths carry very different obligations.
Where this lands operationally
Four of the five pillars describe continuous activity — a live risk framework, incident detection and reporting, recurring testing, and ongoing third-party oversight — rather than a document produced once and shelved. It is the same gap between paperwork and operation that a certification audit exposes, and precisely what a compliance platform does not do. Qalea operates that layer: the monitoring and detection that make incident reporting possible, the testing programme, and the third-party evidence a bank’s procurement team or an auditor will ask for.
If DORA clauses have started appearing in your contracts, the first step is scoping which pillars actually apply to you.
