DORA ICT Third-Party Register: Complete Guide to Article 28 Reporting

·16 min read
FR

FinancialRegulations.EU Team

Regulatory Intelligence

DORA
ICT-third-party
operational-resilience
compliance

Article 28(3) of DORA (Regulation (EU) 2022/2554) requires every in-scope financial entity to maintain a register of information on all ICT third-party service provider (ICT TPP) arrangements. This register is not just an internal management tool — it is a supervisory document. Your National Competent Authority (NCA) can request it at any time, and the European Supervisory Authorities (EBA, ESMA, EIOPA) use aggregated register data to designate Critical ICT Third-Party Providers (CTPPs), which are then subject to direct EU-level oversight.

This guide covers what the register must contain, the specific format required by the implementing regulation, how to submit it to your NCA, and common mistakes that cause firms to be non-compliant.


Why the Register Matters

The DORA register of information serves three purposes:

  1. Internal governance — Forces financial entities to map every ICT dependency, including sub-outsourcing chains. You cannot manage ICT concentration risk you haven't documented.

  2. Supervisory oversight — NCAs use the register to understand each entity's ICT dependency profile. A register that is incomplete or inaccurate is a regulatory finding.

  3. CTPP designation — The ESAs aggregate register data across all financial entities. If a single ICT TPP appears as a critical dependency for a large enough share of the financial sector, the ESAs can designate it as a CTPP and subject it to direct oversight. Accurate reporting feeds this systemic risk analysis directly.


The Legal Framework

Article 28(3) DORA requires that financial entities maintain the register and update it at least annually and after each material change.

Commission Implementing Regulation (EU) 2024/2956 (the "ITS on register of information") specifies:

  • Five mandatory templates (RT.01 through RT.05)
  • Data field definitions and permitted values for each field
  • The format in which the register must be submitted to NCAs (XBRL/CSV/Excel)
  • The reporting reference dates

The ITS was published in the Official Journal on 4 December 2024 and applies from 14 December 2024.


The Five Templates

The register of information comprises five interconnected templates. They must be completed as an integrated data set — the fields cross-reference each other.

RT.01 — Entity Register

Purpose: Identifies your organisation and the group structure for reporting purposes.

Key fields:

  • LEI of the reporting entity
  • Legal name and registered address
  • NCA identifier
  • Type of financial entity (bank, investment firm, fund manager, payment institution, etc.) using the EBA/ESMA/EIOPA classification
  • If part of a group: consolidated entity identifier, consolidating entity LEI
  • Reporting reference date

Note: If you are part of a financial group, one entity may submit the register on behalf of the group, but each entity's data must be separately identified within the submission.


RT.02 — Function Register

Purpose: Lists all business functions that rely on ICT services provided by third parties. The unit of analysis here is the function, not the vendor.

Key fields:

| Field | Description | |-------|-------------| | Function identifier | Internal reference used across all templates | | Function name | Plain-language description (e.g., "Core banking system", "Payment processing", "Trade execution") | | Critical/important function (CIF) flag | Yes/No — is this a critical or important function? This is the most consequential field in the template (see below) | | Substitutability assessment | How easily could this function be replaced if the ICT TPP fails? (Scale: easily substitutable / substitutable with difficulty / not substitutable) | | Recovery time objective (RTO) | Maximum tolerable downtime for this function | | Recovery point objective (RPO) | Maximum tolerable data loss | | Date last assessed | When the criticality assessment was last reviewed |

The CIF determination is defined in Article 2(1)(35) DORA and DORA Article 30(3): a function is critical or important if its disruption would materially impair the financial performance, or the soundness or continuity of the services and activities of the financial entity, or the financial entity could not deliver its core services without it.

Most firms under-flag CIFs, listing only their core banking or trading systems. In practice, payment processing, identity verification, AML screening, market data feeds, cloud infrastructure, and email archiving may all qualify — particularly if disruption would trigger regulatory notification obligations.


RT.03 — ICT Third-Party Provider Register

Purpose: Lists all ICT TPPs that provide services supporting the functions in RT.02.

Key fields:

| Field | Description | |-------|-------------| | TPP identifier | Internal reference (used in RT.04 and RT.05) | | TPP legal name | Exact legal entity name | | TPP LEI | If available | | TPP country of establishment | Country of the contracting entity's registered office | | ICT service category | From the ESA-defined taxonomy: cloud services, software services, data analytics, data transmission, payment, colocation, security, etc. | | TPP type | Direct vs. intra-group (ICT services provided by an affiliate vs. an external vendor) | | Designation status | Is the TPP designated as a CTPP by the ESAs? (Yes/No — check the ESMA/EBA CTPP register) |

