The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. Unlike NIS2 it is a regulation rather than a directive, so it applies directly in every Member State without waiting for national transposition, and it is supervised by the financial regulators rather than the cybersecurity agencies.
Its premise is simple: a bank, an insurer or a trading venue can be brought down by an ICT failure as surely as by a credit loss, so operational resilience against ICT risk is a matter for prudential supervision. The consequence for the technology industry is less obvious and more far-reaching: DORA regulates the relationship between financial entities and the suppliers they depend on, which means the obligations flow down into contracts with cloud providers, software vendors and managed service providers who are not themselves regulated.
Who is in scope
Twenty types of financial entity are listed in Article 2: credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, central securities depositories, trading venues, insurance and reinsurance undertakings, insurance intermediaries, pension institutions, credit rating agencies, crowdfunding providers, and more. A proportionality principle scales the obligations to the size and risk profile of the entity, and some micro-enterprises get a simplified regime.
ICT third-party providers are in scope in two ways. All of them are reached indirectly, through the contractual requirements their financial customers must impose. A small number, designated as critical by the European Supervisory Authorities, are reached directly through an oversight framework with a lead overseer, inspection powers and penalty payments. The first designations were made in late 2025 and cover the largest cloud and infrastructure providers.
The five pillars
ICT risk management (Chapter II). The management body owns ICT risk and must approve and periodically review a framework covering identification, protection, detection, response, recovery, learning and communication. The framework has to be documented, tested, and audited internally. Recovery objectives, backup policies and a crisis communication plan are explicit requirements, not implied ones.
ICT-related incident management and reporting (Chapter III). Entities must classify incidents against thresholds set in regulatory technical standards, and report major ones to their competent authority: an initial notification within four hours of classification and no later than 24 hours of becoming aware, an intermediate report within 72 hours, and a final report within one month. Significant cyber threats may be reported voluntarily.
Digital operational resilience testing (Chapter IV). Every entity runs a testing programme: vulnerability assessments, scenario-based tests, source code reviews and the like, on a risk basis, at least annually for critical systems. Entities identified as significant must also run threat-led penetration testing (TLPT) every three years, following the TIBER-EU style framework, on live production systems, with the results shared with the authority.
ICT third-party risk (Chapter V). This is the pillar that reaches suppliers. Entities must maintain a register of information listing every contractual arrangement for ICT services, distinguishing those that support critical or important functions. Before contracting, they must assess concentration risk and the supplier's suitability. Contracts must contain the provisions in Article 30: service descriptions and locations, data protection, availability and integrity commitments, incident assistance, audit and access rights for the entity and the authority, exit strategies with transition periods, and, for critical functions, service levels, participation in testing, and business contingency arrangements.
Information sharing (Chapter VI). Entities may exchange cyber threat intelligence within trusted communities, subject to safeguards. This pillar is permissive rather than mandatory.
What an auditor asks for
A DORA engagement, whether an internal audit, a readiness review or a supplier assurance exercise, tends to follow the pillars in order and ask for the artefact each one implies:
- The ICT risk management framework and the board minutes approving it, plus evidence of the periodic review and of the management body's own training on ICT risk, which Article 5 requires.
- The asset inventory with the mapping of ICT assets to business functions and the identification of critical or important functions.
- The incident classification procedure, the incident log, and copies of any reports filed with the authority, with timestamps that show the deadlines were met.
- The testing programme, the results of the last annual tests on critical systems, the remediation tracking, and, for significant entities, the TLPT scope and attestation.
- The register of information in the format the ESAs prescribe, and a sample of contracts checked against Article 30 clause by clause.
- The exit strategies for critical functions, and the evidence that they were tested or at least walked through.
- Concentration risk analysis: how many critical functions depend on one provider, and what the plan is if that provider fails.
For ICT suppliers
If you sell software or services to a bank or an insurer in the EU, you have probably already received a revised contract, a questionnaire, or both. What your customer is doing is populating their register of information and satisfying Article 30. The things that make you easy to keep as a supplier:
- Being able to state, in writing, where data is processed and stored, and to notify changes.
- Accepting audit and access rights, including for the customer's regulator, and having a way to honour them without disrupting your other customers, usually by offering an independent assurance report as the first line.
- Supporting incident notification with the detail and the speed your customer's own deadlines require.
- Having an exit plan you can describe: data return formats, transition assistance, deletion confirmation.
- Participating in your customer's resilience testing where you support a critical function.
An ISO 27001 certificate or a SOC 2 report is not DORA compliance, but a supplier who holds one has already answered most of the questions in the register. The gap is usually the contractual terms and the exit and testing commitments, which no certificate covers.
The mistake to avoid
The most common failure in the first year of application was treating DORA as a security project run by the CISO. It is a governance regulation. The management body is named as accountable, the register is a regulatory filing, the incident deadlines are legal deadlines, and the contract clauses are a legal requirement. The entities that were ready had legal, procurement, risk and technology in the same room from the start.