DORA Third-Party Risk Register Template

Key Takeaways

DORA Article 28 requires every EU-regulated financial entity to maintain a Register of Information (RoI) covering all ICT third-party contractual arrangements, with mandatory annual reporting to competent authorities.

The ESA template structures the RoI across 15 interlinked tables with over 60 mandatory data fields, covering provider identity, contract terms, criticality assessments, data locations, and sub-outsourcing chains.

A practical DORA third-party risk register maps each ESA table to internal risk management fields including inherent risk scores, residual risk ratings, KRIs, and control effectiveness measures.

Penalties for non-compliance can reach up to 2% of annual worldwide turnover for financial entities and 1% of average daily worldwide turnover for designated critical ICT providers.

Organizations already ISO 27001-certified are approximately 80% ready for DORA compliance but must close gaps in contractual clause requirements, exit strategies, and sub-outsourcing oversight.

Competent authorities must submit completed RoI data to ESAs by 31 March 2026, making the current window critical for register build-out and validation.

A structured 90-day implementation roadmap moves teams from ICT provider inventory through risk scoring and operational reporting within a single quarter.

 

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.

A well-structured DORA Third-Party Risk Register closes that gap by consolidating every ICT provider, contract, and critical-function dependency into a single auditable source of truth.

 

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

 

Every requirement in Article 28 should be reflected as a documented field or control within your DORA Third-Party Risk Register.

 

Article 28 sets the legal foundation for every DORA Third-Party Risk Register, defining the contractual and oversight obligations financial entities must document for each ICT provider.

 

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

 

Knowing exactly which entities fall in scope determines who must build and maintain a DORA Third-Party Risk Register and how detailed that register has to be.

 

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.

 

Entity Category	Examples	RoI Obligation
Credit institutions	Banks, building societies	Entity, sub-consolidated, and consolidated RoI
Insurance undertakings	Life/non-life insurers, reinsurers	Entity and group-level RoI
Investment firms	Asset managers, broker-dealers	Entity-level RoI (consolidated if part of group)
Payment & e-money institutions	PSPs, digital wallets	Entity-level RoI
Crypto-asset service providers	Exchanges, custodians	Entity-level RoI
ICT intra-group providers	Shared-services IT centres	Must appear as provider in parent entity’s RoI

 

The ESA Register of Information: 15-Table Structure

 

Each of these 15 tables feeds a corresponding part of your DORA Third-Party Risk Register.

 

Understanding this 15-table structure is essential before mapping it into a working DORA Third-Party Risk Register.

 

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.

 

Table ID	Table Name	Purpose
B_01.01	Entity identification	Legal entity identifier (LEI), name, entity type, consolidation scope
B_01.02	Entity branch identification	Branch-level details for entities operating across jurisdictions
B_02.01	Contractual arrangement general	Contract reference ID, start/end dates, governing law, renewal terms
B_02.02	Contractual arrangement linked to function	Maps each contract to the critical/important function it supports
B_02.03	Contractual arrangement ICT services	Detailed description of each ICT service, data classification, hosting model
B_03.01	ICT third-party provider identification	Provider LEI, name, registration country, parent company structure
B_03.02	ICT third-party provider additional	Provider certifications (ISO 27001, SOC 2), audit rights, data centres
B_03.03	ICT third-party provider linked to entity	Relationship type, first engagement date, provider criticality for the entity
B_04.01	Function identification	List of critical/important functions with business-line mapping
B_05.01	Sub-outsourcing arrangement general	Sub-outsourcing contract ID, tier, scope of services delegated
B_05.02	Sub-outsourcing ICT services	ICT services delivered by sub-outsourcers, data locations, oversight model
B_06.01	Assessment of criticality or importance	Criticality score, substitutability, impact of disruption on critical functions
B_07.01	Costs and fees	Annual cost, fee structure, cost as percentage of ICT budget
B_99.01	Data quality and reconciliation	Validation flags, reconciliation status, last-updated timestamp
B_99.02	Reporting information	Reporting reference date, submission entity, consolidation level

 

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 core fields described here form the reusable backbone of a DORA Third-Party Risk Register that scales as your provider portfolio grows.

 

The DORA Third-Party Risk Register Template below organizes every mandatory ESA data point into practical, audit-ready columns your team can populate immediately.

 

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

Accurate provider data keeps the DORA Third-Party Risk Register reliable as contracts change.

