checklist

AI chatbot exception register template for small teams

A copyable exception register for customer-facing AI chatbots, covering temporary access, data scope, connectors, tool actions, compensating controls, expiry dates, review evidence, and closure decisions.

Published: Aug 20, 2026 Last reviewed: Aug 20, 2026 Audience: Founders, support leads, product owners, security owners, privacy owners, and admins managing temporary AI chatbot exceptions Risk: High Evidence: NIST AI RMF Core and Manage Playbook, FTC Safeguards Rule guidance, FTC small-business cybersecurity guidance, OWASP LLM06:2025 Excessive Agency, and Cybergiz chatbot access review templates

Use this template when an AI chatbot has a control gap or unusual access condition that cannot be fixed before the team needs to continue operating the workflow.

An exception is a time-bound risk decision, not a second approval path. Record what is different from the approved baseline, why the business needs it, which data or actions are exposed, what compensating controls reduce the risk, who accepted the residual risk, and exactly when the exception expires. Run the AI Tool Risk Checker before accepting a material scope change.

Bottom line

Keep chatbot exceptions narrow, named, observable, and temporary. If an exception has no owner, no expiry, no verification method, or no independent approval for a high-impact action, do not treat it as approved. Suspend the route, reduce its scope, or move the decision to an incident or change review.

Use the Small Team AI Security Checklist for baseline ownership, access review, incident routing, and evidence storage. Use the AI chatbot access recertification checklist to determine whether the exception is still needed, and the AI chatbot tool action approval checklist when the exception affects a downstream action.

When to use this template

Situation	Register an exception?	Immediate boundary
A pilot needs a connector before the normal review is complete	Yes	Limit the source, users, fields, and expiry.
A support operator needs temporary transcript export	Yes	Use a named identity, approved ticket, and monitored window.
A tool action lacks the required downstream policy	Yes, or pause the action	Do not rely on the chatbot prompt as authorization.
A vendor support account must access a customer workflow	Yes	Record sponsor, contract need, named user, and end time.
A service account has broader scope than the intended workload	Yes while fixing, but reduce first	Disable unrelated actions and rotate ownership if needed.
A required security control is unavailable for the route	Yes only with explicit residual-risk approval	Reduce data and action scope or pause the route.
The team wants to keep an exception indefinitely	No	Convert it into a baseline change or redesign the workflow.
A suspected incident caused the exception	No ordinary exception	Preserve evidence and use the incident response path.

Do not publish real customer transcripts, employee directories, tokens, credentials, vendor tickets, or private incident evidence. The register should contain protected references and redacted descriptions only.

Exception lifecycle

Use the same lifecycle for every exception so a temporary decision does not become invisible permanent access.

Identify the deviation from the approved chatbot baseline.
Contain the scope before requesting approval.
Assess affected users, data, connectors, tools, actions, and customer impact.
Choose compensating controls that can be verified during the exception window.
Set an owner, approver, expiry, review date, and closure test.
Monitor the exception and escalate when a trigger occurs.
Close, renew, reduce, or convert the exception into a formal baseline change.

NIST’s AI RMF Manage Playbook treats residual risk as something to document in a risk response plan, including whether it is accepted, transferred, or minimally mitigated. Use this register to make that decision visible, but do not treat the register as a substitute for a required legal, security, privacy, or incident process.

Exception intake form

Copy this form into the protected register.

Field	Entry
Exception ID
Request date and time
Requestor
Business owner
Technical owner
Security or privacy reviewer
Chatbot route and environment
Vendor and model
Exception title
Baseline control that is missing or changed
Business reason and deadline
Users, groups, vendors, or service identities
Data classes and sources in scope
Connectors and tool actions in scope
Customer or internal impact
Risk level
Compensating controls
Monitoring owner and alert path
Expiry date and time zone
Review date
Approval decision
Residual-risk approver
Evidence location
Closure test

Define the exception boundary before collecting approval. A vague title such as “temporary chatbot access” is not enough to review or close.

Exception register

Use one row for each separate deviation. Do not combine unrelated permissions because the same team requested them.

ID	Deviation	Owner	Scope	Risk	Start	Expiry	Decision	Status

