ICT third-party service providers · Article 2(1)(u)

Your bank customer sent a DORA addendum. This is what it commits you to.

DORA does not regulate you. It regulates your customer, and it tells your customer what has to be in your contract. Nineteen ICT providers in the EU are supervised directly. Everyone else is bound by the clauses in the document on your desk.

See the DORA service Decode your clauses

SaaS
Cloud and hosting
MSP
Core banking
Payments
Data providers

§ 01 Standing Art. 2(1)(u) · Art. 31(9)

Named in the scope article, absent from the supervision

DORA lists ICT third-party service providers among the entities it applies to, and then supervises almost none of them. That gap is the whole of your position, and it decides everything below.

Article 2(1) lists the entities the Regulation applies to. Points (a) to (t) are the twenty categories of financial entity: credit institutions, payment institutions, account information service providers, e-money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, fund managers, management companies, data reporting service providers, insurers and reinsurers, insurance intermediaries, occupational pension institutions, credit rating agencies, benchmark administrators, crowdfunding service providers and securitisation repositories. Point (u) is four words long: “ICT third-party service providers”.

Article 2(2) then quietly takes it back. Points (a) to (t) “shall collectively be referred to as financial entities”, and nearly every operative duty in DORA is written as a duty of a financial entity. The oversight machinery in Chapter V, Section II reaches only those providers the European Supervisory Authorities designate as critical under Article 31.

On 18 November 2025 the ESAs published that designation. There are nineteen names on it. If yours is not one of them, no supervisor will ever write to you about DORA. The Regulation reaches you through exactly one mechanism: the clauses Article 30 obliges your customer to put in your contract. That is not a lighter regime. It is the same substance, enforced by a counterparty with commercial leverage instead of by an authority with a procedure, and negotiated on a deadline set by your renewal date.

§ 02 Contract clause decoder Art. 30 · Art. 26 · RTS (EU) 2024/1773

Decode the addendum on your desk

State what your customer is, what you supply, and whether it has told you the service supports a critical or important function. The decoder returns the clause set that binds the contract, whether Article 30(3)(d) can pull you into a red team exercise, the audit rights you have granted, and the evidence you will be asked for.

Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.

Without the interactive decoder, the rule is short enough to apply by hand. Article 30(2) binds every contract for ICT services with a financial entity. Article 30(3) adds six clauses, and applies only where the ICT service supports a critical or important function, a determination the financial entity makes under Article 28(4)(a) before it signs. Here is the whole of both sets, in plain English.

Art. 30(2)(a) · A clear and complete description of every ICT service you provide, stating whether you may subcontract a service supporting a critical or important function, and on what conditions.
Art. 30(2)(b) · The regions and countries you deliver from and process and store data in, plus advance notice to the customer before you change any of them.
Art. 30(2)(c) · Provisions on availability, authenticity, integrity and confidentiality of data, personal and non-personal alike.
Art. 30(2)(d) · Access, recovery and return of the customer’s data in an easily accessible format on your insolvency, resolution or discontinuation, and on termination.
Art. 30(2)(e) · Service level descriptions, including how updates and revisions to them are made.
Art. 30(2)(f) · Assistance during an ICT incident at no additional cost, or at a cost determined in advance rather than quoted while the incident is running.
Art. 30(2)(g) · Full cooperation with your customer’s competent authorities and resolution authorities, including persons they appoint.
Art. 30(2)(h) · Termination rights and minimum notice periods aligned with what supervisors and resolution authorities expect, not with your standard terms.
Art. 30(2)(i) · The conditions on which your people take part in the customer’s ICT security awareness programme and digital operational resilience training.
Art. 30(3)(a) · Full service levels with precise quantitative and qualitative performance targets, so the customer can monitor you and require correction without undue delay.
Art. 30(3)(b) · Notice periods and reporting duties, including notification of any development that might materially affect your ability to keep delivering at the agreed level.
Art. 30(3)(c) · Business contingency plans that you implement and test, and security measures fitted to the customer’s regulatory framework rather than to your own.
Art. 30(3)(d) · Participation, and full cooperation, in the customer’s threat-led penetration test under Articles 26 and 27.
Art. 30(3)(e) · Unrestricted rights of access, inspection and audit for the customer, anyone it appoints and the competent authority, which no other contract or internal policy may impede.
Art. 30(3)(f) · An exit strategy with a mandatory transition period during which you keep the service running while the customer migrates elsewhere or brings it in house.

If your customer has not told you which paragraph your contract sits under, that is the question to ask before anything else in the draft is worth arguing about. It changes the audit rights you grant, whether you can be required to join a threat-led penetration test, and the evidence you will produce every year.

