checklist
Small-team AI security setup review checklist
A practical checklist for reviewing a small team's AI security setup across tools, data rules, accounts, connectors, browser extensions, meeting bots, developer AI, incidents, and a 30-day action plan.
Use this checklist when a team already uses AI tools and needs a practical setup review before the sprawl gets worse.
The goal is not to create a formal audit. The goal is to find the obvious gaps: unmanaged tools, unclear data rules, broad connectors, AI browser extensions, meeting transcripts, developer AI access, missing owners, and no incident path. Start with the AI Tool Risk Checker, then store the results in the Small Team AI Security Checklist.
Bottom line
A small-team AI security setup review should answer seven questions:
- Which AI tools are actually used for work?
- Which accounts, browser extensions, bots, agents, and connectors can access company data?
- What customer, employee, source-code, meeting, financial, or regulated data can enter each workflow?
- Which tools are approved, restricted, in pilot, or blocked?
- Who owns admin settings, offboarding, incidents, and policy exceptions?
- What can be fixed in the next 30 days?
- What evidence proves the review happened?
If the team cannot answer those questions, it is not ready for broader AI rollout.
Review scope
| Area | Include | Exclude from lightweight review |
|---|---|---|
| AI tools | Chat tools, coding assistants, meeting bots, browser extensions, AI agents, AI writing tools, and embedded SaaS AI features. | Full vendor due diligence or SOC 2 review. |
| Data | Customer data, source code, credentials, transcripts, files, CRM/helpdesk records, HR/finance/legal records, and confidential plans. | Raw customer exports, passwords, API keys, private keys, regulated records, or private contracts. |
| Accounts | Managed workspaces, personal accounts used for work, shared accounts, admins, guests, and departed users. | Password collection or account takeover testing. |
| Integrations | Gmail, Drive, Docs, Slack, GitHub, CRM, helpdesk, calendar, meeting platforms, browser extensions, and custom automations. | Penetration testing or source-code review of vendors. |
| Output | Customer-facing content, support replies, code changes, summaries, decisions, and records created or changed by AI. | Legal, compliance, certification, or security assurance opinions. |
If you need a fixed-scope external review, the AI Security Setup Review page defines what Cybergiz’s pilot offer includes and what it deliberately excludes.
Setup review checklist
| Check | Pass condition | Evidence to collect |
|---|---|---|
| Owner named | One business owner and one admin owner are responsible for AI usage. | Owner names and backup owner. |
| Tool inventory exists | All known AI tools, bots, extensions, agents, and embedded AI features are listed. | Inventory table or export. |
| Data rules exist | Employees know which data is allowed, restricted, or prohibited. | Policy page or checklist. |
| Managed accounts preferred | Work data uses managed company workspaces where practical. | Workspace admin screenshot or notes. |
| No shared AI accounts | Shared logins and shared API keys are blocked. | Account list and key owner list. |
| MFA is required | AI workspaces and connected systems require MFA where available. | Admin settings note. |
| Connectors are approved | Email, Drive, Docs, Slack, GitHub, CRM, helpdesk, calendar, and meeting connectors have owners. | Connector register. |
| Browser extensions are reviewed | AI extensions are scored for permissions, site access, and offboarding. | Extension allowlist and risk score. |
| Meeting bots have rules | Consent, transcript storage, retention, and sharing rules exist. | Meeting bot policy or approval record. |
| Developer AI has boundaries | Source code, secrets, terminal commands, repositories, and production workflows are controlled. | Developer AI inventory and PR rules. |
| Incident path exists | Accidental paste, upload, recording, connector, or secret exposure has a named response path. | Incident contact and first-hour checklist. |
| 30-day plan exists | Fixes are ranked by owner, urgency, and business risk. | Action plan table. |
Intake questions
Ask these before reviewing the setup:
| Question | Why it matters |
|---|---|
| Which AI tools are approved today? | Reveals whether approval is real or assumed. |
| Which AI tools do employees use without approval? | Finds shadow AI before it touches sensitive data. |
| Which tools use personal accounts for work? | Personal accounts are harder to offboard and govern. |
| Which systems are connected to AI tools? | Connectors often expose more data than prompt boxes. |
| Which browser extensions can read work pages? | Extensions can see data across Gmail, Docs, CRM, password managers, and admin consoles. |
| Which meetings are recorded or summarized by AI? | Transcripts need consent, storage, retention, and sharing rules. |
| Which AI tools can change code, tickets, CRM records, or customer messages? | Action-taking workflows need human review and rollback. |
| Who handles mistakes? | Fast reporting is only useful when the owner is known. |
Do not ask employees to send raw customer files, source code, passwords, API keys, or private contracts to complete the review.
Tool inventory review
Start with a simple inventory. Use the developer AI tool inventory template for engineering-heavy teams.
| Tool | Type | Account model | Data exposed | Integrations | Owner | Status |
|---|---|---|---|---|---|---|
| ChatGPT / Claude / Gemini / Copilot | Chat workspace | Managed or personal | Prompts, files, project data | Optional connectors | Operations or IT | Approved / Restricted / Pilot / Blocked |
| Cursor / Copilot / code assistant | Developer AI | Managed or local | Source code, repo context, prompts | GitHub, IDE, terminal | Engineering | Approved / Restricted / Pilot / Blocked |
| Meeting bot | Meeting AI | Managed or personal | Audio, transcript, summary, attendees | Calendar, CRM, Slack, Drive | Sales/CS/People | Approved / Restricted / Pilot / Blocked |
| Browser extension | Extension | Browser profile | Page content, selected text, clipboard, cookies, host data | OAuth or vendor cloud | IT/admin | Approved / Restricted / Pilot / Blocked |
| Embedded SaaS AI | Product feature | Existing SaaS account | App-specific records | Native app data | App owner | Approved / Restricted / Pilot / Blocked |
Every row needs an owner. Tools without an owner should default to “needs review” or “blocked” for sensitive data.
Data handling review
Use this table to decide what the review must test.
| Data class | Review question | Default action |
|---|---|---|
| Public content | Is the AI tool used only with public material? | Allow in approved tools. |
| Internal notes | Could outputs reveal confidential plans? | Allow in managed tools with review. |
| Customer data | Are identifiers, tickets, CRM records, contracts, or transcripts involved? | Use the customer data approval form. |
| Source code | Does the tool see private repos, secrets, incidents, or production code? | Use developer AI rules and secret scanning. |
| Meeting transcripts | Are external, customer, hiring, or sensitive calls recorded? | Use meeting bot consent and retention rules. |
| Browser page data | Can an extension read Gmail, Docs, CRM, password manager, or admin pages? | Score it with the extension risk matrix. |
| Credentials and secrets | Could API keys, tokens, private keys, cookies, or recovery codes appear? | Prohibit and prepare rotation steps. |
| HR, finance, legal, health, payment, government, child, or regulated data | Could the workflow process regulated or high-impact records? | Escalate outside this lightweight review. |
NIST’s Generative AI Profile describes risks such as data privacy, human-AI configuration, information integrity, information security, and value-chain/component integration. For a small team, those risks show up as everyday workflow decisions: what employees paste, which apps they connect, and what AI output is allowed to change.
Connector review
Connectors deserve separate review because they can pull data without a user copying and pasting it.
| Connector | Review check | Block until resolved if |
|---|---|---|
| Gmail / email | Which mailboxes, labels, attachments, and historical messages can the tool access? | It can scan broad customer or employee mail without owner approval. |
| Drive / Docs / files | Which folders, shared drives, and file types are exposed? | It can access broad company or customer folders without scope limits. |
| Slack / Teams | Which channels, DMs, files, and history are exposed? | Private channels or customer incident channels are included by default. |
| GitHub / GitLab | Which repos, issues, pull requests, secrets, and workflows are exposed? | It has write access without branch protection and human review. |
| CRM / helpdesk | Which customer records, tickets, notes, contracts, and exports are exposed? | Bulk customer data can be analyzed or exported without approval. |
| Calendar / meeting | Which meeting titles, attendees, recordings, transcripts, and summaries are exposed? | External or sensitive meetings are recorded by default. |
For ChatGPT connector workflows, pair this section with the ChatGPT connector approval template.
Browser extension review
AI browser extensions need their own pass because they sit between employees and the web apps that contain business data.
| Check | Pass condition |
|---|---|
| Extension ID recorded | The exact extension and vendor are identified. |
| Permission score recorded | Page access, host permissions, and sensitive APIs are reviewed. |
| Sensitive hosts listed | Gmail, Docs, CRM, password manager, SSO, admin, source-control, finance, and HR sites are considered. |
| OAuth scopes reviewed | Connected-account access is reviewed separately from browser permissions. |
| Role-based approval | The extension is approved for a user group, not every employee by default. |
| Offboarding path exists | Removal covers extension install, OAuth app, vendor account, and browser profile. |
Use the AI browser extension risk scoring matrix for the detailed scoring pass.
Meeting bot review
Meeting bots create retained records that employees may treat as informal notes even when they contain customer, candidate, or internal strategy data.
| Check | Pass condition |
|---|---|
| Meeting categories defined | Sales, support, hiring, internal, legal, finance, security, and customer escalations have different rules. |
| Notice script exists | Hosts know how to tell attendees when AI recording or summarization is used. |
| Retention rule exists | Raw audio, transcript, summary, and CRM sync have retention/deletion rules. |
| Sharing rule exists | Summaries are not auto-shared externally or broadly internally by default. |
| Human review required | Customer-facing notes and CRM updates are reviewed before use. |
| Incident path exists | Accidental recording or sharing has a containment workflow. |
Start with the meeting transcript retention policy template if the team records many calls.
Developer AI review
Developer AI often becomes higher risk when it can see secrets, operate on private repositories, or run terminal commands.
| Check | Pass condition |
|---|---|
| Tool inventory exists | Coding assistants, IDE extensions, PR bots, code search, and terminal agents are listed. |
| Repository rules exist | Sensitive repos have AI usage rules before tools index or edit them. |
| Secret controls exist | .env, keys, tokens, certificates, and production credentials are excluded and scanned. |
| PR review remains human-owned | AI suggestions do not bypass code review, CI, or branch protection. |
| Terminal commands are tiered | Read-only, local write, network, deploy, and destructive commands have different approval rules. |
| Incident plan exists | Bad AI-assisted code, leaked secrets, and production changes have response steps. |
For terminal-capable agents, use How to approve AI agents that can run terminal commands.
Admin control review
This section maps the review to practical controls a small team can actually maintain.
| Control | Minimum evidence |
|---|---|
| MFA | MFA enabled for AI workspaces and connected systems where available. |
| Admin ownership | Each AI workspace has a named admin and backup admin. |
| User lifecycle | Joiner, mover, and leaver steps cover AI tools, bots, extensions, and connected apps. |
| Workspace settings | Training, retention, sharing, connector, export, and guest settings are documented. |
| Access review | Users, guests, projects, bots, extensions, API keys, and connected apps are reviewed monthly while the program is new. |
| Logs and records | Approval decisions and incidents live outside the AI tool itself. |
| Backups and recovery | Important business data remains recoverable outside AI-generated summaries. |
This matches the operating spirit of NIST CSF 2.0: govern who owns risk, identify assets and data, protect access, detect problems, respond to incidents, and recover.
Evidence packet
Collect a lightweight evidence packet so the review is useful later.
Small-team AI security setup review
Review date:
Reviewer:
Business owner:
Admin owner:
Tools reviewed:
Tools approved:
Tools restricted:
Tools blocked:
Personal accounts found:
Shared accounts found:
Connectors reviewed:
Browser extensions reviewed:
Meeting bots reviewed:
Developer AI tools reviewed:
Highest-risk data class:
Top 3 gaps:
30-day actions:
Next review date:
Evidence links:
Notes:Do not put secrets, private customer records, source code, payroll data, legal files, or regulated records in the evidence packet.
30-day action plan
| Priority | Action | Owner | Due |
|---|---|---|---|
| 1 | Freeze new AI tools until the inventory is complete. | Operations or IT | Day 2 |
| 2 | Move work AI use into managed workspaces where practical. | Admin owner | Day 7 |
| 3 | Publish allowed/prohibited data rules. | Business owner | Day 7 |
| 4 | Review connectors to Gmail, Drive, Slack, GitHub, CRM, helpdesk, calendar, and meeting platforms. | Admin owner | Day 10 |
| 5 | Review AI browser extensions and remove high-risk unmanaged installs. | IT owner | Day 14 |
| 6 | Set meeting bot notice, retention, and sharing rules. | Sales/CS/People owner | Day 14 |
| 7 | Add developer AI repository and terminal-command rules. | Engineering owner | Day 21 |
| 8 | Run the top five tools through the Risk Checker. | Tool owners | Day 21 |
| 9 | Create an incident contact path for AI data exposure. | Founder or operator | Day 25 |
| 10 | Re-review exceptions and publish final approve/restrict/block list. | Business owner | Day 30 |
Evidence checked
- NIST: AI Risk Management Framework
- NIST: Generative AI Profile linked from the AI Risk Management Framework page
- NIST: Cybersecurity Framework
- NIST: Privacy Framework
- Cybergiz: Small Team AI Security Checklist
- Cybergiz: AI Tool Risk Checker
- Cybergiz: AI Security Setup Review
FAQ
Is this checklist a security audit?
No. It is a practical setup review for small teams. It helps identify gaps and next actions, but it is not a penetration test, legal opinion, compliance certification, vendor due diligence report, or security assurance.
How long should the review take?
A small team can complete a first pass in 60-90 minutes if the tool list is short. The hard part is usually not the checklist; it is finding all the personal accounts, browser extensions, meeting bots, and connected apps employees already use.
Who should own the review?
Use two owners: a business owner who decides what risk is acceptable, and an admin owner who can change settings, remove users, revoke connectors, and enforce offboarding.
What should be blocked immediately?
Block shared AI accounts, shared API keys, AI workflows that process secrets, unmanaged extensions with broad access to sensitive work apps, and tools that connect to customer systems without a named owner.
Should every AI tool get the same review?
No. Low-risk tools that only touch public content can use a lighter record. Tools that touch customer data, source code, meeting transcripts, browser page data, email, Drive, CRM, HR, finance, or legal records need a deeper review.
What should we do after this checklist?
Pick the top five tools employees already use, run each through the AI Tool Risk Checker, and copy the final approve/restrict/block decisions into the Small Team AI Security Checklist. If you want an outside fixed-scope pass, review the AI Security Setup Review scope before sending any non-sensitive intake information.