These provider and contract fields form the backbone of any DORA Third-Party Risk Register, linking each vendor to the critical functions it supports.

 

 

Field	ESA Table Source	Data Type	Example Entry	Validation Rule	Update Frequency
Provider LEI	B_03.01	20-char alphanumeric	5493001KJTIIGC8Y1R12	GLEIF validation	On contract change
Provider Name	B_03.01	Text	Amazon Web Services EMEA	Match LEI register	Annual
Contract Reference ID	B_02.01	Internal code	ICT-2025-AWS-001	Unique within entity	On creation
Contract Start Date	B_02.01	ISO 8601 date	2024-01-15	Cannot be future for active	On execution
Contract End Date	B_02.01	ISO 8601 date	2027-01-14	Must be after start date	On renewal
Governing Law	B_02.01	ISO 3166 country code	IE (Ireland)	Valid country code	On contract change

 

Criticality and Risk Scoring Section

Document your methodology so the DORA Third-Party Risk Register remains auditable over time.

Consistent scoring is what makes a DORA Third-Party Risk Register defensible under supervisory review.

 

 

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.

 

Risk Dimension	Score 1 (Very Low)	Score 2 (Low)	Score 3 (Medium)	Score 4 (High)	Score 5 (Critical)	Weight
Business impact of disruption	Minimal, <1hr RTO	Low, 1-4hr RTO	Moderate, 4-8hr RTO	Significant, 8-24hr RTO	Severe, >24hr RTO	30%
Substitutability of provider	Multiple alternatives	2-3 alternatives	Limited alternatives	Single realistic alternative	No alternative exists	20%
Data sensitivity	Public data only	Internal data	Confidential data	Restricted/PII	Regulated financial data	20%
Concentration risk	<5% of ICT budget	5-10% of budget	10-20% of budget	20-35% of budget	>35% of ICT budget	15%
Subcontracting depth	No sub-outsourcing	1 tier, full visibility	2 tiers, partial visibility	3+ tiers, limited visibility	Unknown chain	15%

 

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

 

Well-chosen KRIs keep your DORA Third-Party Risk Register actionable between formal review cycles.

 

Embedding live KRIs turns a static DORA Third-Party Risk Register into a continuous monitoring tool rather than a point-in-time compliance snapshot.

 

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.

 

KRI Name	Data Source	Green	Amber	Red	Escalation Path
RoI completeness rate	Register vs. contract inventory	>95%	85-95%	<85%	2nd Line risk to CRO
Critical provider SLA breach rate	Service monitoring tools	<2%	2-5%	>5%	1st Line ops to CISO
Sub-outsourcing visibility	Provider disclosures	100% mapped	80-99% mapped	<80% mapped	Vendor management to CRO
Contract renewal without risk review	Contract management system	0 instances	1-2 instances	>2 instances	Compliance to board risk committee
Days since last provider audit	Audit schedule	<365 days	365-450 days	>450 days	Internal audit to audit committee
ICT budget concentration (top provider)	Finance/procurement data	<15%	15-25%	>25%	CFO and CRO joint escalation
Exit strategy readiness score	BCM assessments	>80%	60-80%	<60%	BCM lead to operational resilience committee

 

Aligning DORA with ISO 27001 and NIST CSF 2.0

 

Cross-referencing these frameworks strengthens the control evidence behind your DORA Third-Party Risk Register.

 

Mapping existing controls into your DORA Third-Party Risk Register avoids duplicated effort and accelerates compliance for certified organizations.

 

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.

 

DORA Requirement	ISO 27001:2022 Control	NIST CSF 2.0 Function	Gap Action Required
Article 28: Register of Information	A.5.19-5.22 (Supplier relationships)	GV.SC (Supply Chain)	Build RoI template with ESA fields; automate data feeds
Article 29: Preliminary assessment	A.5.19 (Supplier assessment)	ID.SC-3 (Assessment)	Add DORA-specific criteria to vendor onboarding checklist
Article 30: Key contractual provisions	A.5.20 (Contract clauses)	GV.SC-5 (Agreements)	Embed mandatory DORA clauses in contract templates
Article 31: Concentration risk	No direct equivalent	GV.SC-7 (Concentration)	Develop concentration risk model and thresholds
Article 32: Exit strategies	A.5.21 (Transition planning)	PR.IP (Protection processes)	Draft exit playbooks for each critical provider
Resilience testing (Art. 26-27)	A.8.8 (Vulnerability management)	PR.PT / DE.CM (Testing)	Extend pen-test scope to include provider interfaces

 

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

 

