DORA Third-Party Risk: The ICT Provider Regime Deep-Dive

TL;DR — DORA's third-party regime is where most in-scope firms have the largest gap. This deep dive walks through who counts as an ICT third-party service provider, what changes when a provider is designated a Critical ICT Third-Party Provider (CTPP), the mandatory Article 30 contract content, the Register of Information, exit strategies, and the Lead Overseer's oversight framework as it stands in 2026.

Table of contents

• Why the third-party pillar is the hard one
• Who is an ICT third-party service provider
• The Register of Information
• Article 30 contractual content
• Critical ICT Third-Party Providers and the oversight framework
• Exit strategies and concentration risk
• Sub-outsourcing and the chain
• Three supervisory signals from 2025–2026
• A 10-item readiness checklist
• How leading firms automate this with Sedric
• FAQ

Why the third-party pillar is the hard one

The first three DORA pillars are mostly things a firm controls internally: the framework, the incident process, the testing programme. The fourth pillar — the third-party ICT risk regime in Articles 28 to 44 of Regulation (EU) 2022/2554 — is the one where compliance, procurement, IT and the business have to agree on a single picture of reality, then keep it current.

A year and a half into application, the consistent message from NCAs is that this is where evidence is thinnest. The Register of Information has caused real pain. Article 30 contractual updates are unfinished. Exit strategies often exist on paper but have never been tested. Concentration risk is acknowledged at portfolio level but not quantified at the function level. And the first Critical ICT Third-Party Provider (CTPP) designations have started the formal oversight engagement that everyone knew was coming.

This piece is for the Head of Compliance, DPO and CISO who together own the third-party programme. We go through the regime end-to-end, with the operational detail that matters for 2026.

Who is an ICT third-party service provider

Article 3(19) defines an "ICT third-party service provider" as "an undertaking providing ICT services". Article 3(21) defines "ICT services" expansively: "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis", including hardware as a service and including services provided by hardware suppliers via firmware updates. Intra-group arrangements are in scope.

In practice this catches a wider set than legacy outsourcing registers expected:

• SaaS providers — from core banking platforms to point-solution KYC and complaints tooling.
• IaaS and PaaS providers — the hyperscalers and specialist cloud providers.
• Connectivity and managed network providers.
• Managed security services and SOC providers.
• Data providers where the data is delivered via ICT systems on an ongoing basis (market data, sanctions data).
• Software vendors where firmware or software updates are delivered on an ongoing basis.
• Internal ICT service provision from another group entity.

What is not an ICT third-party arrangement for DORA purposes: pure consultancy with no ongoing service, one-off licence purchases with no ongoing service component, and arrangements that fall under the EBA Guidelines on Outsourcing but are not ICT in nature (e.g., a third-party operating a physical mailroom).

Article 28(7) requires firms to assess and document, before entering an arrangement, whether the function the third party will support is "critical or important". This is the gating decision that drives nearly every other obligation downstream. Get this classification consistent with the ICT risk register and the business continuity plan; supervisors will reconcile.

The Register of Information

Article 28(3) requires firms to maintain a register of all contractual arrangements on the use of ICT services. The ITS in Commission Implementing Regulation (EU) 2024/2956 sets the standardised template that NCAs collect. The first cycle was submitted in April 2025; the 2026 cycle followed in April this year.

Structure

The Register is organised as a set of related tables:

• Entity-level information — the firm itself, its parent, group structure and consolidation perimeter.
• Contractual arrangements — each contract, with a unique identifier.
• ICT services — each service provided under a contract, with a service-type code from the ITS.
• Function-level information — each business function the service supports, with the firm's function identifier.
• ICT third-party service providers — with LEI where available.
• Sub-contractors — the chain that actually delivers the service.

The data-quality killer fields

Three field families are responsible for most of the data-quality issues we have seen:

• Legal Entity Identifiers (LEIs). Many smaller providers do not have one. Where a provider does not have an LEI, the ITS defines fallback identifiers; firms that did not check this field in advance had to chase suppliers for codes mid-submission.
• Service-type codes. The ITS supplies a controlled vocabulary. Procurement free-text descriptions do not map cleanly; align early.
• Function identifiers. Must reconcile to the firm's own function taxonomy used in the ICT risk register and the BCP.

Submission cycle

The Register is submitted to the NCA at the frequency the NCA prescribes — annually in the first cycle. The ESAs aggregate the data to inform the CTPP designation exercise. The data is also used in thematic reviews and in walk-throughs at firm level.

The Register is not a one-off exercise. It is a living dataset. Build the data pipeline so it is current on the last working day of the quarter, not reconstructed at submission time.

Article 30 contractual content

Article 30 sets the minimum contractual content. The detail differs depending on whether the function being supported is "critical or important" or not. Article 30(2) lists the baseline content for every ICT third-party arrangement; Article 30(3) lists the additional content required for arrangements supporting critical or important functions.

Baseline (Article 30(2))

Every ICT arrangement must address:

• A clear description of the services provided.
• Locations where the services are provided and where data is processed and stored.
• Provisions on availability, authenticity, integrity and confidentiality of data.
• Provisions on access, recovery and return of data on insolvency, resolution or discontinuation.
• Service-level descriptions, including updates and revisions.
• The obligation on the provider to provide assistance at no additional cost (or at a pre-defined cost) in case of an ICT-related incident.
• The provider's cooperation with competent authorities and resolution authorities.
• Termination rights and notice periods.
• Conditions for the participation of the provider in the firm's ICT security awareness programmes and operational resilience training.

Critical-or-important (Article 30(3))

Additional content includes:

• Full service-level descriptions with precise quantitative and qualitative performance targets.
• Notice periods and reporting obligations for changes that may materially affect performance.
• The provider's obligation to implement and test BCPs and to have ICT security measures.
• The right of access, inspection and audit (including unrestricted inspection) for the firm, its appointed third parties and competent authorities.
• Termination rights triggered by specific events (regulatory breaches, material change, defects in supervisory oversight).
• Exit strategies, including a mandatory adequate transition period.
• Participation in TLPT where appropriate.

Where contracts typically fall short

Legacy contracts that pre-date DORA almost always need at least an addendum. Common gaps:

• Audit rights are limited to the firm only (not extended to NCAs and appointed third parties).
• Sub-outsourcing is permitted without the firm's prior approval for the critical chain.
• Data location is "EEA" with no further detail and no change-notification.
• Exit assistance is silent or limited to hand-back of data, with no transition period.
• TLPT participation is not addressed.

Pragmatic approach: priority-stack the providers by criticality and concentration, address the top tier with bilateral redlining, and use a standard addendum template for the long tail.

Critical ICT Third-Party Providers and the oversight framework

Article 31 introduces the Critical ICT Third-Party Provider (CTPP) designation. The ESAs, acting through the Joint Committee, designate CTPPs based on criteria in Article 31(2) — systemic impact, criticality of the financial entities relying on them, substitutability, and inter-relationships. The criteria are spelled out in Commission Delegated Regulation (EU) 2024/1502.

Once designated, a CTPP becomes subject to the Oversight Framework in Articles 32 to 44, led by a Lead Overseer (one of the ESAs) appointed for each CTPP.

What the Lead Overseer can do

The Lead Overseer has powers to:

• Request information (Article 37).
• Conduct general investigations (Article 38) and on-site inspections (Article 39).
• Issue recommendations on specific risks identified at the CTPP (Article 35).
• Impose periodic penalty payments (Article 35(6)) where a CTPP fails to comply with information requests or inspections.

The first designations were published in 2025. The Lead Overseers have begun the cycle of joint examination teams, information requests and the first recommendations.

What changes for the financial entity

Designation of one of your providers as a CTPP is not in itself a problem — it confirms what you probably already knew. But Article 28(9) requires the firm to be aware of, and factor into its risk assessment, the consequences of using a designated CTPP, including:

• Heightened concentration risk at the system level.
• The possibility that the Lead Overseer's recommendations could constrain how the CTPP serves the firm.
• The Article 42 mechanism by which an NCA can require the firm to suspend, in full or in part, the use of a CTPP that has not adequately addressed Lead Overseer recommendations.

In practice, firms relying on a designated CTPP should:

• Review the CTPP's public statement on Lead Overseer engagement.
• Update the concentration-risk assessment.
• Tighten the exit strategy and test it.
• Run a focused thematic review on the contractual posture, particularly audit and information rights.

Exit strategies and concentration risk

Article 28(8) requires documented exit strategies for arrangements supporting critical or important functions. The exit strategy must consider:

• Risks at provider level (failure, insolvency, deterioration in service).
• Risks at sector level (concentration, contagion).
• Risks at firm level (continuity of critical functions during transition).

A workable exit strategy is more than a clause in a contract. It is a documented plan that:

• Names the target alternative provider, or a documented "in-house" fallback.
• Quantifies the time and cost to transition.
• Identifies the data, configuration and integration artefacts that must be portable.
• States the trigger conditions for invoking the exit.
• Has been tested at least at the tabletop level, with results captured.

Concentration risk under Article 29

Article 29 requires assessment of ICT concentration risk before entering into an arrangement supporting a critical or important function. The assessment covers:

• Provider-level concentration (how much of the firm's critical estate sits with one provider).
• Geographic concentration (data and service locations).
• Sub-contractor concentration (the chain).
• Sectoral concentration (use of designated CTPPs).

Concentration risk is not just a regulatory line item. It is a fact about your operational continuity that you would want to know even if DORA did not exist.

Sub-outsourcing and the chain

Article 30(2)(a) and Article 30(3)(g) put serious weight on sub-outsourcing. The financial entity must:

• Know who is in the chain (this is what the Register's sub-contractor table is for).
• Have the right to object to or approve material changes in the chain for critical/important arrangements.
• Ensure the chain is bound to equivalent obligations (especially audit, data protection, and incident reporting).

The 2025 RTS on sub-outsourcing (the dedicated RTS specifying the elements a financial entity must determine and assess when sub-outsourcing ICT services supporting critical or important functions) makes the expectations specific. In practice, this is where the original-vendor contract has the most catching-up to do. Firms that left sub-outsourcing language at "with the firm's consent (not to be unreasonably withheld)" are reopening those clauses.

Three supervisory signals from 2025–2026

• Register of Information return-rate. A continental NCA returned roughly a fifth of first-cycle submissions with data-quality errors and a six-week remediation window. The most common error was function-identifier inconsistency between the Register and the ICT risk register.
• Article 30 contract review. A skilled-person-style review at a mid-sized investment firm flagged that 60% of its ICT third-party arrangements supporting critical functions were missing one or more Article 30(3) elements, most often the audit and inspection rights.
• Concentration risk in cloud. Joint committee statements through 2025 underlined the regulators' attention to cloud concentration. Several firms have been asked to produce written assessments of how they would absorb a regional outage at a hyperscaler — including the timing assumptions.

These are the same issues that show up in adjacent regimes — see smarsh-alternatives for the comparable contractual-coverage problem on the recording side.

A 10-item readiness checklist

1. Definition of "ICT third-party service provider" applied consistently across procurement, IT and compliance.
2. Pre-contract assessment under Article 28(4)-(6) documented for every new arrangement.
3. Criticality classification reconciled to the ICT risk register and the BCP.
4. Register of Information complete, accurate, and aligned to the ITS data model.
5. Article 30(2) baseline content present in all ICT third-party contracts.
6. Article 30(3) additional content present in all arrangements supporting critical/important functions.
7. Sub-outsourcing language consistent with the RTS expectations.
8. Concentration-risk assessment at firm and group level, with quantification at the function level.
9. Exit strategies documented and at least tabletop-tested for critical/important arrangements.
10. Internal posture for designated CTPPs reviewed and updated.

How leading firms automate this with Sedric

The third-party pillar is a data problem dressed as a compliance problem. The Register of Information, the contractual posture, the criticality reconciliation, the concentration view — they all need the same underlying data to be consistent across systems that were never designed to talk to each other.

Sedric's compliance-dedicated LLM works as a connective layer: it reads contract text, procurement records, the firm's framework documents and the relevant DORA articles, and produces a reconciled, continuously updated view. When a contract is renewed, Sedric flags missing Article 30 elements and ties each gap to the specific clause of the regulation. When the Register of Information is being prepared, the platform identifies entries with mismatched function identifiers or absent LEIs before submission. Every flag is linked to underlying regulation; every override is logged with the reviewer's reasoning.

Firms moving from spreadsheet-driven third-party programmes to continuous monitoring have used Sedric to compress the year-end reconciliation cycle and absorb the higher cadence the regime now requires.

FAQ

What is the difference between the ICT risk register and the Register of Information?

The ICT risk register (Article 8) is the firm's internal asset and risk inventory. The Register of Information (Article 28(3)) is the third-party arrangements inventory. They share keys but are distinct artefacts. The ICT risk register template covers the internal side.

Who designates a CTPP?

The ESAs, acting through the Joint Committee, on the basis of the criteria in Article 31(2) and Commission Delegated Regulation (EU) 2024/1502.

Are intra-group ICT arrangements in scope?

Yes. Article 3(19) covers undertakings within a group. The proportionality of the contractual content can be assessed, but the obligations apply.

Does DORA replace the EBA Guidelines on Outsourcing for ICT?

DORA is lex specialis for ICT. The EBA Guidelines on Outsourcing continue to apply to non-ICT outsourcing. The two should be read together; the EBA has updated its guidance to reflect this.

What happens if our provider becomes a CTPP?

You do not need to terminate. You do need to update your concentration-risk assessment, review the contractual posture against the Lead Overseer's emerging expectations, and tighten the exit strategy.

How often must the Register of Information be submitted?

At the frequency the NCA specifies — annually in the first cycle for most firms. Material changes between cycles are typically reported in the next cycle, but check the NCA's local guidance.

Do MiCA-authorised CASPs have the same obligations?

Yes. CASPs authorised under MiCA are in DORA scope (Article 2) and have the same third-party regime. Pair this with the MiCA authorisation checklist.

Where to go next

If you have not yet pressure-tested the wider programme, the DORA implementation checklist is the place to start. For the internal asset side, the DORA ICT risk register template is the companion piece. CASPs reading this should also read the MiCA authorisation checklist. For the comparable contractual-coverage discipline on communications platforms, see Smarsh alternatives.

Closing CTA

If you want a clear view of where your DORA third-party programme exposes you — Register of Information data quality, Article 30 coverage, exit-strategy maturity and CTPP posture — book a 30-minute Sedric demo. We will walk through the live tooling on a representative dataset and show how compliance-dedicated AI turns the third-party regime from a year-end reconciliation into continuous evidence.