DORA Compliance: Digital Operational Resilience for Financial Entities

DORA — the Digital Operational Resilience Act (Regulation 2022/2554/EU) — is a mandatory EU regulation that has applied to financial entities across the EU since 17 January 2025, covering banks, insurance companies, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, and ICT third-party service providers designated as critical. DORA requires these entities to implement a comprehensive ICT risk management framework, report major ICT incidents to competent authorities (including Banco de España and the CNMV for Spanish entities), conduct regular digital operational resilience testing including threat-led penetration tests (TLPT), and manage ICT third-party risk through compliant contractual arrangements under Article 30 of the Regulation. Non-compliance is supervised and sanctioned by national competent authorities.

Our financial regulatory compliance team combines deep knowledge of the DORA Regulation with practical experience implementing ICT risk management frameworks in financial sector entities.

Why DORA Is More Than a Documentation Exercise

DORA (Digital Operational Resilience Act, Regulation 2022/2554) has applied directly across the EU since January 2025. Unlike many compliance frameworks, DORA does not limit itself to documentation requirements — it demands real operational changes in how financial entities govern their technology, manage incidents, and contract with their providers. The experience of the first months of application confirms uneven sector readiness, with material gaps particularly in ICT provider contract compliance and the operational capacity to meet incident notification deadlines.

The Four Pillars in Practice

The ICT risk management framework required by Article 6 of DORA calls for board-approved ICT risk policies, a complete inventory of critical ICT systems and assets, a regular risk assessment methodology, and a business continuity plan specific to technology disruptions. For many mid-sized financial entities, this level of formal ICT governance is genuinely new — operational IT management existed, but not the structured framework DORA requires. Our approach builds on what already exists, avoiding duplication and minimising implementation burden.

Third-party ICT risk is the second major area of complexity. Almost every financial entity today depends on cloud providers, SaaS platforms, and specialist software vendors that are essential to daily operations. DORA imposes detailed contractual obligations for these relationships, including audit rights that many global providers do not grant by default, and a complete register of all ICT provider agreements. We coordinate closely with third-party risk management functions and the legal teams negotiating these contracts.

TLPT and Advanced Resilience Testing

For larger entities subject to Threat-Led Penetration Tests, we coordinate the end-to-end process: selecting a certified red-team provider, defining the scope with the supervisory authority, executing the tests across critical functions and systems, and producing the final report with a documented remediation plan. DORA is explicit that TLPT results — including identified vulnerabilities — must be shared with the supervisor and accompanied by a concrete remediation timeline. The coordination demands between the entity, the tester, and the supervisor are substantial, and early engagement with the supervisory authority is essential to avoid process delays.

Relationship with NIS2 and Other Frameworks

Financial entities subject to DORA are exempt from NIS2 in the areas DORA regulates. For groups with both financial and non-financial activities, we map the respective scopes to identify where a single governance framework can serve both regulations and where separate treatment is required. We also integrate DORA compliance with NIS2 compliance programmes for groups that need both, ensuring that security investments are leveraged across regulatory requirements rather than duplicated.

ICT Incident Classification and Notification

One of the most operationally demanding DORA requirements is the real-time incident classification and notification process. DORA distinguishes between ICT incidents and major ICT incidents: only the latter trigger the formal notification obligation to the Banco de España and/or the CNMV. The classification criteria — set out in delegated technical standards published by the European Supervisory Authorities — cover impact on business operations, number of clients affected, data loss, and financial impact. Getting the classification wrong has consequences in both directions: over-reporting creates operational burden; under-reporting constitutes a DORA infringement. We implement the incident classification workflow as a documented internal procedure that enables the compliance and operations teams to make consistent, defensible decisions in real time.

Register of Information and Contractual Compliance

DORA’s Register of Information — the complete registry of all ICT service provider relationships — is both a compliance deliverable and a risk management tool. Building and maintaining it requires coordinating information from across the organisation: IT, procurement, operations, and legal teams all contribute data. DORA’s Article 30 contractual requirements — audit rights, service levels, subcontracting controls, business continuity obligations, and data localisation clauses — must be verified against every ICT contract in scope. Many global technology vendors do not offer DORA-compliant terms by default. Our commercial contracts team handles the contractual negotiation track alongside the regulatory compliance analysis.

Supervisory Expectations in the First Enforcement Cycle

The first full year of DORA application has made supervisory expectations clearer. The Banco de España and CNMV have signalled priority focus areas for their initial inspection activity: ICT third-party contract compliance, the completeness and accuracy of the Register of Information, and the functioning of the ICT incident notification process. Entities that have made good-faith implementation efforts but have documentation or process gaps should approach the compliance gap closure proactively. Our compliance risk mapping methodology provides the structured gap documentation that supports this proactive supervisory engagement.

Sectors Most Affected by DORA

