DORA Regulation Explained (2026 Guide)

You already know DORA matters, but the hard part is figuring out what it actually means for your institution. Maybe you are in compliance and trying to translate legal text into workstreams. Maybe you sit in IT, risk, or procurement and suddenly find yourself part of a DORA project that touches contracts, testing, incident reporting, governance, and the Register of Information all at once. This is where many teams get stuck. The regulation sounds clear at a high level, but the day-to-day implications are much messier.

This article is designed to make that simpler. If you have been searching for a practical what is dora explanation without legal overload, you are in the right place. We will walk through what the DORA Act is, who it applies to, the five pillars, what changed after 17 January 2025, and why 2026 is already more about proof than preparation. DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, helping teams turn complex regulatory requirements into structured, manageable workflows.

What DORA actually is

Who needs to care about DORA

The five pillars in plain English

What supervisors typically expect to see under each pillar

What DORA compliance looks like in 2026

Oversight of critical ICT third-party providers and what it changes for you

Common misunderstandings that slow teams down

DORA vs GDPR: what is different, and where teams get confused

How to get started without getting overwhelmed

Frequently Asked Questions

Key Takeaways

Conclusion

What DORA actually is

DORA stands for the digital operational resilience act dora, formally Regulation (EU) 2022/2554. It became applicable on 17 January 2025 and sets a common EU framework for how financial entities manage ICT risk and operational resilience.

Think of it this way: DORA is not only about cybersecurity. It is about whether your institution can keep critical digital operations running, respond to disruption, recover in a controlled way, and demonstrate that this is governed properly. That includes internal systems, third-party ICT providers, reporting processes, testing, and senior management oversight.

The reality is that many people casually call it the “DORA directive,” but DORA is a regulation, not a directive. That matters because EU regulations are directly applicable across member states, although supervisory expectations and implementation details may still vary in practice.

If your team is still trying to place DORA in the bigger picture of operational resilience, it helps to also understand what is digital resilience. DORA is one of the EU’s most important operational resilience frameworks for the financial sector, but the broader business objective is resilience, not paperwork.

Who needs to care about DORA

DORA applies to 20 categories of EU financial entities. That includes banks, insurers, investment firms, payment institutions, electronic money institutions, asset managers, central securities depositories, crowdfunding platforms, and several other regulated entity types.

From a practical standpoint, this means DORA is not just a bank issue. Smaller institutions, niche financial firms, and group structures with multiple regulated entities may all be in scope. If your organization depends on ICT systems, cloud services, outsourced digital operations, or third-party software to deliver regulated services, DORA likely affects you directly.

It also affects functions beyond compliance

One of the biggest surprises for institutions is how cross-functional DORA becomes once implementation starts. Compliance may lead the interpretation, but IT, security, procurement, legal, vendor management, risk, internal audit, and management all typically play a role.

This is one reason DORA projects often stall. The regulation may sit with one team, but the evidence sits everywhere else.

Matevž Rostaher’s background across FinTech, InsurTech, and RegTech is relevant here because DORA work rarely lives in one department. In real institutions, it sits at the intersection of regulation, operations, and technology.

The five pillars in plain English

DORA is often explained through five pillars. That structure is useful because it turns a broad regulation into manageable themes. If you want a deeper section-by-section view, see DORA Pillars Explained: Complete Breakdown (2026).

1. ICT risk management

This is the foundation. Institutions need a structured framework for identifying, assessing, managing, monitoring, and reviewing ICT risk. Under DORA, this means governance, policies, controls, roles, asset visibility, dependency awareness, and business continuity thinking all need to work together.

If you want to go deeper here, start with ict risk management framework dora and ict risk dora.

2. ICT-related incident reporting

Financial entities must detect, classify, manage, and report major ICT-related incidents. This is not just an IT helpdesk issue. It requires escalation paths, decision criteria, documentation quality, and reporting discipline.

In practice, institutions need to know what counts as a reportable incident, who decides, what evidence is required, and how fast teams can coordinate under pressure.

3. Digital operational resilience testing