Threat-led testing. Only a paragraph 3 contract carries Article 30(3)(d). Identified financial entities test at least every 3 years, on live production systems, with an active red team phase of at least 12 weeks under Delegated Regulation (EU) 2025/1190, Article 11(5).
Audit rights. Only a paragraph 3 contract grants unrestricted rights of access, inspection and audit under Article 30(3)(e)(i), which no other contract term or internal policy may impede. Your own subcontractors must grant the same rights under Delegated Regulation (EU) 2025/532, Article 4(1)(j).
Evidence. Both paragraphs generate an annual data request: identifiers, service classification, locations and incident contacts under Implementing Regulation (EU) 2024/2956, plus, for paragraph 3, reports and independent test results under Delegated Regulation (EU) 2024/1773, Articles 8 and 9.

Get the test and evidence pack

Who is the customer?

The category decides which supervisory regime sits behind the contract. All four are financial entities under Article 2(1).

What do you supply?

Pick everything that applies. The codes are the service types your customer must classify you under in its register of information.

Has the customer classified your service as supporting a critical or important function?

Your customer makes this determination before it signs, under Article 28(4)(a). It is the single fact that changes the size of the contract.

DeterminationNot legal advice

Clauses your contract must contain

Article 30(2) · every ICT contract

Art. 30(2)(a)
A clear and complete description of every ICT service you provide, stating whether you may subcontract a service supporting a critical or important function, and on what conditions.
In scope
Art. 30(2)(b)
The regions and countries you deliver from and process and store data in, plus advance notice to the customer before you change any of them.
In scope
Art. 30(2)(c)
Provisions on availability, authenticity, integrity and confidentiality of data, personal and non-personal alike.
In scope
Art. 30(2)(d)
Access, recovery and return of the customer’s data in an easily accessible format on your insolvency, resolution or discontinuation, and on termination.
In scope
Art. 30(2)(e)
Service level descriptions, including how updates and revisions to them are made.
In scope
Art. 30(2)(f)
Assistance during an ICT incident at no additional cost, or at a cost determined in advance rather than quoted while the incident is running.
In scope
Art. 30(2)(g)
Full cooperation with your customer’s competent authorities and resolution authorities, including persons they appoint.
In scope
Art. 30(2)(h)
Termination rights and minimum notice periods aligned with what supervisors and resolution authorities expect, not with your standard terms.
In scope
Art. 30(2)(i)
The conditions on which your people take part in the customer’s ICT security awareness programme and digital operational resilience training.
In scope

Article 30(3) · critical or important functions only

Art. 30(3)(a)
Full service levels with precise quantitative and qualitative performance targets, so the customer can monitor you and require correction without undue delay.
In scope Out of scope Conditional
Art. 30(3)(b)
Notice periods and reporting duties, including notification of any development that might materially affect your ability to keep delivering at the agreed level.
In scope Out of scope Conditional
Art. 30(3)(c)
Business contingency plans that you implement and test, and security measures fitted to the customer’s regulatory framework rather than to your own.
In scope Out of scope Conditional
Art. 30(3)(d)
Participation, and full cooperation, in the customer’s threat-led penetration test under Articles 26 and 27.
In scope Out of scope Conditional
Art. 30(3)(e)
Unrestricted rights of access, inspection and audit for the customer, anyone it appoints and the competent authority, which no other contract or internal policy may impede.
In scope Out of scope Conditional
Art. 30(3)(f)
An exit strategy with a mandatory transition period during which you keep the service running while the customer migrates elsewhere or brings it in house.
In scope Out of scope Conditional

Threat-led penetration testing

You can be pulled in

Article 30(3)(d) puts participation and full cooperation in your contract. It is not an invitation you decline.
Identified financial entities run a TLPT at least every 3 years, and the authority may raise or lower that frequency. Art. 26(1).
The test runs on live production systems, and the customer must identify the underlying systems supporting critical or important functions “including those supporting the critical or important functions which have been outsourced or contracted to ICT third-party service providers”. Art. 26(2).
The active red team phase lasts at least 12 weeks. RTS (EU) 2025/1190, Art. 11(5).
In a pooled test, at least one scenario must target your own systems, processes and technologies. RTS (EU) 2025/1190, Art. 10(4).
Your own staff are normally not told. If anyone at your company detects the testing, the control team proposes measures to continue while keeping it secret. RTS (EU) 2025/1190, Art. 11(9).
Where participation would harm your non-DORA customers or the confidentiality of their data, Article 26(4) lets you and the financial entity agree in writing that you contract the external tester for a pooled test.

Not through this contract

Article 30(3) applies only to contracts for ICT services supporting critical or important functions. A paragraph 2 contract carries no TLPT clause.
That is a statement about this contract, not about you. A second contract with the same customer, or a first one with another, can carry paragraph 3.
The classification is not frozen. Your customer must tell its authority “when a function has become critical or important”, and the clause set changes with it. Art. 28(3).
Your customer may still ask you to take part voluntarily, and may still test the interfaces it owns without you.

Undecided, so assume yes

