Selling ICT Services Into EU Finance? What DORA Actually Requires From You as the Vendor

If you sell cloud, managed services, software, or any ICT capability into EU banks, investment firms, payment institutions, or insurers, DORA is already in your contracts. It has been since the Regulation entered application on 17 January 2025.

Here is the distinction most vendor sales and legal teams get wrong: DORA does not regulate you, the ICT provider, the way it regulates the financial entity. There is no general "DORA registration" for vendors. Your exposure runs through two specific channels, and they are not the same thing.

Channel one is contractual flow-down. DORA obliges the financial entity to put certain terms into the contract with you. Those obligations land on you because your customer is legally required to make you sign them, not because DORA names you directly. Get this wrong in a negotiation and you will lose deals, because the financial entity cannot lawfully sign a contract that omits them.

Channel two is direct oversight, and it applies to a small set of providers only. If the European Supervisory Authorities (ESAs) designate you a Critical ICT Third-Party Provider (CTPP), you come under a Lead Overseer with investigation powers and penalty powers that bite your worldwide turnover. Most vendors will never be designated. The ones that are will know it.

This article walks both channels at control level, grounded in the actual articles of DORA, so you can tell your customers exactly what you are ready to provide.

Does DORA regulate ICT vendors directly, or only through the financial entities that buy from them?

Start with where the legal duty sits.

DORA Article 28 puts ICT third-party risk management on the financial entity. The financial entity must manage that risk as part of its own ICT risk framework, and it remains "fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law" even when it outsources to you. The accountability does not transfer. It stays with your customer.

That is why DORA reaches you contractually. Your customer cannot discharge its own duty without imposing specific terms on you. The obligations are theirs; the contractual clauses are how they meet them, and those clauses bind you.

The exception is the Oversight Framework in Section II. There, DORA does act on the provider directly, but only after the ESAs designate the provider as critical under Article 31. Absent that designation, you are not a standalone obligation-holder under DORA. You are a counterparty whose contract has to carry the financial entity's flow-down terms.

Hold both ideas at once: contractual flow-down for every in-scope vendor, direct oversight only for designated CTPPs.

How do DORA's obligations flow down to you contractually under Article 30?

Article 30 is the clause catalogue. It is the single most important article for a vendor to read, because it lists the contractual provisions your finance customer is required to obtain.

The framing matters. Article 30 is written as a minimum. The contract "shall include at least" the listed elements. Your customer's procurement and legal teams are not negotiating these in for sport. They are closing a gap that would otherwise leave the financial entity non-compliant.

Two more structural points before the list.

First, Article 30(1) requires the full contract, including the service level agreements, to be set out in one written document, available to both parties in a durable, downloadable, accessible format. A handshake plus a separate, informal SLA does not satisfy this.

Second, the catalogue has two tiers. Article 30(2) is the base set that applies to every ICT services contract. Article 30(3) adds a heavier set on top, and it applies only where the ICT service supports a critical or important function of the financial entity. Whether your service is "critical or important" is the financial entity's determination, not yours, but it drives which tier you are negotiating.

Which Article 30 clauses must be in every contract, and which extra ones apply for critical or important functions?

Here is the base set under Article 30(2), in plain operational terms:

→ A clear, complete description of all functions and ICT services you provide, stating whether you may subcontract a service supporting a critical or important function and, if so, on what conditions → The locations (regions or countries) where the functions and ICT services are provided and where data is processed and stored, plus your obligation to notify the financial entity in advance if you plan to change those locations → Provisions on the availability, authenticity, integrity, and confidentiality of data, including personal data → Provisions on access, recovery, and return of personal and non-personal data in an easily accessible format on your insolvency, resolution, discontinuation, or contract termination → Service level descriptions, including updates and revisions → Your obligation to provide incident assistance at no additional cost, or at a cost fixed ex-ante, when an ICT incident related to the service occurs → Your obligation to fully cooperate with the financial entity's competent authorities and resolution authorities → Termination rights and minimum notice periods aligned with supervisory expectations → The conditions for you to participate in the financial entity's ICT security awareness programmes and digital operational resilience training

Now the additional set under Article 30(3), which kicks in when your service supports a critical or important function:

→ Full service level descriptions with precise quantitative and qualitative performance targets, so the financial entity can monitor and trigger corrective action without undue delay when service levels are missed → Notice periods and reporting obligations on you, including notification of any development that could materially affect your ability to deliver the service in line with agreed levels → A requirement that you implement and test business contingency plans and maintain ICT security measures, tools, and policies appropriate to the financial entity's regulatory framework → Your obligation to participate and fully cooperate in the financial entity's threat-led penetration testing (TLPT) under Articles 26 and 27 → Ongoing monitoring rights, including unrestricted rights of access, inspection, and audit (covered in detail below) → Exit strategies, in particular a mandatory adequate transition period

If you sell into finance and your service touches a critical or important function, the Article 30(3) set is the difference between a contract your customer can sign and one its second line of defence will reject. Build for it.

What will a financial-entity customer ask you to prove before they sign?

