DORA Compliance: The Complete Guide to the Digital Operational Resilience Act for Financial Services and Their Tech Providers

On January 17, 2025, the Digital Operational Resilience Act became enforceable across the entire European Union. For the first time, a single regulation imposed binding, harmonized requirements on how financial entities and their technology providers manage ICT risk, report cyber incidents, test operational resilience, and govern third-party technology dependencies.

Before DORA, a bank operating across six EU member states navigated six different sets of ICT risk rules -- each with its own reporting timelines, testing expectations, and enforcement mechanisms. A fintech providing payment processing across the EU faced a patchwork of supervisory expectations that varied by country and regulator. A cloud provider serving dozens of financial institutions had no direct regulatory obligations under financial services law, even though a failure in its services could destabilize multiple institutions simultaneously.

DORA changed all of that. It created a single, comprehensive framework for digital operational resilience across the EU financial sector -- and, critically, it extended direct regulatory oversight to the technology companies that financial institutions depend on.

If your organization is a financial entity operating in the EU, or a technology provider serving EU financial clients, DORA compliance is not optional. It is a legal requirement with substantial penalties for non-compliance. This guide covers everything you need to understand: what DORA requires, who it applies to, how its five pillars work in practice, what the penalties are, how it maps to frameworks you may already hold, and what you need to do to achieve and maintain compliance.

What Is DORA? (The Digital Operational Resilience Act)

DORA -- Regulation (EU) 2022/2554 -- is a European Union regulation that establishes uniform requirements for the security of network and information systems supporting the business processes of financial entities. It was adopted by the European Parliament and Council in November 2022 and became applicable on January 17, 2025, after a two-year implementation period.

The regulation addresses a straightforward but increasingly urgent problem: the financial sector's growing dependence on information and communication technology (ICT) creates systemic risks that existing, fragmented national rules were not designed to manage. A major ICT disruption at a single institution -- or, more dangerously, at a technology provider serving multiple institutions -- can cascade through the financial system in ways that threaten financial stability itself.

DORA's solution is to treat digital operational resilience as a core prudential requirement for the financial sector, on par with capital adequacy and liquidity requirements. Financial entities must be able to withstand, respond to, and recover from ICT-related disruptions and threats. And the technology providers they depend on must meet defined standards of resilience, security, and oversight.

Key characteristics of DORA

It is a regulation, not a directive. Unlike many EU legislative instruments, DORA applies directly in all 27 EU member states without requiring national transposition. This eliminates the fragmentation that previously resulted from member states implementing ICT risk directives differently.

It applies to financial entities and their ICT providers. DORA's scope extends beyond traditional financial regulation by bringing critical ICT third-party service providers (CTPPs) under direct regulatory oversight through a new EU-level oversight framework.

It is principle-based with prescriptive elements. DORA establishes high-level requirements in the regulation itself, supplemented by Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the European Supervisory Authorities (ESAs) -- the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA). These technical standards provide detailed, prescriptive requirements for implementation.

It is proportionate. DORA applies requirements proportionally based on the size, nature, scale, and complexity of the financial entity. Microenterprises and certain smaller entities face simplified requirements, though the core obligations remain.

Who Must Comply with DORA?

DORA's scope is broader than many organizations initially expect. It covers virtually the entire EU financial sector and, for the first time, extends direct oversight to the technology companies that sector depends on.

Financial entities subject to DORA

DORA applies to 21 categories of financial entities, including:

Credit institutions (banks)
Payment institutions and electronic money institutions
Investment firms and central securities depositories
Trading venues, central counterparties, and trade repositories
Insurance and reinsurance undertakings
Insurance intermediaries and pension funds
Credit rating agencies and securitization repositories
Managers of alternative investment funds and management companies
Crypto-asset service providers and issuers of asset-referenced tokens
Crowdfunding service providers
Data reporting service providers

The list is deliberately comprehensive. If your organization holds a financial services authorization in any EU member state, or operates under any EU financial services directive or regulation, DORA almost certainly applies to you.

ICT third-party service providers

This is where DORA breaks new ground. Any company that provides ICT services to a financial entity covered by DORA falls within the regulation's scope -- at least indirectly, through the contractual requirements that financial entities must impose on their ICT providers.

ICT service providers in this context include:

Cloud service providers (AWS, Azure, GCP, and specialized financial cloud providers)
SaaS platforms used for core banking, payments, compliance, risk management, or customer operations
Data analytics and processing providers
Managed security service providers (MSSPs) and SOC-as-a-service vendors
Core infrastructure providers (data centers, network services, telecom)
Software vendors whose products are embedded in critical financial processes

Critical ICT third-party service providers (CTPPs)

DORA creates a special category: Critical ICT Third-Party Service Providers. The ESAs designate CTPPs based on the systemic importance of the services they provide to the financial sector -- considering factors such as the number and type of financial entities they serve, the criticality of the processes those entities depend on them for, and the degree of substitutability of the provider.

