Here is the uncomfortable part most teams discover late: your DORA ICT third-party risk register is not a compliance artifact you file once and forget. The moment the European Supervisory Authorities designate one of your providers as critical, that register stops being an internal spreadsheet and becomes the evidence base a Lead Overseer uses to reason about systemic risk. If the mapping between "this provider" and "this critical or important function" is thin, ambiguous, or out of date, you will be reconstructing it under a supervisory clock instead of on your own schedule.

This guide is operator-to-operator. It walks the gaps that surface when oversight actually starts asking questions, and it turns each DORA obligation into a concrete register field, control, or evidence task you can assign this quarter.

What changes for financial entities once the ESAs designate a Critical ICT Third-Party Provider (CTPP)?

Start with what does not change: your substantive obligations under Article 28 apply to every in-scope financial entity regardless of whether any of your providers is designated. The register, the exit strategies, the concentration assessment, the contractual clauses - all of that is on you from day one.

What a CTPP designation adds is a second, Union-level layer of scrutiny sitting on top of your provider. Under Article 31, the ESAs, through the Joint Committee and on a recommendation from the Oversight Forum, designate ICT third-party providers as critical based on criteria including systemic impact, the systemic character of the entities that rely on them, reliance in relation to critical or important functions, and the degree of substitutability. A Lead Overseer is appointed for each one. The designation is notified, the provider gets six weeks to submit a reasoned statement, and oversight effectively starts no later than one month after the final notification. The provider must then notify the financial entities it serves that it has been designated.

The practical consequence for you: your register data is what feeds the designation engine in the first place. Article 28(3) requires you to report at least yearly to your competent authority on new arrangements, provider categories, contract types, and the functions being provided. Article 31(10) has competent authorities transmit those reports to the Oversight Forum, which assesses ICT third-party dependencies across the sector. Weak register data does not just fail an audit - it distorts the sector-wide picture regulators are building.

Which fields must your ICT third-party register capture under Article 28 to survive supervisory scrutiny?

Article 28(3) requires you to maintain and update a register of information covering all contractual arrangements for ICT services, at entity level and at sub-consolidated and consolidated levels, and to appropriately document each arrangement while distinguishing those that support critical or important functions from those that do not. That "distinguishing" verb is the load-bearing one. A register that lists 400 vendors but cannot cleanly separate the ICT-services-supporting-a-critical-function subset is not oversight-ready.

Build your register so every row answers the questions an overseer will ask. At minimum, capture:

  • Provider identity and group structure - who the counterparty is, and where they sit in a group, because Article 31 assesses criticality at group level.
  • The ICT service, and the function it supports - with an explicit critical-or-important flag per arrangement.
  • Contract type and status, plus whether subcontracting of a critical-function service is permitted (an Article 30 contractual element).
  • Locations of provision and data processing/storage - Article 30(2) requires these to be contractually fixed, so mirror them in the register.
  • Concentration signals - is this provider not easily substitutable, and do you hold multiple critical-function arrangements with it or closely connected providers?
  • Exit posture - does a tested exit plan and transition period exist for this arrangement?

The ESAs were mandated under Article 28(9) to develop implementing technical standards establishing standard templates for the register, with information common to all contractual arrangements. Align your field taxonomy to that template shape rather than a homegrown schema, because the yearly report and any ad-hoc supervisory request will be evaluated against it. Article 28(3) also requires you to make the full register, or specified sections, available to your competent authority on request - so treat query-ability, not just storage, as a design requirement.

How do you tell whether a CTPP dependency is 'supporting a critical or important function'?

This is where registers rot. The DORA definition (Article 3, point 22) is precise: a critical or important function is one whose disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services and activities, or whose failed performance would materially impair continuing compliance with the conditions of your authorisation or other obligations under financial services law.

Run the test at the function level first, then trace the ICT services and providers that support it. A workable sequence:

  1. Inventory your functions, not your applications. Payment execution, trade settlement, client onboarding, and regulatory reporting are functions; the SaaS underneath them is not.
  2. Apply the Article 3(22) impairment test to each function: material impact on performance, soundness/continuity, or authorisation compliance. Record the reasoning, not just a yes/no.
  3. Map ICT services to each critical-or-important function, including services reached indirectly through subcontracting - Article 31(2)(c) explicitly counts indirect reliance.
  4. Flag the supporting providers in the register and inherit the critical-or-important status onto those arrangements.
  5. Set a re-test trigger. Article 28(3) obliges you to inform your competent authority when a function becomes critical or important, so the classification is a live signal, not a one-time label.

What breaks: teams classify at the application layer and miss shared platform services. An identity provider or a cloud region that quietly underpins six functions gets logged as one "medium" vendor, so its true criticality - and its concentration weight - never surfaces until an incident or an overseer forces the question. Classify top-down from functions, or the most systemically important dependency in your estate stays invisible.

What oversight-readiness gaps show up when Union oversight actually starts asking questions?

Once a Lead Overseer engages, the assessment under Article 33 is broad. It covers ICT security, availability, continuity and quality; physical security of premises and data centres; risk management processes; governance and accountability lines; incident identification and prompt reporting; data and application portability that enables your termination rights; testing; ICT audits; and use of relevant standards. The overseer builds an annual oversight plan per CTPP and can, under Article 35, request information, run investigations and inspections, request post-oversight action reports, and issue recommendations - including on patching, encryption, and refraining from risky subcontracting.

