DORA now covers more than 22,000 financial entities and an estimated 15,000 ICT third-party providers across the EU, according to the European Banking Authority, which gives some sense of how many organizations are working through a DORA compliance checklist right now, not just reading about the regulation in theory. The scale of who’s actually affected is much broader than most firms initially assume.
The ESAs’ own 2024 dry-run told an even more direct story: only 6.5% of nearly 1,000 firms tested passed every requirement checked. That’s a strong signal that good intentions and a general awareness of DORA aren’t enough on their own. This guide walks through a practical DORA compliance checklist, covers whether UK companies actually need to worry about any of this, and clarifies a few things competitors’ checklists tend to gloss over.
What is DORA in compliance terms? The Digital Operational Resilience Act, Regulation (EU) 2022/2554, is directly applicable EU law requiring financial entities and their ICT providers to manage technology risk, test resilience, report major incidents on a fixed timeline, and oversee third-party vendors. It’s been in force without national transposition since January 17, 2025.
Key Takeaways
- DORA requirements span five pillars, but a practical checklist follows a sequence, not a list you can tackle in parallel.
- DORA isn’t certifiable. There’s no formal audit like ISO 27001. Compliance is self-attested, with ongoing supervisory review from the EBA, EIOPA, and ESMA.
- UK companies aren’t automatically exempt. ICT providers supplying EU financial entities can fall within scope regardless of where they’re headquartered.
- The Register of Information has to be resubmitted annually, so a checklist that treats this as a one-time task will leave firms exposed the following year.
- DORA cyber security requirements overlap with GDPR in places but aren’t interchangeable; satisfying one doesn’t automatically satisfy the other.
The DORA Compliance Checklist: 7 Steps
| Step | Focus | Key Deliverable |
| 1 | Confirm scope and entity classification | Documented Article 2 applicability assessment |
| 2 | Assign management-body accountability | Board-approved ICT risk framework |
| 3 | Run a gap analysis | Findings mapped to all five pillars |
| 4 | Build the ICT third-party register | Complete Register of Information |
| 5 | Implement resilience testing | Annual vulnerability scans and TLPT where required |
| 6 | Formalize incident reporting | Rehearsed 4-hour/24-hour/72-hour/1-month reporting workflow |
| 7 | Self-attest and prepare for review | Documentation ready for supervisory requests |
Step 1: Confirm Your Scope and Entity Classification
Before anything else, check whether your organization actually falls within DORA’s scope under Article 2, and if so, which entity category applies. This matters because obligations differ: a small, non-interconnected investment firm qualifies for a simplified ICT risk management framework under Article 16, while a designated significant entity faces the full weight of the regulation, including Threat-Led Penetration Testing.
Step 2: Assign Management-Body Accountability
Article 5 puts ultimate responsibility for ICT risk management squarely with the entity’s management body, not the IT department. The board has to formally approve the ICT risk framework, define clear roles and responsibilities, and review the business continuity and incident response plans on a regular basis. Skipping this step and treating DORA as a purely technical project is one of the more common early mistakes.
Step 3: Run a Gap Analysis Against the Five Pillars
With scope and accountability settled, benchmark current practice against DORA’s five pillars: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. This is where most of the real work gets identified, and where a DORA compliance checklist built around generic best practices, rather than your specific entity classification, tends to miss things.
Step 4: Build Your ICT Third-Party Register
DORA requires a complete Register of Information mapping every ICT third-party dependency, with critical providers identified separately under Article 31 criteria: how central they are to service continuity, how hard they’d be to replace, and how much the entity relies on them. This register isn’t a one-time document. It has to be reviewed and resubmitted annually, and it’s one of the first things a national competent authority will ask to see during any review, whether scheduled or triggered by an incident.
Step 5: Implement Resilience Testing
Every entity needs a baseline DORA security testing programme covering vulnerability scans and network security assessments at least annually. Entities designated as significant have a materially higher bar: Threat-Led Penetration Testing at least once every three years, run by qualified, independently accredited testers. As of July 2025, Commission Delegated Regulation (EU) 2025/1190 added binding technical detail to TLPT specifically, including a minimum twelve-week active testing phase and mandatory purple teaming between red and blue teams.
Step 6: Formalize Incident Reporting
DORA sets a staged, non-negotiable timeline for major ICT incidents: an initial notification once an incident is classified as major, due within four hours of that classification and no later than twenty-four hours after detection, an intermediate report within 72 hours, and a final report within one month. These deadlines only work if the reporting process is rehearsed in advance. Finding out how your team actually performs under a four-hour clock during a live incident is a bad time to discover gaps.
Step 7: Self-Attest and Prepare for Ongoing Review
Here’s something most checklists skip past: DORA isn’t a certifiable framework. There’s no equivalent of an ISO 27001 audit that results in a certificate. Compliance is self-attested, meaning your organization assesses its own adherence once the previous six steps are in place. That doesn’t mean nobody’s checking. The EBA, EIOPA, and ESMA maintain ongoing supervisory oversight, and national competent authorities can and do request evidence at any time, which is exactly what the 6.5% dry-run pass rate reflects.
Does DORA Apply to UK Companies?
This is the question competitors’ checklists tend to answer vaguely, so it’s worth being precise. DORA is EU law, and the UK is not in the EU, so a UK-only financial firm with no EU operations and no EU clients generally sits outside DORA’s direct scope. The UK has its own, broadly similar operational resilience regime run by the FCA and PRA, which shares DORA’s underlying goals without being the same regulation.
Where it gets more complicated is ICT third-party providers. DORA compliance UK obligations become real the moment a UK-based company, cloud provider, software vendor, or IT consultancy supplies services to an EU-regulated financial entity. In that case, DORA applies regardless of where the provider is headquartered, since the obligation flows through the EU entity’s own compliance requirements for its vendor relationships. A UK cloud provider supporting a French bank is very much in scope, even without a single EU office.
Does DORA apply to UK insurance companies specifically? The same logic holds. A UK insurer with no EU presence and no EU customers isn’t directly subject to DORA. A UK insurer operating in the EU through a subsidiary, branch, or passporting arrangement, or one that acts as an ICT provider to EU-regulated entities, needs to evaluate its DORA obligations carefully rather than assume UK domicile provides blanket exemption.
| UK Company Type | DORA Status |
| UK-only financial firm, no EU operations | Generally outside DORA’s direct scope |
| UK firm with an EU subsidiary or branch | The EU entity is in scope; obligations flow back to group-level ICT arrangements |
| UK ICT/cloud/software vendor serving EU financial entities | In scope, regardless of where the vendor is headquartered |
DORA vs. GDPR: Why One Checklist Doesn’t Cover Both
DORA cyber security requirements and GDPR overlap in places; both care about protecting data and managing risk, but they’re not interchangeable frameworks. GDPR is about protecting personal data specifically, with its own lawful basis, consent, and breach notification rules. DORA is about operational resilience broadly: keeping critical financial services running, regardless of whether personal data is involved in a given incident. A firm can be fully GDPR compliant and still fail a DORA resilience test, because DORA cares about system availability and third-party risk in ways GDPR simply doesn’t address. Treating a DORA compliance checklist as a subset of an existing GDPR programme is a common shortcut that tends to leave real gaps in resilience testing and vendor oversight.
How Qualysec Helps With DORA Compliance
I. Gap Assessment Against All Seven Checklist Steps
Qualysec benchmarks your current ICT risk posture against DORA’s five pillars and produces a prioritized roadmap, mapped to your specific entity classification rather than a generic template.
II. CREST-Accredited Resilience Testing
For baseline scanning and, where required, Threat-Led Penetration Testing aligned to Commission Delegated Regulation (EU) 2025/1190, Qualysec’s CREST-accredited testers deliver results structured for regulatory scrutiny, not just an internal readout.
III. Ongoing Register of Information Support
Since the register needs annual resubmission, Qualysec supports continuous third-party risk tracking so compliance doesn’t quietly lapse between formal review cycles.
Conclusion
A DORA compliance checklist only works if it’s followed in sequence: scope and accountability first, technical controls and testing later, because skipping ahead tends to produce exactly the kind of gaps the ESAs found in their 2024 review. Whether you’re confirming UK exposure through a vendor relationship or building out a full five-pillar programme from scratch, the firms that treat this as an ongoing operating discipline, not a one-time project, are the ones still passing review a year from now.
Contact Qualysec to build a DORA compliance checklist tailored to your organization.
Frequently Asked Questions
1. What is DORA in compliance?
DORA, the Digital Operational Resilience Act, is EU Regulation 2022/2554 requiring financial entities and their ICT providers to manage technology risk, test resilience, report major incidents within fixed deadlines, and oversee third-party vendor relationships. It’s been directly applicable across the EU since January 17, 2025.
2. What are the 5 pillars of DORA regulation?
The five pillars are ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing. Four are mandatory; information sharing between entities is voluntary, though still actively encouraged by regulators.
3. Is DORA applicable to the UK?
Not directly, for UK-only financial firms with no EU operations. The UK runs its own operational resilience regime through the FCA and PRA. DORA does apply to UK-based ICT providers, including cloud and software vendors, that supply services to EU-regulated financial entities, regardless of where the provider is headquartered.
4. What is the difference between DORA and GDPR?
GDPR protects personal data specifically, governing lawful basis, consent, and data breach notification. DORA governs operational resilience broadly, covering ICT risk management, resilience testing, and third-party oversight for financial entities, regardless of whether personal data is involved. Compliance with one doesn’t automatically satisfy the other.
5. Who needs to comply with DORA?
Around 20 categories of EU financial entities fall within scope, including banks, insurers, investment firms, and crypto-asset service providers, along with their ICT third-party providers. Providers meeting specific criticality thresholds face direct EU-level oversight as Critical ICT Third-Party Providers.
6. Does DORA apply to UK insurance companies?
A UK insurer with no EU presence and no EU customers generally isn’t directly subject to DORA. One operating in the EU through a subsidiary, branch, or passporting arrangement, or supplying ICT services to EU-regulated entities, needs to assess its specific obligations rather than assume automatic exemption based on UK domicile.
