TPRM for DORA: Registers, Criticality Assessment, and Exit Strategies | FortisEU

DORA does not treat third-party risk as a compliance checkbox. It treats it as an operational discipline that must be maintained continuously, documented precisely, and stress-tested regularly. For financial entities building or upgrading their ICT third-party risk management programme, the regulatory text is specific enough to serve as an implementation specification — if you read it carefully.

This guide walks through the four operational pillars of DORA TPRM: the register of information required by Article 28(3), the criticality assessment methodology that drives tiering and oversight intensity, the exit strategy requirements under Article 28(8) that most organisations currently fail, and the contractual provisions mandated by Article 30 that transform vendor agreements from commercial documents into operational governance instruments. Each section translates the regulatory requirement into practical implementation guidance.

The Register of Information: Article 28(3)

Article 28(3) requires financial entities to "maintain and keep up to date at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers."

Two words define the obligation: "maintain" and "keep up to date." A register compiled during an annual TPRM cycle and reviewed twelve months later does not satisfy this requirement. The register must reflect the current state of your ICT third-party relationships at all times.

What the register must contain. The ESA implementing technical standards specify the register's content in granular detail. At minimum, each entry must include:

Provider identification (name, LEI where available, registration jurisdiction)
Contract identification (reference number, effective date, termination date, renewal terms)
Service description (what the provider delivers, which ICT systems or processes it supports)
Data processing scope (types of data processed, processing locations, data residency jurisdiction)
Sub-contractor chain (identification of sub-contractors that the provider uses to deliver the service, the scope of sub-contracted services)
Criticality classification (whether the service supports a critical or important function)
Substitutability assessment (how easily the provider could be replaced, availability of alternatives)
The entity's assessment of concentration risk associated with this arrangement

This is not a spreadsheet with vendor names and contract values. It is a multi-dimensional data asset that requires input from procurement, IT, risk, legal, and business operations. Each function holds a piece of the complete picture, and the register must aggregate and reconcile those pieces into a coherent, current, defensible record.

How to build it. Start with what you have. Most financial entities maintain some form of vendor inventory, typically in procurement systems, contract management platforms, or spreadsheets. Map your existing data against the ESA template to identify gaps. Common gaps include: LEI identification for smaller providers, complete sub-contractor chain documentation, data processing location detail beyond "EU" or "US," and formal substitutability assessments.

Close the gaps through a structured data collection programme. For critical providers, this may require direct engagement — requesting sub-contractor disclosures, data processing location specifics, and service dependency documentation that the provider may not have previously shared. For non-critical providers, a simplified data request focused on the essential register fields is proportionate.

How to maintain it. The register must be updated when contractual arrangements change: new contracts, contract amendments, scope changes, terminations, renewals. It must also be updated when the underlying reality changes: a provider changes its sub-contractors, relocates its data processing, or alters the services it delivers. These updates require event-driven triggers, not calendar-driven reviews.

Build the following triggers into your operational processes:

Procurement events: Every new ICT service contract or contract amendment triggers a register update before or concurrent with contract execution.
Provider notifications: Contractual provisions (per Article 30) should require providers to notify you of sub-contractor changes, data processing location changes, and material service modifications. Each notification triggers a register update.
Internal events: When your organisation deploys a new system on an existing provider's infrastructure, changes the scope of data processed by a provider, or identifies a new dependency on an existing provider, the register must be updated.
Periodic reconciliation: Quarterly, reconcile the register against your IT asset inventory, your contract management system, and your financial records to identify unregistered arrangements or stale entries.

The register is not a reporting deliverable. It is the operational backbone of your entire DORA TPRM programme. Every other obligation — incident response, concentration risk assessment, exit strategy maintenance, supervisory reporting — depends on the register being current and complete.

Criticality Assessment: Beyond Binary Classification

DORA distinguishes between ICT services that support "critical or important functions" and those that do not. This distinction drives the intensity of oversight, the contractual provisions required, and the supervisory attention your arrangements receive. Getting the criticality classification right is operationally significant.

What makes a function critical or important. DORA Article 3(22) defines a critical or important function as "a function the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation."

In practice, this definition requires a business impact analysis that maps each ICT service to the business functions it supports and assesses the impact of service disruption or failure. A CRM system that supports relationship management may not be critical. The same CRM system, if it also processes regulatory reporting data or supports client onboarding workflows that are subject to regulatory timelines, may qualify.

Building a criticality assessment methodology. A robust methodology evaluates four dimensions:

