Supplier Due Diligence Checklist: A Practical Guide for Clients and Vendors

Supplier due diligence stopped being a box-ticking exercise years ago. What it actually is, when done properly, is a structured process for determining whether a vendor can be trusted with your data, your systems, and, increasingly, your regulatory exposure. Get it wrong and the consequences are not hypothetical.

Think of it as a pre-flight checklist. No pilot takes off on the assumption that everything is probably fine. They verify, systematically and in writing, that every critical system is operational before the aircraft leaves the ground. Supplier due diligence applies the same logic to vendor relationships: before a vendor enters your environment, you confirm that all critical controls, safeguards, and compliance obligations are genuinely in place.

That question has grown considerably more involved in recent years. It now reaches well beyond traditional security. A complete supplier due diligence process today must address data protection under GDPR Article 28, emerging obligations under the EU AI Act, alignment with internationally recognised security standards, and the third-party risk that threads through every modern supply chain. Skip it, and the failures compound.

The most immediate risk is a data breach traced to a vendor. In 2023, MOVEit, a widely used file-transfer tool, was exploited by a ransomware group that compromised data held by hundreds of organisations globally, including government bodies, banks, and healthcare providers. None of those organisations suffered the initial breach. All of them suffered the consequences: notifying regulators, communicating to customers, and facing pointed questions from supervisory authorities about what due diligence they had actually performed before entrusting the vendor with personal data.

The regulatory consequence follows directly. Under Article 83(4) GDPR, a controller that cannot demonstrate it verified a processor's controls before engaging them faces fines of up to EUR 10 million or 2% of global annual turnover, not for the breach itself, but for the failure of due diligence that preceded it. Supervisory authorities across the EU have made this an enforcement priority. In 2022, the Italian DPA fined Enel Energia specifically because it had transferred customer data to a processor without adequate contractual and operational safeguards in place. The vendor's conduct was the proximate cause. The client's liability was the legal result.

Beyond fines, the operational consequences pile up: incident response costs, regulatory investigations stretching over years, contractual disputes with the vendor over liability, reputational damage that erodes customer trust and partner confidence, and the indirect cost of internal resources consumed by the aftermath. Research consistently finds that third-party breaches cost more on average than those caused by internal failures, precisely because the compromised organisation has less visibility into the vendor's environment and less control over the remediation timeline.

For vendors, the consequences run in the opposite direction. A security questionnaire that cannot be answered credibly, a certification that has lapsed, a DPA that was never updated to reflect the current subprocessor list: each gap can stall a deal, trigger a re-assessment, or end a procurement conversation entirely. In competitive evaluations, the vendor whose due diligence documentation is complete, current, and immediately available wins on trust before the commercial conversation even concludes.

This guide explains what a modern supplier due diligence checklist should include, and how both sides of the process can approach it efficiently. For the broader context of how due diligence fits into your vendor response workflow, see our guide on security questionnaire automation.

What Is a Supplier Due Diligence Checklist?

A supplier due diligence checklist is a structured set of questions and evidence requests used to assess a vendor before onboarding and throughout the ongoing relationship. It is the mechanism through which organisations verify that the vendors they depend on can operate safely within their risk, security, and compliance framework.

A well-designed checklist is not a single document sent once at the start of a relationship. It is a living framework that evolves alongside the regulatory environment, the vendor's own posture, and the nature of the services being provided. A payment processor onboarded five years ago under a basic security questionnaire may now need to demonstrate GDPR compliance, EU AI Act readiness, and alignment with ISO 27001 before a contract renewal is approved.

The core domains a modern checklist should cover:

• Legal and regulatory compliance (including jurisdiction-specific obligations)
• Data protection and privacy practices
• Information security controls and certifications
• Operational resilience and business continuity
• Third-party and subprocessor risk management
• Emerging risk areas, particularly AI governance

Core Pillar: Data Processing Under the GDPR

At the centre of modern supplier due diligence sits GDPR compliance, not as a formal requirement alone, but as a liability allocation mechanism between controller and processor. Whenever a vendor processes personal data on behalf of a client, the relationship becomes one of controller and processor under GDPR Article 28. That provision is structural: it defines how responsibility is distributed, how risk is managed, and how accountability is demonstrated under law.