CTPPs are subject to a new EU-level Oversight Framework, led by a designated Lead Overseer from among the three ESAs. This is a fundamental shift: for the first time, technology companies are subject to direct prudential-style supervision under EU financial services law, regardless of whether they hold a financial services license.

The 5 Pillars of DORA Compliance

DORA is structured around five interconnected pillars. Together, they form a comprehensive framework for digital operational resilience. Understanding each pillar is essential for scoping your compliance program.

Pillar 1: ICT Risk Management

The foundation of DORA. Financial entities must establish and maintain a comprehensive ICT risk management framework that is documented, subject to regular review, and integrated into the entity's overall risk management system. This pillar covers everything from governance and organizational structure to specific technical requirements for protection, detection, response, and recovery.

Financial entities must implement processes to detect, manage, classify, and report major ICT-related incidents to their competent authority. DORA standardizes classification criteria and reporting timelines across the EU, replacing the patchwork of national reporting requirements that previously existed.

Pillar 3: Digital Operational Resilience Testing

Financial entities must establish and maintain a risk-based testing program to assess their preparedness for ICT-related disruptions. For significant financial entities, this includes advanced threat-led penetration testing (TLPT) at least every three years.

Pillar 4: ICT Third-Party Risk Management

Financial entities must manage and monitor the risks arising from their use of ICT third-party service providers throughout the entire lifecycle of the relationship. DORA imposes specific contractual requirements, concentration risk analysis, and exit strategy obligations. Critical ICT providers face direct oversight.

DORA encourages -- but does not mandate -- financial entities to exchange cyber threat intelligence and information among themselves and with competent authorities. This pillar recognizes that collective defense strengthens individual resilience.

DORA ICT Risk Management Requirements

Pillar 1 is the most extensive element of DORA and the one that demands the most significant operational changes for many organizations. The ICT risk management framework required by DORA is comprehensive, prescriptive, and must be embedded into the entity's governance structure.

Governance and organizational requirements

DORA places explicit responsibility for ICT risk management at the highest level of the organization. The management body (board of directors or equivalent) must:

Define, approve, oversee, and bear ultimate responsibility for the implementation of the ICT risk management framework
Set clear roles and responsibilities for all ICT-related functions, including those delegated or outsourced
Allocate and periodically review the budget for ICT security, including awareness programs and training
Be informed at least annually about major ICT risk findings, testing results, and the entity's overall ICT risk profile
Undertake specific training on ICT risk, proportionate to the risk profile of the entity

This is not a formality. DORA makes the management body personally accountable for ICT risk management. Members who fail to fulfil these responsibilities may face individual penalties.

ICT risk management framework requirements

The framework itself must include policies, procedures, and tools that address the following areas:

Identification. Financial entities must identify, classify, and document all ICT-supported business functions, information assets, and ICT assets. They must maintain an up-to-date inventory, identify all sources of ICT risk, assess the risks, and define the entity's risk appetite for ICT risk. They must also identify all dependencies on ICT third-party service providers.

Protection and prevention. Based on the risk assessment, entities must implement appropriate ICT security policies and tools to protect ICT systems and data. This includes:

Policies governing access management, authentication, encryption, and network security
Patch management and vulnerability management processes
Data protection and data loss prevention measures
Physical security of ICT systems and data centers
Security awareness and training programs for all staff

Detection. Entities must implement mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. This requires continuous monitoring of ICT systems and networks, with clearly defined alert thresholds and incident detection criteria.

Response and recovery. Entities must establish, document, and test ICT business continuity plans and ICT response and recovery plans. These must include:

Communication plans for internal and external stakeholders, including competent authorities
Procedures for backup, restoration, and recovery of ICT systems and data
Procedures to ensure the continuity of critical or important functions during and after ICT disruptions
Estimates of recovery time and recovery point objectives for critical functions
Arrangements for crisis management, escalation, and communication

Learning and evolving. Entities must collect and analyze post-incident information and integrate lessons learned into the ICT risk management framework. Vulnerabilities and threats identified through incident analysis, testing, and threat intelligence must drive continuous improvement of the framework.

Proportionality in ICT risk management

DORA applies a proportionality principle. Microenterprises (fewer than 10 employees, annual turnover or balance sheet below EUR 2 million) benefit from a simplified ICT risk management framework. They must still address the core requirements but are exempt from the most granular obligations around governance, testing, and documentation.

However, proportionality does not mean exemption. Even smaller financial entities must maintain an ICT risk management framework, conduct risk assessments, implement basic protections, and report major incidents.

DORA Incident Reporting: Classification and Notification Timelines

DORA establishes a harmonized incident reporting regime across the EU financial sector, replacing the inconsistent national reporting requirements that previously complicated cross-border operations.

