DORA: what financial entities must do, pillar by pillar

Regulation (EU) 2022/2554, known as DORA (Digital Operational Resilience Act), has applied since 17 January 2025. Almost two years after its adoption, supervisors now expect arrangements that work, not just documents. Here is what DORA requires, how to read it proportionately and where to make progress.

Who is concerned?

DORA applies directly, without transposition, to the financial entities listed in its Article 2: credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, management companies, insurance and reinsurance undertakings, insurance intermediaries (other than SMEs), institutions for occupational retirement provision, market infrastructures, credit rating agencies, crowdfunding platforms, and more. In France, the competent authorities are mainly the ACPR and the AMF, depending on status.

The text is proportionate: a simplified framework (Article 16) applies in particular to small non-interconnected investment firms, exempted payment and e-money institutions and small pension funds.

ICT providers (software vendors, hosting providers, managed service providers) are not directly subject to DORA unless they are designated as critical third-party providers and placed under the oversight of the European authorities. But their financial customers must pass precise contractual requirements on to them.

Pillar 1: ICT risk management (Articles 5 to 16)

• The management body defines, approves and oversees the ICT risk management framework and is accountable for it; its members are trained.
• A documented framework, reviewed at least yearly: resilience strategy, policies, procedures, tools.
• Identification of business functions, information and ICT assets and their dependencies, in particular on providers.
• Protection and prevention: network security, access control, encryption, change and patch management.
• Detection of anomalous activities.
• Response and recovery: an ICT business continuity policy, response and recovery plans, tested.
• Backups and restoration procedures, learning after incidents and crisis communication.

Delegated Regulation (EU) 2024/1774 specifies these requirements, including for the simplified framework.

Pillar 2: ICT-related incidents (Articles 17 to 23)

1. An incident management process: detection, logging, handling, root cause analysis.
2. Classification against harmonised criteria (Delegated Regulation 2024/1772): clients and counterparts affected, duration, geographical spread, data losses, criticality of services, economic impact.
3. Reporting of major incidents to the authority, under Delegated Regulation (EU) 2025/301: initial notification within 4 hours of classification as major and at the latest 24 hours after becoming aware of it, intermediate report within 72 hours of the initial notification, final report at the latest one month after the last intermediate report.
4. Informing clients when the incident affects their financial interests.

Voluntary notification of significant cyber threats is also provided for.

Pillar 3: resilience testing (Articles 24 to 27)

A risk-based testing programme (vulnerability assessments, scenario-based tests, continuity tests, penetration tests…), with tests at least yearly for systems supporting critical or important functions. Entities designated by the authority also carry out threat-led penetration testing (TLPT) under the TIBER-EU framework, in principle every three years.

Pillar 4: ICT third-party service providers (Articles 28 to 30)

• A strategy and a policy on third-party risk.
• A register of information on all contractual arrangements for ICT services, in the format set by Implementing Regulation (EU) 2024/2956, provided to the authority on request and reported on annually.
• A pre-contract assessment (risks, concentration, subcontracting).
• Mandatory contractual clauses (Article 30): description of services, data location, service levels, assistance in case of incident, access and audit rights, termination conditions and, for critical or important functions, exit plans and participation in testing.
• Documented and testable exit strategies.

Pillar 5: information sharing (Article 45)

DORA encourages participation in cyber threat information-sharing arrangements, within a trusted framework, and requires the authority to be informed.

An eight-step action plan

1. Determine your regime (full or simplified) and scope (entity, group).
2. Map critical or important functions and their ICT dependencies.
3. Have the ICT risk management framework approved by the management body and plan its training.
4. Update the incident procedure with the DORA classification and reporting deadlines.
5. Complete and clean up the register of information.
6. Review the contracts of critical providers against Article 30.
7. Set up and run the testing programme; track remediation.
8. Prepare exit strategies and test them on at least one critical provider.

What if you are an ICT provider?

Anticipate the requests: Article 30 clauses, security questionnaires, participation in tests, exit plans, rapid incident notification. Aligning your ISO 27001 ISMS and ISO 22301 continuity with DORA is a strong commercial argument with banks and insurers.

How OK-GRC helps

OK-GRC’s DORA framework covers the articles of the regulation and their technical standards, linked to shared controls also used by ISO 27001 and ISO 22301. The vendor register tracks criticality, supported functions and contracts, the incident register handles classification and deadlines, and the “ICT risk management framework” template gives you a base to tailor with the AI assistant.