DORA expects institutions to test their resilience, not simply assume it exists. The type and depth of testing should be proportionate to the institution’s size, risk profile, and complexity. For some firms, this may involve relatively straightforward testing routines. For others, advanced threat-led testing becomes relevant.

What many people overlook is that testing is also about governance maturity. Regulators may look for evidence that test results lead to action, remediation, and board-level visibility where appropriate.

4. ICT third-party risk management

This pillar tends to create the most immediate operational workload. Institutions must maintain oversight of ICT third-party service arrangements, assess concentration and dependency risk, review contracts, and maintain a compliant Register of Information.

Platforms like DORApp streamline the Register of Information process through a structured approach that can include data import, intuitive maintenance, enrichment from public sources, validation against technical rules, and compliant report generation. That does not replace your compliance judgment, but it may reduce manual friction significantly.

5. Information sharing

DORA also supports voluntary information sharing arrangements on cyber threats and vulnerabilities among financial entities, subject to relevant safeguards. This is often the least discussed pillar, but it reflects the broader resilience mindset behind the regulation.

What supervisors typically expect to see under each pillar

Consider this: the five pillars are a useful explanation tool, but supervisors usually review something more concrete. They tend to look for a minimum set of artifacts and operating routines that show the pillar is real inside your institution, not just described in a policy.

This matters in 2026 because the conversation is shifting from “do you have a DORA program” to “can you show it works.” The difference often comes down to documentation plus evidence of operating effectiveness. A document is what you say you do. Operating evidence is what you can prove you actually did, consistently, with approvals, timestamps, results, and remediation.

1. ICT risk management: from a framework on paper to day-to-day control

Under this pillar, teams are typically expected to have a defined ICT risk management framework that is actually used. In practice, supervisors often want to see things like:

A documented ICT risk framework, including roles, governance bodies, risk appetite or tolerances where applicable, and how ICT risk ties into enterprise risk management.

An asset and dependency view that is usable, not theoretical, for example an inventory of key systems, services, and supporting components, plus ownership and criticality.

Evidence of ongoing risk activities, such as periodic risk assessments, control testing results, action plans, and management reporting that shows decisions were made and tracked.

What many people overlook is that the “proof” is often in the routine, not in the framework itself. A quarterly risk report with clear decisions and follow-ups can sometimes be more persuasive than a perfect policy that nobody references.

2. ICT-related incident reporting: clarity under pressure

This pillar usually becomes real when an incident hits and nobody agrees on severity, ownership, or escalation. Supervisors often expect to see:

Incident classification criteria that teams can apply quickly, including what makes an incident “major” in your context and how that decision is recorded.

Escalation paths and on-call or decision processes, including who approves external reporting and how you coordinate between IT, security, risk, and management.

Operating evidence, such as incident tickets, timelines, post-incident reviews, and records showing that lessons learned became tracked improvements.

From a practical standpoint, operating effectiveness here often looks like consistency. Similar incidents should be classified in similar ways, escalated through the same channels, and closed with comparable documentation quality.

3. Digital operational resilience testing: testing that leads to remediation

DORA testing is not only about running tests. It is about using tests to find weaknesses, prioritizing fixes, and showing follow-through. Supervisors often look for:

A risk-based testing plan, including scope, frequency, and who signs off, aligned with your critical services and dependencies.

Documented results and remediation tracking, for example findings, severity, owners, due dates, and closure evidence.

Management visibility, typically in the form of reporting that shows what was tested, what failed, what was fixed, and what risks remain open.

Think of it this way: a test is not “done” when the report is published. It is done when the institution can show remediation decisions, implementation, and verification.

4. ICT third-party risk management: inventory, contracts, and ongoing control

This is the pillar where teams often discover gaps between procurement reality and compliance expectations. Supervisors typically expect to see:

A complete and maintained inventory of ICT third-party service arrangements, connected to critical or important functions and reflected in a compliant Register of Information.

Contract readiness, meaning you can point to key clauses and governance rights that support oversight, including information access and audit-related terms where relevant.