A useful way to frame this: GDPR due diligence is not about what a vendor says it does. It is about what its systems actually do in practice. A vendor can claim to delete personal data after 30 days; the question is whether that deletion is automated, auditable, and contractually enforceable. The gap between a claim and an operational reality is exactly what a well-structured due diligence checklist is designed to expose.

1. Role qualification: controller, processor, or joint controller

Misclassification is one of the most common and most consequential errors in GDPR vendor relationships. It happens more often than you would expect. Vendors frequently position themselves as processors while in practice exercising elements of control: determining retention periods, analytics purposes, or secondary uses of data. The client must assess whether the vendor acts strictly on documented instructions (Article 28(3)(a)), or whether it independently determines purposes or essential means, which would indicate controller or joint controller status. This distinction directly affects liability exposure, audit rights, and each party's regulatory obligations.

The EDPB's Guidelines 07/2020 on controller and processor concepts reinforce that role qualification must be based on factual influence over purposes and means, not on how the contract labels the relationship.

2. Depth and enforceability of the Data Processing Agreement

A compliant DPA must include all elements required under Article 28(3) GDPR: the subject matter and duration of processing, the nature and purpose of processing, the types of personal data and categories of data subjects, and the obligations and rights of the controller. Expert-level due diligence goes further, testing enforceability and specificity. Are security measures described concretely or generically? Are audit rights meaningful or purely theoretical? Are the assistance obligations under Articles 28(3)(e) to (h) operationally feasible given the vendor's systems and staffing? A well-drafted DPA should function as an executable document, not a formal appendix that no one reads after signing.

3. Technical and organisational measures under Article 32

Due diligence must assess whether the vendor's technical and organisational measures meet the risk-based, state-of-the-art standard required by Article 32 GDPR. This includes encryption standards at rest and in transit, access control models including least privilege and MFA, logging and monitoring capabilities, and incident detection and response timelines. Crucially, the assessment should test consistency, not just existence. A control that exists on paper but is not systematically enforced does not meet GDPR expectations. Supervisory authorities have consistently held that adequate measures means measures that are actually working, not merely documented.

4. Subprocessor governance under Articles 28(2) and 28(4)

Subprocessor chains are a primary risk vector in third-party due diligence. The client must verify: whether subprocessors require case-by-case authorisation or are pre-approved, whether equivalent GDPR obligations are imposed downstream, whether the vendor maintains an accessible and current subprocessor list, and whether any international transfers are triggered that require Chapter V safeguards. Weak subprocessor governance is one of the most commonly identified sources of GDPR non-compliance in enforcement decisions. A vendor that cannot produce a current subprocessor list with transfer mechanisms documented is not yet compliant.

See our GDPR Guidebook and ROPA Automation for detailed guidance on subprocessor documentation.

5. International data transfers under Chapter V GDPR

Where data is transferred outside the European Economic Area, due diligence must assess the transfer mechanism in use: Standard Contractual Clauses (SCCs), Binding Corporate Rules, adequacy decisions, or derogations. Following Schrems II (C-311/18), this is not a formal tick-box. The Court of Justice of the European Union held that data exporters must verify, on a case-by-case basis, whether the law of the destination country ensures essentially equivalent protection. Where it does not, supplementary measures are required. EDPB Recommendations 01/2020 on supplementary measures clarify that SCCs alone may not be sufficient where public authorities in the destination country can access data without effective legal recourse for data subjects. The practical implication: a vendor hosting data in a jurisdiction with extensive government surveillance powers requires a Transfer Impact Assessment and, typically, additional technical measures such as end-to-end encryption with keys held exclusively in the EEA.

6. Data subject rights and operational readiness

Under Articles 12 to 23 GDPR, controllers must respond to data subject requests within defined timescales. Processors must support this obligation. Due diligence must verify that the vendor can actually locate and retrieve personal data on request, delete or rectify it within statutory deadlines, and escalate requests through clear internal procedures. The key question is operational, not theoretical: can the vendor execute these obligations under real-world conditions, including when the request involves data spread across multiple systems or subprocessors? If a vendor cannot answer this concretely, their GDPR obligations are not yet operationalised.

7. Accountability and documentation under Articles 5(2) and 30

