DORA explained: what does the regulation mean for your organisation?

You work in the financial sector, or you supply software to a bank, insurer or payment institution, and you hear "DORA" everywhere. But what does the regulation actually mean for your organisation? This article gives you a clear picture of what DORA requires, who it applies to, and what the five pillars ask of you in practice.

What is DORA?

DORA stands for Digital Operational Resilience Act, the European regulation with reference EU 2022/2554. The regulation entered into force on 16 January 2023 and became fully applicable on 17 January 2025. From that date, financial entities and critical ICT service providers in the EU must demonstrably comply.

The goal is concrete: to strengthen the digital operational resilience of the European financial sector. Institutions must be able to demonstrate that they can withstand, respond to, and recover from ICT disruptions and cyber threats. DORA is not a directive that each country must transpose into national law. It is an EU regulation that applies directly and uniformly in all EU member states. No national implementation deadline, no room for diverging interpretations. A bank in Amsterdam is subject to the same requirements as a payment institution in Vienna.

Can a startup be in scope for DORA?

Yes, and this catches many startups off guard. A common example is companies with an AISP licence (Account Information Service Provider) under PSD2. These are companies that access financial data on behalf of users — think of budgeting apps or financial dashboards — but do not execute financial transactions themselves. Because they hold a PSD2 licence, they are classified as a payment institution under EU law, which means they fall directly within the scope of DORA. The fact that they are small, early-stage, or "only look at data" does not change that. If your company holds any of the following licences, you are likely in scope:

• AISP (Account Information Service Provider)
• PISP (Payment Initiation Service Provider) -E-money institution licence
• Any other PSD2-regulated licence

When in doubt, the starting point is always: check your licence category, not your company size.

Who does DORA apply to?

Financial institutions

The regulation applies to approximately twenty categories of financial entities. Think of banks, insurers, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, central counterparties, fund managers, credit rating agencies, pension funds and crowdfunding platforms. That is more than most people expect. "DORA is only for banks" is a persistent misconception -- more on that below.

Critical ICT service providers

Beyond the financial institutions themselves, ICT suppliers can also fall directly under DORA. Cloud providers, software suppliers and data analytics companies that deliver critical services to financial entities can be designated by the European Supervisory Authorities (ESAs) as a Critical Third-Party Provider (CTPP). On 18 November 2025, the ESAs designated the first nineteen CTPPs, including major cloud providers and market data providers. A designated CTPP falls under direct European supervision, with a lead overseer.

Do you supply software to a bank or insurer without being a CTPP yourself? Then you are not directly subject to DORA, but you will need to meet DORA requirements contractually. Your customer is obliged to include those requirements in the contract.

Proportionality

DORA tailors obligations to size and risk profile. A specific group (small and non-interconnected investment firms, exempted payment institutions, small pension institutions) may apply a simplified ICT risk management framework under Article 16. Micro-enterprises with fewer than 10 employees and €2 million in turnover also receive specific exemptions. Smaller means less burden, but not exemption.

The five pillars of DORA

1. ICT risk management

Every financial entity must have a documented ICT risk management framework. That framework covers identification, protection, detection, response and recovery. The board is ultimately responsible for this -- that is stated explicitly in the regulation. A risk assessment of the ICT environment is the first step, followed by concrete control measures for each identified risk. Not a one-off project, but an ongoing management process.

2. Incident reporting

Significant ICT incidents must be reported to the competent national supervisor -- in the Netherlands, DNB or the AFM depending on the type of entity. The timeline is tight. An initial report must be submitted as soon as possible, in any case within 4 hours of classification as a major incident, with a backstop of 24 hours after becoming aware. This is followed by an intermediate report within 72 hours of the initial notification, and a final report within one month. This is stricter than the reporting obligation under NIS2. Internal classification procedures must already be in place.

3. Digital operational resilience testing

ICT systems must be tested regularly. This starts with basic resilience tests for all entities: vulnerability assessments, scenario analyses, network penetration tests. Entities designated by the competent authority based on their risk profile must additionally carry out a Threat-Led Penetration Test (TLPT) at least every three years, in which ethical hackers simulate the methods of real attackers. Test results serve as evidence to the supervisor.

4. ICT third-party risk management

This is the pillar that catches many organisations off guard. DORA requires you to actively manage the risk of all your ICT suppliers. This starts before entering into a contract: due diligence, suitability assessment, risk appraisal. DORA then sets minimum contractual requirements: exit strategies, audit rights, SLA definitions, location of data processing. A register of all ICT third-party arrangements is mandatory and must be reported to the supervisor annually. You can maintain this via a risk register that records the contractual status and risk classification for each supplier.

5. Information sharing

DORA encourages financial entities to share information about cyber threats and vulnerabilities with each other. Not a hard obligation, but an active incentive. Participating in sector-level information-sharing platforms contributes to a stronger collective resilience picture.

What DORA concretely asks of your organisation

In essence, you need to be able to demonstrate five things: board approval of the ICT risk management framework, a documented ICT risk framework with a risk assessment and control measures, a working incident classification and reporting process with the correct timelines, regular resilience tests with documented outcomes, and a supplier register in which all ICT arrangements contractually meet the DORA minimum requirements. The board bears ultimate responsibility. This is not an IT topic you can delegate. Missing contractual provisions with existing suppliers must be added at the next contract renewal.

DORA versus NIS2

Both DORA and NIS2 focus on cyber resilience, but they work differently alongside each other. DORA is lex specialis for the financial sector and takes precedence over NIS2 for overlapping obligations. A bank that falls under DORA does not need to separately comply with NIS2 for that overlap.

NIS2 is broader, covering multiple sectors including energy, transport and healthcare. DORA is deeper and more prescriptive for the financial sector. One nuance: ICT suppliers serving financial entities may independently fall under NIS2 regardless of DORA, especially if they also serve other sectors or are independently designated as essential or important. For suppliers, it is therefore important to assess both regulations. A GRC approach in which DORA and NIS2 are managed from a shared framework avoids duplication of effort.

Common misconceptions

"DORA is only for banks." Incorrect. Approximately twenty types of financial entities fall under the regulation, from crypto service providers to crowdfunding platforms.

"DORA is an IT topic." Incorrect. DORA explicitly establishes board-level ultimate responsibility. The board approves the ICT risk management framework and is responsible for its implementation. This touches procurement, continuity planning and crisis management.

"We need to obtain a DORA certification." Incorrect. No DORA certification exists. Compliance is assessed by the supervisor -- DNB or the AFM -- through supervisory conversations and inspections. What you need is evidence: policies, procedures, test results, register data.

"We need to comply with both DORA and NIS2." Incorrect. For financial entities, DORA takes precedence for overlapping obligations. Assess on a per-obligation basis which framework is leading.

How to get started

You do not need to build DORA compliance all at once, but the foundation must be in place. Five steps:

Step 1: Determine whether your organisation is in scope. Financial entity, designated CTPP, or indirect ICT supplier? Don't overlook less obvious licence categories, an AISP or PISP licence under PSD2 classifies your company as a payment institution, putting you directly in scope. Document the scope conclusion in writing.

Step 2: Map your ICT assets and third-party dependencies. Which systems are critical? Which suppliers deliver critical services? Without this overview, you cannot build a risk framework.

Step 3: Assess your current ICT risk management framework. Do you have a documented framework? Are the five pillars covered? Identify the gaps.

Step 4: Address the immediate obligations first. An ICT risk register, an internal incident reporting process with the correct timelines, and a supplier register with minimum contractual requirements.

Step 5: Assign board-level ownership. Someone at board level is responsible for the ICT risk management framework. Document this formally.

Tidal Control supports DORA compliance concretely on the areas where most organisations get stuck:

• ICT risk register: structure and document your risks and control measures in one overview, ready for supervisory conversations.
• Vendor register: Tidal automatically generates a complete vendor register with contractual status and risk classification per supplier — exactly what DNB and AFM expect.
• Tracking controls: monitor the status of your DORA controls and automatically collect evidence through integrations with your existing systems.
• Third-party risk: manage contractual minimum requirements per supplier and keep exit strategies and audit rights up to date.
• Incident management: record classifications and notifications with the correct timelines, so you're not searching for the procedure when an incident occurs.

This way you're not only ready for your first DORA audit, but also for all subsequent reviews, without it becoming a manual project every time.

Not sure where to start?

Take the free Quickscan and find out in five minutes where your organisation stands and what you can tackle first.

Take the free Quickscan →

Frequently asked questions about DORA

What does DORA mean for a small payment institution?

Proportionality applies. Small and non-interconnected investment firms and exempted payment institutions may apply a simplified ICT risk management framework under Article 16. Micro-enterprises also receive additional exemptions. The core obligations (a documented risk framework, an incident reporting process and a supplier register) apply to everyone within scope. The bar is lower in detail, not in scope.

Does DORA also apply to my software company if I supply banks?

If your software company is designated by the ESAs as a CTPP, you fall directly under DORA supervision. If you are not designated, you are not directly subject to DORA. Your customers are, however, obliged to include DORA contractual requirements: exit strategies, audit rights, SLA agreements. You therefore feel DORA indirectly through contractual pressure.

What is the difference between DORA and NIS2?

DORA is specific to the financial sector and takes precedence over NIS2 for financial entities on overlapping obligations. NIS2 is broader: more sectors, less prescriptive. For ICT suppliers serving multiple sectors, both may apply.

How strict are the incident reporting timelines?

Strict. An initial report within 4 hours of classification as a major incident, with a backstop of 24 hours after becoming aware. An intermediate report within 72 hours of the initial notification, and a final report within one month. This requires you to already have an internal classification process running before an incident occurs.

Is there a DORA certification you can obtain?

No. DORA is a legal obligation, not a certification scheme. No DORA certificate exists. You demonstrate compliance through policies, procedures, test results and register data. DNB or the AFM assesses this through supervisory conversations and inspections.