DORA ICT Register of Information: Sub-Outsourcing Compliance Guide

The DORA register of information is a structured, machine-readable inventory that every in-scope financial entity must maintain under Article 28 of Regulation (EU) 2022/2554, listing every ICT third-party arrangement that supports a critical or important function, together with the full chain of sub-outsourcing relationships that underpin it. For many institutions, that chain runs three, four or more tiers deep, with US hyperscalers appearing as undisclosed sub-processors at layers the financial entity itself cannot directly audit or control.

What Article 28 and the ITS Templates Actually Require

Article 28 of DORA establishes the legal obligation; the Commission Implementing Technical Standards (ITS) on the register of information, developed by the EBA, EIOPA and ESMA Joint Committee, specify exactly what data fields must be populated for each arrangement.

The ITS templates require financial entities to record, at minimum: the legal name and LEI of every ICT third-party provider; the nature and classification of the service (critical or important versus other); the jurisdictions in which services are delivered and data is processed; the contractual start and end dates; the substitutability assessment; the data sensitivity classification; and the full sub-outsourcing chain beneath each primary provider. Every sub-processor that stores, processes or transmits data on behalf of the primary provider in support of a critical or important function must be individually identified, not bundled into a generic reference to “cloud infrastructure.”

The practical consequence is significant. A financial entity that hosts its core banking system on a tier-1 cloud provider must identify whether that provider itself relies on, for example, a US-domiciled CDN, an American object storage service or a foreign-controlled identity platform. Each such dependency requires its own register entry and its own contractual disclosure trail.

The EBA, EIOPA and ESMA Joint Committee stated in its joint opinion on the ITS: “The register of information is not a static document; it is a living inventory that supervisors will use to map systemic concentration risk across the entire financial sector.” That framing matters: supervisors are not just assessing individual entities but aggregating register data sector-wide to identify where multiple institutions share the same fourth-party dependencies.

Sub-Outsourcing Depth and Commission Delegated Regulation (EU) 2025/420

Commission Delegated Regulation (EU) 2025/420, which governs the functioning of Joint Examination Teams (JETs) for critical third-party providers, reinforces the obligation to map sub-outsourcing chains by requiring that any ICT arrangement supporting a critical or important function include contractual provisions that flow down through every tier.

The regulation does not set a maximum permitted depth of outsourcing, but it requires that financial entities impose contractual obligations on their primary providers to disclose and consent to any further sub-outsourcing, and to pass equivalent disclosure obligations down the chain. In practical terms this means that a financial entity cannot simply accept a primary provider’s assurance that its own supply chain is compliant: the financial entity must be able to demonstrate, from its own contractual documentation, that each tier below the primary provider is identifiable and bound by equivalent obligations.

The required contractual clauses at each tier include: explicit identification of sub-outsourcing arrangements; the right of the financial entity to object to or withdraw consent for sub-outsourcing changes; audit rights extending to sub-processors; data location and jurisdiction restrictions; and business continuity obligations that bind sub-processors independently. These requirements align with and extend the minimum contractual content set out in DORA Article 30.

Mapping Fourth-Party and Nth-Party Dependencies: ESA Expectations

The ESA expectation is unambiguous: financial entities must be capable of producing, on supervisory request, a complete dependency graph showing every ICT provider, sub-processor and infrastructure layer that supports each critical or important function. This extends to fourth-party relationships, meaning the providers of the entity’s providers’ providers.

In practice, a financial entity running workloads on a major US hyperscaler will find that fourth-party dependencies include: the hyperscaler’s own colocation partners, hardware supply chains, identity and access management platforms, and DDoS mitigation services, many of which are themselves US-domiciled and subject to US jurisdictional reach under the CLOUD Act and FISA 702. Each of these must be assessed for legal and operational risk and entered into the register if they underpin a critical or important function.

Sovereign on-premises infrastructure, or hosting under Swiss law with a provider that does not rely on US-controlled sub-processors, compresses the dependency graph substantially. The financial entity becomes its own infrastructure operator for the relevant layers, eliminating multiple register entries and the contractual cascade obligations that accompany them.

Documenting the Removal of a US Sub-Processor

When a financial entity migrates a critical workload from a US hyperscaler to a sovereign alternative, the register of information must be updated to reflect the change and the file must contain sufficient documentation to justify the transition to a supervisor. This is not merely a technical exercise; it is a compliance narrative.

The documentation package should include: the original register entry and its risk classification; the rationale for substitution, specifying the legal exposure being removed (for example, susceptibility to US government access orders under FISA 702); an equivalence assessment demonstrating that the sovereign alternative meets or exceeds the service levels, security controls and business continuity capabilities of the replaced provider; evidence of testing, including failover and recovery time objective validation; and updated contractual documentation reflecting the Article 30 mandatory clauses with the new provider.

The equivalence assessment is particularly important. Supervisors will not accept a register change that simply removes a provider without affirmative evidence that continuity of service to the critical or important function is unimpaired. Financial entities should document RTO and RPO test results, certification status (ISO 27001, SOC 2 Type II or equivalent) of the sovereign provider, and any enhanced audit rights negotiated in the new contract.

Supervisory Consequences and Continuous Register Accuracy