Evidence of ongoing oversight, such as periodic reviews, performance and risk monitoring, concentration risk discussions, and documented decisions when issues arise.

The reality is that the register itself is only part of the story. Supervisors may also look at how quickly your institution can answer basic questions like which services depend on a given provider, who owns the relationship, and what happens if the service fails.

5. Information sharing: governed participation, not ad hoc forwarding

Because this pillar is voluntary and less operationalized in many firms, expectations vary. Still, if you participate, supervisors may expect:

Defined governance for what you share, with whom, and under which safeguards, including internal approval and classification rules.

Clear roles and accountability, so information sharing is coordinated and does not conflict with confidentiality or security practices.

Evidence of use, meaning records that shared intelligence is actually reviewed and may inform defensive actions or risk updates.

Now, when it comes to the “year of proof” idea, a helpful self-check is simple: for each pillar, can you show both the policy and recent operating evidence, without scrambling across inboxes, spreadsheets, and untraceable versions?

What DORA compliance looks like in 2026

Here is the thing: 2025 was about getting into position. 2026 is shaping up as the year of proof. Supervisors are less interested in whether you have heard of DORA and more interested in whether your institution can evidence operational control, data quality, governance ownership, and reporting readiness.

The first mandatory Register of Information submission deadline was 30 April 2025, using XBRL for EU-level submissions based on the DORA XBRL Data Point Model. That pushed many institutions to confront a hard truth: spreadsheets may help you start, but they often become fragile once validations, versioning, auditability, and recurring updates enter the picture.

Why regulators are looking more closely now

As currently defined, several 2025 and 2026 developments have raised the bar. The ESAs designated Critical Third-Party Providers in November 2025. Delegated Regulation (EU) 2025/532 introduced deeper subcontracting risk requirements. The ECB finalized its guide on outsourcing cloud services in July 2025. The European Commission review of DORA scope under Article 58 is also underway.

Under DORA, this means institutions need to keep vendor and subcontracting visibility current, not just produce a one-time filing. No more grace-period mindset. In many cases, regulators are now using automated methods to cross-reference ICT registers across the EU.

What “proof” usually looks like in practice

Proof of compliance usually means being able to show that your controls are operating, your data is maintained, your responsibilities are assigned, and your reporting is reproducible. Audit trails, approval paths, issue remediation, and defensible decisions matter more than polished slide decks.

With features like automated workflows, non-blocking validation, a data model that converts to XBRL, and search across records, DORApp allows compliance teams to start working with imperfect data while steadily improving quality over time. That can be especially useful for institutions that need progress without waiting for a perfect greenfield rebuild.

If you want the policy context behind DORA’s development, DORA European Commission Timeline and History (2026) is a useful companion read.

Oversight of critical ICT third-party providers and what it changes for you

One of the most important shifts that teams are still adapting to is DORA’s oversight framework for certain ICT third-party providers. At a high level, DORA introduces an EU-level oversight mechanism for providers that are designated as “critical.” Exactly how a provider is designated and how oversight plays out can depend on the evolving regulatory framework and the facts of each case, so this is not something to treat as a checklist for legal interpretation. Still, the practical direction for financial entities is already clear.

What many people overlook is that even though oversight sits at EU level, your institution still carries responsibility for managing third-party risk in your own environment. If a provider is critical, it often means your dependency, or the market’s dependency, is significant enough to trigger deeper scrutiny and more formal expectations around transparency and control.

How “critical provider” oversight changes third-party management day to day

In most institutions, third-party risk management already exists, but DORA tends to raise the bar in a few specific areas:

Stronger dependency mapping: being able to connect ICT services to business functions, critical or important functions, internal systems, and upstream or downstream dependencies.

More subcontractor visibility: understanding where material parts of your service are subcontracted and being able to keep that picture current over time.

Concentration risk conversations: not just “how big is the provider,” but “how concentrated is this dependency across our critical services, and what is our realistic exit or substitution path if conditions change.”

Contract readiness for information and audit-related requests: being prepared to respond to requests for information, evidence, and oversight support that can arise from supervisory attention, while still managing confidentiality and operational constraints.

