checklist

AI tool audit evidence packet template for small teams

A reusable evidence packet template for AI tool reviews, covering owners, access, connectors, data handling, retention, admin controls, incidents, exceptions, decisions, and safe storage rules.

Published: Jul 6, 2026 Last reviewed: Jul 6, 2026 Audience: Founders, operators, IT owners, workspace admins, finance owners, security leads, and team managers who need evidence for AI tool reviews Risk: Medium Evidence: NIST AI RMF, NIST Cybersecurity Framework, NIST Privacy Framework, and Cybergiz AI tool review templates

Use this template when an AI tool review needs evidence, not just opinions.

Small teams do not need a heavy audit program. They do need a short, repeatable evidence packet that proves who owns the tool, who can access it, what data it touches, which connectors are enabled, which settings were checked, what incidents happened, and what decision was made. If you are doing a monthly review, start with the monthly AI tool access review checklist and use this page to package the evidence.

Bottom line

An AI tool evidence packet should answer seven questions:

Why is this tool approved, restricted, piloted, excepted, or removed?
Who owns business value, admin settings, data scope, and source-system access?
Who can use or administer the tool today?
Which data, connectors, extensions, bots, APIs, and automations are in scope?
Which settings, retention rules, training defaults, and sharing controls were verified?
Which incidents, exceptions, vendor changes, or renewal decisions affect the tool?
What decision was made, and when is the next review?

Do not put raw customer records, source code, meeting transcripts, passwords, API keys, private keys, regulated records, or dashboard URLs with tokens into the packet.

When to use this template

Situation	Use this packet?	Why
Monthly AI tool access review	Yes	Keeps review evidence consistent across tools.
Pilot exit	Yes	Supports approve, restrict, extend, remove, or escalate decisions.
Exception review	Yes	Shows why temporary access exists and when it closes.
Renewal decision	Yes	Connects business value, access, vendor changes, and cost.
Vendor change review	Yes	Records what changed and what setting evidence was checked.
Incident response	Yes	Links containment, root cause, and corrective actions.
One-time public-content experiment	Usually no	Close the experiment unless the tool remains in use.

If the tool’s scope changed, rerun the AI Tool Risk Checker before finalizing the packet.

Evidence packet map

Packet section	Evidence to include	Do not include
Tool identity	Tool name, vendor, plan, status, owner, review date.	Account IDs with tokens or private billing details.
Business use	Approved workflow, actual workflow, value summary.	Customer examples with private data.
Access	Users, admins, groups, guests, service accounts.	Passwords, private emails beyond what your internal access export already allows.
Connectors	OAuth apps, browser extensions, meeting bots, API keys, webhooks.	API keys, bearer tokens, private keys, webhook secrets.
Data handling	Data classes, prohibited data, retention rule, export rule.	Raw sensitive records, source code, transcripts, or regulated files.
Settings	Training, retention, sharing, export, audit, deletion, SSO, logs.	Screenshots that expose secrets or customer records.
Incidents and exceptions	Incident IDs, exception IDs, status, owner, expiry.	Raw incident payloads with sensitive data.
Decision	Approve, restrict, renew, pilot, escalate, remove.	Informal chat fragments as the only evidence.

The packet should be short enough to review in a meeting.

Minimum packet

For low-risk tools, collect at least this:

Field	Value
Tool name
Vendor
Status	Approved / restricted / pilot / exception / blocked / removed
Review date
Reviewer
Business owner
Admin owner
Approved use case
Actual use case
Approved users or groups
Connected systems
Allowed data classes
Prohibited data classes
Settings checked
Incidents or exceptions
Decision
Next review date
Evidence links

For medium or high-risk tools, use the deeper sections below.

Owner and scope evidence

Evidence	Question it answers
Original request or intake form	Why was this tool requested?
Pilot exit decision	Why did the tool move out of pilot?
Owner register	Who owns value, admin settings, data, source systems, and backup coverage?
Approved use case	What workflow is allowed?
Actual use case notes	Did users stay within the approved workflow?
Risk checker result	Did the current scope match the current risk decision?
Review calendar entry	When is the next review or expiry date?

Use the AI tool owner and review calendar template when ownership is unclear.

Access and connector evidence

Evidence	What to capture
User export	Active users, inactive users, guests, shared accounts, and personal accounts used for work.
Admin export	Admins, billing owners, workspace owners, and source-system admins.
Group mapping	Groups or teams with access and why they need it.
OAuth app list	Connected apps, scopes, source systems, and owner.
Browser extension record	Extension ID, version, host permissions, sensitive domains, OAuth scopes, and install policy.
Meeting bot record	Calendar app, recording settings, transcript settings, sharing, CRM sync, and retention.
Developer AI record	Repos, code indexes, terminal access, PR bot access, CI/CD scope, and secret boundaries.
API and automation record	API keys by owner and purpose, webhooks, scheduled jobs, agents, and rollback paths.

Never paste live keys, tokens, secrets, or private certificates into the evidence packet.

Data and retention evidence

Evidence	What to verify
Data classification note	Public, internal, customer, source code, transcript, regulated, financial, or secret data classes.
Customer data approval	Whether customer data is allowed, redacted, approval-required, or prohibited.
Retention setting note	Prompt, file, transcript, memory, project, log, and export retention.
Training setting note	Whether workspace or account defaults match the approved data rule.
Sharing setting note	Public links, external guests, exports, downstream sync, and forwarding.
Deletion path	Whether retained files, prompts, transcripts, accounts, and connectors can be removed.
Export record	What was exported, why, where it is stored, and who owns it.