Give every entry a stable ID and a single accountable owner.
Describe the exact data, identity, connector, source, channel, tool, or action affected.
Record a fixed expiry date rather than “until the project is done.”
Link the entry to a change, incident, vendor ticket, customer request, or business deadline when relevant.
Keep the current status visible: proposed, approved, active, expiring, suspended, closed, renewed, or converted.

Baseline and deviation matrix

Describe what should happen and what the exception changes.

Control area	Approved baseline	Exception state	Why it matters
User access	Named users with current role need.
Admin access	Named admins with MFA and separate admin work.
Source access	Approved source and field scope.
Connector scope	Minimum required read or write permission.
Tool action	Downstream policy and approval.
Data handling	Approved classes, redaction, and retention.
Logging	Required identity, action, result, and version evidence.
Human handoff	Defined support or escalation path.
Offboarding	Revocation and negative test.
Vendor access	Named support window and contract boundary.

If the exception cannot be expressed as a difference from a known baseline, pause and define the baseline first. Otherwise, the team cannot tell whether the risk was reduced or merely described differently.

Risk and approval matrix

Use a simple decision rule that small teams can apply consistently.

Exception type	Typical risk	Minimum approver	Default decision
Read-only synthetic or public source for a short pilot	Medium	Business and technical owner	Approve with expiry and sample review.
Read-only customer source or transcript access	High	Business owner plus security or privacy reviewer	Reduce fields, name users, monitor, and set short expiry.
Export of raw customer content	High	Business owner plus security or privacy reviewer	Prefer redacted export; approve only for a documented need.
Write, delete, billing, account, or outbound-send action	High	Action owner plus independent approver	Require downstream authorization and human approval.
Vendor or contractor access to customer data	High	Business owner plus vendor or security owner	Require named user, contract basis, MFA, window, and revocation test.
Shared or orphaned service account	High	Technical owner plus security owner	Suspend or replace; do not normalize the account.
Break-glass access	High	Incident or security owner	Use only for the trigger, alert, and post-use review.
Missing logging or unknown downstream result	High	Security owner	Pause the affected action until evidence is sufficient.

The approval level should follow the affected data and action, not the requestor’s job title. If the exception can change customer state, send data outside the approved boundary, or bypass a human decision, treat it as high impact.

Scope reduction checklist

Before asking for approval, shrink the exception.

OWASP’s LLM06:2025 guidance identifies excessive functionality, excessive permissions, and excessive autonomy as common causes of excessive agency. Minimize the extension, permission, and autonomy before deciding whether the exception is acceptable.

Compensating controls

Choose controls that can be checked during the exception, not promises that are difficult to verify.

Gap	Possible compensating control	Verification evidence
Connector scope is temporarily broad	Use a dedicated test tenant or filtered source.	Query result and scope check.
Human approval is not built into the tool	Require an external ticket or approval record before execution.	Approval ID linked to action.
Logging is incomplete	Restrict the route, record request IDs, and add a manual review log.	Sample and reconciliation record.
Vendor access cannot auto-expire	Use a named support window and operator-removal checklist.	Start and closure timestamps.
Model or source change is not yet fully tested	Use a fixed test set and keep the route in a limited pilot.	Test result and observation log.
Raw data cannot be avoided for a specific support case	Redact after the protected workflow and restrict exports.	Data-handling record and access log.
Service identity has legacy scope	Remove unused grants and monitor remaining actions.	Permission diff and negative test.
Break-glass procedure is untested	Run a safe drill in a non-production boundary.	Drill record and alert evidence.

Assign an owner to each compensating control.
Define how often the control is checked.
Define the failure signal and response time.
Link the check to an evidence location.
Do not use a compensating control that depends on the model correctly following an instruction when a downstream policy can enforce it.

Data and privacy review

Question	Entry
What customer or employee data can the exception reach?
Can the workflow use redacted or synthetic data instead?
Which fields are explicitly excluded?
Can the vendor or support staff view the data?
Where can the data be stored, exported, or sent?
What retention and deletion rules apply?
What customer request or legal hold affects the data?
Who approved the data boundary?

Classify the data before approving the exception.
Limit the exception to fields needed for the stated purpose.
Keep raw transcripts and customer exports outside the register itself.
Check whether the exception changes retention, deletion, export, or access obligations.
Record the customer, privacy, legal, or regulatory owner when the workflow requires one.
Re-run the risk assessment when the exception changes data scope or downstream systems.