Business impact. What happens if this ICT service is unavailable for 4 hours? 24 hours? 7 days? Map the impact to revenue, regulatory compliance, client service, and operational continuity. If disruption at any duration materially impairs a critical business function, the service is supporting a critical or important function.
Data sensitivity. What types of data does the provider process? Client personal data, financial transaction data, regulatory reporting data, and authentication credentials elevate criticality regardless of service continuity impact. A data breach at a provider processing sensitive data creates regulatory and reputational exposure that may exceed the impact of service disruption.
Substitutability. How quickly could the entity migrate to an alternative provider? What are the switching costs? Are there viable alternatives in the market? A service with no realistic alternatives — due to technical lock-in, contractual constraints, or market concentration — carries higher criticality because the entity's options in a crisis are limited.
Concentration impact. Does this provider also deliver other services to the entity? Do other critical services depend on the same underlying infrastructure? A provider that is individually non-critical but that shares infrastructure with three critical services may contribute to concentration risk that elevates the overall criticality assessment.

The output is not just a binary critical/non-critical classification. It is a risk-weighted profile that informs the intensity of monitoring, the frequency of assessment, the depth of exit planning, and the contractual provisions required.

Maintaining the assessment. Criticality is not static. A service that was non-critical when adopted may become critical as the entity's dependency deepens. A change in the entity's business model, regulatory obligations, or IT architecture can shift criticality classifications. Review criticality assessments semi-annually for critical providers and annually for all others, and reassess whenever a material change occurs in the service scope, the entity's dependency, or the provider's risk profile.

Exit Strategies: Article 28(8)

Article 28(8) requires financial entities to "put in place exit strategies, taking into account risks that may emerge at the level of the ICT third-party service provider, in particular a possible failure of the latter, a deterioration of the quality of the ICT services provided, any business disruption due to inappropriate or failed provision of ICT services or any material risk arising in relation to the appropriate and continuous deployment of the respective ICT service."

Most organisations have exit strategy documents. Most of those documents would fail supervisory scrutiny because they describe aspirational exit processes rather than validated, executable plans.

What a credible exit strategy contains. A DORA-grade exit strategy for a critical ICT service provider must address:

Alternative providers. Identification of specific alternative providers that could deliver the service, including an assessment of their capability, capacity, and willingness to onboard the entity. "We would migrate to another cloud provider" is not a strategy. "We have evaluated Provider X and Provider Y, both of which can deliver the service within our requirements, and we have initiated preliminary technical discussions with Provider X" is a strategy.
Migration timeline. A realistic estimate of the time required to migrate from the current provider to the alternative, including data migration, system reconfiguration, testing, and parallel operation periods. This estimate should be based on technical assessment, not optimism. For complex services, migration timelines are typically measured in months, not weeks.
Data portability. Specific mechanisms for extracting data from the current provider in usable formats. This includes API-based data export capabilities, contractual data return obligations, data format specifications, and the entity's capacity to ingest the returned data into alternative systems.
Transition governance. Who manages the exit process? What are the decision triggers that initiate an exit? What approvals are required? What is the communication plan for clients, regulators, and internal stakeholders? The exit strategy should define roles, responsibilities, and escalation paths as clearly as an incident response plan.
Cost estimate. The financial cost of executing the exit, including migration costs, parallel operation costs, potential performance degradation costs, and any contractual termination fees. The management body should understand the cost of exit before they need to make the decision.
Service continuity during transition. How will the entity maintain service delivery to its clients and regulatory compliance during the migration period? What degraded service levels are acceptable? What are the client communication obligations?

Testing exit strategies. An exit strategy that has never been tested is a document, not a plan. For critical providers, conduct periodic exit readiness assessments that validate the key assumptions: Are the alternative providers still viable? Is the migration timeline still realistic given current system architecture? Has the data portability mechanism been tested? Has the internal capacity for migration execution been maintained?

These assessments do not require executing the full exit. They require validating the preconditions. A tabletop exercise that walks through the exit scenario with the relevant stakeholders — IT, procurement, risk, legal, and business operations — can identify stale assumptions and capacity gaps before they matter.

Contractual Provisions: Article 30

Article 30 transforms vendor contracts from commercial agreements into operational governance instruments. The mandatory provisions create ongoing obligations that must be monitored, exercised, and maintained — not just included in the contract and forgotten.

Service level descriptions (Art. 30(2)(a)). Contracts must include service level descriptions that are "quantitative and qualitative" and that enable the entity to monitor the provider's performance. Vague service levels ("best efforts," "commercially reasonable") are insufficient. Specific, measurable, time-bound service levels with defined consequences for breach are required. Build monitoring mechanisms for each service level and review performance data at least quarterly.

