Your Guide to DORA Compliance 

Quick answer: DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554) has applied to EU banks, insurers, investment firms, and their ICT providers since January 17, 2025. It requires a formal ICT risk management framework, encryption and key management controls under Articles 6 and 7, incident classification and reporting, resilience testing including threat-led penetration testing, and third-party risk management. As of late 2025, the EU regulators also directly oversee a named list of critical ICT third-party providers. The recommended action: map each DORA article to a named control owner and an evidence artifact your national competent authority can inspect on request.

Key takeaways

• DORA has been fully enforced since January 17, 2025; this is not a future deadline, it is a live regulatory requirement being actively supervised.
• On November 18, 2025, the European Supervisory Authorities (EBA, ESMA, EIOPA) published the first list of critical ICT third-party providers, bringing major cloud and technology vendors under direct EU oversight for the first time.
• Article 6 and Article 7 make encryption and cryptographic key management explicit, named regulatory controls, not general best practice, for every in-scope financial entity.
• Non-compliance carries fines of up to 2% of global annual turnover for financial entities and up to €5,000,000 for critical ICT third-party providers, with individual liability on top.
• The generic five-pillar overview of DORA is well covered elsewhere; what most organizations actually need is the mapping from each article to a control, an owner, and an evidence artifact, which is what this update adds.

Published: March 2025  |  Updated: August 2026  |  Reviewed by the Encryption Consulting compliance advisory team

DORA sits alongside the other frameworks in Encryption Consulting’s compliance series: data privacy laws for the broader regulatory landscape, NIS2 for the parallel operational-resilience regime covering non-financial critical sectors, and NIST SP 800-53 for organizations that need a control catalog to implement DORA’s requirements against.

What Is DORA, and Who Must Comply?

The Digital Operational Resilience Act (DORA) is an EU regulation that requires financial entities and the ICT third-party providers that support them to manage, mitigate, and report on information and communication technology risk under one harmonized framework. It replaces a patchwork of national and sector-specific ICT rules with a single regulatory standard across banking, insurance, investment, payments, and crypto-asset services.

DORA applies to 21 categories of entities under Article 2: credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurance and reinsurance undertakings, credit rating agencies, crowdfunding platforms, and, critically, the ICT third-party service providers that support all of the above, including cloud providers, software vendors, and data analytics firms. An organization does not need to be a bank to be in scope; a cloud provider hosting a bank’s core systems is in scope too.

How Do DORA Requirements Map to Controls, Owners, and Evidence?

DORA’s five pillars (ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing) are well documented elsewhere. What most compliance teams actually struggle with is translating the pillars into named controls a regulator can test. The table below maps the articles that generate the most audit findings.

Requirement	Control	Owner	Evidence artifact
Article 6 encryption of data at rest, in transit, and in use	Documented encryption policy covering all three data states, with exceptions justified	Encryption / cryptography engineering	Encryption policy document and configuration exports by data store
Article 7 cryptographic key lifecycle management	Key generation, rotation, backup, and destruction procedures with access controls	Key management team	Key management procedure document and certificate/key register
Article 9 secure authentication and access controls	Strong authentication tied to recognized standards for all ICT asset access	Identity and access management	Authentication configuration export and access control policy
Article 17/19 ICT incident classification and reporting	Incident detection, classification, and regulator notification workflow	Security operations / incident response	Incident register and sample regulator notification records
Article 24/25 resilience testing, including TLPT	Annual resilience testing program plus threat-led penetration testing every three years for high-risk entities	Security testing / red team, independent of build teams	Test plans, results, and remediation tracking
Article 28 ICT third-party risk management	Vendor risk register with contractual clauses covering audit rights and exit	Vendor management / procurement	Vendor register and signed contracts with the required clauses

What Are the Implementation Steps?

1. Confirm scope: determine which of the 21 Article 2 entity categories applies, and separately confirm whether any of your ICT vendors are on the critical ICT third-party provider list published by the ESAs.
2. Inventory cryptographic controls against Articles 6 and 7: what is encrypted, where, with what key management practice, and where the gaps are.
3. Stand up the ICT risk management framework under Chapter II, with a named risk owner and a documented risk register reviewed at a defined cadence.
4. Build the incident classification and reporting workflow, including the internal escalation path and the exact regulator notification timelines for major incidents.
5. Schedule resilience testing: annual testing for all in-scope entities, and threat-led penetration testing at least every three years for entities the regulator designates as significant.
6. Build the ICT third-party register and review existing vendor contracts for the audit-rights, exit-strategy, and sub-outsourcing clauses DORA requires.
7. Confirm critical-vendor exposure: if a vendor is on the ESA critical ICT third-party provider list, plan for direct regulatory oversight activity involving that vendor, not just your own contract management.
8. Package the evidence a National Competent Authority will request: risk register, incident log, test results, vendor register, and the cryptographic policy documents.

