DORA Compliance for FinTech Vendors: What Selling Software to EU Financial Firms Now Requires
DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), is the EU regulation that requires financial entities to manage the risks of their information and communication technology (ICT) systems and, critically for software vendors, the risks posed by third parties that supply those systems. It has applied directly across the EU since 17 January 2025.
For a FinTech that sells software to banks, insurers, payment institutions, or investment firms in the EU, DORA matters even though the FinTech is usually not directly regulated by it. As an ICT third-party service provider, a FinTech inherits DORA through the contracts that its financial-entity customers are legally required to enter into. A vendor that understands this can turn DORA readiness into a reason to be chosen. A vendor that meets the requirements for the first time at the negotiation table is at a disadvantage.
Atta Systems builds custom FinTech software for funded startups and financial firms, including Bankata, Nicola Wealth, and a project delivered with EY (see Atta Systems FinTech case studies and builds DORA-relevant resilience and contractual requirements into software from the start.
What DORA is and who it applies to
DORA is a directly applicable EU regulation that sets uniform rules for how financial entities manage ICT risk, and it applies across all EU member states without national transposition. It covers roughly 20 types of financial entities, from banks and insurers to payment institutions, investment firms, and crypto-asset service providers, together with the ICT third-party service providers that support them. In total, more than 20,000 entities fall within its scope.
DORA rests on five pillars, each of which places obligations on financial entities:
- ICT risk management. Financial entities must run a documented framework to identify, protect against, detect, respond to, and recover from ICT risks, with the management body accountable for it.
- ICT incident reporting. Financial entities must classify and report major ICT-related incidents to their competent authority on defined timelines.
- Digital operational resilience testing. Financial entities must regularly test their resilience, and the largest must undergo threat-led penetration testing (TLPT).
- ICT third-party risk management. Financial entities must manage the risks associated with their ICT suppliers, maintain a register of those arrangements, and embed specific contractual terms. This is the pillar that reaches software vendors.
- Information sharing. Financial entities may share cyber threat information with each other, on a voluntary basis.
The fourth pillar, ICT third-party risk management, matters most to a FinTech software vendor because it is the mechanism through which DORA reaches companies that are not themselves financial entities.
Why a FinTech software vendor is in scope, indirectly
A FinTech software vendor is indirectly in scope for DORA as an ICT third-party service provider to the financial entities it serves. DORA places its obligations on the financial entity, not on the ordinary vendor, but a financial entity cannot become compliant on its own. It is required to pass specific obligations down to its ICT suppliers through contracts, which is how DORA reaches vendors.
This has a precise legal shape. Under the ICT third-party risk pillar, a financial entity must maintain a Register of Information (under Article 28(3)) listing every contractual arrangement with an ICT provider, and ensure that each of those contracts contains a defined set of clauses (under Article 30). The vendor does not sign up to DORA directly, but it will be asked to accept the contractual terms DORA requires, at every renewal and every new deal.
There is one exception where a provider is regulated directly. If the European Supervisory Authorities designate a provider a Critical ICT Third-Party Provider (CTPP) under Article 31, because it is systemically important to the EU financial system, that provider comes under direct EU oversight by a Lead Overseer with powers to demand information, inspect, and impose penalties of up to 1 percent of average daily worldwide turnover. The first designations were made on 18 November 2025, when the ESAs designated 19 providers, names such as the large cloud and platform providers rather than ordinary software vendors. Most FinTech vendors are nowhere near this threshold, so for them DORA remains a contractual, indirect obligation rather than a direct one.
The Article 30 clauses a FinTech vendor will be asked to accept
Article 30 of DORA sets out the contractual clauses that a financial entity must include in every ICT contract, and these are the terms a FinTech vendor will be asked to accept. The clauses fall into two tiers: a baseline under Article 30(2) that applies to all ICT contracts, and an additional set under Article 30(3) that applies when the service supports a critical or important function of the financial entity.
The main clauses in each tier are summarized below. This is a summary of the principal terms, not the full lettered list in the regulation:
| Article 30(2): baseline clauses (all ICT contracts) | Article 30(3): additional clauses (critical or important functions) |
| Clear and complete description of the services, and whether subcontracting of critical or important functions is permitted and under what conditions. | Stricter, additional conditions and limits on subcontracting the critical or important function, including where it may be performed. |
| Locations where the service is provided and where data is processed and stored, with advance notice of any change. | Full audit and access rights, including on-site inspections, for the financial entity and its regulators. |
| Data protection: availability, authenticity, integrity, and confidentiality provisions. | Exit strategies with defined transition periods, so service can be moved without disruption. |
| Access, recovery, and return of data in an easily accessible format on the vendor’s insolvency, resolution, or discontinuation, or on termination of the contract. | The vendor’s obligation to participate in threat-led penetration testing where in scope. |
| Service level descriptions, including their updates and revisions. | Full service level descriptions with precise quantitative and qualitative performance targets, and monitoring of them. |
| Incident assistance at no additional cost, or at a cost agreed in advance; cooperation with authorities; and termination rights with notice periods. | Business contingency plans and detailed continuity, reporting, and testing obligations. |
Table note: Article 30(2) sets out nine baseline clauses (a) to (i) for all ICT contracts; Article 30(3) adds further requirements for services supporting critical or important functions. The rows above group the principal terms rather than reproducing the regulation clause by clause.
Whether the baseline set or the fuller set applies depends on whether the software supports a critical or important function of the financial entity, which is the customer’s determination to make. A vendor whose software runs a core banking process should expect the Article 30(3) clauses on top of the baseline. A vendor providing a peripheral tool may face only the baseline. Either way, the terms are mandatory for the financial entity, so they are not negotiable as ordinary commercial terms are; the customer cannot lawfully sign a contract that omits them.
How a FinTech vendor becomes DORA-ready
A FinTech vendor becomes DORA-ready by building the resilience practices and contractual readiness that its financial-entity customers will require, before those customers ask. DORA readiness is both an engineering posture and a contracting posture, and treating it only as a legal exercise misses the operational work that underpins the clauses.
- Operational resilience by design. Build the software so it can withstand and recover from disruption: redundancy, backup and recovery, monitoring, and tested incident response. The contractual clauses on availability and continuity rest on this engineering foundation.
- Security and service-management posture with evidence. Maintain programs that produce evidence an auditor can review. Certifications are the clearest form of that evidence: Atta Systems holds ISO 27001 for information security and ISO 20000 for IT service management, both directly relevant to DORA’s security and operational-resilience clauses, alongside ISO 9001 for quality management and ISO 13485 for medical device software. DORA clauses on security and audit rights are far easier to accept when certified evidence already exists.
- Incident handling that meets customer timelines. Establish incident detection, classification, and assistance processes that support a financial entity’s own reporting obligations. If a customer must report a major incident on a strict timeline, the vendor’s assistance obligations feed directly into that.
- Clear data location and subcontracting records. Document where data is processed and stored and which subcontractors are involved, because these are specific Article 30 requirements and the financial entity must record them in its Register of Information.
- Contractual readiness. Prepare to accept the Article 30 clauses rather than meeting them for the first time in negotiation. A vendor that can present DORA-aligned terms and evidence proactively shortens the customer’s procurement and reduces the friction that loses deals.
Atta Systems builds custom FinTech software with these resilience and security practices designed in, and holds ISO 9001, ISO 13485, ISO 20000, and ISO 27001, so the software a financial entity buys already supports the Article 30 clauses its own regulators require, rather than needing to be retrofitted after a DORA gap is found in diligence.
Why DORA readiness is a commercial advantage, not just a cost
DORA readiness is a commercial advantage for a FinTech vendor because it removes a barrier that its competitors may still carry. A financial entity cannot buy software that would leave it unable to meet its own DORA obligations, so a vendor that is demonstrably DORA-ready is easier to choose and faster to onboard.
The advantage shows up in three concrete ways:
- Shorter procurement. A vendor that already meets the Article 30 requirements and can show the evidence moves through the customer’s third-party risk assessment faster than one that has to remediate gaps mid-deal.
- Access to larger customers. The financial entities with the strictest DORA scrutiny are often the largest and most valuable. Being DORA-ready is what makes a vendor eligible to serve them at all.
- A defensible differentiator. Many smaller software vendors treat DORA as someone else’s problem and discover the clauses at the negotiation table. A vendor that leads with DORA readiness turns a compliance burden into a reason to be selected over a less-prepared competitor.
For financial firms and FinTechs evaluating a development partner on exactly these criteria, Atta Systems offers FinTech software development services, building payments, digital banking, lending, and wealthtech software with resilience, security certification, and DORA-aligned contractual readiness built in.
FAQ about DORA for FinTech vendors
DORA applies to software vendors indirectly, as ICT third-party service providers to the financial entities they supply. A vendor usually has no direct obligations under DORA, but its financial-entity customers are legally required to embed DORA’s Article 30 clauses in their ICT contracts, so the vendor inherits DORA by contract. The exception is a provider designated a Critical ICT Third-Party Provider (CTPP), which comes under direct EU oversight.
DORA entered into force on 16 January 2023 and has applied directly across the EU since 17 January 2025. Through 2026, it has moved into an enforcement and maturity phase, with the European Central Bank integrating DORA into its supervisory review process and competent authorities actively examining ICT risk management and third-party arrangements.
Article 30 of DORA sets out the contractual clauses that a financial entity must include in its ICT service contracts. Article 30(2) lists nine baseline clauses for all ICT contracts, covering the service description and subcontracting terms, data location, data protection, data access and return on insolvency or termination, service level descriptions, incident assistance, cooperation with authorities, and termination rights. Article 30(3) adds further clauses for services that support a critical or important function, including full service level targets, full audit and access rights, exit strategies, and participation in threat-led penetration testing. These are the terms a FinTech vendor will be asked to accept.
A Critical ICT Third-Party Provider (CTPP) is an ICT provider designated by the European Supervisory Authorities under Article 31 as systemically important to the EU financial system. Unlike ordinary vendors, a CTPP is subject to direct EU oversight by a Lead Overseer, who has the power to request information, conduct inspections, and impose penalties of up to 1 percent of average daily worldwide turnover. The first 19 CTPPs were designated on 18 November 2025 and are largely the major cloud and platform providers, not most FinTech vendors.
A FinTech becomes DORA-ready by building operational resilience and security into its software with evidence an auditor can review, such as ISO 27001 and ISO 20000 certification, establishing incident handling that supports its customers’ reporting obligations, documenting data location and subcontracting, and preparing to accept DORA’s Article 30 contract clauses proactively. Readiness is both an engineering posture and a contracting posture, and a vendor that has both moves through customer procurement faster than one that treats DORA as a legal afterthought.
Atta Systems builds custom FinTech software for funded startups and financial firms, including Bankata, Nicola Wealth, and an EY project, and holds ISO 9001, ISO 13485, ISO 20000, and ISO 27001 certifications, with operational resilience, security evidence, and DORA-aligned contractual readiness designed in from the first version.
Atta Systems focuses on custom FinTech software where regulatory and resilience requirements are built in, in payments, digital banking, lending, and wealthtech, rather than on off-the-shelf product configuration or general consumer software outside the financial-services regulatory perimeter.
Related Articles
