checklist
Monthly AI tool access review checklist for small teams
A practical monthly checklist for reviewing AI tool access, users, connectors, browser extensions, meeting bots, developer AI, data retention, incidents, exceptions, and next actions.
Use this monthly checklist after the first AI security rollout is live.
The goal is not to restart the whole program every month. The goal is to catch drift: departed users, stale guests, personal accounts, broad connectors, risky browser extensions, meeting bots that keep too much data, developer AI tools with repo or terminal access, and exceptions that quietly became permanent. If you are still setting the baseline, start with the 30-day AI security rollout plan and the Small Team AI Security Checklist.
Bottom line
A small team should review AI tool access monthly while the program is new. The review should answer:
- Which AI tools, bots, extensions, agents, and embedded AI features are still approved?
- Which users, guests, shared accounts, API keys, and personal accounts need removal?
- Which connectors can reach email, files, chat, code, CRM, helpdesk, calendar, meetings, or admin systems?
- Which workflows touch customer data, source code, transcripts, browser page data, or regulated records?
- Which incidents, near misses, and exceptions need follow-up?
- Which decisions should be keep, restrict, pilot, remove, or escalate?
- What evidence proves the review happened?
If the team cannot remove unused access during the review, the review is only paperwork.
Review cadence
| Situation | Cadence | Why |
|---|---|---|
| New AI program | Monthly | The first 90 days usually reveal shadow tools, personal accounts, and broad connectors. |
| High-risk workflow | Monthly | Customer data, source code, transcripts, browser page data, connectors, and automation drift quickly. |
| Stable low-risk tool | Quarterly | Public-content tools with no connectors and no sensitive data can use a lighter cadence. |
| Employee departure or role change | Same week | AI workspaces, extensions, connectors, bots, and API keys are easy to miss during normal offboarding. |
| Incident, near miss, or vendor setting change | Immediate | The access model may no longer match the approval decision. |
| Major new AI feature | Before rollout | New connector, memory, agent, automation, or sharing behavior can change the risk profile. |
For a team under 50 people, the first monthly review should fit in 30-60 minutes if the inventory is current.
Access review scope
| Area | Review | Evidence |
|---|---|---|
| AI workspaces | Users, admins, guests, shared projects, sharing settings, retention settings, and export access. | User list, admin notes, and setting screenshots or links. |
| Personal accounts | Work usage in unmanaged ChatGPT, Claude, Gemini, Cursor, meeting bot, or extension accounts. | Exceptions list and migration plan. |
| Connectors | Gmail, Drive, Docs, Slack, Teams, GitHub, CRM, helpdesk, calendar, meetings, password manager, and admin apps. | Connector register and owner approval. |
| Browser extensions | Extension ID, host access, permissions, OAuth scopes, sensitive hosts, install source, and user group. | Allowlist, risk score, and offboarding status. |
| Meeting bots | Recording default, notice, consent, transcript storage, CRM sync, external sharing, and retention. | Bot settings and meeting policy notes. |
| Developer AI | IDE tools, repo access, code search, PR bots, terminal agents, API keys, and production-adjacent workflows. | Developer inventory and repo rules. |
| Data handling | Customer, employee, source-code, transcript, finance, HR, legal, health, payment, government, child, and regulated data. | Approval records and data class decisions. |
| Incidents and exceptions | Accidental paste, upload, recording, connector, secret exposure, bad AI output, and overdue exceptions. | Incident log and exception register. |
Run any uncertain tool through the AI Tool Risk Checker before renewing approval.
Monthly checklist
| Step | Task | Owner | Evidence |
|---|---|---|---|
| 1 | Confirm the AI business owner, admin owner, engineering owner, and incident owner are still current. | Review owner | Owner map. |
| 2 | Compare the current tool inventory against expense records, browser extensions, GitHub apps, meeting bot invites, Slack/Teams apps, and employee reports. | Admin owner | Updated inventory. |
| 3 | Remove departed users, guests, shared accounts, stale admins, unused API keys, and personal accounts used for work. | Admin owner | Access removal notes. |
| 4 | Review connectors to email, Drive, Docs, Slack, GitHub, CRM, helpdesk, calendar, meetings, password managers, and admin tools. | Source-system owners | Connector register. |
| 5 | Review AI browser extensions against the allowlist and risk score. | IT owner | Extension decision table. |
| 6 | Review meeting bot recording, sharing, transcript storage, retention, and CRM sync. | Sales, CS, or people owner | Meeting bot settings notes. |
| 7 | Review developer AI tools with repo, terminal, PR, code search, or API-key access. | Engineering owner | Developer AI register. |
| 8 | Check customer-data workflows against the approval form and data rules. | Data owner | Approval records. |
| 9 | Review incidents, near misses, support tickets, and employee questions from the last month. | Incident owner | Incident log. |
| 10 | Close, renew, restrict, or escalate every exception due this month. | Business owner | Exception register. |
| 11 | Pick the top three fixes for the next month. | Review owner | Action list. |
| 12 | Save the evidence packet outside the AI tool being reviewed. | Review owner | Review record. |
Do not collect raw customer exports, source code, payroll data, legal files, regulated records, passwords, API keys, private keys, recovery codes, or session cookies as evidence.
Tool access review
Use this table for each approved or in-pilot AI tool.
| Question | Keep if | Restrict or remove if |
|---|---|---|
| Is there a named business owner? | The owner still accepts the use case and risk. | The tool has no active owner. |
| Are users still correct? | Users match current job roles and business need. | Departed users, stale guests, broad groups, or shared logins remain. |
| Are admins limited? | Only required admins have admin rights. | Admin rights are broad, inherited, or unmanaged. |
| Is work use in a managed account? | Work data stays in a company-controlled workspace where practical. | Employees use personal accounts for customer data, code, transcripts, or internal records. |
| Are settings documented? | Retention, training, sharing, export, connector, and guest settings are recorded. | Settings changed without review. |
| Does the tool still match its approval? | Data classes, user groups, and workflows are unchanged. | New data, automation, connector, or sharing behavior appeared. |
Decision labels should be plain: keep, restrict, pilot, remove, or escalate.
Connector review
Connectors often create broader exposure than prompts because they can reach historical records.
| Connector type | Monthly check | Evidence |
|---|---|---|
| Which mailboxes, labels, attachments, and history can the AI tool access? | Mailbox scope and owner. | |
| Drive or Docs | Which folders, shared drives, file types, and external shares are exposed? | Folder scope and source-system owner. |
| Slack or Teams | Which channels, DMs, files, and history are available? | Channel list and app permissions. |
| GitHub or GitLab | Which repos, issues, pull requests, actions, and secrets-adjacent workflows are available? | Repo scope and permission level. |
| CRM or helpdesk | Which customer records, tickets, notes, contracts, exports, and attachments are available? | Data owner approval. |
| Calendar or meeting platform | Which meeting titles, attendees, recordings, transcripts, and summaries are available? | Meeting category rule. |
| Password manager, SSO, or admin app | Whether the connector can expose credentials, recovery data, sessions, or admin configuration. | Escalation record. |
For ChatGPT connector workflows, use the ChatGPT connector approval template before renewing broad access.
Browser extension review
AI browser extensions need a monthly pass when they can read work pages or connect to cloud accounts.
| Check | Renew approval if | Remove or restrict if |
|---|---|---|
| Exact extension ID | The extension ID matches the allowlist. | The employee installed a lookalike or unreviewed extension. |
| Host access | Host access is limited to approved sites or user action. | The extension can read all sites or sensitive hosts without business need. |
| Sensitive pages | Gmail, Docs, CRM, password manager, SSO, admin, source-control, finance, HR, and support tools are considered. | Sensitive hosts are included by default. |
| OAuth scopes | OAuth access is reviewed separately from browser permissions. | OAuth scopes exceed the approved workflow. |
| Vendor/update status | The vendor, privacy documentation, and recent update pattern still look acceptable. | Ownership, listing, or update behavior changed materially. |
| Offboarding | Removal covers extension install, OAuth app, vendor account, and browser profile. | The team cannot remove access completely. |
Use the browser extension allowlist template and the AI browser extension risk scoring matrix for the detailed record.
Meeting bot review
Meeting bots create retained records from conversations that may feel informal to employees.
| Check | Monthly question |
|---|---|
| Recording default | Are external, customer, hiring, legal, finance, HR, security, and escalation meetings recorded only when approved? |
| Notice | Do hosts use the correct notice or consent language before recording or summarizing? |
| Storage | Where do raw audio, transcript, summary, and clips live? |
| Sharing | Are summaries auto-shared externally, to Slack/Teams channels, or into CRM records? |
| Retention | Are deletion rules working for raw transcripts and summaries? |
| Access | Can only the right host, team, manager, or customer owner view the record? |
| Incident path | Is there a first-hour path for accidental recording, sharing, or transcript exposure? |
Use the meeting transcript retention policy template when the team cannot answer storage or deletion questions.
Developer AI review
Developer AI review should focus on access and change paths, not just vendor names.
| Area | Monthly check | Block until resolved if |
|---|---|---|
| IDE assistants | Which repos, files, and extensions are included? | Secrets, production configs, or restricted repos are exposed without rules. |
| Repo apps | Which repos, issues, PRs, actions, and code search indexes are connected? | Broad org access exists without owner approval. |
| Terminal agents | Which commands can be suggested, run, or approved? | Network, deploy, destructive, or credential commands lack approval tiers. |
| API keys | Which user or service keys power the workflow? | Shared keys or stale keys remain. |
| PR workflow | Can AI output merge, label, close, comment, or change code? | Human review, CI, or branch protection is bypassed. |
| Incident evidence | Were there bad AI code suggestions, leaked secrets, or production issues this month? | No one owns remediation. |
Use the developer AI tool inventory template and terminal-agent approval rules from How to approve AI agents that can run terminal commands.
Data and retention review
Monthly access review should refresh the data decision, not only the user list.
| Data class | Monthly action |
|---|---|
| Public content | Keep in approved tools if outputs are still reviewed. |
| Internal notes | Confirm the tool is managed and sharing remains narrow. |
| Customer data | Re-check owner approval, redaction, retention, and downstream sharing with the customer data approval form. |
| Source code | Confirm repository rules, secret scanning, and branch protection. |
| Meeting transcripts | Confirm notice, storage, sharing, retention, and deletion. |
| Browser page data | Confirm extension permissions and sensitive host rules. |
| HR, finance, legal, health, payment, government, child, or regulated data | Escalate outside the lightweight review before renewal. |
| Secrets and credentials | Prohibit in AI tools and prepare rotation steps for any exposure. |
NIST’s AI RMF frames AI risk management as a way to improve trustworthy use of AI, while the Privacy Framework focuses on managing privacy risk. For a small team, those ideas become recurring access, data, and evidence decisions.
Incident and exception review
Do this even if there were no major incidents.
| Item | Question | Action |
|---|---|---|
| Accidental paste or upload | Did anyone paste customer data, secrets, source code, or regulated records into an unapproved tool? | Contain, document, rotate if needed, and update the rule. |
| Connector exposure | Did a connector expose broader email, Drive, Slack, GitHub, CRM, helpdesk, or calendar data than approved? | Revoke or scope down, then re-approve. |
| Meeting bot mistake | Was a meeting recorded, summarized, synced, or shared incorrectly? | Remove access, notify owner, and adjust bot defaults. |
| Browser extension issue | Did an extension read sensitive pages or request new permissions? | Remove or rescore. |
| Bad AI output | Did AI-generated content, code, or summaries create a customer, security, or operational issue? | Add human review gate. |
| Overdue exception | Is a temporary exception older than its review date? | Close, renew, restrict, or escalate. |
Incidents should improve the next rule. Do not let the same failure repeat because the review record stayed vague.
Decision register
Copy this register into your review notes.
| Tool or workflow | Owner | Data class | Access reviewed | Decision | Due date | Evidence |
|---|---|---|---|---|---|---|
| Example AI chat workspace | Ops | Internal notes | Users, guests, admins, sharing, retention | Keep | Next month | User list and settings note |
| Example customer support workflow | Support | Customer data | Helpdesk connector, redaction, approval form | Restrict | 7 days | Connector register |
| Example browser extension | IT | Browser page data | Extension ID, all-sites access, OAuth scopes | Remove | Today | Allowlist update |
| Example meeting bot | Sales | Customer transcripts | Recording default, CRM sync, retention | Pilot | 30 days | Bot settings note |
Every row needs an owner and a next review date.
Evidence packet
Keep the packet short and non-sensitive.
Monthly AI tool access review
Review date:
Reviewer:
Business owner:
Admin owner:
Engineering owner:
Incident owner:
Tools reviewed:
Users removed:
Guests removed:
Shared accounts removed:
Personal accounts found:
API keys reviewed:
Connectors reviewed:
Connectors revoked or scoped down:
Browser extensions reviewed:
Extensions removed:
Meeting bots reviewed:
Transcript or retention changes:
Developer AI tools reviewed:
Customer-data workflows reviewed:
Incidents or near misses:
Exceptions closed:
Exceptions renewed:
Top 3 next actions:
Next review date:
Evidence links:
Notes:Store this outside the AI tool being reviewed. Do not include raw customer records, source code, credentials, regulated records, payroll data, legal files, or private contracts.
Monthly metrics
Track only numbers that influence the next review.
| Metric | Good signal | Bad signal |
|---|---|---|
| Approved tools | Stable list with owners. | More tools than owners can review. |
| Restricted or blocked tools | Decisions are enforced. | Same blocked tools keep reappearing. |
| Personal accounts used for work | Decreasing. | Personal accounts touch customer data, code, or transcripts. |
| Connectors reviewed | All high-risk connectors have owners. | Broad connectors have no source-system owner. |
| Browser extensions reviewed | All work AI extensions are allowlisted or removed. | All-sites access is common. |
| Meeting bots reviewed | Retention and sharing rules are documented. | Auto-sharing or permanent transcript retention is unclear. |
| Developer AI tools reviewed | Repo and terminal rules are current. | AI tools can change code or run commands without approval tiers. |
| Risk Checker completions | High-risk tools are re-scored before renewal. | Decisions are made without a current risk record. |
| Incidents and near misses | Reported quickly and converted into fixes. | No reporting path or repeated incidents. |
| Overdue exceptions | Low and shrinking. | Temporary exceptions become permanent. |
If the monthly review only adds metrics and never removes access, simplify it.
Evidence checked
- NIST: AI Risk Management Framework
- NIST: Cybersecurity Framework
- NIST: Privacy Framework
- Cybergiz: Small Team AI Security Checklist
- Cybergiz: AI Tool Risk Checker
- Cybergiz: 30-day AI security rollout plan
- Cybergiz: Small-team AI security setup review checklist
FAQ
Who should run the monthly AI access review?
Use one review owner, usually the founder, operations lead, IT owner, or security-minded manager. They need help from workspace admins, engineering, support, sales, and people operations when the review touches connectors, code, customer data, or meeting records.
Is monthly too often for a small team?
Monthly is appropriate while the AI program is new or while tools touch customer data, source code, browser page data, meeting transcripts, connectors, or automation. Stable low-risk tools can move to quarterly after the team has reliable inventory and offboarding.
What should be removed first?
Remove departed users, stale guests, shared AI accounts, shared API keys, personal accounts used for sensitive work, broad connectors without owners, unapproved all-sites browser extensions, and meeting bots with unclear transcript retention.
Do we need screenshots for every setting?
No. Keep enough evidence to prove the review happened and support the next decision. A user export, connector list, setting note, ticket, or short decision record is often enough. Avoid storing sensitive records as evidence.
What if an employee still needs an unapproved tool?
Move it into an exception record with owner, business need, data class, allowed workflow, restrictions, due date, and next review. If the tool touches customer data, use the customer data approval form.
How does this connect to the Risk Checker?
Use the AI Tool Risk Checker whenever a tool gets a new connector, new user group, new data class, new automation capability, or overdue exception. Copy the result into the Small Team AI Security Checklist so decisions remain visible.