The difference often comes down to whether you can answer these questions quickly and defensibly. If your service owners, procurement, vendor managers, and ICT or security teams each hold a different version of the truth, oversight pressure will expose that gap fast.

What to operationalize so data stays current

A common failure mode is treating third-party data as a one-time “Register of Information project” rather than an operating process. In practice, teams often need a simple operating model that keeps information fresh:

Procurement captures baseline data at onboarding and renewal, including service scope, contracting entity, and key subcontracting disclosures where available.

Vendor management maintains the relationship view, including contacts, performance discussions, and changes to the service that could affect criticality.

ICT and security maintain the technical dependency view, including integrations, authentication paths, data flows, and operational monitoring inputs that may affect incident response and testing.

From a practical standpoint, the goal is not perfection. The goal is a repeatable update cycle with ownership, so your register and supporting evidence can keep pace with real vendor changes without a quarterly scramble.

Common misunderstandings that slow teams down

DORA is not only a cybersecurity project

This is probably the most common misconception. Cybersecurity is part of DORA, but the regulation is broader. Governance, operational continuity, reporting discipline, third-party oversight, and resilience testing all sit within scope.

DORA is not the same as NIS2

Teams often confuse these frameworks because both deal with resilience and cyber risk. They do overlap, but they are not interchangeable. If your institution is trying to separate these obligations clearly, read dora nis2.

The Register of Information is not just a vendor list

The Register of Information is a structured regulatory record of ICT third-party service arrangements. It requires depth, consistency, and traceable relationships between data points. That is why many institutions underestimate the operational effort involved until they begin mapping services, providers, functions, contracts, and dependencies.

Compliance is not the same as resilience

You can complete templates and still have weak operational resilience. The strongest institutions are using DORA as a forcing mechanism to improve real operational control, not merely to satisfy a filing requirement.

DORA vs GDPR: what is different, and where teams get confused

DORA and GDPR often come up in the same conversations because both touch security, incidents, and operational discipline. The reality is they are different frameworks with different goals, and you usually cannot treat one as a substitute for the other.

At a high level, DORA focuses on ICT risk and operational resilience for financial entities. It asks whether you can prevent, withstand, respond to, and recover from ICT-related disruption across your critical operations, including third parties. GDPR focuses on personal data protection and lawful processing. It asks whether you process personal data in a compliant way and protect data subjects’ rights, supported by appropriate technical and organizational measures.

Where they touch

There is overlap in the sense that both can push you toward stronger security practices, clearer governance, and better documentation. They also touch in incident handling. An ICT incident could be relevant for DORA reporting even if it does not involve personal data. A personal data breach can trigger GDPR considerations even if it is operationally small in broader ICT terms.

Common confusion point: incident reporting and breach notification

Teams sometimes assume that one incident playbook covers everything. In practice, you may need parallel triage paths:

A DORA-oriented incident classification and reporting workflow that determines whether an ICT incident is “major” and how it is reported through the required channels.

A GDPR-oriented personal data breach assessment workflow that determines whether there is a breach of personal data, what the risk is to individuals, and whether notifications may be required.

Think of it this way: the same event can trigger two different internal assessments, with different thresholds, different stakeholders, and different reporting outputs. That does not mean duplicating work unnecessarily. It usually means aligning definitions, handoffs, and documentation so the institution can act quickly without confusion.

Practical takeaway: get the right people in the room early

For most financial entities, a workable approach is to align security, ICT risk, compliance, and the DPO or legal stakeholders on a shared triage process. The goal is clarity on who decides what, what evidence is captured, and how internal reporting thresholds map across frameworks. Since regulatory obligations can vary by jurisdiction and facts, it is typically worth validating your approach with qualified legal and compliance professionals rather than assuming a single framework “covers” the other.

How to get started without getting overwhelmed

If DORA still feels too big, that is normal. The regulation spans multiple teams, systems, and governance layers. The best starting point is usually not “do everything at once.” It is “get control of the foundations first.”

