Vendor Due Diligence: A Step-by-Step Guide
Step-by-step guide to vendor due diligence covering financial, operational, security, and compliance checks, DORA's specific ICT provider requirements, red flags, and decision frameworks for EU regulated entities.
- 1
Due diligence must be completed before contract execution — retrospective due diligence is a common and avoidable supervisory finding under DORA and NIS2.
- 2
Scope due diligence proportionately using your criticality tiering model: critical vendors require comprehensive financial, operational, security, and compliance assessments, while low-risk vendors need only basic screening.
- 3
DORA imposes unique requirements including ICT concentration risk assessment, CTPP designation awareness, and exit strategy evaluation that go beyond standard vendor due diligence practices.
- 4
Red flags should have predefined treatment in a documented decision framework — automatic rejection for critical flags, escalation for accumulated moderate flags, and conditional approval with enforceable timelines.
- 5
Due diligence findings must flow into contractual provisions, establishing the baseline risk profile for ongoing monitoring and the conditions that will be tracked throughout the vendor relationship.
1. The Purpose and Scope of Vendor Due Diligence
Vendor due diligence is the investigative process conducted before entering into a third-party relationship to determine whether the vendor meets your organisation's risk, security, compliance, and operational requirements. Unlike ongoing risk assessment, which monitors an existing relationship, due diligence is specifically a pre-engagement or pre-contract activity designed to surface risks before you are contractually and operationally dependent on the vendor. The outcome of due diligence is a go/no-go decision or a set of conditions that must be met before the relationship can proceed.
The scope of due diligence should be proportionate to the criticality and nature of the proposed vendor relationship. A vendor that will host your production data in their cloud environment warrants a fundamentally different due diligence process than a vendor providing branded merchandise. The criticality tiering model established in your TPRM programme should determine which due diligence workstreams apply: financial checks may apply to all vendors above a minimum contract value, while detailed security assessments and on-site audits should be reserved for vendors that will support critical functions, access sensitive data, or integrate with your systems.
For EU regulated entities, due diligence is not merely a best practice — it is a regulatory obligation. DORA Article 29(1) explicitly requires financial entities to undertake a risk assessment before entering into ICT third-party arrangements, including verifying that the ICT third-party service provider complies with appropriate information security standards. NIS2 Article 21(2)(d) requires entities to consider the overall quality of products and cybersecurity practices of their suppliers. GDPR Article 28(1) requires controllers to use only processors providing sufficient guarantees. Each of these provisions creates a duty to investigate before contracting, and the burden of demonstrating that due diligence was conducted falls on your organisation.
Due diligence must be completed before contract execution, not after. Regulators will scrutinise the timing — discovering that a critical vendor was onboarded months before due diligence was completed is a common and avoidable supervisory finding.
2. Financial and Operational Due Diligence
Financial due diligence assesses the vendor's economic viability and stability. A vendor that becomes insolvent mid-contract can cause severe operational disruption, data access issues, and costly emergency migrations. At minimum, financial due diligence should include review of audited financial statements (last two to three years), credit rating or score from a recognised agency, analysis of revenue concentration (is the vendor dangerously dependent on a single client or market?), assessment of funding structure (for startups and growth-stage companies, evaluate burn rate and runway), and verification of insurance coverage (professional indemnity, cyber liability, and business interruption).
Operational due diligence evaluates the vendor's ability to deliver the contracted services reliably and at the required quality level. This encompasses organisational structure and staffing (does the vendor have sufficient qualified personnel?), service delivery track record (references from comparable clients), business continuity and disaster recovery capabilities (documented and tested plans), geographic footprint (where are services delivered from, where is data processed, and does this alignment with your data residency requirements?), and change management processes (how does the vendor manage updates, migrations, and service changes without disrupting your operations?).
For critical vendors, operational due diligence should include an assessment of key-person dependency. If the vendor's ability to deliver your service depends on a small number of irreplaceable individuals, this represents a concentration risk within the vendor that should be addressed contractually (key-person clauses, knowledge transfer requirements) and factored into your overall risk assessment. Similarly, assess technology dependencies: a vendor built entirely on a single cloud provider's proprietary services inherits that provider's availability risk and may face significant challenges if forced to migrate — a concern that directly intersects with DORA's exit strategy requirements.
3. Security and Technical Due Diligence
Security due diligence is the most technically demanding workstream and the one most directly relevant to DORA and NIS2 compliance. The objective is to evaluate whether the vendor's security posture is adequate to protect your data, systems, and operations from compromise through the vendor's environment. This assessment must go beyond certifications and policy documents to evaluate the operational effectiveness of the vendor's security controls.
The security assessment should cover, at minimum: information security governance (policies, organisation, roles, management commitment), access management (authentication mechanisms, least-privilege enforcement, privileged access controls, access review processes), data protection (encryption at rest and in transit, key management, data classification and handling procedures, backup and recovery), network security (segmentation, firewall management, intrusion detection and prevention, DDoS mitigation), application security (secure development lifecycle, code review, vulnerability management, penetration testing cadence), endpoint security (device management, anti-malware, patch management), incident response (documented plan, testing cadence, notification procedures and timelines), and physical security (data centre certifications, access controls, environmental protections).
For ICT third-party providers under DORA, Article 29(1) requires verification that the provider complies with appropriate information security standards. In practice, this means requesting and evaluating independent assurance artefacts: ISO 27001 certification (verify the scope covers the relevant services), SOC 2 Type II reports (review the testing period, control descriptions, and exceptions), penetration test summaries (not just the executive summary — request the methodology, scope, and critical/high findings with remediation status), and vulnerability management metrics (patch cadence, mean time to remediate critical vulnerabilities). Where the vendor processes personal data, also assess GDPR Article 32 compliance: encryption, pseudonymisation, resilience, availability, and regular testing of security measures.
Request penetration test reports that cover the specific services or infrastructure relevant to your relationship, not just the vendor's corporate environment. A penetration test of the vendor's website does not provide assurance about their SaaS platform's security.
4. Compliance and Regulatory Due Diligence
Compliance due diligence verifies that the vendor's regulatory posture does not create compliance risk for your organisation. This is particularly important in the EU regulatory environment, where regulatory obligations often flow through vendor relationships: if your data processor violates GDPR, your organisation bears supervisory risk as the controller. If your ICT provider fails to meet DORA's contractual requirements, the financial entity bears the regulatory consequence.
The compliance due diligence workstream should verify: GDPR compliance (data processing agreements, transfer impact assessments for non-EU transfers, Data Protection Officer appointment where required, DPIA completion for high-risk processing), sector-specific regulatory compliance (financial services licensing, healthcare certifications, telecommunications regulations), sanctions screening (verify the vendor and its beneficial owners against EU restrictive measures lists, OFAC, and UN sanctions), anti-money laundering and anti-bribery screening (particularly for vendors in high-corruption-risk jurisdictions), and ESG and human rights due diligence (increasingly required under the EU Corporate Sustainability Due Diligence Directive for in-scope companies).
For international vendors, pay particular attention to data transfer mechanisms. Following the Schrems II decision and the subsequent EU-US Data Privacy Framework, the legal basis for transferring personal data to non-EU countries requires careful analysis. Verify which data transfer mechanism the vendor relies on (adequacy decision, standard contractual clauses, binding corporate rules), whether a transfer impact assessment has been conducted for SCCs, and whether supplementary measures are in place where required. For DORA-regulated entities, Article 29(2)(g) requires contracts to specify the locations where ICT services are provided and data is processed — including any planned sub-outsourcing to non-EU locations — making data residency verification a regulatory requirement, not just a best practice.
5. DORA's Specific Due Diligence Requirements for ICT Providers
DORA imposes several due diligence requirements that go beyond general vendor assessment practices. Article 29(1) requires financial entities, prior to entering into contractual arrangements on the use of ICT services, to assess whether the contractual arrangement covers the use of ICT services supporting a critical or important function, whether supervisory conditions for contracting or sub-outsourcing are met, to identify and assess all relevant risks in relation to the contractual arrangement (including the possibility that such arrangement may contribute to reinforcing ICT concentration risk), to undertake all due diligence on prospective ICT third-party service providers, and to identify and assess conflicts of interest that the contractual arrangement may cause.
The concentration risk assessment is a distinctively DORA requirement without direct parallel in other frameworks. Financial entities must evaluate whether entering into the proposed ICT arrangement would create or increase concentration risk — excessive dependency on a single ICT provider, a small number of related providers, or a provider that is already heavily concentrated in the financial sector. This analysis requires visibility into your existing ICT third-party portfolio (the register maintained under Article 28), the vendor's market position and client concentration, and the availability of alternative providers for the same ICT service. Where concentration risk is identified, the entity must document the mitigation measures and exit strategies.
DORA also introduces the concept of critical ICT third-party service providers (CTPPs), designated by the ESAs under Articles 31-44. These providers will be subject to direct oversight by a Lead Overseer appointed from among the ESAs. While designation is an ESA-level decision (not the financial entity's), the due diligence process should assess whether a prospective ICT provider is likely to be designated as a CTPP, as this brings additional regulatory dynamics to the relationship. Providers designated as CTPPs will be subject to inspections, recommendations, and potentially penalties from the Lead Overseer, which may affect service delivery, pricing, and contractual terms.
DORA's concentration risk assessment is unique among regulatory frameworks. It requires you to evaluate not just the individual vendor's risk but also how the vendor relationship affects your overall portfolio-level concentration across all ICT third-party arrangements.
6. Red Flags and Decision Frameworks
Effective due diligence requires the ability to recognise red flags — indicators that a vendor relationship may carry unacceptable risk. Financial red flags include declining revenue trends, negative working capital, qualified audit opinions, frequent auditor changes, and heavy reliance on a single customer for more than 30% of revenue. Security red flags include absence of independent security certifications, refusal to share penetration test results or SOC 2 reports, inability to articulate incident response procedures, use of end-of-life software in production, and a history of publicly disclosed breaches without evidence of remediation.
Compliance red flags include absence of a Data Protection Officer where one is required, inability to identify the legal basis for data transfers, vague or non-specific data processing agreements, sanctions matches or adverse media findings, and registration in jurisdictions known for opaque corporate structures without clear business justification. Operational red flags include high staff turnover (particularly in security and operations teams), lack of documented business continuity plans, absence of disaster recovery testing evidence, and reluctance to provide client references.
The decision framework should define how red flags translate into outcomes. A single critical red flag (such as a sanctions match or refusal to provide audit access) should result in automatic rejection. An accumulation of moderate red flags (such as declining finances combined with limited security certifications) should trigger escalation to a risk committee for decision. The framework should also define conditions under which a vendor can be approved conditionally — for example, approving a vendor that lacks ISO 27001 certification on the condition that certification is achieved within 12 months, with contractual penalties for non-compliance. Document all decisions, including rejections, with the rationale — this creates the auditable record that regulators expect to see.
7. Due Diligence Outputs and Contract Integration
The output of the due diligence process should be a structured due diligence report that summarises findings across all workstreams, assigns a risk rating, documents the decision (approved, approved with conditions, or rejected), and identifies any residual risks that must be managed through contractual provisions, compensating controls, or ongoing monitoring. This report becomes a foundational document in the vendor relationship file and the starting point for the ongoing risk assessment cycle.
Due diligence findings must flow directly into contract negotiations. Risks identified during due diligence that cannot be fully mitigated through the vendor's own controls should be addressed through contractual provisions: service levels with financial consequences for breach, security obligations with audit rights and remediation timelines, data processing terms that satisfy GDPR Article 28(3), incident notification obligations with defined timelines (DORA Article 30(2)(e) requires ICT providers to assist with incident reporting obligations), and termination rights triggered by material security failures or compliance breaches. The contract should also include the exit strategy provisions required by DORA Article 28(8), ensuring that the financial entity can transition away from the provider without service disruption.
Finally, the due diligence report should establish the baseline for ongoing monitoring. The risk rating assigned during due diligence determines the monitoring intensity and reassessment frequency. Conditions imposed during due diligence (such as achieving a certification by a deadline) should be tracked with defined escalation procedures if the condition is not met. Residual risks accepted during due diligence should be formally recorded in the risk register and reviewed at each reassessment cycle to determine whether the risk level remains within appetite or whether changed circumstances warrant reclassification.
How long should vendor due diligence take?
Duration depends on criticality tier and vendor responsiveness. For Tier 1 critical vendors, allow 6-12 weeks for a comprehensive due diligence process covering all workstreams. Tier 2 vendors typically require 3-6 weeks. Tier 3 low-risk vendors can be cleared through automated screening in 1-2 weeks. These timelines assume vendor cooperation — unresponsive vendors will take longer and should be flagged as an operational red flag. Build due diligence timelines into your procurement process to avoid pressure to shortcut the process due to business urgency.
Is due diligence required for existing vendors?
If your existing vendors were onboarded without formal due diligence (or with due diligence that predates your current regulatory obligations under DORA or NIS2), you should conduct retrospective due diligence prioritised by criticality tier. Focus first on Tier 1 critical vendors, particularly those supporting critical or important functions under DORA. Frame this as a 'baseline assessment' rather than suggesting previous onboarding was deficient. Contract renewal is an ideal trigger for conducting due diligence on legacy vendor relationships.
What if a vendor refuses to participate in due diligence?
A vendor's refusal to participate in reasonable due diligence is itself a significant red flag. For critical vendor relationships, refusal to provide security documentation, audit access, or compliance evidence should generally result in rejection. For lower-tier relationships, you may accept independent certifications (ISO 27001, SOC 2) in lieu of direct engagement if the certification scope covers the relevant services. Document the refusal and your risk-based decision in either case. Under DORA Article 30(3)(e), contracts for critical ICT services must include audit rights — a vendor unwilling to accept this during due diligence will not accept it contractually.
How does due diligence differ for cloud service providers?
Cloud service providers present unique due diligence considerations: shared responsibility models require clear delineation of security obligations, multi-tenancy introduces risks around data isolation, geographic distribution of infrastructure affects data residency compliance, and the scale of major cloud providers makes traditional on-site audits impractical. For cloud providers, emphasise review of SOC 2 Type II reports (ensure scope includes the specific services you use), data processing and residency documentation, shared responsibility matrices, incident notification procedures and historical response times, and sub-processor lists with change notification mechanisms. DORA's ITS on the information register includes specific fields for cloud service characteristics.
Should we conduct due diligence on sub-processors and fourth parties?
You should assess your direct vendor's management of their sub-processors rather than attempting to conduct due diligence on every fourth party directly. Evaluate whether the vendor has a formal sub-processor management programme, contractual flow-down of security and compliance requirements, a sub-processor change notification process, and the ability to provide you with sub-processor risk information upon request. Under GDPR Article 28(2) and (4), the processor must not engage sub-processors without your authorisation and must impose equivalent data protection obligations. Under DORA Article 29(2), ICT sub-outsourcing of services supporting critical functions requires specific contractual provisions.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.