DORA third-party risk management

DORA third-party risk management, article by article.

DORA third-party risk management is the fourth of the regulation’s five pillars, and the one that reaches furthest outside the firm. It obliges every in-scope financial entity to maintain a register of information covering all ICT contractual arrangements, to run due diligence before contracting, to carry specified provisions in those contracts, to assess concentration risk, and to hold tested exit strategies for anything supporting a critical or important function. This page sets out each of those obligations, what the register has to contain, how Article 30’s two tiers of contract terms differ, and what changes when a provider is designated critical.

Last reviewed 24 August 2026 by Darren Craig

What DORA requires on third-party risk

Regulation (EU) 2022/2554, applying since 17 January 2025. The third-party pillar sits in Chapter V.

DORA’s premise is that a financial firm’s operational resilience is inseparable from the resilience of the technology providers behind it. So where earlier outsourcing regimes asked firms to manage their suppliers sensibly, DORA specifies what managing them consists of — and then, uniquely, reaches past the regulated firm to supervise designated providers directly.

Two definitions do most of the work, and getting them wrong is the most expensive early mistake in a DORA programme.

ICT services is drawn broadly: digital and data services provided through ICT systems on an ongoing basis, including hardware as a service and hardware support. It is materially wider than the outsourcing arrangements most firms had registered under previous regimes, which is why register populations routinely came in several times larger than expected.
Critical or important function — a function whose disruption would materially impair financial performance, or the soundness or continuity of services and activities, or whose discontinued or failed performance would materially impair continued compliance with authorisation conditions and obligations. Almost every heightened obligation in the pillar keys off this judgement, so it needs to be documented reasoning rather than a column in a spreadsheet.

Note what DORA does not do: it does not prohibit outsourcing, it does not require providers to be EU-established, and it does not set a maximum concentration. It requires the firm to know, to document, to have assessed, and to be able to leave.

The seven obligations in plain terms

Article 28 sets the general principles, Articles 29 and 30 the concentration and contractual detail. Together they come to seven things a firm has to be able to demonstrate.

Manage ICT third-party risk as part of your ICT risk framework
Article 28(1)–(2). It is not a separate procurement exercise running alongside risk management. There must be a strategy on ICT third-party risk, reviewed regularly, with a documented policy covering arrangements that support critical or important functions, and the management body remains fully responsible for the firm’s ICT risk regardless of what has been contracted out.
Maintain a register of information on all ICT arrangements
Article 28(3). Every contractual arrangement for ICT services, not only those supporting critical or important functions, maintained at entity, sub-consolidated and consolidated level, and provided to the competent authority on request.
Report annually, and notify planned critical arrangements
Article 28(3). At least yearly, report to the competent authority on new arrangements, the categories of provider, the types of arrangement and the services and functions covered. Separately, inform the authority in a timely manner of any planned arrangement for ICT services supporting a critical or important function — and when a function that was already contracted out becomes critical or important.
Run due diligence before you sign
Article 28(4). Assess whether the provider is suitable, including whether it applies appropriate information security standards, before entering the arrangement. For arrangements supporting critical or important functions, take account of the provider’s use of subcontractors and whether it is established in a third country. Diligence performed after signature does not satisfy this.
Carry the specified contractual provisions
Article 30. Two tiers: a set required in every ICT contract, and a longer set required additionally where the arrangement supports a critical or important function. Set out in the comparison below.
Assess concentration risk before contracting, not after
Article 29. A preliminary assessment of ICT concentration risk, explicitly covering arrangements with providers that are not easily substitutable or where multiple arrangements exist with the same provider or closely connected providers — and the risks arising from subcontracting chains, including where subcontractors are established outside the EU.
Hold exit strategies for critical or important functions
Article 28(7). Documented and tested, covering provider failure, deterioration in quality, business disruption and regulatory concerns — with a transition that does not disrupt the business or breach regulatory requirements. An exit plan nobody has rehearsed is the finding examiners report most often on this article.

