Vendor Due Diligence: A Practical Checklist

Vendor due diligence is the documented process of learning enough about a supplier to make and revisit an informed decision. Start with the service, your dependence on it, the data it handles, and the access it needs. Scale the review to the consequences of interruption or compromise; a low-risk office service does not need the same investigation as a supplier that processes sensitive information or administers critical systems.

For ICT suppliers, NIST defines cybersecurity supply chain risk management (C-SCRM) due diligence as research and verification of pertinent supplier or product information to inform acquisition decisions. Its five assessment areas are foreign ownership, control, or influence; provenance; resilience; foundational cyber practices; and supply-chain tiers. NIST SP 1326 is scoped to ICT suppliers and supplements SP 800-161 Revision 1; it is not a universal legal checklist for every vendor or a substitute for a full supply-chain risk assessment. (NIST SP 1326; publication record.)

1. Scope the relationship

Write down what the supplier will do before sending questionnaires. This frames the evidence you need and helps avoid collecting information unrelated to the decision.

What business outcome will the vendor provide? Which teams and processes depend on it?
What systems, facilities, or data will it access? Does it handle personal, financial, regulated, or otherwise sensitive information?
What would a service interruption, compromise, or supplier failure mean for customers, operations, finances, or legal obligations?
Who owns the business decision? Who must review security, privacy, legal, procurement, and operational issues?
What review effort is proportionate to the vendor’s criticality and your available resources?

For ICT suppliers, NIST describes due diligence as a minimum research layer before a more complete supplier review. Use it to identify questions and concerns; do not treat a desktop check as the whole assessment for a critical supplier.

2. Choose a review level

Start with public information for every relationship, then add evidence gathering where the risk justifies the time and cost. NIST describes basic due diligence as desktop research using publicly available information. Enhanced due diligence can add commercial datasets, proprietary sources, and supply-chain illumination tools. Corroborate material findings with more than one source where possible.

Review level	Typical work	Use when
Basic	Confirm identity and service; review public security, incident, vulnerability, ownership, and location information relevant to the relationship; record sources and unknowns.	The service has limited business impact, little sensitive data, and no broad system or facility access.
Enhanced	Request scoped evidence and contract commitments; interview relevant owners; investigate dependencies, recovery, and data flows; use commercial or proprietary research sources where they fill material gaps.	The supplier is important, handles sensitive data, has privileged access, or a failure would have substantial consequences.
Specialist or full review	Involve security, privacy, legal, procurement, or supply-chain specialists; examine ICT product and sub-tier risks; set conditions, mitigations, and monitoring before approval.	The relationship is critical, highly regulated, difficult to replace, or has unresolved high-impact concerns.

These levels are a practical way to organize effort, not a NIST scoring scheme. Define your own concern levels and escalation thresholds based on your risk tolerance.

3. Verify supplier identity and context

Confirm the legal name, public identity, website, headquarters, operating locations, and relevant parent or subsidiary relationships.
Check that the entity you researched is the entity that will contract, process data, provide support, and receive access. Note any differences.
For public-sector procurement or other applicable transactions, check relevant exclusion, sanction, or procurement status using the resources that apply to your jurisdiction and buyer. NIST SP 1326 discusses U.S. government screening resources; applicability depends on the transaction.
For ICT suppliers, examine ownership, control, or influence; where the supplier and product operate or are produced; relevant components and supply-chain tiers; and whether the available information is sufficient to understand provenance.
Label each item as a verified fact, supplier assertion, third-party report, or unknown. Record the source and date, and corroborate important claims where possible.

A supplier’s website or questionnaire is useful evidence of what it claims, but it does not independently verify the claim. Record uncertainty explicitly instead of converting missing information into a pass.

4. Examine capability, security, and resilience

Ask for evidence tied to the actual service, product, locations, and period in scope. A certification logo or a completed questionnaire alone may not show whether the relevant system or control was assessed.

What public information exists about security practices, incidents, vulnerabilities, and remediation relevant to the service?
What evidence supports claimed controls? Record the document or evidence type, its scope, date, exclusions, and any independent validation it represents.
How does the supplier detect, report, and respond to incidents that could affect you? Who is contacted, through what channel, and under what agreed timeline?
What support, continuity, backup, recovery, and service restoration commitments apply? Are they appropriate to your dependency?
For an ICT supplier, assess foundational cyber practices, product and organizational resilience, and supply-chain dependencies using NIST’s categories.
What material gaps remain, who owns each follow-up, and what evidence would resolve it?

