Vendor review checklist sheet
- Assign one owner plus a backup before filling cells.
- Link each row to a system name—not a vague team name.
- Attach evidence (ticket IDs, screenshots policy) for audits later.
- Revisit quarterly or when vendors and flows change.
See also: Compliance portal · Official resources · Guides index
Use this sheet before a new tool, processor, or service provider touches real personal data. The point is not to create procurement theater. The point is to make sure someone checked what data is involved, why the vendor is needed, who approved the risk, and what must happen before go-live.
Best owner
Usually ops, procurement, security, founder, or whoever approves new vendors in smaller teams.
- Get engineering input on integrations and access scope
- Get legal or policy input if customer commitments or contracts matter
- Get the business owner to justify why the vendor is necessary
- Re-open the sheet when scope, data, or vendor access changes
How to use this sheet
- Create one row or tab per vendor under review.
- Document what data the vendor will access, store, transmit, or enrich.
- Record the business owner, approver, and conditions for launch.
- Do not mark the vendor complete until contract, access, and operational follow-through are done.
Suggested columns or sections
- Vendor name and product category
- Business owner and backup owner
- Purpose for using the vendor
- Data categories involved
- Systems or workflows connected
- Internal users with access
- Customer-facing impact or notice implications
- Retention and deletion expectations
- Open questions, blockers, and launch conditions
- Approval status, approval date, and next review date
What to check before approval
- Is the vendor solving a real business need or duplicating an existing tool?
- What personal data will move into the tool and is all of it necessary?
- Does the integration scope match least-privilege API keys, SSO roles, and data-minimised exports?
- Will the vendor change what your privacy notice, consent flow, or customer commitments need to say?
- Are subprocessors disclosed, and do change-notification clauses match your enterprise DPAs?
- Who will own deletion, account closure, evidence exports, and offboarding later?
- How will personal-data incidents involving this vendor be escalated within your security runbook?
- What audits, questionnaires, or SOC reports are on file—and when do they expire?
- What is the fallback if the vendor is not approved or must be removed?
Teams often approve vendors based on feature excitement and then discover the data questions later. Reverse that order.
Escalate when
- The vendor touches sensitive or high-volume customer workflows
- No one can clearly explain why the tool needs the data it is requesting
- Deletion, offboarding, or support handling is vague
- Sales, enterprise customers, or existing contracts create extra promises the vendor could affect
If a vendor would be awkward to explain to a customer, board member, or enterprise prospect, that is usually a sign the review is incomplete.