The Digital Operational Resilience Act (DORA) entered into application on 17 January 2025 for financial entities within its scope in the European Union. DORA establishes a harmonised framework for information and communication technology (ICT) risk management, incident reporting, resilience testing, third-party oversight, and information sharing among certain financial-sector participants.
DORA directly regulates financial entities—not generic software vendors by default. Banks, payment institutions, electronic money institutions, investment firms, crypto-asset service providers where in scope, and other listed entity types must implement ICT risk governance programmes and manage critical third-party providers according to DORA requirements and related regulatory technical standards.
Technology and infrastructure platforms serving regulated clients may therefore experience DORA indirectly through contractual pass-through obligations, oversight visits, audit requests, and—in defined cases—registration as ICT third-party service providers of critical importance. This article explains who falls within scope, what operational capabilities are involved, and how shared fintech infrastructure should prepare without assuming every technology company is a DORA-regulated financial entity.
This analysis connects to FinDech's Payments Core, part of the Seven Cores infrastructure model.
Who DORA applies to—and who it does not
DORA's direct obligations apply to financial entities listed in the regulation, including credit institutions, payment institutions, electronic money institutions, investment firms, insurance undertakings, and certain market infrastructures and crypto-asset service providers, subject to specific exclusions and phasing. National competent authorities and, for cross-border matters, the European Supervisory Authorities oversee implementation.
A technology company providing cloud hosting, payment orchestration, core banking software, or fraud tools is not automatically a DORA 'financial entity.' Instead, such firms may be ICT third-party service providers to in-scope clients. Where a provider is designated critical, additional oversight mechanisms—including potential lead overseer involvement—may apply.
Product and compliance teams should begin with entity-level scoping: identify which group companies hold financial licenses, which activities each performs, and which technology suppliers support critical or important functions. Unlicensed pure technology developers may still need to support clients' DORA compliance even when they are not themselves subject to financial-sector authorization.
ICT risk management and governance
In-scope financial entities must maintain an ICT risk management framework proportionate to their size, activities, and risk profile. The framework covers identification, protection, detection, response, recovery, and learning from ICT-related incidents. Senior management and boards retain accountability; many firms embed ICT risk within broader operational risk committees.
For multi-brand fintech portfolios built on shared infrastructure, governance must clarify which entity owns ICT risk decisions, how changes propagate across tenants, and where brand-specific configurations could introduce vulnerabilities. Centralised platforms can strengthen consistency, but they can also concentrate failure domains if resilience testing and change management are weak.
Documentation expectations include policies, procedures, roles, asset inventories, and mapping of ICT dependencies to critical business services. Infrastructure providers supporting regulated clients should expect requests for architecture diagrams, data-flow descriptions, segregation controls, and evidence of secure development practices.
- Board and senior-management accountability for ICT risk
- Documented ICT risk management framework and review cycle
- Mapping of critical business services to supporting ICT assets
- Integration with change management, patching, and vulnerability handling
Incident classification, reporting, and communication
DORA introduces harmonised rules for reporting major ICT-related incidents to competent authorities and, in defined cases, sharing cyber threat information with other financial entities. Entities need playbooks that classify incidents by severity, customer impact, data compromise, and service downtime, with clear escalation paths and legal review.
Third-party incidents count when they affect critical services. A cloud outage, payment gateway failure, or certificate-management error at a supplier can trigger client reporting duties within tight timelines. Technology partners should provide timely, structured incident notifications, root-cause summaries, and remediation timelines to help clients meet regulatory clocks.
Customer communication and statutory reporting differ: a platform may need to support its client's external messaging without disclosing information that creates tipping-off or security risks. Runbooks should separate technical recovery steps from regulatory notification templates.
Resilience testing, continuity, and recovery
Financial entities must test ICT resilience, including threat-led penetration testing for many in-scope firms on a defined cadence. Testing programmes validate not only perimeter security but also backup restoration, failover routing, capacity under stress, and ability to maintain critical functions during disruption.
Shared infrastructure operators should support client testing with isolated environments, realistic failover drills, and documented recovery time objectives. Multi-tenant systems must demonstrate that one tenant's test or incident does not compromise another's data or availability.
Business continuity plans should address prolonged third-party unavailability, including exit scenarios described below. Testing results feed back into risk registers and board reporting rather than sitting as static compliance artifacts.
Third-party provider registers and contractual requirements
DORA requires financial entities to maintain registers of contractual arrangements with ICT third-party service providers and to report certain information to supervisors. Contracts supporting critical or important functions must include minimum terms on access, audit, participation in testing, service levels, security standards, data locations, subcontracting, and termination assistance.
Standard SaaS terms rarely satisfy these expectations without negotiation. Infrastructure vendors should prepare DORA-ready contract schedules covering incident cooperation, sub-processor transparency, and support for on-site or remote audits. Financial entities increasingly score vendors on evidence readiness before procurement.
Subcontracting chains amplify complexity: a fintech platform using a hyperscaler, a card processor, and a KYC API must disclose subcontractors and ensure flow-down clauses. Concentration risk arises when many firms depend on the same small set of hyperscale or payment providers.
1. Service and dependency mapping
Maintain an accurate inventory of which third parties support which critical business services, including subprocessors.
2. Contractual minimum terms
Align master agreements with DORA Annex expectations for access, audit, SLAs, security, and exit assistance.
3. Register maintenance and reporting
Financial entities must keep registers current and file information with supervisors according to applicable templates and timelines.
4. Concentration and substitutability reviews
Periodically assess whether critical providers can be replaced without unacceptable disruption to regulated services.
Concentration risk and exit planning
Supervisors increasingly scrutinise concentration in critical ICT providers, including hyperscale cloud platforms and dominant payment processors. DORA contemplates oversight of critical ICT third-party service providers and expects financial entities to plan for orderly exit or substitution where feasible.
Exit planning does not always mean building duplicate live stacks in every corridor. It does require documented data portability, contract termination assistance, cryptographic key control, and operational runbooks that prevent client lock-in from becoming systemic risk.
For modular fintech architectures, provider abstraction layers—such as orchestration in Payments Core—can reduce switching costs if interfaces, ledger mappings, and reconciliation exports are designed early rather than retrofitted under regulatory pressure.
Shared infrastructure and multi-brand portfolios
Groups operating multiple consumer brands on one platform must decide whether each regulated entity maintains separate registers and contracts or whether a central technology entity contracts with suppliers on behalf of licensed subsidiaries. Either model can work with clear legal allocation of responsibilities.
Incident response becomes more complex when one infrastructure outage affects several brands and potentially multiple license holders. Shared status pages, isolated blast-radius controls, and per-entity incident classification help meet DORA expectations while preserving brand-specific customer communications.
Risk Shield-style intervention capabilities can complement DORA by limiting fraudulent or abusive traffic during partial outages, but they do not replace ICT resilience duties. Operational resilience and fraud controls should be coordinated without conflating regulatory reporting categories.
A practical preparation checklist for technology platforms
Even when a platform is not a directly in-scope financial entity, its enterprise clients may require DORA-aligned evidence. Preparation focuses on operability, transparency, and contract readiness.
Teams should publish incident notification channels, maintain up-to-date subprocessors lists, document RTO/RPO targets for core services, and participate in client resilience tests where contracts require. Security certifications and penetration-test summaries frequently support procurement but do not substitute for DORA-specific contractual terms.
FinDech describes itself as financial infrastructure under development, not as a licensed financial entity. Where portfolio products require regulated services, those services would be provided by appropriately authorized partners. DORA planning for such a model should clarify partner oversight chains and which entity holds ICT registers for each live regulated activity—without asserting universal direct DORA applicability to the technology layer.
Practical takeaways
DORA is now part of the operational baseline for in-scope EU financial entities, elevating ICT risk to a board-level concern with concrete incident, testing, and third-party oversight duties. Technology platforms encounter DORA through client contracts, critical-provider designation, and supervisory expectations for substitutability and transparency.
Fintech infrastructure teams should map dependencies, strengthen incident cooperation, align contracts with DORA terms, and support resilience testing without overclaiming direct regulatory status. Shared platforms can improve consistency across brands if tenant isolation, auditability, and exit planning are treated as core design requirements—not late-stage compliance patches.
Treat DORA as a multi-year operating programme integrated with cybersecurity, vendor management, and business continuity rather than a one-off documentation exercise.
