DORA Compliance | The Complete Guide for Financial Firms

What Is DORA Compliance?

DORA compliance means meeting the obligations in the EU's Digital Operational Resilience Act. In plain terms, a regulated financial firm must show it can withstand, respond to, and recover from technology disruptions, and that it controls the risks posed by the outside vendors it relies on. The firm must prove this to a supervisor with documents, test results, and records, not just policies.

DORA in One Paragraph (Regulation (EU) 2022/2554)

DORA is an EU regulation that creates one binding set of ICT risk rules for the financial sector. The EU adopted it in December 2022, it entered into force in January 2023, and it has applied since January 17, 2025. Because it is a regulation rather than a directive, it applies directly in every member state without national transposition, so the core obligations read the same in Frankfurt, Paris, and Dublin. Those obligations fall into five areas: ICT risk management, incident management and reporting, resilience testing, third-party risk management, and information sharing. Supporting regulatory technical standards from the European Supervisory Authorities provide operational detail.

What DORA Stands For, and DORA vs DORA Metrics

DORA stands for the Digital Operational Resilience Act. The acronym also names the DORA metrics, a separate and unrelated DevOps measurement framework from the DevOps Research and Assessment program, now part of Google Cloud. Those metrics track software delivery performance, such as how often a team deploys code and how quickly it recovers from a failed release. They have no legal force and no connection to financial regulation. If your search results mention deployment frequency or lead time for changes, they are about the DevOps framework, not the EU regulation. When someone asks about DORA compliance in a banking, insurance, or fintech context, they mean the regulation.

Why the EU Introduced DORA

The EU introduced DORA because financial services had become dependent on technology and outside providers, while the rules covering that dependence were fragmented and uneven. Before DORA, institutions managed ICT risk through general operational risk requirements and a patchwork of national and sector-specific guidance. Incident reporting formats differed by country and by regulator. Supervisors also had little visibility into concentration risk, which arises when many institutions rely on the same cloud or data provider, so one outage can spread across the sector. DORA emerged from the European Commission's digital finance strategy and aims to harmonize these requirements and give regulators direct oversight of the most critical technology providers.

How DORA Relates to the Broader EU Financial Rulebook

DORA sits atop existing EU financial and data regulation as the sector-specific standard for ICT resilience. It works alongside the NIS2 Directive, which covers cybersecurity across many industries, and DORA takes precedence for financial entities where the two overlap. It also works alongside the GDPR on personal data, the Markets in Crypto-Assets Regulation (MiCA) for crypto-asset providers, and payment rules such as PSD2. These frameworks answer different questions. GDPR asks whether personal data is protected, while DORA asks whether critical financial services keep running. A well-run governance, risk, and compliance program maps one set of controls to all of them instead of building separate stacks. The European Banking Authority, EIOPA, and ESMA draft the technical standards DORA relies on, and national authorities supervise individual firms' compliance.

Who Must Comply With DORA?

DORA applies to most regulated financial entities in the EU, and to the ICT third-party providers that serve them. Firms outside the EU are not directly bound unless they hold an EU authorization. However, many still comply in practice because their EU financial customers must pass DORA obligations down through contracts.

Financial Entities in Scope

Article 2 of the regulation lists 20 categories of financial entity. The best-known are credit institutions (banks), insurance and reinsurance undertakings, investment firms, payment institutions, and electronic money institutions. The list also covers crypto-asset service providers authorized under MiCA, central securities depositories, central counterparties, trading venues, trade repositories, fund managers, credit rating agencies, and crowdfunding service providers. It also includes insurance intermediaries and certain pension institutions. A few small categories are excluded, so check the exemptions in Article 2 against your own license type. If a national or EU authority supervises your firm under financial services law, assume DORA applies until the regulation's text says otherwise.

ICT Third-Party Providers: Cloud, SaaS, Data and Security Vendors

ICT third-party providers supply digital and data services to financial entities, including cloud platforms, SaaS applications, data analytics, hosting, software, and managed security services. DORA does not directly regulate most of them. Obligations reach them through the contracts and due diligence financial entities must carry out. The exception is a small group of providers the European Supervisory Authorities designate as critical ICT third-party providers (CTPPs). Those providers fall under direct EU oversight, with a Lead Overseer able to inspect them and recommend changes. The regulation also allows periodic penalty payments of up to 1% of a provider's average daily worldwide turnover, for up to six months, if a CTPP fails to cooperate. A provider designated as critical that is established outside the EU must also set up an EU subsidiary.

Does DORA Apply Outside the EU?

DORA applies directly to firms authorized or registered in the EU, not to a company based on its headquarters location. A UK, Gulf, or US firm with no EU-authorized entity is not itself a regulated "financial entity" under the regulation. Three routes still pull non-EU firms in:

• EU subsidiaries or branches. If you operate an EU-authorized entity, that entity is in scope, and group-level controls often need to support it.

• Service provision to EU financial entities. A non-EU cloud, SaaS, or security vendor selling to EU banks, insurers, or crypto firms must accept DORA-driven contract terms. If designated critical, it faces direct oversight.

• EU market access. A crypto or payments firm that wants an EU license must meet DORA as a condition of operating there.

