The Digital Operational Resilience Act
Digital innovation is transforming how financial services operate – but it is also expanding the attack surface that regulators expect firms to defend. The European Union’s Digital Operational Resilience Act (DORA) represents a landmark shift in how financial institutions are expected to manage ICT risks and withstand operational disruptions.
DORA has been fully in force since January 2025, meaning compliance is now a legal obligation rather than a future requirement. DORA compliance is a regulatory requirement for financial institutions operating in the EU and cannot be treated as optional guidance.
Firms that fall short face regulatory scrutiny and potential penalties – under DORA, financial entities can face fines of up to 2% of global annual turnover, while individuals may be subject to penalties of up to €5 million.
This guide covers what DORA actually requires, which organizations it applies to, how its five pillars translate into practical obligations, and what a realistic compliance roadmap looks like.
Whether you’re a compliance officer trying to understand the regulation or a security team mapping out your testing program, this is designed to give you a clear, jargon-free foundation and show how specialist security services can support compliance in practice.
What is DORA?
The Digital Operational Resilience Act (DORA) is a European Union regulation designed to ensure that financial services firms can withstand, respond to, and recover from information and communications technology (ICT) disruptions. It forms part of the EU’s broader Digital Finance Strategy, aiming to secure the financial ecosystem from operational risks and cyber threats.
DORA applies to a wide range of financial entities – including banks, insurance companies, investment firms, crypto-asset service providers, and certain third-party IT service providers – making DORA compliance a concern for much of the financial sector.
Who Must Comply With DORA?
DORA applies to:
- Credit institutions and banks
- Investment firms and trading venues
- Insurance and reinsurance companies
- Payment institutions and electronic money institutions
- Crypto-asset service providers (CASPs)
- Critical ICT third-party providers supporting financial entities
If your organization delivers regulated financial services or provides ICT services to regulated firms, DORA is likely to apply.
Key Objectives of DORA
- Strengthen ICT Risk Management: Financial institutions must implement robust, documented risk management frameworks.
- Incident Reporting: Mandatory, timely reporting of significant cyber incidents – within 24 hours.
- Third-Party Risk Oversight: Ensure that third-party providers, such as cloud service vendors, meet resilience requirements.
- Operational Resilience Testing: Continuous testing of systems to mitigate risks and assess resilience, including threat-led penetration testing (TLPT).
Why Is DORA Important?
Financial institutions sit at the center of the economy – they process payments, hold savings, underwrite risk, and facilitate trade. That centrality makes them a prime target for cyberattacks, and a single major outage at a large bank or payment processor can have cascading effects far beyond the institution itself.
Before DORA, ICT risk management requirements across EU member states were fragmented and inconsistent. A bank operating in five countries could face five different sets of rules. DORA changes that by establishing a single, harmonized standard – meaning regulators, institutions, and their vendors are all working from the same playbook for the first time.
Firms can no longer satisfy themselves with informal processes or vendor assurances – they need documented frameworks, tested recovery plans, and evidence of continuous monitoring.
The 5 Key Pillars of DORA
DORA organizes its requirements around five core pillars. Understanding these pillars is the foundation of any effective DORA compliance strategy and directly informs how security services should be selected and implemented.
1. ICT Risk Management
Business continuity and disaster recovery plans must be in place and regularly tested.
2. Incident Reporting
Mandatory cybersecurity incident reporting processes and regulatory notification within defined timelines.
3. Digital Operational Resilience Testing
Establish a technical testing program with threat-based and threat-led penetration testing.
4. Third-Party Risk Management
Oversee and manage risk from ICT third-party service providers throughout the vendor lifecycle.
5. Information Sharing
Encourage the sharing of threat intelligence and cyber-threat information across the sector.
Mapping DORA to Existing Security Frameworks
DORA Requirement | ISO 27001 Equivalent | NIST CSF Equivalent | What This Means in Practice |
ICT Risk Management | Annex A.5–A.8 | Identify (ID) / Protect (PR) | Maintain documented risk assessments, asset inventories, and security controls. |
Incident Reporting | Annex A.16 | Respond (RS) | Have defined incident detection, classification, and reporting procedures. |
Operational Resilience Testing | Annex A.12 / A.18 | Detect (DE) / Respond (RS) | Regularly test systems through penetration testing, simulations, and recovery exercises. |
Third-Party Risk Management | Annex A.15 | Identify (ID) / Protect (PR) | Assess vendor security, include resilience clauses in contracts, and monitor suppliers continuously. |
Business Continuity & Recovery | Annex A.17 | Recover (RC) | Implement and test disaster recovery plans, backup processes, and failover systems. |
Information Sharing | Annex A.6 | Respond (RS) / Recover (RC) | Participate in threat intelligence sharing and industry collaboration initiatives. |
DORA Compliance Checklist: 7 Steps to Get Ready
Whether your organization is just starting or looking to fine-tune its approach, the following step-by-step checklist provides a clear roadmap to meeting DORA’s key requirements. Each step maps directly to DORA’s five pillars and reflects real-world implementation priorities.
1. Establish an ICT Risk Management Framework
The foundation of DORA compliance is a comprehensive ICT risk management framework. Without one, all other efforts lack the governance structure needed to satisfy regulators.
- Identify critical ICT assets and associated risks.
- Develop and implement risk management policies covering all potential ICT risks.
- Assign clear internal responsibilities for ICT risk management.
How It Looks
An effective ICT risk management framework isn’t a static document – it’s a living process with clear ownership, regular reviews, and integration with your broader enterprise risk function. Look for frameworks that align with ISO 27001 or NIST CSF, which share significant overlap with DORA’s requirements and can reduce duplication of effort. Services like Penetration Testing as a Service (PTaaS) and continuous vulnerability management are often used to feed real-time data into these frameworks.
2. Set Up Continuous Resilience Testing
DORA requires financial institutions to continuously test their resilience against cyberattacks and operational disruptions, including advanced threat-led penetration testing (TLPT) for significant entities. A ransomware assessment is a valuable starting point for organizations looking to understand their exposure to one of the most disruptive operational threats.
- Perform regular vulnerability scans and penetration testing.
- Simulate cyberattacks to assess response and recovery capabilities.
- Test backup systems and disaster recovery processes.
Understanding TLPT Requirements
Threat-Led Penetration Testing (TLPT) under DORA is more rigorous than a standard penetration test. It must be based on current, specific threat intelligence relevant to your organization, and the testers must meet defined competency and certification standards – typically CREST or an equivalent national scheme.
Not all penetration testing providers are qualified to conduct TLPT, so it’s worth verifying credentials early. Red Team as a Service engagements are generally the closest commercial equivalent.
3. Develop an Incident Response Plan
Under DORA, you must have a structured incident response plan to detect and report incidents swiftly. DORA’s 24-hour reporting window leaves little margin for disorganized processes.
- Define your incident response team and their individual roles.
- Establish incident reporting protocols in line with DORA’s 24-hour requirement.
- Regularly update and stress-test your response plan.
DORA Incident Reporting Flow
- Incident detected internally
- Initial assessment and classification
- Initial regulator notification within 24 hours
- Intermediate report within 72 hours
- Final report within one month
This process must be documented, rehearsed, and supported by tooling capable of producing accurate reports under time pressure.
4. Monitor and Manage Third-Party Risk
Third-party service providers – such as cloud vendors and managed service providers – must also meet DORA’s resilience standards. DORA places direct responsibility on financial entities to oversee their vendors, and requires that significant entities conduct regular guided or threat-led penetration testing (TLPT) based on real, specific threats.
Penetration testers involved in TLPT must meet stringent criteria, including relevant technical expertise and recognized certifications.
- Audit your third-party vendors to confirm they meet resilience requirements.
- Include resilience clauses in all contracts with third-party providers.
- Implement ongoing monitoring of vendors’ operational resilience.
- Ensure TLPT testers meet DORA’s certification standards (e.g., CREST, CyberScheme).
What DORA Requires From Vendors
DORA introduces the concept of “critical ICT third-party providers” (CTPPs), which may be designated by regulators and subjected to direct oversight. Even where a vendor isn’t formally designated, financial entities are responsible for ensuring their contracts include exit strategies, audit rights, and resilience obligations.
Rootshell’s RedForce Red Team includes CREST and CyberScheme certified consultants – view our full accreditations – and all Red Team engagements are managed by certified Cyber Scheme Red Team Managers. We also provide vendor risk assessments that evaluate the security practices of your third-party providers.
5. Implement Business Continuity and Recovery Plans
DORA requires detailed, tested plans for business continuity and IT recovery. Untested plans offer false assurance – DORA expects organizations to demonstrate that recovery actually works.
- Create detailed business continuity and disaster recovery plans.
- Test recovery processes to ensure data can be restored quickly.
- Ensure secure backups are regularly updated and stored in resilient environments.
Don’t Forget To Test
Having a business continuity plan on paper is not enough under DORA – the regulation explicitly requires that plans are tested. Tabletop exercises, disaster recovery drills, and simulated attack scenarios should all be documented, with results used to update the plans. Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) need to be defined, realistic, and validated against actual test results rather than estimates.
6. Enhance Security Awareness Across Your Organization
Human error remains the most common entry point for cyberattacks. DORA explicitly emphasizes staff awareness and training as part of a sound DORA compliance program.
- Conduct regular cybersecurity training for all employees.
- Run phishing simulations and practical exercises to improve security awareness.
- Keep staff up to date on the latest cyber threats relevant to the financial sector.
Training That Works
Annual compliance e-learning modules are unlikely to satisfy DORA’s intent. The regulation expects organizations to demonstrate that employees can actually recognize and respond to threats. Simulated phishing campaigns provide measurable, evidence-based insight into where human risk is concentrated – and which teams or departments need more targeted support.
7. Streamline Incident Reporting to Regulators
DORA requires financial institutions to report significant incidents to the relevant regulatory authorities within 24 hours of detection. This demands pre-built, well-tested reporting workflows – not an ad-hoc response.
- Establish clear reporting protocols that meet regulatory guidelines.
- Ensure incident reports are accurate and include all required technical details.
- Test your reporting process regularly with tabletop exercises.
Know Your Competent Authority
The regulatory body you report to will depend on your entity type and jurisdiction. Banks typically report to their national central bank or prudential regulator, while investment firms and insurance companies report to their respective sector supervisors. Getting clarity on this before an incident occurs – including the correct reporting format and contact details – is a practical step many organizations overlook. Platforms like The Rootshell Platform can help standardize and streamline reporting workflows so deadlines aren’t missed under pressure.
How Rootshell Security Supports DORA Compliance
At Rootshell Security, we specialize in enhancing the operational resilience of financial organizations through comprehensive cybersecurity services. Our solutions address every pillar of DORA – from continuous vulnerability management and threat-led penetration testing to incident response, external attack surface management, and ongoing compliance support.
DORA compliance is not a one-time effort. As new threats emerge and the regulatory landscape evolves, Rootshell’s team is here to guide you through every stage of your compliance journey – from initial infrastructure penetration testing and attack surface management through to ongoing managed testing and reporting support.
Frequently Asked Questions
Who enforces DORA?
DORA is enforced by national competent authorities (NCAs) in each EU member state (such as financial regulators or central banks), with oversight coordination from EU-level bodies including ESAs.
What happens if my organization doesn't comply with DORA?
Non-compliance can result in fines of up to 2% of global annual turnover for financial entities and up to €5 million for individuals, alongside reputational damage and regulatory intervention. Failing to meet ICT risk management requirements puts your entire operation at risk and may trigger regulatory intervention.
How does DORA impact third-party providers?
DORA places direct responsibility on financial institutions to monitor their third-party ICT service providers. Rootshell Security can help you assess and mitigate risks related to your vendors, ensuring they meet DORA’s operational resilience standards.
Does DORA apply to crypto businesses?
Yes – crypto-asset service providers fall within DORA’s regulatory scope. Our penetration testing and risk management solutions can help crypto companies strengthen their operational resilience and achieve DORA compliance.
How can Rootshell Security help with the 24-hour incident reporting requirement?
Rootshell’s incident response services ensure your organization is prepared to detect, report, and recover from cyber incidents quickly. Through The Rootshell Platform, we help you streamline reporting processes to reliably meet DORA’s 24-hour reporting window.
Can’t find the answer to your question?
You can always Contact Our Team of experts for a chat!