Start with a realistic sequence

Confirm which legal entities and business lines are in scope.

Map your core ICT dependencies and third-party arrangements.

Assess the current state of policies, risk processes, and reporting paths.

Identify where evidence already exists and where it is missing.

Decide which areas need process design, tooling, or both.

For many institutions, the Register of Information becomes the most concrete starting point because it forces cross-functional visibility. From there, you can build stronger incident management, risk governance, and testing discipline around actual dependencies rather than assumptions.

DORApp is one platform worth exploring if your institution wants a modular path. Verified product information shows DORApp includes modules for Register of Information, Third-Party Risk Management, Incident Management, Risk Management and Governance, and Information and Intelligence Sharing, with a 14-day free trial available at https://dorapp.eu/create-account/. You can also explore the broader DORA Fundamentals category for related explainers.

Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.

Regulatory note: This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. DORA compliance requirements may vary based on your institution type, size, and national regulatory framework. Content referencing regulated industries is provided for general context only and should not be interpreted as legal, regulatory, compliance, or financial advice. If you operate in a regulated sector, always consult qualified financial, legal, and compliance professionals for guidance specific to your situation.

Frequently Asked Questions

What is DORA in simple terms?

DORA is an EU regulation for financial entities that sets rules for managing ICT risk and operational resilience. In simple terms, it asks whether your institution can keep critical digital operations running, respond to disruptions, recover effectively, and prove that these processes are governed properly. It covers much more than cybersecurity alone. It also includes incident reporting, resilience testing, third-party risk oversight, and information sharing. For most institutions, DORA becomes a practical operating framework, not just a legal text.

Is DORA a regulation or a directive?

DORA is a regulation, not a directive. Its full name is the Digital Operational Resilience Act, Regulation (EU) 2022/2554. This matters because regulations apply directly across the EU, while directives generally need national transposition into local law. That said, institutions still need to pay attention to local supervisory practice and evolving guidance. Even with a directly applicable regulation, the way evidence is reviewed or expectations are emphasized may vary somewhat by competent authority and institution type.

Who does DORA apply to?

DORA applies to 20 categories of EU financial entities. This includes banks, insurers, payment institutions, investment firms, asset managers, and other regulated financial organizations. It is not limited to large institutions. Smaller firms and specialized regulated entities may also be in scope. The regulation also has practical implications for ICT third-party providers that support these institutions, especially where critical or important functions are involved. If your organization relies heavily on outsourced ICT services to deliver regulated activities, DORA likely deserves close attention.

When did DORA become applicable?

DORA became applicable on 17 January 2025. That was the point when financial entities were expected to be compliant with the regulation’s requirements, based on the framework and technical standards available at the time. Since then, the focus has shifted. In 2026, many institutions are no longer asking what DORA is, but how to demonstrate compliance in a repeatable, defensible way. That is why audit trails, data quality, workflow evidence, and third-party oversight processes are becoming more important in supervisory conversations.

What are the five pillars of DORA?

The five pillars are ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. These pillars help organize the regulation into practical work areas. Most institutions do not implement them in isolation. They are connected. For example, your third-party dependency mapping affects your incident response, your testing priorities, and your risk assessments. That is why DORA programs often work best when they are treated as operational systems of governance rather than as separate compliance documents.

What is the Register of Information under DORA?

The Register of Information is a mandatory structured record of ICT third-party service arrangements maintained by DORA-regulated financial entities. It is much more detailed than a simple supplier spreadsheet. It typically requires institutions to track provider information, contractual relationships, dependencies, criticality, and service-related details in a consistent format. For EU-level submissions, the reporting format uses XBRL based on the DORA XBRL Data Point Model. Many institutions discover that maintaining the register on an ongoing basis is a larger operational task than they first expected.

How is DORA different from NIS2?

DORA and NIS2 both address resilience and cyber-related risk, but they serve different regulatory purposes. DORA is tailored specifically to the financial sector and creates a detailed operational resilience framework for financial entities. NIS2 is broader and applies across sectors considered important or essential. There may be overlap in controls, governance themes, and incident management expectations, but institutions should not assume that satisfying one framework automatically satisfies the other. Mapping common controls can help, but the regulatory logic and reporting expectations are not identical.