An incomplete or inaccurate register of information exposes financial entities to a range of supervisory consequences under DORA Article 50, from remediation orders to public disclosure of deficiencies. For entities whose ICT providers are designated as critical third-party providers, supervisors participating in Joint Examination Teams under Commission Delegated Regulation (EU) 2025/420 can access the register directly and cross-reference it against provider disclosures.

IBM’s Cost of a Data Breach Report 2024 found that the average total cost of a data breach reached USD 4.88 million globally, the highest figure in the report’s history. The EBA’s Risk Assessment of the European Banking System, published in December 2023, noted that over 50 percent of material ICT-related incidents in the EU financial sector involved a third-party provider. These figures underscore why supervisors treat register accuracy as a proxy for operational risk governance maturity.

Approximately 22,000 entities fall within DORA’s direct scope across the EU, according to the European Commission’s impact assessment accompanying Regulation (EU) 2022/2554. Supervisors cannot individually audit each entity’s supply chain manually; they will rely on register data, automated cross-referencing and whistleblower or incident disclosures to identify gaps.

Continuous automated asset discovery addresses this operationally. Sovereign on-premises environments can be instrumented with configuration management databases (CMDBs) and network discovery tools that generate register-ready outputs, flagging new dependencies automatically. Cloud-native environments hosted under a single sovereign provider similarly allow complete API-level enumeration of infrastructure components, which can be mapped to register templates without manual re-entry. US hyperscaler environments, by contrast, frequently introduce new managed services and third-party integrations that are invisible to the customer’s register until an incident or audit reveals them.

The Interaction Between the Register and DORA Article 30 Audit Rights

DORA Article 30 sets mandatory minimum content for every ICT third-party contract. Among the required provisions are: full service level descriptions; data location and jurisdiction specifications; cooperation obligations with supervisory authorities; and, critically, the right of the financial entity and its competent authority to audit the ICT provider and any sub-processor supporting a critical or important function.

Article 30’s text specifies: “Financial entities shall ensure that contractual arrangements on the use of ICT services include provisions on the full service level descriptions, including updates and revisions thereof.” Each entry in the register of information should be traceable to a contract that contains the Article 30 minimum clauses. An entry without a compliant contract is both a register deficiency and a contractual compliance failure.

For sub-outsourcing chains, this means that audit rights must flow down in writing. A financial entity cannot rely on its primary provider’s assurance that sub-processors allow audits; it must hold contractual documentation confirming that the right passes through every tier. Where a US hyperscaler acts as a sub-processor, audit rights are frequently limited by the provider’s standard terms to third-party certification reviews rather than direct financial entity audits, which may not satisfy the DORA requirement. Sovereign providers, particularly those operating under negotiated service agreements, are typically willing to grant direct audit access as a contractual standard term, simplifying both the Article 30 compliance record and the corresponding register documentation.

Practical Path to a Compliant and Defensible Register

Building a register of information that survives supervisory scrutiny requires treating it as an operational system rather than an annual document. The steps that distinguish compliant institutions are: automated discovery feeding register templates in real time; contractual due diligence that captures sub-outsourcing chains before onboarding, not after; a formal change-management process that updates the register whenever an ICT arrangement changes; and regular tabletop exercises that simulate a supervisor’s request for the full dependency graph of a named critical function.

Sovereign infrastructure investments pay a direct compliance dividend here. A financial entity that hosts its critical workloads on sovereign on-premises or Swiss-hosted infrastructure, using open-source platforms without undisclosed US sub-processors, can enumerate its complete ICT dependency graph in hours rather than weeks. That capability, documented and repeatable, is precisely what the EBA, EIOPA and ESMA Joint Committee describes as the standard they expect to find when they access a register of information submission.

FAQ

Which financial entities must maintain a DORA register of information?

All entities within DORA’s scope under Article 2, including credit institutions, payment institutions, insurers, investment firms, crypto-asset service providers and CCPs, must maintain and annually submit a register of information covering every ICT third-party service arrangement supporting critical or important functions.

How many tiers of sub-outsourcing must be documented under Commission Delegated Regulation (EU) 2025/420?

The regulation does not cap the number of tiers, but it requires that every sub-outsourcing arrangement supporting a critical or important function be individually identified and assessed. Financial entities must contractually impose equivalent disclosure obligations on each tier so that the full chain is visible and supervisors can trace dependencies to the nth party.

What happens if a financial entity cannot provide an accurate register of information to its supervisor?

Competent authorities can impose supervisory measures under DORA Article 50, including binding remediation orders, public disclosure of non-compliance and, for entities dealing with designated critical third-party providers, enhanced supervisory engagement. Persistent inaccuracy may also restrict the entity’s ability to onboard new outsourced functions without prior supervisory approval.

Does replacing a US-hyperscaler with Swiss sovereign hosting require a new DPIA under GDPR?

Yes, the controller must document the change in its records of processing activities and conduct or update a DPIA where the original assessment assumed US-based processing. The new assessment will typically be shorter because Swiss hosting under the revised FADP avoids the cross-border transfer analysis required for US providers subject to the CLOUD Act and FISA 702.

How does DORA Article 30 interact with sub-outsourcing register entries?

Each entry in the register of information must correspond to a contract that includes the Article 30 mandatory clauses, covering audit rights, data location, service levels and subcontracting conditions. Where sub-outsourcing exists, equivalent clauses must flow down contractually to sub-processors. An entry in the register without a compliant underlying contract is itself a regulatory deficiency that supervisors will treat as evidence of inadequate third-party risk governance.