DORA Third-Party Risk Register Template

According to Deloitte research, 46% of financial institutions rank the Register of Information as the single most challenging component of DORA compliance.

That statistic exposes a gap between regulatory intent and operational readiness that grows more urgent every quarter.

The Digital Operational Resilience Act (DORA) became enforceable on 17 January 2025, and competent authorities across the EU must forward completed register of information submissions to the European Supervisory Authorities by 31 March 2026.

Financial entities that still rely on ad-hoc spreadsheets or fragmented vendor lists face material compliance and penalty exposure.

This guide provides a practitioner-ready DORA third-party risk register template that maps the ESA’s 15-table structure to a usable risk register format.

The template covers every mandatory field under Article 28, adds risk-scoring columns aligned with ISO 31000, and includes a 90-day implementation roadmap so your team can move from inventory to operational reporting in a single quarter.

The article walks through each register component, explains the criticality assessment methodology, provides worked KRI examples, and highlights the pitfalls that trip up first-time filers.

Every table and field mapping is designed for direct use in your third-party risk management programme.

What DORA Article 28 Requires for ICT Third-Party Risk

DORA establishes five core pillars: ICT risk management, incident reporting, resilience testing, third-party risk management, and cyber threat information sharing.

The third-party pillar carries particular weight because financial entities increasingly depend on external ICT providers for critical functions ranging from cloud hosting to payment processing.

Article 28 mandates that every financial entity shall maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information covering all contractual arrangements with ICT third-party service providers.

The register is not a passive compliance document. DORA assigns it three active roles: an internal monitoring tool for the financial entity, a supervisory data source for competent authorities, and a foundation for the ESAs’ designation of Critical ICT Third-Party Providers (CTPPs).

In November 2025, the ESAs designated 19 CTPPs, including AWS, Microsoft Azure, and Google Cloud, triggering direct EU-level oversight for the first time. Entities that contract with designated CTPPs face heightened scrutiny of their register entries and risk assessment documentation.

Scope of Entities Covered

DORA applies to 21 categories of financial entities, spanning banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more. The regulation also covers ICT intra-group service providers, meaning that shared-services centres within financial groups must appear in the register.

A solid understanding of your enterprise risk management framework is foundational before mapping DORA-specific requirements.

The ESA Register of Information: 15-Table Structure

Commission Implementing Regulation (EU) 2024/2956 specifies the template that all financial entities must follow.

The register is a multi-table relational data model, not a single flat spreadsheet. Each table links to others through primary and foreign keys, enabling regulators to trace relationships from entity-level governance down to individual subcontractor arrangements.

Understanding this structure is essential for building a compliance risk assessment that holds up under supervisory review.

Each table includes mandatory and conditional fields. The mandatory fields form the baseline that every entity must complete.

Conditional fields activate based on the criticality assessment; contracts supporting critical or important functions trigger additional disclosure requirements around business continuity provisions, exit strategies, and subcontractor chains.

DORA Third-Party Risk Register Template: Core Fields

The ESA template captures regulatory data. A practical risk register adds risk-scoring and monitoring dimensions that transform compliance data into an active management tool.

The template below merges ESA mandatory fields with risk assessment methodology columns drawn from ISO 31000 and COSO ERM. Adapt column widths and scoring scales to your entity’s risk appetite statement.

Provider and Contract Section

Criticality and Risk Scoring Section

DORA requires a formal assessment of whether each ICT service supports a critical or important function.

The template below adds inherent and residual risk scores using a 5×5 risk assessment matrix so your team can prioritize oversight resources and set KRI thresholds that drive escalation.

The weighted score produces a composite risk rating that maps directly to oversight intensity.

Scores of 1.0-2.0 fall within risk tolerance and require standard annual review. Scores of 2.1-3.5 trigger enhanced monitoring with quarterly reviews. Scores above 3.5 demand monthly oversight, board reporting, and active risk mitigation plans.

Key Risk Indicators for DORA Third-Party Monitoring

Static registers decay in value unless connected to live monitoring. The table below defines key risk indicators calibrated to DORA’s third-party requirements.

Each KRI includes green/amber/red thresholds and an escalation path aligned with the three lines model. Feed these into your KRI dashboard for real-time visibility.

Aligning DORA with ISO 27001 and NIST CSF 2.0

Organizations holding ISO 27001 certification have a head start. Research from GRC Solutions indicates that ISO 27001-certified entities cover approximately 80% of DORA’s requirements through existing controls for information security management.

The gap sits primarily in three areas: prescriptive contractual clauses for ICT providers, mandatory exit strategies, and structured sub-outsourcing oversight.

A mapped approach avoids duplicate controls and reduces compliance cost. The table below cross-references DORA articles to ISO 27001 controls and NIST CSF 2.0 functions.

Building Your DORA Third-Party Risk Register: Step-by-Step

A phased build prevents scope paralysis. The following six-step process moves from raw provider data to a submission-ready register, incorporating lessons from first-wave filers and regulatory feedback from competent authorities.

Anchor each step in your risk management process to ensure consistency.

Step 1: Complete ICT Provider Inventory

Start with procurement, accounts payable, and IT asset management data. Cross-reference against cloud subscription consoles (AWS, Azure, GCP), SaaS licence databases, and IT risk management inventories.

The goal is a single, deduplicated list of every entity providing ICT services, including intra-group providers.

