DORA ICT provider due diligence and assurance

What DORA due diligence on ICT providers involves before you sign

Before a financial entity onboards or renews an ICT provider, DORA requires a pre-contract assessment, due diligence on the provider and a check for conflicts of interest under Article 28(4). The entity must also set out in its policy how it keeps assurance over that provider after signing. DORA does not set an official price or duration for this work, so the effort depends on the entity's own size, the number of providers and how much evidence already exists. The first question is whether the service supports a critical or important function, because that classification drives how deep the assessment and contract terms must go. The assessment also weighs the provider's location, whether it subcontracts, and concentration risk, meaning how much of the entity's operations would stall if one provider failed.

The entity owns this decision and the policy behind it. Its management body must approve the outcome, and its staff must be able to explain why a provider was accepted. An implementation partner can help prepare the material: a documented assessment template, a due diligence file for each provider, records of conflict-of-interest declarations, and a subcontracting review that answers the questions in Article 3(1) of Delegated Regulation (EU) 2024/1774. The partner does not judge the provider on the entity's behalf and does not issue any assurance. Assurance comes from the entity's own audits, the provider's internal audit reports, independent audit reports or appropriate third-party certifications, and the policy must say which of these it relies on and why. Ask the partner for a written list of deliverables and the evidence each one produces before work begins.

Confirm early which assurance sources your providers can actually offer, including audit and inspection rights in the contract, because these are hard to add after signature. Under Article 28(5) and (6), the entity should also check that the provider follows appropriate information security standards and that the audit frequency and scope fit the risk. Do not rely on a single source where more than one is appropriate. For provider vulnerability handling, the entity should confirm how the provider reports critical vulnerabilities in time and how the entity tracks open-source libraries used by services that support critical or important functions, as Article 10(2) of Delegated Regulation (EU) 2024/1774 requires. The Regulation (EU) 2022/2554 text on EUR-Lex gives the wording of Article 28 for your legal team to check against your own process.

How the pre-contract assessment and due diligence run

The sequence turns a proposed ICT service into a documented decision: what the service supports, what risks it brings, who the provider is, and whether subcontracting is acceptable, all recorded before any contract is signed.

Scope the service against the critical or important function test
The business owner and the ICT risk function describe the service, the systems it touches and the business process it supports, then decide whether that process is a critical or important function. This is the first question Article 28(4) asks, and the answer determines how deep every later step goes. The output is a short scoping record naming the function, the service, the data and systems involved, and a yes or no on critical or important status, approved by the person accountable for the function. Confirm the reasoning against your own methodology, because the answer drives the contract clauses and testing that follow.
Complete the Article 5 pre-contract risk assessment
The ICT risk function assesses the proposed arrangement across operational, legal, ICT, reputational, data protection, data availability, data location, provider location and ICT concentration risks. Each risk gets a rating, the controls that reduce it, and a residual view that the approver accepts or rejects. Concentration risk should consider whether other critical services already depend on the same provider or platform. The output is a signed risk assessment that the file can show to a supervisor, with open items listed as conditions that must be closed before signature.
Perform due diligence on the provider
The third-party risk team gathers and checks information about the provider's financial standing, governance, security posture, regulatory history, service continuity arrangements and references where they can be verified. This covers the Article 28(4) requirement to perform due diligence and sets the baseline for the assurance work in later steps. Ask for the evidence itself, not a summary of it, and record which sources were used and when. The output is a due diligence file with dated evidence and a finding for each area that either clears the provider or raises a condition.
Check for conflicts of interest
The entity identifies any conflict of interest in the selection and contracting, such as a relationship between the provider and an employee who approves the contract, a shared ownership structure with another supplier, or a group relationship that affects the independence of the assessment. The check is performed by compliance or internal audit and signed off separately from the business approver. The output is a conflict of interest declaration for the deal, with any identified conflicts assessed, mitigated or escalated to the management body.
Decide subcontracting before contracting
Before signature, the entity decides whether the provider may subcontract the service or parts of it. Where subcontracting is permitted for a critical or important function, the file must confirm the provider's ability to select, monitor and identify subcontractors, that the entity keeps equivalent access and inspection rights through the chain, and that the provider has assessed location risk, concentration risk and the impact of a subcontractor failure. The output is a subcontracting decision with the conditions attached, and a list of subcontractors or a rule for approving them, recorded in the contract file.
Record the approval and gate the signature
The file is reviewed as a whole against the scoping record, the risk assessment, the due diligence findings, the conflict check and the subcontracting decision. The accountable approver confirms that open conditions are closed or formally accepted, and the decision is minuted. Procurement should not sign until this gate is passed. The output is a pre-contract approval record that links each earlier output, so an assessor can trace the decision from the service description to the signed contract.

