Learn
CorrectionCorrected on 14 July 2026. An earlier version of this article contained a quotation attributed to “ESA guidance on DORA implementation” that we cannot source, a statistic about the share of contracts missing mandatory clauses that we cannot source, a table of “what supervisors find” that had no published basis, and a set of article citations that pointed at the wrong provisions, including a claim that Article 29(1) requires an annual concentration assessment when it is in fact a pre-contractual one. All of that has been cut or corrected against the Official Journal texts. The clause count has been replaced with the actual structure: nine elements under Article 30(2) for every ICT contract, six more under Article 30(3) where the service supports a critical or important function.
Chapter V of DORA, Articles 28 to 44, covers ICT third-party risk. It splits in two. Section I, Articles 28 to 30, is what financial entities have to do: the register, the pre-contractual assessment, the concentration assessment, the mandatory contract clauses and the exit strategies. Section II, Articles 31 to 44, is the oversight framework for critical ICT third-party service providers, which is the supervisors' side of the arrangement rather than yours.
This guide covers Section I, plus the three technical standards that sit under it: Implementing Regulation (EU) 2024/2956 for the register templates, Delegated Regulation (EU) 2024/1773 for the policy on ICT services supporting critical or important functions, and Delegated Regulation (EU) 2025/532 for subcontracting.
One clarification worth making early, because it is a common mix-up. Article 28(9) mandates implementing technical standards, which became the register templates in ITS (EU) 2024/2956. Article 28(10) mandates regulatory technical standards on the content of the third-party policy, which became Delegated Regulation (EU) 2024/1773. They are different instruments doing different jobs, and a register built against the wrong one will not export.
📜
Chapter V, Section I
What DORA Requires for ICT Third-Party Risk
Article 28(1) sets the frame: financial entities “shall manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework”. That is the sentence that stops this being a standalone vendor programme. The obligations then run across the ICT service lifecycle.
The strategy and the policy (Art. 28(2))
Entities other than microenterprises and other than those in Art. 16(1) must adopt and regularly review a strategy on ICT third-party risk, including a policy on the use of ICT services supporting critical or important functions. The management body “shall regularly review the risks identified in respect to contractual arrangements on the use of ICT services supporting critical or important functions”. The content of that policy is specified by RTS (EU) 2024/1773.
The register (Art. 28(3))
Maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers, distinguishing those that support critical or important functions from those that do not.
Before you sign (Art. 28(4))
Assess whether the arrangement covers a critical or important function; assess whether the supervisory conditions for contracting are met; identify and assess all relevant risks, including whether the arrangement would reinforce ICT concentration risk under Art. 29; carry out due diligence on the prospective provider; and identify and assess conflicts of interest.
Security standards (Art. 28(5))
You may only contract with providers that comply with appropriate information security standards. Where the arrangement concerns critical or important functions, you must take due consideration, before concluding it, of the provider's use of “the most up-to-date and highest quality information security standards”.
Audit rights, exercised (Art. 28(6))
Having audit rights is not enough. You must pre-determine, on a risk basis, the frequency of audits and inspections and the areas to be audited. Where the arrangement is technically complex, you must verify that the auditors have the skills to actually perform the audit.
Termination and exit (Art. 28(7), 28(8))
Contracts must be terminable in the four circumstances Art. 28(7) lists. For ICT services supporting critical or important functions, you must have exit strategies that are comprehensive, documented, sufficiently tested and periodically reviewed.
What Article 28(3) actually says you report, and to whom
The yearly reporting obligation runs to your competent authority, not directly to the ESAs, and it is narrower than the full register: entities “shall report at least yearly to the competent authorities on the number of new arrangements on the use of ICT services, the categories of ICT third-party service providers, the type of contractual arrangements and the ICT services and functions which are being provided”. Separately, you must make the full register, or specified sections of it, available to the competent authority on request, and you must inform it in a timely manner about any planned contractual arrangement on ICT services supporting critical or important functions, and when a function becomes critical or important.
📝
Article 30
The Contract Clauses: Nine, Plus Six
Article 30 is the most operationally consequential provision in Chapter V, and the clause count is frequently reported wrong. There is no single list of “14 clauses”. There are two lists.
Article 30(1) comes first and is easy to overlook: the rights and obligations of both parties must be “clearly allocated and set out in writing”, and “the full contract shall include the service level agreements and be documented in one written document” available on paper or in a downloadable, durable and accessible format. A contract split across an unsigned order form, a web page of terms and a service description PDF is already a finding waiting to happen.
Article 30(2): the nine elements every ICT contract must include
| Art. 30(2) | Element | What it must contain |
|---|---|---|
| (a) | Description of functions and ICT services, and the subcontracting position | A clear and complete description of all functions and ICT services, indicating whether subcontracting of an ICT service supporting a critical or important function, or material parts of it, is permitted and, if so, the conditions that apply. |
| (b) | Locations of provision and of data processing | The regions or countries where the contracted or subcontracted functions and ICT services are provided and where data is processed, including the storage location, plus a requirement on the provider to notify you in advance if it plans to change them. |
| (c) | Data protection provisions | Provisions on availability, authenticity, integrity and confidentiality in relation to the protection of data, including personal data. |
| (d) | Access, recovery and return of data | Provisions ensuring access to, recovery of and return of personal and non-personal data in an easily accessible format in the event of the provider's insolvency, resolution or discontinuation of business, or on termination. |
| (e) | Service level descriptions | Service level descriptions, including updates and revisions to them. |
| (f) | Incident assistance at no or pre-agreed cost | The obligation on the provider to assist you at no additional cost, or at a cost determined in advance, when an ICT incident related to the service occurs. |
| (g) | Cooperation with authorities | The obligation on the provider to fully cooperate with your competent authorities and resolution authorities, including persons appointed by them. |
| (h) | Termination rights and notice periods | Termination rights and the related minimum notice periods, in accordance with the expectations of competent authorities and resolution authorities. |
| (i) | Participation in your security training | The conditions for the provider to participate in your ICT security awareness programmes and digital operational resilience training, in accordance with Article 13(6). |
Article 30(3): six further elements where the service supports a critical or important function
These are additional to the nine above, not a replacement for them.
| Art. 30(3) | Element | What it must contain |
|---|---|---|
| (a) | Full service level descriptions with quantitative targets | Full service level descriptions with precise quantitative and qualitative performance targets, so you can monitor effectively and take corrective action without undue delay when the agreed levels are not met. |
| (b) | Notice periods and provider reporting obligations | Notice periods and reporting obligations, including notification of any development that might materially affect the provider's ability to deliver the service in line with agreed service levels. |
| (c) | Contingency plans and security measures | Requirements for the provider to implement and test business contingency plans, and to have ICT security measures, tools and policies giving an appropriate level of security. |
| (d) | TLPT participation | The obligation on the provider to participate and fully cooperate in your threat-led penetration testing under Articles 26 and 27. |
| (e) | Ongoing monitoring rights | The right to monitor performance on an ongoing basis: unrestricted rights of access, inspection and audit by you, by an appointed third party and by the competent authority; the right to take copies of relevant documentation on-site; the right to agree alternative assurance levels where other clients' rights are affected; provider cooperation during on-site inspections; and details of scope, procedures and frequency. Microenterprises may agree to delegate these rights to an independent third party appointed by the provider. |
| (f) | Exit strategies with a mandatory transition period | Exit strategies, in particular a mandatory adequate transition period during which the provider keeps providing the service, allowing you to migrate to another provider or move the service in-house. |
Article 30(4) adds a softer requirement that is worth knowing about: when negotiating, entities and providers “shall consider the use of standard contractual clauses developed by public authorities for specific services”.
Track the clauses per contract, not per programme
The unit of compliance here is the individual contractual arrangement. Fifteen elements, evaluated as present, absent or partial, against each arrangement in scope. That grid is the only thing that tells you the size of your remediation backlog and which contract renewal to prioritise. We are not going to tell you what share of contracts typically fail: we have no published data on that, and neither, as far as we can find, does anybody else.
📌
Build sequence
Building the Register
The register is not a spreadsheet with more columns. It is a relational data model whose shape is set by the 15 official templates in Implementing Regulation (EU) 2024/2956, running from B_01.01 to B_99.01. Build the data model first and the fields will follow. We cover the templates themselves in the guide to the 15 official templates. Here is the sequence to get from nothing to a populated register.
Step 1
Inventory every ICT third-party service arrangement
The register covers “all contractual arrangements on the use of ICT services provided by ICT third-party service providers” (Art. 28(3)), which is broader than the word “outsourcing” suggests. Start from procurement and accounts payable records, software asset inventories and access logs. Two categories are routinely missed: intra-group ICT providers, which the register handles through its own intra-group templates, and free-tier or business-line SaaS bought outside procurement.
Source: Art. 28(3)
Step 2
Decide which functions are critical or important, and record why
Article 3(22) defines it 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”. That determination drives almost everything else: which contracts need the extra Article 30(3) clauses, which arrangements need an exit strategy, and which need the pre-contractual concentration assessment.
Source: Art. 3(22), Art. 28(3)
Step 3
Record the contractual arrangement, clause by clause
Article 30(1) requires the rights and obligations of both parties to be “clearly allocated and set out in writing” in one written document that includes the service level agreements. Then check the contract against the nine elements in Article 30(2), and, if the service supports a critical or important function, the six further elements in Article 30(3). Track each element as present, absent or partial. That per-clause status is the artefact that tells you where your remediation backlog actually is.
Source: Art. 30(1), 30(2), 30(3)
Step 4
Map the subcontracting chain for critical or important functions
Where a provider may subcontract a service supporting a critical or important function, Delegated Regulation (EU) 2025/532 sets out what you must determine before you sign, what the contract must say, and what happens when the chain changes. This is the part with the most new obligation in it, and it has its own section below.
Source: Art. 30(2)(a), 30(5); RTS (EU) 2025/532
Step 5
Run the pre-contractual concentration assessment
Article 29(1) is not an annual reporting exercise. It bites when you are about to sign: as part of the risk identification required by Article 28(4)(c), you must take into account whether the envisaged arrangement would mean contracting a provider that is not easily substitutable, or holding multiple arrangements for critical or important functions with the same provider or with closely connected providers. You must then “weigh the benefits and costs of alternative solutions”.
Source: Art. 28(4)(c), Art. 29(1)
📈
Article 29
Concentration Risk Is a Pre-Contractual Test
Article 29 is titled “Preliminary assessment of ICT concentration risk at entity level”, and the title carries the whole point. It is triggered by Article 28(4)(c), which sits under the heading “Before entering into a contractual arrangement”. This is a gate in your procurement process. It is not something you do once a year with a spreadsheet in December.
Here is what the text tells you to weigh.
Substitutability of the provider
Article 29(1)(a): whether the envisaged arrangement would mean “contracting an ICT third-party service provider that is not easily substitutable”. Substitutability is a field in the register's assessment template, so the conclusion you reach here has to be recorded, not just discussed.
Multiple arrangements with the same or connected providers
Article 29(1)(b): whether you would end up “having in place multiple contractual arrangements in relation to the provision of ICT services supporting critical or important functions with the same ICT third-party service provider or with closely connected ICT third-party service providers”. Note “closely connected”: two contracts with two subsidiaries of the same group are one concentration.
The alternatives you considered
Article 29(1), second subparagraph, requires you to “weigh the benefits and costs of alternative solutions, such as the use of different ICT third-party service providers”, against the business needs and objectives in your digital resilience strategy. The output is a documented comparison, not a conclusion.
Location, third countries and insolvency law
Article 29(2) requires you, for critical or important functions, to consider the insolvency law that would apply if the provider went bankrupt, and any constraint on urgently recovering your data. Where the provider is established in a third country, you must also consider compliance with Union data protection rules and the effective enforcement of law in that country.
Chain length and your ability to monitor
Article 29(2), final subparagraph: where the arrangement provides for subcontracting, you must assess “whether and how potentially long or complex chains of subcontracting may impact their ability to fully monitor the contracted functions and the ability of the competent authority to effectively supervise the financial entity in that respect”.
Concentration inside the chain
RTS (EU) 2025/532, Article 1(j), makes it explicit that the factors you weigh include “whether the provision of ICT services supporting critical or important functions or material parts thereof is concentrated to a single subcontractor of an ICT third-party service provider or a small number of such subcontractors”. Two independent providers resting on the same subcontractor is a single dependency.
What keeps it alive after signature
Article 28(2) puts the ongoing duty on the management body, which “shall regularly review the risks identified in respect to contractual arrangements on the use of ICT services supporting critical or important functions”. And RTS (EU) 2025/532 Article 3(2) requires entities whose providers subcontract critical or important services to carry out the relevant risk assessment “periodically” against changes in the business environment, including ICT threats, ICT concentration risks and geopolitical risks. Neither provision sets a fixed annual cadence, so if you claim one in your policy, it is your commitment, not the regulation's.
🔗
RTS (EU) 2025/532
Subcontracting: Your Provider’s Providers
This is the part of the regime with the most detail and the least awareness. DORA Article 30(2)(a) requires the contract to indicate whether subcontracting of an ICT service supporting a critical or important function, or material parts of it, is permitted, and on what conditions. Article 30(5) then mandated a technical standard to specify what you have to determine and assess. That standard is Delegated Regulation (EU) 2025/532, and it has three moving parts.
1. The decision happens before you sign
Article 3(1) is explicit: a financial entity “shall, before entering into a contractual arrangement with an ICT third-party service provider, decide whether that ICT third-party service provider may subcontract an ICT service that supports critical or important functions or material parts thereof”. You may only enter the arrangement once you have assessed that ten conditions, points (a) to (j), are met. They include that the provider is able to identify all subcontractors supporting critical or important functions and notify you of them; that the subcontractor grants you and the authorities the same access and inspection rights as the provider does; that you have assessed the impact of a subcontractor failure on your resilience and financial soundness; that you have assessed concentration risk under Article 29; and that you have assessed whether there are obstacles to the exercise of audit and inspection rights.
Article 3(3) closes the obvious loophole: relying on the provider’s own assessment of its subcontractors “shall not limit the final responsibility of financial entities to comply with their legal and regulatory obligations”.
2. Twelve things the contract has to specify
Where subcontracting of critical or important services is permitted, Article 4(1) requires the contract to identify which services are eligible for subcontracting and under which conditions, and to specify all of the following.
| Art. 4(1) | The contract must specify |
|---|---|
| (a) | The provider is responsible for the services delivered by its subcontractors. |
| (b) | The provider must monitor all subcontracted ICT services supporting critical or important functions so that its obligations to you are continuously met. |
| (c) | The monitoring and reporting obligations the provider owes you in respect of those subcontractors. |
| (d) | The provider must assess all risks associated with the location of current and potential subcontractors, and of their parent company, and with the location the service is provided from. |
| (e) | The location of data processed or stored by the subcontractor, where relevant. |
| (f) | The provider must specify, in its own contracts with subcontractors, the monitoring and reporting obligations of those subcontractors. |
| (g) | The provider must ensure continuity of the service throughout the chain of subcontractors if a subcontractor fails to meet its obligations. |
| (h) | The provider's contract with its subcontractors must carry the business contingency plan requirements of DORA Art. 30(3)(c) and specify the service levels the subcontractors must meet. |
| (i) | That same contract must specify the ICT security standards and any additional security requirements referred to in DORA Art. 30(3)(c). |
| (j) | The subcontractor must grant you and the competent and resolution authorities the same rights of access, inspection and audit as in DORA Art. 30(3)(e). |
| (k) | The provider must notify you of any material change to subcontracting arrangements. |
| (l) | You have the right to terminate when the conditions in Art. 6 of the RTS or in DORA Art. 28(7) are met. |
3. You get a veto over material changes to the chain
Article 5 is the provision most likely to change how your providers behave. The contract must require the provider to inform you of any intended material change to its subcontracting arrangements “well in time” for you to assess the impact on your risk and on the provider’s ability to meet its obligations. The contract must contain “a reasonable notice period by which the financial entity is to approve or object to the changes”. And then Article 5(3): the provider “shall only implement the material changes to its subcontracting arrangements after the financial entity has either approved or not objected to the changes by the end of the notice period”.
If you conclude the change exceeds your risk tolerance, Article 5(4) requires you to tell the provider and object before the notice period ends. Article 6 then gives you a right to terminate where the provider implemented material changes you objected to, implemented them before the notice period ended without your approval, or subcontracted a critical or important service that the contract did not explicitly permit it to subcontract.
Where the data comes from is the hard part
The obligation runs through the contract. RTS Article 3(1)(b) requires you to have assessed, before signing, that the provider “is able to identify all subcontractors that provide ICT services that support critical or important functions or material parts thereof, to notify and inform the financial entity of those subcontractors”. That is a diligence condition on the provider's capability, and it is your lever. Where an existing contract lacks it, RTS Article 4(2) requires changes made necessary to comply “to be implemented in a timely manner and as soon as it is possible”, with the planned timeline documented. Publicly maintained subprocessor pages from large providers are useful as a cross-check, but they change without notice and they are not a substitute for the contractual notification right.
🚪
Article 28(8)
Exit Strategies: Four Tests
Exit strategies are required for ICT services supporting critical or important functions. The obligation is more specific than “have an exit plan”, and each part of it is testable.
The exit must be possible without three things happening
Article 28(8), second subparagraph, requires entities to be able to exit “without disruption to their business activities”, without “limiting compliance with regulatory requirements”, and without “detriment to the continuity and quality of services provided to clients”. Those are the three tests an exit plan has to pass.
The plan must be tested
Article 28(8), third subparagraph: “Exit plans shall be comprehensive, documented and, in accordance with the criteria set out in Article 4(2), shall be sufficiently tested and reviewed periodically.” An untested exit plan does not meet the article.
Alternatives and transition plans must be identified
Article 28(8), fourth subparagraph, requires you to “identify alternative solutions and develop transition plans enabling them to remove the contracted ICT services and the relevant data from the ICT third-party service provider and to securely and integrally transfer them to alternative providers or reincorporate them in-house”.
The contract must give you a transition period
Article 30(3)(f) requires contracts for critical or important functions to contain exit strategies including “the establishment of a mandatory adequate transition period” during which the provider keeps delivering the service. If your contract has no transition period, your exit plan is resting on the provider's goodwill.
Article 28(8) also requires contingency measures to maintain business continuity in the event of the circumstances that trigger the exit, and it ties the trigger list back to the termination circumstances in Article 28(7): significant breach by the provider, circumstances found through monitoring that could alter performance, evidenced weaknesses in the provider’s ICT risk management, and the situation where the competent authority can no longer effectively supervise you because of the arrangement.
Article 10 of RTS (EU) 2024/1773 covers exit and termination as part of the policy on ICT services supporting critical or important functions, so the exit content of your policy has a specified home too.
⚡
Tooling
Where Venvera Fits
All of this can be run in spreadsheets, and for a handful of providers it often is. What breaks is not the storage, it is the integrity: the register is relational, the reference on a contractual arrangement is a key that several other tables point at, and a spreadsheet has no way to stop those references drifting apart. Venvera covers a range of frameworks; DORA is one of them. These are the third-party capabilities that exist in the product today.
📚
ICT provider and contract register
Providers, contractual arrangements, branches, business functions and risk assessments as linked records. Contracts carry the contract reference, start and end dates, notice periods on both sides, governing law, country of provision, data locations and data sensitivity.
📋
Article 30 clause tracking
Each contractual arrangement carries a per-clause Article 30 status, so a contract missing clauses is visible as a record rather than as a memory. The provider risk score reads that status and marks a provider down where the clause set is incomplete.
📈
Concentration analysis
Spend concentration per provider with a share threshold flag, dependency of critical functions on single versus multiple providers, breakdown by country and by data location, and a Herfindahl-Hirschman index on provider spend with bands.
🔗
Sub-outsourcing chains
Subcontractors recorded against the arrangement they sit under, with the sub-provider's LEI, country, service description, data locations, criticality and the tier level in the chain.
🚪
Exit and substitutability assessments
Provider risk assessments carry substitutability score and reasoning, whether an exit plan exists, reintegration possibility, discontinuation impact, identified alternative providers, and the next review date. Contracts carry an exit strategy reference.
📋
Vendor questionnaire campaigns
Questionnaire campaigns sent to providers against framework-tagged templates, with per-provider status, contacts and scored responses.
📊
xBRL-CSV export of the register
Export in the ITS (EU) 2024/2956 table structure across all 15 official templates, B_01.01 to B_99.01, with a completeness score and validation issues surfaced before you export rather than after the portal rejects the file.
🔔
Audit trail
Changes to records are logged, which is what turns “the register is maintained” from an assertion into something you can show.
What the platform does not do is decide which of your functions are critical or important, or negotiate the Article 30(3) clauses into a contract your provider would rather not reopen. Those are yours. What it does is make sure that once you have made those calls, they are recorded against the arrangement, they survive the year, and they come out in the shape the register expects.
Build the ICT register on the data model the regulation actually uses.
Providers, contracts, functions, subcontracting chains and risk assessments as linked records, with Article 30 clause tracking and an xBRL-CSV export built to the 15 official templates.
Book a demo →Primary sources
- Regulation (EU) 2022/2554 (DORA). Article 3(22), definition of a critical or important function. Chapter V, Articles 28 to 44. Section I: Article 28 general principles and the register, Article 29 preliminary assessment of ICT concentration risk, Article 30 key contractual provisions. Section II, Articles 31 to 44: the oversight framework for critical ICT third-party service providers.
- Commission Implementing Regulation (EU) 2024/2956. ITS setting the standard templates for the register of information, under DORA Article 28(9). Fifteen templates, B_01.01 to B_99.01.
- Commission Delegated Regulation (EU) 2024/1773. RTS on the detailed content of the policy on the use of ICT services supporting critical or important functions, under DORA Article 28(10). Covers governance, the lifecycle phases, ex-ante risk assessment, due diligence, conflicts of interest, contractual clauses, monitoring, and exit and termination.
- Commission Delegated Regulation (EU) 2025/532. RTS on the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions, under DORA Article 30(5).
- Commission Delegated Regulation (EU) 2024/1774. RTS on ICT risk management tools, methods, processes and policies, which is the framework Article 28(1) requires third-party risk to sit inside.
This article is for information only and is not legal or regulatory advice. Article citations were checked against the Official Journal texts on 14 July 2026. Technical standards are amended over time, so confirm the version in force before relying on any requirement stated here.
