Vendor Risk Assessment Template: A Practical Third-Party Due Diligence Workflow

Overview

Third-party due diligence should be proportionate to the risk a vendor introduces. A company that receives only basic business contact details should not follow the same review path as a cloud platform that stores customer records, connects to production systems, or supports a critical business process.

Use the workflow below as a reusable vendor risk assessment template. Adapt the questions to your environment, document the reasoning behind each decision, and keep the completed assessment with the vendor record. The goal is not to collect documents for their own sake. The goal is to determine whether the vendor’s controls, contract terms, and operating practices are suitable for the proposed relationship.

For broader program design, see the third-party risk management program checklist. If cloud services are involved, also map responsibilities using the cloud compliance controls mapping guide.

Core assessment record

• Vendor name, service name, owner, and procurement contact.
• Business purpose and the process the service supports.
• Types of data involved, including personal, confidential, regulated, or authentication data.
• Systems, accounts, integrations, and network access required.
• Countries or regions where data is accessed, processed, or stored, when relevant.
• Contract status, renewal date, and termination dependencies.
• Inherent risk rating, residual risk rating, reviewer, decision, and approval date.

Risk-tiering criteria

Assign an initial risk tier before sending a long questionnaire. A simple three-tier model is usually easier to operate than a complicated score that reviewers interpret inconsistently.

• Low risk: No sensitive data, no privileged access, limited operational dependency, and no material connection to customer-facing systems.
• Moderate risk: Access to internal information, business data, standard integrations, or a process where disruption would cause meaningful inconvenience.
• High risk: Personal or regulated data, production or administrative access, critical operations, customer-facing functionality, significant concentration risk, or dependence on subcontractors that perform important processing.

Risk tiers should guide the depth of review rather than replace judgment. A low-volume vendor may still require a higher tier if it has privileged access or handles particularly sensitive information.

Checklist by scenario

Scenario 1: Low-risk supplier

For a supplier with no sensitive data or system access, confirm the basics without creating unnecessary friction:

• Verify the business owner and intended use.
• Confirm what information the vendor will receive, if any.
• Check whether the service uses accounts, browser extensions, integrations, or local software.
• Review the supplier’s basic security contact and incident-notification process.
• Record the rationale for the low-risk classification.

Scenario 2: Vendor processing company or customer data

Request enough information to understand the data lifecycle and privacy obligations:

• Document the categories of personal and confidential data involved.
• Identify the purpose of processing, retention period, deletion method, and access locations.
• Confirm whether the vendor uses subprocessors and how changes are communicated.
• Review the data processing agreement or equivalent contractual terms.
• Check support for access, correction, deletion, export, and incident-response requests where applicable.
• Update the relevant records of processing activities. The records of processing activities checklist can help structure this review.
• Consider whether a DPIA is needed for the proposed processing. Use the DPIA checklist as a decision aid.

Scenario 3: Cloud platform or production integration

Focus on control effectiveness and the division of responsibilities:

• Request a current security overview, independent assurance report, or control summary where available.
• Review identity, authentication, authorization, privileged access, and administrator logging.
• Confirm encryption practices, key responsibilities, backup coverage, and recovery expectations.
• Understand vulnerability management, penetration testing scope, monitoring, and incident escalation.
• Document which controls are operated by the vendor and which remain with your organization.
• Confirm how access is removed and data is returned or deleted at termination.

When a vendor will receive administrative access, compare its controls with your own access standards. The privileged access review checklist provides useful questions for that part of the assessment.

Scenario 4: Vendor cannot answer every question

Incomplete questionnaire answers should trigger analysis, not an automatic rejection. First, separate unanswered questions into three groups: not applicable, unavailable but supported by alternative evidence, and genuinely unknown.

• Ask the vendor to explain why a question is not applicable or cannot be answered.
• Accept alternative evidence when it addresses the same control objective, such as a policy excerpt, configuration description, audit report, or implementation statement.
• Prioritize unanswered questions connected to data exposure, privileged access, resilience, incident response, and contract commitments.
• Document compensating controls, limitations, owner, due date, and residual risk.
• Require business, security, privacy, or legal approval before accepting a material gap.
• Use a time-limited exception when the risk is understood and remediation has a clear owner.

Do not treat a completed questionnaire as proof that controls work. Validate important responses with evidence and, where appropriate, a focused review or demonstration.

What to double-check

Before approval, review the assessment for gaps that are easy to miss:

• Data flow: The service description, contract, privacy documentation, and actual integration should describe the same data and processing purpose.
• Access scope: Confirm whether access is read-only, administrative, API-based, persistent, or temporary. Verify that the requested permissions are necessary.
• Subcontractors: Identify providers that host, support, monitor, or process information on the vendor’s behalf.
• Incident handling: Confirm notification contacts, escalation paths, expected cooperation, and evidence preservation responsibilities.
• Resilience: Check backup frequency, restoration testing, recovery expectations, and dependencies. See the backup and restore audit checklist for additional prompts.
• Termination: Specify data return, deletion, account removal, certificate handling, and assistance with transition.
• Evidence dates: Record when documents were issued, what period they cover, and whether they apply to the relevant service and environment.
• Contract alignment: Ensure security commitments, privacy terms, audit rights, and notification obligations are reflected in the signed agreement rather than only in questionnaire responses.

For an audit-ready record, retain the assessment, questionnaire, evidence, review notes, approvals, exceptions, and follow-up actions together. This creates a defensible trail for internal reviews and customer due diligence.

Common mistakes

• Using one questionnaire for every vendor: A universal form creates noise and can hide the questions that matter most for a specific service.
• Starting after the contract is signed: Security and privacy requirements are harder to negotiate once implementation is underway.
• Accepting certifications without checking scope: An assurance document may not cover the product, region, environment, or period relevant to your use.
• Scoring without an approval rule: A numerical rating is not a decision. Define who may approve each tier and who must accept residual risk.
• Ignoring fourth parties: A vendor’s subcontractors can materially affect data location, resilience, and incident response.
• Leaving exceptions open-ended: Every exception should have a reason, owner, compensating control, target date, and review point.
• Failing to connect procurement and operations: The assessment should be revisited when permissions, integrations, data types, or service scope change.

When to revisit

Set a reassessment schedule based on risk, but do not rely on the calendar alone. Revisit a vendor when any of the following occurs:

• Before a new contract, renewal, expansion, or major procurement cycle.
• When the vendor begins processing a new data category or supporting a new business process.
• When production, privileged, identity, or API access is added or materially changed.
• After a security incident, service outage, material control failure, or significant audit finding.
• When the vendor changes hosting locations, subprocessors, ownership, or core technology.
• When your own security, privacy, retention, or compliance requirements change.
• When an exception expires or a remediation commitment is overdue.

As a practical next step, create a vendor register with the risk tier, owner, renewal date, last assessment, next review date, open issues, and approval status. Review the register before seasonal planning cycles and whenever workflows or tools change. For related control work, connect vendor findings to your SOC 2 readiness evidence, access control policy, and data retention process. A vendor assessment becomes valuable when it remains current, informs purchasing decisions, and leads to tracked action rather than sitting as a completed questionnaire.