CISA’s SMB vendor supply-chain material describes a template and spreadsheet for assessing ICT hardware, software, and services, with yes, no, and partial response options. It may help a small organization structure evidence requests. Treat partial responses as items to understand, not automatic passes. (CISA fact sheet.)

5. Map data and restrict access

Ask what information crosses the supplier boundary and what access the supplier needs to deliver the service. The FTC recommends understanding what personal information a business holds, how it moves through the business, and who can access it; keep only what is needed and only as long as needed. (FTC guide to protecting personal information.)

What data will the vendor collect, receive, create, or access? Where is it stored and processed, and which people or subcontractors can access it?
Can you reduce data fields, privileges, environments, locations, or access duration without breaking the service?
How will accounts be approved, monitored, limited to the work period, and removed when the work ends?
What encryption protects data and the access path? Is multifactor authentication required for vendor access to business networks?
What are the rules for the vendor’s use, sharing, sale, retention, and deletion of your data? How can you verify those rules are followed?
For personal information, map its flow, retain only what the business needs, and define retention and secure disposal.

The FTC specifically recommends limiting vendor access to what is needed and for the time it is needed, and properly configuring encryption and multifactor authentication for vendor access to business networks. (FTC vendor security guidance.)

6. Put requirements into the agreement

Translate material expectations into written terms that match the service and applicable law. The FTC recommends putting vendor security expectations in writing, specifying how vendors may use, share, retain, and delete data, and verifying that contractual expectations are followed. Its general guidance does not prescribe one clause for every contract or settle the legal requirements for a particular industry.

Name required security practices or standards clearly, including how controls will be evaluated and updated.
Specify permitted data uses and sharing, retention and deletion, and any required confirmation of disposal.
Set access conditions, evidence expectations, and verification rights appropriate to the relationship.
Agree how the vendor will communicate incidents and material changes in controls, ownership, service, or relevant subcontractors.
Define support, continuity, and recovery commitments where interruption would affect your operations.
Assign owners and a process for checking compliance during the relationship; do not rely only on initial assurances.

Have qualified legal and privacy reviewers adapt terms to the transaction. The checklist identifies issues to address; it is not legal advice or a ready-made contract clause.

7. Decide, document, and revisit

Keep a concise decision record that another reviewer can understand later. NIST recommends a due-diligence report template, concern levels, and consideration of continuous monitoring; it does not prescribe a universal risk score or reassessment interval.

Record the relationship scope, findings, sources and dates, evidence gaps, and whether each item is verified, asserted, reported, or unknown.
Assign concern levels using your organization’s own risk tolerance. Explain what makes a concern material and what would change the decision.
Document the decision, approver, conditions for proceeding, mitigations, accountable owners, and unresolved questions.
Choose a refresh schedule or event triggers proportionate to criticality and access. Triggers might include a material service or ownership change, a relevant incident, a new data use, or a change in access; choose those that fit your relationship.
Escalate unresolved concerns, narrow access, request more evidence, add contract conditions, or select another supplier through your normal risk decision process.

8. Use this working checklist

Scope: service, dependency, data sensitivity, access, impact of failure, business owner, reviewers.
Set effort: basic public research or enhanced evidence gathering, based on criticality and available resources.
Confirm identity: legal entity, locations, parent relationships, applicable procurement checks.
Review evidence: security, incidents, vulnerabilities, remediation, resilience, recovery, ICT provenance and tiers when relevant.
Map exposure: data flows, storage and processing locations, people and subcontractors with access, privileges and access duration.
Set requirements: security, data use and sharing, retention and deletion, incident communication, verification, and change notification.
Record the decision: concern levels, sources and dates, unknowns, conditions, owners, and approval.
Revisit: define refresh triggers or a schedule appropriate to the relationship’s risk.

9. Compare suppliers on the same questions

Use the same evidence axes for alternatives so a polished presentation does not outweigh material gaps. A comparison can include:

Business criticality and dependency.
Types and sensitivity of data, and the supplier’s data-use, retention, and deletion commitments.
Degree and duration of system or facility access.
Ownership and relevant jurisdictional exposure.
For ICT products, provenance and visibility into sub-tier dependencies.
Security evidence scope and date, incident response, and recovery capability.
Ability to verify commitments and resolve open evidence gaps.

These axes combine NIST’s ICT supplier categories with FTC recommendations on vendor security and personal information. The right supplier is the one whose documented residual risk fits your requirements and risk tolerance, not simply the one with the longest questionnaire response.

10. Where website evidence fits

Public supplier pages, product documentation, security pages, and status information can be part of basic desktop research. A screenshot can preserve what a public page displayed at a review time for an internal record. It does not authenticate the page, validate a security control, prove a supplier’s claim, or replace appropriate evidence from the vendor. Record the page URL and capture date alongside the image.

