DORA and ICT third-party risk: what financial firms must now prove
DORA's third-party risk requirements are not about having the right contracts in place. They are about being able to prove, on demand, that your vendor relationships are understood, monitored, and controlled. Most firms are not ready for that question.
This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.
The audit question most firms are not prepared for
The Digital Operational Resilience Act (DORA) entered into force across EU financial services on 17 January 2025. Supervisory assessments are now underway. When a national competent authority examines a firm’s ICT third-party risk posture, the question it is asking is not whether the firm has vendor contracts. It is whether the firm can demonstrate, with documented evidence, that it understands what each critical vendor does, what would happen if that vendor failed, and what controls exist to detect and respond to a disruption before it becomes a systemic event.
Most financial firms can produce a vendor list. Fewer can produce a register that maps each vendor to the functions it supports, the data it can access, the substitutability of the service, and the last date on which the relationship was formally reviewed. That gap, between having vendors and understanding vendor exposure, is where DORA’s third-party requirements create the most immediate compliance pressure.
This article covers what DORA actually requires firms to prove about their ICT third-party relationships, where the documentation burden is heaviest, and why the firms most likely to struggle are not the ones with the most vendors but the ones that have not treated vendor oversight as a continuous function rather than a periodic exercise. For a full overview of DORA’s five pillars and what compliance looks like in practice, see the DORA compliance checklist for financial entities.
What DORA means by third-party ICT risk
DORA defines ICT third-party service providers broadly. The regulation covers any entity that provides ICT services to a financial firm, including cloud infrastructure providers, software vendors, data providers, managed service providers, and outsourced operational functions with a technology component. The scope is wide enough that most firms of any meaningful size will have dozens of entities in scope, and larger institutions will have hundreds.
The regulation creates two tiers of obligation. The first applies to all ICT third-party providers and covers contractual requirements, monitoring obligations, and exit planning. The second applies specifically to critical ICT third-party providers (CTPPs), a designation that the European Supervisory Authorities (ESAs) assign directly to providers whose failure would have systemic implications across the financial sector. Firms do not designate their own critical providers. The ESAs do. But firms are required to identify, from their own vendor population, which providers they treat as critical to their own operations, and to apply proportionate oversight to those relationships regardless of whether formal CTPP designation applies.
The distinction matters because firms sometimes interpret the CTPP framework as transferring responsibility upward. If the ESAs have not designated a provider as critical, the reasoning goes, the firm’s obligations are lighter. DORA does not support that reading. Article 28 of Regulation (EU) 2022/2554 requires firms to maintain a register of all ICT third-party service providers, identify which are critical to the firm’s own operations, and apply a risk-based oversight programme to those relationships. The ESA designation process operates in parallel, not as a substitute for firm-level risk assessment.
The register requirement and what it actually demands
The ICT third-party provider register is one of the most practically demanding elements of DORA for firms that have not previously maintained structured vendor oversight. The register is not a spreadsheet of supplier names and contact details. Under the implementing technical standards developed by the Joint Committee of the ESAs pursuant to Article 28(9) of Regulation (EU) 2022/2554, the register must capture a defined set of information for each provider.
For each ICT service, firms must document the nature of the service, whether it supports a critical or important function, the data classification involved, the contractual start and end dates, the applicable law and jurisdiction, the location from which the service is delivered, and the subcontractors used by the provider to deliver the service. That last point is where the register requirement becomes genuinely difficult for most organisations. Supply chain visibility below the first tier of vendors is sparse in most firms. DORA requires it to be documented.
The register must also be updated when material changes occur. A vendor extending its own subcontracting arrangements, a provider shifting data processing to a new jurisdiction, a contract renewal that changes the scope of the service: each of these triggers an update obligation. A static register compiled at a point in time and not maintained as vendor relationships evolve will fail an audit even if it was accurate when it was created.
The practical implication is that maintaining the register is a continuous function, not a one-time compliance project. Firms that treated initial DORA implementation as a documentation sprint rather than an operational change are likely to find their registers degrading in accuracy from the moment they were completed.
Contractual requirements: what vendors must now accept
DORA specifies minimum contractual requirements for ICT third-party arrangements. These are not aspirational standards. They are mandatory clauses that must be present in contracts with providers supporting critical or important functions. Firms negotiating or renewing contracts that do not meet these requirements are in breach of their DORA obligations regardless of how well their internal governance is structured.
The minimum requirements include: a clear description of the ICT services and the service levels that apply to them; provisions requiring the provider to cooperate with audits and inspections by the firm, by competent authorities, and by the firm’s auditors; termination rights that allow the firm to exit the relationship without operational disruption in specified circumstances; and requirements for the provider to maintain and test business continuity plans for the services it provides to the firm.
The audit and inspection clause is the one that has generated the most friction in vendor negotiations. Established cloud infrastructure providers and large software vendors have historically resisted granting individual financial firm clients audit rights over their facilities and operations. DORA does not resolve this tension, but it does shift the regulatory liability firmly onto the financial firm. If a provider refuses to accept contractual audit rights and the firm continues the relationship, the firm is non-compliant. Regulators have signalled that the expectation is for firms to have renegotiated or exited non-compliant arrangements by the enforcement date.
For large providers, industry-standard audit reports such as ISAE 3402 and SOC 2 attestations are frequently offered as a substitute for direct audit access. DORA permits this approach for some purposes but not all. Where competent authorities require access to a provider’s premises or systems as part of a supervisory investigation, the firm is required to ensure that access is contractually available. A third-party attestation is not a substitute for that right in a supervisory context.
Concentration risk and what firms must document about it
One of the less discussed dimensions of DORA’s third-party requirements is the concentration risk obligation. Firms are required to assess not only their individual vendor relationships but the degree to which their operational resilience depends on a small number of providers, or on providers that are themselves dependent on a small number of upstream suppliers.
The concentration risk concern operates at two levels. At the firm level, heavy reliance on a single cloud provider for infrastructure, a single data vendor for critical inputs, or a single managed service provider for a core function creates a dependency that DORA expects to be documented, assessed, and subject to a proportionate mitigation strategy. At the sector level, the same dependency structure replicated across many firms creates systemic risk, which is the primary reason the CTPP designation framework exists.
Firms are required to document their concentration exposures and to consider what would happen if a key provider became unavailable, whether through operational failure, financial distress, regulatory action, or geopolitical disruption. Exit plans are a mandatory element of this assessment. The exit plan must demonstrate that the firm could transition the affected service to an alternative provider, or bring it in-house, within a timeframe that does not compromise its ability to meet its regulatory obligations and serve its clients.
The credibility of an exit plan is an area where supervisory scrutiny is likely to intensify. An exit plan that has not been reviewed by the team that would execute it, that assumes transition timelines that are not supported by evidence, or that was written to satisfy a documentation requirement rather than to function as an operational guide, is unlikely to satisfy a competent authority conducting a substantive review.
Where monitoring obligations are most frequently missed
DORA requires ongoing monitoring of ICT third-party providers, not only at the point of contract signature. The monitoring obligation covers the provider’s financial health, its compliance with the contractual terms, the actual service levels delivered against the agreed standards, and any material changes to the provider’s own operating environment that could affect the service.
For firms with large vendor populations, continuous monitoring across all providers is operationally demanding. DORA accommodates a risk-based approach: the intensity of monitoring should be proportionate to the criticality of the function the provider supports. Providers supporting critical or important functions require more intensive monitoring than those providing peripheral services.
The monitoring gap that is most commonly identified in DORA readiness assessments is not at the top of the vendor stack, where large and visible relationships tend to receive attention, but in the middle tier. Providers that were originally procured for a limited purpose, have expanded over time into functions of genuine operational importance, and have never been reclassified to reflect that expansion tend to sit in a monitoring blind spot. The register requirement is partly designed to surface this problem, because a register that forces documentation of which functions each provider supports will reveal, if it is maintained honestly, that the middle tier contains more critical dependencies than the firm had previously recognised.
What supervisors are likely to examine first
DORA enforcement is conducted by national competent authorities rather than directly by the ESAs, except in the case of designated CTPPs where the ESAs have direct oversight authority. The supervisory approach varies across member states, but the areas that have been identified as priorities in early assessments follow a consistent pattern.
Register completeness and currency is the first examination point for most supervisory reviews. A register that is incomplete, that does not reflect the current state of vendor relationships, or that cannot be updated in response to examiner questions is a significant finding regardless of how well-developed other elements of the firm’s DORA programme are. The register is the foundation on which all other third-party risk management activities rest. If the foundation cannot be demonstrated, the superstructure is not credible.
Contractual compliance is the second focus area. Examiners are reviewing whether contracts with providers supporting critical functions contain the mandatory clauses and whether the firm has documented its approach to providers who declined to accept those clauses. Firms that have not completed a systematic contract review against the DORA minimum requirements are exposed here even if their governance frameworks are otherwise well designed.
Exit planning credibility is the third area of scrutiny. Supervisors are not only checking whether exit plans exist but whether they are plausible. An exit plan that has not been reviewed by the team that would execute it, that relies on transition timelines that are not validated, or that identifies a substitute provider without confirming that the substitute has capacity and willingness to take on the service is likely to be assessed as inadequate.
The continuous monitoring problem
The obligation that DORA places on firms is not a point-in-time compliance requirement. It is a permanent operating obligation. The register must be maintained. Contracts must reflect the current scope of services. Concentration exposures must be reassessed as the vendor landscape changes. Exit plans must be reviewed and updated. Monitoring must continue.
This is structurally different from how most financial firms have historically managed vendor risk. The traditional model is procurement-led: a vendor is assessed at the point of onboarding, a contract is signed, and the relationship then moves to a business owner who may or may not engage with the compliance team again until the contract comes up for renewal. DORA requires a compliance function that operates continuously across the full lifecycle of every vendor relationship that touches an ICT service.
The firms that are best positioned for ongoing DORA compliance are those that have built vendor oversight into their operational rhythm rather than treating it as a compliance project to be completed and filed. That means regular review cycles, defined triggers for out-of-cycle reassessment, clear ownership of the register update function, and monitoring systems that surface changes in the vendor landscape without requiring a manual audit to detect them.
Regulatory intelligence plays a directly relevant role here. The rules that govern what firms must demonstrate about their vendor relationships continue to evolve through the regulatory technical standards and implementing technical standards development process. An obligation that applies from a particular implementation date, a technical standard that clarifies what the register must contain, a supervisory expectation communicated through ESMA or EBA guidance: each of these changes the compliance picture for firms that are trying to stay current. Tracking those changes through manual monitoring of EUR-Lex and ESA publications is feasible for a dedicated team. For smaller firms and compliance professionals without that resource, it is where gaps tend to appear.
For a detailed breakdown of DORA’s full compliance obligations across all five pillars, the DORA compliance checklist for financial entities covers what each pillar requires and what demonstrable compliance looks like in practice. For teams thinking about how to structure regulatory monitoring as a continuous function rather than a periodic exercise, what regulatory horizon scanning actually means for compliance teams covers the methodology question directly.
Forseti, Citium’s EU regulatory intelligence platform, is in development and will monitor DORA-related regulatory developments continuously, anchored to verified official sources. If you want to be kept informed ahead of launch, get in touch.