A GCC-based provider such as a VARA-licensed exchange or a Dubai fintech does not become subject to DORA just because it has one European client. But the contract clauses and security evidence that client requests will follow the DORA framework.

Proportionality: How Obligations Scale for Smaller Entities

DORA applies a proportionality principle, so the depth of required controls scales with an entity's size, risk profile, and the nature and complexity of its services. Microenterprises and certain small, non-interconnected firms can follow a simplified ICT risk management framework instead of the full one. The most demanding testing requirement, threat-led penetration testing (TLPT), applies only to entities that authorities identify as significant and mature enough to need it. Proportionality reduces the scale of the work. It does not remove obligations such as incident reporting, third-party oversight, or maintaining an information register. Document how you assessed your own proportionality, because supervisors expect a reasoned position.

Fintech and SaaS Companies: How DORA Reaches You Through Customer Contracts

For a fintech or SaaS company that sells to EU financial entities, DORA arrives as a procurement requirement. Article 30 requires financial entities to include specific provisions in agreements with ICT providers. These cover service descriptions, data location and protection, incident assistance, audit and access rights, subcontracting terms, and exit and termination arrangements. For services supporting critical functions, the requirements go further. In practice, you may receive a DORA addendum or a detailed questionnaire before renewal. Providers that can answer it with evidence, such as a mapped control set, a tested incident process, a clear subcontractor list, and defined recovery objectives, close deals faster. Those that can't often get blocked by the customer's compliance team.

DORA Compliance Deadline and Timeline

The DORA compliance deadline has already passed. The regulation has applied to in-scope financial entities since January 17, 2025, so firms are now expected to operate under it, not prepare for it. Supervision has moved from preparation to active oversight.

Entry into Force vs Date of Application (17 January 2025)

DORA has two dates, and mixing them up is the most common timeline error. The regulation entered into force in January 2023, starting the clock but creating no operational duties. It became applicable on January 17, 2025, which is the date firms had to comply. The two-year gap gave the European Supervisory Authorities time to finalize detailed technical standards on incident classification, third-party contracts, and testing. It gave firms time to build programs around them. When a customer, auditor, or regulator asks whether you are DORA compliant, they mean the January 2025 date. A statement like "we're preparing for DORA" no longer holds up in a supervisory conversation or a vendor review.

What Regulators Expect Now

Three expectations stand out for firms in scope.

Supervision. National competent authorities supervise individual financial entities and can request evidence of ICT risk governance, incident handling, and third-party controls. Expect questions on board accountability, tested recovery capabilities, and whether your incident classification process works in practice.

Register of information. Financial entities must maintain a register of all contractual arrangements with ICT third-party providers, including subcontractors that support critical functions, and keep it current at entity and consolidated levels. This register is not just paperwork. According to the ESAs, it was the data source for designating critical providers. On November 18, 2025, they published a list of 19 critical ICT third-party providers, including hyperscale cloud, data center, and network providers, which now face direct EU oversight. That list is updated annually. An inaccurate register weakens your compliance position and can delay customer due diligence.

TLPT scheduling. Authorities must carry out threat-led penetration testing, generally at least every three years. Authorities decide who is in scope, so check with your supervisor and plan early, because scoping, threat intelligence, and testing can take months and require coordination with your critical providers.

The Five Pillars of DORA Compliance

DORA compliance rests on five pillars: ICT risk management, incident management and reporting, resilience testing, third-party risk management, and information sharing. Each maps to a chapter of Regulation (EU) 2022/2554, and together they cover the full cycle of preventing, detecting, responding to, and learning from technology disruption.

ICT Risk Management and Governance (Board Accountability)

The ICT risk management pillar requires financial entities to maintain a documented framework to identify, protect against, detect, respond to, and recover from ICT risks. It places responsibility for that framework on the management body. Boards cannot delegate accountability to the IT department. They must approve the digital resilience strategy, set risk tolerance, oversee implementation, and keep enough ICT knowledge to challenge what they are told. In practice, the framework covers asset inventories, access and change controls, monitoring, backup and recovery, business continuity, and lessons learned after incidents. A supervisor reviewing this pillar will usually ask for board minutes, risk appetite statements, and evidence that the framework is reviewed after major events, not just a policy binder.

ICT Incident Management, Classification and Reporting

DORA requires firms to run a consistent incident response process: detect, classify by severity, and report major incidents to the competent authority on a fixed schedule. Under the associated technical standards, the staged timeline for a major incident is an initial notification within four hours of classifying it as major (and no later than 24 hours after becoming aware of it), an intermediate report within 72 hours of the initial notice, and a final report within one month once root cause is established. Firms may also voluntarily report significant cyber threats, and they must notify clients when a major incident affects their financial interests. The common failure here is classification. Teams that cannot judge quickly whether an incident meets the "major" thresholds, which consider clients affected, duration, data loss, and geographic spread, lose the first hours the schedule depends on.

Digital Operational Resilience Testing

The testing pillar requires firms to test their resilience on a recurring, risk-based basis, not only after an incident or before an audit. All in-scope entities must run a testing program that may include vulnerability assessments, scenario-based tests, network security assessments, and, where feasible, source code reviews, with critical systems tested at least annually. A smaller group of significant entities must also run threat-led penetration testing (TLPT), a realistic, intelligence-driven attack simulation on live production systems, at least every three years. The firm must track findings to remediation and show it fixed what the tests revealed. A scan report alone doesn't satisfy this pillar.

