Vendor Due Diligence: What to Collect, Verify, and Record

Vendor due diligence is the process of collecting and checking information about a provider and its proposed service before making or renewing a business commitment. It helps establish what the vendor will do, which risks matter, whether the evidence supports its claims, and what conditions are needed for the relationship.

The review should fit the exposure. A provider handling customer data needs different evidence from one supplying office materials. A vendor administering production systems deserves deeper scrutiny than a service restricted to public information.

This guide focuses on security-related due diligence within the wider process. Financial, operational, legal, and privacy questions should be assigned to the relevant specialists.

Start with the relationship, then request evidence

Before contacting the vendor, establish the service, business owner, data involved, required access, criticality, and intended AI use. Clarify which entity supplies the service and which important subprocessors or dependencies support it.

Use that context to choose a review path. Inherent risk describes the exposure before the safeguards that reduce it are considered. A small contract can still support a critical function or create sensitive access.

Agree the blocking requirements, reviewer responsibilities, and decision authority early. Business requesters should be able to see what information is missing, who needs to respond, and what the next step is.

The vendor tiering guide provides a starting point for defining proportionate review paths.

What should you collect during vendor due diligence?

Collect enough evidence to answer the questions for this relationship. The table is a menu to tailor, not a requirement to request every document from every vendor.

Evidence area	What to request	What to verify
Identity and service	Legal entity, ownership information where relevant, service description, business and security contacts.	The documents and records refer to the provider and service you intend to use.
Data and access	Data flow, information categories, locations, integration scope, administrative access, retention and deletion arrangements.	The description matches the proposed use and contractual terms.
Independent assurance	Relevant SOC reports, ISO certificate and scope, or other applicable assurance evidence.	Scope, period or validity, issuing body, exceptions, and relevant limitations.
Security controls	Appropriate policies, technical configuration evidence, and targeted responses on authentication, encryption, patching, and access.	The evidence addresses the actual service and any controls your organization must configure.
Testing and corrective work	Relevant penetration-test summary, material findings, remediation status, and retest evidence where needed.	Testing coverage and date, unresolved issues, and support for claimed closure.
Incident response and resilience	Notification process, incident contacts, relevant recovery arrangements, and test summaries.	Commitments fit your response and continuity needs, with clear ownership.
Fourth parties	Important subprocessors, model providers, hosting dependencies, locations, and change procedures.	Which parties handle your data or support the critical service, and what remains unknown.
Contracts and approvals	Proposed agreement, data-use terms, security obligations, exit provisions, and any required specialist reviews.	The obligations correspond to the evidence and approved relationship.
External signals	Relevant incidents, exposures, filings, and other credible records.	Entity matching, source date, service relevance, and whether the information is confirmed.

Use an appropriate SaaS vendor questionnaire or SIG-aligned questionnaire where helpful. Adapt questions to the scope and avoid asking vendors to reproduce information already supported by current, applicable evidence.

For ICT suppliers, NIST’s due diligence quick-start guide provides additional considerations spanning ownership and influence, provenance, resilience, foundational cyber practices, and supply chain tiers. Its ICT scope should not be treated as a universal checklist for every vendor type.

How do you review the evidence?

1. Confirm identity, scope, and dates

Check that the evidence covers the legal entity, service, environment, and period relevant to your use. A document for another product or subsidiary may not answer your question.

Record gaps between the evidence date and the proposed engagement. Ask what changed during that interval and what supports the answer. Retain the original evidence and any update separately.

2. Review assurance reports rather than badges

For a SOC 2 report, examine the service and system description, period or date, auditor’s opinion, relevant control testing, exceptions, and customer responsibilities. Check how important subservice organizations are treated and whether further evidence is needed for your use case.

A Type 2 report provides information about operating effectiveness over its specified period. It does not establish that every current service or newly launched AI feature is covered. A subsequent management statement may explain changes but does not extend the audited period.

For ISO certification, inspect the actual certificate, scope, issuing body, and validity. A certification badge alone does not show whether the relevant service and locations are included.

3. Review testing results and closure evidence

Read a testing summary in context: what was tested, when, which material findings remain, and how corrective work was verified. A statement that an issue is “fixed” may need supporting evidence or retesting before it can satisfy a blocking requirement.

Ask focused follow-up questions rather than repeating an entire questionnaire when one gap needs resolution. Link the response and evidence to the finding they address.

4. Reconcile questionnaires, contracts, and configurations

Look for conflicting claims. A vendor may describe encryption or deletion practices that do not match the proposed configuration or service terms. Determine which statement applies, request clarification, and record the resolution.

An external rating is a useful signal. It does not establish the internal controls, data obligations, or permissions for your particular relationship. Conversely, an externally reported issue needs service and entity matching before you assume your organization is affected.

5. Check your organization’s responsibilities

Some safeguards depend on what you configure or do: enforcing authentication, limiting integration permissions, controlling which data users upload, or removing access at exit.

