These are the 8 points this article covers on what DORA means for fintechs:

  1. What DORA is and who it applies to
  2. DORA’s five pillars explained
  3. What DORA requires in practice
  4. Incident reporting deadlines
  5. What changes for fintech companies
  6. Penalties for non-compliance
  7. Common mistakes
  8. How PrivaLex can help and next steps

Financial regulation in the EU has entered a new phase with DORA: the Digital Operational Resilience Act (Regulation 2022/2554), which entered into application in January 2025. DORA is not a cybersecurity framework in the traditional sense, it is a binding resilience regulation that requires financial entities and their technology providers to demonstrate they can withstand, respond to and recover from digital incidents.

If you operate a fintech startup, a payment platform, a SaaS serving financial institutions, or any technology company within the EU financial ecosystem, DORA applies to you. This guide explains what DORA means for fintechs, who is in scope, what its five pillars require in practice, what the incident reporting deadlines are, and what happens if you do not comply.

At PrivaLex Partners we support fintechs and ICT providers in the financial sector to prepare for DORA with clarity and confidence, from initial gap assessment to implementation and ongoing compliance.

What Is DORA and Who Does It Apply To?

DORA (Regulation EU 2022/2554) is part of the EU digital finance package. It establishes a common framework to ensure that financial entities and their ICT providers can withstand, respond to and recover from all ICT-related disruptions and threats.

DORA applies directly to a broad range of financial entities, including banks, insurers, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, crowdfunding platforms, and credit rating agencies. It also applies to ICT third-party service providers that are classified as critical, a formal designation made at EU level by the European Supervisory Authorities (ESAs: EBA, ESMA and EIOPA).

For fintechs specifically, DORA is relevant in three ways:

  • As a regulated financial entity: if your fintech holds a payment institution licence, an e-money licence, a MiCA authorisation or any other EU financial services authorisation, DORA applies to you directly.
  • As a critical ICT third-party provider: if you provide ICT services to financial entities and are designated as critical by the ESAs, you are subject to direct oversight under DORA.
  • As a supply chain participant: even if you are not directly regulated, if you provide services to banks, insurers or other regulated financial entities, those entities must include DORA-aligned contractual clauses in agreements with you. In practice, many fintechs will feel DORA through their clients’ requirements.

DORA’s Five Pillars Explained

DORA is structured around five pillars. Understanding them is the first step to knowing what you need to implement and demonstrate.

1. ICT Risk Management

Organisations must have a robust, documented ICT risk management framework that identifies critical assets, maps dependencies and implements controls proportionate to the risks identified. This is not a one-off exercise: it must be reviewed regularly and updated when technology, structure or risks change. Senior management is responsible for approving and overseeing the framework.

2. ICT-Related Incident Reporting

DORA introduces strict timelines for reporting major ICT-related incidents to competent authorities. For classified major incidents, the deadlines are: an initial notification within 4 hours of classification (and no later than 24 hours after becoming aware), an intermediate report within 72 hours, and a final report within one month. Having clear internal protocols, with defined roles, classification criteria and communication channels, is essential to meet these deadlines consistently.

3. Digital Operational Resilience Testing

Organisations must conduct regular resilience testing to verify that their ICT systems and processes can withstand disruptions. This includes basic testing (vulnerability assessments, scenario-based tests, penetration testing) for all entities, and advanced Threat-Led Penetration Testing (TLPT) for significant financial entities at least every three years. Testing must be documented and findings must be tracked through to remediation.

4. ICT Third-Party Risk Management

DORA places significant obligations on how financial entities manage their ICT suppliers. Contracts with ICT third-party providers must include specific clauses covering security requirements, audit rights, incident notification, business continuity and exit strategies. Organisations must maintain a register of all ICT third-party arrangements and actively monitor the performance and risk posture of critical providers. This pillar directly affects fintechs both as buyers and as suppliers.

5. Information Sharing

