Third-Party Risk Management Checklist

Start before the vendor is committed

A supplier review is most useful while the business can still change the scope, terms or provider. Beginning after a contract is signed often turns due diligence into a search for reasons to approve an existing decision.

NIST SP 800-161 Revision 1, Update 1 treats cybersecurity supply-chain risk through the lifecycle.¹ The checklist below adapts that approach for a business vendor relationship. It is an original management aid, not a complete legal or regulatory checklist for every industry.

1. Record the proposed use

Ask the requester what the supplier will do, which business process depends on it and why it is needed. Identify the service owner, purchasing owner and the people who must review security, privacy or contractual issues.

Capture expected information access, integrations, administrative privileges, locations and important subcontractors. If the proposed use is unclear, clarify it before sending a generic questionnaire.

A public scheduling tool used without confidential data differs from a payroll processor or an administrator with production access. Brand reputation alone does not determine the exposure.

2. Set inherent criticality before evaluating assurances

Assess what could happen if the service fails or the access is misused, before considering the supplier's controls. Think about interruption, information sensitivity, substitutability, financial effects and obligations.

Keep that criticality separate from the later assessment of safeguards. A critical provider does not become noncritical because it supplies a report. The report may affect the remaining risk, while the business dependence stays significant.

Intake factor	Question to ask
Service dependence	What stops if the vendor is unavailable?
Information	What data is received, stored or processed?
Access	Can the vendor administer systems or change important records?
Replaceability	How quickly could another provider or manual process work?
Chain dependencies	Which subcontractors or platforms are material?
Obligations	Which contracts, laws or policies affect the relationship?

3. Perform proportionate due diligence

Choose the review depth from the exposure and relevant requirements. NIST's final July 2026 SP 1326 provides due-diligence considerations specifically for ICT suppliers.² Its scope should not be mistaken for a universal legal requirement for all vendors.

For a low-impact relationship, a focused public-information review and basic confirmations may be appropriate. For sensitive data or critical access, obtain more detailed evidence, specialist review or contractual safeguards through the normal approval process.

Document sources and limitations. A supplier statement is evidence of its claim, not independent verification. The audit-evidence guide explains source and coverage distinctions. Ask whether important assurances cover the exact service, environment and period you intend to use.

4. Evaluate answers and evidence together

The vendor questionnaire guide provides a focused question set and answer-evaluation method. Ask for explanations where yes/no answers hide scope. “Encrypted” raises questions about which information, where, who manages access and what remains outside coverage. “Backed up” should lead to recovery scope and tested usability.

If a supplier supplies a SOC report or ISO certificate, check organization, service or system scope, relevant dates and any conditions or exceptions. Do not treat a badge as approval of every use you might propose.

Use a clear disposition: supported, partly supported, not yet checked, or unresolved. Record what would change the conclusion. Missing evidence should not receive the same status as evidence that demonstrates a failure, although both may require action.

5. Agree responsibilities and terms

Work with qualified legal and commercial advisers on relevant terms. Consider service commitments, incident communication, permitted information use, subcontractors, return or deletion of records and exit assistance where they matter to the relationship.

Avoid inventing universal notice periods or legal clauses. Requirements vary with jurisdiction, data, role and contract. Record the agreed requirement and the source of the interpretation.

Confirm responsibilities on your side. You may still need to configure permissions, review users, maintain an export or monitor the relationship. Outsourcing the service does not outsource every decision.

Worked example: a payroll provider

This fictional business proposes a new payroll processor. The provider will handle staff records and supports a time-sensitive payment process, so the relationship is critical even if the provider has a strong reputation.

Review observation	Decision or action
Provider supplies a current report for the proposed service	Authorized reviewer checks scope and relevant responsibilities
Data export is available but has not been tested	Finance runs an approved synthetic export before full reliance
Incident contact is a general inbox	Agree an appropriate escalation route in the relationship
Internal access has not been assigned	Name administrators and restrict roles before onboarding
Exit timing is uncertain	Clarify transition dependencies and record an interim condition

The approval record identifies the decision authority, conditions, owners and review date. It does not say “zero vendor risk.” If conditions are unmet, the agreed governance process decides whether onboarding waits or a limited use is permitted.

6. Onboard through the normal access process

Limit access to the approved purpose and scope. Use existing authority for credentials, integrations and information transfer. Confirm that technical configuration matches the relationship reviewed.

Record completion evidence, including owner contacts and operational instructions. If the actual implementation differs from the assessed design, return for review rather than silently expand approval.

NIST CSF 2.0 includes governance outcomes relevant to supplier risk.³ Use that business-level framing to connect purchasing, technology and leadership decisions, while retaining the actual obligations and approval rules that govern your organization.

7. Monitor changes and performance

Set review frequency from criticality and change rate, rather than a universal annual rule. Define triggers such as service incidents, new data types, ownership changes, material subcontractors or a changed integration.

Track outstanding conditions and expiring evidence. A review date should lead to a decision about continued use, further work or changed scope, not simply renew an earlier green status.

Keep business performance alongside security questions. Frequent service interruption may matter even when a provider's security documentation is current.

8. Plan exit and revoked access

Identify how information is exported, returned or deleted; who verifies the outcome; and which accounts, integrations and keys must be revoked. Confirm the plan against actual contract and technical capabilities.

Test a safe part of the exit process before the relationship becomes hard to replace. An export file that cannot be interpreted is not a usable transition plan.

Retain the appropriate closure records under your retention requirements. Do not leave obsolete access in place because the commercial contract has ended.

A compact supplier decision record

Record proposed use, inherent criticality, evidence inspected, unresolved questions, responsible reviewers, authorized decision and conditions. Add action owners, completion criteria, the next review and change triggers.

That record makes the relationship reviewable over time. A questionnaire is one input; the accountable decision and maintained boundaries are what make third-party risk management work.

Sources and references

NIST. Cybersecurity Supply Chain Risk Management Practices, SP 800-161 Revision 1, Update 1 (2024-11-01). Current guidance treats supplier risk through its lifecycle; supports risk-based due diligence and monitoring. ↩
NIST. Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, SP 1326 (2026-07-08). Final July 2026 guide concerns ICT suppliers and risk-prioritized due diligence; not a general legal checklist for every supplier. ↩
NIST. The NIST Cybersecurity Framework (CSF) 2.0 (2024-02-26). Primary framework: outcomes, six functions, profiles and tiers; not a certification. ↩