Participation binds you only if the contract falls under Article 30(3). Until your customer states the classification, you cannot price the risk.
Ask for the determination in writing before signature. Your customer already has to make it, under Article 28(4)(a), before it enters the arrangement.
If the answer turns out to be yes, budget for an active red team phase of at least 12 weeks against live production. RTS (EU) 2025/1190, Art. 11(5).
If it turns out to be no, the TLPT clause has no basis in Article 30 and should come out of the draft.

For a credit institution classified as significant under Article 6(4) of Regulation (EU) No 1024/2013, Article 26(8) allows only external testers. Expect a named third-party red team rather than the customer’s internal function.

Competent authorities decide which insurers must run TLPT, using the Article 26(8) criteria: impact on the financial sector, financial-stability concerns, and the entity’s ICT risk profile and maturity. Not every insurer is in the population.

A payment institution exempted under Directive (EU) 2015/2366, or an exempted electronic money institution, falls under Article 16(1) and sits outside the Article 26 TLPT population altogether. Confirm which kind of institution your customer is before pricing the clause.

A small and non-interconnected investment firm falls under Article 16(1) and sits outside the Article 26 TLPT population altogether. Larger investment firms are identified by their competent authority on the Article 26(8) criteria.

Access, inspection and audit

Unrestricted, by contract

Unrestricted rights of access, inspection and audit for the financial entity, an appointed third party and the competent authority, including the right to take copies of documentation on site. Art. 30(3)(e)(i).
Those rights may not be “impeded or limited by other contractual arrangements or implementation policies”. A confidentiality clause elsewhere in your paper does not survive this one. Art. 30(3)(e)(i).
You must fully cooperate during on-site inspections by the competent authorities, the Lead Overseer, the customer or its appointee. Art. 30(3)(e)(iii).
You are entitled to be told the scope, the procedures and the frequency in advance. Art. 30(3)(e)(iv), and the customer must pre-determine frequency and areas on a risk basis under Art. 28(6).
The one hinge in the text: the parties may “agree on alternative assurance levels if other clients’ rights are affected”. Art. 30(3)(e)(ii).
Your customer may organise pooled audits and pooled ICT testing, including threat-led penetration testing, jointly with other firms that use you. RTS (EU) 2024/1773, Art. 8(2)(b).
Your own subcontractors must grant the financial entity and the authorities the same rights of access, inspection and audit. RTS (EU) 2025/532, Art. 4(1)(j).

No statutory audit right

Article 30(2) contains no access, inspection or audit clause. Whatever audit right appears in a paragraph 2 draft is your customer’s commercial ask, not a statutory requirement, and it is negotiable on that basis.
Article 30(2)(g) still binds you to cooperate fully with the customer’s competent authorities and resolution authorities, and with persons they appoint.
Your customer still has to run due diligence on you before contracting and monitor you afterwards, so questionnaires and reports will still arrive. Art. 28(4)(d).
If the classification later changes, the unrestricted right arrives with it. Draft the audit clause as though it might.

Depends on the classification

An unrestricted right of access, inspection and audit exists only in Article 30(3). Nothing in Article 30(2) creates one.
Before you sign, get the classification in writing, and read the audit clause knowing which paragraph it is meant to implement.
If the draft grants unrestricted access on a service the customer has not classified as critical or important, say so and ask which article it is based on.
Refusing on-site audit outright is not a negotiating position: under RTS (EU) 2024/1773, Art. 6(1)(e), your consent to effective on-site audits is assessed before the contract exists.

Evidence you will be asked for

A valid, active LEI or EUID for your legal entity, and the same for any subcontractor underpinning the service.
ITS 2024/2956, Art. 3(5), (6)
Your service classified against the S01 to S19 type-of-ICT-services list, and the countries you deliver and store from.
ITS 2024/2956, Annex III
A named incident contact and the price of incident assistance, agreed in advance rather than quoted during the incident.
Art. 30(2)(f)
Records that the staff working on the account completed the customer’s security awareness and resilience training modules.
Art. 30(2)(i), Art. 13(6)
Periodic, incident, service delivery, ICT security and business continuity reports, on the cadence the contract sets.
RTS 2024/1773, Art. 9(2)(a)
A current independent test report whose scope demonstrably covers the systems and key controls your customer named.
RTS 2024/1773, Art. 8(3)(b)
Evidence that business contingency plans exist, are implemented and have actually been tested.
Art. 30(3)(c)
A transition plan showing how the customer leaves you without disruption, and evidence that it has been rehearsed.
Art. 30(3)(f), RTS 2024/1773, Art. 10
Region and data-location declarations for every environment, and the notice process before you move one.
Art. 30(2)(b)
Tenant isolation and access-path evidence for the customer’s environment, plus the results of your resilience testing.
Art. 30(3)(c)
Secure development and release evidence for the versions actually in use, and your vulnerability-handling timelines.
Art. 28(5)
A current application or API penetration test report, dated inside the customer’s assurance cycle.
RTS 2024/1773, Art. 6(3)(a)
The procedure for returning and deleting data on insolvency, resolution, discontinuation and ordinary termination.
Art. 30(2)(d)
The controls behind availability, authenticity, integrity and confidentiality, and the processing and storage locations.
Art. 30(2)(c)
Privileged-access controls, and joiner, mover and leaver records for the people who can reach the customer’s systems.
Art. 28(5)
The full subcontracting chain behind your service desk, with the monitoring and reporting duties written into each link.
RTS 2025/532, Art. 4(1)(f)