Banks and credit institutions: subject to the full DORA obligation set including TLPT (threat-led penetration testing) for significant institutions. The Banco de España is the competent authority for DORA oversight of Spanish credit institutions.

Insurance companies: subject to DORA as insurance undertakings under Solvency II. ICT risk management must be integrated with the existing ORSA (Own Risk and Solvency Assessment) process and the Solvency II governance framework. The DGSFP is the competent authority.

Investment firms and asset managers: subject to DORA obligations with oversight by the CNMV. ICT risk management must be coordinated with the MiFID II operational resilience requirements that already applied.

Payment institutions and electronic money institutions: subject to DORA and PSD2 operational resilience requirements simultaneously. The Banco de España is the competent authority for payment institutions.

Crypto-asset service providers (CASPs): subject to DORA from 2025. CASPs are also subject to MiCA (Regulation 2023/1114) operational resilience requirements, creating a dual compliance requirement. For CASPs registered in Spain under CNMV supervision, we coordinate DORA and MiCA compliance as an integrated programme.

Worked Example: DORA Implementation for a Spanish Payment Institution

A Spanish payment institution (110 employees, EUR 18 million revenue) processing over EUR 2 billion in annual transaction volume needed to demonstrate DORA compliance to maintain its authorisation under Banco de España supervision.

BMC’s DORA implementation:

• ICT risk management framework: designed and documented the board-approved ICT risk policy, critical asset inventory (28 systems identified as critical or important), risk assessment methodology, and business continuity plan specific to ICT disruptions.
• Register of Information: identified 47 ICT service provider relationships, including 12 critical providers (cloud infrastructure, payment processing, fraud detection, core banking software). All 12 critical provider contracts reviewed; 9 required contractual amendments to meet Art. 30 requirements (audit rights, incident notification obligations, subcontracting provisions).
• Incident notification workflow: designed and tested the classification procedure (using EBA delegated technical standards criteria), notification templates for the Banco de España initial report, and the DORA/GDPR parallel notification coordination protocol.
• TLPT: not required for this institution (below systemic significance threshold). Annual network penetration test conducted to satisfy the regular resilience testing obligation.
• Implementation timeline: 7 months from initial instruction to documented DORA compliance package submission to Banco de España.

Common Mistakes We Fix

1. Treating DORA as a documentation project rather than an operational change. DORA requires real operational processes — incident classification workflows, ICT provider monitoring, TLPT coordination — not just policy documents. Entities that produce documentation without implementing the underlying processes will fail their first supervisory inspection.

2. Not identifying all critical and important ICT providers. The Register of Information is only as useful as it is complete. Many entities underestimate the number of ICT provider relationships with significant operational dependency — particularly those embedded in commercial software as third-party integrations. A systematic assessment of all software in use, not just IT-contracted services, is required.

3. Assuming existing cybersecurity frameworks fully satisfy DORA. ISO 27001 and NIS2 controls provide a good foundation, but DORA has specific requirements — particularly around the Register of Information, Art. 30 contract provisions, and TLPT — that these frameworks do not fully cover.

4. Not coordinating DORA incident notification with GDPR breach notification. Many DORA-triggering incidents also constitute personal data breaches under GDPR. The notification obligations run in parallel with different deadlines and different addressee authorities. Companies that manage these notifications sequentially (DORA first, then GDPR) may miss the 72-hour GDPR deadline while processing the DORA report.

5. Delaying Art. 30 contract negotiation with global ICT providers. Major cloud providers (AWS, Azure, GCP) and large SaaS vendors do not offer standard DORA-compliant contract terms to all customers. Negotiating the required contractual provisions (audit rights, subcontracting disclosure, incident notification obligations) typically requires engagement with the provider’s enterprise or financial services sales team, which takes time. Starting these negotiations early in the DORA implementation timeline is essential.

How We Work

Our DORA compliance practice combines financial regulatory lawyers with ICT risk management specialists. A typical engagement:

Phase 1 — Gap assessment (3-4 weeks): current state assessment against DORA requirements, critical asset inventory, ICT provider mapping, and prioritised gap analysis.

Phase 2 — Framework design (6-10 weeks): ICT risk management framework documentation, Register of Information construction, incident notification workflow design, and Art. 30 contract review programme.

Phase 3 — Ongoing compliance: annual ICT risk assessment update, Register of Information maintenance, incident notification support, and supervisory examination preparation.

Fixed-fee DORA gap assessment packages are available for entities that need a rapid compliance baseline assessment — for example, ahead of a scheduled Banco de España or CNMV inspection.

Regulatory Framework: DORA Regulation and Implementing Technical Standards

DORA (Regulation 2022/2554) applies directly across the EU since 17 January 2025. It is accompanied by a substantial body of Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) published by the European Supervisory Authorities (EBA, ESMA, EIOPA):