ICT Third-Party Risk Management and the Register of Information

This pillar treats outsourcing as a risk the financial entity cannot hand off. Firms must assess providers before signing, include mandatory provisions in contracts, monitor performance, and plan exit strategies for services that support critical functions. They must also keep a register of information covering every ICT third-party arrangement, including subcontractors where relevant. That register has real consequences, since the European Supervisory Authorities used firms' submitted registers to identify the 19 critical providers they designated in November 2025. Because this pillar creates the contract demands that reach vendors, it also affects non-EU technology providers most directly.

Information and Intelligence Sharing

The final pillar is the lightest, because it is voluntary. DORA allows financial entities to exchange cyber threat information and intelligence, such as indicators of compromise, tactics, & mitigation strategies, within trusted communities. Sharing must improve digital operational resilience, protect the confidentiality of business and personal data, and comply with competition law, and firms must notify their authorities when they participate. It matters less as a compliance box than as a practical advantage, since firms that receive early indicators from peers can detect and block attacks sooner.

DORA Compliance Requirements Checklist

A DORA compliance checklist turns the regulation's five pillars into concrete requirements, each paired with the evidence a supervisor or customer will ask to see and a named internal owner. Use it as a working control list, not a one-time audit, because regulators judge DORA compliance by what you can demonstrate, not by what your policies say.

Checklist Table: Requirement, DORA Area, Evidence, Owner

Checklist Variants: Banks vs Insurers vs SaaS Providers

The core requirements are the same across firm types, but the emphasis shifts with each firm's legal position under DORA.

SaaS providers should treat this column as their own checklist: a subcontractor list, a defined incident notification timeline, audit and access terms, documented recovery objectives, and exit assistance.

Template and Spreadsheet Structure

To build your own tracker, use one row per requirement and a consistent set of columns. Start with a unique ID, the requirement description, the DORA pillar, and the relevant article reference. Add the control or policy that satisfies it, the current status (not started, in progress, implemented, or tested), and the evidence location, such as a document link or system export. Then add the accountable owner, the last review date, the next review date, and a gap or remediation note. A final column for linked third parties is useful if you also use the sheet to feed your register of information. Keep evidence as links to the source rather than copies, so the tracker stays current, and add a separate tab for open findings from tests and incidents so remediation gets its own history.

How to Build a DORA Compliance Program, Step by Step

Building a DORA compliance program takes six steps, in this order: scope your entities and critical functions, run a gap assessment, build the information register, update governance and incident documents, renegotiate third-party contracts, then test and remediate on a recurring cycle. The order matters because each step produces the inputs the next one needs.

Step 1: Scope Entities, Services and Critical Functions

Start by deciding which legal entities are in scope and which business services they deliver, because every later decision depends on this. List each regulated entity in the group, confirm which DORA category it falls under, and note whether a simplified framework might apply. Then map the services each entity provides to the ICT systems, data, and providers that support them, and mark which functions are critical. This is the step most teams rush. Scope defined by system ownership rather than business services produces a register and testing plan that don't align with how supervisors think about resilience. Record the reasoning behind each scoping decision, since a supervisor may ask why you classed a function as critical or not.

Step 2: Gap Assessment Against the Requirements

A gap assessment compares your current controls, documents, and evidence against each DORA requirement and records what is missing, outdated, or untested. Work from a requirement-level checklist rather than from a general maturity score, and rate each item on two questions: does the control exist, and can you prove it works? Many firms discover that their weaknesses are in evidence, not in policy. A recovery plan may exist but have no recent test result, or an incident process may exist but not use DORA's classification thresholds. Prioritize gaps by regulatory exposure and effort. The register of information, incident reporting readiness, and third-party contract terms usually carry both the highest exposure and the longest lead time.

Step 3: Build the Register of Information

The register of information is a structured record of every contractual arrangement for ICT services, including the providers, the services, the entities using them, and the subcontractors behind them. Regulators publish standard templates, such as B_04.01 for entities using ICT services, B_05.01 for direct providers and subcontractors, and B_07.01 for assessing services that support critical functions, so you don't have to design the format yourself. Build it by pulling data from procurement, finance, and IT asset records, then reconciling those sources, because no single system holds a complete picture. Assign one owner and a defined update trigger, such as a new contract, a renewal, or a subcontractor change, so the register stays accurate between submissions. A stale register is both a compliance and due-diligence problem.

Step 4: Update Policies, Incident Playbooks and Board Reporting

With scope and gaps defined, update the documents that show governance in action. Revise the ICT risk management framework and information security policy so they reflect DORA's structure. Rewrite incident playbooks around DORA's classification criteria and reporting stages, and assign named people to the initial, intermediate, and final reports. Set up board reporting that covers ICT risk posture, test results, major incidents, and third-party concentration, at a regular cadence. The aim is a visible decision trail. When a supervisor asks how the management body oversees ICT risk, you should be able to show agendas, papers, and minutes that prove it. Run at least one tabletop exercise on a major incident before you rely on the new playbook.

