OperationalResilience.help
The Continuity Desk - important services, kept running
Home / Line 10 - Outsourcing and cloud dependencies / Guide

Outsourcing Due Diligence Records

Due diligence records show why a provider was chosen and what was checked before signing. This guide explains what to examine, what to keep, and when to revisit it.

Published 26 October 2026Checked against the regulation text on 26 October 2026European Union (financial entities in scope of DORA)

The short answer

Outsourcing due diligence records are the evidence that a firm examined a provider before relying on it, and that the examination matched the importance of the service involved. Due diligence covers the provider's capability, resilience arrangements, security posture, financial and organisational stability, sub-provider use, and location of data and operations, insofar as those matters affect the service. DORA's provisions on ICT third party risk expect that examination to happen before contracting and to be proportionate to dependence: a provider supporting a peripheral tool calls for a lighter examination than a provider operating a core service. The record matters because it shows reasoning, not merely collection. A folder of provider brochures, without an assessment of what they mean for a named service, is not due diligence. It is filing.

What capability should be examined?

Capability examination starts with the service, not with the provider's general reputation. The firm asks whether the provider can operate the specific function involved, at the scale and complexity the service requires, and under disruption conditions as well as normal conditions. That question covers technical architecture, staffing, support arrangements, and the provider's own resilience and testing practices. It also covers change: whether the provider can introduce updates without disrupting the service, and how it handles incidents affecting other customers that share the same platform. A provider that performs well for a small pilot may not perform the same way when the service is used widely, and due diligence should test that scaling assumption rather than assume it.

How should assurance documents be read?

Security and resilience evidence needs interpretation, not acceptance at face value. Certifications, audit reports, and assurance statements can be useful, but they describe a scope, a period, and a set of controls that may not match the service in question. A firm should ask what was in scope, what was excluded, what findings arose, and how they were addressed, and should record its own judgement on those points. A lending platform illustration helps: a provider assurance covering its data centre operations says little about the resilience of a lending decision workflow that also depends on external data feeds and a separate fraud service. Due diligence that stops at the assurance document has examined a building, not a service.

What about sub-providers and location?

Sub-providers, location, and concentration belong in due diligence from the start, because they are difficult to retrofit later. The firm should understand which parts of the service the provider itself sub-contracts, where important data will be stored and accessed, and whether the provider is also used for other important services, creating concentration. It should also understand the provider's own dependence on other parties, such as hosting or network providers, since a failure there can affect the firm's service without the direct provider being at fault. These questions do not require exhaustive mapping of every minor component. They require a proportionate picture of the chain that matters to the service, recorded with its gaps acknowledged rather than hidden.

What should the record contain?

The record itself should be structured so that it can be revisited and challenged. A useful record names the service, the provider function, the questions asked, the evidence obtained, the gaps or concerns found, the judgement reached, and the person or forum that approved the arrangement. It also notes conditions, such as additional monitoring, contract terms, or a later review triggered by a change. That structure turns due diligence into a living input to governance and risk assessment, rather than a hurdle cleared at procurement and forgotten. When a provider changes, a service expands, or an incident reveals a weakness, the record gives the firm a starting point for asking what was known, what was assumed, and what has changed.

When should due diligence be revisited?

Revisiting due diligence is part of the discipline, not a sign that the first examination failed. Providers change ownership, strategy, architecture, and sub-provider arrangements. Services grow in importance, acquire new users, or become connected to other services. A periodic review, and a review triggered by material change, keeps the firm's understanding aligned with reality. The review need not repeat the full original examination where nothing material has changed, but it should confirm that the original judgement still holds, or record why it no longer does. A due diligence record that is never revisited will eventually describe a provider that no longer exists in the form examined, supporting a service that has moved on without it.

Primary sources on the record

Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.

Follow the service map

Line 10 - Outsourcing and cloud dependencies Outsourcing and Cloud Dependencies Outsourcing does not move accountability away from the firm owning the service. This guide explains how DORA treats cloud and outsourcer dependence, tolerance, recovery, and evidence. Line 10 - Outsourcing and cloud dependencies Cloud Shared Responsibility Explained Shared responsibility divides cloud work between provider and firm, but the boundary is rarely where marketing draws it. This guide explains how to map it for a specific service. Line 10 - Outsourcing and cloud dependencies Outsourcing Risk Assessments Risk assessment asks what could harm a service through a provider, and what would limit that harm. This guide explains how to assess outsourcing risk in service terms, not vendor terms.