DORA compliance checklist for financial entities

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. If you run a bank, insurer, payment institution, investment firm, crypto-asset service provider, or any of the other financial entities named in the regulation, DORA is now a live supervisory obligation, not a future project. A DORA compliance checklist is the practical bridge between the legal text and the work your teams actually have to do. It turns five abstract pillars into a list of artifacts, controls, and tests that an auditor or competent authority can inspect.

We wrote this checklist as engineers who run the security testing and governance work that DORA demands, not as lawyers reading the recitals. The regulation rewards firms that can show evidence, not firms that can describe intentions. Every item below maps to something you can produce, store, and defend. We also flag where DORA overlaps with frameworks you may already run, so you reuse work instead of duplicating it. For the governance and reporting backbone behind all of this, our GRC services carry most of the load, and the dedicated DORA compliance page covers the regulatory detail in full.

What DORA actually requires

DORA standardizes ICT risk management across the EU financial sector. Before it, each member state and each sub-sector applied its own patchwork of guidance. DORA replaces that with one regulation that applies directly, without national transposition, which is why it bit hard on day one. The regulation is built on five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. A compliant firm has to demonstrate all five with documentation and live evidence.

The scope is broad. DORA names roughly twenty categories of financial entity and applies proportionally based on size and risk profile. Smaller entities get a lighter version of some requirements, but no one is fully exempt from the core obligations. The supervisory teeth come from your national competent authority, which can demand evidence, run inspections, and escalate. Critical ICT third-party providers, including major cloud platforms, fall under a separate EU-level oversight framework, which changes how you negotiate and document those contracts.

The governance and ICT risk management checklist

DORA puts accountability on the management body, not the IT department. The board has to approve the ICT risk framework and stay informed. That is the first thing supervisors check, because it signals whether resilience is a real priority or a delegated afterthought. The risk management pillar then asks for a documented, tested, and maintained framework that covers the full asset and dependency map.

• Confirm the management body has formally approved the ICT risk management framework in writing and reviews it at least annually, with the approval recorded in board minutes that an auditor can read.
• Maintain a complete inventory of ICT assets, business functions, and their dependencies, classified by criticality, because you cannot protect or test what you have not mapped.
• Document protection and prevention controls covering identity, access, network segmentation, encryption, and patching, with named owners for each control area.
• Define detection mechanisms that flag anomalous activity quickly, since DORA expects you to find incidents, not wait for a third party to tell you about them.
• Build and test response and recovery plans, including backup restoration and defined recovery time and recovery point objectives for critical functions.
• Run a learning loop after incidents and tests so findings feed back into the framework, and keep the evidence of that loop because supervisors ask to see it.

Much of this maps cleanly onto an ISO 27001 information security management system. If you already hold or are pursuing certification, you have a head start on the documentation discipline DORA wants. Our ISO 27001 certification guide explains how that structure works, and the regulatory mapping lives on the ISO 27001 compliance page. DORA is more prescriptive about testing and third parties, so treat ISO as the foundation, not the finish line.

The incident reporting checklist

DORA requires a structured process for classifying and reporting major ICT-related incidents to your competent authority within defined timeframes. This is one of the areas where firms get caught out, because the clock starts at detection and the classification criteria are specific. You need the machinery in place before an incident, not improvised during one.

• Define a single incident classification process that applies DORA's criteria for what counts as a major incident, including impact on clients, data, and service availability.
• Set up the reporting workflow to your national competent authority and rehearse the initial, intermediate, and final report stages so the deadlines are met under pressure.
• Establish detection-to-classification timing so you can prove when an incident was identified, which determines when the reporting clock began.
• Maintain a central incident register that records every event, its classification, the decisions taken, and the evidence behind them.
• Run tabletop exercises that walk the whole reporting chain, from analyst to board to regulator, at least once before you ever need it for real.
• Align this process with NIS2 obligations if you also fall under that directive, because the two regimes overlap and you do not want two contradictory playbooks.

Detection capability is the hinge here. You cannot report what you never saw. A mature detection function, whether in-house or delivered as managed detection and response, is what makes the reporting timeline achievable. We wrote about the difference between alert volume and real detection in MDR signal vs noise, which is worth reading if your current monitoring produces dashboards but not decisions.

The resilience testing checklist

This is the pillar where DORA is most explicit, and the one where we spend most of our time. Article 24 onward requires a digital operational resilience testing programme proportionate to your size and risk. Every financial entity has to test ICT tools and systems regularly. Significant entities also have to undergo threat-led penetration testing, known as TLPT, on a multi-year cycle, conducted by qualified testers against live production systems.

• Establish a documented testing programme that defines scope, frequency, methodology, and who is responsible for remediation of findings.
• Run vulnerability assessments and penetration tests on critical ICT systems at least annually, covering networks, applications, and APIs that support important functions.
• Test the systems that support critical or important functions specifically, because DORA cares about the functions clients depend on, not just the easy targets.
• Determine whether you are in scope for threat-led penetration testing, which targets significant entities and follows the TIBER-EU framework using realistic adversary tactics.
• Use threat intelligence and adversary techniques mapped to MITRE ATT&CK so the test reflects how real attackers operate, not a generic checklist scan.
• Track every finding to closure with evidence of remediation and retest, since an unremediated finding from last year is the first thing a supervisor will question.

DORA does not ask whether you have a security policy. It asks whether your defenses survive contact with someone trying to break them.

There is a real difference between an automated scan and an engagement run by people who think like attackers. DORA's testing language, especially TLPT, points firmly at the second kind. If you are unclear on where the line sits, pentest vs scan and PTaaS vs pentest vs automated scanning lay out the trade-offs. Our offensive security work delivers the threat-led testing DORA expects, and for the web and API layer specifically, application security testing covers the OWASP Top 10 and OWASP API Security Top 10 that sit behind most financial services.