Data processing locations (Art. 30(2)(b)). The contract must specify where data is processed and stored, and require the provider to notify the entity in advance of any changes to processing locations. This provision intersects with GDPR data transfer requirements and with any jurisdictional restrictions in the entity's own regulatory framework. Monitor provider disclosures and update your register when locations change.

Incident notification (Art. 30(2)(e)). The provider must notify the entity of ICT-related incidents that affect the services provided. The notification timeline should align with your own incident reporting obligations under DORA Article 19 — which requires an early warning to the competent authority within four hours of classifying a major ICT-related incident. If your provider's notification reaches you too late for you to classify and report within the four-hour window, the contractual provision is operationally inadequate.

Audit rights (Art. 30(2)(f)). The entity must have the right to audit the provider's ICT risk management arrangements, either directly or through pooled audits and third-party certifications. This right must be exercisable — not just contractually stated. Plan audit activities for critical providers on a defined schedule and ensure you have the internal or external capacity to conduct meaningful audits.

Exit provisions (Art. 30(2)(g)). The contract must include "adequate transition periods and obligations to the ICT third-party service provider to cooperate with the migration." These provisions must be consistent with your exit strategy — if your exit strategy assumes a six-month migration period, the contract must provide for at least six months of transition support from the provider.

Participation in resilience testing (Art. 30(3)). For critical or important functions, the contract must ensure the provider participates in the entity's digital operational resilience testing, including threat-led penetration testing (TLPT) where applicable. This is not a standard contractual provision and may require negotiation with providers who are unfamiliar with DORA's testing requirements.

Building Your DORA TPRM Programme: Operational Sequence

For financial entities building or upgrading their TPRM programme for DORA, the following operational sequence provides a practical implementation pathway.

Phase 1: Foundation (Months 1-2). Complete the register of information. Identify all ICT third-party service provider relationships, populate the ESA template fields, and classify each arrangement's criticality. Accept that the initial register will have gaps — completeness over perfection. Identify the top ten concentration risk exposures.

Phase 2: Governance design (Months 2-3). Define event triggers for register updates. Design the criticality assessment methodology. Establish the quarterly review cadence for critical providers. Assign register ownership and define the RACI for each data field. Build the reporting framework for the management body.

Phase 3: Contractual remediation (Months 3-6). Review contracts with critical providers against Article 30 requirements. Identify gaps in service level definitions, incident notification provisions, audit rights, exit provisions, and resilience testing participation. Prioritise remediation based on criticality and contract renewal timelines. Negotiate amendments with providers — this is typically the longest and most resource-intensive phase.

Phase 4: Exit strategy development (Months 4-6). Develop exit strategies for all critical providers. Identify alternatives, estimate migration timelines and costs, validate data portability mechanisms, and define transition governance. Conduct a tabletop exit readiness assessment for the top three critical providers.

Phase 5: Operationalisation (Month 6 onward). Implement continuous monitoring signals for Tier 1 providers. Activate event-driven assessment triggers. Conduct the first quarterly deep review. Brief the management body on the programme's operating model and the current state of the register.

This timeline is aggressive but achievable for entities that assign dedicated resources and have management body sponsorship. For entities that are starting from a mature TPRM baseline, the timeline compresses. For those starting from a spreadsheet-based annual assessment model, additional time may be needed for the contractual remediation phase.

The programme's integration with your broader compliance automation and risk management capabilities determines its long-term sustainability. A DORA TPRM programme that operates as a standalone project will degrade when project resources are reallocated. One that is embedded in the entity's operational risk management infrastructure — with automated register updates, integrated monitoring signals, and workflow-driven escalation — will sustain through the programme's lifecycle.

Key Takeaways

The DORA register of information under Article 28(3) is not a reporting exercise — it is the operational backbone of your entire TPRM programme, requiring continuous maintenance with event-driven updates whenever contracts, services, sub-contractors, or data processing arrangements change.
Criticality assessment must evaluate four dimensions (business impact, data sensitivity, substitutability, and concentration impact) and must be maintained dynamically, not classified once and filed — a service's criticality can shift as your dependency deepens or your business model evolves.
Exit strategies fail supervisory scrutiny when they describe aspirations rather than validated plans — a credible exit strategy names specific alternative providers, estimates realistic migration timelines based on technical assessment, validates data portability mechanisms, and has been tested through tabletop exercises.
Article 30 contractual provisions create ongoing operational obligations (service level monitoring, incident notification exercise, audit right usage, exit provision maintenance) that must be actively managed, not just inserted into contracts and forgotten.
Build the programme in sequence: register first, governance design second, contractual remediation third, exit strategies fourth, operationalisation ongoing — assign dedicated resources and secure management body sponsorship, because supervisory authorities will assess programme maturity during their first engagement.