DORA — Regulation (EU) 2022/2554 on digital operational resilience — has been in force since 17 January 2025. Most analysis focuses on what banks, insurers and other financial entities have to do. But there is a blind spot: ICT providers themselves. Software vendors, cloud providers, SaaS companies, development shops, managed service providers — if your customers are regulated financial entities, DORA concerns you directly, even though the regulation does not name you. This article explains exactly what Articles 28 to 30 change for you, and how to turn the constraint into a competitive advantage.

DORA: Why It Matters Even If You Are Not a Bank

DORA governs the way financial entities manage the risks they incur through their ICT providers. In practice, the regulation imposes no obligations on you as a provider — it imposes obligations on your customers that they then pass through to you by contract. That is the whole point: you bear DORA by trickle-down, without being its direct addressee.

The Contractual Trickle-Down Effect

A financial entity bound by DORA cannot become compliant on its own. Article 30 requires it to embed a specific set of clauses in its ICT contracts: audit rights, service levels, cooperation in case of incident, exit strategy, location of data, and more. As a result, at every renewal or new contract, your financial-services clients will present those requirements and expect you to accept them. The provider who discovers the clauses at the negotiation table is on the back foot; the one who has prepared for them turns the conversation into a sales advantage.

Standard Provider vs Critical ICT Third-Party Provider (CTPP)

Not every provider sits under the same regime. The majority fall under the ordinary contractual framework described above. A minority — providers whose failure could affect the stability of the financial system — may be designated as a Critical ICT Third-Party Provider (CTPP) by the European Supervisory Authorities. Those firms then move into a direct European supervisory framework with obligations of their own. The distinction matters: you need to know which side of the line you sit on. We come back to this further down.

The Register of Information: What Your Clients Must Declare About You

Each financial entity must keep and update a Register of Information listing every contractual arrangement it has with ICT providers and submit it to its competent authority. In plain terms, your customers report their relationship with you to their regulator.

What Information About You Goes Into the Register

The Register standardises a large number of fields: the provider’s identity (including the Legal Entity Identifier — LEI — where one exists), the nature of the service supplied, the function it supports and whether that function is critical or important, where the data is processed and stored, whether subcontractors are used, and so on. In other words, your client must be able to document precisely who you are and what you do for them. The third-party ICT risk pillar on this site walks through the Register from the customer’s side, which is useful background when those questions land in your sales pipeline.

Why Your Transparency Becomes a Commercial Argument

A provider that can deliver this information cleanly — up-to-date LEI, clear data-flow map, list of subcontractors, supported functions — saves its customer considerable time and reduces their compliance friction. Conversely, an opaque provider becomes a risk point the customer will look to replace. DORA transparency is not just admin overhead: it is a differentiating factor in an RFP against a competitor.

Mandatory Contractual Clauses (Article 30)

Article 30 is the operational heart of DORA for any ICT provider serving financial entities. It sets out the contractual minimum every arrangement must include, and a heavier set of clauses for arrangements that support a critical or important function. Both stacks are non-negotiable from your customer’s side — they are regulatory obligations, not bargaining positions — and the contract cannot be signed off as compliant without them.

Minimum Clauses for All ICT Contracts (Article 30(2))

For every ICT services contract — including those supporting non-critical functions — Article 30(2) requires the agreement to spell out:

  • A clear description of the functions and ICT services supplied, including any subcontracted services.
  • The locations where the data is processed and stored, and the conditions for any relocation.
  • Provisions on accessibility, integrity and security of data, including the protection of personal data.
  • The assistance the provider is to deliver — at no additional cost or at the cost agreed in advance — in case of an ICT incident affecting the service.
  • The obligation for the provider to cooperate fully with the competent authorities and resolution authorities of the financial entity.
  • Termination rights and minimum notice periods, in line with supervisory and resolution authority expectations.
  • The conditions for the provider’s participation in the financial entity’s ICT security-awareness programmes and digital operational resilience training, where applicable.

These are the baseline. Even a small SaaS vendor selling a non-critical monitoring tool to a bank will be expected to accept them. Treating them as standard clauses in your master services agreement template — rather than negotiating each one individually — is the single biggest productivity gain you can make.

Enhanced Clauses for Critical or Important Functions (Article 30(3))