What changed in 2026 for DORA compliance?

The biggest change in 2026 is the shift from initial readiness to demonstrable, ongoing compliance. Supervisors are increasingly focused on evidence quality, recurring control operation, and data consistency across reporting cycles. The designation of Critical Third-Party Providers in late 2025, deeper subcontracting expectations under Delegated Regulation (EU) 2025/532, and more mature regulatory scrutiny all contribute to this shift. In practice, institutions may need stronger governance records, better vendor data, and more reliable ways to reproduce regulatory outputs without last-minute remediation.

Can a tool make an institution DORA compliant?

No tool by itself can make an institution compliant. DORA is a regulatory and operational responsibility that depends on governance, decision-making, controls, evidence, and institution-specific interpretation. A platform can support the process by improving structure, traceability, validation, reporting, and workflow management. That can save time and reduce manual error, but it does not replace legal interpretation or management accountability. If you are evaluating software in this area, the right question is usually not “will this make us compliant?” but “will this help us operate compliance more effectively?”

What are the 5 principles of DORA?

DORA is commonly structured around five core pillars, which are often treated as the practical principles teams organize around: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. In most institutions, the “principle” is not only having a policy for each pillar, it is being able to evidence that the process operates, produces results, and leads to tracked remediation where needed.

What are the 7 key principles of operational resilience?

Different regulators and industry groups use slightly different language, but operational resilience programs are often built around a consistent set of themes. A practical set of seven principles many teams use as a working model is: identify critical services, map dependencies, set impact tolerances, implement preventative and detective controls, prepare response and recovery plans, test regularly (including scenario-based testing), and learn and improve through remediation and governance oversight. DORA aligns with these ideas for the financial sector, but your exact approach and terminology typically depends on your institution type and supervisory expectations.

How is DORA different from GDPR?

DORA focuses on ICT risk and operational resilience for financial entities, including governance, incident handling, testing, and third-party oversight. GDPR focuses on personal data protection and lawful processing. They can overlap in areas like security and incident response, but an ICT incident under DORA is not automatically a GDPR personal data breach, and GDPR compliance does not automatically satisfy DORA obligations. Many institutions use aligned but distinct triage paths so security, risk, and DPO or legal stakeholders can assess the same event under both frameworks where relevant.

Who needs to comply with DORA?

DORA compliance applies to in-scope EU financial entities across 20 categories, including banks, insurers, investment firms, payment institutions, electronic money institutions, and other regulated firms. In practice, it also affects key internal functions such as IT, security, procurement, vendor management, and internal audit because those teams own much of the evidence. ICT third-party providers are not “financial entities” under DORA, but they may still be impacted through contractual requirements, oversight expectations, and information requests from their regulated customers.

Key Takeaways

DORA is Regulation (EU) 2022/2554, applicable since 17 January 2025, and it covers operational resilience across the financial sector.

The five pillars are ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.

In 2026, the focus is increasingly on proof of compliance, evidence quality, and repeatable operational control.

The Register of Information is a core operational requirement, not just an administrative vendor list.

Tools can support DORA workflows, but they do not replace institution-specific legal, regulatory, or compliance judgment.

Conclusion

If you were looking for a practical DORA regulation explained article, the main point is this: DORA is not just another policy exercise. It is a live operating framework for how financial institutions manage digital dependency, disruption, and accountability. The institutions making the most progress are usually the ones that stop treating DORA as a one-off project and start treating it as an ongoing operational discipline.

You do not need to solve every pillar in one week. You do need a realistic way to build visibility, improve evidence, and keep the work moving across teams. That is where clearer structure, better data, and the right workflows start to matter. If you want to keep learning, browse more articles in DORA Fundamentals or explore how DORApp approaches modular DORA compliance support at https://dorapp.eu/book-demo/. A personalized demo or the 14-day trial may help you see what a more structured approach could look like in practice.