Step 5: Renegotiate Third-Party Contracts

Contracts with ICT providers must contain the provisions DORA requires, and older agreements rarely do. Review contracts for services that support critical functions first, and check them for service levels, data location and protection, incident assistance, audit and access rights, subcontracting conditions, and exit and termination support. Prepare a standard DORA addendum to speed up negotiation, and expect pushback from large providers that offer their own standard terms. Where a provider won't agree, document the risk and your mitigation, and consider whether a substitute is realistic. Renegotiation runs on the vendor's timeline, so start early and track each contract's status in the register.

Step 6: Test, Remediate, Repeat

Run the testing program on a defined schedule, track every finding to closure, and feed the results back into the risk framework. That means recurring vulnerability and scenario tests, annual coverage of critical systems, and threat-led penetration testing if your authority identifies you for it. Treat remediation as part of the test, not a separate project. A findings register with owners, due dates, and closure evidence is what shows a supervisor that testing changes outcomes. Repeat the cycle whenever your environment changes materially, such as after a migration, an acquisition, or a new critical provider.

Continuous Compliance and Automation: What Can and Can't Be Automated

Automation can reduce the effort of staying compliant, but it cannot replace accountability. Tools can reliably collect evidence from cloud and identity systems, monitor control status, flag out-of-date register fields, track remediation deadlines, and produce incident report templates from logged data. They cannot decide whether a function is critical, judge whether an incident is major, accept a risk on behalf of the board, negotiate a contract, or substitute for a threat-led penetration test. Use automation to keep the evidence current, and keep people responsible for the judgments. A useful test is to ask who would answer a supervisor's question if the tool disappeared. If nobody could, the process depends too heavily on the tool.

Technical Controls Behind DORA Compliance

DORA compliance does not hand firms a fixed technical checklist. It requires controls proportionate to the risk, documented and provable, with detail in Articles 9 to 12 and 24 to 26 of the regulation and its technical standards. In practice, supervisors look for eight control areas: access, data protection, monitoring, testing, DDoS resilience, threat-led testing, software supply chain transparency, and recovery architecture.

Access Controls and Identity Management

DORA expects firms to limit access to ICT systems and data to what each role needs, and to prove it. That means least-privilege permissions, strong authentication for administrative and remote access, tighter controls on privileged accounts, and logging of who did what. The ICT risk management framework's technical standards require reviewing and removing access rights when roles change. Regulators ask for operational evidence: access-review records, joiner-mover-leaver logs, and privileged-access reports. A strong policy with no review history is a common weak point. Service accounts and third-party access deserve extra attention, because they often outlast the project that created them.

Data Security and Encryption

Firms must protect data at rest, in transit, and where feasible in use, and they need a documented approach to cryptography and key management. DORA does not name specific algorithms, so the standard is a defensible policy that matches data sensitivity and risk. A useful policy covers which data classes need encryption, how keys are generated, stored, rotated, and retired, and who can access them. Firms most often fail in key management because encryption is easy to enable but hard to govern. Data location also matters, because contracts with providers must address where data is processed and stored.

Network Visibility and Monitoring

DORA requires detection. Firms need mechanisms to spot anomalous activity, including logging with enough detail to reconstruct an incident, monitoring across network and application layers, and alerting that reaches people who can act. Network segmentation supports this by limiting how far an attacker can move and by making unusual traffic easier to see. The test of this control is incident reconstruction. If your logs can't show what happened, when, and which systems were affected, you will struggle to classify an incident within the reporting timelines or to write a credible final report.

Vulnerability Scanning vs. Penetration Testing Under DORA

Vulnerability scanning and penetration testing answer different questions, and DORA expects both. Scanning finds known weaknesses across many assets quickly and runs on a regular schedule. Penetration testing has skilled testers attempt to exploit weaknesses and chain them together, which shows what an attacker could actually reach. The regulation's testing article lists vulnerability assessments, network security assessments, scenario-based tests, and, where feasible, source code reviews, so a scan report alone does not demonstrate a mature testing program. Treat scanning as the baseline, targeted penetration tests as the validation layer, and track every result to closure through vulnerability management.

DDoS Resilience Testing Expectations

DORA does not mandate a test called "DDoS test", so the expectation comes through its general requirements: resilience of critical systems, performance and scenario testing, and monitoring that detects service degradation. For a payments platform or trading venue, a distributed denial-of-service attack is a realistic scenario for those tests. The practical approach is to include DDoS in scenario planning, confirm mitigation with your network or cloud provider, and test failover and communication procedures. Check what your provider's contract permits, because many prohibit unannounced load testing against shared infrastructure.

Threat-Led Penetration Testing (TLPT): Who Must Do It and How Often

TLPT is a realistic attack simulation, driven by current threat intelligence, run against live production systems that support critical functions. Authorities require it only for financial entities they identify as significant, based on factors such as impact, systemic importance, and ICT maturity. Under Article 26, those entities must run it at least every three years, although authorities can adjust the frequency. The process follows the TIBER-EU framework, with defined scoping, threat intelligence, red team vs penetration testing, and remediation. Entities should check with their supervisor early, as the preparation, including coordination with critical providers whose systems are in scope, takes considerable time.

