checklist
AI vendor change review checklist for small teams
A practical checklist for reviewing AI vendor changes, including terms, retention, training settings, connectors, admin controls, pricing, support, incidents, and approval outcomes.
Use this checklist when an AI vendor changes terms, features, data settings, integrations, pricing, or support.
Small teams often approve an AI tool once and then forget that the product keeps changing. New connectors, retention defaults, training settings, admin controls, model behavior, pricing, and support terms can change the original risk decision. If the change appears during a renewal cycle, use this together with the AI tool renewal decision checklist.
Bottom line
An AI vendor change should trigger review when it affects:
- What data the tool can access, retain, train on, export, or share.
- Which users, admins, guests, bots, extensions, connectors, or API keys can use the tool.
- Whether AI output can affect customers, records, source code, meetings, tickets, or production workflows.
- Whether the team can still offboard users, revoke connectors, delete retained data, and audit activity.
- Whether the approved business case, cost, and owner still make sense.
If the vendor change expands data access or action scope, rerun the AI Tool Risk Checker before letting users continue.
Change trigger matrix
| Vendor change | Risk question | Default action |
|---|---|---|
| Terms of service or data processing terms changed | Did data use, retention, sharing, liability, or support obligations change? | Review before renewal or continued use. |
| Training or model improvement settings changed | Could prompts, files, transcripts, or outputs be used differently? | Verify workspace defaults and record evidence. |
| Retention or deletion behavior changed | Can the team still delete or export what policy requires? | Recheck retention policy and offboarding path. |
| New connector or OAuth scope added | Can the tool reach new source systems or broader records? | Require source-system owner approval. |
| New browser extension permission added | Can the extension read more hosts, pages, tabs, files, or clipboard data? | Rerun extension review. |
| New meeting bot feature added | Can recordings, transcripts, summaries, or CRM sync reach new people or systems? | Rerun meeting bot review. |
| New agent or automation feature added | Can AI take actions, run commands, update records, or call APIs? | Treat as a new workflow. |
| Admin controls changed | Can admins still manage users, logs, sharing, retention, and exports? | Verify before rollout. |
| Pricing or plan packaging changed | Did required controls move plans or become unavailable? | Review renewal and downgrade options. |
| Vendor incident or outage disclosed | Did it affect your data, workflow, or trust boundary? | Open an incident or vendor review record. |
The safer default is to restrict new features until the review is complete.
15-minute triage
| Step | Question | Outcome |
|---|---|---|
| 1 | What changed? | Terms, settings, feature, connector, pricing, support, incident, or ownership. |
| 2 | Which approved tool record is affected? | Link to the tool register and owner record. |
| 3 | Which users or workflows are affected? | Identify teams, groups, bots, extensions, and automations. |
| 4 | Which data classes are affected? | Public, internal, customer, source code, meeting, regulated, secret, or financial. |
| 5 | Did the change expand access or actions? | If yes, pause or restrict until approved. |
| 6 | Who owns the decision? | Business owner plus admin, data, engineering, or source-system owner. |
| 7 | What is the immediate decision? | No action, monitor, restrict, approve, escalate, or remove. |
If the triage cannot identify an owner, treat the tool as restricted.
Full review checklist
| Review area | Check | Evidence |
|---|---|---|
| Vendor notice | Capture the change date, notice source, summary, and affected plans. | Vendor email, changelog, release note, admin banner, or support note. |
| Tool owner | Confirm business owner, backup owner, admin owner, and data/source-system owner. | Owner register. |
| Approved use case | Confirm the original workflow is still the same. | Intake, pilot exit, or renewal record. |
| User scope | Confirm affected users, admins, guests, shared accounts, and personal accounts. | Access export. |
| Data scope | Confirm affected data classes and prohibited data. | Data approval record. |
| Connector scope | Confirm OAuth apps, integrations, extensions, bots, webhooks, and API keys. | Connector inventory. |
| Settings | Confirm retention, training, sharing, export, deletion, audit, and admin settings. | Admin screenshots or setting notes. |
| Output control | Confirm whether AI output can affect customers, code, tickets, CRM, meetings, or records. | Workflow notes. |
| Offboarding | Confirm the team can still remove access and delete retained data. | Removal checklist. |
| Decision | Record approve, restrict, monitor, escalate, or remove. | Decision record. |
Do not store private customer data, raw transcripts, source code, API keys, passwords, private keys, or dashboard URLs with tokens in the review packet.
Terms and data review
| Question | Why it matters |
|---|---|
| Did vendor terms, privacy terms, data processing terms, or acceptable use terms change? | Contract language can change the approved risk assumption. |
| Did retention, deletion, export, or archive behavior change? | Stored prompts, files, transcripts, and logs may outlive policy expectations. |
| Did model training or product improvement defaults change? | Workspace defaults can affect whether business data is reused. |
| Did subprocessors or hosting regions change? | Some workflows depend on location, support, or vendor chain assumptions. |
| Did support access or human review behavior change? | Support workflows can expose prompts, files, or account data. |
| Did audit logs, admin exports, or evidence availability change? | Review and incident response depend on evidence. |
| Did cancellation or offboarding terms change? | Removal must remain possible if the tool is no longer acceptable. |
For customer workflows, pair this section with the customer data approval form.
Feature and connector review
| Feature change | Review question |
|---|---|
| New connector | Which source system, scopes, records, files, messages, or write permissions are involved? |
| New browser extension capability | Which hosts, tabs, pages, clipboard, downloads, files, or page content can be read? |
| New meeting bot capability | Which meetings, attendees, recordings, transcripts, summaries, and CRM fields are affected? |
| New developer AI capability | Which repos, terminals, PRs, CI/CD systems, code indexes, and secrets are in scope? |
| New agent or workflow automation | Which records, APIs, approvals, scheduled jobs, and rollback paths are involved? |
| New sharing or collaboration feature | Can guests, external users, public links, or wider teams access outputs? |
| New memory or project feature | Can retained context cross users, workspaces, projects, or time periods? |
| New export or reporting feature | Can sensitive data leave the original system more easily? |
Treat a new action-taking capability as a new tool approval, not a minor feature update.
Admin control review
| Control | Verify |
|---|---|
| SSO and domain control | Users still authenticate through the approved identity path. |
| User and group management | Owners can still remove users and narrow access quickly. |
| Admin roles | Admin permissions are not broader than needed. |
| Audit logs | The team can still see relevant user, connector, export, and admin activity. |
| Retention settings | Prompt, file, transcript, log, memory, and project retention match policy. |
| Training settings | Defaults match the approved data rule. |
| Sharing controls | Public links, guests, external sharing, and exports are controlled. |
| Connector controls | OAuth apps and integrations can be reviewed and revoked. |
| Deletion path | The team can delete retained data or close the workspace when needed. |
| Plan dependency | Required security controls are still available on the paid plan. |
If a required control moved to a more expensive plan, use the AI tool renewal decision checklist before paying more.
Decision table
| Outcome | Use when | Next action |
|---|---|---|
| No change needed | The vendor change does not affect approved users, data, connectors, settings, output, or cost. | Record the review note. |
| Monitor | The change is relevant but not active in your workspace yet. | Add a future review date and owner. |
| Approve | The change is useful and risk stays within the approved scope. | Update the tool register and evidence packet. |
| Restrict | The change is useful but should not apply to all users, data, connectors, or workflows. | Disable, narrow, or gate the feature. |
| Pilot | The change creates a new workflow but may be useful. | Run intake and pilot exit review. |
| Escalate | The change touches customer data, source code, regulated data, production actions, broad automation, or unclear vendor behavior. | Move to legal, security, engineering, or leadership review. |
| Remove | The change makes the tool too risky, too costly, or impossible to govern. | Start offboarding. |
Do not rely on “we will watch it” when the change is already active for users.
Change record template
Copy this into the tool register or review ticket.
AI vendor change review
Tool:
Vendor:
Change date:
Review date:
Reviewer:
Business owner:
Admin owner:
Data/source-system owner:
Change source:
Change summary:
Affected plan or workspace:
Affected users/groups:
Affected data classes:
Affected connectors/apps/extensions/bots/API keys:
Affected workflows:
Settings checked:
Incidents or support notes:
Decision:
Restrictions:
Escalation owner:
Next review date:
Evidence links:
Notes:Store evidence links, not raw sensitive data.
Employee notice template
Use this when the change affects how employees may use a tool.
Subject: AI tool change: [tool name]
[Tool name] has changed [terms/settings/feature/connector/pricing/support].
Until the review is complete:
- Use it only for: [approved workflows]
- Do not use it for: [prohibited data or workflows]
- Do not enable: [new feature/connector/extension/bot]
- Send questions to: [owner]
We will update the approved AI tool list by: [date].Keep the notice short. Employees need the allowed behavior, not a vendor-policy summary.
Evidence packet
| Evidence | Store it when |
|---|---|
| Vendor notice or changelog | Any change triggered review. |
| Admin setting notes | Settings, retention, training, sharing, or audit controls changed. |
| Access export | Users, groups, admins, or guests could be affected. |
| Connector inventory | OAuth, browser extension, meeting bot, API, or automation scope changed. |
| Data owner note | Customer data, source code, transcripts, regulated records, or exports are affected. |
| Incident note | Vendor disclosure, outage, bad output, or exposure is relevant. |
| Decision record | The team approves, restricts, pilots, escalates, or removes the feature/tool. |
| Employee notice | User behavior changed. |
Store the packet in an internal system outside the AI tool being reviewed.
Metrics to track
| Metric | Why it matters |
|---|---|
| Vendor changes reviewed | Shows how often approved risk assumptions change. |
| Changes approved | Shows accepted product evolution. |
| Changes restricted | Shows where defaults or features were too broad. |
| Changes escalated | Shows where lightweight review is not enough. |
| Changes leading to removal | Shows vendor risk or poor fit. |
| Reviews completed before feature use | Shows whether teams catch changes early. |
| Ownerless changes | Shows where governance records are incomplete. |
| Employee notices sent | Shows whether user behavior changed. |
| Incidents tied to vendor changes | Shows whether change monitoring is working. |
If vendor changes are never reviewed, renewals and monthly reviews will miss real risk drift.
Evidence checked
- NIST: AI Risk Management Framework
- NIST: Cybersecurity Framework
- NIST: Privacy Framework
- Cybergiz: AI Tool Risk Checker
- Cybergiz: Small Team AI Security Checklist
- Cybergiz: AI tool renewal decision checklist
- Cybergiz: AI tool owner and review calendar template
- Cybergiz: AI tool request intake form template
FAQ
What counts as an AI vendor change?
Any change that affects terms, data use, retention, training settings, connectors, browser permissions, meeting bot behavior, admin controls, audit logs, support, pricing, cancellation, or action-taking features should be reviewed.
Do we need legal review for every vendor change?
No. Many changes only need an owner note and settings check. Escalate when the change affects customer data, regulated records, source code, production actions, broad automation, contract terms, or unclear vendor behavior.
What if the change is optional?
Keep it disabled until reviewed. Optional features still create risk if users can enable them without approval.
What if the vendor change only affects pricing?
Review cost, seats, plan controls, and alternatives. Pricing changes can still affect security if required controls move to a different plan.
Should employees be told about every change?
Only tell employees when their allowed behavior changes, a feature is restricted, a connector is disabled, or the tool is being removed. Keep the notice short and action-oriented.
How does this connect to the monthly checklist?
The monthly AI tool access review checklist catches access drift. This checklist catches vendor-driven drift when the product changes between monthly or renewal reviews.