Article 28 imposes pre-contract duties on the financial entity that translate directly into the diligence questions you will field.

Before entering the contract, the financial entity must, under Article 28(4): assess whether the arrangement covers a critical or important function, check whether supervisory conditions for contracting are met, identify and assess all relevant risks including ICT concentration risk, undertake "all due diligence" on you and confirm you are suitable, and identify conflicts of interest.

That due-diligence duty is the source of the security questionnaires and evidence requests you receive. They are not box-ticking. The financial entity is legally required to perform them.

Article 28(5) sets a hard gate. A financial entity "may only enter into contractual arrangements with ICT third-party service providers that comply with appropriate information security standards." Where the contract concerns critical or important functions, the financial entity must, before signing, take due consideration of your use of "the most up-to-date and highest quality information security standards." If you cannot demonstrate a current, credible security posture, your customer is not permitted to contract with you for those functions.

There is also the register of information. Article 28(3) requires every financial entity to maintain and update a register of all contractual arrangements for ICT services, distinguishing those that support critical or important functions from those that do not, and to make that register available to its competent authority on request. The ESAs have a standard template for it under Article 28(9). You will be asked for the structured data that populates the financial entity's register entry for your contract. Having that data clean and ready shortens every onboarding.

How does DORA treat your subcontracting chains and concentration risk?

Your subcontractors are in scope, by extension, through the financial entity's duties.

Article 29 requires the financial entity, when assessing risk for a critical-or-important-function arrangement, to consider whether contracting you would mean using a provider that is "not easily substitutable," or stacking multiple critical arrangements with you or with closely connected providers. That is the concentration-risk lens, and it can affect whether the deal proceeds at all.

Where your contract allows you to further subcontract a critical or important function, Article 29 obliges the financial entity to weigh the benefits and risks, with specific attention to subcontractors established in a third country. The financial entity must also assess how long or complex subcontracting chains could impair its ability to monitor the function and its competent authority's ability to supervise it.

The practical consequence for you: expect contracts to constrain subcontracting of critical functions, to require advance notice of subcontractor changes, and to make your full chain visible. Article 30(2)(a) requires the contract to state whether subcontracting of a critical or important function is permitted and on what conditions, so this is not optional small print.

What audit, access, and inspection rights must you actually grant, and to whom?

This is where vendor and customer expectations most often collide, so be precise.

For services supporting critical or important functions, Article 30(3)(e) requires the contract to give the financial entity ongoing monitoring rights, including:

→ Unrestricted rights of access, inspection, and audit by the financial entity (or an appointed third party) and by the competent authority, including the right to take copies of relevant documentation on-site, and these rights must not be impeded or limited by your other contractual arrangements or internal policies → The right to agree alternative assurance levels where other clients' rights would be affected → Your obligation to fully cooperate during on-site inspections and audits by the competent authorities, the Lead Overseer, the financial entity, or an appointed third party → Your obligation to provide details on the scope, procedures, and frequency of those inspections and audits

Note that the named beneficiaries include the Lead Overseer, not only your direct customer. That clause anticipates the oversight channel.

On the financial-entity side, Article 28(6) requires it to pre-determine, on a risk-based approach, the frequency and areas of audits and inspections using commonly accepted audit standards. So the audit rights are real and exercised on a defined cadence, not theoretical.

One narrow relief valve exists. Article 30(3) provides a derogation for microenterprise financial entities: they may agree that access, inspection, and audit rights are delegated to an independent third party you appoint, with the right to request information and assurance at any time. This applies only when your customer is a microenterprise.

What changes if the ESAs designate you a Critical ICT Third-Party Provider?

This is the second channel, and it changes your legal position entirely.

Under Article 31, the ESAs, through the Joint Committee and on a recommendation from the Oversight Forum, designate providers that are critical for financial entities. Designation rests on criteria in Article 31(2): the systemic impact of a large-scale operational failure on your part, the systemic character of the financial entities relying on you (including how many G-SIIs and O-SIIs depend on you), the degree to which financial entities rely on you for critical or important functions including indirectly through subcontracting, and your degree of substitutability.

If designated, you are assigned a Lead Overseer, one of the three ESAs, chosen as the authority responsible for the financial entities that together hold the largest share of total assets among your customers (Article 31(1)(b)).

Two structural consequences are worth flagging now.

If your group is established in a third country, Article 31(12) provides that financial entities may only use a designated critical provider that is established outside the Union if it has set up a subsidiary in the Union within the 12 months following designation. For a non-EU cloud or platform provider, that is a corporate-structure commitment, not a paperwork exercise.

Several categories are carved out of designation under Article 31(8), including ICT intra-group service providers and providers serving financial entities in a single Member State only where those entities are active solely in that Member State.

Once designated, the Lead Overseer assesses, under Article 33, whether you have sound rules, procedures, and arrangements to manage the ICT risk you pose to financial entities. The assessment focuses on the services supporting critical or important functions and covers ICT security and continuity, physical security of premises and data centres, risk-management and governance processes, incident detection and reporting, portability and interoperability that enable customers' termination rights, testing, ICT audits, and your use of relevant standards.

