Vendor risk assessment template

Use this template to assess third-party risk, supplier due diligence, security, privacy, data access, business criticality, AI use, compliance evidence, risk score, mitigation owners, and approval decisions before onboarding or renewal.

Download CSV Download Markdown View scoring model Build answer library

Assessment previewSecurity, GRC, procurement

VendorAI customer support tool

Risk tierHigh impact / Medium likelihood

EvidenceSOC 2, DPA, subprocessors, access controls

DecisionMitigate before production use

What this template gives you

It is designed for teams that need a reusable vendor review artifact, not a long theory page.

Downloadable templateCSV and Markdown versions that procurement, GRC, security, and privacy teams can adapt immediately.

Risk scoring modelSimple scoring for data sensitivity, business criticality, access level, compliance exposure, evidence quality, and AI use.

Supplier questionsA starter questionnaire for third-party risk, supplier due diligence, security controls, privacy, subprocessors, incident response, compliance evidence, and AI automation.

Reusable evidenceOutputs can feed security questionnaires, privacy reviews, risk registers, renewal reviews, and vendor approval records.

Do AI vendors need extra review beyond SOC 2?

Usually yes. The practical gap is not generic security posture. It is whether you can answer what the AI system can access, where data goes, and how risky actions are controlled.

Short answerNo. SOC 2 helps, but AI vendors usually need extra review for model-provider data flow, training or opt-out boundaries, OAuth scopes, token revocation, audit logs, and MCP or agent tool access.

Use this whenA vendor touches customer data with AI, connects to internal tools, requests broad integrations, or shows up in a customer or procurement AI review.

Minimum extra fieldsCustomer-data use, model providers, subprocessors, retention and deletion, OAuth scopes, token custody, human review, tool permissions, and logging.

Decision ruleIf you cannot explain data flow, approval boundaries, or emergency disablement in plain language, the vendor is not ready for a fast approval path.

Add privacy review fields Open supplier questionnaire Review MCP and tool access

Recommended vendor risk assessment fields

These fields keep supplier review useful for procurement, security, privacy, GRC, and customer due diligence.

Vendor nameThe supplier, SaaS tool, service provider, AI platform, consultant, or data processor under review.

Service or productWhat the vendor provides and which internal workflow, team, product, or customer process depends on it.

Business ownerThe internal owner accountable for vendor use, renewal, risk acceptance, and mitigation follow-up.

Data accessWhether the vendor handles public data, business data, confidential data, personal data, PHI, credentials, or customer content.

Business criticalityHow disruptive the vendor failure, breach, or outage would be to revenue, operations, compliance, or customers.

Security controlsMFA, SSO, encryption, access review, vulnerability management, incident response, backups, and audit logging.

Privacy and data processingDPA, BAA, subprocessors, retention, deletion, data location, purpose limitation, and privacy review status.

Integrations and OAuth scopesFor agentic or AI vendors, record each integration, minimum OAuth scopes, token type, where refresh tokens are stored, and revocation owner.

Compliance evidenceSOC 2, ISO 27001, CAIQ, SIG, penetration test summary, security whitepaper, policies, or customer trust center.

AI or automation useWhether the vendor uses AI, agents, MCP servers, automated decisions, model providers, or customer-data training.

Risk scoreA simple total score that combines data sensitivity, access level, criticality, compliance exposure, and evidence quality.

Risk tierLow, medium, high, or critical tier used to decide review depth, approval path, and renewal frequency.

Mitigation ownerThe person responsible for requesting evidence, closing gaps, approving exceptions, or blocking use.

Supplier risk assessment scorecard fields

If the search intent is specifically a supplier risk assessment template, treat the worksheet as a scorecard, not only as a vendor intake form. Each row should show who the supplier is, what data or workflow they touch, which risk category applies, what evidence was reviewed, which score was assigned, and who owns mitigation.

Supplier categoryClassify the supplier as a software vendor, processor, service provider, AI tool, support vendor, infrastructure provider, or consultant.

Data or workflow touchedRecord whether the supplier touches customer data, employee data, PHI, financial data, production systems, or internal-only workflows.