The list grows with the services you selected. It is what a financial-sector due-diligence pack routinely contains, not a statutory checklist.

Get the test and evidence pack

This decoder reads the Regulation, not your contract. Article 30 sets a floor, and your customer is free to demand more. Nothing here is legal advice, and no answer you give is transmitted, stored or added to any link.

§ 03 Paragraph three Art. 30(3)(a) to (f)

The six clauses that only appear when the function is critical

Paragraph 2 is mostly administrative. Paragraph 3 is where the cost sits. Here are the six additions, quoted, with what each one costs a supplier to honour and where the text leaves room to move.

Article 30(3) opens with a sentence worth reading twice: “The contractual arrangements on the use of ICT services supporting critical or important functions shall include, in addition to the elements referred to in paragraph 2, at least the following”. Paragraph 3 is cumulative, not alternative. A critical-function contract carries fifteen mandatory elements, not six.

None of the six can simply be struck out. What can be negotiated is how they are implemented: notice periods, the cadence and format of reporting, the assurance route, the length and price of the transition period. Article 30(4) also tells both parties to “consider the use of standard contractual clauses developed by public authorities for specific services”, which is a legitimate way to move a negotiation off your counterparty’s in-house paper.

Art. 30(3)(a)Service levels

Quantitative targets, not best endeavours

“full service level descriptions … with precise quantitative and qualitative performance targets within the agreed service levels to allow effective monitoring by the financial entity of ICT services and enable appropriate corrective actions to be taken, without undue delay, when agreed service levels are not met”

Costs you Measurable targets you can be held to, plus the telemetry to prove them and a corrective-action process with a clock on it.

Room to move The numbers themselves. Agree targets you can actually hit across the whole customer base, and define the measurement method in the contract rather than leaving it to be argued later.

Art. 30(3)(b)Notification

You report your own bad news

“notice periods and reporting obligations of the ICT third-party service provider to the financial entity, including notification of any development that might have a material impact on the ICT third-party service provider’s ability to effectively provide the ICT services supporting critical or important functions in line with agreed service levels”

Costs you A duty to volunteer material change: funding trouble, a key-person loss, an acquisition, an architecture migration, a subcontractor failure.

Room to move The definition of “material” and the notice period. Both are unspecified in the Regulation, and both belong in the contract rather than in a later dispute.

Art. 30(3)(c)Contingency

Contingency plans that are tested, and security fitted to their framework

“requirements for the ICT third-party service provider to implement and test business contingency plans and to have in place ICT security measures, tools and policies that provide an appropriate level of security for the provision of services by the financial entity in line with its regulatory framework”

Costs you Continuity plans you exercise and can evidence, and a security baseline benchmarked against your customer’s regulatory framework rather than your own risk appetite.

Room to move Which framework and which evidence. Pin the reference standard in the contract so that “in line with its regulatory framework” does not become an open-ended obligation renewed at every supervisory letter.

Art. 30(3)(d)Threat-led testing

Participation in the customer’s red team exercise

“the obligation of the ICT third-party service provider to participate and fully cooperate in the financial entity’s TLPT as referred to in Articles 26 and 27”

Costs you Engineering and security time across a test whose active red team phase alone lasts at least 12 weeks, run against live production, usually without telling your own operations team.

Room to move Article 26(4). Where participation would adversely affect the quality or security of the services you deliver to customers outside DORA, or the confidentiality of their data, you and the financial entity may agree in writing that you contract the external tester for a pooled test.

Art. 30(3)(e)Audit

Unrestricted access, inspection and audit

“unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority, and the right to take copies of relevant documentation on-site … the effective exercise of which is not impeded or limited by other contractual arrangements or implementation policies”

Costs you On-site audits by the customer, its appointee and its supervisor, repeated on a frequency your customer pre-determines under Article 28(6), with your own subcontractors bound to grant the same access.

Room to move Sub-point (ii): “the right to agree on alternative assurance levels if other clients’ rights are affected”. That is the clause behind pooled audits, shared reports and a published assurance calendar, and it is the only limit the text itself offers.

Art. 30(3)(f)Exit

A transition period you must keep serving through

“exit strategies, in particular the establishment of a mandatory adequate transition period … during which the ICT third-party service provider will continue providing the respective functions, or ICT services … allowing the financial entity to migrate to another ICT third-party service provider or change to in-house solutions”

Costs you A duty to keep running a service you have already lost, for a period long enough for the customer to move, with data export in an accessible format under Article 30(2)(d).