The register of information field by field

The register is the pillar’s single most demanding deliverable, and the reason is not conceptual — it is that most of these fields did not exist in anybody’s supplier records before 2024.

Area	What is captured	Where firms struggle
The entity and its group	The reporting entity, its identifiers, and the level at which the register is maintained — entity, sub-consolidated, consolidated	Getting consistent submissions out of subsidiaries that maintain their own supplier records in different systems
Contractual arrangements	Every ICT contract: reference, start and end dates, notice periods, governing law, annual cost, and whether it supports a critical or important function	Annual cost by arrangement rather than by supplier, and notice periods that live only in the signed PDF
Providers, identified formally	Legal name and, critically, a legal entity identifier — not a trading name typed by whoever raised the purchase order	Obtaining an LEI for smaller providers that have never needed one, and reconciling group structures
ICT services supplied	The service type against the defined taxonomy, and the functions it supports	Mapping free-text service descriptions onto a fixed taxonomy across hundreds of arrangements
Functions and their criticality	The firm’s functions, whether each is critical or important, and the reasoning and date behind that assessment	Criticality asserted rather than reasoned, which does not survive a follow-up question
The subcontracting chain	For arrangements supporting critical or important functions, the chain of subcontractors supplying that service	Suppliers who will not disclose their own suppliers, where the contract gave you no right to ask
Substitutability and exit	How substitutable the provider is, whether an exit plan exists, and where reintegration or an alternative would go	Substitutability recorded as an opinion with no analysis behind it

Registers are collected annually by competent authorities and passed to the ESAs, with the first full collection having run in 2025. The template and validation rules sit in implementing technical standards and have been revised — confirm the current version before a submission rather than relying on last year’s mapping.

Article 30: the two tiers of contract terms

Every ICT contract needs the left-hand set. Anything supporting a critical or important function needs the right-hand set as well — and this is the distinction that determines how much of your contract estate has to be reopened.

Article 30(2)

Required in every ICT arrangement

A clear, complete description of all functions and ICT services provided
The locations where services are provided and where data is processed and stored, with notice if they change
Provisions on availability, authenticity, integrity and confidentiality of data, including personal data
Access, recovery and return of data in an easily accessible format on insolvency, resolution or discontinuation
Service level descriptions, kept updated
An obligation to assist at no additional cost, or at a pre-determined cost, when an ICT incident related to the service occurs
An obligation to cooperate fully with the firm’s competent and resolution authorities
Termination rights and minimum notice periods, as expected by the authorities
Conditions for participating in the firm’s security awareness and operational resilience training

Article 30(3)

Additionally, for critical or important functions

Full service level descriptions with precise quantitative and qualitative performance targets
Notice periods and reporting obligations, including notification of developments that may materially affect the provider’s ability to deliver
A requirement to implement and test business contingency plans, and to maintain appropriate security measures, tools and procedures
Participation and full cooperation in the firm’s threat-led penetration testing
Unrestricted rights of access, inspection and audit — by the firm, an appointed third party, or the competent authority
An obligation to cooperate fully during on-site inspections and audits
Exit strategies, with a mandatory adequate transition period during which the provider continues to supply the service

When the provider itself is supervised

The genuinely novel part: the regulator reaches past you, to your supplier.

Articles 31 onwards establish an oversight framework for critical ICT third-party service providers. The European Supervisory Authorities — EBA, EIOPA and ESMA, acting through their Joint Committee — designate providers as critical on criteria including the systemic impact of a failure, the systemic importance of the entities relying on them, the degree of substitutability and the reach across the sector. A provider may also apply to be designated voluntarily.

Each designated provider is assigned a Lead Overseer, which can request information, conduct general investigations and on-site inspections, issue recommendations, and — where a provider does not comply — impose periodic penalty payments of 1% of average daily worldwide turnover from the preceding business year, charged for each day of non-compliance for up to six months under Article 35(8).