Following these steps in order produces a DORA Third-Party Risk Register that is both complete and submission-ready.

 

Building a defensible DORA Third-Party Risk Register follows six sequential steps, each producing evidence that maps directly to the ESA Register of Information.

 

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

 

A complete inventory is the foundation of an accurate DORA Third-Party Risk Register, so capture every ICT provider before moving on.

 

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

 

Linking contracts to critical functions inside the DORA Third-Party Risk Register clarifies which provider failures would disrupt essential services.

 

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

 

Completing every mandatory field keeps your DORA Third-Party Risk Register aligned with the ESA Register of Information schema.

 

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

 

Apply your scoring model consistently across the DORA Third-Party Risk Register to keep ratings comparable and defensible.

 

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

 

Wiring KRIs into the DORA Third-Party Risk Register turns it into a living monitoring tool rather than a static document.

 

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

 

Final validation confirms the DORA Third-Party Risk Register is complete, internally consistent, and ready for competent-authority submission.

 

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

 

This phased roadmap converts your DORA Third-Party Risk Register from a draft into a validated, submission-ready dataset within 90 days.

 

This 90-day roadmap turns the DORA Third-Party Risk Register from a planning concept into a validated, submission-ready dataset.

 

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.

 

Phase	Actions	Deliverables	Success Metrics
Days 1-30: Discovery & Inventory	Complete ICT provider inventory across all business units. Cross-reference procurement, IT asset, and cloud subscription data. Identify intra-group providers. Map providers to critical functions using existing BIA outputs.	Deduplicated provider master list. Provider-to-function mapping. Gap analysis of BIA coverage.	100% of known providers inventoried. >90% of critical functions mapped to providers. BIA gaps documented with remediation owners.
Days 31-60: Population & Scoring	Populate ESA tables B_01 through B_07 with mandatory fields. Validate LEIs via GLEIF. Request sub-outsourcing disclosures from providers. Apply 5×5 weighted risk scoring to each provider-contract pair. Draft exit strategies for critical providers.	Populated RoI template (all 15 tables). Completed risk score for each provider. Exit strategy drafts for top-5 critical providers.	>95% of mandatory fields populated. All critical providers scored. Exit strategies reviewed by BCM lead and legal.
Days 61-90: Validation & Go-Live	Run ESA validation rules. Remediate data quality issues. Connect KRI data feeds to monitoring dashboard. Conduct dry-run submission to competent authority portal. Train 1st and 2nd line teams on register maintenance procedures.	Validated RoI ready for submission. Live KRI dashboard with automated feeds. Training completion records. Dry-run submission confirmation.	Zero critical validation errors. KRI dashboard operational with real-time data. 100% of designated staff trained. Dry-run submitted on schedule.

 

DORA Third-Party Risk Register: Questions Practitioners Ask

The questions below address the practical concerns teams raise most often when standing up a DORA Third-Party Risk Register for the first time.

What is a DORA third-party risk register?

Put simply, the DORA Third-Party Risk Register consolidates ICT provider, contract, and risk data into one auditable record.

In short, a DORA Third-Party Risk Register is the central record EU financial entities use to track every ICT provider relationship in line with the regulation.

A DORA third-party risk register is the Register of Information (RoI) that Article 28 of the Digital Operational Resilience Act requires every EU-regulated financial entity to maintain for all ICT third-party contractual arrangements.

It records provider identity, contracts, criticality, data locations, and sub-outsourcing chains, doubling as an internal monitoring tool and a supervisory data source.

What does DORA Article 28 require for the Register of Information?

These Article 28 obligations translate directly into specific columns within your DORA Third-Party Risk Register.

Article 28 requires financial entities to maintain and update a register of all contractual arrangements with ICT third-party providers, at entity, sub-consolidated, and consolidated levels. The register serves three uses: internal monitoring, supervisory reporting to competent authorities, and the ESAs’ designation of critical ICT providers. It must be kept current and reported annually, not filed once.

What is the deadline for the DORA Register of Information?

Meeting that deadline means your DORA Third-Party Risk Register must be populated and validated well in advance of the submission window.