What constitutes a reportable incident under DORA

Financial entities must classify ICT-related incidents based on criteria defined in the DORA Regulatory Technical Standards. The classification criteria include:

Number of clients, financial counterparts, and transactions affected
Duration of the incident
Geographical spread of the impact
Data losses (availability, authenticity, integrity, or confidentiality)
Criticality of services affected -- whether the incident impacts critical or important functions
Economic impact -- direct and indirect costs, including financial losses and regulatory costs

An incident is classified as major if it meets defined thresholds across one or more of these criteria. Only major ICT-related incidents trigger the mandatory reporting obligation, though entities must classify and document all incidents regardless of severity.

Reporting timelines

DORA requires a three-stage reporting process for major incidents:

Report	Deadline	Content
Initial notification	Within 4 hours of classifying the incident as major (and no later than 24 hours after detection)	Basic facts: type of incident, affected services, initial impact assessment
Intermediate report	Within 72 hours of the initial notification	Updated information: root cause (if known), impact assessment, containment measures, recovery status
Final report	Within 1 month of the last intermediate report	Complete analysis: confirmed root cause, full impact assessment, remediation actions, lessons learned

These timelines are significantly more compressed than many existing national reporting requirements. The 4-hour classification and 24-hour notification window, in particular, requires financial entities to have mature incident detection, classification, and escalation processes that can operate around the clock.

Significant cyber threats

DORA also introduces a voluntary reporting mechanism for significant cyber threats -- threats that the entity determines could materially affect the financial system, even if they have not yet resulted in an actual incident. This is separate from the mandatory incident reporting obligation.

Reporting infrastructure

Reports must be submitted to the entity's competent authority (the relevant national financial regulator). The ESAs are developing a centralized reporting hub to standardize the format and enable EU-level aggregation and analysis of incident data.

For companies already managing incident response plans under frameworks like SOC 2 or ISO 27001, the DORA reporting requirements add a regulatory reporting layer on top of existing incident management processes. The underlying detection, classification, and response capabilities are complementary, but the specific classification criteria and reporting timelines must be implemented separately.

DORA Resilience Testing: TLPT and Scenario-Based Testing

DORA requires financial entities to establish and maintain a comprehensive digital operational resilience testing program. This goes beyond the periodic vulnerability scanning or annual penetration testing that many organizations are accustomed to.

The general testing program

All financial entities subject to DORA must establish a testing program that is proportionate to their size, business profile, and risk profile. The testing program must include:

Vulnerability assessments and scans of ICT systems and networks
Open-source analyses -- review of publicly available information that could be used to attack the entity
Network security assessments -- evaluation of network architecture, configurations, and traffic flows
Gap analyses -- comparison of existing controls against relevant standards and best practices
Physical security reviews of ICT assets and data centers
Scenario-based tests -- simulations of plausible ICT disruption scenarios, including cyberattacks, to assess the entity's response and recovery capabilities
Compatibility testing -- validation that ICT system changes do not introduce operational disruption
Performance testing -- evaluation of ICT system capacity under stress conditions
End-to-end testing of critical business processes, including dependencies on ICT third-party service providers
Penetration testing -- active testing of ICT system defenses against simulated attacks

The results of all testing activities must be documented, analyzed, and used to drive improvements in the ICT risk management framework. Testing must be conducted by qualified, independent parties -- either internal teams with sufficient expertise and independence or external testing providers.

Threat-Led Penetration Testing (TLPT)

For significant financial entities -- those identified by competent authorities based on their systemic importance, size, or criticality -- DORA mandates advanced Threat-Led Penetration Testing at least every three years.

TLPT under DORA follows the TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming), which the ECB originally developed for the banking sector. Key requirements:

