DORA has changed the standard for fintech compliance in the European Union. Since 17 January 2025, regulated financial entities have had to show that they can prevent, withstand, respond to and recover from serious ICT disruption. The obligation is not satisfied by owning security tools or holding an ISO certificate. A fintech must be able to connect governance, systems, incidents, testing, suppliers, contracts and recovery evidence into one operational resilience framework.
This matters because fintech operating models are unusually dependent on cloud infrastructure, APIs, outsourced software, payment processors, identity providers, data platforms and specialised technology vendors. A single unavailable service can interrupt onboarding, payments, trading, account access or regulatory reporting. Under the Digital Operational Resilience Act, Regulation (EU) 2022/2554, outsourcing a service does not outsource the financial entity’s accountability.
This guide explains who DORA covers, what a fintech must implement in practice, which evidence supervisors expect, how the 2025 technical standards change incident reporting and third-party governance, and which mistakes repeatedly leave firms exposed.
What is DORA and what problem does it solve?
DORA is the EU’s sector-specific framework for digital operational resilience in finance. Its central question is broader than “Can the company prevent a cyberattack?” It asks whether the entity can continue delivering critical or important financial services when technology fails, data is compromised, a supplier becomes unavailable or a severe incident disrupts normal operations.
The regulation harmonises requirements that were previously distributed across sectoral rules and national expectations. It creates common obligations in 5 connected areas:
The European Commission’s cyber-resilience overview describes the policy objective as strengthening the financial sector’s ability to prevent incidents, minimise disruption and recover quickly. DORA also introduces EU-level oversight of ICT providers designated as critical to the financial system.
Who must comply with DORA?
DORA applies to the financial entities listed in Article 2. The scope includes credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers authorised under MiCA, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, data-reporting service providers, insurance and reinsurance undertakings and intermediaries, institutions for occupational retirement provision, credit-rating agencies, administrators of critical benchmarks, crowdfunding service providers and securitisation repositories.
A fintech should not decide scope from its marketing label. “Fintech” is not a legal category under DORA. The correct assessment starts with the licences, registrations, regulated services and group entities involved. A payments platform, digital lender, investment app and crypto platform may have different obligations even if all describe themselves as fintechs.
Direct scope, indirect impact and exclusions
A regulated financial entity in Article 2 is directly subject to DORA. An ICT provider is not automatically a financial entity, but it will often face substantial indirect requirements through contracts with regulated clients. Providers designated as critical ICT third-party providers are also subject to the EU oversight framework. In November 2025, the ESAs published the first list of designated critical providers.
DORA contains exclusions and differentiated requirements, including exclusions for certain very small sectoral entities and a simplified ICT risk-management framework for specified categories. Microenterprises benefit from targeted proportionality, but “small” does not mean exempt. Scope and proportionality require a documented legal analysis, not an informal assumption based on headcount.
What proportionality really means
Article 4 requires requirements to be applied in a way that takes account of size, overall risk profile, and the nature, scale and complexity of services and operations. Proportionality affects how controls are designed and evidenced; it does not remove the underlying outcome. A smaller payment institution may use a leaner committee structure and simpler tooling than a multinational bank, but it still needs clear ownership, a current asset and dependency view, tested recovery arrangements, an incident process and defensible supplier governance.
7 DORA compliance workstreams fintechs must operate
1. Put the management body in control of ICT risk
DORA places ultimate responsibility for ICT risk on the management body. Senior management must define roles, approve and periodically review the ICT risk-management framework, set risk tolerance, oversee continuity and recovery arrangements, approve ICT audit plans and remain informed about important supplier arrangements and material changes.
This changes the governance conversation. DORA is not a project that the CISO can complete alone. The board or equivalent management body needs usable information: which services are critical, which risks exceed tolerance, which incidents and near misses matter, where single points of failure exist, whether remediation is overdue and whether exit plans are realistic. Members must also maintain sufficient knowledge and skills through regular training.
Good evidence includes approved policies, terms of reference, responsibility matrices, board packs, challenge and decisions recorded in minutes, risk-acceptance records, budgets linked to material gaps and follow-up of overdue actions.
2. Build an ICT risk-management framework around business services
The framework should connect business functions to the information assets, applications, infrastructure, people, premises, data and providers that support them. A consistent risk-assessment methodology with audit-ready evidence helps turn that dependency map into prioritised and explainable treatment decisions. A fintech that inventories laptops and servers but cannot map the technology chain behind card authorisation, customer authentication or withdrawals does not yet have an operational-resilience view.
The practical sequence is to identify critical or important functions; map supporting information and ICT assets; classify risks and dependencies; protect and prevent; detect anomalous activity; respond and recover; learn from incidents and tests; and communicate internally and externally. The framework should be reviewed at least annually and after major incidents, material technology changes or supervisory instructions.
Controls should cover access management, privileged access, secure configuration, patching, vulnerability management, encryption, logging and monitoring, change management, capacity, network security, backups, restoration, physical security, secure development and data integrity. The relevant DORA delegated and implementing acts give the technical framework much more detail than the original regulation alone.
3. Make incident classification and reporting executable
Financial entities need one process that can detect an event, preserve evidence, assess impact, classify it against the DORA criteria, escalate to the right decision-makers and submit accurate reports. The classification analysis considers affected clients and transactions, duration and service downtime, geographical spread, data losses, criticality of affected services and economic impact. Where personal data may also be affected, the GDPR data-breach response template provides a complementary structure for the separate privacy assessment.
The current regulatory timeline is demanding. Under Commission Delegated Regulation (EU) 2025/301, an initial notification is due as early as possible and, in any case, within four hours after an incident is classified as major, while also no later than 24 hours after awareness. The intermediate report is due within 72 hours of the initial notification, and the final report is generally due within one month of the intermediate or latest updated intermediate report.
| Stage | Operational requirement | Key evidence |
|---|---|---|
| Detection and awareness | Establish when the entity had a reasonable degree of certainty that an ICT incident occurred. | Alerts, tickets, logs, chronology and awareness-time decision. |
| Classification | Assess all DORA criteria and thresholds; reassess when facts change. | Classification worksheet, impact data and approval trail. |
| Initial notification | Submit within four hours of major classification and no later than 24 hours after awareness. | Submission receipt, facts known, assumptions and missing information. |
| Intermediate report | Submit within 72 hours of the initial notice and update when regular activities recover. | Impact development, containment, recovery status and updated indicators. |
| Final report | Generally submit within one month after the intermediate or latest updated report. | Root cause, resolution, costs, lessons learned and remediation plan. |
For Spanish entities within its remit, the Banco de España has published a dedicated DORA incident and significant cyber-threat notification procedure. Firms supervised by other authorities should confirm the competent authority, portal, credentials, delegated-reporting arrangements and out-of-hours process before an incident occurs.
4. Operate a risk-based resilience testing programme
DORA expects annual testing of ICT systems and applications supporting critical or important functions, as well as an overall programme proportionate to risk. The programme can include vulnerability assessments, open-source analyses, network security assessments, gap analyses, physical security reviews, source-code reviews where feasible, scenario-based tests, compatibility and performance tests, end-to-end tests and penetration testing.
Testing is valuable only when findings have owners, deadlines, risk ratings, retest criteria and escalation rules. Evidence should show that severe findings change the control environment rather than disappearing into a report archive.
Threat-led penetration testing
Certain financial entities identified by competent authorities must perform threat-led penetration testing at least every three years, unless the authority changes the frequency. TLPT is not an ordinary penetration test. It uses realistic threat intelligence, targets live production systems supporting critical or important functions and can include the ICT providers that support them. The detailed criteria and methodology are set out in Commission Delegated Regulation (EU) 2025/1190.
5. Create and maintain the Register of Information
Every in-scope financial entity must maintain a comprehensive register of contractual arrangements for ICT services. Depending on the structure, this must be available at individual, sub-consolidated and consolidated levels. The register supports internal risk management, supervisory review and the designation of critical ICT providers.
This is not a simple vendor list. It requires consistent information about the contracting entity, provider, services, functions supported, criticality, data and service locations, subcontractors, contract dates, notice periods, exit arrangements and other regulatory fields. The EBA’s Register of Information resources include the reporting framework, taxonomy materials and FAQs.
Data quality is a control issue. The ESAs’ dry run found that only a small minority of registers passed every validation check. A reliable process therefore needs defined data owners, contract-to-register reconciliation, identifiers such as LEIs where relevant, controlled changes and periodic validation rather than an annual spreadsheet scramble.
6. Govern ICT suppliers throughout the lifecycle
Before entering an ICT arrangement, the entity should assess whether the service supports a critical or important function, perform due diligence, identify conflicts, consider concentration and substitutability, review data location and security, and determine whether supervisory conditions are met. The risk assessment must look beyond the direct vendor to material subcontracting chains.
Article 30 requires written contracts to contain minimum provisions. These include a clear description of services, service and data locations, data-access and recovery provisions, security requirements, assistance with incidents, cooperation with authorities and termination rights. Contracts supporting critical or important functions require additional provisions, including service levels, notice and reporting duties, business-contingency requirements, audit and access rights, participation in security programmes where appropriate and tested exit strategies.
The final subcontracting standard, Commission Delegated Regulation (EU) 2025/532, adds a structured assessment of subcontracting that supports critical or important functions. Fintechs should know which subcontractors actually deliver the service, where concentration or long chains reduce visibility, what changes require notice, and when a proposed change could justify objection or termination.
7. Make recovery and exit plans credible
Continuity documents frequently describe a provider failure without demonstrating that the business can operate through it. DORA requires more. Recovery objectives must reflect business impact, dependencies and tolerable disruption. Backups need secure separation and restoration tests. Crisis roles, internal communications, customer messaging and regulatory reporting must work together.
For critical ICT providers, an exit strategy should identify triggers, owners, transition periods, data migration, replacement options, minimum service continuity, dependencies, contract support, secure deletion and the evidence required to confirm completion. “We could move to another cloud provider” is not an exit plan unless architecture, data portability, cost, time and operational constraints have been assessed and tested.
What documentation and evidence should a fintech maintain?
A DORA programme should produce evidence that lets a reviewer trace a requirement from governance to implementation and testing. The exact set depends on scope and proportionality, but a mature evidence library usually includes:
- An approved ICT risk-management framework and associated policies, standards and procedures.
- A map of critical or important functions and their supporting assets, data, people, facilities and ICT third parties.
- ICT asset inventories, network and data-flow diagrams, classification rules and dependency maps.
- Risk assessments, risk-treatment plans, exceptions, management approvals and accepted residual risk.
- Business impact analyses, continuity plans, ICT response and recovery plans, crisis communications and restoration test results.
- Incident procedures, classification records, notification templates, incident registers, regulator submissions and post-incident reviews.
- A digital operational resilience testing policy, annual plan, test reports, remediation records and retest evidence.
- The Register of Information, supplier due-diligence files, concentration-risk assessments, contract reviews and subcontractor information.
- DORA-compliant contractual clauses, service levels, audit reports, monitoring results and exercised exit plans.
- Board training, management reporting, meeting minutes, decisions, budgets and oversight of remediation.
The strongest evidence is connected. A critical business service should link to its recovery objective, supporting applications, owners, key suppliers, resilience tests, incident thresholds and open risks. That traceability is what allows management and supervisors to judge whether the framework actually protects financial services.
8 common DORA mistakes fintechs should avoid
- Assuming “fintech” determines scope. Scope depends on regulated status and the Article 2 categories, not branding. Analyse every legal entity, licence, service and group relationship. Separately assess whether unregulated technology entities create contractual or concentration-risk exposure for regulated clients.
- Treating DORA as a cybersecurity checklist. Security controls matter, but DORA also covers governance, business continuity, reporting, testing, supplier contracts, oversight, learning and accountability. A tooling project without legal and operational ownership will leave major obligations unaddressed.
- Applying proportionality as an exemption. Smaller firms may implement leaner controls, but they still need to achieve and evidence the required outcomes. Document why the design is proportionate to the entity’s services, risk and complexity.
- Starting the incident clock too late. Teams sometimes wait for complete root-cause analysis before classification. DORA expects an initial report with the information available. Define awareness, major-incident classification and escalation triggers in advance, and rehearse the four-hour and 24-hour constraints.
- Maintaining an incomplete Register of Information. Procurement lists rarely contain all regulatory fields or subcontracting relationships. Assign data owners, reconcile the register to contracts and accounts payable, validate identifiers and integrate updates into vendor onboarding and change management.
- Signing supplier addenda without operational verification. A compliant clause is weak if security, audit, reporting, recovery and exit commitments cannot be exercised. Test whether supplier evidence arrives on time, whether incidents are escalated and whether data can actually be recovered or migrated.
- Testing controls without closing findings. Repeated vulnerabilities, unresolved recovery gaps and overdue actions demonstrate weak governance. Tie findings to accountable owners, risk acceptance, deadlines, retesting and management escalation.
- Relying on ISO 27001 as proof of complete DORA compliance. ISO 27001 provides a valuable management-system foundation, but DORA adds sector-specific governance, incident-reporting, Register of Information, contractual, supervisory and TLPT requirements. Map overlap and gaps explicitly. For implementation context, see our guide to ISO 27001 certification for EU startups.
A practical DORA implementation roadmap
Phase 1: establish scope and governance
Confirm the legal entities and services in scope, identify the competent authorities, define proportionality, appoint an executive sponsor and approve a responsibility matrix. Translate DORA requirements into an obligations register with owners and evidence expectations.
Phase 2: map critical services and dependencies
Identify critical or important functions and map the end-to-end technology chain supporting each one. Reconcile business-service maps with asset, data, supplier and contract inventories. Establish impact tolerances and recovery objectives that the business can explain.
Phase 3: assess controls and prioritise gaps
Evaluate governance, protection, detection, continuity, recovery, incident handling, testing and third-party controls. Prioritise gaps according to customer and service impact, regulatory exposure, concentration, ease of exploitation and remediation dependencies. Do not wait for every policy to be rewritten before fixing a high-risk operational weakness.
Phase 4: operationalise reporting and testing
Build the incident classification workflow, authority-specific submission process, reporting templates and evidence capture. Run a tabletop exercise that forces teams to classify an ambiguous incident and produce an initial notification under time pressure. Establish an annual testing programme and a controlled remediation cycle.
Phase 5: remediate supplier and contract exposure
Complete the Register of Information, segment services by criticality, identify missing Article 30 clauses, assess subcontracting and concentration risk, and agree a risk-based contract remediation plan. Exercise at least one material supplier exit or severe-outage scenario.
Phase 6: embed continuous assurance
Move from project delivery to recurring governance. Management reporting should track incidents, near misses, risks, test coverage, supplier changes, contract exceptions, register quality, remediation and resilience trends. Review the framework after material change and at least annually.
How DORA relates to ISO 27001, NIS2 and GDPR
| Framework | Primary focus | Relationship with DORA |
|---|---|---|
| ISO/IEC 27001 | Information-security management system and risk-based controls. | Provides governance and control foundations, but does not replace DORA-specific reporting, registers, contract rules, supervisory evidence or TLPT. |
| NIS2 | Horizontal cybersecurity requirements for essential and important entities across sectors. | For covered financial entities, DORA operates as sector-specific law for ICT risk management and incident reporting. Group and non-financial entities may still require a separate NIS2 analysis. |
| GDPR | Protection of personal data and individuals’ rights. | An incident can trigger both DORA and GDPR assessments. The thresholds, authorities, content and timelines differ, so one coordinated incident process must support separate legal decisions. |
For a detailed scope and control comparison, read NIS2 and DORA: key differences and overlaps.
For technical context and the broader financial-sector threat environment, ENISA maintains a dedicated finance cybersecurity resource. In Spain, the CNMV’s cybersecurity and DORA materials collect regulatory developments and implementation resources for entities within its sphere.
How PrivaLex supports fintechs with DORA compliance
DORA implementation often becomes fragmented because legal, security, engineering, procurement, risk, compliance and business-continuity teams each own only part of the operating model. PrivaLex brings those workstreams together so that the policies, technology, contracts and supervisory evidence describe the same reality.
Scope, proportionality and regulatory mapping
We assess the group’s entities, licences, services and ICT-provider relationships to determine direct scope, indirect exposure and the competent-authority landscape. We then build a practical obligations matrix that distinguishes requirements applicable to all in-scope entities, simplified-framework provisions, proportional implementation choices and sector-specific expectations.
DORA gap assessment and remediation roadmap
We review the ICT risk-management framework against the regulation and applicable technical standards. The assessment covers governance, asset and dependency mapping, protection and detection, response and recovery, learning, communication, testing and third-party risk. Findings are translated into owners, evidence requirements, dependencies and risk-based deadlines rather than delivered as an abstract legal checklist.
Governance and management-body readiness
We help define decision rights, risk-acceptance routes, committee responsibilities and management reporting. Board and executive sessions focus on the questions supervisors and customers are likely to ask: which services are critical, where concentration exists, whether recovery objectives are credible, what incidents reveal, and why management considers residual risk acceptable.
Incident classification, reporting and exercises
We design the legal and operational workflow from detection through classification, notification, recovery and final reporting. This includes decision trees, authority-specific routes, templates, evidence capture, delegated reporting and coordination with GDPR or contractual notifications. Tabletop exercises test whether teams can make defensible decisions and meet the binding reporting timetable with incomplete facts.
Register of Information and ICT supplier governance
We help define the data model, ownership and validation process for the Register of Information, then connect it with procurement, contract management, finance and technical inventories. For critical or important services, we review due diligence, concentration and substitutability, subcontracting, data location, service levels, audit rights, incident support, continuity, termination and exit provisions.
Resilience testing and remediation governance
PrivaLex helps create a proportionate annual test programme, evidence standards and remediation workflow. Where TLPT applies, we support governance, scoping, provider coordination, legal safeguards and the translation of results into controlled remediation. Our role complements technical testers by ensuring that testing decisions and outcomes remain aligned with regulatory expectations.
Integrated assurance across DORA, ISO 27001, NIS2 and GDPR
Many fintechs already operate an ISO 27001 information-security management system or maintain GDPR and business-continuity controls. We map reusable evidence and identify DORA-specific gaps so teams do not build parallel systems. The goal is one coherent control environment that can support regulatory supervision, enterprise due diligence, audits and operational decision-making.
PrivaLex does not approach DORA as a document-production exercise. We work with founders, boards, CISOs, compliance teams, risk owners, procurement and engineering to create controls that can be operated, tested and defended under scrutiny. Learn more about our DORA compliance support or request an initial readiness discussion.
DORA readiness checklist for fintech leaders
- Have we documented why each legal entity is in or out of scope?
- Can management identify the critical functions, systems and providers that matter most?
- Does our incident team know the awareness, classification and reporting deadlines?
- Can we produce a validated Register of Information without a manual reconstruction?
- Do contracts and operating practice meet the requirements for critical or important functions?
- Have we assessed subcontracting, concentration and realistic exit options?
- Does our test programme cover end-to-end service resilience, not only technical vulnerabilities?
- Are severe findings remediated, retested or formally risk-accepted?
- Can we show board oversight through decisions and follow-up, not merely presentations?
- Would our evidence remain coherent across DORA, GDPR, NIS2 and ISO 27001 reviews?
Frequently Asked Questions (FAQs)
DORA has applied since 17 January 2025. Because it is an EU regulation, its core obligations are directly applicable across Member States. It is accompanied by technical standards and implementing acts that specify operational details such as risk management, incident reporting, registers, subcontracting and TLPT.
No. “Fintech” is a commercial description, not a DORA category. Direct application depends on whether the legal entity falls within Article 2, for example as a payment institution, electronic money institution, investment firm, crowdfunding service provider or authorised crypto-asset service provider. Technology companies outside direct scope may still face extensive contractual requirements from regulated financial clients.
The initial notification must be submitted as early as possible and within four hours after classification as a major ICT-related incident, while also no later than 24 hours after awareness. An intermediate report is due within 72 hours of the initial notification. The final report is generally due within one month after the intermediate or latest updated intermediate report. The detailed rule is Commission Delegated Regulation (EU) 2025/301.
It is the structured record of contractual arrangements for ICT services used by the financial entity. It captures providers, services, functions supported, criticality, locations, subcontracting and contractual information. It supports internal third-party risk management, supervisory review and the EU process for designating critical ICT providers.
No. DORA permits the use of ICT third parties, including for critical or important functions, but the financial entity remains responsible for compliance. It must perform due diligence, assess concentration and subcontracting, maintain the register, include mandatory contractual provisions, monitor performance and risk, preserve audit and access rights, and maintain viable exit strategies.
No. ISO 27001 can provide a strong risk-management and control foundation, but certification does not prove compliance with all DORA obligations. Fintechs still need to address DORA-specific governance, regulatory reporting, Registers of Information, contractual provisions, third-party oversight, resilience-testing requirements and, where applicable, TLPT.
The same event may require both assessments, but the rules are different. DORA focuses on major ICT-related incidents affecting financial operations; GDPR focuses on personal data breaches and risk to individuals. Thresholds, competent authorities, report content and timelines differ. A coordinated incident process should produce the facts needed for separate, documented legal decisions.
No. Competent authorities identify the financial entities required to perform TLPT using regulatory criteria. Entities selected for TLPT normally carry it out at least every three years, subject to supervisory adjustment. All in-scope entities must nevertheless maintain a proportionate resilience-testing programme and test systems and applications supporting critical or important functions.
Start with scope, governance and critical-service mapping. Then address time-sensitive operational risks: incident classification and reporting, recovery gaps, critical supplier exposure, Register of Information quality and severe unresolved test findings. A risk-based roadmap should distinguish immediate operational remediation from longer-term policy, contract and assurance work.
Yes. PrivaLex can assess the applicable requirements, test the evidence chain, review governance and incident readiness, validate the Register of Information, analyse ICT contracts and supplier risks, structure testing and remediation, and prepare a prioritised plan for supervisory or customer scrutiny.
Next step: turn DORA requirements into operational evidence
DORA compliance is credible when a fintech can show how a critical service is governed, protected, monitored, tested, recovered and supported by suppliers—and when management can explain the remaining risk. The fastest route is not to write more policies. It is to map the operating model, test the evidence and prioritise the gaps that could disrupt customers or fail supervisory review.