DORA Information Register (ICT Third-Party Arrangements)

DORA Information Register ICT Third-Party EU Regulation Financial Services Compliance

Overview

Create and maintain the Register of Information on ICT third-party service arrangements required by DORA Art. 28(3) and ITS 2024/2956. Covers entity identification, TPP data, contractual arrangements, function mapping, sub-outsourcing chains, and ICT concentration risk assessment.

What It Covers

Entity identification (Template B01) – LEI, legal name, entity type, competent authority, group membership, consolidation scope, and reporting reference date
TPP identification (Template B02) – provider LEI, legal name, country of registration, headquarters, service provision, and cloud/non-cloud classification
Contractual arrangement data (Template B03) – contract references, service type mapped to DORA categories, dates, notice periods, governing law, data processing locations, and personal data flags
Function mapping and criticality (Template B04) – which business functions each arrangement supports, Art. 3(22) critical/important classification with justification
Assessment data (Template B05) – risk assessment outcomes, exit strategy availability, substitutability assessment, and due diligence dates
Sub-outsourcing chains (Template B06) – full chain documentation for critical function arrangements, including sub-contractor identity, location, and entity approval status
ICT concentration risk – single-TPP dependencies, sub-contractor overlap, geographic concentration, and mitigation planning per Art. 29(1)

Example Conversation

You: Create the DORA information register for our bank. We are Nordica Bank AG, a credit institution supervised by BaFin. Our LEI is 5493001KJTIIGC8Y1R12. We have 6 ICT third-party arrangements, 3 of which support critical functions. Reporting reference date is 2025-12-31.
Agent: I’ll set up the register structure following ITS 2024/2956 templates. Let me start by populating the entity identification data (Template B01) and then we’ll work through each arrangement systematically.
Entity data captured:
LEI: 5493001KJTIIGC8Y1R12
Legal name: Nordica Bank AG
Entity type: Credit institution
Competent authority: BaFin
Reporting reference date: 2025-12-31
Now I need the details for each of your 6 ICT third-party arrangements. Let’s start with arrangement #1. Can you provide the TPP name, LEI, type of ICT services, contract reference, and whether it supports a critical or important function?
You: Arrangement 1 is with CloudCore GmbH (LEI: 391200ABCDEF1234GH56), a cloud provider running our core banking platform (SaaS). Contract ref ICT-2023-001, started 2023-04-01, runs to 2028-03-31, 12-month notice period, governed by German law. Data stored in DE and NL. This supports our core banking function which is critical – disruption would halt all customer transactions.
Agent: Captured arrangement #1 with CloudCore GmbH. I’ve mapped it as:
Template B02: Cloud provider (SaaS – public), registered DE, service provision DE and NL
Template B03: Contract ICT-2023-001, 2023-04-01 to 2028-03-31, 12-month notice, German law, data locations DE/NL
Template B04: Core banking function flagged as critical/important per Art. 3(22) – disruption would materially impair continuity of services and customer access to payments
Since this supports a critical function, I also need:
Does CloudCore sub-outsource any part of the service? (Template B06)
Do you have an exit strategy documented for this arrangement? (Template B05)
When was the last due diligence review performed?
You: CloudCore uses AWS Frankfurt as their infrastructure provider – that’s the only sub-outsourcing. We approved it in writing last June. We have an exit strategy tested in Q3 2025, and substitutability is “substitutable with effort” since we’d need 9-12 months to migrate. Last due diligence was 2025-09-15.
Agent: Sub-outsourcing chain documented:
CloudCore GmbH → Amazon Web Services EMEA SARL (infrastructure, Frankfurt/DE), chain depth 1, entity approved 2024-06-01
Assessment data recorded: exit strategy available (last tested Q3 2025), substitutability “substitutable with effort”, last due diligence 2025-09-15.
Let’s move to arrangement #2. I’ll continue this process for all 6 arrangements, then run the validator and assess ICT concentration risk.
You: [After all 6 arrangements are entered] Run the validator and produce the register.
Agent: Running dora_register_validator against the register data.
Validation results: 0 errors, 3 warnings. All mandatory ITS 2024/2956 fields are populated. Warnings are for optional improvements – TPP headquarter country missing for 2 arrangements, and one governing law could be more specific.
ICT concentration risk analysis found:
HIGH: AWS Frankfurt appears as a sub-contractor for 2 different TPPs supporting 3 critical functions (CloudCore and DataVault). Single infrastructure failure could cascade.
MEDIUM: 4 of 6 arrangements serviced from Germany – moderate geographic concentration.
I’ve produced the complete register document with all 8 sections including the concentration risk mitigation plan. Saved to output/Register-of-Information-ICT-TPP.md. The register is ready for management body review and sign-off per Art. 28(2).

Sample Output Excerpt

The register follows the ITS 2024/2956 template structure with executive summary, per-arrangement data organized by templates B01–B06, critical function mapping, and ICT concentration risk assessment.

Register of Information on ICT Third-Party Service Arrangements

Regulation (EU) 2022/2554 – Article 28(3) Implementing Technical Standard (ITS) 2024/2956

1. Executive Summary

Reporting entity: Nordica Bank AG LEI: 5493001KJTIIGC8Y1R12 Entity type: Credit institution Competent authority: BaFin Reporting reference date: 2025-12-31 Register prepared by: Maria Schneider, Head of ICT Third-Party Risk Register approved by: Dr. Hans Weber, Chief Risk Officer (Management Board member) Approval date: 2026-01-15

Scope

This register covers all ICT third-party service arrangements maintained by Nordica Bank AG at individual level as of 2025-12-31. The register includes 6 contractual arrangements with 6 distinct ICT third-party service providers, of which 3 arrangements support critical or important functions as defined in Art. 3(22) DORA.