If your service supports what the financial entity classifies as a critical or important function, Article 30(3) layers a much heavier stack on top of the baseline. You will be asked to accept:

  • Full service-level descriptions, including precise quantitative and qualitative performance targets to allow effective monitoring.
  • Notice periods and reporting obligations, including reports on developments that might materially impact the provider’s ability to deliver the service.
  • The obligation to implement and test business contingency plans and to maintain ICT security measures, tools and policies that ensure secure provision of the service.
  • Participation in and full cooperation with the financial entity’s Threat-Led Penetration Testing (TLPT) when the provider’s systems fall within the scope of testing.
  • Unrestricted rights of access, inspection and audit by the financial entity, an appointed third party, and the competent authority — including the right to take copies of relevant documentation on site.
  • Exit strategies and dedicated transition periods, during which the provider must continue to deliver the service to allow the financial entity to migrate to another provider or to bring the function back in-house.

The Article 30(3) stack is where most negotiations get stuck. Providers used to standard commercial contracts find the audit and exit clauses uncomfortable. The right preparation is to have a standardised DORA Schedule — a contract addendum already aligned with Article 30(3) — that you propose at the outset, rather than treating each clause as a one-off concession.

Audit, Access and Exit Rights — What You Will Need to Concede

Three rights cause the most discomfort and deserve specific preparation.

Audit rights must be effective. A clause that grants audit rights “subject to mutual agreement on scope and timing” is not enough — supervisors and your client’s internal control function will read it as a weakening of the obligation. Expect the right to cover the financial entity, an external auditor it appoints, and the competent authority itself, with reasonable notice but no veto from your side.

Access rights extend to your premises, systems, and any documentation relevant to the supplied service. Cloud and SaaS providers cannot escape this through standard “remote audit only” wording: the regulation contemplates on-site access where needed.

Exit rights require a documented, executable transition plan. Your customer must be able to move away from your service — to another provider or back in-house — without the migration itself becoming a stability event. In practice, this means contractual commitments on data portability, transition assistance during a defined period, and, in many cases, the obligation to support a parallel-running phase.

Subcontracting: DORA’s Chain of Responsibility

DORA does not stop at the boundary of your own organisation. The regulatory perimeter follows the data and the service through every layer of subcontracting, and your customer’s obligations cascade down with it. If you use third parties to deliver any part of the service — a hyperscaler for hosting, a managed-database provider, an offshore development partner, an identity-management SaaS — they are inside the perimeter your customer has to control.

Your Own Subcontractors Enter the Scope

For services supporting critical or important functions, the recently finalised RTS on sub-outsourcing requires you to obtain prior written authorisation from the financial entity before subcontracting a material portion of the service. You must also notify changes in your subcontractor stack with sufficient notice for the customer to assess and, where necessary, object.

In practice, that means three things. First, your subcontractor inventory needs to be available, accurate, and structured around the service you supply — not just a generic vendor list. Second, your own contracts with subcontractors must mirror the relevant Article 30 clauses, so the rights your customer holds against you can be exercised down the chain. Third, your concentration risk has to be visible: if a significant share of your service depends on a single hyperscaler region, your customer will want to see how you manage that exposure, and a competitor with a multi-region or multi-cloud posture will use it as a differentiator. The same approach is detailed from the financial entity’s perspective in our third-party risk management guide, useful background to anticipate how your customer will frame the conversation.

The Special Case of Critical ICT Third-Party Providers (CTPPs)

Most ICT providers will spend their DORA life under the contractual regime described above. A small group will not. Designation as a Critical ICT Third-Party Provider moves a firm from the indirect contractual perimeter into a direct European supervisory regime, with obligations owed not to a single financial entity but to the EU supervisory architecture itself.

How the ESAs Designate a CTPP and What the Oversight Framework Implies

Designation is made by the European Supervisory Authorities — EBA, EIOPA and ESMA — through a Joint Committee, based on a set of criteria including the systemic impact on the stability and continuity of financial services if the provider were to fail, the systemic importance of the financial entities relying on the provider, and the degree of substitutability of the provider. The first wave of designations was published in late 2025 and covers a small population concentrated around the major hyperscalers and other systemically important infrastructure suppliers.

Once designated, a CTPP enters the Oversight Framework run by a Lead Overseer (one of the three ESAs, depending on the provider’s main exposure). The Lead Overseer can request information, conduct inspections including on-site, issue formal recommendations on ICT risk management, and — in serious cases — apply periodic penalty payments. A designated provider must also have an EU subsidiary acting as a point of contact for the supervisor if it does not already have one.

