Skip to main content
Bureau of AI
Category: Third-Party & Supply Chain

Vendor Due Diligence

Also known as: VDD, third-party vendor due diligence
Simply put

Vendor due diligence is the process of investigating and evaluating a third-party vendor before, and sometimes during, a business relationship to make an informed decision about whether to engage them. It helps organizations understand a vendor's characteristics and risks so they can reduce the likelihood of problems arising from the relationship. Note that the term is used in more than one sense: in some contexts it refers to a buyer's pre-contract evaluation of a supplier, while in others it refers to a seller-side exercise conducted as part of a sale process.

Formal definition

Vendor due diligence (VDD) commonly refers to the structured investigation and evaluation of a third-party vendor conducted prior to and during engagement to inform contracting and onboarding decisions and to identify and mitigate risks arising from the relationship. In much of the risk-management literature it denotes the buyer-side, pre-contract and onboarding assessment of a specific vendor's suitability. In transactional and sell-side contexts, the same term can denote a seller-commissioned exercise intended to provide transparency and reduce risk in a sale process; practitioners should confirm which sense applies in a given setting. As a risk control, VDD reduces or manages exposure rather than eliminating it. The evidence provided does not specify AI- or model-specific due-diligence procedures, so any application to AI vendors or model providers should be treated as an extension of the general concept rather than as an established, separately defined practice here.

Why it matters

Vendor due diligence matters because organizations increasingly depend on third parties for functions that can carry material operational, legal, security, and reputational exposure. A structured evaluation before entering a relationship helps a business make an informed decision about whether to engage a vendor and understand the risks that relationship may introduce. Without it, an organization may discover problems only after contracting and onboarding, when remediation is more costly and options are narrower.

It is important to recognize that the term carries more than one meaning, and conflating them can lead to scoping errors. In much of the risk-management literature, VDD refers to a buyer-side, pre-contract and onboarding assessment of a specific vendor's suitability. In transactional and sell-side contexts, the same term can denote a seller-commissioned exercise intended to provide transparency and reduce risk in a sale process. Practitioners should confirm which sense applies in a given setting before designing or relying on a due-diligence workflow, because the objectives, audience, and deliverables differ.

As a risk control, vendor due diligence reduces or manages exposure rather than eliminating it. It informs decisions and helps identify issues, but it does not guarantee that a relationship will be free of problems. Treating a completed due-diligence exercise as a one-time assurance rather than as an input to ongoing risk management is a common pitfall; the evidence indicates the process can occur both before and during a relationship.

Who it's relevant to

Third-Party and Vendor Risk Managers
These professionals own the buyer-side evaluation of vendors before and during engagement. Vendor due diligence gives them a structured way to investigate a vendor's characteristics and risks so they can inform contracting and onboarding decisions. They should treat the process as a risk control that reduces exposure rather than eliminating it, and consider whether evaluation continues during the relationship rather than ending at onboarding.
Procurement and Contracting Teams
For teams deciding whether to engage a specific vendor, VDD in its buyer-side sense supports the pre-contract and onboarding decision. It provides the investigative basis for judging vendor suitability and identifying risks that may need to be addressed in contract terms. These teams should confirm they are applying the buyer-side sense of the term rather than a sell-side transactional sense.
M&A and Transactional Legal Professionals
In transactional and sell-side contexts, vendor due diligence can refer to a seller-commissioned exercise conducted as part of a sale process to provide transparency and reduce risk. Professionals working on transactions should be explicit about which sense of VDD is in play, since the objectives, audience, and deliverables differ from a buyer's pre-contract assessment of a supplier.
AI Governance and Model Risk Professionals
Those evaluating AI vendors or model providers may draw on vendor due diligence as a general concept, but should note that the evidence here does not define AI- or model-specific due-diligence procedures. Any application to AI vendors should be treated as an extension of the general practice rather than an established, separately defined method, and framed as a measure that manages rather than removes risk.

Inside VDD

Vendor Risk Assessment
An evaluation of the risks a third-party AI or model provider introduces to the acquiring organization, typically spanning operational, compliance, reputational, security, and model-specific risks. In model risk management contexts, this includes assessing whether externally sourced or vendor-developed models fall within the organization's model inventory and require the same validation rigor as internally built models.
Documentation and Transparency Review
Examination of the documentation a vendor provides about how a model was developed, tested, and intended to be used, including data provenance, methodology, assumptions, and known limitations. Because vendor models are often less transparent than in-house models (the 'black box' problem commonly noted in guidance such as SR 11-7), practitioners assess whether the documentation is sufficient to support independent understanding and, where possible, validation.
Validation and Testing Considerations
Assessment of what testing the acquiring organization can perform on a vendor-supplied model, given that full access to underlying code or training data may be restricted. This may involve reviewing the vendor's own validation evidence, conducting outcome analysis or benchmarking on the organization's own data, and identifying gaps that cannot be independently verified.
Contractual and Accountability Provisions
Terms governing responsibilities, service levels, audit rights, data handling, change notification, and remediation. These provisions typically address who is accountable for model behavior and how the organization retains oversight, recognizing that outsourcing model development generally does not transfer the accountability for using the model.
Ongoing Monitoring and Reassessment
Processes for continued oversight after onboarding, including monitoring for performance changes, vendor updates to the model, and changes in the vendor's own risk posture. Due diligence is commonly treated as a lifecycle activity rather than a one-time gate at procurement.
Governance Integration
The organizational structures, roles, and escalation paths that connect vendor due diligence outcomes to accountability and oversight functions. This is where AI governance (defining who owns the decision and how oversight operates) and model risk management (measuring and controlling the model-specific risk) intersect without being identical.