Room to move The length, the price and the definition of “adequate”. Price the transition period as a service rather than as an obligation, and agree what migration support is included before it is needed.

Quotations are verbatim from Article 30 of Regulation (EU) 2022/2554 as published on EUR-Lex, trimmed only where an ellipsis is shown. Article 30(3) also carries one derogation, from point (e) alone, and it depends on the customer being a microenterprise: fewer than 10 staff and turnover or balance sheet total at or below EUR 2 million. Almost no bank qualifies.

§ 04 Determination Art. 3(22) · Art. 28(4)(a)

Critical or important function: the call you do not get to make

One determination decides whether your contract carries nine clauses or fifteen, whether you can be pulled into a red team exercise, and whether you have granted unrestricted audit rights. Your customer makes it.

Article 3(22) defines a critical or important function as “a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law”.

Read what that definition is about. It is a statement about the customer’s function, not about your product. A small tool can support a critical function; a large platform can support none. Recital 70 adds that the definition also encompasses the “critical functions” defined in Article 2(1), point (35), of Directive 2014/59/EU, the bank recovery and resolution directive, which pulls resolution planning into the same word.

Article 28(4)(a) puts the determination squarely with the financial entity, before contracting: it “shall … assess whether the contractual arrangement covers the use of ICT services supporting a critical or important function”. Article 28(3) then requires the register of information to distinguish contracts that do from contracts that do not, and requires the entity to inform its competent authority “when a function has become critical or important”. The classification is a live value, not a one-off.

Does the supplier decide?

No

Nothing in DORA gives the ICT provider a role in the determination. You can supply facts and you can argue, but you cannot classify your own service.
Does the financial entity decide?

Yes

Article 28(4)(a), before entering the arrangement, as part of its own ICT risk management framework and under its management body’s responsibility.
Can it change after signature?

Yes

Article 28(3) obliges the entity to inform its competent authority when a function has become critical or important. Your clause set moves with it.
Does your own size matter?

No

The definition measures impairment at the financial entity, not headcount or revenue at the supplier. A three-person vendor can hold a critical-function contract.

Signals that point towards a critical or important classification
Signal	Why it points that way	Basis
Your service sits in a licensed activity	Failure would impair the entity’s continuing compliance with the conditions of its authorisation, which is the second limb of the definition	Art. 3(22)
There is no ready substitute	Substitutability is one of the criteria the ESAs themselves used when designating critical providers, and supervisors apply the same instinct downwards	Art. 31(2)
An outage stops customer-facing service	Disruption would materially impair the soundness or continuity of the entity’s services and activities, the first limb of the definition	Art. 3(22)
The customer asked for an exit plan and a tested transition period	Exit strategies are required for ICT services supporting critical or important functions, so the ask reveals the classification	Art. 28(8), Art. 30(3)(f)
The draft addendum contains audit and TLPT clauses	Both live only in Article 30(3). Their presence is your customer telling you the answer before it says so	Art. 30(3)(d), (e)
You appear in a resolution plan discussion	The definition expressly encompasses the critical functions of Directive 2014/59/EU	Recital 70

§ 05 Threat-led testing Art. 26 · RTS (EU) 2025/1190

What “participate and fully cooperate” costs in calendar time

A threat-led penetration test is not a scan of your product. It is an intelligence-led red team exercise against live production, run to a supervisory methodology, and Article 30(3)(d) makes your participation a contractual duty.

Article 26(1) requires identified financial entities, other than microenterprises and the entities under the simplified framework in Article 16(1), to carry out advanced testing by means of TLPT at least every 3 years. Article 26(2) requires the test to cover several or all of the entity’s critical or important functions and to be “performed on live production systems”, and requires the entity to identify all relevant underlying systems “including those supporting the critical or important functions which have been outsourced or contracted to ICT third-party service providers”. That sentence is how you end up in scope.

Article 26(3) then makes it the customer’s job to get you there: where providers are included in the scope, the financial entity “shall take the necessary measures and safeguards to ensure the participation of such ICT third-party service providers”, while retaining full responsibility for compliance. In practice the necessary measure is the clause it already put in your contract.

The detail is in Delegated Regulation (EU) 2025/1190, the TLPT regulatory technical standard, which is written around the TIBER-EU framework. The numbers below come from its text, and they are the ones that decide how much of your year this takes.

01

Identification

The competent authority identifies which financial entities must perform TLPT, weighing the entity’s impact on the financial sector, financial-stability concerns, and its specific ICT risk profile and maturity. You find out because your customer tells you.

Who runs it
Competent authority

Basis
Art. 26(8)
02

Scoping

The entity assesses which critical or important functions the test must cover and identifies every underlying system supporting them, including the ones contracted to you. The resulting scope is validated by the competent authority, which is why it is not renegotiable later.

Who runs it
Customer, validated by the authority

Basis
Art. 26(2)
03

Threat intelligence

A threat intelligence provider builds targeted intelligence and proposes scenarios. The control team lead selects at least three, of which no more than one may be non-threat-led. For a pooled test, at least one scenario must include your relevant underlying systems, processes and technologies.

