guide

Building Your ICT Third-Party Register: A Practical Guide to DORA Article 28

DORA Atlas EditorialMarch 22, 202610 min read

The Register That Supervisors Will Request First

When national competent authorities begin their DORA examinations, one of the earliest requests will be the register of information mandated by Article 28(3). This register — a structured, comprehensive record of all ICT third-party service arrangements — is not merely a documentation exercise. It is the supervisory window into your institution's external dependency landscape, your concentration risk exposure, and your contractual compliance posture.

Yet building this register is one of the most operationally challenging requirements in DORA. It touches procurement, legal, IT operations, security, risk management, and business continuity. It demands data that most institutions have never collected in a structured format. And the ESA Implementing Technical Standards (ITS) specify exactly what fields must be populated — leaving little room for approximation.

This guide provides a practical, step-by-step approach to building a register that meets both the letter of Art. 28(3) and the supervisory expectations behind it.

What Article 28(3) Actually Requires

Art. 28(3) states that financial entities shall maintain and update "a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers." The register must be available to the competent authority upon request and must be submitted at least annually — with the first submission cycle already underway for many institutions.

The scope is broader than most compliance teams initially assume. "ICT services" as defined in Art. 3(21) encompasses any digital or data service provided through ICT systems to internal or external users on an ongoing basis, including hardware-as-a-service, software, cloud services, data analytics, and data center services. This captures cloud infrastructure, SaaS applications, managed security services, data feeds, API integrations, and any other ICT service provided by a third party — regardless of whether a formal outsourcing arrangement exists.

This is not your vendor management list. It is a comprehensive register of every ICT service relationship your institution depends on.

The ESA Template: 15+ Required Data Fields

The Joint Committee of the ESAs published Implementing Technical Standards specifying the structure and content of the register. The template organizes information into several reporting categories. While national authorities may add jurisdiction-specific requirements, the core fields include:

Identification data:

LEI (Legal Entity Identifier) of the financial entity
LEI or equivalent identifier of the ICT third-party service provider
Name, registration country, and corporate group structure of the provider
Contract reference number and arrangement start/end dates

Service description:

Type of ICT services provided (classification per ESA taxonomy)
Business functions supported by the ICT service
Whether the service supports critical or important functions (Art. 3(22))
Data location: country of processing, storage, and management
Whether personal data is processed (and volume/sensitivity)

Risk and continuity:

Substitutability assessment (Art. 29): can the provider be replaced?
Alternative providers identified (if any)
Exit strategy status (Art. 28(8)): documented, tested, or not yet developed
Last risk assessment date and outcome
Recovery time and recovery point objectives for the service

Contractual compliance:

Presence of DORA-mandated contractual provisions (Art. 30 checklist)
Audit rights clause (Art. 30(3)(e))
Subcontracting notification and approval clause (Art. 30(2)(a))
Data location and processing restrictions
Termination and exit provisions (Art. 30(2)(f))
Last contract review date

Sub-outsourcing chain:

Identified sub-contractors performing material parts of the service
Country of sub-contractor operation
Whether the sub-outsourcing chain has been assessed for concentration risk

Step-by-Step: Building the Register

Step 1: Inventory Discovery

Begin with a comprehensive inventory exercise that goes beyond your existing vendor list. Cross-reference at least five data sources:

Procurement/AP systems: Every vendor with an active purchase order or invoice in the last 24 months
IT asset management: All applications, SaaS subscriptions, and infrastructure services in use
Network traffic analysis: External connections from your network that indicate unregistered services
Cloud management consoles: AWS, Azure, GCP accounts and marketplace subscriptions
Shadow IT surveys: Direct inquiry to business units about tools adopted without IT procurement

Most institutions discover 20-40% more ICT service arrangements than their official vendor register contains during this discovery phase. Shadow IT — SaaS tools adopted by business units via corporate credit card — is the most common source of unregistered arrangements.

Step 2: Classification

Once the inventory is complete, classify each arrangement according to DORA's criticality framework:

Critical or important function support (Art. 3(22)): An ICT service supports a critical or important function if its disruption would materially impair the financial entity's compliance with regulatory obligations, financial performance, or the soundness and continuity of its business activities. Art. 28(1)(a) requires enhanced oversight for these arrangements.

Standard: All other ICT service arrangements. Lighter oversight but still subject to registration and periodic review.

Classification should be derived from your Business Impact Analysis (Art. 11) — not assigned subjectively. An ICT service supporting a function with a recovery time objective under 4 hours is almost certainly supporting a critical function.

Step 3: Data Collection

For each arrangement, populate the ESA template fields. This is typically the most labor-intensive step, requiring coordination across:

Legal: Contract terms, amendment history, DORA clause compliance
IT operations: Technical architecture, data flows, availability metrics
Security: Risk assessments, vulnerability exposure, access controls
Procurement: Commercial terms, renewal dates, SLA commitments
Business continuity: Recovery capabilities, exit strategy documentation

For critical arrangements, Art. 28(5) requires that due diligence is performed prior to entering into the arrangement. For existing pre-DORA arrangements, this means conducting retrospective due diligence and documenting findings.