Assign these actions internally and confirm completion where required. Reviewing the provider’s controls cannot compensate for an unmanaged connection in your own environment.

6. Record uncertainty and route the decision

Separate what is verified, what is claimed, and what remains unknown. Missing evidence is not proof of either safety or a failure; its significance depends on the exposure and the requirement being tested.

Send the findings and limitations to the relevant risk assessment and approval process. The vendor risk assessment guide explains how evidence becomes a treatment plan and decision.

How should review depth change for higher-risk vendors?

The labels below are illustrative. Define thresholds and minimum evidence in your policy rather than adopting one fixed vendor-percentage split or review cadence.

Relationship	Suitable review approach	Additional scrutiny
Lower exposure	Confirm the service, owner, limited access or data use, relevant terms, and proportionate baseline requirements.	Investigate any signal or change that challenges the lower-risk classification.
Moderate exposure	Review relevant assurance, data handling, access, incident communication, and service-specific gaps.	Follow up on exceptions and evidence conflicts that affect the intended use.
Higher exposure or critical dependency	Use deeper technical, operational, legal, and privacy review with explicit decision gates.	Validate material controls, recovery arrangements, unresolved findings, dependencies, and the safeguards your organization must apply.
AI-enabled relationship	Add an AI-specific review to the appropriate exposure tier.	Examine training use, retention, model providers, tool permissions, oversight, and change detection.

AI is a scope modifier, not a reason to assume every provider has the same risk. An internal summarizer using public information and an agent accessing production data require different scrutiny.

When a critical vendor cannot supply a SOC 2 report, identify alternative evidence relevant to the requirements: targeted control evidence, technical review, testing, or other assurance. A missing report does not automatically prove the vendor is unsafe. If a material requirement remains unsupported, defer the affected use or route a documented exception to the authorized decision maker.

Enable AI use with a clear due diligence path

Collect the intended AI use case, data flow, model-provider dependencies, retention and training-use terms, and any tools or actions the system can execute. Security, legal, and privacy should review the same scope and evidence.

Confirm which settings and contractual terms apply to your deployment. If the AI feature is optional, distinguish approval of the underlying service from approval of that feature. Reuse relevant evidence while reviewing the changed exposure.

Define monitoring and reassessment triggers from the start. New models, subprocessors, permissions, or data use may require review after approval. This creates a repeatable route to adoption while keeping oversight current.

Use the AI and LLM vendor risk questionnaire to structure the review.

A practical vendor due diligence checklist

Use this short checklist to structure the work. Assign an owner and evidence reference for each relevant item, and record the reason for any not-applicable response.

Scope and tier

• Confirm the supplying legal entity, service, and security contact.
• Identify the business owner and intended use, including any AI features.
• Map data categories, access, locations, and critical dependencies.
• Assign the review tier and identify requirements that block the proposed use.

Evidence review

• Collect the assurance and technical evidence required for that tier.
• Check the relevant service scope, dates, exceptions, and limitations.
• Confirm how important subprocessors and downstream providers are covered.
• Check material testing findings and evidence supporting corrective work.
• Compare questionnaire claims with contracts and relevant configurations.
• Review external signals for identity, relevance, source date, and uncertainty.

AI and internal safeguards

• Where AI is used, check retention, training use, model providers, and action permissions.
• Confirm the controls and settings your organization must implement.
• Verify blocking prerequisites before the affected data or access is enabled.

Decision and follow-through

• Record open gaps, missing evidence, owners, and treatment options.
• Route the assessment and any exception to the authorized decision maker.
• Retain the rationale, approval, evidence versions, and permitted scope.
• Set scheduled reviews and triggers for incidents or material changes.
• Assign exit responsibilities for access removal and data disposition.

For the full lifecycle working document, use the existing vendor risk assessment checklist. The shorter checklist above focuses on collecting and validating the information needed for a decision.

Keep due diligence scalable and audit-ready

Maintain one evidence record for each relevant service and relationship, with dates, scope, and owners. Reuse it when it still supports the question, and refresh it when material changes occur.

Automate request distribution, reminders, document organization, and reviewer routing where appropriate. Reserve specialist time for significant findings, disputed evidence, sensitive access, and exceptions. Measure the work released and coverage gained alongside review quality.

Capture decision evidence as the workflow progresses. An audit record should show what was reviewed, why the decision was made, who approved it, and what happened to outstanding findings. This reduces the need to reconstruct the history during an examination or incident.

Monitor relevant changes after onboarding and renewal. Due diligence supplies the evidence foundation; ongoing vendor risk management keeps it useful as the relationship evolves.

How SAFE supports vendor due diligence

The SAFE TPRM AI Co-Worker supports evidence collection, document and questionnaire review, conflict detection, and vendor follow-up. Agentic Workflows preserve relationship context through monitoring and remediation, while people define policies, approval boundaries, and material exception handling.

Frequently Asked Questions

What if the vendor has no assurance report?

Can we reuse due diligence for a renewal?

Does due diligence end when the contract is signed?