What is DORA and what does the regulation mean for your organisation?

What is DORA?

DORA, the Digital Operational Resilience Act, is Regulation (EU) 2022/2554. The regulation was adopted on 14 December 2022 and has applied since 17 January 2025 (Article 64). It is binding in its entirety and directly applicable in every EU member state; no national implementing law is needed.

DORA bundles the requirements for how financial firms handle ICT risk. Those requirements are spread across five substantive chapters, treated in this guide as five pillars: ICT risk management (Chapter II), managing and reporting ICT-related incidents (Chapter III), digital operational resilience testing (Chapter IV), managing ICT third-party risk (Chapter V) and information sharing on cyber threats (Chapter VI).

Two principles run through the entire regulation. The proportionality principle (Article 4): the weight of the implementation may match the size, risk profile and complexity of the organisation. And the simplified regime (Article 16): for certain small or exempted entities, Articles 5 to 15 do not apply, but a lighter set of requirements does.

Up front: this article is general information based on the text of the regulation, not legal advice. A self-assessment or checklist is not a certification and does not mean your organisation complies with DORA; the competent authority ultimately determines how the rules apply to your organisation.

Who does DORA apply to?

Article 2(1) lists twenty-one categories of entities the regulation applies to. They include, among others:

• credit institutions (banks);
• payment institutions and electronic money institutions, including exempted ones, and account information service providers;
• investment firms and crypto-asset service providers;
• insurance and reinsurance undertakings, and their intermediaries;
• institutions for occupational retirement provision;
• trading venues and managers of investment funds;
• crowdfunding service providers;
• ICT third-party service providers (in this guide simply: ICT providers).

The regulation groups the first twenty categories together as financial entities (Article 2(2)). ICT third-party service providers form the twenty-first category: they get no self-assessment obligations of their own, but the regulation reaches them through the contracts with their financial clients and, for providers designated as critical, through a European oversight framework (see pillar 4).

There are exceptions. Article 2(3) excludes, among others, occupational pension institutions operating schemes with no more than fifteen members in total, and insurance intermediaries that are microenterprises or small or medium-sized enterprises. In addition, the regulation applies lighter requirements to microenterprises in many places, and the entities of Article 16(1) (including small and non-interconnected investment firms, exempted payment institutions and electronic money institutions, and small institutions for occupational retirement provision) fall under the simplified regime.

Pillar 1: what does DORA require of ICT risk management? (Chapter II)

Chapter II (Articles 5 to 16) is the broadest part of the regulation and places final responsibility squarely with the management body: it defines the ICT risk management framework, approves it and oversees it (Article 5). The framework itself must be documented and reviewed at least yearly and after major ICT-related incidents (Article 6). The main lines:

• up-to-date and reliable ICT systems with sufficient capacity, including at peak times (Article 7);
• a current inventory of business functions, information and ICT assets and their interdependencies, including those held by ICT providers (Article 8);
• security policies, continuous monitoring and protection of the availability, authenticity, integrity and confidentiality of data (Article 9);
• prompt detection of anomalous activities, with alert thresholds and automatic alerts to the staff who must respond (Article 10);
• a business continuity policy with response and recovery plans tested at least yearly (Article 11), plus a backup policy with separated recovery environments and recovery objectives per function (Article 12);
• learning from threats, incidents and tests, and mandatory digital operational resilience training for all staff and senior management (Article 13);
• crisis communication plans with at least one designated spokesperson (Article 14).

For entities under the simplified regime, Article 16 replaces all of this with a lighter set: protect and continuously monitor systems, detect and handle risk sources and incidents quickly, know the key dependencies on ICT providers, safeguard the continuity of critical or important functions with tested plans, and provide for security awareness and training.

Pillar 2: how must you manage and report ICT incidents? (Chapter III)

Every financial entity must have an established process to detect, manage and report ICT-related incidents, record all ICT-related incidents and significant cyber threats, and identify and eliminate their root causes (Article 17). Incidents are classified using criteria such as the number of clients, counterparties and transactions affected, reputational impact, duration and downtime, geographical spread, data losses and economic impact (Article 18).

Major ICT-related incidents are reported to the competent authority in three steps: an initial notification, an intermediate report when there are relevant changes, and a final report once the root cause analysis is complete (Article 19(4)). If a major incident affects the financial interests of clients, you inform them without undue delay, including the measures you are taking to mitigate the effects (Article 19(3)). Credit institutions, payment institutions, account information service providers and electronic money institutions apply these rules to payment-related operational and security incidents as well (Article 23).

Pillar 3: what must you test? (Chapter IV)