The third-party risk checklist

DORA treats your ICT supply chain as part of your own risk surface. The reasoning is sound. A bank that outsources its core systems to a cloud provider has not outsourced the operational risk, it has concentrated it. The regulation requires a register of all ICT third-party arrangements, specific contractual provisions, and active management of concentration risk. Critical providers are supervised directly at EU level, which is new and changes the negotiating dynamic.

• Maintain a register of information covering all contractual arrangements with ICT third-party service providers, in the format competent authorities expect to receive.
• Classify which providers support critical or important functions, because those contracts carry the heaviest DORA requirements.
• Ensure contracts include mandated provisions on access, audit rights, data location, subcontracting limits, exit strategies, and incident cooperation.
• Assess concentration risk so you understand the blast radius if a single provider, often a major cloud platform, suffers an outage or compromise.
• Define and rehearse exit strategies for critical providers so a contract termination does not itself become an operational resilience event.
• Extend your own security testing to the integration points and externally exposed surface, since attackers target the seams between you and your vendors.

The externally facing side of third-party risk deserves continuous attention, not an annual snapshot. Vendor integrations, exposed APIs, and forgotten subdomains drift over time. External attack surface management keeps that picture current, and we go deeper on the topic in external attack surface management. For cloud-heavy estates, identity is usually the quiet weak point, which we covered in cloud IAM quiet risk.

How the five pillars fit together as a process

A checklist can read like five separate workstreams. In practice they form one cycle. You map your assets and dependencies under risk management. You test those assets under the testing pillar. Tests and monitoring feed your detection and incident processes. Incidents and third-party exposures feed back into the risk framework. Information sharing closes the loop by letting you learn from threats hitting peer firms. Treating the pillars as one process is the difference between a binder that satisfies an audit and a programme that actually reduces the chance of a serious outage.

We usually sequence a DORA programme in four phases. First, a gap assessment against all five pillars to find where you stand. Second, governance and documentation work to fix the framework and the registers. Third, the testing programme, including penetration testing and, where applicable, TLPT. Fourth, an operating rhythm that keeps everything current as your systems and vendors change. The first phase is fast. The fourth never ends, because resilience is a steady state, not a project with a closing date.

How DORA relates to NIS2, ISO 27001, and SOC 2

Most regulated firms are not facing DORA alone. The NIS2 Directive, Regulation (EU) 2022/2555, covers a wider set of sectors and overlaps heavily on incident reporting and risk management. Where both apply, DORA generally takes precedence for financial entities as the more specific regime, but the practical controls look similar. We compare the two directly in NIS2 vs DORA, and NIS2 explained covers the directive on its own. The regulatory detail sits on the NIS2 compliance page.

• ISO/IEC 27001:2022, with its 93 Annex A controls across four themes, gives you the management system structure that DORA's risk pillar assumes you already have.
• SOC 2 Trust Services Criteria overlap with DORA on security, availability, and confidentiality, so a clean SOC 2 report supports parts of your DORA evidence, as we discuss in our work on SOC 2 readiness.
• NIS2 and DORA share incident reporting logic, so one well-built classification and reporting workflow can serve both regimes if you design it for the stricter of the two.
• DORA goes further than any of these on mandatory resilience testing and direct oversight of critical ICT providers, which is the gap most firms underestimate.
• Reusing existing certifications cuts DORA effort, but none of them replaces the testing and third-party register work that DORA uniquely demands.

If you are choosing between attestations or stacking them, SOC 2 vs ISO 27001 and SOC 2 readiness are the practical starting points, and the SOC 2 compliance page maps the criteria.

Common mistakes and red flags

We see the same failure patterns across firms preparing for DORA. They are predictable, which means they are avoidable if you know to look for them early.

• Treating DORA as a documentation exercise and producing polished policies with no testing or detection capability behind them, which collapses the moment a supervisor asks for evidence.
• Leaving the management body out of the loop, so the board cannot demonstrate the oversight DORA explicitly requires of it.
• Running automated scans and calling them resilience testing, when DORA's language clearly expects penetration testing and, for significant entities, threat-led testing.
• Keeping an incomplete third-party register that omits the providers behind critical functions, which is exactly where concentration risk lives.
• Designing an incident process that has never been rehearsed, so the reporting deadlines get missed during the first real event.
• Buying a one-off compliance project and assuming DORA is done, when the regulation expects a continuous operating rhythm that survives staff turnover and system change.

Cost and effort

DORA effort scales with your size, your reliance on ICT third parties, and whether you fall into the significant entity category that triggers threat-led penetration testing. A smaller payment institution with a tidy ISO 27001 system might close most gaps in a focused quarter of work plus an annual testing cadence. A large bank with a sprawling vendor estate and TLPT obligations is looking at a sustained multi-year programme with a recurring testing budget. The largest single line item is usually the testing, because realistic, threat-led work takes skilled people and time. We break down what drives engagement pricing in penetration testing cost, which applies directly to the DORA testing pillar.

The cost of non-compliance runs in the other direction. Competent authorities can impose remedial requirements and penalties, and a serious incident at a firm with weak resilience attracts both supervisory and reputational consequences. Spending on testing and governance is cheaper than explaining to a regulator why a critical function went dark and stayed dark.

DORA rewards firms that can prove resilience, not describe it. A checklist gets you organized, but the evidence behind each item is what satisfies a competent authority and, more importantly, what keeps your critical functions running when something goes wrong. We help financial entities turn this checklist into a working programme, from the governance backbone through to threat-led testing, under our GRC services. If you want a clear read on where you stand against all five pillars, book a scoping call and we will start with the gaps that matter most.