Capture a page with your own browser setup

For a one-off capture, open the public page in a browser and save a screenshot using the browser’s built-in capture or print controls. For repeatable captures, use a browser automation library. This Python example uses Playwright to visit a page and save a full-page PNG; install Playwright and its Chromium browser first:

python -m pip install playwright
python -m playwright install chromium

import asyncio
from playwright.async_api import async_playwright

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page(viewport={"width": 1440, "height": 1000})
        await page.goto("https://example.com", wait_until="networkidle", timeout=60000)
        await page.screenshot(path="supplier-page.png", full_page=True)
        await browser.close()

asyncio.run(main())

Use a page you are authorized to access. Public pages may change or behave differently by region, session, or time; preserve the capture timestamp and source URL. Do not enter supplier credentials into an untrusted capture environment.

Or skip the browser setup

Use ScreenshotNeo, a website screenshot API and MCP server from Yorker Media. One GET request captures a URL as an image or PDF. See the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers identify the page verdict and billing status. AI agents can use its MCP server tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000.

11. Troubleshooting due diligence gaps

Problem	Why it happens	What to do
The vendor provides only a questionnaire.	Answers may be self-reported and may not establish scope, date, or independent validation.	Ask for evidence relevant to the service and record its scope, date, exclusions, and validation. Mark unsupported claims as unverified.
A control report covers a different product or entity.	The evidence scope does not match the service or contracting supplier under review.	Ask the supplier to explain the boundary and provide applicable evidence; note exclusions and any remaining gap.
Ownership or supply-chain details are unclear.	Public sources may not expose parent relationships, manufacturing locations, or sub-tier dependencies.	Request relevant information, corroborate material claims where possible, and escalate based on ICT criticality and your tolerance for unknowns.
The supplier answers “partial.”	A requirement may exist only in some systems, locations, or circumstances.	Ask what is partial, what is excluded, who owns remediation, and by when. Do not treat partial as a pass.
The vendor needs broad or persistent access.	The service design may bundle permissions or leave support accounts active.	Ask whether access can be narrowed by role, environment, data, and time. Use monitoring and remove access when it is no longer needed.
There is no clear deletion answer.	Backups, subprocessors, or operational logs may have different retention cycles.	Specify what must be deleted, applicable retention limits, treatment of backups and subprocessors, and how completion will be verified.
The review stalls on too many questions.	The request may be broader than the actual service risk.	Return to scope and prioritize questions tied to sensitive data, privileged access, material dependency, and the consequence of failure.

12. Performance, reliability, and cost of the process

Due diligence consumes staff time and may require paid datasets or specialist help. NIST recommends matching effort to supplier criticality and available resources. Reduce wasted effort by scoping the service first, reusing current evidence where its scope fits, asking focused questions, and escalating only material gaps. Higher-risk or ICT supplier reviews may benefit from commercial datasets, proprietary sources, or supply-chain illumination tools; treat these as optional aids, not substitutes for judgment or source verification.

Public web captures are inexpensive to repeat but are snapshots, not proof that a claim is true or that a page existed unchanged at another time. Keep the URL, capture time, and review notes with the record. For supplier evidence, record the source date and applicability so stale or out-of-scope material does not create false confidence. Set a refresh approach around material changes and criticality; neither NIST nor the FTC guidance cited here establishes one interval for every vendor.

Frequently asked questions

Is vendor due diligence the same as a full risk assessment?

No. It is an information-gathering and verification step that informs an acquisition or continuing relationship decision. For ICT supply-chain risk, NIST positions due diligence as a minimum layer before more complete supplier review.

Does every vendor need the same checklist?

No. Use a consistent core record, then scale evidence requests to the service, data, access, dependency, and consequences of failure.

How often should a vendor be reassessed?

Set a schedule or event-driven refresh that fits the relationship’s criticality and access. The cited NIST guidance does not prescribe one universal interval.

Does a certification prove a supplier is safe?

No single certificate establishes that every relevant service, system, location, or current risk is covered. Check its scope, date, exclusions, and relationship to the service you are buying.

Sources and scope

NIST SP 1326, Due Diligence Assessment Quick-Start Guide, final, July 8, 2026. It is focused on ICT suppliers.
NIST publication record, including scope and authors.
FTC, Cybersecurity for Small Business: Vendor Security.
FTC, Protecting Personal Information: A Guide for Business.
CISA, Assisting Small and Medium-sized Businesses Assess Vendors and Suppliers Fact Sheet.