Who runs it
Threat intelligence provider

Basis
RTS (EU) 2025/1190, Art. 10
04

Active red team

Testers execute the scenarios against live production for at least 12 weeks. Detection by any of your staff does not end the test: the control team proposes measures to continue while preserving secrecy. In an emergency the test may be suspended, or continued as a limited purple teaming exercise that still counts towards the 12 weeks.

Who runs it
External testers under Art. 27

Basis
RTS (EU) 2025/1190, Art. 11
05

Closure

Reports and remediation plans are agreed, a summary of findings and the supporting documentation go to the authority, and the authority issues an attestation that the test met the requirements. Your remediation commitments are negotiated here, in writing.

Who runs it
Customer, testers and the authority

Basis
Art. 26(6), 26(7)

The route where you hold the contractArt. 26(4)

Pooled testing turns the supplier into the paying client

“the financial entity and the ICT third-party service provider may agree in writing that the ICT third-party service provider directly enters into contractual arrangements with an external tester, for the purpose of conducting, under the direction of one designated financial entity, a pooled TLPT involving several financial entities (pooled testing) to which the ICT third-party service provider provides ICT services”Regulation (EU) 2022/2554, Article 26(4)

The gate is a harm test: participation must be “reasonably expected to have an adverse impact on the quality or security of services delivered by the ICT third-party service provider to customers that are entities falling outside the scope of this Regulation, or on the confidentiality of the data related to such services”. A multi-tenant platform with non-financial customers meets it on its face.
It is a written agreement, not a right. You propose it; the financial entity has to agree.
The pooled test “shall be considered TLPT carried out by the financial entities participating”, so it discharges their obligation and replaces a queue of separate exercises against the same platform.
One designated financial entity directs it, and where several authorities are involved they agree which entity leads. RTS (EU) 2025/1190, Art. 16(5).
You choose the tester, subject to Article 27(1): demonstrated expertise in threat intelligence, penetration testing and red team testing, certification by a Member State accreditation body or adherence to formal codes of conduct, independent assurance over the risk management of the test, and professional indemnity insurance.

§ 06 Access and audit Art. 30(3)(e) · Art. 28(6) · RTS (EU) 2024/1773

Unrestricted means unrestricted

Article 30(3)(e) is the clause suppliers under-read most often. It grants three separate parties a right of entry, and it pre-empts every confidentiality term you have elsewhere in the same contract.

The clause is a right to monitor “on an ongoing basis”, and it names the parties: the financial entity, an appointed third party, and the competent authority. It includes “the right to take copies of relevant documentation on-site if they are critical to the operations of the ICT third-party service provider”, and it states that the effective exercise of the right must not be “impeded or limited by other contractual arrangements or implementation policies”. An NDA, a security policy that forbids visitors, or a standard term restricting audits to once a year does not survive that sentence.

This is not an unbounded right in practice, because Article 28(6) obliges the financial entity to pre-determine, on a risk basis, the frequency of audits and inspections and the areas to be audited, “adhering to commonly accepted audit standards”. Where the arrangement is technically complex, it must also verify that its auditors have the skills to perform the work. Ask for that plan; it is the customer’s own obligation, and having it in writing is how an unrestricted right becomes a schedulable one.

The delegated regulation on the customer’s ICT third-party policy, Delegated Regulation (EU) 2024/1773, then decides what your certificates are worth. Article 8(2) requires the contract to allow the entity “to access information, to carry out inspections and audits, and to perform tests on ICT”, by its own audit or an appointed third party, by pooled audits and pooled ICT testing including threat-led penetration testing, by third-party certifications, or by audit reports you make available.

Art. 30(3)(e)(i)

Access, inspection, audit and copies

Unrestricted rights for the financial entity, an appointed third party and the competent authority, including copies of documentation taken on site, and no other contract term or internal policy may impede them.
Art. 30(3)(e)(ii)

Alternative assurance levels

The parties may agree alternative assurance levels where other clients’ rights are affected. This is the textual basis for a pooled audit programme and a published assurance calendar.
Art. 30(3)(e)(iii)

Cooperation during on-site inspections

Full cooperation during on-site inspections and audits performed by the competent authorities, the Lead Overseer, the financial entity or its appointee.
Art. 30(3)(e)(iv)

Scope, procedure, frequency

You must be given details of the scope, the procedures to be followed and the frequency of inspections and audits. Use it: an audit you can plan for is cheaper than one you cannot.
Art. 28(6)

A pre-determined audit plan

The financial entity must pre-determine frequency and areas on a risk basis, adhering to commonly accepted audit standards, and must verify that complex work is audited by people competent to audit it.
RTS 2025/532, Art. 4(1)(j)

The same rights, one level down

Your contract with any subcontractor supporting a critical or important function must grant the financial entity and the authorities the same rights of access, inspection and audit that you granted.