Key Findings

Total ICT TPP arrangements: 6
Arrangements supporting critical/important functions: 3
Distinct ICT TPPs: 6
ICT concentration risk indicators identified: 2 (HIGH: 1, MEDIUM: 1)
Sub-outsourcing chains documented: 2
Register completeness (ITS 2024/2956): 100% of mandatory fields populated

3. Register of ICT Third-Party Arrangements

Arrangement 1: ICT-2023-001

3.1 TPP Identification (Template B02)

Field	Value
TPP LEI	391200ABCDEF1234GH56
TPP legal name	CloudCore GmbH
Country of registration	DE
Country of headquarters	DE
Country(ies) of service provision	DE, NL
TPP type	Cloud (SaaS – public)

3.2 Contract Data (Template B03)

Field	Value
Contract reference	ICT-2023-001
Type of ICT services	Cloud computing – SaaS – core banking platform
Contract start date	2023-04-01
Contract end date	2028-03-31
Notice period	12 months
Governing law	German law (Frankfurt am Main)
Data storage locations	DE, NL
Personal data processing	Yes – GDPR Art. 28 DPA in place: Yes

3.3 Functions Supported (Template B04)

Function ID	Description	Critical/Important	Outsourced	Assessment Date	Justification
FN-001	Core banking platform – customer accounts, transactions, balances	Yes	Yes	2025-06-15	Disruption halts all customer transactions, materially impairing continuity of services
FN-002	Payment processing – SEPA credit transfers and direct debits	Yes	Yes	2025-06-15	Failure prevents customers from executing payments, regulatory breach of PSD2 obligations

3.5 Sub-Outsourcing Chain (Template B06)

Sub-contractor	LEI	Country (Reg.)	Country (Service)	Service Description	Chain Depth	Entity Approved
Amazon Web Services EMEA SARL	222100T6FKMLJNVKC407	LU	DE	Cloud infrastructure (compute, storage, networking) – Frankfurt region	1	Yes (2024-06-01)

5. ICT Concentration Risk Assessment

5.1 Single-TPP Dependencies

No single TPP supports 2 or more critical/important functions directly. However, the sub-contractor concentration below represents a functional equivalent.

5.2 Sub-Contractor Concentration

Sub-Contractor	Used By (TPPs)	Services	Severity	Mitigation Actions
Amazon Web Services EMEA SARL	CloudCore GmbH, DataVault BV	Cloud infrastructure for core banking and data warehouse	HIGH	Multi-cloud feasibility study commissioned (due Q2 2026); contractual SLA with 99.99% availability; business continuity drill conducted Q3 2025

5.3 Geographic Concentration

Country/Region	Critical Functions Serviced	TPPs in Region	Severity	Mitigation Actions
Germany (DE)	Core banking, payment processing, AML monitoring, data warehouse	CloudCore GmbH, SecureID AG, DataVault BV, PayNet GmbH	MEDIUM	Secondary DR site in NL operational; contractual right to relocate processing within EU

Extension Tools

`dora_register_validator`

Validates a DORA information register JSON file against the complete ITS 2024/2956 field requirements. Designed to run after populating the register data and before producing the final document for supervisory submission.

Check	What It Validates	Output
Entity identification (B01)	LEI present and valid, legal name, entity type, competent authority, reporting reference date in ISO format	ERROR if mandatory fields missing
TPP identification (B02)	Legal name, LEI or documented reason for absence, country of registration, country of service provision	ERROR for missing mandatory fields, WARNING for missing optional fields like headquarters country
Contract data (B03)	Contract reference uniqueness, start date present and valid ISO format, data storage locations populated	ERROR for missing contract reference or data locations
Function mapping (B04)	At least one function mapped per arrangement, criticality flag set, justification and assessment date present for critical functions	ERROR if no functions mapped or criticality flag missing, WARNING if justification missing for critical functions
Assessment data (B05)	Exit strategy documented for critical function arrangements, substitutability assessed, risk assessment outcome recorded	ERROR if assessment missing for critical arrangements, WARNING for non-critical
Sub-outsourcing (B06)	Chain documented for critical function arrangements (explicitly stating “none” if no sub-outsourcing), sub-contractor name and country present	ERROR if critical arrangement has no sub-outsourcing documentation
ICT concentration risk	Single-TPP dependency (one TPP supporting 3+ critical functions = HIGH, 2 = MEDIUM), sub-contractor overlap across TPPs, geographic concentration of critical services	Severity-rated concentration indicators (HIGH / MEDIUM / LOW)
Date validation	All date fields parse as valid ISO 8601 dates (YYYY-MM-DD)	WARNING for malformed dates

Getting Started

To create your DORA information register, prepare the following before starting:

Entity identification data – your organization’s LEI, full legal name, entity type (credit institution, investment firm, etc.), and competent authority
Contract inventory – a list of all ICT third-party service contracts, including contract reference numbers, start/end dates, and governing law
TPP details – for each provider: legal name, LEI (if available), country of registration, and countries where they deliver services
Function register – your internal catalogue of business functions, with preliminary assessment of which are critical or important per Art. 3(22)
Sub-outsourcing information – for providers supporting critical functions, details of any sub-contractors they use

Then start the conversation by telling the agent:

Your entity name, LEI, and entity type
How many ICT third-party arrangements you have
The reporting reference date for this register snapshot
Whether this is a first-time register or an update

The agent will walk through each arrangement systematically, collecting data for all six ITS templates (B01–B06), then run the validator to check completeness, analyze ICT concentration risk, and produce the final register document ready for management body sign-off and supervisory submission.

Tip: For large registers (20+ arrangements), consider working in batches – critical function arrangements first, then remaining arrangements. The validator can be run incrementally as you build the register.