DORA became enforceable on 17 January 2025, and competent authorities must forward completed Register of Information submissions to the European Supervisory Authorities by 31 March 2026. Most entities work backward from that date, setting an internal deadline around 30 days earlier for validation and remediation. Deloitte found 46% of firms rank the RoI as DORA’s hardest component.

How many tables and fields are in the DORA Register of Information?

Each of those tables maps to a defined section of the DORA Third-Party Risk Register.

Commission Implementing Regulation (EU) 2024/2956 sets the ESA template as 15 interlinked tables with more than 60 mandatory fields. It is a relational data model, not a flat spreadsheet: tables link through primary and foreign keys so regulators can trace relationships from entity governance to individual subcontractors. Conditional fields activate for contracts supporting critical or important functions.

Who must maintain a DORA third-party risk register?

DORA applies to 21 categories of financial entity, including banks, insurers, investment firms, payment and e-money institutions, and crypto-asset service providers.

The register must also list ICT intra-group providers, so shared-services centres within a financial group appear as providers. Groups maintain it at entity, sub-consolidated, and consolidated levels depending on their structure.

How do you score third-party risk in the DORA register?

Map each provider-contract pair onto a 5×5 weighted risk matrix. The template weights business impact at 30%, substitutability and data sensitivity at 20% each, and concentration and subcontracting depth at 15% each.

The composite score sets oversight intensity: 1.0-2.0 gets standard annual review, 2.1-3.5 enhanced quarterly review, and above 3.5 monthly oversight with board reporting.

Does ISO 27001 certification help with the DORA third-party risk register?

Largely, yes. Research cited in the guide suggests ISO 27001-certified entities already cover roughly 80% of DORA’s requirements through existing information-security controls.

The remaining gaps sit in three areas: prescriptive contractual clauses for ICT providers, mandatory exit strategies, and structured sub-outsourcing oversight. Mapping DORA to existing ISO 27001 and NIST CSF controls avoids duplicated effort.

What are the penalties for an incomplete DORA Register of Information?

Penalties are significant. Financial entities can face fines of up to 2% of annual worldwide turnover, while designated critical ICT providers face up to 1% of average daily worldwide turnover. Beyond fines, an inaccurate register invites heightened supervisory scrutiny, especially where the entity contracts with one of the 19 critical providers now under direct EU oversight.

Common Pitfalls and How to Avoid Them

 

Even experienced teams stumble when assembling a DORA Third-Party Risk Register; the table below maps the most frequent mistakes to concrete fixes.

 

Pitfall	Root Cause	Remedy
Treating the RoI as a one-off compliance exercise	Register ownership sits with a project team that disbands after initial submission	Assign permanent register ownership to 2nd line risk function. Embed quarterly update cycles in the risk management calendar.
Incomplete sub-outsourcing chain visibility	Providers resist disclosing subcontractor details or clauses lack disclosure obligations	Embed mandatory sub-outsourcing disclosure clauses in all new and renewed contracts. Use Article 29 preliminary assessments to verify chains.
Misclassifying critical vs. important functions	BIA not updated since pre-DORA period, or criticality criteria do not align with DORA definitions	Refresh BIA using DORA-specific criticality criteria. Cross-reference against impact tolerance assessments under operational resilience requirements.
Flat-file register that breaks relational integrity	Teams build RoI in a single Excel tab without primary-foreign key relationships	Use the 15-table relational structure from the ESA ITS. Implement data validation rules and referential integrity checks before every submission.
Ignoring concentration risk until audit findings surface	No systematic process for aggregating spend and dependency across providers	Build an automated concentration risk model that pulls live data from finance systems. Set thresholds at 15% (amber) and 25% (red) of ICT budget.
Missing the 31 March 2026 submission window	Late start, underestimation of data collection effort, or unclear internal deadlines	Work backward from the competent authority submission date. Set internal deadline 30 days ahead of regulatory deadline to allow for remediation.
Disconnecting the register from ongoing risk monitoring	Register data is not linked to KRIs, incident feeds, or vendor performance dashboards	Integrate register fields with your KRI dashboard. Automate alerts for SLA breaches, contract renewals, and score threshold crossings.

 

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.

Treating your DORA Third-Party Risk Register as a living asset, rather than a one-off compliance exercise, keeps your organization audit-ready as supervisory expectations evolve.

 

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