The GDPR's accountability principle requires that compliance can be demonstrated, not merely asserted. Due diligence should confirm the existence and currency of the vendor's Records of Processing Activities, internal policies that reflect actual processing rather than generic templates, and audit trails and documentation practices that would withstand regulatory scrutiny. In essence, GDPR due diligence is about verifying that compliance is embedded into systems, not layered on top of them as an afterthought.

Key regulatory sources: what informs a rigorous GDPR due diligence review

A rigorous GDPR due diligence approach should draw on the following sources:

Schrems II (C-311/18): The CJEU invalidated the Privacy Shield and held that data exporters must assess, on a case-by-case basis, whether the destination country's legal framework provides essentially equivalent protection. Transfer assessments are substantive legal analysis, not formal compliance.

EDPB Recommendations 01/2020 on supplementary measures: Standard Contractual Clauses alone may be insufficient where public authorities in the destination country can access data without effective redress. Technical measures such as encryption or pseudonymisation may be required.

EDPB Guidelines 07/2020 on controller and processor concepts: Role qualification must be based on factual influence over purposes and means of processing, not on contractual labels. A vendor described as a processor in a contract may legally function as a controller.

Processors must implement measures that are appropriate and effective in practice, not merely documented. Due diligence must test operational reality, not paper compliance.

GDPR Article 28 and Article 83: the legal weight behind due diligence

Article 28 requires that controllers only engage processors who provide sufficient guarantees as to the implementation of appropriate technical and organisational measures. This is not a formality: a controller that fails to conduct adequate vendor due diligence before sharing personal data with a processor can itself face enforcement action. Due diligence is therefore both a risk management exercise and a direct legal obligation for the client, not only for the vendor.

The financial consequences are substantial. Under Article 83(4), infringements of the obligations set out in Article 28, including the failure to have a compliant Data Processing Agreement in place or to verify that a processor provides sufficient guarantees, are subject to administrative fines of up to EUR 10 million, or 2% of total worldwide annual turnover, whichever is higher. In practice, supervisory authorities across the EU have levied fines against controllers not because their own systems were breached, but because they failed to verify that a vendor was operating appropriate controls before being granted access to personal data.

The EU AI Act: What Is Changing for Vendor Due Diligence

The EU AI Act (Regulation (EU) 2024/1689) introduces a risk-based regulatory framework that extends supplier due diligence into algorithmic governance. Unlike GDPR, which is technology-neutral, the AI Act is technology-specific: it imposes obligations based on the classification of the AI system, creating a distinct layer of vendor assessment that operates alongside, not instead of, existing data protection due diligence.

Consider a practical example. A company deploying an AI-powered hiring tool from a third-party vendor. Under the EU AI Act, employment-related AI systems are classified as high risk under Annex III. The deploying company is responsible for verifying that the system meets the Act's requirements, including human oversight mechanisms, transparency to affected individuals, and documented risk management. That responsibility cannot be delegated to the vendor through contract alone. It must be verified through due diligence.

1. Risk classification of AI systems

The first step in AI due diligence is determining where the vendor's system falls within the AI Act's classification structure: prohibited AI systems (banned entirely), high-risk AI systems (subject to the most stringent obligations), limited-risk systems (transparency obligations only), or minimal-risk systems (no specific AI Act obligations). High-risk systems include those used in employment decisions, access to essential services, education, law enforcement, and critical infrastructure, as set out in Annex III. For clients, this means identifying whether the vendor's product falls within a listed category before any other assessment takes place. A vendor that cannot answer this question has not begun to comply.

2. Obligations for high-risk AI systems

Where a system is classified as high risk, the AI Act imposes obligations that must be verifiable through due diligence: a continuous risk management system covering the full system lifecycle, data governance procedures ensuring training and validation data are relevant, representative, and free from bias, technical documentation sufficient for regulatory assessment, logging and record-keeping capabilities, transparency and instructions for use, human oversight mechanisms that allow intervention and correction, and accuracy, robustness, and cybersecurity safeguards. The due diligence assessment must verify not only that these elements exist, but that they are integrated into the actual operation of the system, not described only in a policy document. An ISO 42001 certification from the vendor is currently the most efficient single mechanism for verifying this layer.

3. Allocation of roles: provider versus deployer

