The Question
"We are a UK-based SaaS company with around 60 employees. We sell to a handful of EU banks. Since January, three of them have sent us long contract addenda referencing 'DORA' and asking for audit rights, exit plans, subcontractor lists, and incident reporting commitments. We are not regulated by anyone. Why are they asking, and what do we actually have to do?"
The Short Answer
You are an ICT third-party service provider under the Digital Operational Resilience Act (Regulation EU 2022/2554). DORA applies to your bank customers, not to you directly — but it imposes specific contractual obligations on them whenever they buy ICT services from anyone. They cannot satisfy those obligations without your cooperation. You are not obliged to be DORA-compliant. You are, in practical terms, obliged to give your financial-services customers the contractual hooks DORA requires them to have, or they have to stop buying from you.
The Detail
Where this comes from
DORA's full application date was 17 January 2026. From that moment, every financial entity in the EU — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and a few dozen other categories listed in Article 2 — has to manage its ICT third-party risk under a binding regulatory framework. The relevant articles are Article 28 (ICT third-party risk management strategy) and Article 30 (key contractual provisions).
Article 30 tells financial entities exactly what their contracts with ICT providers must contain. It splits requirements into two tiers: a baseline that applies to all ICT services, and an enhanced tier that applies when the ICT service supports a critical or important function of the financial entity.
What the baseline looks like
For any ICT service contract, your bank customer's compliance team needs the contract to specify, at minimum: a clear description of the service, the geographic locations where the service is provided and where data is stored or processed, service-level descriptions, data accessibility and recovery commitments (including in your insolvency), incident-assistance obligations, cooperation with competent authorities, and termination rights with notice periods. Most well-drafted SaaS MSAs already cover three-quarters of this list. The pain is usually in the geographic-locations clause and the data-on-insolvency clause, which most boilerplate contracts do not address with the precision DORA demands.
What changes when you support a "critical or important function"
This is where the addenda you are receiving become substantial. If your bank customer's compliance team has classified the service you provide as supporting a critical or important function — which, for most SaaS that touches transaction processing, customer data, identity, fraud, AML, or core banking, it will be — Article 30(3) requires the contract to additionally include:
- Precise quantitative and qualitative performance targets sufficient to trigger corrective action when missed
- Audit and inspection rights for the bank customer or its appointed third parties, including on-premises access where reasonable
- The right for the customer to obtain copies of relevant materials needed to perform the audit
- Notification of material developments that affect your ability to deliver the service
- Mandatory participation in threat-led penetration testing (TLPT) where the bank is required to perform it
- A defined exit strategy with a mandatory transition period during which you continue to provide the service while the customer migrates
- Resolution-resilience clauses preventing you from terminating the contract because the customer is in restructuring or resolution
That is the bulk of what is in the addenda you have received. None of it is your customer being aggressive. It is them satisfying their own regulatory checklist.
The Register of Information
Your bank customer also has to maintain a Register of Information of all their ICT third-party arrangements, in a standardised format defined by Commission Implementing Regulation (EU) 2024/2956 (29 November 2024). This Register must include identifying details about you (LEI or alternative codes), the data locations, the supply chain — meaning your subcontractors and their subcontractors where they support critical or important functions — governing law, notice periods, and the bank's risk assessment of you.
This is why some of your customers are asking for things like a current list of your sub-processors, a copy of your most recent SOC 2 report, your data-residency commitments in writing, and your business continuity plan. They are populating the Register. They have to submit it on request to their competent authority.
What you actually have to do
In practical terms, three things.
First, accept that this is not negotiable for your customers. They are not asking you to do these things because they want to renegotiate the deal. They are asking because if they cannot get these clauses into your contract, they cannot continue to do business with you under DORA. Pushing back hard on the principle wastes goodwill; pushing back on the specifics (audit scope, notification thresholds, exit-period length) is normal and expected.
Second, decide whether the service you provide to them is supporting a critical or important function. This is their classification, not yours, but you should know which of your services they have classified that way so you can scope your response. Services that don't touch a critical function get the lighter baseline contract. Services that do get the full Article 30(3) package.
Third, build a "DORA-ready supplier pack" once and reuse it. For every financial-services customer asking for the same thing, you are going to be asked for: a service description with geographic locations, your sub-processor list with their locations, your SOC 2 / ISO 27001 attestations, your business continuity and exit-transition plans, your incident-response runbook, and your data-recovery commitments. Put this in a single document set you can hand out under NDA. Suppliers that have this ready close DORA addenda in days. Suppliers that don't take months and lose business.
What you do not have to do
You are not required to become DORA-compliant. DORA does not apply to you. Only a small subset of ICT providers — those designated as Critical ICT Third-Party Service Providers (CTPPs) by the European Supervisory Authorities under DORA Article 31 — are subject to direct supervision. The current CTPP designation regime targets a small number of very large hyperscale cloud providers and similar systemically important infrastructure. A 60-employee SaaS vendor will not be designated. The contractual obligations flowing through your bank customers are the entire extent of your DORA exposure.
You are also not required to give every customer the same terms. The audit rights, notification thresholds, and exit-transition periods are negotiable — what is not negotiable is that some version of each clause has to exist.
Sources
- Regulation (EU) 2022/2554 (DORA) — Articles 2, 28, 30, 31
- Commission Implementing Regulation (EU) 2024/2956 — Register of Information templates