What Is the Current State of DORA Enforcement?

DORA has been fully applicable since January 17, 2025; there is no remaining grace period. The most significant recent development is oversight-related, not legislative: on November 18, 2025, the European Supervisory Authorities designated the first official list of critical ICT third-party providers (CTPPs), covering major cloud and technology vendors that support the EU financial sector. Each designated CTPP is now assigned a lead overseer among the EBA, ESMA, and EIOPA and is subject to direct oversight activity, including examinations that can extend to how the financial entities using that vendor manage the relationship. Financial entities should confirm which of their vendors appear on the published list and expect follow-on oversight questions during their 2026 supervisory review cycle.

What Are the Limitations to Be Aware Of?

• DORA does not prescribe specific algorithms or key lengths; Articles 6 and 7 require a documented, risk-based policy, which means an organization’s own risk assessment carries real weight during examination.
• Being a customer of a designated critical ICT third-party provider does not transfer compliance responsibility; the financial entity remains accountable for its own DORA obligations regardless of vendor oversight status.
• Threat-led penetration testing requirements apply only to entities a regulator designates as significant; smaller entities should not assume TLPT is mandatory without confirming their designation status.
• DORA and NIS2 overlap for entities that are both financial and operate critical infrastructure; DORA takes precedence as the sector-specific lex specialis, so map obligations to avoid duplicate reporting.

Audit-Ready Checklist for DORA

1. Documented ICT risk management framework with a named risk owner and review cadence.
2. Encryption policy covering data at rest, in transit, and in use, with justified exceptions.
3. Key management procedures covering the full key lifecycle, with a current key and certificate register.
4. Incident classification workflow with sample records showing regulator notification within required timelines.
5. Resilience testing results from the most recent annual cycle, plus TLPT results if designated significant.
6. ICT third-party register cross-checked against the published critical ICT third-party provider list.
7. Vendor contracts reviewed for audit-rights, exit-strategy, and sub-outsourcing clauses.
8. Named individual accountability for each pillar, matching what Article 5 requires of the management body.

What Would Encryption Consulting Recommend?

Do not treat DORA as a single compliance project that ends at a deadline; the deadline has already passed, and the ESAs’ November 2025 critical-provider designations show that enforcement activity is still expanding. Our recommendation is to prioritize Articles 6 and 7 first among the technical requirements: encryption and key management are the controls with the clearest audit trail and the ones most commonly found deficient, because “we encrypt sensitive data” without a documented policy, ownership, and key lifecycle process does not satisfy an examiner. Pair a DORA gap assessment with a cryptographic inventory so the same evidence serves both the regulatory review and your internal security posture.

Encryption Consulting’s Encryption Advisory Services and Compliance Advisory Services assess your current encryption and key management posture against Articles 6, 7, and 9 directly, identify gaps against the specific evidence a National Competent Authority will request, and deliver a prioritized remediation roadmap.

Frequently Asked Questions

Who must comply with DORA?

21 categories of financial entities under Article 2, plus any ICT third-party service provider that supports them, including cloud providers, software vendors, and data analytics firms.

What does DORA require for encryption?

Article 6 requires a documented policy for encrypting data at rest, in transit, and, where feasible, in use, plus periodic updates to cryptographic technology. Article 7 requires managing cryptographic keys through their full lifecycle with strict access controls.

What is a critical ICT third-party provider under DORA?

A vendor the European Supervisory Authorities have designated as systemically important to the EU financial sector, first published November 18, 2025. Designated providers are subject to direct EU oversight through a lead overseer.

What are the penalties for DORA non-compliance?

Financial entities can face fines of up to 2% of total annual worldwide turnover, with individuals liable up to €1,000,000. Critical ICT third-party providers can face fines up to €5,000,000, with individuals liable up to €500,000.

How does DORA differ from NIS2?

DORA is sector-specific to financial entities and acts as lex specialis, taking precedence over NIS2 for those entities. NIS2 covers a broader set of critical-infrastructure sectors. See our NIS2 compliance guide for the comparison.

Ready to close the gap? Contact Encryption Consulting at [email protected] to scope a DORA readiness assessment focused on Articles 6, 7, and 9.

References

• DORA Article 2, dora-info.eu
• European Banking Authority: ESAs Designate Critical ICT Third-Party Providers
• DORA Article 6, dora-info.eu
• DORA Article 7, dora-info.eu