SBOM and Software Supply Chain Transparency

DORA does not require a software bill of materials by name. But firms must know what software and components they depend on, manage third-party risk, and review code where feasible, and an SBOM is a practical way to provide that evidence. It lets you answer quickly when a vulnerable library is disclosed: which systems contain it, and who owns the fix. For vendors, an SBOM often becomes part of the evidence pack that EU financial customers request. Keep it current and tied to your asset inventory, because a stale SBOM creates false confidence.

Resilience Architecture: Backup, Failover and Recovery Objectives

Firms must maintain backup and recovery arrangements and define recovery objectives for the functions that matter most. In practice, that means setting a recovery time objective and a recovery point objective for each critical function, protecting backups from tampering, ensuring they're restorable, and designing failover to match those objectives. Regulators expect proof, so run recovery tests and keep the results. A backup that has never been restored is an assumption, not a control. Also test dependencies, such as identity services and third-party platforms recovery relies on, since many recovery plans fail because a dependency is missing.

DORA Third-Party and Contract Requirements

DORA requires financial entities to include specific protections in every ICT services contract, with stricter terms when the service supports a critical function. Article 30 sets those terms in two tiers. Beyond the clauses themselves, firms must assess concentration risk and keep a tested exit strategy for each critical arrangement.

Mandatory Contractual Provisions (the Article 30 Clauses in Plain English)

Article 30 splits contract terms into a baseline that applies to all ICT services and an extended set for services supporting critical functions.

The baseline requires that every contract do the following:

• Describe the services clearly, including whether subcontracting is allowed and under what conditions.

• State where services are performed and data is processed, with notice of any change.

• Cover the availability, integrity, confidentiality, and protection of data, including personal data.

• Ensure the financial entity can access, recover, and restore its data if the provider fails, is wound down, or the contract ends.

• Include service level descriptions.

• Require the provider to help with ICT incidents, either at no extra cost or at an agreed upfront price.

• Require cooperation with the financial entity's supervisors.

• Set termination rights and notice periods.

• Require the provider to take part in the entity's security awareness and resilience training where appropriate.

For critical functions, the contract must add the following:

• Precise quantitative and qualitative performance targets.

• Provider notice and reporting duties.

• Business contingency plans that are tested.

• Cooperation with threat-led penetration testing.

• Unrestricted rights of access, inspection, and audit for the financial entity and its authorities.

• Exit strategies with a mandatory transition period.

The most contested negotiation items are usually audit rights, subcontractor transparency, and the exit period. Large providers often offer certifications or pooled audits instead of direct inspection, and the financial entity must justify to its supervisor whether that satisfies the clause.

Cloud and Shared-Responsibility Considerations

DORA does not accept the shared-responsibility model as a reason to treat cloud security as the provider's problem. The financial entity stays fully responsible for meeting the regulation, even when the provider operates the infrastructure. Contracts therefore need to clearly state which party handles each control, such as encryption key management, logging, backups, patching, and incident notification. Gaps appear at the edges. A provider may secure the platform, while the customer assumes it also handles backup retention or log access, and neither side finds out until an incident. Map each responsibility in writing, confirm you can retrieve logs and data in a usable form, and check where data and support staff are located. The same applies to SaaS products built on top of a hyperscale cloud, because your provider's provider becomes part of your risk chain.

Concentration Risk and Exit Strategies

Concentration risk arises when too many critical functions depend on one provider, or when providers depend on the same underlying infrastructure. Article 29 requires financial entities to assess this before signing contracts for critical functions. They must consider whether the provider is easily substitutable, whether several contracts lead to the same subcontractor, and whether one provider supports multiple critical functions. Exit strategies are the counterpart. For each critical arrangement, the entity needs a documented, realistic plan to move to another provider or bring the service in-house without disrupting operations, including data migration, a transition period, and roles for the outgoing provider. An exit plan that has never been tested, or that assumes unlimited migration time, will not hold up under supervisory review. For deeply embedded services, the honest answer is sometimes that exit takes years, and the plan should say so and describe interim mitigations.

How SaaS Vendors Should Respond to DORA Questionnaires and Position Themselves to EU Customers

SaaS vendors win or lose EU financial customers on how well they answer DORA due diligence. Prepare a reusable evidence pack instead of answering each questionnaire from scratch. It should include the following:

• A mapping of your controls to DORA's requirements.

• A subcontractor and data location list.

• Your incident notification process and timelines.

• Recovery objectives with recent test results.

• Your audit and access terms.

• A documented exit and data return process.

Make sure answers match across customers and across your own documents, because inconsistency is a red flag for a buyer's vendor risk team. Offer a standard DORA addendum that already covers the Article 30 clauses to shorten negotiations. Be direct about limits, such as audit rights you can't grant on multi-tenant infrastructure, and offer a workable alternative like third-party reports or a structured audit process. For a non-EU vendor, such as a Gulf or US provider, state clearly where your data is processed and which legal regimes apply, since customers must assess that risk. Don't claim a "DORA certified" status, because no official certification exists. Show controls and evidence instead.

DORA Penalties and Enforcement