Which information security standards and audit rights the contract needs

Article 28(5) sets the baseline: a financial entity may contract only with an ICT provider that complies with appropriate information security standards. For a critical or important function, the entity must also consider the most up-to-date and highest quality standards available. In practice, the due diligence file should name the specific standards each provider holds or follows, record who checked them and when, and state why each one is considered appropriate for the service in question. Do not assume that a general claim of security maturity meets this test. Ask for the scope of any certificate or attestation, because a certificate covering a different business unit or a different data centre says little about the service being bought. Confirm with counsel which standards the contract should reference by name and how the clause should handle a provider that moves to a newer version during the term.

Article 28(6) turns the contract into a set of working audit rights. The entity must agree a risk-based frequency and scope of audits and inspections, determined in advance, and those audits must follow commonly accepted audit standards. The clause should state who may audit (the entity, its appointed auditor, or competent authorities), what premises, records, personnel and systems are in scope, how much notice is given, and how findings are tracked to closure. A critical or important function usually warrants a more demanding schedule and wider scope than a low-impact service, and the pre-determined plan should be documented so that it can be shown to a supervisor. Where a self-hosted open-source platform is supported under a commercial contract, the entity should check that these rights cover the support provider's access to the environment, not only the software vendor's premises.

Subcontracting is where audit rights most often break down. Under Article 3(1) of Delegated Regulation (EU) 2024/1774, the entity must decide before contracting whether the provider may subcontract, and the provider must show it can select, monitor and identify its subcontractors. The contract should require that subcontractors grant the entity and its auditors equivalent access and inspection rights, and it should cover how those rights are exercised down the chain. Ask providers to name material subcontractors, their locations, and the provider's own assessment of location, concentration and subcontractor failure risk. Confirm the exact wording with counsel, and test it with the auditor before signing, since a right that a subcontractor will not honour is not a right the entity holds.

Which assurance sources the policy must name under Article 6

Article 6 of DORA requires the ICT third-party risk policy to say how assurance on each provider is obtained. The four source types below are the options the Regulation names, and most entities rely on more than one, because each one proves a different slice of the provider's controls.

The entity's own audits

Your own audit team or an appointed auditor tests the provider directly, using rights written into the contract. This is the only source that tests the controls against your requirements rather than the provider's chosen scope. It proves what was examined on the dates examined. It does not prove the controls held between audits. Ask the provider to confirm in writing the audit, inspection and access rights for your staff and your appointed auditors, including for the premises and systems that process your data.

Independent audit reports

An independent auditor's report on the provider's controls gives a third-party view without your team having to run the fieldwork. Its value depends on scope: the report covers only the systems, locations and services named in it, and a report on one product line does not cover another. Check the period covered, the exceptions noted and whether the services you buy from the provider are inside the boundary. Ask for the most recent report, the bridge letter covering the gap to today and the list of controls excluded from scope.

The provider's internal audit reports

Internal audit reports show that the provider runs its own assurance function and tracks findings to closure. They are often more detailed than external reports, but they are written for the provider's management and may not be independent of the business they review. They prove the provider has a working review process. They do not prove the findings you care about were fixed. Ask for the internal audit plan for the services you use, the open findings and the due dates on which they were tracked.

Third-party certifications and other information

Certificates issued by accredited certification bodies, and other documented evidence such as security questionnaires or penetration test summaries, can support due diligence. A certificate proves that a scoped management system met a standard at a point in time, not that a specific service you buy is covered. Confirm the issuing body, the certificate scope, the expiry date and whether the certified sites include the ones that handle your data. Ask the provider which certificate covers the service in your contract and for the statement of applicability or equivalent scope document.

How to check a provider's vulnerability handling and open-source libraries

Article 10(2) of Delegated Regulation (EU) 2024/1774 asks the financial entity to verify two things about an ICT provider: that the provider handles vulnerabilities and reports critical ones in a timely way, and that the entity can track the third-party and open-source libraries used by ICT services that support critical or important functions. The verification belongs in due diligence before contracting and in the periodic assurance cycle afterwards, and the results should be recorded in the ICT third-party policy so that an assessor can see how the entity knows what it is relying on. The RTS sets the duty, but the exact depth, frequency and timing expected for a given provider should be confirmed against the current text of Delegated Regulation (EU) 2024/1774 and with the competent authority, rather than assumed.

In practice, the entity should request documentary evidence rather than rely on a general statement of security. Useful items include the provider's vulnerability handling procedure, how it classifies and prioritizes findings, the internal and external channels through which vulnerabilities are received and disclosed, and the contractual commitment on how quickly it will notify the entity of a critical vulnerability affecting the service. Ask for the last few examples of anonymized advisories or customer notifications, which show whether the process works in practice. For libraries, ask for a software bill of materials or equivalent inventory covering the components in the service, including open-source libraries, their versions and their licences, and ask how the inventory is kept current after each release. Where the entity runs self-hosted open-source software under a support contract, the same questions apply to the upstream project and the supplier's patching cadence.