RTS on ICT risk management framework (JC 2023/86): specifies the minimum elements of the ICT risk management framework required by Art. 6, including the ICT risk appetite statement, the ICT risk management policies, the incident management process, and the business continuity and disaster recovery plans.

RTS on simplified ICT risk management (JC 2023/87): for financial entities below the significance thresholds that qualify for simplified obligations, specifying a proportionate version of the Art. 6 framework requirements.

RTS on major ICT incident classification (JC 2023/83): the classification criteria that determine whether an ICT incident constitutes a “major ICT incident” triggering notification obligations. Criteria include: number of clients affected, duration, data loss, economic impact, and criticality of services affected.

RTS on ICT third-party risk (JC 2023/84): specifies the policy requirements for ICT third-party risk management, the minimum contract provisions under Art. 30, and the information to be maintained in the Register of Information.

RTS on TLPT (JC 2024/16): specifies the requirements for Threat-Led Penetration Testing for in-scope entities, including the test scope, the use of accredited testers, and the supervisory coordination process.

The interaction between these technical standards and the DORA Regulation itself creates a complex compliance architecture. Our DORA compliance practice includes monitoring of all delegated acts and supervisory Q&A publications, ensuring that our clients’ compliance programmes are updated as the regulatory framework evolves.

Interaction with GDPR and Data Protection

DORA incidents frequently involve personal data — customer account information, transaction records, employee data processed through ICT systems. When a DORA major ICT incident also constitutes a personal data breach under GDPR Art. 4(12), parallel notification obligations arise: DORA notification to Banco de España or CNMV, and GDPR notification to the AEPD within 72 hours.

The dual notification obligation is operationally demanding: the two notification authorities require different information, apply different templates, and operate on slightly different timelines. We design notification workflows that satisfy both obligations simultaneously, using a single incident timeline and facts base to produce consistent notifications to different authorities. The most common failure mode — submitting the DORA notification and then discovering the GDPR clock was running independently — is avoided through a unified incident classification and notification protocol.

Supervisory Expectations for Spanish Financial Entities

The Banco de España and the CNMV have each published supervisory priorities that include DORA compliance oversight for their respective supervised entities. Based on the first year of DORA application:

Banco de España priorities: ICT third-party risk management, particularly the Register of Information completeness and the Art. 30 contract compliance status. The Banco de España has signalled that entities should expect to be asked to submit their Register of Information during routine supervisory interactions.

CNMV priorities: ICT incident classification and notification processes, with emphasis on the operational readiness of entities to meet the 4-hour initial notification deadline for critical incidents. The CNMV has indicated concern about entities whose incident response procedures have not been updated to reflect DORA timelines.

We prepare clients for supervisory examination by ensuring that the documentation package — Register of Information, ICT risk management framework documentation, incident notification procedure, and evidence of TLPT completion or assessment — is maintained in a format suitable for immediate submission to the supervisory authority.

DORA Compliance Timeline and Key Operational Deadlines

Understanding the operational time constraints embedded in DORA is essential for building realistic internal processes. The regulation imposes strict notification deadlines that are measured in hours rather than days:

Initial notification of major ICT incidents: entities must notify the competent authority (Banco de España or CNMV, as applicable) within 4 hours of classifying an incident as “major” — and in any case no later than 24 hours after first detecting that a major incident may have occurred. This compressed timeline requires pre-built notification templates, pre-authorised decision-making authority for the classification and notification decision, and a tested process for reaching the duty officer outside business hours.

Intermediate report: within 72 hours of the initial notification, the entity must submit an intermediate report providing updated information on the incident status, containment measures taken, and revised impact assessment. Where the incident has been fully resolved within this period, the entity may submit the final report directly.

Final report: within 1 month of the initial notification (or within 1 month of resolving the incident, if later), a final incident report must be submitted including root cause analysis, lessons learned, and the remediation plan for identified vulnerabilities.

ICT testing cycle: basic resilience testing must be conducted at minimum annually for all ICT systems. TLPT for significant entities has a minimum 3-year cycle but may be requested by the supervisory authority at any time. Planning the annual testing programme at the start of each year — with board-approved scope and certified testing providers selected in advance — prevents last-minute programme failures.

Register of Information submission: while DORA does not impose a standing periodic submission obligation for the Register of Information, entities must be prepared to submit it to the supervisor on request, typically within a short response window during an inspection or supervisory review.

Geographic Coverage and Multi-Jurisdiction Application

DORA is an EU Regulation that applies directly and uniformly across all EU Member States without transposition. For financial entities operating in multiple EU Member States — with banking licences, insurance authorisations, or investment firm authorisations in multiple countries — the competent authority for DORA oversight is the primary supervisor in each jurisdiction. We advise Spanish financial groups with cross-border operations on coordinating DORA compliance across multiple EU supervisory authorities, ensuring a consistent framework that satisfies each supervisor’s specific requirements.