DORA does not set a single EU-wide fine schedule for financial entities. Each member state decides the administrative penalties and remedial measures its authorities can impose, while the European Supervisory Authorities (ESAs) directly oversee critical ICT third-party providers. For most firms, the practical exposure is a mix of supervisory action, public disclosure, and commercial fallout.

How Penalties Work: Set by Member States, Not One EU-Wide Fine Table

DORA requires every member state to give its competent authorities the powers to investigate, supervise, and sanction breaches. It leaves penalty levels and procedures to national law, so you won't find a single headline percentage for non-compliance, as GDPR does. A firm's exposure depends on its home regulator and the national rules that implement DORA. Authorities can typically order a firm to fix a deficiency, restrict or require changes to its activities, and impose administrative fines. Member states may also apply criminal penalties, and national rules can address the liability of individual management body members. DORA also requires publishing certain penalties, making enforcement public. For compliance planning, treat each country's national implementing law as a requirement and track it alongside the regulation.

Oversight of Critical ICT Third-Party Providers by the European Supervisory Authorities

The EU oversees critical ICT third-party providers (CTPPs) directly, rather than through national authorities. The ESAs designated the first 19 CTPPs on November 18, 2025, and update the list annually. For each CTPP, a Lead Overseer assesses whether the provider has sound risk management, governance, and security arrangements. The Lead Overseer can request information, conduct inspections, and issue recommendations, and ESAs can use joint examination teams that include national supervisors. If a provider fails to cooperate, the Lead Overseer can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover from the previous business year. These can run daily for up to six months. The oversight regime also lets authorities push financial entities to reconsider using a provider that doesn't follow the Lead Overseer's recommendations. This makes CTPP oversight a commercial risk for customers and a compliance matter for the provider.

Non-Financial Consequences: Supervisory Measures, Reputational and Contractual Impact

The fine is rarely the biggest cost of a DORA failure. Supervisory measures can include mandatory remediation plans, closer inspection cycles, and restrictions on new business or outsourcing arrangements, all of which consume management time and constrain growth. A publicly reported failure damages trust with regulators, clients, and counterparties, and a poorly handled incident is remembered longer than the incident itself. Contractual consequences follow too. EU financial customers can ask providers for evidence, trigger audit rights, withhold renewals, or terminate agreements where a provider can't meet DORA terms. For vendors, a failed due diligence review can lose a deal outright, without any regulator being involved. Because national authorities and customers' own exposure shape enforcement, the most reliable protection is evidence that controls work: tested recovery, accurate registers, and well-handled incident reports.

Common DORA Compliance Mistakes

The most common DORA compliance mistakes come from treating the regulation as a documentation project instead of an operational one. Firms that stumble usually have policies in place but lack current registers, tested recovery, accurate vendor data, and evidence that controls work.

Treating DORA as a Policy-Writing Exercise

DORA asks firms to show that controls operate, not that documents exist. A polished ICT risk framework with no review history, board minutes, or incident or test records will not satisfy a supervisor. The fix is to pair every policy with proof of operation: access review logs, recovery test results, tabletop exercise outcomes, and board papers that show real challenge. If a requirement has a policy but no evidence, treat it as a gap.

Incomplete or Stale Register of Information

A register that was accurate at submission and never updated is one of the easiest weaknesses for a supervisor to find. Registers go stale when procurement or IT changes contracts, renewals, or subcontractors without anyone updating the record. They are also often incomplete from the start, because no single system holds all ICT arrangements. Assign one owner, define update triggers, and reconcile procurement, finance, and asset data on a fixed schedule.

Ignoring Subcontractor Chains

Many firms record their direct providers and stop there. DORA's third-party framework expects visibility into subcontractors that support critical or important functions, because a failure several layers down can still stop your service. A payment platform running on a SaaS product that runs on a niche hosting provider carries the risk of all three. Ask providers for their subcontractor lists, include notice rights for contract changes, and record material subcontractors in the register.

Confusing Vulnerability Scans With TLPT

A vulnerability scan finds known weaknesses across assets, while threat-led penetration testing simulates a realistic, intelligence-driven attack on live systems that support critical functions. Presenting scan reports as TLPT evidence misrepresents your testing maturity. If your authority identifies you for TLPT, the scoping, threat intelligence, and red team stages must follow the required process. Scanning remains necessary, but it supports a testing program and does not replace the advanced test.

No Tested Exit Plan

An exit plan on paper rarely survives contact with a real provider failure. Common flaws include assuming unlimited migration time, assuming the provider will cooperate during a dispute, and never confirming that data can be exported in a usable format. For critical arrangements, test the parts you can: restore data from an export, confirm the transition support in the contract, and document how long a real migration would take. If the honest answer is that exit takes years, say so and describe the interim safeguards.

Vendor Questionnaires Answered Inconsistently Across Customers

For SaaS and ICT providers, inconsistent answers are a quiet deal-killer. When one customer receives a four-hour incident notification commitment and another receives 24 hours, or when your subcontractor list differs between documents, a buyer's vendor risk team will notice. Keep one controlled source of truth for answers, review it before each response, and update it whenever your architecture, subprocessors, or recovery objectives change. Consistency also saves time, since most questionnaires ask the same questions in different words.