That 1% figure is the most frequently misquoted number in DORA coverage. It is a daily measure applied to designated providers, not an annual fine on financial entities. Penalties for financial entities are left to member states under Article 50, so they are set nationally rather than by a single EU-wide figure.

What this means practically for a firm is narrower than the attention it receives. Designation does not transfer your obligations to the provider: you still register the arrangement, still hold the contract terms, still assess concentration, still need an exit. What changes is that the Lead Overseer’s findings become information you are expected to act on — and that competent authorities may require financial entities to suspend or terminate arrangements with a designated provider that does not remedy serious recommendations.

Where the third-party pillar meets incident reporting

The statutory windows are measured in hours, and most of the information you need sits with somebody else.

Article 19 requires major ICT-related incidents to be reported to the competent authority on a staged basis — an initial notification, an intermediate report as the picture firms up, and a final report with root cause. The windows are short, and they run from the firm’s awareness and classification of the incident, not from the provider getting round to telling you.

An incident originating at a supplier is still your reportable incident if it affects a critical or important function. So the deadlines are only achievable if the contractual obligations in Article 30 have been drafted to serve them: notification of developments that materially affect delivery, cooperation and assistance during an incident at no additional or a pre-agreed cost, and a named route to reach somebody technical out of hours. A contract that promises cooperation without a deadline is the clause that fails on the night.

This is the practical case for continuous monitoring of supplier posture rather than annual assurance. Material change detected the day it happens leaves the notification window open; the same change discovered at the next scheduled review does not.

Closing the gap, in sequence

For firms whose register exists but does not yet hold up, which is most of them.

Reconcile the arrangement population against accounts payable
The broad definition of ICT services means the register is almost always under-populated on first pass. Reconciling against payables finds the arrangements nobody classified as technology — data feeds, hardware support, managed print.
Document the criticality reasoning, not just the flag
Every heightened obligation keys off critical-or-important. Write the reasoning and date it, because the follow-up question is always why, and an undocumented judgement made two years ago cannot be defended by whoever inherits it.
Fix identifiers before fixing anything else
Legal entity identifiers and correct legal names are the fields that fail validation and block a submission. They are also slow to obtain from smaller providers, so they belong at the front of the queue rather than the end.
Triage contracts against Article 30(3), critical tier first
Audit and access rights, subcontracting disclosure and the transition period are the three clauses most often absent from pre-2024 contracts, and all three need a renewal conversation rather than an amendment letter.
Get the subcontracting chain into the register
For critical or important functions this is required, and it is the field firms are least able to populate — because the right to ask was never contracted for. Where you have it, use it; where you do not, it is a renewal item. Fourth-party discovery fills part of the gap from the outside.
Assess concentration across the portfolio, not per contract
Article 29 is a portfolio question: several arrangements with one provider, several providers resolving to one underlying platform, and substitutability across the set. It cannot be answered from inside a single contract review.
Test one exit plan properly
Not all of them — one, on a genuinely critical arrangement, end to end. The rehearsal reliably finds the dependency the written plan omitted, and one tested plan is better evidence than twelve untested ones.
Move supplier assurance from annual to continuous
The register describes the arrangement. It does not tell you what changed at the provider last week, which is the question Articles 19 and 28 both assume you can answer.

DORA, NIS2 and the UK position

Three regimes, regularly conflated, with different reach.

DORA is an EU regulation for the financial sector. Being a regulation rather than a directive, it applies directly and does not vary between member states. It is prescriptive about third-party risk in a way almost nothing else is.

NIS2 is an EU directive covering a much broader set of essential and important entities across sectors, transposed into national law and therefore varying between member states. Its supply chain obligation, in Article 21, is a management duty stated at a far higher level than DORA’s. Where both apply, DORA takes precedence for the financial entities and ICT risks it covers as the more specific regime. See NIS2 explained.

