How to Manage DORA Third Party Risk Properly

A cloud migration, outsourced transaction-monitoring platform or payment-processing partner can become a regulatory exposure long before it becomes an operational failure. To manage DORA third party risk properly, financial entities must show that they understand their ICT dependencies, retain control over critical services and can continue operating when a provider fails, suffers an incident or exits the market.

For fintechs, payment firms, crypto-asset service providers and iGaming groups with regulated EU operations, this is not a procurement exercise. DORA places accountability with the regulated entity. A supplier may host the systems, process the data or provide the security tooling, but it cannot assume the firm's regulatory responsibility.

What DORA requires from third-party arrangements

The Digital Operational Resilience Act applies a lifecycle approach to ICT third-party risk. It covers selection, due diligence, contracting, ongoing monitoring, incident management, testing and termination. The focus is not limited to traditional outsourcing. Cloud infrastructure, software-as-a-service platforms, managed security providers, data analytics tools, custody technology and communications systems can all fall within scope where they support ICT services.

The first question is whether the service supports a critical or important function. This assessment determines the intensity of due diligence, contractual protection, monitoring and exit planning required. A service does not become non-critical simply because it is delivered by a recognised global provider. If its loss would materially impair regulatory compliance, client service, security, financial performance or business continuity, it demands closer control.

DORA also requires financial entities to maintain and update a register of information covering contractual arrangements for ICT services. This is a practical regulatory record, not a static list held by procurement. It must be complete enough to identify dependencies, subcontracting chains, locations and the services supporting critical or important functions.

Start with the business service, not the supplier list

Many firms begin with a vendor spreadsheet and discover too late that it does not show what actually matters. A single business service, such as client onboarding, may rely on identity verification, sanctions screening, case management, cloud hosting, API gateways, communications and document storage. Each provider may appear manageable in isolation, while the combined dependency is substantial.

Map your important business services first. Identify the process owner, systems involved, data flows, legal entity using the service, client impact and recovery requirements. Then connect each service to its ICT providers, including providers used by a direct supplier. This exposes hidden concentration risk and gives management a realistic view of the operating model.

The exercise should also distinguish between group arrangements and local arrangements. A parent company may negotiate a global cloud agreement, but the EU-regulated entity still needs evidence that its own DORA obligations are met. Governance, audit rights, data access and exit provisions must work for the entity subject to supervision, not merely for the wider group.

Assign ownership that can make decisions

Third-party risk fails when responsibility is split between procurement, IT, compliance and legal without a clear decision-maker. Senior management should approve the framework, risk appetite and treatment of material exceptions. Operational owners should assess service performance and dependencies. Compliance, risk, legal and information security should challenge the assessment and verify that required controls are operating.

For critical providers, establish a named relationship owner and a formal review cadence. That owner needs authority to escalate service deterioration, demand remediation and trigger contingency planning. A quarterly supplier meeting without meaningful metrics will not satisfy a regulator after an outage.

Apply proportionate due diligence before signing

DORA does not require every low-risk software subscription to receive the same assessment. It does require a documented, risk-based approach. The depth of diligence should increase with the service's criticality, the sensitivity of data, substitutability, geographical exposure, subcontracting model and concentration risk.

For a critical or important service, the due-diligence file should normally address four areas:

• the provider's financial stability, operational capacity and relevant experience;

• information security, resilience, incident handling and testing arrangements;

• data location, access controls, confidentiality and subcontractor governance; and

• recovery capability, replacement options and the practical feasibility of exit.

Do not treat industry certifications as a complete answer. They can support assurance, but they rarely address your particular service configuration, recovery objectives or regulatory needs. Ask what happens if the provider's key region is unavailable, an API is suspended, a subcontractor fails or a cyber incident affects multiple clients at once.

For early-stage firms, proportionate diligence can be efficient rather than slow. A standardised assessment pack, a criticality methodology and pre-approved contract clauses reduce repeated legal work. The aim is to make a defensible decision before dependency becomes costly to unwind.

Build DORA controls into the contract

A well-written contract is one of the most valuable third-party risk controls, but only if the business can enforce it. Generic supplier terms often limit liability, restrict audit access and permit material subcontracting changes without meaningful notice. Those positions may be commercially understandable, yet they can leave a regulated firm unable to meet its obligations.

Contracts for ICT services should clearly set out the services, service levels, data processing and security requirements, incident notification, cooperation duties, audit and access rights, subcontracting controls, termination rights and exit support. Where a service supports a critical or important function, the agreement should also address testing participation, contingency arrangements, recovery objectives and the locations from which data and services are provided.

The commercial trade-off is real. Large cloud and software providers may not accept bespoke clauses for every customer. In that case, document the gap, assess whether published assurance materials and alternative controls reduce the risk, and escalate any residual risk through the appropriate governance route. A signed contract that falls short of DORA should not be treated as a closed issue simply because the provider has market power.

Monitor performance and incidents throughout the relationship

Third-party oversight must continue after onboarding. For material suppliers, use reporting that links directly to your operational resilience objectives: availability, response times, security events, unresolved vulnerabilities, recovery performance, subcontractor changes and recurring service failures.

Monitoring should be calibrated. A non-critical communications tool may justify annual review. A provider supporting payment execution, client asset protection, trading systems or AML controls may require frequent operational reporting and executive escalation. The relevant test is whether the level of oversight matches the impact of failure.

Incident procedures should include third parties from the outset. Confirm who contacts whom, what information the provider must supply, how evidence is preserved and how the firm will meet its own DORA incident-classification and reporting obligations. Waiting for a supplier's internal investigation to finish may be incompatible with regulatory deadlines.

Test the exit plan before you need it

Exit planning is often reduced to a clause allowing termination. That is insufficient where data migration, technical integration, regulatory records and client-facing processes depend on the provider. A usable exit plan identifies a replacement route, migration responsibilities, data formats, timescales, access during transition, costs and decision triggers.

Not every service needs an immediate substitute. For some specialist providers, a rapid replacement may be unrealistic. The appropriate plan may involve temporary manual controls, internal capacity, phased migration or a secondary provider. What matters is that the plan reflects reality and has been tested to a level proportionate to the risk.

Concentration requires particular attention. Using several suppliers does not remove concentration risk if they all rely on the same hyperscale cloud provider, identity service or data centre region. Consider both direct exposure and common points of failure across the supply chain.

Treat the register of information as a management tool

The register of information is often approached as a reporting burden. Used properly, it is an executive control document. It should enable the firm to identify critical providers, services nearing renewal, contracts lacking required terms, subcontracting exposure and dependencies that could affect continuity.

Keep legal, procurement, security and operational data aligned. If a system is retired, a contract is renewed or a provider introduces a new subcontractor, update the register and reassess the service where necessary. Stale records are especially damaging during supervisory engagement or a live incident because they signal that the firm does not have control of its own operating model.

For firms scaling across several jurisdictions, the fastest route is usually a single DORA framework with entity-level application, rather than separate processes built by each business unit. NUR Legal can help translate that framework into contract remediation, governance documentation and evidence that supports regulator-facing readiness.

A credible DORA programme is not measured by the number of supplier questionnaires completed. It is measured by whether management can explain its dependencies, challenge its providers and keep critical services operating when conditions deteriorate. Build that evidence now, while there is time to negotiate, test and correct weaknesses.