Threat intelligence-led. The test must be based on real, current threat intelligence specific to the entity being tested. A threat intelligence provider analyzes the entity's threat landscape and develops realistic attack scenarios.
Red team execution. An independent red team (external testers, not the entity's own security team) executes the scenarios against the entity's live production systems, not test environments.
Scope includes critical functions. TLPT must cover the entity's critical or important functions, including those supported by ICT third-party service providers. Where a critical function depends on an external provider, the provider may need to participate in or support the test.
Blue team unaware. The entity's defensive security team (blue team) must not be informed of the test in advance, to ensure the test evaluates genuine detection and response capabilities.
Supervised by the competent authority. TLPT is conducted under the oversight of the entity's competent authority, which must be notified and may observe or review the test.

TLPT is the most operationally demanding testing requirement in DORA. It requires specialized capabilities, significant coordination, and engagement with qualified external providers. For entities that have not previously conducted TIBER-EU or similar red team exercises, building the capability to meet this requirement takes substantial planning and investment.

DORA Third-Party Risk Management: The Critical ICT Provider Regime

Pillar 4 is, for many organizations, the most transformative element of DORA. It fundamentally changes the relationship between financial entities and their technology providers -- and it creates a new category of directly regulated technology companies.

Contractual requirements for all ICT third-party service providers

DORA mandates that financial entities include specific provisions in their contracts with ICT third-party service providers. These are not optional clauses or best practices -- they are regulatory requirements that must be reflected in binding agreements.

Required contractual provisions include:

Service level descriptions -- clear, measurable descriptions of the services provided, including quantitative and qualitative performance targets
Subcontracting provisions -- requirements for the provider to notify the financial entity of any subcontracting of ICT services supporting critical or important functions, and the entity's right to object
Data provisions -- location of data processing and storage, requirements for data portability and return, and data deletion upon contract termination
Accessibility and audit rights -- the financial entity's right to access, inspect, and audit the provider, including on-site access to the provider's premises, and unrestricted access to relevant documentation
Exit strategies -- detailed plans for transitioning services away from the provider, including adequate transition periods and the provider's obligation to support migration
Cooperation with competent authorities -- the provider's obligation to cooperate fully with the financial entity's competent authority, including allowing on-site inspections
Termination rights -- clear provisions for terminating the contract in specific circumstances, including material breach, provider designation as a CTPP, or supervisory concerns

For organizations familiar with vendor risk management programs under SOC 2 or ISO 27001, DORA's contractual requirements represent a significant escalation. The required provisions go well beyond what most vendor management programs currently address.

Concentration risk

DORA requires financial entities to assess and manage ICT concentration risk -- the risk arising from dependence on a single or limited number of ICT service providers. Entities must consider:

The degree to which critical or important functions depend on a single provider
The substitutability of the provider (whether alternative providers exist and can be engaged within reasonable timeframes)
The potential impact on the entity if the provider fails or experiences a major disruption
The number of other financial entities relying on the same provider

This concentration risk analysis must be documented, reported to the competent authority, and factored into the entity's overall ICT risk assessment.

The CTPP Oversight Framework

The most novel element of DORA is the direct oversight regime for Critical ICT Third-Party Service Providers. CTPPs are designated by the ESAs based on criteria including:

The systemic importance of the financial entities they serve
The degree of dependence of those entities on the provider's services
The substitutability of the provider
The number and type of financial entities and financial market infrastructures served

Once designated as a CTPP, a technology provider is assigned a Lead Overseer -- one of the three ESAs (EBA, EIOPA, or ESMA). The Lead Overseer has substantial powers, including:

Requesting information and documentation about the provider's ICT risk management, security, and operations
Conducting general investigations and on-site inspections of the provider's premises and systems
Issuing recommendations to the provider, including recommendations to strengthen security, improve resilience, or address identified weaknesses
Requiring corrective action -- if the provider does not adequately address recommendations, the Lead Overseer can escalate to formal requests and, ultimately, impose penalties
Publishing the fact of non-compliance -- the Lead Overseer can publicly disclose that a CTPP has failed to comply with recommendations

CTPPs that are established outside the EU must set up a subsidiary within the EU to facilitate oversight. This ensures that EU regulators have jurisdictional reach regardless of where the technology provider is headquartered.

What this means for financial entities

Financial entities cannot outsource their own DORA obligations to their ICT providers. They must maintain oversight of provider compliance, conduct due diligence before entering into new ICT arrangements, negotiate the required contractual provisions, and maintain documented exit strategies. The entity's management body is ultimately responsible for ensuring that ICT third-party risk is appropriately managed.

What this means for ICT providers

Even if an ICT provider is not designated as a CTPP, it faces substantial indirect obligations through the contractual requirements that its financial entity clients must impose. Providers should expect:

More prescriptive contract terms with explicit DORA-mandated provisions
Requests for audit rights, including on-site access
Requirements to support exit strategies and data portability
Notification obligations for subcontracting and material changes
Expectations for incident notification to the financial entity
Potential inclusion in the financial entity's resilience testing program, including TLPT

DORA Penalties and Enforcement

DORA establishes a robust enforcement framework. While the regulation itself does not specify exact penalty amounts (leaving these to national competent authorities), it provides for a range of enforcement actions that include substantial financial penalties.

Penalties for financial entities

National competent authorities can impose administrative penalties and remedial measures on financial entities that fail to comply with DORA, including:

Fines -- member states set the specific amounts, but DORA requires that penalties be "effective, proportionate, and dissuasive." In practice, fines can reach millions of euros for significant breaches.
Orders to cease and desist -- requiring the entity to stop activities that breach DORA requirements
Public statements -- publicly identifying the entity and the nature of the breach
Withdrawal or suspension of authorization -- in extreme cases, competent authorities can revoke the entity's financial services authorization
Temporary bans on members of the management body from exercising management functions

The key enforcement principle is that DORA penalties must be severe enough to change behavior. Given that EU financial regulators have demonstrated willingness to impose significant fines under other regulatory regimes (GDPR, AML/CFT, MiFID II), organizations should expect DORA enforcement to follow a similar trajectory.

Penalties for critical ICT third-party service providers

The Lead Overseer can impose periodic penalty payments on CTPPs that fail to comply with oversight measures. These penalties accrue daily, at a rate of up to 1% of the provider's average daily worldwide turnover in the preceding business year, until compliance is achieved -- for a maximum period of six months.

To put this in perspective: for a large cloud provider with annual worldwide revenues in the tens of billions, 1% of daily turnover represents a penalty of hundreds of thousands or millions of euros per day.

Criminal sanctions

DORA allows member states to impose criminal sanctions for DORA breaches if they choose to do so under national law. Some member states may adopt criminal penalties for the most serious violations, particularly those involving willful non-compliance or negligence that results in systemic harm.

The enforcement trajectory

DORA became enforceable on January 17, 2025. Regulators typically allow an initial period for the industry to adapt, focusing initially on supervisory dialogue and guidance rather than aggressive enforcement. However, the ESAs and national competent authorities have been clear that they expect financial entities to have been preparing during the two-year implementation window and that enforcement will ramp up through 2025 and 2026.

Organizations that have not yet begun their DORA compliance programs are operating with significant regulatory risk.

How DORA Maps to Existing Frameworks (ISO 27001, SOC 2, NIST CSF)

Many organizations subject to DORA already hold certifications or attestations under other information security and compliance frameworks. A critical question for these organizations is: how much of our existing compliance work counts toward DORA?

The answer is nuanced. DORA shares significant conceptual overlap with frameworks like ISO 27001, SOC 2, and NIST CSF, but it also introduces requirements that none of these frameworks fully address. Existing certifications accelerate DORA compliance -- they do not replace it.

DORA to ISO 27001 mapping

The following table maps DORA's core requirements to relevant ISO 27001:2022 Annex A controls:

DORA Requirement	ISO 27001:2022 Control(s)	Gap Analysis
ICT risk management framework	A.5.1 (Policies), A.5.8 (Project management), A.8.8 (Vulnerability management)	ISO 27001 provides a strong foundation but does not require sector-specific financial services risk considerations or the governance-level accountability DORA mandates
Identification and classification of ICT assets	A.5.9 (Inventory), A.5.10 (Acceptable use), A.5.12-5.13 (Classification and labeling)	Strong overlap; ISO 27001 asset management requirements map closely to DORA identification requirements
Protection and prevention	A.5.15-5.18 (Access control), A.8.1 (User endpoints), A.8.5 (Authentication), A.8.9 (Configuration management), A.8.20-8.22 (Network security), A.8.24 (Cryptography)	Substantial overlap in technical controls; DORA may require more granular documentation of specific measures
Detection and monitoring	A.8.15 (Logging), A.8.16 (Monitoring activities), A.5.7 (Threat intelligence)	ISO 27001 addresses detection broadly; DORA requires more specific continuous monitoring capabilities and alert thresholds
Incident management and reporting	A.5.24-5.28 (Incident management)	ISO 27001 covers incident management comprehensively but does not address DORA's specific classification criteria, reporting timelines, or regulatory notification requirements
Business continuity and recovery	A.5.29 (ICT for business continuity), A.5.30 (ICT readiness)	Overlap exists but DORA requirements are more specific, including defined recovery time and point objectives and mandatory continuity testing
Digital operational resilience testing	A.8.8 (Vulnerability management), A.8.34 (Audit of information systems)	ISO 27001 requires periodic testing but does not mandate the breadth of testing DORA requires, and has no TLPT equivalent
ICT third-party risk management	A.5.19-5.23 (Supplier relationships)	ISO 27001 addresses supplier risk but does not require DORA-level contractual provisions, concentration risk analysis, or exit strategy documentation
Information sharing	A.5.6 (Special interest groups)	Minimal overlap; DORA's information sharing framework is more structured and sector-specific

Bottom line: An organization certified to ISO 27001 has a meaningful head start on DORA compliance -- particularly in the areas of risk management methodology, asset management, access control, and incident response. However, substantial gaps remain in governance accountability, reporting timelines, testing depth, and third-party management. ISO 27001 certification alone does not satisfy DORA.

DORA to SOC 2 mapping

DORA Requirement	SOC 2 Trust Services Criteria	Gap Analysis
ICT risk management framework	CC3.1-3.4 (Risk Assessment)	SOC 2 risk assessment criteria align conceptually but are less prescriptive than DORA's detailed framework requirements
Protection and prevention	CC6.1-6.8 (Logical and Physical Access), CC7.1 (System operations)	Strong overlap in access controls and system operations; SOC 2 criteria are outcome-based while DORA specifies particular measures
Detection and monitoring	CC7.2 (Monitoring for anomalies)	Both require monitoring capabilities; DORA is more specific about continuous monitoring and defined alert thresholds
Incident management and reporting	CC7.3-7.5 (Incident identification, response, recovery)	SOC 2 covers incident management but does not include DORA's specific classification criteria, 4-hour reporting window, or three-stage regulatory reporting process
Business continuity	A1.1-A1.3 (Availability criteria)	SOC 2 Availability criteria provide a foundation but are less prescriptive than DORA's continuity and recovery requirements
Change management	CC8.1 (Change management)	Both require structured change management; DORA adds specific requirements for compatibility and performance testing of changes
Third-party risk management	CC9.2 (Vendor risk management)	SOC 2 requires vendor risk management but does not approach the specificity of DORA's contractual requirements, concentration risk analysis, or exit strategies
Resilience testing	Not specifically addressed	SOC 2 does not include mandatory resilience testing, TLPT, or scenario-based testing requirements -- this is a significant gap

Bottom line: SOC 2 attestation provides evidence of mature security controls that support multiple DORA requirements, particularly around access management, monitoring, incident response, and change management. However, SOC 2 was not designed for financial services and does not address DORA's testing, reporting, third-party management, or governance requirements at the depth DORA demands.

DORA to NIST CSF mapping

NIST CSF's six functions (Govern, Identify, Protect, Detect, Respond, Recover) align conceptually with DORA's ICT risk management framework more closely than either ISO 27001 or SOC 2. The Govern function, added in CSF 2.0, directly parallels DORA's governance requirements. The Identify function maps to DORA's asset identification and risk assessment requirements. Protect, Detect, Respond, and Recover map to their DORA counterparts intuitively.

However, NIST CSF is a voluntary framework that describes desired outcomes, not mandatory controls. It does not include DORA's specific reporting timelines, TLPT requirements, contractual provisions for third-party management, or the CTPP oversight regime. NIST CSF provides an excellent strategic foundation for DORA compliance but does not substitute for it.

The practical implication for multi-framework organizations

If your organization already holds ISO 27001, SOC 2, or both, the most efficient path to DORA compliance is a gap analysis that maps your existing controls to DORA's specific requirements. For organizations building a multi-framework compliance strategy, the key areas where DORA adds requirements beyond existing frameworks are:

Governance accountability -- board-level ICT risk responsibilities with personal liability
Incident reporting -- the 4-hour/72-hour/1-month three-stage reporting process
TLPT -- threat-led penetration testing against live production systems
Third-party contractual requirements -- DORA-specific provisions that go beyond standard vendor management
Concentration risk -- formal analysis of ICT provider dependencies
Exit strategies -- documented, tested plans for transitioning away from critical providers

DORA for SaaS and Fintech Companies: What ICT Providers Must Do

If you are a SaaS company, fintech, or technology provider serving EU financial services clients, DORA affects you directly -- whether or not you are designated as a Critical ICT Third-Party Service Provider.

If you are a fintech with an EU financial services license

You are a financial entity under DORA. The full set of DORA requirements applies to you, proportionate to your size and complexity. You must implement the ICT risk management framework, the incident reporting regime, the testing program, and the third-party management requirements. The two-year implementation window has passed. Compliance is expected now.

If you are a SaaS or cloud provider serving EU financial clients

Even without an EU financial services license, your financial entity clients must comply with DORA's third-party risk management requirements. In practice, this means:

Your contracts will need to change. Financial entity clients will require DORA-mandated contractual provisions. If your standard terms do not include provisions for audit rights, data portability, exit support, subcontracting notification, and regulatory cooperation, expect renegotiation requests.

Your security posture must be demonstrable. Financial entities must conduct due diligence before engaging ICT providers and must monitor provider risk on an ongoing basis. You will face more detailed security questionnaires, requests for compliance certifications (ISO 27001, SOC 2), and potentially on-site audit requests.

Your incident response must include client notification. Financial entities need to report major ICT incidents within 4 hours of classification. They cannot do this if their ICT providers do not notify them promptly when incidents occur. Expect contractual requirements for near-real-time incident notification.

Your resilience must be testable. If your services support critical or important functions for a financial entity, you may be asked to participate in the entity's resilience testing program, including scenario-based tests and potentially TLPT.

Your data practices must support exit. DORA requires financial entities to maintain exit strategies for all critical ICT providers. You must be able to demonstrate that your clients can migrate away from your services without unacceptable disruption, data loss, or degradation of service quality.

Practical steps for ICT providers

Identify your financial entity clients. Determine which of your clients are subject to DORA and which of your services support their critical or important functions.
Conduct a contract gap analysis. Review your standard terms against DORA's contractual requirements and develop DORA-compliant contract templates or addenda.
Strengthen your incident notification capabilities. Implement processes to notify financial entity clients of ICT incidents within timeframes that support their 4-hour classification obligation.
Invest in compliance certifications. ISO 27001 and SOC 2 are not substitutes for DORA, but they provide the foundational evidence that financial entity clients need for their due diligence. If you do not already hold these certifications, obtaining them is a practical first step.
Prepare for audit and oversight requests. Establish processes for responding to audit requests, including on-site inspections, from financial entity clients and, potentially, from competent authorities or Lead Overseers.
Document your resilience capabilities. Maintain evidence of business continuity planning, disaster recovery testing, and incident response capability that can be shared with financial entity clients.
Build a third-party risk assessment process for your own sub-processors and subcontractors, as your financial entity clients will require visibility into your supply chain.

DORA Implementation Timeline and Roadmap

The legislative timeline for DORA has already passed its major milestones. Understanding where we are in the enforcement trajectory helps organizations prioritize their compliance efforts.

Key dates

Date	Milestone
September 2020	European Commission publishes DORA legislative proposal
November 2022	DORA adopted by European Parliament and Council
January 16, 2023	DORA enters into force (two-year implementation period begins)
January 17, 2025	DORA becomes applicable and enforceable
2025-2026	ESAs finalize remaining Regulatory Technical Standards and Implementing Technical Standards
2025-2026	ESAs designate the first Critical ICT Third-Party Service Providers
2025 onward	National competent authorities begin supervisory activities and enforcement

Implementation roadmap for financial entities

If your organization has not yet completed DORA implementation, the following phased approach prioritizes the highest-risk compliance gaps:

Phase 1: Foundation (0-3 months)

Conduct a comprehensive DORA gap analysis against current ICT risk management practices
Assign board-level responsibility for ICT risk management and DORA compliance
Establish a DORA compliance program with dedicated resources, budget, and executive sponsorship
Complete an inventory of all ICT-supported business functions, ICT assets, and ICT third-party service providers
Review existing compliance frameworks (ISO 27001, SOC 2, NIST CSF) and map them to DORA requirements

Phase 2: Core Compliance (3-6 months)

Develop or update the ICT risk management framework to meet DORA requirements
Implement or upgrade incident detection, classification, and reporting capabilities to meet DORA timelines
Conduct a contract review of all ICT third-party service provider agreements and initiate renegotiations where gaps exist
Develop ICT concentration risk analysis and document findings
Develop or update ICT business continuity and disaster recovery plans to meet DORA specifications
Implement the vulnerability management processes DORA requires

Phase 3: Testing and Maturity (6-12 months)

Establish and execute the digital operational resilience testing program
Conduct scenario-based tests of ICT disruption scenarios
For significant entities, begin planning for TLPT (engage threat intelligence and red team providers, coordinate with the competent authority)
Develop documented exit strategies for all critical ICT third-party service providers
Implement information sharing arrangements with relevant industry groups and authorities

Phase 4: Continuous Compliance (Ongoing)

Integrate DORA requirements into BAU (business as usual) operations
Conduct regular reviews and updates of the ICT risk management framework (at least annually)
Monitor ESA guidance, RTS/ITS updates, and supervisory expectations for evolving requirements
Maintain ongoing incident classification, reporting, and post-incident analysis
Execute the resilience testing program on defined cycles (TLPT every three years; other testing annually or more frequently)
Report to the management body at least annually on ICT risk profile, testing results, and incident trends

Implementation roadmap for ICT providers

ICT providers serving financial entity clients should prioritize:

Contract readiness -- develop DORA-compliant contract templates and engage legal counsel to review standard terms (immediate priority)
Incident notification -- implement client-facing incident notification processes that support the 4-hour classification window (0-3 months)
Compliance certifications -- if not already holding ISO 27001 or SOC 2, begin the certification process to provide baseline assurance to financial entity clients (3-6 months)
Audit readiness -- prepare for on-site audits and information requests from financial entity clients and competent authorities (ongoing)
Resilience documentation -- develop and maintain evidence of business continuity, disaster recovery, and incident response capabilities (ongoing)

Frequently Asked Questions

Does DORA apply to companies outside the EU?

DORA applies to financial entities authorized in the EU and to ICT third-party service providers that serve those entities, regardless of where the provider is headquartered. A US-based SaaS company providing services to an EU bank is indirectly subject to DORA through the contractual requirements the bank must impose. If the provider is designated as a Critical ICT Third-Party Service Provider, it must establish a subsidiary within the EU and is subject to direct oversight by a Lead Overseer.

Is DORA the same as NIS2?

No. DORA and NIS2 (the Network and Information Security Directive 2) are separate EU legislative instruments with different scopes and purposes. NIS2 is a broad cybersecurity directive that applies across critical sectors (energy, transport, healthcare, digital infrastructure, and others). DORA is a sector-specific regulation exclusively for the financial sector. DORA is lex specialis to NIS2, meaning that where DORA and NIS2 overlap, DORA's requirements take precedence for financial entities. Financial entities subject to DORA are generally exempt from the equivalent NIS2 requirements.

We already have ISO 27001 certification. Are we DORA compliant?

No. ISO 27001 provides a strong foundation for DORA compliance, particularly in risk management methodology, asset management, and incident response. However, DORA introduces requirements that ISO 27001 does not address: specific governance accountability at the board level, harmonized incident classification and reporting timelines, TLPT, prescriptive third-party contractual requirements, concentration risk analysis, and the CTPP oversight framework. An ISO 27001-certified organization has a meaningful head start but must conduct a gap analysis and address the DORA-specific requirements that fall outside ISO 27001's scope.

What is the relationship between DORA and PSD2?

PSD2 (the Payment Services Directive 2) and its successor PSD3/PSR include operational resilience requirements for payment service providers. DORA builds on and replaces the ICT risk management provisions that existed under PSD2 and other sector-specific financial services directives. Where PSD2 previously addressed operational security for payment institutions, DORA now provides a more comprehensive, harmonized framework. Payment institutions must comply with DORA in addition to any remaining PSD2/PSD3 requirements that are not superseded.

How does DORA affect cloud service providers?

Cloud service providers serving EU financial entities face significant indirect obligations under DORA. Financial entity clients must include DORA-mandated contractual provisions in their agreements, conduct ongoing due diligence, and maintain exit strategies. If a cloud provider is designated as a CTPP by the ESAs, it becomes subject to direct oversight, including on-site inspections and the power to impose daily penalty payments of up to 1% of worldwide turnover. Major cloud providers (AWS, Azure, GCP) are widely expected to be among the first CTPPs designated.

Do we need to conduct TLPT?

TLPT is mandatory only for significant financial entities identified by their competent authorities. Not all financial entities are required to conduct TLPT. However, all financial entities subject to DORA must maintain a digital operational resilience testing program that includes vulnerability assessments, scenario-based tests, and penetration testing, proportionate to their size and risk profile. Even entities not required to conduct TLPT may find it valuable as a means of demonstrating mature operational resilience.

Can we use a compliance automation platform for DORA?

Yes. DORA's requirements span policy documentation, risk assessment, asset inventory, incident management, testing programs, and third-party management -- all areas where compliance automation platforms provide significant efficiency gains. The key is ensuring that the platform supports DORA's specific requirements (incident classification criteria, reporting timelines, contractual provision tracking, concentration risk analysis) rather than only addressing DORA through the lens of another framework. Platforms that support multi-framework compliance programs are particularly valuable, as most financial entities subject to DORA also maintain ISO 27001, SOC 2, or other certifications.

What should we do first to prepare for DORA?

Start with a gap analysis. Map your existing ICT risk management practices, incident response capabilities, testing programs, and third-party management processes against DORA's specific requirements. Identify the gaps between what you have and what DORA mandates. Prioritize the gaps that carry the most regulatory risk: incident reporting capabilities (the compressed timelines catch many organizations unprepared), governance accountability (ensure your management body understands and accepts its DORA responsibilities), and third-party contractual provisions (contract renegotiations take time). If you hold ISO 27001 or SOC 2, use those as your baseline and focus on the DORA-specific additions.

Achieve DORA Compliance with QuickTrust

DORA represents the most significant regulatory development in financial sector ICT risk management in a decade. Its five pillars -- ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing -- impose comprehensive, enforceable requirements on financial entities and the technology providers they depend on.

For organizations that already hold ISO 27001 or SOC 2, DORA builds on familiar ground but adds substantial new requirements in governance accountability, incident reporting timelines, testing depth, and third-party management. For organizations starting from scratch, the scope of DORA can feel overwhelming -- but the regulation's proportionality principle and the overlap with existing frameworks mean that a well-structured compliance program can address DORA efficiently alongside other framework obligations.

QuickTrust helps financial entities and their ICT providers build, manage, and demonstrate DORA compliance alongside ISO 27001, SOC 2, and other frameworks. Our platform automates ICT risk management documentation, maps controls across multiple frameworks simultaneously, tracks third-party provider compliance, manages incident classification and reporting workflows, and generates the audit evidence that regulators and competent authorities expect.

Whether you are a bank building a DORA-compliant ICT risk management framework, a fintech preparing for your first regulatory engagement on operational resilience, or a SaaS provider adapting to the contractual demands of your financial entity clients, QuickTrust provides the tools and structure to make DORA compliance manageable and sustainable.

Start your free QuickTrust assessment to see how your current controls map to DORA requirements -- and where the gaps are.

This guide is maintained by the QuickTrust Editorial team and updated as DORA Regulatory Technical Standards, supervisory guidance, and enforcement practices evolve. Last updated: March 19, 2026.