The assurance routes a customer may use, and the conditions attached
Route	What it is	Condition attached
Own or appointed audit	The entity’s internal audit function, or a third party it appoints, auditing you directly	Always available under Art. 30(3)(e)(i); frequency and areas pre-determined under Art. 28(6)
Pooled audit or pooled ICT testing	Several financial entities that use you audit or test jointly, including by threat-led penetration testing	Expressly permitted by RTS 2024/1773, Art. 8(2)(b), and the practical answer to audit fatigue
Third-party certification	An ISO/IEC 27001 certificate or comparable attestation you already hold	Usable only under the eight conditions in RTS 2024/1773, Art. 8(3), and never on its own over time
Your audit reports	Internal audit or independent assurance reports you make available	Same eight conditions; the entity must satisfy itself the scope covers the systems and key controls it identified
Independent test report	A penetration test or independent assessment commissioned by you or on the entity’s behalf	Named in RTS 2024/1773, Art. 6(3)(a) and (b) as an element of the required level of assurance

§ 07 Register of information Art. 28(3) · ITS (EU) 2024/2956

The data request that arrives every first quarter

Your customer keeps a register of every ICT contract it holds and files it with its supervisor annually. Most of what goes in the row about you has to come from you, and the request lands on the same schedule every year.

Article 28(3) requires every financial entity to maintain and update, at entity, sub-consolidated and consolidated level, “a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers”, documented so as to distinguish contracts covering critical or important functions from those that do not. Implementing Regulation (EU) 2024/2956 sets the templates.

Two of its rules reach you directly. Article 3(5) requires the entity to identify every provider that is a legal person by a valid, active LEI or the European Unique Identifier, and both where available. Article 3(6) goes a level deeper: where the service supports a critical or important function, the entity must ensure, through you, that every subcontractor which effectively underpins that service also has a valid LEI or provides its EUID. If you have never obtained an LEI, this is the clause that makes you.

The filing dates are national. Latvijas Banka states that after the first submission, due 15 April 2025 on 31 March 2025 data, financial entities file the register annually by 1 March, using the previous year’s 31 December data. Read that backwards from a supplier’s calendar: the questionnaire asking you to confirm identifiers, service types, locations and subcontractors arrives in January or February, every year, from every financial customer you have.

What your customer needs from you for its register row
Field	What you supply	Basis
Provider identifier	A valid, active LEI or your EUID, and both if you have both. Third-country providers are identified by LEI only	ITS 2024/2956, Art. 3(5)
Subcontractor identifiers	LEI or EUID for every subcontractor that effectively underpins a critical or important function service	ITS 2024/2956, Art. 3(6)
Type of ICT services	One or more codes from the S01 to S19 list in Annex III, matched to what you actually deliver	ITS 2024/2956, Annex III
Function classification	Confirmation of whether the contract supports a critical or important function, which the entity determines and records	Art. 28(3), Art. 28(4)(a)
Locations	Countries of provision, of the provider’s headquarters, and of data processing and storage	Art. 30(2)(b)
Contract dates and notice	Start and end dates, notice periods and the termination grounds already in the contract	Art. 30(2)(h)

Annex III · type of ICT services

S01 ICT project management
S02 ICT Development
S03 ICT help desk and first level support
S04 ICT security management services
S05 Provision of data
S06 Data analysis
S07 ICT, facilities and hosting services
S08 Computation
S09 Non-Cloud Data storage
S10 Telecom carrier
S11 Network infrastructure
S12 Hardware and physical devices
S13 Software licencing (excluding SaaS)
S14 ICT operation management
S15 ICT Consulting
S16 ICT Risk management
S17 Cloud services: IaaS
S18 Cloud services: PaaS
S19 Cloud services: SaaS

Labels are the identifiers used in Annex III to Implementing Regulation (EU) 2024/2956, shortened for S07 and S14 only. Annex III describes S02 as covering “business analysis, software design and development, testing”, and S14 as including managed service providers. Pick the codes yourself before your customer picks them for you: the classification travels with your name into a supervisory filing.

§ 08 Guides Four long-form references

The four questions suppliers ask first

Each guide is written from the supplier’s side of the contract and cites the article behind every claim.

§ 09 Questions Answered from the text

Questions suppliers ask before signing

Short answers, each traceable to an article. Where the Regulation is silent, this page says so instead of guessing.

Does DORA apply to us if we are not a financial entity?

Directly, almost certainly not. Article 2(1)(u) lists ICT third-party service providers among the entities the Regulation applies to, but Article 2(2) reserves the term “financial entity” for points (a) to (t), and the direct oversight regime in Chapter V applies only to providers designated as critical under Article 31. Nineteen firms were designated on 18 November 2025. Everyone else is reached through the contract clauses Article 30 obliges the financial entity to impose.

What is the difference between Article 30(2) and Article 30(3)?