The AI Act distinguishes between providers (those who develop or place AI systems on the market) and deployers (those who use them in a professional context). In vendor relationships, this distinction has direct contractual consequences. A SaaS vendor is typically a provider; the client organisation is typically a deployer. Each role carries separate, non-delegable obligations under the AI Act. Due diligence must verify that the contractual allocation of responsibilities between provider and deployer reflects the AI Act's requirements and that neither party is relying on the other to fulfil obligations that the law assigns to them directly.

4. Interaction with GDPR

AI systems frequently process personal data, creating direct overlap between AI Act and GDPR obligations. Key interaction points include the lawful basis for processing under Article 6 GDPR, automated decision-making restrictions under Article 22 GDPR where decisions produce significant effects on individuals, and the principles of data minimisation and purpose limitation. A compliant AI system must satisfy both regimes simultaneously. This dual compliance is one of the central challenges of modern vendor due diligence, and it means that GDPR and AI Act assessments cannot be conducted in isolation from each other.

5. Conformity assessments, CE marking, and post-market obligations

High-risk AI systems require conformity assessments before being placed on the market. Due diligence should confirm whether the vendor has completed the required assessment, whether CE marking is applicable and in place, and whether a notified body was involved where the AI Act requires third-party involvement. Beyond initial conformity, the AI Act imposes lifecycle obligations: post-market monitoring systems, incident reporting to supervisory authorities, and continuous risk reassessment as the system is updated or deployed in new contexts. Clients must assess whether vendors have operational mechanisms to meet these ongoing duties, not only at procurement but throughout the contract term.

In practice, questionnaire frameworks are already evolving to reflect this. The SIG's Domain S and the GRC domains of the CAIQ and HECVAT are beginning to incorporate AI governance questions. Vendors who have formalised their AI governance ahead of this wave will find these sections straightforward; those who have not will face increasing friction at every assessment.

Regulatory context: interpreting AI Act obligations

The EU AI Act is relatively new and does not yet have extensive case law. However, its interpretation is already being shaped by existing legal principles and regulatory guidance:

The risk-based approach mirrors GDPR logic, particularly Recital 76 GDPR, which emphasises proportionality calibrated to the actual risk posed to individuals. Higher-risk processing requires more stringent safeguards.

The need for strict safeguards in high-risk use cases is emphasised particularly where fundamental rights are affected. AI systems must be designed to enable human oversight rather than circumvent it.

Existing jurisprudence on automated decision-making provides an interpretative baseline for AI Act obligations in cases involving profiling or decisions with significant effects on individuals. Supervisory authorities are expected to apply consistent principles across both regimes. For a deeper look at the EU AI Act, see our EU AI Act Guidebook.

Security and Compliance Standards: The Evidence Layer

Standards and certifications serve as the structural backbone of a due diligence process. They provide independently verified evidence that controls are in place and operating effectively. Without them, due diligence becomes a comparison of claims. With them, it becomes a comparison of audited realities.

Think of certifications as pre-validated reference letters. Rather than asking a vendor to describe their access control processes from scratch, a client can ask: do you hold SOC 2 Type II? If yes, the audit report provides independent evidence of those controls across a defined period, issued by a qualified third party. The client's review time shrinks from hours to minutes.

Questionnaires: CAIQ, SIG, and HECVAT

Supplier due diligence is most commonly operationalised through standardised questionnaires. Rather than each client designing their own assessment from scratch, these frameworks provide a shared vocabulary that makes vendor responses comparable, repeatable, and efficient for both parties.

In practice, organisations often use multiple questionnaire frameworks simultaneously. A financial services firm with a university research partnership might send a SIG for general vendor assessment and a HECVAT for the specific research data processing relationship. A vendor selling into both markets needs a response infrastructure capable of handling all three formats. That is precisely the problem that security questionnaire automation is built to solve.

Perspective 1: The Client Sending the Questionnaire

For the organisation initiating due diligence, the process is fundamentally about risk reduction and regulatory accountability. A poorly structured process produces inconsistent vendor evaluations, creates blind spots in the risk picture, and leaves the organisation exposed both to vendor failures and to regulatory findings that it failed to conduct adequate oversight.

Consider a common scenario: a procurement team evaluates three competing SaaS vendors using three different questionnaires, designed independently by three different internal stakeholders. The responses arrive in different formats, cover different control areas, and cannot be meaningfully compared. The organisation ultimately selects a vendor based on factors it can evaluate, such as price and feature set, while the security and compliance picture remains opaque. This is not an edge case. It is the default in organisations without a standardised due diligence framework.

