checklist

AI vendor security review packet template for small teams

A practical template for reviewing AI vendors before approval, covering data use, model training, retention, connectors, admin controls, incidents, evidence, and customer-safe answers.

Use this template before approving a new AI vendor, upgrading an AI workspace, connecting an AI tool to customer systems, or letting a team use an AI tool with customer data, source code, meetings, support tickets, or production workflows.

Most small teams do not need a full enterprise vendor risk program on day one. They do need one consistent packet that shows what was reviewed, who approved it, what data can be used, what evidence exists, and when the decision expires. If the vendor will touch sensitive data or take actions in another system, run the AI Tool Risk Checker before approval.

Bottom line

An AI vendor security review packet should answer:

1. What tool is being approved?
2. What business workflow needs it?
3. What data can the tool access, retain, train on, export, or share?
4. What admin, access, connector, audit, retention, and deletion controls exist?
5. What evidence supports the decision?
6. What conditions, limits, exceptions, and next review date apply?

Do not approve an AI vendor from a sales deck alone. Use vendor documentation, admin settings, contract terms, security questionnaires, and your own data classification rules. The Small Team AI Security Checklist remains the baseline for minimum operating controls.

When to use this packet

Situation	Use this packet?	Why
New AI SaaS tool requested by a team	Yes	Establishes owner, scope, data rules, and approval evidence.
Existing SaaS product adds AI features	Yes	AI features may change data use, retention, output, or automation risk.
Tool connects to Google Workspace, Microsoft 365, Slack, GitHub, CRM, support desk, or file storage	Yes	Connectors expand data access and source-system risk.
Tool processes customer calls, tickets, transcripts, or files	Yes	Customer data and privacy claims need evidence.
Developer tool can read repositories, local files, terminal output, or secrets-adjacent context	Yes	Engineering workflows need stricter boundaries.
Browser extension can read pages or tabs	Yes	Host permissions and page access need review.
Vendor is already approved but changes terms or features	Use the change review checklist	This packet is for initial approval or major reapproval.
Vendor only handles public content with no login, connector, storage, or automation	Maybe	Use a lighter review if the data and workflow are low risk.

If no one can name the tool owner, do not approve the vendor.

Packet cover sheet

Field	Required answer
Vendor and product	Legal vendor name, product name, plan, and workspace.
Business owner	Person or role accountable for the use case.
Admin owner	Person or role managing settings, users, logs, retention, and connectors.
Request date	Date the review started.
Decision date	Date approved, restricted, denied, or escalated.
Approved use cases	Specific workflows allowed.
Prohibited use cases	Workflows not allowed.
Approved users	Team, group, role, or named pilot users.
Approved data classes	Public, internal, customer, source code, meeting, regulated, financial, or other.
Connected systems	Systems the tool can access through connectors, OAuth, extension permissions, webhooks, or imports.
Risk level	Low, Medium, or High.
Approval decision	Approve, approve with limits, pilot only, restrict, deny, or escalate.
Review expiry	Date the decision must be reviewed again.

Keep the cover sheet short. The detail belongs in the evidence sections below.

Evidence request list

Ask the vendor or internal tool owner for:

1. Security overview or trust center page.
2. Privacy policy and product-specific data processing terms.
3. AI-specific data use, model training, retention, and deletion documentation.
4. Subprocessor or service provider list when available.
5. Admin control documentation for users, groups, sharing, retention, exports, logs, and connectors.
6. Authentication and SSO documentation if the team will use managed accounts.
7. Audit log and activity export documentation.
8. Connector, OAuth, browser extension, API, webhook, and file import documentation.
9. Data residency, backup, deletion, and export documentation when relevant.
10. Incident response, vulnerability disclosure, uptime, support, and customer notification documentation.
11. Security questionnaire, CAIQ, SOC 2 report, ISO certificate, or other assurance materials if available.
12. Pricing and plan documentation showing which security controls require a higher tier.

If the vendor cannot provide evidence, write that into the packet. Missing evidence is a decision input, not an excuse to skip review.

Data use review

Question	Acceptable evidence	Decision note
What data will users enter, upload, sync, transcribe, summarize, or generate?	Use case description and data classification table.	List allowed data classes explicitly.
Can customer data be used?	Data processing terms, admin settings, and internal approval.	If yes, define customer data classes and workflow limits.
Can regulated data be used?	Legal, compliance, and data owner review.	Default should be no unless approved.
Can source code be used?	Developer AI policy and repository scope decision.	Define repositories, file types, and sensitive file restrictions.
Can meeting recordings or transcripts be used?	Meeting bot policy and transcript retention rule.	Define consent, storage, sharing, and deletion.
Can the vendor use inputs or outputs for model training or product improvement?	Vendor terms, product settings, and plan documentation.	Answer by tool, setting, and data class.
Can users export or share outputs externally?	Product sharing controls and policy.	Define approved sharing destinations.
Can data be deleted or exported on request?	Vendor deletion and export documentation.	Record operational owner and expected process.

Do not rely on a generic “enterprise-grade security” claim. Match each claim to a setting, document, or contract term.

AI-specific questions