Article 30(2) sets nine elements that must appear in every contractual arrangement on the use of ICT services with a financial entity. Article 30(3) adds six more, and applies only where the ICT services support a critical or important function. Paragraph 3 is cumulative: a critical-function contract carries all fifteen. The six additions are quantitative service levels, material-change notification, tested contingency plans, TLPT participation, unrestricted access and audit rights, and an exit strategy with a mandatory transition period.

Who decides whether our service supports a critical or important function?

The financial entity, before it contracts, under Article 28(4)(a). The definition in Article 3(22) measures impairment at the financial entity, not at the supplier, so it is about what the customer uses the service for. The determination can change during the life of the contract: Article 28(3) requires the entity to tell its competent authority when a function has become critical or important. Ask for the classification in writing before signature.

Can a bank really force us into a red team test of our own production systems?

If the contract falls under Article 30(3), yes, by the clause it obliges the bank to include. Article 30(3)(d) requires participation and full cooperation in the financial entity’s TLPT. Article 26(2) requires the test to run on live production systems and requires the entity to identify underlying systems supporting critical or important functions, including those contracted to providers. Delegated Regulation (EU) 2025/1190 sets an active red team phase of at least 12 weeks.

Is there a way to avoid a separate red team exercise for every bank customer?

Article 26(4) is the route. Where your participation would be reasonably expected to adversely affect the quality or security of services you deliver to customers outside DORA, or the confidentiality of their data, you and the financial entity may agree in writing that you contract the external tester directly for a pooled TLPT covering several of your financial customers, under the direction of one designated entity. The pooled test counts as TLPT carried out by every participating entity. It is an agreement, not a right, so propose it early.

Can we cap or refuse the audit rights?

Not in a critical-function contract. Article 30(3)(e)(i) requires unrestricted rights of access, inspection and audit whose effective exercise is “not impeded or limited by other contractual arrangements or implementation policies”. The one hinge in the text is point (ii), which lets the parties agree alternative assurance levels where other clients’ rights are affected. Refusal is worse than useless: under Delegated Regulation (EU) 2024/1773, Article 6(1)(e), your consent to effective on-site audits is assessed during due diligence, before the contract exists.

We are ISO/IEC 27001 certified. Is that enough?

No, and the reason is written down. Delegated Regulation (EU) 2024/1773, Article 8(3) states that the financial entity “shall not over time rely solely on certifications … or audit reports”. Reliance is conditional on eight further tests, including that the scope covers the systems and key controls the entity itself identified, that the report is not obsolete, that the audit tested the operational effectiveness of key controls, and that the entity keeps the right to run its own individual and pooled audits at its discretion. A certificate shortens the conversation; it does not end it.

What happens to our own subcontractors?

Delegated Regulation (EU) 2025/532 pushes the regime one level down. The contract must identify which critical-function services may be subcontracted and on what conditions, make you responsible for the services your subcontractors provide, and require that your subcontractors grant the financial entity and the authorities the same rights of access, inspection and audit. Article 5 goes further: you must notify intended material changes to your subcontracting and may only implement them after the financial entity has approved or not objected within the notice period.

Why do we get a data request every February?

Because of the register of information. Article 28(3) requires every financial entity to maintain a register of all its ICT contracts and file it with its supervisor. Implementing Regulation (EU) 2024/2956 sets the templates and requires an LEI or EUID for you and, where the service supports a critical or important function, for the subcontractors underpinning it. Latvijas Banka states that entities file annually by 1 March using the previous 31 December data, so the questionnaire reaches you in the weeks before that.

Does DORA make our staff sit the bank’s security training?

It makes the contract address the question. Article 30(2)(i) requires the contract to set out “the conditions for the participation of ICT third-party service providers in the financial entities’ ICT security awareness programmes and digital operational resilience training in accordance with Article 13(6)”. Article 13(6) obliges financial entities to run those programmes as compulsory modules for their own staff and says they “shall also include ICT third-party service providers in their relevant training schemes” where appropriate. So the extent is negotiable; the presence of the clause is not.

Sources

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) EUR-Lex · 2022 Articles 2, 3, 13, 16, 24 to 31 are quoted throughout this site.
Commission Delegated Regulation (EU) 2024/1773: the policy on contractual arrangements for ICT services supporting critical or important functions EUR-Lex · 2024
Commission Delegated Regulation (EU) 2025/532: subcontracting of ICT services supporting critical or important functions EUR-Lex · 2025
Commission Delegated Regulation (EU) 2025/1190: regulatory technical standards on threat-led penetration testing EUR-Lex · 2025
Commission Implementing Regulation (EU) 2024/2956: standard templates for the register of information EUR-Lex · 2024
European Supervisory Authorities designate critical ICT third-party providers under DORA EIOPA, for the Joint Committee of the ESAs · 2025 The list of nineteen designated providers, published 18 November 2025.
Informācijas reģistra (RoI) iesniegšana: register of information submission dates Latvijas Banka · 2026
Digital Operational Resilience Act (DORA) European Securities and Markets Authority · 2026