Common questions

Answers to the questions practitioners most commonly ask about VDD.

Is vendor due diligence the same as validating a third-party model?
No, and professionals frequently blur these. Vendor due diligence typically assesses the vendor as an organization and counterparty—covering aspects such as financial viability, security posture, documentation quality, support arrangements, and the vendor's own governance practices. Model validation, by contrast, is the independent assessment of a model's conceptual soundness, performance, and fit for its intended use. Due diligence may inform or feed into validation (for example, by surfacing the documentation needed to validate a third-party model), but it does not substitute for it. In many model risk frameworks, an institution remains responsible for validating externally sourced models regardless of vendor assurances, so treating vendor attestations as a replacement for independent validation is a common pitfall.
Does completing vendor due diligence transfer or eliminate the risk of using a third-party model or AI system?
No. Due diligence is a risk-reduction and risk-understanding measure, not a risk-transfer mechanism. In most governance and model risk frameworks, accountability for outcomes from a third-party model or system generally remains with the adopting institution even when the tool is externally developed. Contractual terms may allocate certain liabilities, but they do not remove the institution's operational, reputational, or supervisory exposure. Due diligence helps an organization understand and manage residual risk; it does not make that residual risk disappear, and it should not be presented internally as doing so.
What information should an organization typically request from a vendor during due diligence?
Requests commonly include model or system documentation (intended use, design, limitations, and known constraints), evidence of the vendor's own testing and performance monitoring, data provenance and handling practices where disclosable, security and access-control information, information on how updates or model changes are communicated, and details of support and escalation processes. Where the vendor treats aspects as proprietary, the organization typically documents these disclosure gaps as limitations and considers whether they can be mitigated through compensating controls or additional independent testing. The specific set of requests varies by the risk tier assigned to the use case and by applicable sector expectations.
How should due diligence differ for higher-risk versus lower-risk vendor tools?
Many organizations apply a proportionate, risk-based approach, calibrating the depth of due diligence to the assessed inherent risk of the use case. Higher-risk deployments—for example those affecting significant decisions, larger populations, or regulated activities—typically warrant more extensive documentation review, independent testing where feasible, closer scrutiny of the vendor's controls, and more frequent reassessment. Lower-risk tools may be handled through lighter-touch review. The tiering criteria and thresholds are generally defined by the organization's own governance policies rather than being fixed across all frameworks.
How is vendor due diligence typically integrated with ongoing monitoring rather than treated as a one-time exercise?
Due diligence is commonly framed as a lifecycle activity rather than a single gate at onboarding. Practices often include periodic reassessment, monitoring of vendor-communicated model changes or updates, tracking of performance and any observed degradation over time, and review triggered by material events such as security incidents or changes in the vendor's ownership or viability. Integrating due diligence with ongoing monitoring helps organizations detect when a previously acceptable tool no longer meets requirements. The cadence and triggers are typically set in internal policy and may reflect the risk tier of the use case.
How do the three lines of defense typically relate to vendor due diligence responsibilities?
In organizations that use a three-lines model, responsibilities are commonly distributed rather than concentrated. The first line—those who own and operate the vendor relationship or the deployed tool—typically conducts the primary due diligence and manages day-to-day controls. The second line—such as risk management or compliance functions—often sets standards, challenges the first line's assessments, and provides oversight. The third line—internal audit—typically provides independent assurance that the due diligence process itself is designed and operating as intended. The precise allocation varies by organization, and smaller institutions may combine functions while preserving independence where possible.

Common misconceptions

Using a vendor's model transfers the risk and accountability to the vendor.
In many frameworks, including guidance commonly applied in banking such as SR 11-7, an organization that uses an externally developed model generally remains accountable for its use and is typically expected to subject it to comparable risk management, even though development was outsourced. Contractual provisions allocate certain responsibilities but do not eliminate the acquiring organization's oversight obligations.
If a vendor provides its own validation report, the acquiring organization does not need to validate the model.
A vendor's validation evidence is an input to due diligence, not a substitute for independent assessment. Practitioners typically still evaluate the model against their own use case and data, and where independent testing is constrained by limited access, that limitation is documented rather than treated as full validation coverage. Reviewing vendor documentation (verification of provided evidence) is also distinct from independently confirming the model performs as intended in the organization's context.
Vendor due diligence is a one-time procurement checkpoint.
Due diligence is commonly treated as an ongoing lifecycle activity. Vendor models can be updated, retrained, or degrade in performance over time, and the vendor's own risk posture can change, so many frameworks call for periodic reassessment and continued monitoring rather than a single point-in-time review.

Best practices

Include vendor-supplied and vendor-developed models in the model inventory and apply risk-tiered scrutiny comparable to that used for internally built models.
Obtain and critically review vendor documentation on data provenance, methodology, assumptions, intended use, and known limitations, and explicitly record where transparency is insufficient for independent understanding.
Where full access to code or training data is restricted, perform outcome analysis or benchmarking on your own data and document which risks could not be independently verified.
Negotiate contractual provisions that preserve oversight, including audit rights, change and update notification, data handling terms, and clear remediation responsibilities.
Clarify and document accountability internally, recognizing that outsourcing development does not transfer the organization's responsibility for using the model.
Establish ongoing monitoring and scheduled reassessment to detect performance changes, model updates, and shifts in the vendor's risk posture after onboarding.