DORA encourages, and in some cases requires, financial entities to share information and intelligence on cyber threats with each other and with authorities. Participation in trusted information-sharing arrangements is seen as a sign of maturity and contributes to sector-wide resilience. Sharing must be done in a way that protects confidentiality and does not create additional risk.

What Does DORA Require in Practice?

What distinguishes DORA from earlier regulations is its focus on demonstrated, operational resilience rather than written policies alone. Authorities can inspect, request documentation and require evidence that controls are not just documented but actively implemented, tested and improved.

In practice, complying with DORA means having:

  • A documented ICT risk management framework with assigned ownership at senior management level
  • A formal register of critical ICT assets and third-party arrangements
  • Tested and documented incident response procedures, including the 4-hour and 72-hour notification protocols
  • A resilience testing programme with evidence of results and remediation
  • Contracts with ICT suppliers that include DORA-required clauses (security, audit rights, incident notification, exit strategies)
  • Staff training on ICT risk, incident response and their specific roles
  • A process for continuous improvement: acting on audit findings, test results and incident lessons learned

Documentation alone is not enough. Authorities expect evidence that controls work in practice: test results, simulation records, training logs, incident reports and management review minutes.

Incident Reporting Deadlines Under DORA

DORA’s incident reporting requirements are one of the most operationally demanding aspects for fintechs. The deadlines for major ICT-related incidents are strict and require internal processes to be ready well in advance:

  • Initial notification: within 4 hours of classifying an incident as major (and no later than 24 hours after first becoming aware of it)
  • Intermediate report: within 72 hours of the initial notification, with an update on the status, impact and measures taken
  • Final report: within one month of the incident being resolved, including root cause analysis, lessons learned and any systemic implications

Meeting these deadlines requires having internal classification criteria (what counts as a major incident), defined escalation roles (who decides to notify, who drafts the report, who submits it), pre-prepared notification templates, and rehearsed procedures. Improvising under pressure leads to late or incomplete notifications, which themselves constitute a compliance failure.

What Changes for Fintech Companies?

For many fintechs, DORA requires a step-change in how they approach operational resilience. Several areas that were previously informal or ad hoc now need to be formalised, documented and demonstrated:

  • Business continuity and disaster recovery: plans must exist, be tested and be updated regularly, not just written and filed
  • Third-party management: supplier relationships need structured risk assessments, contractual DORA clauses and active monitoring
  • Incident response: internal procedures must be fast enough to meet DORA’s 4-hour initial notification window, this requires rehearsal, not improvisation
  • Leadership accountability: senior management must be demonstrably involved in ICT risk oversight, not just delegating it to the IT team
  • Supply chain obligations: even fintechs that are not directly regulated will face DORA requirements passed down through contracts from their financial sector clients

An information security management system (ISMS) aligned with ISO 27001 covers significant ground across DORA’s requirements and can reduce the implementation effort substantially, particularly for ICT risk management, incident response and third-party risk.

Penalties for Non-Compliance with DORA

National supervisory authorities, such as the CNMV and Bank of Spain in Spain, the BaFin in Germany, or the AMF in France, have powers to inspect, request documentation and impose sanctions for non-compliance with DORA. For critical ICT third-party providers, direct oversight powers rest with the ESAs.

Sanctions can include:

  • Administrative fines, which vary by Member State but can be substantial for serious or repeated violations
  • Mandatory remediation orders requiring specific controls or processes to be put in place within a defined timeframe
  • Public disclosure of the non-compliance, which carries significant reputational risk
  • Exclusion from tenders, procurement processes and strategic contracts with major financial sector clients
  • For critical ICT third-party providers: suspension or termination of services to EU financial entities

Beyond sanctions, the commercial risk is significant. Fintechs that cannot demonstrate DORA compliance may be excluded from deals with banks, insurers and other regulated clients who are themselves required to ensure their ICT providers meet DORA standards.

Mistakes That Can Undermine DORA Compliance

Treating DORA as a documentation exercise

DORA explicitly requires demonstrated, operational resilience, not just written policies. If your incident response plan has never been tested, or your risk register has not been reviewed since implementation, authorities will identify this in an inspection.

