Copy it, adapt it and test it. That is the purpose of this template for an AI incident response plan. It walks through the sections a workable plan needs, from purpose and roles to containment, notification and post-incident review, with prompts you can fill in for your own organization. It assumes you already have a basic security incident process and adds what AI systems require on top. For professional grounding in the wider discipline, see the certified responsible AI expert certification. This is general information, not legal advice, so have counsel review the final plan.

What is an AI incident response plan?

An AI incident response plan is a written, rehearsed procedure that tells people what to do when an AI system causes harm, behaves unsafely or is attacked. It names who decides, what steps to take, who must be told and how evidence is kept.

A plan is different from a policy. A policy says what you value. A plan says who does what at two in the morning when a chatbot starts giving harmful advice.

Template: preparation sections

Fill these in before any incident happens.

Section 1: Purpose and scope

State why the plan exists and which systems it covers. Include in-house models, vendor AI, generative tools and agents. Add a short definition of "AI incident" with examples, and note how the plan connects to security, privacy and business continuity procedures.

Section 2: Roles and authority

List each role and the named person or team behind it, with backups.

Incident lead: coordinates the response and decides on escalation
Technical lead: investigates and fixes the system
Legal and privacy lead: assesses duties, notifications and risk
Communications lead: manages internal and external messages
Business owner: represents the affected service and its users
Executive sponsor: approves major decisions

State plainly who has the authority to pause or shut down an AI system, and make clear that they can do so without waiting for committee approval.

Section 3: System register and contacts

Link to your AI inventory so responders can quickly find a system's owner, vendor, data, risk tier and fallback process. Keep an up-to-date contact list, including vendor emergency contacts. Confirm that the people holding response roles are qualified, and consider credential checks through services such as HireValid for sensitive positions.

Template: response steps

Write each step as short instructions that a responder can follow under pressure.

Step 1: Detect and report

List the ways incidents are identified, such as monitoring alerts, user complaints, staff reports and vendor notices, and give a single reporting route with a clear contact. Specify the minimum information to capture: what happened, when, which system, who is affected and any evidence.

Step 2: Triage and classify

Provide a severity scale with simple criteria, for example harm to people, data sensitivity, legal exposure, number affected and reversibility. For each level, state who is alerted, the target response time and whether executives are informed.

Sample severity logic

A low-level event might be a minor quality issue with no user impact. A high-level event might involve exposed personal data, unsafe advice to customers or an autonomous system taking unauthorized actions. Adjust the scale to your context.

Step 3: Contain

List containment options for each system type: switch to manual process, disable a feature, restrict inputs, revoke credentials, block an attack path, roll back to a previous version or turn off the system. Note any dependencies that need coordination, such as customer commitments or connected services.

Step 4: Investigate and preserve evidence

Instruct responders to preserve logs, prompts, outputs, model and data versions, configurations and communications before making changes. Define how to determine the cause, including data issues, model behavior, prompt design, attacks, vendor changes or oversight failures. Technical teams with strong engineering foundations, such as those developed through tech certifications, can investigate more effectively.

Step 5: Notify

Create a table or list of notification duties: regulators, affected individuals, customers, partners and insurers, with the trigger and deadline for each, as confirmed by legal counsel. Include a template for each type of notice, and require legal review before sending.

Step 6: Remediate and recover

Describe how to fix the root cause, correct affected outputs or decisions, support harmed individuals and test before restoring service. State who must approve return to normal operation, and consider whether extra monitoring or human review should stay in place temporarily.

Template: after the incident

These sections turn the experience into improvement.

Step 7: Post-incident review

Schedule a blameless review within a set period. Capture the timeline, impact, root causes, what worked, what failed and recommended actions. Assign each action an owner and deadline, and track them to completion.

Step 8: Records and reporting

Log each incident in a central register with severity, timeline, decisions, notifications and outcomes. Keep records secure and tamper-evident, an area linked to topics explored in deep tech certifications. Report trends to leadership on a regular schedule.

Step 9: Communications guidance

Add principles for public statements: be accurate, avoid speculation, take responsibility where appropriate and update as facts develop. Communications staff can strengthen clear, honest messaging through a digital marketing course.

Testing and maintaining the plan

An untested plan is a guess. Run tabletop exercises with realistic AI scenarios, such as a harmful chatbot output or a vendor model update that changes behavior. Involve all named roles, note where people hesitate or disagree and fix gaps. Review the plan on a set schedule, after every significant incident and when systems, vendors or laws change.

Conclusion

This AI incident response plan template covers the sections you need: purpose and scope, roles and authority, a system register and contacts, then the response steps of detection, triage, containment, investigation, notification and recovery, followed by review, records and communications. Fill it in with names and decisions specific to your organization, have legal counsel review it and rehearse it regularly. A short plan that people can actually follow beats a long one that nobody has read.

Frequently asked questions

These are the questions teams ask most about AI incident response plans.

1. What is an AI incident response plan?

A written procedure for handling harm, failures or attacks involving AI systems.

2. How is it different from a policy?

A policy states principles, while a plan says who does what and when.

3. Do we need a separate plan from security incident response?

Not always, but your plan must cover AI-specific harms and link to security processes.

4. Who should lead the response?

A named incident lead with authority to coordinate and escalate.

5. Who can shut down an AI system?

A named person or role with clear authority and no approval delay.

6. What goes in a severity scale?

Harm, data sensitivity, legal exposure, scale and reversibility.

7. What are containment options?

Manual fallback, feature disabling, input limits, access revocation, rollback or shutdown.

8. What evidence should be preserved?

Logs, prompts, outputs, versions, configurations and communications.

9. Who decides about notifications?

Legal and privacy leads, with the incident lead.

10. Should we prepare notice templates?

Yes, with legal review before use.

11. What if the incident involves a vendor?

Use contact lists and contract terms to require quick cooperation and information.

12. How do we handle affected individuals?

Provide notice where required and offer remediation where appropriate.

13. When can a system return to service?

After the root cause is fixed, testing passes and the named approver signs off.

14. What is a blameless review?

A review of causes and weaknesses that avoids blaming individuals.

15. How soon should the review happen?

Within a set period after the incident, while details are fresh.

16. How do we test the plan?

Run tabletop exercises with realistic AI scenarios.

17. How often should we update the plan?

On a schedule and after incidents or major system or legal changes.

18. What records should we keep?

A register of incidents with timelines, decisions, notices and outcomes.

19. Can small organizations use this template?

Yes. Shorten it and keep the roles, steps and contacts.

20. Who should review the final plan?

Legal counsel, security, privacy and business leaders.