Step 4: Concentration Risk Assessment

Art. 29 requires financial entities to assess concentration risk arising from ICT third-party arrangements. This assessment must consider:

Provider concentration: What share of your critical ICT services depends on a single provider or corporate group? Use quantitative measures — the Herfindahl-Hirschman Index (HHI) is increasingly referenced by supervisors as a standard methodology for measuring market concentration.

Geographic concentration: Are critical services concentrated in a single jurisdiction or data center region? Geopolitical risk, natural disaster exposure, and legal/regulatory divergence all factor into geographic concentration.

Technology concentration: Does your infrastructure depend on a single cloud platform, operating system, or database technology? The failure mode is not just provider failure — it is correlated failure across services sharing a common technology stack.

Sub-outsourcing concentration: Even if your direct providers are diverse, do they rely on a common set of sub-contractors? Art. 30(2)(a) requires contractual provisions on subcontracting precisely because sub-outsourcing chains can create hidden concentration.

Step 5: Contractual Gap Analysis

Art. 30 specifies mandatory contractual provisions for ICT service arrangements. For critical or important function arrangements, the requirements are more extensive. Conduct a systematic gap analysis against this checklist:

[ ] Complete service description with performance targets (Art. 30(2)(b))
[ ] Data processing locations and restrictions (Art. 30(2)(c))
[ ] Data availability, integrity, and confidentiality provisions (Art. 30(2)(d))
[ ] Termination rights and minimum notice periods (Art. 30(2)(f))
[ ] Access, inspection, and audit rights for entity and supervisor (Art. 30(3)(e))
[ ] Subcontracting notification and approval requirements (Art. 30(2)(a))
[ ] Cooperation with competent authority obligations
[ ] Business continuity provisions aligned with entity's requirements
[ ] Exit plan provisions including transition assistance and data return (Art. 28(8))
[ ] Obligation to participate in operational resilience testing (Art. 30(3)(b))

For existing contracts missing mandatory clauses, negotiate amendments or addenda. For contracts approaching renewal, incorporate the full DORA clause set. Track contractual gap closure as a remediation programme with defined timelines and ownership.

Step 6: Exit Strategy Documentation

Art. 28(8) requires financial entities to have exit strategies for ICT services supporting critical or important functions. An exit strategy is not a bullet point — it must include:

Alternative providers: Identified, assessed, and where possible pre-qualified
Transition plan: Technical migration steps, data portability requirements, timeline
Resource requirements: Staff, budget, and external support needed for transition
Testing: Evidence that the exit strategy has been validated (at minimum through tabletop exercise)
Trigger conditions: Defined criteria that activate the exit strategy

Common Pitfalls

Pitfall 1: Shadow IT blind spots. Business units adopt SaaS tools without procurement involvement. A marketing team using an AI transcription service processes customer call recordings — personal data flowing to an unregistered ICT service provider. The register must capture these arrangements, which means discovery must extend beyond IT procurement channels.

Pitfall 2: Cloud sub-processors. Your cloud provider runs on infrastructure sub-processors, content delivery networks, and managed services that you may not have visibility into. Art. 30(2)(a) requires that sub-outsourcing material parts of the service requires the financial entity's approval. If your cloud provider's service agreement does not provide sub-processor transparency, your register is incomplete.

Pitfall 3: Legacy contracts. Contracts signed before DORA's enactment almost certainly lack mandatory clauses. Art. 30 does not provide a grandfather clause — all arrangements must comply. Prioritize contractual remediation for critical function arrangements, but track remediation timelines for all arrangements.

Pitfall 4: Confusing "vendor list" with "register of information." A vendor list tracks commercial relationships. The DORA register tracks ICT service dependencies with regulatory-grade metadata: criticality, data location, substitutability, exit strategy, sub-outsourcing chains, and contractual compliance. Most vendor management tools were not designed to capture this level of detail.

Pitfall 5: Point-in-time snapshots. The register is not an annual compliance exercise. Art. 28(3) requires that it be "maintained and updated." Every new ICT service arrangement, every contract renewal, every provider merger or acquisition, and every change in service scope should trigger a register update. Institutions managing this in spreadsheets will find that the register is outdated within weeks of completion.

Pitfall 6: Ignoring intra-group arrangements. ICT services provided by entities within the same corporate group are still ICT third-party service arrangements under DORA. Shared service centers, group-level IT platforms, and intra-group software licensing arrangements must be included in the register.

Making It Sustainable

The register is a living document. Its value to supervisors — and to your own risk management — depends on its accuracy and currency, not on its initial completeness. An operational resilience platform like Valendir that natively integrates vendor registry, contract governance, concentration risk analysis, and exit strategy tracking transforms the register from a compliance burden into a continuously maintained risk management asset.

Build the register once, keep it alive continuously, and it becomes the foundation not just of regulatory compliance but of genuine third-party resilience governance. Build it as a one-time project, and you will be rebuilding it for every examination.

This guide reflects the ESA ITS and RTS published as of Q1 2026. Financial entities should monitor for updates to the reporting templates and submission timelines from their national competent authorities.