Sub-outsourcing: If your ICT TPP sub-contracts material parts of its service to a fourth party, and you are aware of this (as you should be under DORA Article 28(2)(e)), the sub-contractor must also be recorded in RT.03 as a sub-contracted entity, linked to the primary TPP.


RT.04 — Contractual Arrangements

Purpose: Maps each ICT TPP in RT.03 to the specific contractual arrangement and the functions in RT.02 that the arrangement supports.

This is where the three-way relationship (entity → function → TPP → contract) is documented.

Key fields:

| Field | Description | |-------|-------------| | Contract reference | Internal contract ID | | Contract start date | When the arrangement commenced | | Contract end date | When it expires (or "rolling" / "indefinite") | | Notice period | How many days' notice is required to terminate | | Governing law | Applicable jurisdiction | | TPP identifier (from RT.03) | Link to the relevant TPP record | | Function identifier(s) (from RT.02) | Which function(s) does this contract support? | | Data classification | What types of data are processed under this arrangement? (personal data / business confidential / publicly available) | | Data location | Country/region where data is stored or processed (important for GDPR and for concentration risk analysis) | | SLA availability target | The contractually required uptime percentage | | Last audit date | When the ICT TPP was last audited by the entity or its representative | | Exit plan exists | Yes/No — does a documented exit/substitution plan exist for this arrangement? |


RT.05 — Sub-Outsourcing Register

Purpose: Documents material sub-contracting arrangements — where your ICT TPP has itself sub-contracted material parts of its service to another entity.

This template is the most commonly incomplete. Many firms are unaware of their ICT TPPs' sub-contractors, or have not contractually required disclosure.

Key fields:

  • Sub-contractor legal name and LEI
  • Sub-contractor country of establishment
  • Services sub-contracted (description)
  • Link to the primary TPP (from RT.03) and contract (from RT.04)
  • Whether the sub-contractor is subject to a DORA-aligned ICT security framework (relevant for non-EU sub-contractors)

Practical note: DORA Article 28(2)(e) requires financial entities to include sub-outsourcing disclosure obligations in their ICT TPP contracts. If your existing contracts do not require the TPP to notify you of material sub-contracting, this is a gap that should be addressed at the next contract renewal or via a contract amendment.


Reporting Reference Dates and Submission

When to Submit

The ITS establishes the following reporting reference dates:

| Reference Date | What Happens | |---------------|--------------| | 31 March 2025 | First reporting reference date — entities must have submitted their register to the NCA as at this date | | Ongoing | Submit to NCA each year (or upon NCA request); update register within a reasonable time after any material change |

The first submission deadline has already passed. If your entity has not yet submitted a compliant register to your NCA, this is an outstanding regulatory obligation.

How to Submit

Submission channels vary by NCA:

| NCA | Submission Method | |-----|-----------------| | AFM (Netherlands) | AFM supervisory portal / secure file transfer | | BaFin (Germany) | BaFin MELDEWESEN portal | | CSSF (Luxembourg) | CSSF eDesk — dedicated DORA reporting module | | CBI (Ireland) | Central Bank ONR (Online Notification & Reporting) | | ECB (significant institutions) | STAR reporting platform (ECB) | | AMF / ACPR (France) | ACPR ONEGATE / AMF reporting portal |

The ITS specifies that submission must use the XBRL DPM taxonomy published by the ESAs, or the equivalent CSV/Excel format templates provided by the ESAs. Most NCAs accept the Excel template format from the EBA/ESMA/EIOPA register of information data point model package.


Common Mistakes and How to Avoid Them

1. Scope too narrow — treating it as an outsourcing register, not an ICT TPP register

The mistake: Only capturing formal "outsourcing" arrangements (as defined under EBA outsourcing guidelines) rather than all ICT third-party service provider arrangements.

Why it matters: DORA's scope is broader than traditional outsourcing. Any ICT service provided by a third party — including SaaS tools, cloud infrastructure, data feeds, and network services — falls within the register scope, regardless of whether it would be classified as "outsourcing" under prior frameworks.

Fix: Apply the Article 3(1)(21) DORA definition of "ICT third-party service provider" broadly: any undertaking that provides ICT services, even if it does not provide a managed service, and even if the arrangement is not formally documented as an outsourcing agreement.


2. Missing sub-outsourcing chains

The mistake: RT.05 is left blank or minimally populated because the entity does not know what its ICT TPPs sub-contract.