Risk categoryTag the main risk as security, privacy, operational, financial, compliance, AI/model, subprocessor, or access-management risk.

ScoreUse a low/medium/high band or the 0-3 factor score so procurement, security, and business owners can compare suppliers consistently.

Evidence reviewedList the proof used for the score: SOC 2, ISO 27001, DPA, BAA, subprocessor list, pentest summary, policy, trust center, or audit log.

Mitigation ownerName the person accountable for follow-up evidence, exception approval, renewal review, or blocking supplier use.

Vendor risk scoring model

Score each factor from 0 to 3. The goal is consistent triage, not a formal certification.

Data sensitivity0 for no sensitive data, 1 for business data, 2 for personal or confidential data, 3 for regulated or high-impact data.

System criticality0 for optional, 1 for team workflow, 2 for customer-facing or revenue workflow, 3 for mission-critical operations.

Access level0 for no access, 1 for read-only limited access, 2 for broad read/write access, 3 for admin, credential, or production access.

Compliance exposure0 for no compliance impact, 1 for internal policy only, 2 for customer commitments, 3 for regulated or contractual obligations.

AI and automation0 for no AI use, 1 for internal AI only, 2 for AI processing customer data, 3 for agent/tool access or automated high-impact decisions.

Evidence quality0 for strong current evidence, 1 for partial evidence, 2 for stale evidence, 3 for missing or unverifiable evidence.

0-4: Low

Approve with standard owner review and renewal tracking.

5-8: Medium

Request core evidence and document open risks before approval.

9-13: High

Require security, privacy, and business-owner approval before use.

14-18: Critical

Escalate to formal risk acceptance, mitigation plan, or block until gaps are closed.

Download scoring worksheet Score questionnaire readiness

Supplier questionnaire starter questions

Use these questions to collect evidence before assigning risk tier or approval status.

What customer, employee, patient, or business data will the vendor access?Identify data categories, systems, environments, retention period, and whether data is stored, processed, or only viewed.

What security evidence can the vendor provide?Request SOC 2, ISO 27001, CAIQ, SIG, penetration test summary, security policy, access control policy, and incident response evidence.

Which subprocessors or fourth parties are involved?Document hosting providers, AI providers, support vendors, analytics tools, data locations, and subprocessor notification process.

How are access, authentication, and privileged actions controlled?Review SSO, MFA, RBAC, admin access, support access, offboarding, access reviews, and audit logs.

What integrations and OAuth scopes does the vendor request?Ask for a per-integration scope sheet, minimum scopes, refresh token custody, token revocation runbook, and how scope changes are approved.

How does the vendor handle incidents and breach notification?Ask for notification timelines, escalation contacts, incident history, customer communication process, and evidence retention.

Does the vendor use AI, agents, or automated decisioning?Record model providers, customer-data use, opt-out paths, human review, tool permissions, logs, and prompt injection controls.

AI vendor access review fields

For agentic or AI vendors, add OAuth scopes, token revocation, model-provider, MCP/tool access, and audit evidence before approval.

AI vendor data useRecord whether customer data is used for training, fine-tuning, inference, embeddings, evaluation, logging, or human review.

OAuth scopesList every integration the AI vendor can access, the minimum scopes required, approval owner, and when scope changes are reviewed.

Token revocationDocument refresh token custody, emergency disable path, revocation runbook, and the last date revocation was tested.

Agent tool accessMap tools, data classes, denied actions, approval rules, and whether the vendor uses MCP servers, gateways, or browser extensions.

Third-party model providersIdentify model providers, subprocessors, data location, retention, deletion, and customer opt-out controls.

Review and audit trailKeep evidence for human review, tool calls, denied actions, admin changes, incident response, and reviewer decisions.

Review MCP gateway evidence Add privacy risk fields

AI vendor change-control fields

A one-time vendor review is not enough if the model, provider stack, or tool permissions can change after approval. Keep these fields next to the worksheet so procurement and security can re-check the vendor quickly.

Model or provider change noticeRecord how the vendor notifies customers about model changes, new subprocessors, changed data flows, or newly enabled tool access.