Not having a 4-hour incident notification protocol

The 4-hour initial notification deadline is tight and requires a pre-defined, rehearsed process. Without clear classification criteria, assigned roles and a notification template, the team will lose critical hours debating what to do rather than doing it.

Assuming indirect scope means no obligations

Fintechs that are not directly regulated but provide services to financial entities will face DORA requirements through their clients’ contracts. Ignoring this until a bank or insurer asks for evidence of compliance creates urgency and risk.

Not reviewing ICT supplier contracts

DORA requires specific contractual clauses with ICT providers. If your existing supplier contracts predate DORA and have not been reviewed, they likely lack the required provisions on audit rights, incident notification, business continuity and exit strategies.

How PrivaLex Can Help You With DORA Compliance

At PrivaLex Partners we work with fintechs, tech scale-ups and ICT providers in the financial ecosystem to make DORA compliance practical, structured and aligned with business goals. We do not sell software: we provide expertise, experience and direct support so you know exactly where you stand and what to do next.

Our support covers gap assessments against DORA’s five pillars, ICT risk management framework design, incident response protocol development and rehearsal, supplier contract review and DORA clause implementation, resilience testing planning, staff training and preparation for supervisory inspections. If you are also managing ISO 27001, NIS2 or GDPR obligations, we integrate all frameworks to avoid duplicating effort.

Schedule a strategic session with PrivaLex and turn DORA compliance into a competitive advantage: a signal to clients, investors and regulators that your operations are built to last.

Frequently Asked Questions (FAQs)

What is DORA and when did it come into force?

DORA (Regulation EU 2022/2554, the Digital Operational Resilience Act) is an EU regulation that sets binding rules for ICT risk management, incident reporting, resilience testing, third-party risk and information sharing in the financial sector. It entered into application on 17 January 2025.

Does DORA apply to my fintech if we are not a bank?

Possibly. DORA applies directly to all EU-authorised financial entities, including payment institutions, e-money institutions, crypto-asset service providers, investment firms and crowdfunding platforms. It also applies to critical ICT third-party providers designated by the ESAs. Even if you are not directly regulated, if you provide services to banks or insurers, you may face DORA-aligned contractual requirements from your clients.

What are the incident reporting deadlines under DORA?

For major ICT-related incidents: initial notification to the competent authority within 4 hours of classification (and no later than 24 hours after becoming aware); intermediate report within 72 hours; final report within one month of resolution.

What are DORA’s five pillars?

DORA is structured around five pillars: (1) ICT risk management, a documented, senior-management-owned framework; (2) ICT-related incident reporting, with strict notification deadlines; (3) digital operational resilience testing, regular vulnerability assessments and, for significant entities, advanced Threat-Led Penetration Testing; (4) ICT third-party risk management, contracts, monitoring and a register of providers; (5) information sharing, sharing cyber threat intelligence with peers and authorities.

What are the sanctions for DORA non-compliance?

National supervisory authorities can impose administrative fines, issue mandatory remediation orders and publicly disclose non-compliance. For critical ICT third-party providers, the ESAs can suspend or terminate service provision to EU financial entities. Beyond sanctions, the commercial risk includes exclusion from deals with regulated financial sector clients.

How does DORA relate to NIS2 and ISO 27001?

DORA and NIS2 overlap in scope for some financial entities, where both apply, DORA’s requirements take precedence under the lex specialis principle. ISO 27001 covers much of DORA’s ICT risk management pillar and can reduce implementation effort significantly. A partner like PrivaLex can help you align all three frameworks in a single project.

Can PrivaLex help my fintech prepare for DORA?

Yes. PrivaLex offers DORA gap assessments, ICT risk framework design, incident response protocol development, supplier contract review, resilience testing planning, staff training and inspection preparation. We support you from initial diagnosis through to implementation and ongoing compliance.

What’s Next?

Want to ensure your fintech complies with DORA in a solid and efficient way? Book a free call with our team.