The Digital Operational Resilience Act (DORA) came into full application in January 2025. For financial institutions across the EU—banks, insurers, investment firms, payment services providers—DORA is now binding law. For non-financial companies that provide technology services to these institutions, DORA is equally critical because your customers are contractually obligated to manage risks associated with your services, and they will demand proof of your compliance.
Many organizations are still in a reactive scramble. Some still believe DORA is “like the previous regulatory regime but stricter.” It isn’t. DORA fundamentally reorganizes how financial institutions approach operational resilience. It creates new categories of risk, new reporting obligations, and new liability for both financial institutions and their ICT service providers.
This guide is built on real-world implementation experience. We’ve worked with dozens of financial institutions and their ICT vendors navigating DORA. The patterns are consistent: organizations that move quickly, understand DORA’s five pillars, and act on third-party risk management establish a sustainable compliance foundation. Those that drag their feet face repeated regulatory inquiries and customer pressure.
What Is DORA? Digital Operational Resilience Act
DORA is an EU regulation—not a directive—which means it applies directly and uniformly across all member states. It was adopted in December 2022, a Regulation on digital operational resilience for the financial sector (EU 2023/2821).
DORA’s purpose is to strengthen the financial sector’s ability to withstand, respond to, and recover from ICT failures and shocks. The 2008 financial crisis illustrated the systemic risk of tightly interconnected financial institutions. Since then, cyber incidents affecting banks, payment networks, and insurance companies have grown more frequent and more severe. DORA exists because regulators concluded that traditional risk management frameworks—designed for market risk, credit risk, and operational risk—didn’t adequately address digital and cyber threats.
Unlike NIS2, which is sector-agnostic (applying to energy, water, healthcare, and other critical infrastructure), DORA is lex specialis—specialized law for financial services. It supersedes and complements existing regulatory requirements like MiFID II, PSD2, and the European Banking Authority’s guidelines.
DORA distinguishes between financial entities (who must comply with most of its requirements) and ICT third-party service providers (who have specific obligations around resilience and transparency).
Who Does DORA Apply To?
DORA’s scope is deliberately broad because the financial sector is deeply interconnected and dependent on ICT.
Financial Entities
DORA applies to:
– Credit institutions (banks, building societies, credit unions)
– Investment firms (brokers, advisors, trading venues, asset managers)
– Insurance and reinsurance undertakings
– Payment institutions and account information service providers
– Electronic money institutions
– Central counterparties and trade repositories
– Managers of alternative investment funds
– Crypto-asset service providers
The scope is intentionally wide. Even small payment institutions or niche investment firms fall within DORA.
ICT Third-Party Service Providers
Critically, DORA extends obligations to non-financial companies that provide ICT services. This includes:
– Cloud service providers (AWS, Azure, Google Cloud, etc.)
– Software vendors (SaaS platforms, trading systems, data analytics)
– Managed service providers and MSPs
– Telecommunications providers (connectivity, VoIP, etc.)
– Outsourced IT support vendors
– Cybersecurity service providers
Even non-EU vendors are in scope if they provide ICT services to EU financial entities. A US-headquartered SaaS company providing accounting software to EU banks is subject to DORA. This extraterritorial reach is significant.
Proportionality and Carve-Outs
DORA does include some flexibility. Microenterprises (fewer than 10 employees, less than €2 million annual revenue) have reduced obligations on some requirements. Very small insurance companies and pension funds have a limited exemption. But these exceptions are narrow. Most organizations in financial services and most ICT vendors should assume full DORA applicability.
The Five Pillars of DORA
DORA is organized around five interconnected pillars. Understanding them is the key to structuring a compliant program.
Pillar 1: ICT Risk Management
This is the foundation. Financial entities must establish a comprehensive ICT risk management function that identifies, assesses, and mitigates risks to their information systems, networks, and the continuity of critical services.
Key components:
– ICT risk identification and assessment : Document and regularly update your understanding of ICT risks—both threats (external and internal) and vulnerabilities in your systems. Consider ransomware, zero-day exploits, nation-state threats, supply chain compromise, and internal mistakes.
– ICT risk mitigation : Implement technical, organizational, and procedural controls to reduce identified risks. This includes standard information security controls (access management, encryption, segmentation) but also DORA-specific requirements like advanced monitoring and cryptography strength.
– Governance and oversight : Board and management-level oversight of ICT risk, with documented roles, responsibilities, and escalation procedures.
– Business continuity and disaster recovery : Defined recovery objectives, tested procedures, alternate processing capabilities, and documented recovery time objectives (RTO) and recovery point objectives (RPO).
– Third-party risk management : (Covered in depth below—this is Pillar 4, but it’s central to ICT risk management.)
Pillar 2: ICT-Related Incident Management and Reporting
DORA requires financial entities to detect, respond to, and report ICT incidents with defined timelines and severity thresholds.
The incident classification system:
Incidents are classified as “significant” based on quantitative and qualitative criteria:
– Availability impact : Systems unavailable for more than 4 hours
– Confidentiality impact : Unauthorized disclosure of sensitive data (amount and type matter)
– Integrity impact : Unauthorized modification or deletion of systems or data
– Financial impact : Losses exceeding €30,000
– Affected customers : More than 1,000 retail customers or 100 institutional customers experience service degradation
– Reputational impact : Public awareness of the incident affecting market confidence
An incident meeting any of these thresholds is significant.
Reporting timelines:
– 4-hour notification : Financial entities must notify their regulator within 4 hours of identifying a significant incident
– 24-hour initial report : Within 24 hours, submit an initial incident report including: what happened, when, affected systems, estimated impact, actions taken
– 1-month detailed report : Within 30 days, submit a comprehensive forensic report with root cause analysis, timeline, remediation, and lessons learned
These timelines are strict. Four hours sounds daunting, but it’s achievable if your organization has automated monitoring and documented incident response procedures. The expectation is rapid detection and escalation, not a complete forensic investigation in four hours.
Cross-border coordination:
If an incident affects financial entities or critical infrastructure in multiple member states, regulators may coordinate responses. DORA requires information-sharing with relevant authorities in other countries.
Pillar 3: Digital Operational Resilience Testing
DORA mandates testing of your resilience, and the testing must be rigorous and realistic.
Threat-led penetration testing (TLPT):
At least annually, and more frequently for systemic or critical institutions, financial entities must conduct “threat-led penetration tests”—realistic simulations of cyber attacks designed to test whether your defenses and incident response actually work.
The test must:
– Be conducted by an external, qualified security firm (your own pentester isn’t sufficient)
– Target your critical information systems and critical operational functions
– Assume realistic threat scenarios (e.g., a nation-state trying to exfiltrate data, an insider making malicious changes)
– Include social engineering, malware, and advanced attack techniques
TLPT is not the same as annual vulnerability scanning. It’s a full adversarial engagement designed to find weaknesses in both technology and processes.
Advanced scenario testing:
In addition to TLPT, financial entities must conduct scenario-based testing of business continuity and incident response. This includes:
– Simulations of complete data center failure
– Testing of backup and recovery procedures
– Communication and escalation testing
– Supply chain disruption scenarios
Lessons learned process:
After any significant test, a formal lessons-learned process must be conducted. Identified gaps must be remediated, and testing procedures refined based on what’s learned.
Pillar 4: ICT Third-Party Risk Management
This pillar deserves special attention because it’s where many organizations struggle. DORA places significant responsibility on financial entities for managing risks from their ICT vendors.
Critical third-party designation:
DORA introduces the concept of a “critical ICT third-party”—a vendor whose failure would disrupt critical functions of a financial entity. Financial entities must identify which vendors are critical (typically cloud providers, core banking systems, payment processors).
For critical third-parties:
– Enhanced due diligence is required before engagement
– Contractual requirements are strict (see below)
– Right to audit and inspect the vendor’s security controls is mandatory
– Incident notification requirements are defined
– Exit strategies (how you’d move away from the vendor if necessary) must be documented
Contractual requirements:
DORA mandates specific contractual clauses with all ICT service providers:
– Security requirements : Vendor must meet security standards consistent with DORA
– Subcontracting : If vendor subcontracts (e.g., cloud provider using another cloud provider for redundancy), you must be informed and must approve critical subcontractors
– Incident notification : Vendor must notify you of incidents affecting your systems within one business day
– Audit and inspection rights : You have the right to conduct security audits of the vendor
– Confidentiality : Vendor must protect your data and maintain confidentiality
– Exit and data return : Upon termination, vendor must return or securely delete all your data
– Location of processing : Vendor must be transparent about where your data is processed and stored
Vendor monitoring and testing:
Ongoing vendor management includes:
– Annual security assessments of critical vendors (in-house assessment, vendor self-assessment, or third-party audit)
– Continuous monitoring of vendor security (subscription to threat feeds, incident reports, vulnerability alerts)
– Regular communication channels for incident escalation
– Documentation of vendor compliance status and any remediation activities
Multi-vendor resilience:
Financial entities must avoid single points of failure with respect to critical vendors. If your organization depends entirely on one cloud provider, for instance, regulatory expectation is that you have a documented strategy to reduce this dependency or have tested failover to an alternative provider.
Pillar 5: Information Sharing
DORA encourages and facilitates the sharing of cyber threat information among financial entities and between financial entities and competent authorities.
Financial entities may share information about:
– Cyber threats and attacks they’ve experienced
– Indicators of compromise (malware hashes, suspicious IP addresses, etc.)
– Vulnerabilities and mitigation strategies
– Best practices and lessons learned
Information sharing happens through established channels:
– Sector-specific Information Sharing and Analysis Centers (ISACs)
– Regulatory reporting channels
– Public vulnerability databases
– Industry conferences and forums
Entities must remove personal data before sharing (GDPR compliance) and verify the accuracy of shared information.
DORA’s ICT Third-Party Risk Requirements: What SaaS Providers and Cloud Vendors Need to Know
If your organization is a non-financial ICT vendor providing services to EU financial institutions, DORA creates concrete obligations for you.
Contractual responsibility:
Your customers (the financial entities) will insert DORA-required clauses into contracts with you. These clauses obligate you to:
– Maintain security controls meeting regulatory standards
– Notify customers of security incidents within one business day
– Allow customer audits of your security controls
– Maintain detailed technical documentation of your services
– Provide transparency on data locations and processing
– Support your customers’ business continuity planning
– Facilitate exit and data recovery if the customer decides to leave
Documentation and transparency:
You must maintain detailed technical documentation of your services, including:
– Architecture and data flow diagrams
– Security control descriptions
– Incident response procedures
– Backup and disaster recovery capabilities
– Geographic redundancy and failover procedures
When a financial entity customer requests this documentation, you must provide it. This is a concrete burden, especially if you’re a small SaaS vendor.
Incident notification:
If you experience a security incident affecting your customers’ data or service availability, you must notify all affected customers within one business day. This applies even if the incident is resolved quickly. The notification should include:
– What happened (incident summary)
– When it occurred
– How many of their systems or data were affected
– What measures you’ve taken to contain and remediate
Supply chain obligations:
You may not subcontract critical functions without your customer’s approval. If you do subcontract, your customer must know and must approve the subcontractor. This creates a chain of responsibility: if your subcontractor has a security incident, you’re responsible for notifying your customer.
Audit and inspection:
Financial entity customers have the right to audit your security controls. This includes on-site inspections of your facilities, review of your security documentation, and potentially third-party audits conducted on behalf of your customer. You should expect at least one audit per year from significant customers.
The practical implication:
If you’re a SaaS vendor serving financial institutions, you need:
– Formalized incident response procedures with documented timelines
– Security documentation and architecture diagrams maintained and updated
– Annual third-party security assessments (SOC 2, ISO 27001, or equivalent)
– Customer communication procedures for incident notification
– Subcontractor management and approval processes
– Audit response procedures and documentation
Many vendors are unprepared for this level of scrutiny. Building a DORA-compliant vendor management program is now table stakes for success in financial services.
DORA Incident Reporting Timelines (The 4-Hour, 24-Hour, 1-Month Schedule)
DORA’s incident reporting is notably different from GDPR’s data breach notification and NIS2’s reporting requirements. It’s worth understanding the distinctions.
DORA’s timeline:
– 4 hours : Initial notification to regulator (identification of significant incident)
– 24 hours : Detailed incident report including impact assessment
– 30 days : Final report with root cause analysis and remediation
GDPR’s timeline (for context):
– Without undue delay , typically 72 hours: Notification to regulators if there’s risk to personal data
– Reasonable time : Notification to affected individuals
NIS2’s timeline (for context):
– 24 hours : Early warning to competent authority
– 72 hours : Detailed incident notification
– Open-ended: Final report once investigation is complete
The implication:
DORA’s 4-hour initial notification is the tightest timeline in European regulation. It requires:
– Continuous monitoring to detect incidents rapidly
– Documented escalation procedures
– 24/7 on-call incident response leadership
– Clear definition of what constitutes a “significant” incident
– Regular testing of incident response procedures to ensure you can actually meet timelines
Many organizations initially thought the 4-hour requirement was impossible. It’s not. Entities with mature security operations centers (SOCs) and incident response programs consistently meet it. Entities without mature monitoring infrastructure struggle.
DORA vs. NIS2: Key Differences
Both regulations require cybersecurity governance, risk management, and incident reporting. But they’re not identical.
Scope:
– DORA: Financial services only
– NIS2: Critical infrastructure across multiple sectors (energy, transport, water, healthcare, manufacturing, etc.) plus some critical digital services
Applicability to vendors:
– DORA: Explicitly applies to ICT third-party service providers, creates contractual obligations
– NIS2: Generally applies only to entities in covered sectors, though supply chain management is required
Incident reporting:
– DORA: 4-hour initial, 24-hour detailed, 30-day final
– NIS2: 24-hour early warning, 72-hour notification, final report after investigation
Testing:
– DORA: Mandatory threat-led penetration testing (TLPT) at least annually
– NIS2: Risk assessments and testing required but not as prescriptive about penetration testing
Personal liability:
– DORA: Board members and senior managers can face personal liability
– NIS2: More explicit on personal liability and criminal consequences in some member states
If you’re in financial services and subject to both:
Practical approach is to build a program that meets the stricter requirement. DORA’s requirements typically exceed NIS2’s in financial services context. A DORA-compliant program will likely satisfy NIS2 obligations, but map them carefully because timelines and incident classification criteria differ.
DORA Compliance Checklist: Where to Start
If your organization is subject to DORA (either as a financial entity or ICT vendor), here’s a practical roadmap:
Month 1-2: Understand scope and initial assessment
– Confirm whether organization is within DORA scope
– Identify critical information systems and critical operational functions
– Identify ICT third-party service providers (especially critical ones)
– Assess current security posture and maturity level relative to DORA requirements
Month 2-3: Governance and leadership alignment
– Ensure board/senior management understands DORA obligations
– Appoint senior executive accountable for DORA compliance (CRO, CISO, or equivalent)
– Establish DORA steering committee with IT, compliance, risk, and business representation
– Document governance structure and accountability
Month 3-6: ICT Risk Management Program
– Conduct comprehensive ICT risk assessment
– Document ICT risk management policies and procedures
– Identify gaps in current controls relative to DORA requirements
– Develop remediation roadmap
– Establish incident response procedures and escalation paths
Month 6-9: Third-Party Management
– Identify and classify critical ICT third-parties
– Audit or assess critical vendor security posture
– Develop or update vendor contracts with DORA-required clauses
– Establish vendor monitoring and incident notification procedures
– Document exit strategies for critical vendors
Month 9-12: Operational Resilience Testing
– Conduct first threat-led penetration test (external vendor)
– Conduct business continuity and disaster recovery testing
– Test incident response procedures (tabletop and full simulation)
– Document testing results and remediation of gaps
Ongoing: Compliance maintenance
– Annual threat-led penetration testing
– Annual vendor security assessments
– Quarterly incident reporting validation (ensure procedures work)
– Regular monitoring of regulatory guidance updates
– Continuous improvement based on testing results and lessons learned
For financial entities, this is a 12+ month program assuming starting from a mature baseline. For organizations with less mature security foundations, extend accordingly.
For ICT vendors, focus initially on documenting your services, securing customer access to documentation, and establishing incident notification procedures. These are the immediate pain points for your customers.
Common DORA Compliance Mistakes
Based on our work with dozens of organizations, here are the most frequent errors:
1. Treating DORA as a checkbox, not a transformation
Some organizations try to achieve DORA compliance through documentation alone—writing policies about resilience without actually building resilience. When tested, their systems fail. DORA requires genuine capability, not paper compliance.
2. Underestimating the 4-hour notification requirement
Organizations with manual incident detection and escalation processes can’t meet the 4-hour timeline. If your incident detection depends on a human noticing something is wrong, you’ll regularly miss the deadline. You need automated monitoring and rapid escalation.
3. Inadequate third-party management
Many financial entities have dozens or hundreds of ICT vendors but haven’t formally assessed their security posture or included DORA-required contractual clauses. This is immediately visible in regulatory examinations. You need a tiered approach: deep assessment of critical vendors, lighter-touch assessment of important vendors, documented justification for why non-critical vendors aren’t assessed extensively.
4. Insufficient incident response testing
Entities that have documented incident response procedures but haven’t tested them regularly discover during real incidents that procedures don’t work. Tabletop exercises and simulations are essential—at least annually, more frequently for critical scenarios.
5. Inadequate documentation for regulators
Regulators expect to see detailed technical documentation: architecture diagrams, data flow diagrams, control descriptions, testing results, vendor assessments. Many organizations have this information scattered across emails and system notes. You need consolidated, maintained documentation.
6. Assuming old security practices are sufficient
Some organizations think DORA compliance is just “better security.” But DORA is specific. It requires threat-led penetration testing. It requires documentation of critical functions and recovery objectives. It requires particular contractual language. Old security practices, done well, still don’t address these DORA-specific requirements.
7. Neglecting board and senior management involvement
DORA explicitly requires board-level oversight. Some organizations delegate DORA to a compliance officer without meaningful board engagement. Regulators notice. Board papers should include DORA metrics, incident data, test results, and third-party risk assessments.
How Soter Advisory Can Help
DORA compliance is technically challenging and operationally demanding. We work with financial entities and their ICT vendors at every stage of the compliance journey.
For financial entities, we help with:
– DORA compliance assessment and roadmapping
– ICT risk management program design and implementation
– Incident response procedure development and testing
– Third-party risk assessment and vendor management
– Threat-led penetration testing coordination and interpretation
– Business continuity and disaster recovery planning
– Regulatory reporting and documentation
For ICT vendors serving financial institutions, we help with:
– Documentation and transparency programs
– Incident response procedures aligned with customer requirements
– Audit readiness and SOC 2 / ISO 27001 preparation
– Subcontractor and supply chain management
– Customer communication and escalation procedures
If you’re facing DORA deadlines, have questions about third-party obligations, or want to ensure your incident response procedures will actually work, we’re here to help.
Conclusion
DORA represents a marked increase in regulatory expectation around operational resilience in financial services. It’s not optional, it’s not negotiable, and it’s not something you can achieve through documentation alone.
The organizations that have moved fastest to DORA compliance share certain characteristics: they’ve involved their boards and senior management, they’ve been honest in their risk assessments, they’ve tested their resilience through realistic scenarios, and they’ve treated compliance as an opportunity to genuinely strengthen their operational posture.
The organizations that are struggling are those that treated DORA as a compliance checkbox, assuming old security practices would suffice. They’re discovering that regulators are thorough and that “we thought we had resilience” isn’t acceptable when reality tells a different story.
Your incident response must be fast. Your third-party management must be rigorous. Your testing must be realistic. Your documentation must be detailed and maintained. Your board must be engaged. These are the ingredients of genuine DORA compliance.
Need help navigating DORA? Soter Advisory works with companies at every stage—from initial assessment through full implementation and ongoing compliance. Book a free consultation →