Evaluation and regression evidenceKeep the last review date, testing summary, unacceptable-failure criteria, and owner for quality, safety, and prompt-injection checks.

Emergency disable or rollbackDocument who can disable the feature, revoke access, reduce scopes, or roll back to a safer path if the vendor changes behavior.

Customer-safe change summaryPrepare a short external note that explains what changed, what data is affected, and whether customers need to re-review the vendor.

Ask supplier evidence questions Store reusable AI review answers Add DPIA and ADMT fields

AI request boundary evidence

If an AI vendor can take actions, retrieve customer data, or call tools, review the request boundary instead of only asking whether the vendor has SOC 2.

Request identity contextRecord which user, service account, tenant, role, integration, or delegated agent context is attached to each AI request.

Policy decision pointAsk where allow, deny, approval-required, and data-minimization decisions are made before the model or tool call runs.

Prompt injection handlingDocument how the vendor treats untrusted retrieved content, tool output, user uploads, and cross-tenant instructions.

Per-request audit trailKeep evidence that model calls, tool calls, denied actions, reviewer overrides, and admin policy changes can be reviewed later.

Data residency and retentionConfirm where prompts, outputs, embeddings, logs, and evaluation traces are processed, stored, deleted, or excluded from training.

Incident and disable pathDefine who can pause the AI feature, revoke tool access, reduce scopes, notify customers, and preserve evidence after misuse.

Map agent and tool boundaries Collect reviewer-openable proof

AI coding assistant vendor review checklist

Teams often approve an AI coding assistant and still misunderstand the actual data handling. Use this checklist to capture what matters before rollout.

Checklist

Confirm what content is sent off-device (open files, diffs, terminal output, telemetry) and how it is minimized.
Separate training opt-out from retention and human review (prompts, code, logs, evaluation).
Check where data is processed (region) and which subprocessors are involved.
Verify admin controls: SSO/MFA, policy toggles, context limits, repo/file exclusions, and safe defaults.
Confirm auditability: prompt logs, admin actions, policy changes, access logs, and retention settings.
Document incident response and customer notification for data exposure or misuse scenarios.
Create an internal safe-use policy for secrets and sensitive data in prompts (and how it is enforced).

Evidence to request

Vendor technical data-handling documentation (collection, processing locations, retention, deletion).
DPA + subprocessor list + data residency statement.
SOC 2 / security whitepaper scope + enterprise admin controls overview.
Sample audit log schema + retention configuration evidence.
Internal safe-use guideline and enforcement plan.

Store reusable answers + evidence links Capture audit log + approval controls

Example starter rows

These examples show how to turn vendor intake into risk scenarios and evidence requests.

Vendor type	Use case	Data access	Risk scenario	Evidence to request
Payroll provider	Employee compensation and tax workflow	Employee PII, bank data, tax records	Regulated personal data exposure	SOC 2, DPA, access controls, incident response, subprocessor list
AI customer support tool	AI-assisted support triage and answer drafting	Customer contact data, ticket content, account metadata	Sensitive data exposure or incorrect automated routing	AI governance notes, DPA, retention limits, human review, audit logs
Cloud analytics tool	Product analytics and event tracking	Usage events, identifiers, device metadata	Unexpected tracking, retention, or vendor reuse	DPA, privacy review, retention policy, opt-out review, access controls
Healthcare data processor	Patient portal message processing	ePHI, patient identifiers, authentication logs	Unauthorized access or incomplete HIPAA evidence	BAA, HIPAA controls, access logs, encryption, incident response

Download CSV template Download Markdown version

Subprocessor list hygiene

Community discussions show deals slow down when subprocessor lists are missing, hidden, or stale.

What to implement

Publish a single canonical subprocessor list (trust center, security page, or privacy subpage) that reviewers can link to.
Show last updated date + owner. Treat missing ownership as a risk signal.
Trigger updates when you add a new vendor, enable a new integration, or ship a feature that changes data sharing.
Track upstream changes too: key vendors may add their own subprocessors without your team touching the stack.
Log change history and keep an exportable list for procurement (name, purpose, data categories, region).
Review on a cadence (quarterly is common) and keep an exception note when a vendor will not disclose details.