Under DORA, testing is not a one-off project but a standing programme within the ICT risk management framework (Article 24); only microenterprises are exempt from that programme obligation. The programme follows a risk-based approach and tests all ICT systems and applications supporting critical or important functions at least once a year. Article 25 lists the appropriate types of tests, from vulnerability assessments and scans to scenario-based tests and penetration testing.

The heaviest form, threat-led penetration testing (TLPT), applies only to entities designated for it by the competent authority (Article 26(8)): at least every three years, on live systems supporting critical or important functions, with strict requirements on the suitability and independence of the testers (Article 27). ICT providers that fall within the scope of such a test must actually participate (Article 26(3)).

Pillar 4: what does DORA require around ICT providers? (Chapter V)

The starting point of Chapter V is Article 28(1): the financial entity remains fully responsible at all times for compliance, including for outsourced ICT services. Under DORA, outsourcing is never the outsourcing of responsibility. Around that, Section I builds concrete obligations:

• a current register of information covering all contracts with ICT providers, with at least yearly reporting to the supervisor and timely notification of planned contracts for critical or important functions (Article 28(3));
• assessment and due diligence before concluding any ICT contract, with extra attention to security standards for critical or important functions (Article 28(4) and (5));
• predetermined, risk-based audits and inspections of providers (Article 28(6));
• contracts that can be terminated in the circumstances the regulation lists, such as demonstrable weaknesses in the provider's ICT risk management (Article 28(7));
• documented and sufficiently tested exit strategies for ICT services supporting critical or important functions (Article 28(8));
• an assessment of concentration risk and of the risks of subcontracting chains, including outside the EU (Article 29).

Section II of this chapter (Articles 31 to 44) is the European oversight framework for ICT providers designated as critical. That part contains obligations for supervisors and for those providers themselves, not self-assessment obligations for financial entities.

Pillar 5: is information sharing on threats mandatory? (Chapter VI)

No. Article 45 expressly makes exchanging cyber threat information and intelligence between financial entities possible, under conditions: within trusted communities and through arrangements that protect the sensitivity of the information and respect confidentiality, data protection and competition rules (Article 45(1)). Those who participate notify the competent authority, as they do when their participation ends (Article 45(3)). Not participating is not a shortcoming.

What does DORA mean for ICT providers?

DORA places the self-assessment and reporting obligations on the financial entity, not on its providers. But the requirements reach the ICT provider along three routes:

1. 01Through the contract, for all ICT services. Article 30(2) prescribes minimum content for every ICT contract with a financial entity: a complete service description including conditions for subcontracting, the locations where services are provided and data is processed, provisions on data protection and on access to and return of data upon termination or insolvency, service levels, incident assistance, cooperation with authorities, and termination notice periods. Where relevant, this also includes participating in the client's security awareness training (point (i) of Article 30(2), linked to Article 13(6)).
2. 02Heavier for critical or important functions. If the service supports a critical or important function, additional provisions apply (Article 30(3)): full service level descriptions with measurable performance targets, notification and reporting obligations on the provider, mandatory contingency plans and security measures, participation in the client's threat-led penetration testing, unrestricted rights of access, inspection and audit for the client and its supervisor, and exit provisions with an appropriate mandatory transition period.
3. 03Through the register, due diligence and testing. Every financial client records the provider in its register of information (Article 28(3)), performs due diligence before concluding the contract (Article 28(4) and (5)) and determines in advance how often and on what it audits or inspects (Article 28(6)). If the service falls within the scope of a TLPT, participation is mandatory (Article 26(3)).

For an ICT provider this means, concretely: expect these provisions in new and renegotiated contracts with financial clients, and expect questions about security, continuity and exit that you must be able to answer with documentation.

How does a structured self-assessment help?

If you want to know where your organisation stands, you can walk through the regulation article by article. A structured self-assessment makes that manageable: for each requirement you record whether it applies (with a reason if it does not), how mature the implementation is on a scale from 0 (absent) to 5 (optimised), and which reasoning and evidence support that score. The proportionality principle of Article 4 should be visible in it: a low score is not by definition a shortcoming, the reasoning counts.

Novaro Compliance helps structure the self-assessment. The platform is in development and is being built with launching partners; DORA is on its roadmap as a framework. To be clear: a completed self-assessment is not a certification and does not mean your organisation complies with DORA. What it does give the board is a substantiated picture of where the organisation stands and where the work is.

More context: the Cybersecurity & compliance service describes how Novaro approaches security and demonstrability in the broader environment, and the frequently asked questions explain, among other things, how the platform handles your data.