Step 2: Map Contracts to Critical Functions

Link each provider to the critical or important functions they support using table B_04.01 as the anchor.

A business impact analysis should already exist for your entity’s critical functions. Map providers against BIA outputs to auto-populate the criticality assessment in table B_06.01. Where BIA coverage is incomplete, prioritise services that carry regulated data or support payment processing.

Step 3: Populate ESA Mandatory Fields

Work through tables B_01 to B_07 sequentially. Use LEI lookups from the GLEIF database for provider identification.

For contracts lacking explicit end dates (e.g., evergreen SaaS subscriptions), enter the next renewal/notice date and flag for review. Populate the sub-outsourcing tables (B_05) by requesting provider disclosure letters.

Step 4: Apply Risk Scoring

Layer your risk scoring methodology over the ESA data. Use the 5×5 weighted matrix from this template to generate composite scores for each provider-contract pair.

Align scoring thresholds to your entity’s risk appetite and ensure scores trigger the correct oversight intensity (standard, enhanced, or intensive).

Step 5: Connect KRIs and Reporting

Embed the KRIs from this guide into your operational risk management dashboard. Automate data feeds where possible: pull SLA breach data from service monitoring tools, contract expiry alerts from CLM systems, and budget concentration figures from finance. Set up board reporting that surfaces red-rated KRIs alongside register completeness metrics.

Step 6: Validate and Submit

Run the ESA’s validation rules against your register before submission. Check primary-foreign key integrity across all 15 tables, verify LEI validity, and confirm that conditional fields are populated for all critical/important function contracts. Use a RCSA process to self-assess the completeness and accuracy of your submission.

Implementation Roadmap

The roadmap below compresses register build-out into a single quarter. Adjust timelines based on your entity’s size and current maturity level. Align milestones with your risk management lifecycle stages.

Common Pitfalls and How to Avoid Them

Looking Ahead: DORA Third-Party Risk Trends for 2025-2027

The regulatory trajectory is clear: DORA’s third-party risk requirements will tighten, not loosen. The EBA’s July 2025 consultation on non-ICT third-party risk guidelines signals that the register concept will expand beyond ICT services to encompass all material outsourcing arrangements.

Financial entities building their DORA registers should design for this expansion from the start by selecting data architectures that accommodate additional provider categories and risk dimensions. The GRC framework you adopt now should be extensible enough to absorb these incoming requirements.

Direct supervision of CTPPs adds a new dynamic. The 19 providers designated in November 2025 will face ESA-led inspections, and their financial entity clients will need to demonstrate that their registers accurately reflect the services consumed, data locations, and contingency arrangements for each designated provider.

Expect competent authorities to benchmark entity-level RoI submissions against the CTPP supervision findings, creating a cross-validation loop that rewards data accuracy. Your regulatory risk management function should track these designation decisions and update register entries accordingly.

Technology will play a growing role. The current Excel-based submission format will likely migrate to xBRL-CSV or API-based reporting within 18-24 months, reflecting the ESAs’ broader digital reporting strategy.

Entities that invest in structured data models now, rather than flat spreadsheets, will avoid costly re-architecture later. Meanwhile, AI-driven risk assessment tools are beginning to automate provider risk scoring, sub-outsourcing chain mapping, and anomaly detection across register data, reducing the manual burden on 2nd line teams.

Cross-border convergence is another trend to watch. US financial regulators are closely monitoring DORA’s implementation, and the OCC’s existing third-party risk guidance (OCC 2023-17) already shares conceptual DNA with DORA’s register approach.

Global financial groups operating across EU and US jurisdictions should build unified registers that satisfy both regimes, reducing duplication and improving group-level risk quantification for boards.

The cost of compliance, estimated by Deloitte at 2-5 million euros for most institutions, is better absorbed when the register serves multiple regulatory masters simultaneously.

Ready to build your DORA third-party risk register? Visit riskpublishing.com for downloadable templates, risk management consulting services, and expert guidance on DORA compliance implementation. Contact us for a tailored assessment of your register readiness.

References

1. European Insurance and Occupational Pensions Authority (EIOPA) – Digital Operational Resilience Act

2. DORA Article 28 – General Principles for Third-Party Risk

3. European Securities and Markets Authority (ESMA) – DORA Digital Finance and Innovation

4. European Banking Authority (EBA) – Preparation for DORA Application and RoI Reporting

5. EBA – DORA Register of Information Reporting FAQ (March 2025)

6. ESMA – Final Report on Draft ITS on Register of Information (JC 2023/85)

7. ESAs – First Set of Rules Under DORA for ICT and Third-Party Risk Management

8. Morgan Lewis – Preparing for DORA: Compliance Deadline Arrives (January 2025)

9. Copla – DORA ISO 27001 Mapping: Turning Compliance into Resilience

10. GRC Solutions – How DORA Fits with ISO 27001, NIS2 and the GDPR

11. DORA Toolkit – Register of Information: A Practitioner’s Guide to All 15 Tables

12. Austrian Financial Market Authority (FMA) – DORA Managing ICT Third-Party Risk

13. AFM Netherlands – Getting Ready for DORA: Management of ICT Risk for Third Parties

14. ISO – ISO 31000:2018 Risk Management Guidelines

15. NIST – Cybersecurity Framework 2.0

Chris Ekai

Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.