DORA vs NIS2, ISO 27001, GDPR and SOC 2

DORA is the binding EU rule for ICT resilience in financial services, while NIS2, GDPR, ISO 27001, and SOC 2 each answer a different question. NIS2 and GDPR are laws with their own scope, and ISO 27001 and SOC 2 are voluntary assurance frameworks. Complying with one does not discharge the others, but a single control set can support all of them.

Comparison Table: Scope, Legal Force, Incident Reporting, Testing, Third-Party Focus

For financial entities, DORA is treated as the sector-specific rule where it overlaps with NIS2, so the financial sector follows DORA for ICT risk and incident reporting rather than running both regimes in parallel. GDPR still applies if personal data is involved, so one event can trigger a DORA report and a GDPR notification on separate clocks to separate authorities.

How an ISO 27001 ISMS Helps but Doesn't Satisfy DORA

An ISO 27001 information security management system gives you a risk-based management structure, defined roles, an asset and risk register, and a catalog of 93 Annex A controls in the 2022 edition. That foundation covers much of DORA's ICT risk management pillar and gives auditors and supervisors a familiar structure to review.

The gaps are in what DORA adds on top. ISO 27001 does not require a register of information on all ICT third-party arrangements in a regulator-defined format. It lacks equivalents of Article 30 contract clauses, concentration risk assessments, or documented exit strategies for critical services. It has no staged major-incident reporting to a financial supervisor, and it has no threat-led penetration testing regime. DORA also places explicit accountability on the management body for ICT risk, which goes beyond the leadership commitment ISO 27001 requires. A certificate shows you run a management system. It does not show you meet DORA's specific obligations. Use your ISMS as the backbone and add DORA-specific controls, evidence, and reporting on top.

For GCC and Web3 Firms: Mapping VARA, CBUAE and ISO 27001 Controls to DORA Obligations

DORA reaches GCC firms only through EU exposure, such as an EU-licensed entity or EU financial customers. Where that exposure exists, existing Gulf compliance work can cover some ground, but it does not replace DORA.

For Web3 firms, the most relevant pull is MiCA. Crypto-asset service providers authorized in the EU fall inside DORA, so a Dubai-based exchange seeking EU authorization needs a DORA-ready program as a condition of entry. The practical approach is to build one control library, map each control to VARA, CBUAE, ISO 27001, and DORA references, and keep evidence once. Map using the actual rulebook text, since requirements differ in wording and what counts as sufficient evidence.

Using AI With DORA: Compliance and Risk

DORA does not regulate AI as a separate category. It is technology-neutral, so any AI system a financial entity uses counts as ICT and falls under the same risk, incident, testing, and third-party rules as other systems. AI also works both ways: it can speed up compliance work and add new ICT risk that must be managed.

AI Tools That Support Compliance Work

AI is most useful in DORA programs where tasks are high-volume and a person can review the output. Common uses include:

• Register of information: extracting provider names, services, dates, and subcontractors from contracts to pre-fill register fields.

• Contract review: comparing agreements against the Article 30 clauses and flagging missing provisions.

• Gap assessments: mapping existing policies and evidence to DORA requirements.

• Incident triage: helping security teams classify events against the major-incident criteria and draft report text.

• Evidence collection: pulling configuration and access data into the compliance tracker.

The limits matter as much as the uses. A model can mislabel a clause, miss a subcontractor, or state a requirement with false confidence, so every output that feeds a regulatory submission needs human review by someone accountable for it. Classifying an incident as major, judging whether a function is critical, and approving a risk acceptance remain decisions for people. Check, too, where the tool processes your data. Sending contracts or incident details to an external AI service can itself create a third-party and data-protection issue.

DORA Obligations When You Deploy AI in Financial Services

When a bank or insurer deploys AI, DORA applies to it as it does to any other ICT asset. The AI system belongs in the asset inventory and in the ICT risk framework, with an owner, defined access controls, monitoring, backup and recovery, and inclusion in resilience testing. Because AI behaviors can degrade without a visible outage, through model drift, bad input data, or manipulated prompts, monitoring should cover output quality and anomalous behavior, not only uptime.

Most AI deployments involve external providers, which makes third-party risk the largest practical exposure. A model API, a hosted AI platform, or an AI feature inside a SaaS product is an ICT service from an ICT third-party provider. That means the register must record it, the contract must include the Article 30 provisions, and you must assess concentration risk if several critical functions depend on the same model vendor. For services supporting critical functions, you also need an exit plan, which is harder for AI than for most software because models, prompts, and fine-tuned data are often tied to one provider. Incident handling extends to AI failures, such as a model producing systematically wrong decisions or a data leak through a prompt, which can meet the criteria for a major incident.

DORA is not the only regulation involved. The EU AI Act sets separate obligations for certain AI uses, including some credit and insurance applications, and the two regimes should be managed together in one control set. This guide covers only DORA's side of AI; for security details on agents, large language models, and AI supply chains, see the dedicated pages on those topics.

Is There a DORA Certification?

No official DORA certification exists. The regulation creates no certificate, seal, or accreditation scheme, and no EU body issues a "DORA compliant" badge. Your supervisor or your customers' due diligence judges compliance based on the evidence you can show.

