The Digital Operational Resilience Act (DORA) is now in full enforcement as of 17 January 2025. Financial services firms across the European Union must demonstrate strong ICT risk management, structured incident reporting, operational resilience testing, and effective third-party risk oversight. DORA represents the most significant regulatory change for financial services cybersecurity in a decade, and firms that have not yet achieved compliance face regulatory action, reputational damage, and operational risk.
This guide explains what DORA requires, who must comply, and what practical steps security teams should take to meet the regulation's demands.
What Is DORA?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is an EU regulation that establishes a complete framework for managing ICT risk across the financial services sector. Unlike previous regulations that addressed ICT risk as a subset of broader operational risk, DORA creates specific, detailed, and enforceable requirements for how financial entities manage, monitor, and report on their digital operational resilience.
DORA was published in the Official Journal of the European Union on 27 December 2022, entered into force on 16 January 2023, and became fully applicable on 17 January 2025. The regulation is directly applicable in all EU member states; it does not require national transposition.
The regulation was motivated by several factors. The financial sector's increasing dependence on technology and ICT service providers creates concentration risks that transcend individual institutions. A single ICT failure or cyberattack can cascade across interconnected financial entities, threatening financial stability. Previous regulatory guidance was fragmented across sectors and member states, creating inconsistent standards and supervisory gaps.
DORA addresses these challenges by harmonising ICT risk management requirements across the entire financial sector, introducing a direct oversight framework for critical ICT third-party providers, and establishing standardised incident reporting and resilience testing requirements.
Who Must Comply with DORA?
DORA applies to 21 categories of financial entities, plus critical ICT third-party service providers. The scope is deliberately broad, covering virtually every regulated financial institution in the EU.
Financial entities in scope include:
- Credit institutions (banks)
- Payment institutions
- Account information service providers
- Electronic money institutions
- Investment firms
- Crypto-asset service providers
- Central securities depositories
- Central counterparties
- Trading venues
- Trade repositories
- Managers of alternative investment funds (AIFMs)
- Management companies (UCITS)
- Data reporting service providers
- Insurance and reinsurance undertakings
- Insurance intermediaries and reinsurance intermediaries
- Institutions for occupational retirement provision
- Credit rating agencies
- Administrators of critical benchmarks
- Crowdfunding service providers
- Securitisation repositories
- ICT third-party service providers designated as critical
The inclusion of ICT third-party service providers is particularly significant. DORA establishes a Lead Overseer framework that gives European Supervisory Authorities (ESAs) direct supervisory powers over critical ICT providers, including cloud service providers, managed security service providers, and other technology vendors that serve multiple financial entities.
Microenterprises (fewer than 10 employees and annual turnover or balance sheet below EUR 2 million) benefit from a simplified, proportionate regime under DORA, but they are not exempt.
What Are the Five DORA Pillars?
DORA is structured around five interconnected pillars that collectively establish a full operational resilience framework.
Pillar 1: ICT Risk Management (Articles 5-16)
Financial entities must implement a thorough ICT risk management framework that includes:
- Governance and organisation: The management body bears ultimate responsibility for ICT risk. Entities must define clear roles and responsibilities, allocate adequate budget, and ensure that ICT risk management is integrated into the overall risk management framework.
- ICT risk management framework: Entities must identify, classify, and document all ICT-supported business functions, information assets, and ICT assets. They must conduct regular risk assessments and implement appropriate protection, detection, response, and recovery measures.
- Detection: Entities must implement mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents.
- Response and recovery: Entities must establish ICT business continuity policies, disaster recovery plans, and crisis communication plans. These must be tested regularly.
- Learning and evolving: Post-incident reviews must be conducted, and lessons learned must be incorporated into the ICT risk management framework.
Pillar 2: ICT Incident Reporting (Articles 17-23)
Financial entities must establish processes to detect, manage, classify, and report ICT-related incidents. Major incidents must be reported to the relevant competent authority according to specific timelines (detailed in the next section).
Pillar 3: Digital Operational Resilience Testing (Articles 24-27)
Entities must establish and maintain a thorough digital operational resilience testing programme that includes vulnerability assessments, network security assessments, penetration testing, and source code reviews. Significant entities must also conduct advanced threat-led penetration testing (TLPT) at least every three years.
Pillar 4: ICT Third-Party Risk Management (Articles 28-44)
Entities must manage ICT third-party risk as an integral component of their ICT risk management framework. This includes maintaining a register of all ICT third-party arrangements, conducting due diligence before entering contracts, including mandatory contractual provisions, and monitoring performance throughout the contract lifecycle.
Pillar 5: Information Sharing (Article 45)
DORA encourages, but does not mandate, financial entities to exchange cyber threat intelligence among themselves and with competent authorities. Information-sharing arrangements must include safeguards for data protection and business confidentiality.
What Are the DORA Incident Reporting Requirements?
DORA's incident reporting requirements are among the regulation's most operationally demanding provisions. Financial entities must classify ICT-related incidents based on specific criteria and report major incidents to their competent authority within strict timelines.
Classification Criteria
Incidents are classified as major based on the following criteria:
| Criterion | Description | |---|---| | Clients, counterparts, and transactions affected | Number of clients or financial counterparts affected, and number/value of transactions impacted | | Reputational impact | Severity of reputational damage, considering the profile of affected clients and media attention | | Duration and service downtime | Total duration of the incident and period of service unavailability | | Geographical spread | EU member states affected by the incident | | Data losses | Whether data integrity, confidentiality, or availability was compromised | | Criticality of services affected | Whether critical or important functions were impacted | | Economic impact | Direct and indirect costs, including recovery costs and regulatory fines |
Reporting Timelines
| Report | Deadline | Content | |---|---|---| | Initial notification | Within 4 hours of classifying an incident as major (and no later than 24 hours from detection) | Basic facts: what happened, when, initial impact assessment | | Intermediate report | Within 72 hours of the initial notification | Updated information: root cause analysis (if available), impact on clients, remediation actions taken | | Final report | Within 1 month of the intermediate report | Complete analysis: root cause, total impact, remediation actions completed, lessons learned |
These timelines are significantly tighter than many existing reporting obligations. The 4-hour initial notification window means that financial entities must have automated detection and classification capabilities; manual triage processes are unlikely to meet this deadline consistently.
Entities must also notify clients when a major incident impacts their financial interests, and they must report significant cyber threats to their competent authority on a voluntary basis.
How Does DORA Differ from NIS2?
DORA and NIS2 (the Network and Information Security Directive 2) both address cybersecurity requirements in the EU, but they differ in scope, focus, and application. Understanding their relationship is essential for organisations that may be subject to both.
| Aspect | DORA | NIS2 | |---|---|---| | Legal instrument | Regulation (directly applicable) | Directive (requires national transposition) | | Sector focus | Financial services exclusively | Cross-sector (energy, transport, health, digital infrastructure, and more) | | Scope | 21 categories of financial entities + critical ICT providers | Essential and important entities across 18 sectors | | Incident reporting | 4 hours (initial), 72 hours (intermediate), 1 month (final) | 24 hours (early warning), 72 hours (notification), 1 month (final) | | Penalties | Sector-specific; up to 1% daily turnover for critical ICT providers | Up to EUR 10 million or 2% of global turnover (essential entities) | | Resilience testing | Mandatory TLPT every 3 years for significant entities | Risk-based; no specific TLPT requirement | | Third-party oversight | Direct oversight framework for critical ICT providers | Supply chain security requirements but no direct oversight | | Application date | 17 January 2025 | 17 October 2024 (transposition deadline) |
DORA is considered _lex specialis_, a specialised law that takes precedence over NIS2 for financial entities within its scope. This means financial entities subject to DORA comply with DORA's ICT risk management and incident reporting requirements rather than NIS2's equivalent provisions. However, NIS2's broader security requirements may still apply for aspects not covered by DORA.
For a detailed guide to NIS2 requirements, see our NIS2 Compliance Guide.
DORA Compliance Checklist
Achieving DORA compliance requires a structured, cross-functional approach. The following checklist outlines the practical steps security and compliance teams should take.
- Establish governance and accountability. Ensure the management body formally acknowledges its responsibility for ICT risk. Appoint a senior executive or committee responsible for ICT risk management oversight. Document roles, responsibilities, and reporting lines.
- Conduct an ICT asset inventory. Identify and document all ICT-supported business functions, information assets, ICT assets, and their interdependencies. This inventory forms the foundation for risk assessment and third-party management.
- Perform a thorough ICT risk assessment. Assess threats, vulnerabilities, and potential impacts across all ICT assets and business functions. Align the assessment with DORA's specific requirements for protection, detection, response, and recovery.
- Review and update your ICT incident management process. Ensure your incident classification criteria align with DORA's requirements. Validate that your detection capabilities can identify major incidents within hours, not days. Test your ability to produce an initial notification within 4 hours of classification.
- Build or update your ICT third-party register. Document all ICT third-party service arrangements, including cloud services, managed security providers, and SaaS platforms. Classify each arrangement based on criticality and assess concentration risk.
- Conduct a contractual review. Review all ICT third-party contracts against DORA's mandatory contractual provisions, including audit rights, exit strategies, and sub-outsourcing restrictions. Renegotiate contracts that do not meet DORA requirements.
- Implement continuous monitoring and detection. Deploy detection capabilities that provide continuous monitoring across endpoints, networks, and cloud environments. Ensure anomaly detection and incident classification can be automated to meet reporting timelines.
- Establish a digital operational resilience testing programme. Define and implement a testing programme that includes vulnerability assessments, penetration testing, and scenario-based testing. If designated for TLPT, plan for threat-led penetration testing using the TIBER-EU framework.
- Develop and test business continuity and disaster recovery plans. Ensure ICT business continuity plans cover all critical functions. Conduct regular testing, including crisis simulations, and document results.
- Implement information-sharing arrangements. Evaluate and, where appropriate, participate in sector-specific information-sharing communities. Establish internal processes for receiving, assessing, and acting on shared threat intelligence.
- Document everything. DORA requires extensive documentation, including the ICT risk management framework, policies, procedures, testing results, incident reports, and third-party registers. Ensure documentation is current, accessible, and audit-ready.
- Conduct regular reviews and updates. DORA compliance is not a one-time exercise. Review and update your ICT risk management framework at least annually, after major incidents, and following significant changes to your ICT environment.
How SenseOn Supports DORA Compliance
SenseOn's unified detection platform directly addresses several of DORA's most operationally demanding requirements.
Continuous Monitoring and Detection (Pillar 1)
DORA requires entities to implement mechanisms for the prompt detection of anomalous activities. SenseOn deploys lightweight sensors across endpoints, network infrastructure, and cloud environments that collect full telemetry continuously. The cross-domain correlation engine (supervised learning, unsupervised learning, and deep learning) processes this telemetry in real time to identify anomalies, threats, and potential incidents without reliance on rule-based detection alone.
This satisfies DORA's expectation that detection capabilities go beyond basic log monitoring. SenseOn's behavioural analytics establish baselines for normal activity and flag deviations, which aligns directly with the regulation's requirements for anomaly detection.
Incident Detection and Classification (Pillar 2)
The 4-hour reporting window for major incidents demands automated detection and rapid classification. SenseOn's correlation engine automatically links related events across endpoints, network, and identity systems into coherent incidents, providing security teams with the context needed to classify an incident quickly against DORA's criteria.
The platform's Flexible Intelligence Credit (FIC) model ensures there is no financial disincentive to ingest full telemetry. Credits are consumed by security outcomes (detections, investigations, and AI-accelerated resolutions) not by data volume. Unlike SIEM-based approaches where per-GB costs force organisations to limit log sources, creating blind spots that delay detection, SenseOn collects everything without cost escalation.
Evidence Generation for Audit (Pillars 1 and 3)
DORA's emphasis on documentation and testing requires security teams to produce evidence of their detection and response capabilities. SenseOn maintains a complete audit trail of detections, investigations, and response actions. This evidence can be exported for regulatory reporting and audit purposes, reducing the manual burden of compliance documentation.
Automated Reporting Data (Pillar 2)
SenseOn's incident data, including timelines, affected assets, impact scope, and remediation actions, provides the structured information needed for DORA's initial, intermediate, and final incident reports. Rather than reconstructing incident timelines manually from disparate log sources, security teams can extract report-ready data directly from the platform.
Third-Party Risk Visibility (Pillar 4)
SenseOn's network monitoring capabilities provide visibility into connections to and from third-party service providers, helping entities identify unusual traffic patterns, unauthorised data flows, or changes in third-party service behaviour that may indicate a compromise in the supply chain.
For organisations navigating the UK regulatory landscape alongside DORA, our guide to UK Cyber Security Regulations provides additional context on how domestic requirements align with EU frameworks.
Frequently Asked Questions
When did DORA come into effect?
DORA entered into force on 16 January 2023 and has been in full enforcement since 17 January 2025. All in-scope financial entities and their critical ICT third-party providers must now demonstrate compliance with the regulation's requirements for ICT risk management, incident reporting, resilience testing, and third-party risk management.
Does DORA apply to UK financial services firms?
DORA is an EU regulation and applies directly to financial entities operating within the EU. UK-based firms are not directly subject to DORA unless they operate EU-regulated entities or provide critical ICT services to EU financial institutions. However, the UK's FCA and PRA operational resilience framework imposes similar requirements, and UK firms with EU clients or operations should expect DORA compliance to be a contractual requirement.
What are the penalties for DORA non-compliance?
DORA empowers competent authorities to impose administrative penalties and remedial measures on financial entities that fail to comply. For critical ICT third-party providers, the Lead Overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover for up to six months. Financial entities face sector-specific penalties determined by their national competent authority.
How does DORA differ from existing financial services regulation?
DORA is the first EU regulation to create a unified, cross-sector framework specifically for ICT risk in financial services. Previous regulations addressed ICT risk as part of broader operational risk requirements. DORA introduces specific, detailed requirements for ICT incident reporting timelines, mandatory resilience testing, a direct oversight framework for critical ICT providers, and standardised information-sharing arrangements.
Do we need to conduct threat-led penetration testing under DORA?
DORA requires financial entities identified by competent authorities to carry out advanced threat-led penetration testing (TLPT) at least every three years. TLPT must be conducted using the TIBER-EU framework or an equivalent recognised standard. Not all entities are required to conduct TLPT; competent authorities designate which entities must participate based on their systemic importance, ICT maturity, and risk profile.
Related reading:
