A practical response policy for identifying AI-related harm or control failures, getting the right people into the decision, containing the issue, reviewing notification obligations, and restoring service with evidence and follow-through.
Updated
Generic reusable template · Replace bracketed fields · Review notification obligations for each incident
Use this policy for AI systems that [Organization] develops, operates, buys, or embeds in products and workflows. Adapt the scope, roles, severity criteria, and retention rules to the organization and the systems it uses.
Use the highest credible severity while impact is being assessed. Severity may increase or decrease as evidence develops; record the rationale, time, and person approving each change.
| Severity | Illustrative impact | Escalation trigger and response |
|---|---|---|
| SEV 1 · Critical | Credible risk of death or serious injury; widespread or irreversible harm; major sensitive-data exposure; unauthorized consequential decisions; active compromise with broad reach. | Immediately page the incident commander and executive sponsor; convene security, privacy, legal, system owner, and communications. Consider disabling the affected AI capability while scope is assessed. |
| SEV 2 · High | Material harm or customer impact; repeated unsafe outputs; significant data or access issue; impaired regulated or essential workflow; likely contractual or legal implications. | Escalate promptly to the commander and relevant specialists. Restrict the affected use, assign an impact assessment, and set a frequent update cadence. |
| SEV 3 · Moderate | Limited or contained impact; isolated inaccurate or policy-violating output; near miss; localized service or monitoring failure with a viable human check. | Notify the system owner and designated security, privacy, or compliance contact as relevant. Track remediation and reassess if scope or recurrence changes. |
| SEV 4 · Low / observation | No confirmed harm or exposure; low-impact anomaly, blocked attempt, or control weakness detected before use. | Log and route to the accountable owner for triage. Promote the incident if new facts indicate impact, repetition, or a control failure. |
Escalate regardless of initial severity when there may be personal or sensitive data, a vulnerable or protected population, external customer impact, an unsafe autonomous action, a compromised credential, a vendor or subprocessor event, a legal hold, a regulator or media inquiry, or uncertainty about notification duties. Localize examples and thresholds with [Organization]'s risk owners.
Maintain an on-call directory with contact methods and alternates. One person may hold multiple functions in a small team, but record which decision they are making and when an independent review is required.
| Role | Primary / backup | Responsibilities and decision authority |
|---|---|---|
| Incident commander | [Name / role] · Backup: [Name / role] | Owns severity, response priorities, cadence, assignments, and decision log. May direct temporary containment under this policy and escalate unresolved risk to the executive sponsor. |
| AI / system owner | [Name / role] · Backup: [Name / role] | Identifies system behavior, versions, integrations, affected use cases, and safe rollback or fallback. Executes approved operational changes and validates technical recovery. |
| Security lead | [Name / role] · Backup: [Name / role] | Leads compromise investigation, access and token controls, forensics, and security containment; advises on evidence integrity and threat status. |
| Privacy lead | [Name / role] · Backup: [Name / role] | Assesses personal-data exposure, affected people, data flows, minimization, and privacy obligations; recommends protective steps and notification analysis. |
| Legal counsel | [Name / role] · Backup: [Name / role] | Reviews legal holds, privilege where appropriate, contracts, jurisdiction-specific duties, regulatory engagement, and proposed external statements. |
| Communications lead | [Name / role] · Backup: [Name / role] | Prepares consistent internal and external updates with subject-matter owners; releases communications only through the designated approval path. |
| Executive sponsor | [Name / role] · Backup: [Name / role] | Accepts or rejects material residual risk, approves exceptional business tradeoffs and resource priorities, and resolves disputes that exceed the commander's delegated authority. |
Choose proportionate, reversible controls where practical. The incident commander records what was changed, by whom, when, the reason, and how the change can be verified or reversed.
| Workstream | Response steps | Owner / evidence |
|---|---|---|
| Preserve evidence | Capture relevant prompts, inputs, outputs, model and system versions, configuration, retrieval sources, logs, user reports, timestamps, and decision history. Preserve originals and record collection method, access, time zone, and chain of custody where needed. | [Forensic owner] · Evidence location and references: [Links / IDs] |
| Limit AI behavior | Disable or pause the affected AI feature, tool call, model route, or workflow; roll back to a known-good version if safe; block the affected use case or population; add human review for consequential outputs. | [System owner] · Change and validation record: [Ticket / timestamp] |
| Secure access | Revoke or rotate exposed credentials, API keys, tokens, and service accounts; restrict privileged access; review recent authentication and data access; preserve logs before changing short-lived evidence. | [Security lead] · Access actions: [Record] |
| Protect people and operations | Stop affected automated decisions or actions; identify impacted users, customers, records, and downstream processes; provide a manual fallback with an accountable reviewer and instructions. | [Business owner] · Population and fallback: [Record] |
| Coordinate suppliers | Contact the vendor through the agreed incident channel, request preservation and relevant facts, and coordinate isolation or rollback without surrendering control of the incident record. | [Vendor owner] · Contact and response: [Record] |
Do not delete or overwrite data needed to understand the event. Apply legal hold and retention guidance from counsel, and use approved secure channels for sensitive evidence. Record containment gaps and interim safeguards when an immediate control cannot be applied.
There is no single notification deadline for every AI incident. Legal and privacy owners must assess applicable laws, affected jurisdictions and people, data types, contracts, customer commitments, and regulator requirements. Record the analysis and the source of each deadline before communicating where practicable.
| Audience | When to assess | Owner and approval |
|---|---|---|
| Internal leadership and response teams | Escalate according to severity and trigger criteria; share verified facts, uncertainty, containment, and next update time. | Incident commander; executive sponsor for material risk or resource decisions. |
| Employees and affected business units | When users need to stop a workflow, use a manual fallback, preserve records, or answer questions consistently. | Communications lead with system and business owners; legal review as needed. |
| Customers, users, or impacted individuals | Assess potential harm, data exposure, contractual commitments, applicable law, and useful protective steps for affected people. | Privacy and legal leads with the accountable customer or business owner. |
| Vendors, customers, and other counterparties | Review incident clauses, service terms, data-processing agreements, security addenda, and cooperation requirements. | Vendor / contract owner with legal and security review. |
| Regulators, law enforcement, or public channels | Determine whether a law, regulator request, safety concern, or approved communications plan requires or supports engagement. | Legal counsel leads regulator or law-enforcement contact; communications lead coordinates public statements. |
When a deadline may apply, escalate immediately to counsel and the privacy lead so they can calculate and track the relevant clock. This template does not establish a legal deadline or replace jurisdiction-specific or contract-specific advice.
Recovery is a documented decision. The incident commander and system owner may propose restoration; any required security, privacy, legal, business, or executive approver confirms the gates appropriate to severity and impact.
| Gate | Evidence required before proceeding | Owner / approval |
|---|---|---|
| Containment stable | Immediate threat, unsafe behavior, or uncontrolled exposure is stopped; access and affected workflows are understood; manual fallback remains available. | [Incident commander] · [Approver] |
| Cause and fix understood | Known cause or bounded hypothesis, corrective change, residual uncertainty, and remaining risks are documented. Vendor dependencies and affected outputs or decisions are addressed. | [System owner / security lead] · [Approver] |
| Validation passed | Tests cover the triggering failure, relevant edge cases, security and privacy controls, expected model behavior, and human review. Record test data, results, limitations, and independent checks as required. | [Test owner] · [Reviewer] |
| Staged restoration approved | Start with a limited scope, defined success and stop thresholds, named rollback authority, and a communication plan for affected users. | [Business owner / commander] · [Approver] |
| Heightened monitoring active | Assign monitoring owner, frequency, signals, escalation channel, coverage window, and end condition for heightened observation. | [Monitoring owner] · [Review date] |
Schedule a review after immediate response stabilizes. As an internal starting target, open a SEV 1 review within 5 business days of stabilization, a SEV 2 review within 10 business days, and review lower severity incidents at the next monthly governance meeting; adjust these targets for [Organization]. Conduct a separate safety or legal review when needed. Focus on how the system and response behaved rather than assigning blame.
| Review area | Questions and evidence |
|---|---|
| Timeline and impact | When did the event begin, become detectable, get reported, get contained, and resolve? Which systems, decisions, data, people, and downstream workflows were affected? What remains uncertain? |
| Root cause and contributing factors | What technical, data, model, vendor, workflow, monitoring, access, or governance conditions contributed? Which assumptions or safeguards failed or were missing? |
| Response effectiveness | Did classification and escalation happen at the right time? Were roles and backups reachable? Did evidence preservation, containment, manual fallback, notifications, and recovery gates work as intended? |
| Learning and prevention | What should change in design, testing, monitoring, contracts, training, policy, or response exercises? What near misses indicate broader exposure? |
| Corrective action | Owner | Due date | Completion evidence / approver |
|---|---|---|---|
| [Action, priority, and interim safeguard] | [Name / role] | [YYYY-MM-DD] | [Evidence location / reviewer] |
| [Action, priority, and interim safeguard] | [Name / role] | [YYYY-MM-DD] | [Evidence location / reviewer] |
Assign responders, test the escalation path, and adapt this policy to the AI systems, contracts, and jurisdictions your organization actually uses.
Free assessment · Personalized Compliance Action Plan $299 · No subscription