The UK did not transpose either. UK firms most often meet DORA in one of two ways: a UK group with an EU-authorised entity is in scope through that entity, or — far more commonly — a UK technology provider is asked to accept Article 30 contract terms and supply register fields by its EU financial customers. The second is a commercial obligation rather than a regulatory one, and it arrives without warning through a contract renewal. Separately, the UK’s own critical third parties regime gives the Bank of England, PRA and FCA direct oversight of providers designated as critical to the UK financial sector — a similar idea, on a separate statutory footing.

The register is not the obligation

Article 28(3) gets treated as though it were the whole pillar. It is the most visible part, because it has a template and a deadline — so programmes optimise for a clean submission and leave concentration risk unassessed, exit plans untested and Article 30(3) terms missing from live contracts. A validated register describing arrangements you cannot leave, whose concentration you have not analysed, is a compliant description of an unmanaged risk. Supervisors have been explicit that they are reading the register as a starting point for questions, not as the answer.

FAQ

DORA third-party questions.

What does DORA require for third-party risk management?

A register of information covering all ICT contractual arrangements, maintained at entity, sub-consolidated and consolidated level; pre-contractual due diligence; specified contractual provisions under Article 30, with an additional set where the arrangement supports a critical or important function; a preliminary assessment of ICT concentration risk; documented and tested exit strategies for critical or important functions; and annual reporting to the competent authority alongside timely notification of planned critical arrangements.

What is the DORA register of information?

A structured record of every ICT contractual arrangement, required by Article 28(3). It captures the arrangement, the provider as a formally identified legal entity, the ICT services supplied, the functions they support and whether those are critical or important, the subcontracting chain where a critical or important function is involved, and substitutability and exit information. It is collected annually by competent authorities and passed to the European Supervisory Authorities.

Which contracts need the extra Article 30(3) terms?

Those supporting a critical or important function. The additional set covers precise performance targets, notification of developments materially affecting delivery, contingency planning and testing, participation in threat-led penetration testing, unrestricted access, inspection and audit rights, cooperation with on-site inspections, and exit strategies with a mandatory adequate transition period.

Does DORA apply to UK companies?

Not directly — the UK did not transpose it. A UK group with an EU-authorised financial entity is in scope through that entity. Much more commonly, UK technology suppliers meet DORA through their EU financial customers, who must pass Article 30 terms and register requirements down the contract. That is a commercial obligation rather than a regulatory one, and it usually arrives at renewal.

What counts as a critical or important function under DORA?

A function whose disruption would materially impair the firm’s financial performance, or the soundness or continuity of its services and activities, or whose failure would materially impair continued compliance with its authorisation conditions and regulatory obligations. Nearly every heightened obligation in the third-party pillar depends on this judgement, so the reasoning behind it should be written down and dated rather than recorded as a flag.

What are the penalties under DORA?

They differ by population. For financial entities, administrative penalties are set nationally by member states under Article 50, and competent authorities can also require conduct to cease and order remedial action. For critical ICT third-party service providers, the Lead Overseer may impose periodic penalty payments of 1% of average daily worldwide turnover from the preceding business year, for each day of non-compliance for up to six months, under Article 35(8). The widely repeated “1% of annual turnover” merges the two.

How does DORA differ from NIS2 on supply chain?

DORA is a regulation applying directly to EU financial entities and is highly prescriptive — named articles, a register template, mandatory contract clauses. NIS2 is a directive covering a much wider set of sectors, transposed nationally and therefore variable, and its Article 21 supply chain duty is stated at a far higher level. Where both could apply, DORA takes precedence for the financial entities and ICT risks it covers.

Keep reading

A register that is current on the day they ask for it.

Book a 30-minute call and we will show the Article 28 register composed from live vendor data, with the concentration and substitutability analysis already attached.

Book a 30-min demo →See DORA compliance