Due Diligence Before Contracting

Due diligence before contracting is the work of checking, before signature, whether a provider can support the particular service that will depend on it. Under DORA, that check is not a generic vendor questionnaire completed for the file. It examines the provider's security and resilience arrangements, its use of subcontractors, where relevant data and operations sit, and whether the provider will accept the audit, reporting and cooperation terms the entity needs. The aim is to surface problems while they can still change the decision, the price, the contract, or the design of the dependency, rather than discovering them after the service is live.

A cloud hosting example illustrates the matching problem. A provider may hold an assurance report for its data centre estate, yet the service in question may run on one platform within that estate, supported by a subcontracted monitoring tool. Due diligence that accepts the estate-level report without asking which systems, locations and subcontractors sit behind this service has not yet answered the relevant question. Matching means tracing the service through the provider's arrangements and asking for evidence at that level of detail. Where evidence at that level is unavailable, the gap itself is a finding, and it should influence the decision rather than being noted and forgotten.

The areas examined tend to follow the dependency rather than a fixed checklist. Security arrangements and incident history in broad terms, resilience and recovery capability, the identity and role of subcontractors, data location and access, and the provider's ability to support audit and regulatory access are all commonly relevant. Financial resilience in broad terms also matters, because a provider under strain may cut investment in exactly the controls the entity relies on. The point is not to demand perfection in every area. It is to understand where the provider is strong, where it is thin, and whether the thin areas touch the service that matters.

Questionnaires and third-party reports are useful starting points, but they carry limits that due diligence should acknowledge. A questionnaire records what a provider says about itself, and a report records what an assessor observed for a defined scope and period. Neither one proves that controls operate effectively for this service today. Follow-up questions, clarification of scope, and, where the dependency justifies it, direct discussion or independent testing can narrow that gap. The discipline is to treat every piece of evidence as answering a specific question, and to keep asking until the questions that matter for this service have answers.

Due diligence works best when the people who will live with the dependency are involved before signature, not consulted afterwards. The service owner can judge whether a limitation matters for customers. Technology and security specialists can judge whether an arrangement is sound. Legal and risk specialists can judge whether contract terms and risk appetite align. Procurement can judge commercial terms, but commercial agreement alone does not settle a risk question. Bringing those perspectives together before signature is slower than a purely commercial process, yet it avoids the costlier outcome of signing a contract that the entity later finds it cannot oversee or exit.

A problem found in due diligence does not always mean rejection. It may lead to a different design, such as limiting the data shared or keeping a fallback process. It may lead to stronger contract terms, such as enhanced reporting or a right to audit a particular system. It may lead to a decision to proceed with eyes open, with the residual concern recorded and monitored. What matters is that the response is deliberate and documented. Proceeding without a response, on the assumption that a problem will not materialise, converts due diligence from a decision tool into a filing exercise, and the file will not help when the problem does materialise.