The FTC Safeguards Rule guidance describes periodic risk reassessment, access-control review, data inventory, MFA, logging, service-provider oversight, and change management as parts of a security program for covered financial institutions. This page is an operational template, not legal advice; use the controls that apply to the business and data involved.

Connector and tool action review

Capability in the exception	Minimum question	Do not approve when
Read source	Which identity reads which records and fields?	The scope crosses an unrelated tenant or source.
Search or retrieval	How are permissions and stale results handled?	The chatbot can retrieve data outside the approved boundary.
Create or update	Who approves the change and how is it reconciled?	The model is the only authorization layer.
Delete	Is deletion required, confirmed, and reversible?	Delete is bundled into a broad extension.
Export or send	Who can approve the destination and content?	Any user can send raw customer data externally.
Billing or account action	What is the customer impact and rollback path?	There is no independent policy or human review.
Webhook or queue	How are retries and unknown results handled?	A duplicate side effect cannot be detected.
Admin setting change	Who can make and review the change?	The same person can change, approve, and conceal it.

Record the downstream identity and effective permissions.
Enforce authorization in the downstream system.
Use idempotency or reconciliation for actions that can retry.
Require human approval for high-impact actions.
Test a denied request and an expired grant before activating the exception.
Disable an action when the logs cannot explain the result.

Monitoring and escalation rules

Signal	First response	Escalate when
Exception used outside the approved window	Stop or revoke the grant.	Customer data or a high-impact action may be affected.
Scope exceeds the register	Contain the route and compare permissions.	Data crossed a tenant, field, or action boundary.
Missing approval or unknown operator	Hold the action and preserve evidence.	The action changed customer or business state.
Failed negative test	Keep the exception inactive.	Revocation or downstream authorization does not work.
Alert or log collector failure	Use the documented fallback and note the gap.	The team cannot reconstruct high-impact activity.
Repeated renewal request	Reassess the baseline and business need.	The exception is becoming a permanent control.
Vendor or contractor cannot confirm closure	Revoke access and contact the sponsor.	Access or data exposure remains uncertain.
Prompt injection or abuse during the exception	Pause the route and preserve a redacted sample.	Permissions, data, or actions changed unexpectedly.

Assign a response owner and target response time to every trigger.
Alert when an exception is close to expiry.
Review all high-impact uses, not only failed requests.
Link suspected incidents to the protected incident record.
Record whether a trigger caused suspension, renewal, reduction, or closure.

Expiry and renewal rules

Status	Required action
Proposed	No production use; collect scope, owner, controls, and approval.
Approved	Activate only the recorded scope and start the monitoring window.
Active	Review use, alerts, compensating controls, and approaching expiry.
Expiring	Decide to close, reduce, renew, or convert before the deadline.
Suspended	Revoke or isolate access and investigate the trigger.
Closed	Run the closure test and record the final evidence.
Renewed	Create a new decision with a new reason and expiry; do not silently extend the old row.
Converted	Update the approved baseline through change management.

Never renew solely because the business still wants the feature.
Require a new reason, current evidence, and an updated risk decision.
Shorten the next window when the exception was used more often or more broadly than expected.
Convert repeated exceptions into a formal control change or redesign.
Close exceptions automatically where the platform supports expiry.

Closure test

Do not mark the exception closed until the team can prove that the temporary condition is gone.

Closure test	Expected result	Evidence
Temporary user or group removed	Identity cannot reach the route.	Denial record and timestamp.
Connector scope reduced	Excluded source or field is denied.	Redacted query result.
Tool action disabled	Action is unavailable and has no downstream side effect.	Tool and downstream records.
Vendor window ended	Named access and active sessions are revoked.	Closure checklist and access log.
Service account replaced	Old credentials fail and new scope is documented.	Rotation and negative test.
Data export completed	Protected copy is stored and temporary files are deleted.	Retention and deletion evidence.
Compensating control removed	The baseline control is now active or the route is paused.	Change or pause record.

Test the actual revoked or reduced permission, not just the admin console state.
Check queued jobs, webhooks, scheduled tasks, and pending approvals.
Review recent use for unexpected data access or side effects.
Record the operator, time, environment, result, and evidence pointer.
Reopen the exception or create an incident when closure cannot be verified.