Evidence to keep

Public subprocessor page link + last updated date
Internal subprocessor register (name, purpose, data categories, region, owner)
Subprocessor change notification workflow (customer notice + approvals where applicable)
Vendor monitoring signal (trust-center RSS/email alerts, renewal checklist, or quarterly review record)

Map subprocessor claims to evidence Store reusable subprocessor answers

Connect it to security and privacy review

A useful vendor assessment should feed supplier questionnaires, privacy review, and answer-library evidence.

Security questionnaire answers

Reuse approved vendor evidence when customers ask how third parties and suppliers are reviewed.

Open

Privacy risk assessment

Connect vendor review to data categories, subprocessors, DPA, BAA, retention, and high-risk processing.

Open

AI vendor review

Add fields for AI providers, agent tool access, prompt injection controls, audit logs, and MCP gateway boundaries.

Open

Software selection

Compare tools by whether they preserve evidence, owners, risk tier, approval status, and renewal history.

Open

Evidence and source trail

Use recognized sources and internal records to support supplier risk decisions.

NIST SP 800-161 Rev. 1

External source

Open

NIST guidance supports identifying, assessing, and mitigating cybersecurity supply-chain risks across products and services.

SOC 2 report

Related template

Open

Use SOC 2 evidence to review security controls, control ownership, monitoring, incident response, and audit scope.

Privacy risk assessment

Related template

Open

Connect vendor review to data categories, subprocessors, retention, DPA or BAA status, and high-risk processing.

AI vendor and MCP evidence

Related template

Open

For AI vendors, record agent identity, tool permissions, prompt injection controls, audit logs, and gateway boundaries.

Vendor risk assessment FAQ

Short answers for teams deciding how this template fits supplier review.

What is a vendor risk assessment template?

A vendor risk assessment template is a structured worksheet used to collect supplier details, data access, security controls, privacy evidence, risk score, mitigation owner, and approval decision.

Who should use this vendor risk assessment template?

GRC, procurement, security, privacy, legal, IT, and business owners can use it before approving a new vendor, renewing a supplier, or responding to customer due diligence.

Is vendor risk assessment the same as a vendor security questionnaire?

They overlap, but they are not identical. A questionnaire collects answers and evidence from the supplier; the risk assessment scores the supplier, records decisions, and tracks mitigation.

Is a supplier risk assessment template different from a vendor risk assessment template?

In practice they usually support the same workflow. Supplier language is common in procurement and supply-chain reviews, while vendor language is common in SaaS, GRC, and security reviews. The worksheet should still capture category, data access, evidence, score, owner, and mitigation.

What should a supplier risk scorecard include?

A supplier risk scorecard should include supplier category, data or workflow touched, risk category, score, evidence reviewed, mitigation owner, approval decision, and next review date.

Can this supplier risk assessment template be used in Excel?

Yes. The CSV version is designed for spreadsheet workflows where teams need sortable supplier categories, score fields, evidence links, owners, and mitigation status.

Should AI vendors get extra review?

Yes. AI vendors may need extra review for customer-data use, model providers, automated decisions, agent tool access, prompt injection controls, logs, and human review paths.

How do you keep an AI vendor review from going stale?

Treat model/provider changes like risk events. Track review owner, last review date, model or subprocessor change notices, evaluation evidence, and emergency disable steps so the worksheet stays usable after the vendor changes behavior.

How do you keep a subprocessor list from going stale?

Give the list an owner and a trigger. Update it when new vendors or integrations are added, monitor key vendors for upstream subprocessor changes, and keep a version log so customers can trust that the list is current.

Is this template legal or compliance advice?

No. It is a practical starting point for organizing vendor risk information. Legal, privacy, security, or compliance owners should review obligations for regulated workflows.

Need a shortlist for your workflow?

Send the formats you receive, your current answer-library setup, and whether you need portal support. We will use those signals to prioritize the next comparison updates.

Request a shortlist