Area	Review question	Evidence to keep
Model training	Are prompts, files, transcripts, code, embeddings, or outputs used to train or improve vendor models?	Vendor terms, admin setting screenshot, plan notes, and date checked.
Human review	Can vendor staff or contractors review customer content, prompts, files, transcripts, or outputs?	Support terms, abuse monitoring terms, data processing terms, and escalation rule.
Retention	How long are prompts, files, logs, transcripts, outputs, embeddings, and metadata retained?	Retention documentation and internal retention decision.
Deletion	Can the team delete user data, workspace data, transcripts, files, or logs?	Deletion workflow and owner.
Output risk	Can AI output affect customers, records, code, invoices, legal text, hiring, healthcare, finance, or production systems?	Use case approval and human review rule.
Agent actions	Can the tool run commands, call APIs, send messages, update records, or trigger automations?	Action scope, approval matrix, and rollback plan.
Connectors	What source systems can the AI tool access?	Connector register and source-system owner approval.
Memory or personalization	Does the tool store reusable memory, profile data, workspace context, or learned preferences?	Setting screenshot and deletion rule.
Evaluation	Is there a review process for hallucination, harmful output, bias, or incorrect recommendations?	Workflow-specific human review checklist.

If the vendor cannot explain a model training or retention path clearly, keep sensitive data out of the tool.

Connector and access review

Control	Review item	Default requirement
Managed accounts	Users should authenticate with company-managed accounts where practical.	Avoid personal accounts for business data.
SSO or MFA	Confirm available authentication controls by plan.	Require MFA at minimum for sensitive workflows.
Role-based access	Confirm admins, users, guests, and shared workspaces.	Least privilege for admins and users.
Groups	Confirm whether user groups can limit access.	Use groups for pilots and approved teams.
Connector scope	List source systems, scopes, and data types.	Source-system owner must approve each connector.
OAuth grants	Capture app name, publisher, scopes, install date, and owner.	Remove unused grants after pilot.
Browser extension access	Capture extension ID, permissions, host scope, and update risk.	Prefer allowlisted deployment over user self-install.
Logs	Confirm admin activity, user activity, data access, connector events, and export options.	Keep enough logs for access review and incidents.
Offboarding	Confirm how users, connectors, local apps, extensions, and tokens are removed.	Test before broad rollout.

Connector approval should be separate from tool approval. A tool can be approved for manual use but not approved for CRM, Drive, Slack, GitHub, or support desk access.

Evidence scoring matrix

Evidence area	0 points	1 point	2 points
Vendor security documentation	Missing	Generic page	Current security page plus relevant controls
AI data use terms	Missing	Generic privacy terms	AI-specific training, retention, and deletion terms
Admin controls	Missing	Basic user settings	Users, groups, roles, sharing, logs, retention, and connectors
Access controls	Personal accounts only	MFA available	Managed accounts, MFA or SSO, and role separation
Connector controls	Unknown	Manual list	Scope register and source-system owner approval
Audit logs	Missing	Basic activity	Admin, user, connector, and export evidence
Deletion and export	Unknown	Vendor support request only	Documented workflow and owner
Incident communication	Unknown	Generic support route	Security contact, incident process, and notification terms
Assurance materials	None	Partial questionnaire	CAIQ, SOC 2, ISO, or equivalent customer-safe evidence
Internal owner	Missing	One owner	Business, admin, data, and backup owners

Use the score as a triage aid:

Score	Decision
0-8	Do not approve for customer data, source code, meeting transcripts, or connectors.
9-14	Pilot only with low-risk data and written limits.
15-18	Approve with documented scope, owners, and review date.
19-20	Approve for broader use if the data class and workflow are also acceptable.

High-impact workflows still need owner review even with a high evidence score.

Decision rules

Finding	Default decision
No owner	Deny until an owner is assigned.
No data use terms	Restrict to public or synthetic data only.
Model training terms are unclear	Restrict customer data, source code, transcripts, and confidential records.
No admin console	Pilot only or deny for team use.
No access review path	Restrict until offboarding and review are documented.
Broad connector scopes	Require source-system owner approval and narrower scope.
No deletion path	Restrict data classes and retention-sensitive workflows.
Vendor requires a higher tier for required controls	Escalate to finance and business owner before approval.
Vendor has recent material incident or unresolved trust concern	Escalate and document compensating controls.
User wants to bypass review because the tool is urgent	Pilot only with low-risk data or deny.

The packet should produce a decision, not just a pile of links.

Approval record

Copy this into the review record.

Field	Entry
Decision	Approve, approve with limits, pilot only, restrict, deny, or escalate.
Approved workflow	Specific workflow.
Approved users	Team or group.
Approved data classes	Data classes allowed.
Prohibited data classes	Data classes not allowed.
Approved connectors	Source systems and scopes.
Required settings	Admin settings that must stay enabled.
Required monitoring	Access review, log review, connector review, or renewal review.
Required user notice	Employee rule, meeting notice, customer notice, or support workflow rule.
Required evidence	Screenshots, vendor docs, questionnaire, approval notes, and owner decision.
Expiry date	Date for reapproval.
Approver	Business owner and required technical or data owners.