Decision record

Field	Entry
Exception ID
Decision date
Decision	Approve, reduce, suspend, close, renew, or convert.
Scope approved
Data and action boundary
Compensating controls
Monitoring owner
Expiry and review date
Residual risk summary
Approver and role
Dissent or conditions
Evidence location

NIST AI RMF does not prescribe one risk tolerance for every organization or use case. The decision record should therefore state the context, residual risk, conditions, and accountable approver instead of using an unexplained label such as “accepted.”

Remediation tracker

Gap or follow-up	Severity	Owner	Due date	Closure test	Status

Separate baseline fixes from exception monitoring tasks.
Give every fix a due date and a verification result.
Re-run the AI Tool Risk Checker when a fix changes data, connector, user, or action scope.
Escalate overdue high-risk fixes instead of renewing automatically.
Link a repeated gap to a change request, vendor review, or product decision.

Final exception review checklist

Metrics to track

Number of active chatbot exceptions by data class, connector, tool, and risk level.
Percentage of exceptions with a named owner, approver, expiry, and closure test.
Percentage of high-impact exceptions with downstream authorization or human approval.
Number of exceptions reduced, suspended, closed, renewed, or converted each period.
Average time from exception request to decision and from expiry to verified closure.
Number of exceptions used outside scope or after expiry.
Number of failed negative tests, missing logs, and unreviewed alerts.
Number of repeated exceptions tied to the same baseline control gap.
Percentage of overdue remediation actions and exceptions.

Evidence checked

NIST AI RMF Core describes risk management outcomes including safe operation, monitoring, change management, and risk-based resource allocation.
NIST AI RMF Manage Playbook discusses documenting residual risk, roles, delegated authority, monitoring, re-verification, and updates.
NIST AI RMF 1.0 explains that risk tolerance is contextual and that the framework does not prescribe one tolerance level for every organization.
FTC Safeguards Rule guidance covers periodic risk reassessment, access controls, MFA, logging, service providers, and change management for covered financial institutions.
FTC Cybersecurity for Small Business recommends need-to-know access, vendor controls, MFA, incident response, and recovery practices.
OWASP LLM06:2025 Excessive Agency recommends minimizing functionality and permissions, using downstream authorization, requiring approval for high-impact actions, and monitoring extensions.
Cybergiz internal templates for chatbot access recertification, audit logs, tool actions, incident review, and general AI exceptions were checked for overlap and linked boundaries.

FAQ

Is an exception the same as an approval?

No. An approval authorizes the normal baseline. An exception records a temporary deviation from that baseline, the reason for it, the compensating controls, and the date when the deviation must end or be re-decided.

How long should a chatbot exception last?

Use the shortest window that supports the stated work. High-risk data or action exceptions usually need a short window and more frequent checks. If the same exception keeps being renewed, stop treating it as temporary and decide whether to fix the baseline, redesign the workflow, or retire the capability.

Who can approve a high-risk chatbot exception?

The approver should own the affected business outcome and have the authority to accept the residual risk. Include security or privacy review when the exception changes sensitive data, access, retention, vendors, or customer impact. For legal or regulated workflows, follow the applicable internal and external requirements.

Can a prompt instruction be a compensating control?

It can be one layer of a control, but it should not be the only authorization for a high-impact action. Put the decisive permission and policy check in the downstream system, and require human approval where the impact warrants it.

What should happen when an exception expires but the work is unfinished?

Suspend or reduce the access first, then create a new decision with a current reason, evidence, scope, approver, and expiry. Do not silently extend the old row or let the platform’s default behavior decide.

Should an incident be recorded as an exception?

No. An exception may describe a pre-approved temporary deviation. A suspected incident requires evidence preservation, containment, impact assessment, and the team’s incident response path. Link the exception history to the incident record when they are related.

Where should the real register be stored?

Store it in a protected governance or evidence system with need-to-know access, retention, and deletion rules. The public template should contain only reusable fields and decision logic, never raw customer data, credentials, tokens, or private employee information.

What is the minimum record for a small team?

Record the deviation, business reason, owner, affected scope, risk level, compensating control, approver, start and expiry times, monitoring path, closure test, and evidence location. If any of these are unknown, the team has an open risk question rather than a complete exception decision.