Key challenges on the sending side

• Fragmented questionnaires designed by different teams with different risk priorities, making systematic comparison impossible
• No consistent mapping of questionnaire questions to GDPR Article 28 requirements or EU AI Act obligations
• Manual review of large volumes of vendor responses without a structured risk-scoring methodology
• No audit trail demonstrating that adequate due diligence was performed, creating regulatory exposure

That last point carries a specific legal dimension worth naming directly. Where a data breach occurs and the supervisory authority finds that the controller failed to conduct adequate due diligence before engaging the processor involved, the controller faces dual exposure: liability for the breach itself under Article 83(4) (up to EUR 10 million or 2% of global annual turnover for Article 28 violations) and potentially under Article 83(5) (up to EUR 20 million or 4% of global annual turnover) for the underlying failure to implement appropriate technical and organisational measures under Article 5(1)(f) and Article 32 GDPR. Skipping adequate vendor due diligence does not merely create operational risk. It creates a regulatory scenario in which the client organisation bears liability for a vendor's failures, at penalties calibrated to its own global revenue.

Best practices for clients

• Standardise on recognised frameworks such as CAIQ, SIG, or HECVAT, adapted to your specific regulatory context
• Map every questionnaire section explicitly to GDPR Article 28 requirements so that the assessment simultaneously produces due diligence documentation
• Introduce structured AI governance questions where vendors operate AI systems in high-risk categories
• Require evidence, not assertions: certifications, audit reports, and DPA templates carry more weight than narrative descriptions of controls
• Maintain a centralised vendor risk repository so that reassessment at contract renewal does not start from zero

Whisperly's Vendor Assessment platform transforms the sending side of due diligence into a structured, scalable process: standardised questionnaires aligned with CAIQ, SIG, and custom frameworks; automated analysis and risk scoring of vendor responses; regulatory mapping to GDPR and EU AI Act requirements; and a centralised vendor risk repository. Instead of manually reviewing each response, clients gain a consistent, data-driven view of vendor risk across their entire supplier portfolio.

Perspective 2: The Vendor Receiving the Questionnaire

For the vendor, due diligence is frequently one of the most persistent bottlenecks in the sales cycle. It arrives at precisely the wrong moment, when a deal is close to closing and attention is at its most valuable, and it demands significant effort from people who have other priorities.

The structural problem is repetition. Most questionnaires cover the same underlying control domains: access management, encryption, incident response, data retention, subprocessor management. A vendor responding to multiple assessments a month is answering largely the same questions, in slightly different formats, on a nearly continuous basis. Without a systematic approach, that repetition consumes thousands of hours annually and introduces inconsistencies that create audit risk.

Key challenges on the receiving side

• Answering overlapping questions across multiple questionnaire formats without a centralised knowledge base, creating inconsistency between responses
• Aligning answers with certifications and policies that live in different systems, owned by different teams
• Preparing accurate GDPR documentation, including DPA templates and ROPA, for every questionnaire that asks about data processing
• Keeping AI governance documentation current as regulatory requirements evolve and buyer expectations increase
• Delays in sales cycle closing caused by slow questionnaire turnaround

Best practices for vendors

• Build a centralised response library that maps approved answers to your SOC 2 report, ISO 27001 certification, and GDPR documentation
• Maintain current, accessible GDPR compliance documentation: a signed DPA template, a current subprocessor list, and an up-to-date Records of Processing Activities
• Prepare AI governance documentation now, before buyers require it: an ISO 42001 certification or an EU AI Act readiness statement converts future AI governance questions from a research project into a reference
• Publish your security posture proactively in a Trust Center: every buyer who self-serves your documentation before sending a questionnaire is a questionnaire you never have to complete

Whisperly's security questionnaire automation automates questionnaire completion by connecting your existing documentation to an AI-driven response engine. Your SOC 2 report, ISO 27001 certificate, GDPR documentation, and prior questionnaire responses pre-populate answers across CAIQ, SIG, HECVAT, and custom formats. Questions that fall outside your existing library are routed to the right subject matter expert with full context. The result is faster turnaround, more consistent answers, and a response library that improves with every questionnaire you complete.