For a provider that is not designated, two things still matter. First, the published CTPP list shapes how your customers think about concentration risk: if your competitor is a designated CTPP and you are not, that is sometimes a feature, sometimes a liability, depending on the customer. Second, the threshold for designation is not fixed forever — fast-growing providers with concentrated financial-services exposure can reach it within a few years, and pretending otherwise is a strategic blind spot.

Becoming “DORA-Ready”: A Checklist for ICT Providers

The providers that handle DORA best are not the ones who do the most — they are the ones who systematise. A DORA-ready posture is a small number of clean artefacts, repeated across the customer portfolio.

Exit Strategy, Incident Reporting, Resilience Testing on the Provider Side

  • A DORA contract schedule. A pre-drafted addendum, aligned with Article 30(2) and Article 30(3), that you propose at the start of every negotiation with a financial-services customer. Negotiating the same clauses thirty times against thirty different templates is the most expensive way to handle the regulation.
  • A customer information pack. A short document — usually under ten pages — containing your LEI, your data-flow map, your subcontractor list with locations, your security certifications (ISO 27001, SOC 2, etc.), your business-continuity test results, and your insurance position. Customers preparing their Register of Information will request these systematically.
  • An incident notification protocol. Articles 17 to 23 set out tight timelines (initial notification within hours, intermediate and final reports within days) for major ICT-related incidents. As a provider you will not file these yourself, but you will trigger them — your customer cannot meet their deadlines unless you alert them quickly enough. A documented internal escalation path with named contacts and target times is the minimum. Our DORA incident reporting reference walks through the deadlines as your customers see them.
  • A TLPT-ready posture. If you supply services that fall under Articles 24 to 27 (the Threat-Led Penetration Testing regime), your customers may include your systems in the test scope. You should know in advance how you would cooperate — a non-disruption clause, a dedicated technical contact, a process for handling vulnerabilities discovered during the test. The mechanics of the regime are covered in our TLPT requirements guide.
  • A documented exit plan. For every critical-or-important contract, a written exit playbook covering data export formats, parallel-running options, transition assistance, and the timeline. Customers will not always read it, but they will hold you to it in the rare moment they need it.
  • A subcontracting governance trail. Your vendor inventory, your contracts mirroring Article 30 clauses, your concentration-risk analysis, your authorisation log with each financial-services customer.

This list is not a marketing exercise — it is the artefact set a customer’s compliance officer will request when they vet you. Having it ready turns a multi-month onboarding into a multi-week one. For providers preparing this packaging, our third-party risk scoring tool covers the same material from the customer’s side — useful because the questions in your sales process will mirror the framework on which the customer is being assessed.

FAQ

Does DORA apply to ICT providers?

DORA applies directly to financial entities, not to ICT providers — with one exception. ICT providers designated as Critical ICT Third-Party Providers (CTPPs) by the European Supervisory Authorities are brought into a direct EU oversight framework. All other providers are governed indirectly: their financial-services customers pass DORA requirements through contractual clauses under Article 30.

What clauses must appear in a DORA-compliant ICT contract?

For every ICT contract, Article 30(2) requires clauses on service description, data location, security, incident assistance, cooperation with authorities, and termination rights. For contracts supporting a critical or important function, Article 30(3) adds full audit and access rights, exit strategies, participation in Threat-Led Penetration Testing where in scope, and detailed reporting and continuity obligations.

What is a Critical ICT Third-Party Provider (CTPP)?

A CTPP is an ICT provider designated by the European Supervisory Authorities under Article 31 as systemically important to the EU financial system. CTPPs are subject to direct European oversight by a Lead Overseer, with powers to request information, conduct inspections, and impose periodic penalty payments. The first list of designations was published in late 2025.

Does DORA apply to software vendors and SaaS providers?

Yes — indirectly. Any software vendor or SaaS provider supplying an ICT service to a regulated financial entity falls inside the perimeter of that entity’s DORA obligations. The vendor will be asked to accept the Article 30 clauses by contract and to provide the information the financial entity must enter into its Register of Information.

What is the Register of Information?

The Register of Information is a structured inventory each financial entity must maintain, listing every contractual arrangement with an ICT provider. It includes provider identity, services supplied, supported functions and their criticality, data locations, and subcontracting. Financial entities submit the Register to their competent authority on a recurring basis.

How can an ICT provider turn DORA into a commercial advantage?

By being ready before the customer asks. A pre-drafted DORA contract schedule, a clean customer information pack, a documented incident-notification protocol and an executable exit plan turn a months-long compliance negotiation into a short one. Providers who systematise this win against competitors who treat each DORA clause as an unwelcome surprise.