Confirm three points with the provider before signing: which timeframes are contractual and which are best-effort, who receives notifications on the entity's side and whether that route is tested, and how the provider tracks vulnerabilities in libraries it did not write. Record any gap as a finding with an owner and a remediation date, and decide whether the entity will accept the residual risk or require a compensating control, such as the entity's own scanning of the deployed artifacts. Reassess the evidence on a defined schedule and after any material change in the service. Where a provider cannot produce an inventory or a reporting commitment, treat that as a due diligence result that bears on the contracting decision, not as a paperwork issue to resolve after signature.

Who owns the controls, who prepares evidence and who gives assurance

The financial entity owns the outcome. Under Article 28 and the related provisions, it decides whether a provider supports a critical or important function, performs due diligence, assesses concentration and location risk, signs the contract and keeps the register of information. The board remains accountable for these decisions, and no outside party can take that accountability over. The entity also decides which assurance sources the policy names and how it weighs them, because Article 6 requires the policy to state how assurance on the provider is obtained.

Decisions: whether the service is an ICT service, whether it supports a critical or important function, and whether subcontracting is permitted under Article 3 of Delegated Regulation (EU) 2024/1774.
Policy and register: the ICT third-party policy, the assurance methodology and the register entries for each provider and chain.
Contract terms: audit and inspection rights, information security standards, vulnerability reporting duties and exit provisions.
Ongoing monitoring: reviewing the provider's reports, its vulnerability notices and its performance against the entity's own requirements.
Accountability: keeping records that show who approved each decision and on what evidence.

Before relying on any partner's material, confirm that your internal team can explain and defend each decision to a supervisor without the partner in the room.

Where provider due diligence usually stalls

Most DORA due diligence delays trace back to a small set of gaps: no clear inventory of what counts as an ICT service, evidence requested too late, certificates that do not match the service, and unclear ownership. The cards below cover each gap and the step that prevents it, so the pre-contract assessment can finish before signature.

No register-ready service list

Due diligence cannot start until the entity knows which suppliers provide ICT services and which of those support critical or important functions. Build one inventory that maps each provider, service, data location and function, and keep it in the format the register of information will use. Check every software line item, including support and maintenance contracts, against the ICT service definition before procurement begins, so no provider reaches signature unrecorded.

Assurance requested after signature

Audit reports, certificates and security questionnaires requested once a contract is signed give the entity little leverage if the evidence is weak. Article 28(4) expects due diligence before contracting, so issue the assurance request as part of the procurement pack and set a deadline before the contract is negotiated. Hold back signature until the evidence has been reviewed and any gaps are recorded.

Certificates that miss the service

A certificate often covers an organization or a narrow set of locations, not the specific service the entity is buying. Before relying on one, confirm the legal entity named on it, the services and systems inside scope, the assessment period, and any carve-outs. Where the certificate does not cover the service, request a bridging statement from the provider or supplement it with the provider's own audit report, as Article 6(3) and (4) allow more than one assurance source.

Missing subcontractor information

Subcontracting chains are often documented only at the top level, which leaves the entity unable to assess location risk, concentration risk or the impact of a subcontractor failure. Under Article 3(1), the entity must decide before contracting whether subcontracting is allowed and confirm conditions such as the provider's ability to monitor subcontractors and secure equivalent inspection rights. Ask for the full chain, with locations and the services each subcontractor supplies, during the pre-contract stage.

Unclear ownership across functions

Legal reviews the contract, security reviews the evidence, and procurement runs the timeline, yet no one owns the decision to accept or reject a provider. Name one accountable owner for each provider file, define who signs off the risk assessment, and set out which function holds the audit and inspection rights after signature. Record these roles in the policy so that assessors can trace each decision to a named person.

Open-source libraries and vulnerability handling

Providers of software and managed services often do not say how they handle vulnerabilities or which open-source libraries their products contain, so the entity learns about critical flaws late. Under Article 10(2) of Delegated Regulation (EU) 2024/1774, the entity must verify that providers handle vulnerabilities and report critical ones in a timely way, and track third-party and open-source libraries used by services supporting critical or important functions. Put disclosure timelines and a library list into the due diligence questionnaire and the contract.

Questions buyers ask about DORA provider due diligence

Does a certification alone satisfy DORA provider due diligence?