Building a Future-Proof Due Diligence Process

Supplier due diligence is evolving from a static, point-in-time checklist into a dynamic, continuously updated system. The organisations that treat it as a strategic capability rather than a compliance obligation will move faster, reduce risk more effectively, and build vendor relationships on a foundation of verified trust rather than documented assumption.

Frequently Asked Questions

What is supplier due diligence?

Supplier due diligence is the structured process of assessing a vendor's security, privacy, regulatory compliance, and operational reliability before onboarding them and throughout the ongoing relationship. It is not a one-off check. It is the mechanism through which organisations verify that their vendors can operate safely within the organisation's risk and compliance framework, meeting obligations under laws such as GDPR and, increasingly, the EU AI Act. The scope has expanded significantly in recent years, and organisations that treat it as a static form are falling behind the regulatory reality.

What should a supplier due diligence checklist include?

A complete modern checklist covers: legal and regulatory compliance (including GDPR, CCPA, and sector-specific rules); data protection practices including DPA, subprocessor management, and ROPA; information security controls and certifications (SOC 2, ISO 27001); AI governance where the vendor operates AI systems; operational resilience including business continuity and incident response; and third-party risk management. See our detailed guides on GDPR compliance and security questionnaire automation for deeper coverage of each layer.

What is the difference between supplier due diligence and a security questionnaire?

A security questionnaire is one instrument within a broader supplier due diligence process. Due diligence encompasses the full assessment lifecycle: initial risk classification, questionnaire completion, evidence review, DPA negotiation, ongoing monitoring, and reassessment at renewal. The questionnaire is the structured evidence-gathering phase of that lifecycle. Not the whole process.

How does GDPR affect supplier due diligence?

Under GDPR Article 28, organisations that share personal data with third-party vendors must verify that those vendors provide sufficient guarantees as to the implementation of appropriate technical and organisational measures. Failure to conduct adequate due diligence before engaging a processor is itself a GDPR compliance failure on the part of the controller. Due diligence is therefore both a risk management exercise and a direct legal obligation. The fines for getting this wrong can reach EUR 10 million or 2% of global turnover.

How does the EU AI Act change vendor due diligence?

The EU AI Act requires organisations deploying high-risk AI systems to verify that those systems meet the Act's requirements for risk management, human oversight, transparency, and technical documentation. When those systems are provided by a third-party vendor, that verification must happen through due diligence. Contract clauses alone are not enough. Organisations must actively assess whether the vendor's AI systems meet the required standards. For more detail, see our EU AI Act Guidebook.

Which security questionnaire should I use for vendor due diligence?

The right framework depends on your sector and the vendor's deployment model. The CAIQ is best suited for cloud and SaaS vendor assessments. The SIG is the standard for broad enterprise-wide third-party risk assessment in financial services, healthcare, and large enterprise contexts. The HECVAT is specific to higher education procurement. Many organisations use a combination, particularly when vendors serve multiple markets or handle multiple data types.

How can vendors reduce the time spent on due diligence questionnaires?

Three things make the biggest difference. First, build a centralised response library mapped to your certifications (SOC 2, ISO 27001) and GDPR documentation. Second, publish your security posture proactively in a Trust Center so buyers can self-serve before sending a questionnaire. Third, use security questionnaire automation to pre-populate responses from your existing documentation. Together, these measures can reduce response time from days to hours and cut inbound questionnaire volume significantly.

Related Whisperly Guides

Whether you are sending questionnaires to vendors or responding to them, Whisperly replaces the manual process with a structured, AI-driven workflow. Clients get consistent, comparable vendor risk assessments mapped to GDPR and EU AI Act requirements. Vendors get pre-populated responses drawn from their live compliance documentation, with exceptions routed to the right reviewer. The result: faster due diligence, fewer delays, and a process that improves with every assessment completed.

Book a demo | Explore questionnaire automation | Launch your free Trust Center

| Vendor Security Questionnaire Guide | Complete guide to vendor security questionnaires: what they cover, how frameworks compare, and how to respond efficiently |

Related reading: AI Vendor Risk: How AI Is Redefining Third-Party Assessment explains the three-layer framework for evaluating vendor AI systems against your own governance standard, the EU AI Act, and ISO 42001.