Article 35 gives the Lead Overseer the teeth. It can request all relevant information, conduct general investigations and inspections, and issue recommendations, including on your security and quality processes, the terms on which you serve financial entities to prevent single points of failure, and your planned subcontracting. It can even require you to refrain from a further subcontracting arrangement where cumulative conditions are met (third-country subcontractor, critical or important function, and a clear and serious risk to Union financial stability).

The enforcement point that focuses minds: under Article 35(6) to (8), if you fail to comply with required measures after at least 30 calendar days' notice, the Lead Overseer can impose a periodic penalty payment, levied daily for up to six months, of up to 1% of your average daily worldwide turnover in the preceding business year. That is daily, against worldwide turnover, until you comply.

What exit, termination, and data-return obligations must your contracts support?

Exit is a recurring DORA theme because regulators want financial entities to be able to leave you without service disruption.

On termination, Article 28(7) requires the financial entity to ensure the contract can be terminated in defined circumstances: a significant breach by you of laws, regulations, or contractual terms; monitoring findings that could alter performance, including material changes to your situation; evidenced weaknesses in your ICT risk management, particularly around data availability, authenticity, integrity, and confidentiality; and where the competent authority can no longer effectively supervise the financial entity because of the arrangement.

On exit, Article 28(8) requires the financial entity to have exit strategies for ICT services supporting critical or important functions, with tested, documented exit plans, identified alternative solutions, and transition plans to remove the contracted services and the relevant data from you and transfer them securely and integrally to another provider or back in-house.

For you, the contractual hook is Article 30(3)(f): contracts for critical or important functions must include exit strategies, in particular a mandatory adequate transition period during which you continue providing the function so the financial entity can migrate to another provider or to an in-house solution. Combined with Article 30(2)(d) on data access, recovery, and return in an easily accessible format, the message is unambiguous: your service has to be exitable, and the data has to come back clean.

What should an ICT provider have ready to show today? Checklist

Use this as a readiness self-check before your next finance deal. Each item maps to a specific DORA article above.

• A standard contract template carrying the full Article 30(2) base clause set, in one durable written document with SLAs included
• An Article 30(3) addendum for services supporting critical or important functions: full quantitative and qualitative SLAs, contingency-plan testing, TLPT cooperation, unrestricted audit rights, and a defined transition period
• A current, documented information-security posture you can evidence against recognised standards (Article 28(5))
• Clean, structured contract metadata to populate the financial entity's register of information (Article 28(3) and (9))
• A subcontractor inventory with locations, change-notification commitments, and explicit terms for subcontracting any critical or important function (Articles 29 and 30(2)(a))
• Access, inspection, and audit provisions naming the financial entity, its appointed third parties, the competent authority, and the Lead Overseer (Article 30(3)(e))
• A documented exit and transition package: data return in an accessible format, a mandatory transition period, and portability that lets the customer leave (Articles 28(8) and 30(3)(f))
• Incident-assistance terms with cost fixed ex-ante and a cooperation commitment with competent and resolution authorities (Article 30(2)(f) and (g))
• If you are large and systemically relied upon, a CTPP-readiness view: governance you could put in front of a Lead Overseer, and, for non-EU groups, a plan for the Article 31(12) EU-subsidiary requirement

The vendors winning EU finance contracts are the ones that turn up with these already drafted. The financial entity's legal team is not looking to educate you. It is looking to confirm you already know.

Aegis GRC maps every DORA clause your finance customers are obliged to impose, traced to the source article, so you can see your contractual readiness instead of guessing at it. Every obligation is traced to a verbatim quote from the legal text. No AI hallucinations. Map every DORA clause your finance customers will impose on you and see your contractual readiness at aegis-grc.com.

Frequently asked questions

Does DORA apply to me directly if I am just an ICT vendor? Not as a general entity obligation. DORA's duties sit on the financial entity, which under Article 28 stays fully responsible for compliance even when it outsources to you. Those duties reach you through the Article 30 contractual clauses your customer is required to impose. The one exception is direct ESA oversight, which applies only if you are designated a Critical ICT Third-Party Provider under Article 31.

What is the difference between the Article 30(2) and Article 30(3) clauses? Article 30(2) is the base clause set for every ICT services contract. Article 30(3) adds heavier obligations, full SLAs with quantitative targets, contingency-plan testing, TLPT cooperation, unrestricted audit rights, and a mandatory transition period, and applies only where your service supports a critical or important function of the financial entity.

Can a financial entity refuse to contract with me over security? Yes. Article 28(5) permits a financial entity to contract only with providers that meet appropriate information security standards, and for critical or important functions it must take due consideration of your use of the most up-to-date and highest quality standards before signing. A weak or undocumented posture can block the deal.

What is the worst-case penalty if I am designated critical and do not comply? Under Article 35, after at least 30 calendar days' notice the Lead Overseer can impose a periodic penalty payment of up to 1% of your average daily worldwide turnover in the preceding business year, levied daily for up to six months until you comply.