Financial Services Cybersecurity and DORA Compliance: Practitioner Guide
The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — became directly applicable across all EU member states on January 17, 2025. Unlike a directive requiring national transposition, DORA is a regulation that applies uniformly. It covers banks, insurers, investment firms, payment institutions, crypto-asset service providers, and critically, their ICT third-party service providers. For security teams in EU-regulated financial entities, DORA is not a compliance checkbox: it mandates a structured ICT risk management framework, binding incident reporting timelines, third-party risk oversight, and threat-led penetration testing for systemically important entities.
DORA's Five Pillars: What Security Teams Own
DORA organizes requirements around five chapters. Security teams have primary ownership or significant contribution to all five.
ICT Risk Management (Chapter II)
Entities must establish, implement, and maintain a documented ICT risk management framework covering identification, protection, detection, response, and recovery. This is the NIST CSF translated into binding regulation — with required annual review and board-level reporting.
ICT Incident Management and Reporting (Chapter III)
Major ICT incidents must be reported to competent authorities in a three-phase timeline. The framework distinguishes between ICT incidents and cyber threats, with different handling and reporting requirements for each.
Digital Operational Resilience Testing (Chapter IV)
Basic testing (vulnerability assessments, network security assessments, gap analyses) is mandatory for all in-scope entities. Advanced testing — Threat-Led Penetration Testing (TLPT) — is required for significant entities at least every three years.
ICT Third-Party Risk Management (Chapter V)
Financial entities must maintain a register of all ICT third-party service providers, conduct risk assessments before engagement, include DORA-mandated contractual provisions in all ICT contracts, and exercise exit strategies annually.
Information Sharing (Chapter VI)
DORA explicitly encourages sharing of cyber threat intelligence among financial entities. Participation in sector information sharing arrangements (like FS-ISAC) is positioned as a compliance-supporting activity.
ICT Risk Management Framework Requirements
DORA Article 6 requires the ICT risk management framework to be documented, approved by the management body, and reviewed at least annually. The framework must cover the full ICT risk lifecycle and include specific elements that security teams must implement.
Asset identification and classification
Maintain an inventory of all ICT assets supporting critical or important functions. Classification must reflect sensitivity of data processed and operational criticality. This is the prerequisite for everything else in DORA.
Protection and prevention
Document and implement controls for each identified risk. DORA requires network segmentation, access control policies based on need-to-know, patch management procedures, and cryptography policies specifying approved algorithms and key management.
Detection capabilities
Establish mechanisms to promptly detect anomalous activities. SIEM, IDS/IPS, and behavioral analytics are the standard implementations. The detection layer must cover ICT systems supporting critical functions.
Response and recovery
Maintain documented incident response plans with defined roles, communication procedures, and escalation paths. Business continuity plans must address ICT disruption scenarios with defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs).
Learning and evolving
Post-incident reviews and lessons-learned integration are explicit DORA requirements. Threat intelligence inputs must feed back into the risk management framework update cycle.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
ICT Incident Reporting: The Three-Phase Timeline
DORA's incident reporting requirements are operationally demanding. Security operations teams must integrate reporting obligations into their incident response workflows before an incident occurs — not during one.
“DORA's 4-hour initial notification requirement is faster than most organizations' internal incident classification processes. The notification obligation must be built into the IR runbook, not decided during the incident.”
EBA DORA Implementation Guidance, 2024
Initial notification (4 hours)
Within 4 hours of classifying an ICT incident as major, submit an initial notification to the competent authority. The initial notification is brief: incident classification, affected functions, initial assessment of impact, and whether the incident is ongoing. The 4-hour clock starts at classification, not detection — classification triggers the obligation.
Intermediate report (72 hours)
Within 72 hours of the initial notification, submit an intermediate report with an updated impact assessment, preliminary root cause hypothesis, applied mitigation measures, and estimated financial impact if determinable.
Final report (within 1 month)
After resolution, submit a final report covering complete root cause analysis, applied and planned remediation, cross-border impact assessment, and lessons learned. The final report becomes part of supervisory records.
Major incident classification criteria
The European Supervisory Authorities (ESAs) Joint RTS on incident classification defines major incidents by number of clients affected, duration, geographic spread, economic impact (0.1% of total annual transactions or EUR 5 million minimum), reputational impact, and criticality of affected services.
Threat-Led Penetration Testing (TLPT)
TLPT is DORA's advanced testing requirement for significant financial entities. It is based on the TIBER-EU framework and requires intelligence-led red team operations conducted by qualified external testers. TLPT is significantly more demanding than a standard penetration test.
Scope
TLPT must cover all functions, systems, and processes supporting critical or important functions, including those operated by ICT third-party providers. Third-party providers can be included in scope directly.
Threat intelligence phase
Before testing begins, a threat intelligence provider develops a Targeted Threat Intelligence (TTI) report profiling the entity's threat landscape, likely threat actors, and probable attack scenarios. This intelligence drives the red team's tactics.
Red team testing phase
External red team providers execute multi-week adversary simulations based on the TTI scenarios. Tests may include social engineering, physical access attempts, and technical exploitation targeting production systems (with appropriate safeguards).
Remediation and attestation
After testing, the entity must remediate identified vulnerabilities and submit attestation to the competent authority confirming completion. TLPT results are shared with lead supervisors through the DORA authority structure.
Frequency
Significant entities subject to TLPT must conduct it at least every 3 years. The competent authority can require more frequent testing based on risk profile.
Third-Party ICT Risk Management
DORA places binding obligations on how financial entities manage ICT third-party risk — not just recommendations. The key operational requirements are the ICT third-party register and mandatory contractual provisions.
ICT third-party register
Maintain a register of all ICT third-party service providers. The register must include provider name, services provided, contract start/end dates, criticality assessment, and whether the provider is classified as critical by ESAs. The register is submitted to competent authorities annually.
Pre-engagement due diligence
Before entering an ICT contract supporting critical or important functions, conduct and document a risk assessment of the provider. Assessment must cover data security practices, business continuity capabilities, and sub-outsourcing chains.
Mandatory contractual clauses
DORA Article 30 lists required contract elements: service levels with measurable indicators, data location and access provisions, incident notification obligations on the provider, audit rights (entity and competent authority), and termination rights. Contracts not including these provisions are non-compliant.
Exit strategies
Entities must document and test exit strategies for all critical third-party ICT services at least annually. The exit strategy must address transferring services to an alternative provider or in-house without disrupting critical functions.
DORA vs. Existing Frameworks: What Changes
Financial entities already subject to EBA outsourcing guidelines, NIST CSF, ISO 27001, or national banking regulations will find significant overlap with DORA — but also critical differences. DORA is directly enforceable without discretion: the RTS set specific thresholds and timelines that cannot be negotiated. Existing outsourcing registers can serve as the basis for the ICT third-party register, but will require expansion to include DORA-specific fields. ICT incident reporting under DORA is in addition to, not instead of, existing national reporting obligations. Entities reporting under NIS2, GDPR, or national financial sector regulations must track and meet all applicable deadlines simultaneously.
The bottom line
DORA is the most prescriptive financial sector cyber regulation the EU has produced. For security teams, the operational priorities are: a documented and board-approved ICT risk management framework, integration of DORA's incident classification criteria and reporting timelines into IR runbooks, a complete ICT third-party register with DORA-compliant contracts, and a TLPT program for significant entities. The regulation is enforceable now — gaps identified in supervisory reviews or after a major incident will carry the full weight of DORA's penalty framework.
Frequently asked questions
Who does DORA apply to?
DORA applies to EU financial entities including credit institutions (banks), payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, central counterparties, central securities depositories, and trading venues. It also applies directly to ICT third-party service providers designated as critical by the European Supervisory Authorities. Non-EU entities providing ICT services to in-scope EU financial entities face indirect obligations through contractual requirements.
What is the difference between an ICT incident and a major ICT incident under DORA?
All ICT disruptions that affect the confidentiality, integrity, or availability of ICT systems or data are ICT incidents. A major ICT incident is one that crosses materiality thresholds defined in the ESAs' Joint RTS: high number of affected clients, significant duration, geographic spread across multiple member states, economic impact above EUR 5 million or 0.1% of annual transactions, or disruption of critical services. Only major ICT incidents trigger the external reporting obligation to competent authorities.
What is Threat-Led Penetration Testing (TLPT) and how does it differ from a standard penetration test?
TLPT is an intelligence-led red team exercise mandated by DORA for significant financial entities at least every three years. Unlike a standard penetration test that covers a defined technical scope, TLPT begins with a threat intelligence phase that profiles likely adversaries and attack scenarios specific to the entity. The subsequent red team operation simulates those realistic adversary tactics against production systems. TLPT typically spans 3-6 months, requires external providers meeting DORA qualification criteria, and results in attestation submitted to the competent authority.
What contractual clauses must ICT contracts include under DORA?
DORA Article 30 requires ICT contracts supporting critical or important functions to include: clear description of services with measurable SLAs, data location and sovereignty provisions, incident notification obligations on the provider to the financial entity, audit rights for the entity and competent authorities, business continuity provisions, and termination rights if the provider no longer meets DORA standards. Contracts that predate DORA must be renegotiated to include these provisions.
How does DORA interact with GDPR and NIS2?
DORA is sector-specific and adds requirements on top of, not instead of, GDPR and NIS2. A major ICT incident involving personal data will trigger both DORA incident reporting (to the financial competent authority) and GDPR breach notification (to the data protection authority, within 72 hours). NIS2 covers critical infrastructure broadly; DORA covers financial entities specifically with more detailed requirements. Entities subject to both must satisfy both reporting chains, potentially with different timelines and reporting authority contacts.
What are the penalties for DORA non-compliance?
For financial entities, DORA enables member state competent authorities to impose penalties including fines, public censure, and suspension of activities. For critical ICT third-party service providers under direct ESA oversight, fines can reach 1% of average daily global turnover, applied per day during ongoing violations. Member states have discretion to set specific penalty levels within the DORA framework.
What is the ICT third-party register and how detailed must it be?
The ICT third-party register is a comprehensive record of all ICT service providers the financial entity uses. Required fields include provider identity, services provided, data categories processed, contract dates, geographic location of data processing, criticality classification (critical or important function support), and whether the provider appears on the ESA critical ICTSP list. The register is reported to the competent authority annually and must be kept current throughout the year.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.