For customer workflows, link to the customer data approval form instead of copying customer records.

Admin control evidence

Control	Evidence to keep
SSO or identity path	Setting note or admin export showing approved authentication.
User lifecycle	Offboarding steps for users, guests, admins, bots, and service accounts.
Audit logs	What activity can be reviewed and how long logs are available.
Sharing controls	Workspace defaults for guests, public links, exports, and collaboration.
Connector controls	How connectors are approved, revoked, and reviewed.
Retention controls	Screenshots or notes with sensitive values redacted.
Training controls	Workspace setting evidence with date and reviewer.
Incident controls	Where accidental paste, connector exposure, or bad output is reported.
Billing controls	Renewal date, owner, and cancellation path without private payout or tax details.

If required controls are missing, record the decision as restricted, exception, escalation, or removal.

Incident and exception evidence

Record type	Include
Incident	Incident ID, date, owner, affected workflow, affected data class, status, and corrective action.
Near miss	What almost happened, how it was caught, and what guardrail changed.
Bad output	Output type, human review result, business impact, and training need.
Accidental paste	Data class, containment action, owner, and vendor/source-system follow-up.
Connector exposure	Connector, source system, exposed scope, containment, and decision.
Exception	Exception ID, owner, approved scope, guardrails, expiry date, and closure status.
Vendor change	Change source, affected settings, decision, and next review date.

Link to the incident or exception record. Do not copy sensitive payloads into the packet.

Review decision record

Copy this into the packet.

AI tool evidence packet decision
Tool:
Vendor:
Review type:
Review date:
Reviewer:
Business owner:
Admin owner:
Data/source-system owner:
Current status:
Approved use case:
Actual use case:
Users/groups reviewed:
Connectors reviewed:
Data classes reviewed:
Settings reviewed:
Incidents/exceptions reviewed:
Vendor changes reviewed:
Decision:
Restrictions:
Cleanup actions:
Next review date:
Evidence links:
Notes:

The decision should be one of: approve, restrict, pilot, extend once, renew, monitor, escalate, remove, or block.

Storage and redaction rules

Rule	Why
Store packets outside the AI tool being reviewed.	Evidence must survive offboarding and deletion.
Use links to source records instead of copying sensitive data.	Keeps the packet small and safer.
Redact customer names, secrets, private records, transcripts, and source code.	Reviewers need scope, not raw content.
Record dates and reviewers.	Evidence without timing and ownership decays quickly.
Keep one packet per review event.	Monthly review, renewal, incident, and vendor change may have different decisions.
Limit packet access.	Evidence can still reveal sensitive business workflows.
Delete packets by policy.	Evidence retention should not become unmanaged data retention.

If you cannot store the packet safely, store only the decision record and pointers to controlled systems.

30-minute assembly checklist

Step	Done
Confirm review type, tool status, owner, and next review date.
Link the original request, intake form, pilot exit, or renewal record.
Export users, admins, groups, guests, and service accounts.
Review connectors, browser extensions, meeting bots, API keys, and automations.
Record data classes, prohibited data, retention, training, sharing, and deletion settings.
Link incidents, exceptions, vendor changes, and renewal decisions.
Write the decision record.
Redact sensitive details and remove secrets.
Store the packet in the approved internal location.
Update the review calendar or tool register.

If this takes longer than 30 minutes for every tool, split tools by risk and start with high-risk workflows.

Metrics to track

Metric	Why it matters
Packets completed	Shows whether reviews produce evidence.
Packets missing owners	Shows accountability gaps.
Packets missing access exports	Shows weak access review.
Packets missing connector evidence	Shows hidden integration risk.
Packets with incidents or exceptions	Shows where follow-up is needed.
Packets leading to restrictions	Shows risk reduction from review.
Packets leading to removals	Shows the team can clean up tools.
Average assembly time	Shows whether the process is sustainable.
Evidence storage exceptions	Shows where evidence handling itself needs improvement.

If evidence packets are always incomplete, reduce the tool list or narrow the approval scope.

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: Monthly AI tool access review checklist
Cybergiz: AI tool renewal decision checklist
Cybergiz: AI vendor change review checklist

FAQ

Is this an audit?

Not in the formal assurance sense. This is an internal evidence packet for small-team AI tool reviews. It helps owners make and defend decisions, but it is not legal, compliance, certification, or security assurance advice.

Where should we store the packet?

Store it in an internal system outside the AI tool being reviewed, such as a secure document workspace, ticket, or governance folder with access limited to the people who need it.

Should screenshots be included?

Screenshots can help for settings evidence, but redact customer records, tokens, private messages, source code, transcripts, and sensitive account details. A short setting note is often safer than a screenshot.

How much evidence is enough?

Enough to prove owner, use case, access, connector scope, data scope, settings, incidents, exceptions, and decision. Low-risk tools can use the minimum packet. High-risk tools need the deeper sections.

Who owns the packet?

The review owner owns the packet. The business owner owns the decision, the admin owner owns settings and access evidence, and the data or source-system owner owns data scope evidence.

How does this connect to the main checklist?

The Small Team AI Security Checklist defines the baseline controls. This evidence packet shows whether those controls are actually being reviewed for each tool.