Banks, insurance companies, investment firms, payment institutions, and crypto-asset service providers operating in the EU. Also applies to their critical ICT third-party service providers (cloud platforms, SaaS vendors, data analytics providers). DORA entered into force in January 2023 and became applicable on January 17, 2025. Any technology vendor selling to EU financial institutions needs to understand DORA requirements.
DORA (Digital Operational Resilience Act) is an EU regulation that sets strict requirements for how financial institutions and their technology providers manage ICT risk, handle incidents, and ensure operational resilience. It became applicable on January 17, 2025, after a two-year implementation period.
The regulation exists because the financial sector's growing dependence on technology has created systemic risk. When a bank's cloud provider goes down, it's not just an IT problem. It can disrupt payments, lock people out of their accounts, and cascade through the financial system. DORA addresses this by creating a unified regulatory framework that applies across all EU financial sectors, replacing the patchwork of national rules that existed before.
DORA is binding law, not a voluntary framework. Financial entities that fail to comply face regulatory sanctions from their national competent authorities, and critical ICT providers face direct oversight from the European Supervisory Authorities.
DORA applies to a very wide range of financial entities:
But here's the part that catches technology companies off guard: DORA also applies to "critical ICT third-party service providers" (CTPPs). If your cloud platform, SaaS product, or data analytics service is used by financial entities and designated as critical, you're directly subject to DORA oversight. The European Supervisory Authorities maintain a list of designated CTPPs.
Even non-critical ICT providers aren't off the hook. Financial entities are required to manage their ICT third-party risk, which means your contracts, security practices, and incident reporting capabilities will be scrutinized through your financial customers' compliance programs.
DORA is built around five areas:
1. ICT Risk Management
Financial entities must establish a complete ICT risk management framework. This includes identifying and classifying all ICT assets and dependencies, implementing protection and prevention measures, maintaining detection capabilities, and having response and recovery procedures. The management body (board of directors or equivalent) is directly responsible for approving and overseeing the ICT risk management framework. This isn't something that can be delegated entirely to IT.
2. ICT-Related Incident Management and Reporting
Financial entities must classify ICT incidents using criteria defined in the regulation (data losses, duration, geographic spread, economic impact). Major incidents must be reported to national competent authorities using standardized templates and timelines:
This reporting structure is more prescriptive than most existing frameworks.
3. Digital Operational Resilience Testing
All financial entities must conduct regular testing: vulnerability assessments, network security testing, gap analyses, and scenario-based testing. For larger, systemically important entities, DORA requires Threat-Led Penetration Testing (TLPT) at least every three years, based on the TIBER-EU framework. TLPT simulates real-world attack scenarios against live production systems, which goes well beyond standard penetration testing.
4. ICT Third-Party Risk Management
Financial entities must maintain a register of all ICT third-party arrangements, conduct due diligence before engaging providers, and include specific contractual provisions covering security requirements, audit rights, exit strategies, and incident reporting. Key contractual elements are prescribed in the regulation, meaning financial entities can't negotiate them away.
For CTPPs, the regulation goes further: European Supervisory Authorities have direct oversight powers, including the ability to conduct inspections, issue recommendations, and impose penalties.
5. Information Sharing
DORA encourages (but doesn't require) financial entities to share cyber threat intelligence with each other. This is intended to improve collective defense. Participation in information-sharing arrangements is voluntary, but the framework for doing so is established in the regulation.
DORA stands apart from other frameworks in several ways:
It's sector-specific and legally binding. Unlike NIST CSF or ISO 27001, DORA isn't a general-purpose framework you choose to adopt. It's law, specific to financial services, with regulatory enforcement.
It regulates technology providers directly. Most compliance frameworks only apply to the organization seeking compliance. DORA extends regulatory authority to critical third-party providers, giving EU supervisors the power to oversee cloud providers and SaaS vendors that serve the financial sector.
It emphasizes resilience, not just security. The focus isn't just on preventing incidents but on ensuring the financial entity can continue operating through them and recover quickly. This shifts the conversation from "are we secure?" to "can we survive a major disruption?"
Board-level accountability. DORA explicitly requires the management body to take responsibility for ICT risk. Board members need sufficient knowledge of ICT risks, and they're accountable for the risk management framework. This isn't just a recommendation; it's a regulatory expectation.
DORA compliance costs vary enormously by entity size and type:
The ongoing costs are also significant. Threat-led penetration testing alone can cost $100,000-$300,000 per engagement. Maintaining the required ICT third-party registers, incident reporting infrastructure, and resilience testing programs adds recurring expense.
For technology vendors selling to EU financial institutions, the costs come through contractual compliance: meeting the prescribed contractual terms, providing audit access, adapting incident reporting to match DORA timelines, and potentially being subject to direct regulatory oversight.
Compliance automation platforms can help with several DORA requirements: maintaining ICT asset inventories, tracking third-party risk across vendors, monitoring security controls continuously, and managing incident classification and reporting workflows.
However, DORA's requirements are more operationally demanding than typical compliance frameworks. Threat-led penetration testing, board-level governance documentation, and the detailed contractual provisions for ICT providers go beyond what most compliance tools cover out of the box.
Of the 17 tools in our database, 8 currently support DORA. The framework is new enough that tool coverage is still catching up. Companies subject to DORA should verify that their chosen platform's DORA module covers the specific pillars relevant to their situation.
Treating DORA as an IT compliance exercise. DORA explicitly requires board-level ownership of ICT risk management. Delegating it entirely to the CISO or IT department misses the regulatory intent and creates governance gaps that supervisors will notice.
Underestimating the third-party management burden. Maintaining a complete register of ICT arrangements, with all the detail DORA requires, is a significant ongoing effort. Many organizations discover they have far more third-party ICT dependencies than they realized.
Assuming existing frameworks cover it. Having ISO 27001 or SOC 2 gets you part of the way, but DORA has specific requirements around incident reporting timelines, TLPT, contractual provisions, and information sharing that those frameworks don't address.
Ignoring the impact on procurement. DORA's prescribed contractual terms mean existing vendor agreements likely need renegotiation. This affects procurement processes, legal review timelines, and vendor relationships. Starting late on contract remediation creates a bottleneck.
Technology vendors waiting to be told. ICT providers serving EU financial clients shouldn't wait for a "critical" designation to start preparing. Financial entity customers are already flowing DORA requirements into vendor contracts. Being ready before customers ask gives you a competitive advantage.
| Platform | Starting Price | Best For | G2 Rating |
|---|---|---|---|
| Vanta | ~$10,000/yr | Compliance automation | 4.6 |
| Drata | ~$7,500/yr | Compliance automation | 4.8 |
| Secureframe | ~$7,500/yr | Compliance automation | 4.7 |
| Hyperproof | ~$12,000/yr | GRC platform | 4.5 |
| Sprinto | ~$6,000/yr | Compliance automation | 4.8 |
| Strike Graph | ~$9,000/yr | Compliance automation | 4.7 |
| Scrut Automation | ~$15,000/yr | GRC platform | 4.9 |
| Oneleet | ~$12,000/yr | Mixed | 4.9 |