The recurring gaps that surface:

  • No line of sight from function to provider to control. You can name the provider but not evidence which controls protect the critical function it supports.
  • Portability claimed but never tested. Article 33(3)(f) puts data and application portability squarely in scope precisely because it underwrites your ability to exit.
  • Register drift. The contractual locations, subcontracting permissions, or SLAs in the signed agreement no longer match the register row.
  • No mechanism to absorb overseer recommendations. Under Article 42, competent authorities inform financial entities of risks identified in recommendations to a CTPP, and you are obliged to take those risks into account in your own ICT third-party risk management. If there is no workflow for that inbound signal, you will miss it.

How should you rework exit strategies and concentration-risk limits before a designation lands?

Article 28(8) requires exit strategies for ICT services supporting critical or important functions, and it is specific about the bar: you must be able to exit without disruption to business activities, without limiting regulatory compliance, and without detriment to service continuity or quality for clients. Exit plans must be comprehensive, documented, sufficiently tested, and periodically reviewed, with identified alternative solutions, transition plans to move data and services to another provider or back in-house, and contingency measures. Article 30(3)(f) reinforces this by requiring a contractual mandatory transition period during which the provider keeps delivering while you migrate.

ICT concentration risk is the twin problem. Article 3(29) defines it as dependency on one or multiple related critical providers such that a failure could endanger your ability to deliver critical or important functions. Article 29 tells you to assess, before contracting, whether the arrangement means engaging a provider that is not easily substitutable, or stacking multiple critical-function arrangements on the same or closely connected providers - and to weigh subcontracting chains and third-country exposure.

A pragmatic pre-designation program:

  1. Rank critical-function providers by substitutability, using the Article 31(2)(d) lens - lack of real alternatives, migration cost, technical lock-in.
  2. Set internal concentration thresholds per provider and per closely-connected group, and record breaches as risks, not footnotes.
  3. Test the top exit plan end-to-end, at least tabletop, and capture the transition-period assumptions from the contract.
  4. Close contractual gaps against Article 30(3) - quantitative SLAs, cooperation with the Lead Overseer, unrestricted access/inspection/audit rights, and TLPT participation.

Our third-party risk management and risk register tooling is built to hold these links - provider, function, concentration weight, and exit posture - as one connected model rather than four disconnected spreadsheets.

What evidence and reporting workflow proves continuous oversight rather than a point-in-time attestation?

Supervisors are not looking for a signed attestation from last January. Article 33 frames oversight as continuous, and Article 42 wires financial entities into an ongoing loop: a CTPP has 60 calendar days to tell the Lead Overseer whether it will follow a recommendation, competent authorities relay identified risks to you, and as a last resort they can require you to suspend or even terminate use of a CTPP service. Your evidence has to prove the loop is running.

A workflow that holds up:

  1. Version the register. Every field change is timestamped and attributable, so drift is visible and explainable.
  2. Bind evidence to each critical-function arrangement - the SLA, the tested exit plan, the last audit, the concentration assessment - so a section request under Article 28(3) is a query, not a scramble.
  3. Ingest overseer recommendations as tracked risks the moment a competent authority relays them under Article 42(3), with owners and due dates.
  4. Regenerate the yearly Article 28(3) report from the same source of record, not a hand-built deck, so what you file matches what you operate.
  5. Re-run the critical-or-important classification on triggers - new contract, material change, or a function crossing the impairment threshold.

This is exactly the posture Aegis GRC is designed for. Because every obligation is source-grounded to the legal text, your DORA controls trace back to the specific article - Article 28 for the register, Article 29 for concentration, Article 30 for contracts - with no AI hallucinations in the mapping. Answer once. Assess everything. And when the section request lands, the audit pack is a query, not a project. Map your ICT third-party register to DORA oversight expectations with Aegis GRC - see how at DORA compliance or start at agrc.ai.

FAQ: CTPP designation, register scope, and entity obligations

Do I have to wait for a CTPP designation before building the Article 28 register? No. The register, exit strategies, concentration assessment, and contractual provisions under Articles 28 to 30 apply to in-scope financial entities independently of any designation. Designation adds Union oversight of the provider; it does not create your register duty. Build it now, because oversight can start roughly one month after final notification under Article 31.

Does a CTPP designation transfer compliance responsibility to the provider? No. Article 28(1) is explicit that a financial entity using ICT services remains fully responsible for compliance with all obligations under DORA and applicable financial services law. The Oversight Framework does not offload your accountability onto the provider.

What is the difference between the register scope and the critical-or-important subset? The Article 28(3) register covers all ICT-service contractual arrangements. Within it, you must distinguish the arrangements that support critical or important functions, because the heavier duties - full SLAs, exit strategies, enhanced monitoring rights under Article 30(3) - attach to that subset. Get the subset flag wrong and you either over-invest everywhere or under-protect the arrangements that matter.

What can happen to me if a CTPP ignores an overseer recommendation? Under Article 42, competent authorities inform you of the risks identified, and you must take them into account in your ICT third-party risk management. As a last resort they can require you to temporarily suspend or terminate use of the provider's service until the risk is addressed - which is precisely why a tested exit strategy and transition plan is not optional.