If the decision is “approve with limits,” make the limits visible to users before rollout.

Customer-safe summary

Turn the internal packet into a short customer-safe summary for sales, support, and security questionnaires.

Customer question	Safe summary source
Do you review AI vendors?	Packet cover sheet and decision record.
What AI tools are approved?	Approved AI tool inventory.
Can AI vendors access customer data?	Data use review and approved data classes.
Is customer data used for model training?	AI-specific questions and vendor terms.
What connectors are used?	Connector register summary.
How do you remove access?	Offboarding and access review evidence.
Can you share proof?	Redacted screenshots, review date, and customer-safe questionnaire evidence.
What certifications do vendors have?	Vendor assurance materials, with dates and scope.

Do not send the internal packet to customers by default. Use the AI security questionnaire response checklist to decide what can be shared.

Review cadence

Trigger	Review action
New vendor or product	Full packet.
New AI feature in an existing product	Full packet if data use or automation scope changes.
New connector	Connector review plus source-system owner approval.
New data class	Data use review and owner approval.
New meeting bot or transcript workflow	Meeting bot review and retention decision.
New browser extension permission	Browser extension permission review.
New developer AI repository scope	Developer AI review and code context decision.
Vendor terms, plan, or security docs change	Vendor change review.
Incident or public trust concern	Incident triage and reapproval decision.
Renewal	Renewal decision checklist plus current packet update.

Set a default annual review date even when no trigger occurs. Use quarterly review for high-risk tools.

Red flags

Escalate or deny when:

1. The vendor will not explain AI data use, model training, retention, or deletion.
2. Customer data, source code, transcripts, or regulated data would be used without a clear approval path.
3. Required admin controls exist only on a plan the team will not buy.
4. The tool requires broad read/write connectors for a narrow workflow.
5. Users must use personal accounts for business data.
6. There is no practical offboarding or deletion path.
7. AI output can update customer records, financial data, production systems, legal text, hiring decisions, or medical content without human review.
8. The vendor asks for unnecessary data or permanent access.
9. The requested workflow conflicts with customer contracts, internal policy, or data classification rules.
10. The requester cannot explain the business need.

Escalation is not a blocker by itself. It is how the right owner makes a clear decision.

Metrics to track

Metric	Why it matters
Vendor reviews opened	Shows AI tool demand.
Reviews approved, restricted, denied, or escalated	Shows risk posture and decision quality.
Average review time	Shows whether review is slowing adoption.
Missing evidence by category	Shows which vendor questions need standard follow-up.
High-risk connectors requested	Shows source-system exposure.
Tools approved for customer data	Shows privacy and trust surface area.
Exceptions granted	Shows pressure points and policy gaps.
Review expiries coming due	Prevents stale approvals.
Customer questions tied to vendor evidence	Shows which packet sections help revenue.

If reviews are slow, standardize the packet before adding more meetings.

Evidence checked

This template is aligned with:

1. Cloud Security Alliance STAR Level 1 CAIQ v4.1, which describes CAIQ as a way to document security controls for IaaS, PaaS, and SaaS services and support security control transparency.
2. Cloud Security Alliance CAIQ explainer, which describes CAIQ as a questionnaire for transparency and assurance, not a certification.
3. NIST SP 1305, which explains how the Cybersecurity Framework 2.0 can support cybersecurity supply chain risk management and help organizations define and communicate supplier requirements.
4. NIST AI Risk Management Framework, which is intended to help organizations manage AI risks and incorporate trustworthiness considerations.
5. NIST Privacy Framework getting started guidance, which frames privacy risk around data processing across the full lifecycle.
6. Cybergiz templates for tool inventory, vendor change review, evidence retention, security questionnaires, trust center summaries, access review, connector review, meeting bot review, browser extension review, developer AI review, and incident response.

This page is an operational checklist, not legal, procurement, compliance, audit, or certification advice.

FAQ

Is a CAIQ the same as a certification?

No. CSA describes CAIQ as a questionnaire used for transparency and assurance. Treat it as evidence to review, not as proof that every control is operating effectively.

Should every AI vendor have a SOC 2 report?

Not always. A low-risk public-content tool may not need the same evidence as a tool connected to customer records or source code. The packet should match data sensitivity, workflow impact, and connector scope.

Can we approve a tool if the vendor has no AI-specific data use page?

Sometimes, but restrict the approval. Keep customer data, source code, transcripts, regulated data, and broad connectors out of the tool until data use, retention, and training terms are clear.

Who owns the final decision?

The business owner owns the need, but security, admin, data, engineering, legal, or finance owners may need to approve parts of the decision. One person should own the final review record.

How long should the packet be kept?

Keep it for the life of the tool plus your normal evidence retention period. If the tool handles high-risk data, keep the decision record long enough to support access reviews, renewal decisions, incidents, and customer questions.

What should be shared with customers?

Share customer-safe summaries, redacted screenshots, dated decision records, and scoped assurance materials. Do not share raw internal notes, full logs, private screenshots, source code, customer examples, or sensitive account details by default.