No. A certificate is one input, not a complete answer. Article 6 of DORA requires the financial entity's ICT risk management policy to state how assurance on each provider is obtained. The listed sources include the entity's own audits, independent audit reports, the provider's internal audit reports, appropriate third-party certifications, and other information. The policy should use more than one source where appropriate. A certificate covers a defined scope at a point in time, so it has to be read alongside the services actually bought, the locations used and the subcontractors involved. Ask the provider which scope the certificate covers and whether it includes the service you consume.

How much effort does provider due diligence take, and what drives it?

DORA does not set a fixed effort or duration, so confirm any figure with your competent authority and your own environment. Effort rises with the number of providers, whether the service supports a critical or important function, the depth of the provider's subcontracting chain, and how much evidence the provider already holds. Pre-contract work covers the risk assessment under Article 5, the due diligence and conflict of interest checks under Article 28(4), and the review of information security standards under Article 28(5). Much of this is one-time per contract, while monitoring, reassessment and audit follow-up recur. Ask any partner for a written breakdown of which tasks are fixed and which repeat each year.

Can our team run DORA provider due diligence in-house?

Often yes for a first pass, but the work spans several disciplines. Your team needs to decide whether each contract supports a critical or important function, document risks such as ICT concentration, data location and provider location, and judge whether the provider meets appropriate information security standards. Those decisions must be recorded in the policy and the register of information. Smaller entities with few providers can usually handle this internally using their own audit rights and the provider's documents. Larger entities, or those with complex cloud or subcontracting chains, often bring in outside help for the technical review, while keeping ownership of the decisions and sign-off.

What does the work need from procurement and security teams?

The work is shared. Procurement must obtain the information needed before signing, including subcontracting details, audit and inspection rights, exit and termination terms, and data location commitments. Security must review the provider's information security standards, vulnerability handling and open-source library tracking, and must agree which evidence is acceptable. Legal should confirm that contract clauses meet the requirements that apply to the service. Both teams should agree a single register of provider evidence so that the same documents are not requested twice. Ask each partner which of these tasks it takes on and which it expects your staff to complete.

How often must we audit or inspect an ICT provider?

Under Article 28(6), the frequency and scope of audits and inspections must be risk-based and pre-determined, and must follow commonly accepted audit standards. There is no fixed interval in DORA itself. Your policy and each contract should set the frequency for each provider based on its criticality, its concentration risk and the changes it makes. Higher-risk providers, especially those supporting critical or important functions, typically warrant more frequent review than low-risk services. Record the chosen frequency and the reasoning, so the schedule can be shown to your competent authority. Confirm any specific expectation with your supervisor.

Do we need to check how a provider handles vulnerabilities?

Yes. Article 10(2) of Delegated Regulation (EU) 2024/1774 requires entities to verify that ICT third-party service providers handle vulnerabilities and report critical ones in a timely way. It also requires tracking third-party and open-source libraries used by ICT services that support critical or important functions. In practice, ask the provider for its vulnerability disclosure process, its patch timelines for critical issues, and how it notifies customers. For self-hosted open-source platforms, your own team or your implementation partner owns the library tracking, so the duty sits with you even when support is bought in.

What should we ask an outside partner before engaging?

Ask for a written scope, deliverables and timeline before work starts, since most engagements are fixed-scope. Confirm which DORA sections the work covers and which assurance sources the partner will help you document under Article 6. Ask how it will prepare evidence, what it will not do, and who signs off results. Remember that a partner prepares systems and evidence, while only an independent auditor or assessor issues reports or certificates. Ask which parts of the work you must still own, which documents you will receive, and how monitoring continues after the first review. DeployOpen provides a quote based on that written scope.

How DeployOpen prepares provider evidence for your assessment

DeployOpen helps financial entities assemble the evidence their DORA due diligence and assurance files need, working inside the client's own infrastructure. We prepare systems, documentation and evidence for review; the organization keeps ownership of its provider decisions, and independent auditors issue any reports.

How we scope

Scope is agreed in writing before work starts, naming the ICT providers and services in the assessment.
The written scope lists which providers are self-hosted platforms and which rely on vendor support or hosted services.
Scope states which assurance sources the policy will name, such as own audits, provider reports or certifications.

How we build

We map pre-contract assessment questions to the evidence each provider can supply, including subcontracting and location details.
We set up tracking of vulnerability disclosures and open-source libraries used by services supporting critical or important functions.
We design audit and inspection checklists with a risk-based frequency and scope agreed with your risk function.

How we hand over

Deliverables include the due diligence files, assurance register and provider evidence packs, in formats your team can maintain.
Each document records who owns the decision, what evidence supports it and when it is due for review.
We walk your assessors and management body through the evidence trail so they can test it independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can keep provider assurance files current as contracts, subcontractors and vendor reports change.
Ask us to confirm which parts of the provider review your own legal and risk teams must sign off.

DORA due diligence and assurance on ICT providers