Fix: Send disclosure requests to all material ICT TPPs requiring them to identify any sub-contractors that support services provided to you. Include sub-outsourcing disclosure obligations in all new and renewing ICT contracts.


3. CIF under-classification

The mistake: Only flagging the core trading or core banking system as a critical or important function, while failing to flag payment processing, AML screening, data storage, or cloud infrastructure.

Why it matters: If a CIF is disrupted and a major incident results, DORA's incident reporting obligations are triggered. Mis-classifying a function as non-CIF means your incident classification framework will also be wrong.

Fix: Run a structured CIF assessment against the Article 2(1)(35) definition for every function that relies on an ICT TPP. Err on the side of inclusion.


4. Stale contract data

The mistake: RT.04 reflects original contract dates rather than current terms. Contracts have been renewed, amended, or replaced without updating the register.

Fix: Register maintenance must be tied to the contract management lifecycle. Any contract amendment, renewal, or termination should trigger an update to the register.


5. Incorrect data location entries

The mistake: Data location fields reflect where the primary vendor's servers are, without accounting for backup, disaster recovery, or CDN locations.

Why it matters: The ESAs use data location entries to assess third-country concentration risk. If a significant share of EU financial sector data is processed in a single non-EU country, this creates systemic risk that the CTPP framework is designed to address.

Fix: Require ICT TPPs to disclose all locations where data is stored or processed, including backup and DR sites.


CTPP Designation: What Happens Next

Once NCAs collect register submissions, the ESAs use the data to designate CTPPs under Article 31 DORA. The designation process involves:

  1. ESA assessment — EBA (for banks, payment firms), ESMA (for investment firms, CCPs, fund managers), EIOPA (for insurers) assess the systemic importance of each ICT TPP using the register data
  2. Designation criteria — Assessed against: number of financial entities relying on the TPP, systemic importance of those entities, impact of a disruption, and difficulty of substitution
  3. Designation notification — The ICT TPP is notified and has the right to respond
  4. Lead Overseer assignment — One ESA is assigned as Lead Overseer; the CTPP must cooperate with oversight activities, respond to requests, submit action plans, and may be subject to on-site inspections
  5. Remediation — If the Lead Overseer identifies material ICT risk at the CTPP level, it can recommend remediation measures; non-compliance can lead to financial penalties on the CTPP (up to €5 million for CTPPs that are not financial entities)

Key point for financial entities: If your primary ICT TPP is designated as a CTPP, your contractual arrangements with that provider must be updated to reflect the oversight requirements. DORA Article 30(3) requires that contracts with CTPPs include clauses enabling Lead Overseer access.


Summary: DORA Register of Information Checklist

Completeness

  • [ ] All ICT TPP arrangements captured — not just formal outsourcing
  • [ ] Intra-group ICT services included (even if from a parent or affiliate)
  • [ ] Sub-outsourcing chains documented in RT.05
  • [ ] All five templates (RT.01–RT.05) populated and cross-referenced

Accuracy

  • [ ] CIF assessments current and correctly applied
  • [ ] Contract data reflects current terms (not original terms)
  • [ ] Data location entries cover backup and DR sites, not just primary locations
  • [ ] TPP LEIs verified

Process

  • [ ] Register submitted to NCA as at the 31 March 2025 reference date
  • [ ] Update procedure in place for material changes
  • [ ] Annual review cycle documented
  • [ ] CTPP designation status checked for all TPPs (ESMA register maintained under Article 31(15))

Contractual

  • [ ] New and renewing ICT contracts contain sub-outsourcing disclosure obligations
  • [ ] Contracts with CTPPs (or potential CTPPs) contain Lead Overseer access clauses
  • [ ] Exit plans documented for all critical/important function TPP arrangements

Further Reading

  • Commission Implementing Regulation (EU) 2024/2956 — the ITS on register of information (OJ L, 4 December 2024)
  • EBA/GL/2019/02 — EBA Outsourcing Guidelines (relevant for prior-framework context)
  • DORA Article 28 — General principles on the use of ICT third-party service providers
  • DORA Article 31 — Designation of critical ICT third-party service providers
  • JC 2023 83 — Joint ESA Q&A on DORA implementation

Query FinancialRegulations.EU for specific Article 28 and Article 31 requirements, CTPP designation criteria, and contract clause templates sourced directly from the regulation text.

FR

FinancialRegulations.EU Team

Regulatory Intelligence

Expert analysis of EU financial regulation — covering MiCAR, DORA, AIFMD, SFDR, and 15+ regulatory frameworks across 7 jurisdictions.

Query DORA obligations instantly

AI-powered analysis of EU financial regulations. No credit card required.

Start Free →

Related Articles