Why No Official DORA Certificate Exists

DORA is a supervisory regulation, not a certification framework. It sets obligations, and national competent authorities check whether each financial entity meets them through reviews, inspections, and incident follow-up. For critical ICT third-party providers, the European Supervisory Authorities oversee compliance directly. Designation as a critical provider is a regulatory classification that brings oversight, not an endorsement or a pass.

This is why claims like "DORA certified" on a vendor website should raise questions. A company may be DORA-ready, may have mapped its controls to the regulation, or may hold related certifications, but none of those is a regulatory approval. Related certifications such as ISO 27001 or a SOC 2 report show that an independent assessor evaluated a management system or control set. They support a DORA program, but they don't prove DORA compliance because they omit requirements like the information register, Article 30 contract terms, and staged incident reporting to a financial supervisor.

What Evidence to Keep Instead

Since no certificate settles the question, your evidence file is the proof. Keep records that show controls exist, operate, and improve over time. At a minimum, that includes:

• Governance: board-approved resilience strategy, meeting minutes showing ICT risk oversight, and an up-to-date ICT risk management framework.

• Incidents: classification criteria, incident logs, submitted reports, and post-incident reviews.

• Testing: test plans, scan and penetration test reports, TLPT documentation if applicable, and a findings register showing remediation to closure.

• Recovery: defined recovery objectives, restore and failover test results, and business continuity exercise records.

• Third parties: a current information register, due diligence files, signed contracts with the required provisions, subcontractor records, and exit plans.

Store evidence with an owner and a review date, link to source systems instead of copying files, and make sure you can produce any item quickly. Supervisors and enterprise customers often ask for a specific artifact, such as the latest recovery test result, and a slow or missing answer says more than the policy does.

What DORA Certified Specialist Credentials Actually Are(H3)

"DORA certified" professional credentials come from private training providers, consultancies, and professional bodies, not from the EU or its supervisors. They usually certify that a person completed a course or passed an exam on the regulation. That can help build internal knowledge or choose advisors, but the certificate does not authorize anyone to approve a firm's compliance, and no regulator requires it. When evaluating a specialist, look at their practical experience with registers of information, incident reporting, TLPT, and third-party contracts. Also check who issues the credential and what the assessment covered. A firm should never describe itself as certified because its staff hold individual training certificates.

Conclusion

Start your DORA compliance work by scoping your critical functions and building an accurate information register, because every other requirement depends on knowing which services and providers matter most. Then run a gap assessment, close the evidence gaps first, and keep testing and remediation on a fixed cycle. The regulation has applied since January 17, 2025, so supervisors and EU customers will judge you on what you can demonstrate, not on what you plan to do.

If you want help mapping your controls to DORA or preparing your evidence, you can explore Femto Security compliance services.

Frequently Asked Questions (FAQs)

Does DORA apply to non-EU companies?

DORA applies directly to financial entities authorized or registered in the EU, not to a company based on its headquarters location. A non-EU firm is pulled in if it operates an EU-authorized entity, seeks EU authorization, or provides ICT services to EU financial entities. In the last case, the obligations reach it through customer contracts and, if it is designated a critical provider, through direct EU oversight.

Is DORA already in force?

Yes. DORA entered into force in January 2023 & has applied to in-scope financial entities since January 17, 2025. Firms are now expected to operate under it, and supervisors can ask for evidence of working controls.

What is the DORA incident reporting timeline?

For major ICT incidents, firms submit an initial notification within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, & a final report is due within one month once the root cause is known. These reports go to the firm's competent authority.

Does DORA require a penetration test?

DORA requires a risk-based testing program for all in-scope entities, which can include vulnerability assessments, scenario-based tests, network security assessments, and source code reviews, with critical systems tested at least annually. Authorities require threat-led penetration testing (TLPT) only for entities they identify as significant, generally at least every three years. A basic penetration test is common practice, but the regulation does not mandate one for every firm.

Is DORA a directive or a regulation?

DORA is a regulation: Regulation (EU) 2022/2554. Unlike a directive, it applies directly in every EU member state without national transposition, so the core obligations are the same across the EU. National law still matters for penalties and supervisory procedures.

What is the register of information?

The register of information is a structured record of all contractual arrangements a financial entity has for ICT services, including the providers, the services, the entities using them, and relevant subcontractors. Regulators publish standard templates, and the ESAs use firms' submitted registers to identify critical ICT third-party providers. Entities must keep them current at the entity and consolidated levels.

How does DORA affect SaaS vendors?

DORA rarely regulates SaaS vendors directly. It affects them through EU financial customers, who must include specific contract terms, run due diligence, track subcontractors, and plan exits. Expect requests for a DORA addendum, audit and access rights, incident notification commitments, data location details, and recovery objectives. A vendor designated as a critical provider faces direct EU oversight.

How much does DORA compliance cost?

There is no reliable single figure because cost depends on the entity's size, the number of ICT providers and critical functions, the maturity of existing controls, and the size of the gaps. A small firm with a clean ISO 27001 foundation will spend very differently from a group with hundreds of legacy vendor contracts. The most useful way to estimate cost is to run a gap assessment, then price the register build, contract renegotiation, testing, and remediation work separately.