AI Incident Response Plan

An AI incident response plan tells people how to recognise a potentially harmful AI event, contain the affected activity, preserve evidence, assess consequences and authorise recovery. It should work before the organisation knows whether the cause is the model, a source document, an integration, a permission or a human action.

The first useful question is not “was the AI hacked?” It is “what may have happened, who or what may be affected, and which action can prevent further harm while we establish the facts?” An inaccurate recommendation, confidential information in a generated draft and an unintended agent transaction can need different responses even when they occur in the same platform.

This guide provides an original plan structure and a tabletop example for Saudi governance, security, privacy and operating teams. It connects incident decisions to governance setup, keeping reporting obligations and technical investigation within their appropriate specialist responsibilities.

Define which events enter the response route

Give staff recognisable triggers: information appearing where it should not, a consequential action without the expected approval, a repeated unsupported statement used in a business process, unexpected access or an inability to stop an agent. Accept uncertain reports. The employee should not need to prove a breach or diagnose the technology before the organisation starts triage.

Distinguish an observation from its interpretation. “A supplier's rate appeared in another supplier's draft email” is an observation. “The model leaked all supplier data” is a hypothesis that requires evidence. Recording the two separately keeps the response proportionate and prevents early wording from becoming an unsupported executive or external statement.

Define how ordinary defects, near misses and active incidents are routed. A harmless draft correction may belong in a product-quality queue; a recurring error influencing customer treatment may need incident handling. The distinction depends on the activity, consequence and exposure, not simply the severity label produced by a software tool.

NIST SP 800-61 Revision 3 integrates cybersecurity incident response with broader cybersecurity risk management. An AI plan can connect to that established response structure while adding the relevant model, data, output and action evidence. It need not create a second disconnected command structure.

Write the first-report form for a person under pressure

Ask for the affected use or application, the time noticed, what the reporter observed, the action already taken and a safe way to locate evidence. Include whether an output was merely generated, shown internally, sent externally or used to change a record. Those distinctions can matter more than a detailed model description in the first few minutes.

Do not require unrestricted prompt or customer-content uploads into an incident form. The form itself may have a wider audience than the source system. A controlled record reference, request identifier or appropriately prepared screenshot can direct an authorised investigator to the evidence. Define a secure route for material that cannot be described safely in the general ticket.

Make the receiving team and backup route explicit. A generic instruction to “contact IT” can fail outside office hours or when the application belongs to a business unit. State how acknowledgement occurs and who can escalate if the initial recipient is unavailable. Internal response targets should be agreed for the organisation; they are not substitutes for any applicable legal timetable.

Assign containment, investigation and notification authority

Decisions to assign before an incident

Decision	Accountable capability	Boundary to record
Pause the affected activity	Operating or incident authority with a tested control	What can be stopped and what business fallback continues
Preserve and inspect evidence	Authorised investigation team	Access, handling, retention and chain of decisions
Assess affected people and obligations	Relevant privacy, legal, security and business specialists	Applicable requirements and the facts supporting the assessment
Communicate internally or externally	Designated communications decision maker	Audience, confirmed facts, review and approval
Resume or expand operation	Authorised service and risk decision roles	Required repair evidence, remaining restrictions and monitoring

One person can coordinate these decisions without personally possessing every specialist authority. The plan should identify who can act immediately and what needs escalation. A supplier's support team may help diagnose the issue, but should not become the unrecorded decision maker for the customer's external communication or acceptance of remaining risk.

Include an alternate for material roles and a route for conflicts. The person who approved a disputed configuration can provide evidence, while another authorised role may need to lead the decision about resumption. The responsibility map and approval routes should reflect these emergency responsibilities rather than leaving them in an isolated appendix.

Tabletop scenario: confidential supplier rates in email drafts

In this fictional exercise, an employee notices at 09:20 that a draft addressed to supplier A contains a rate belonging to supplier B. The application generated 17 drafts between 09:00 and 09:20. Its dashboard shows five unopened drafts, eight in manual review and four marked sent. The initial report does not establish which drafts contain the unrelated rate or which messages actually left the organisation.

The incident lead pauses generation and the affected outbound queue, preserves relevant references and keeps the ordinary manual supplier-contact process available under its existing controls. The team does not delete the draft history or ask every employee to copy suspicious text into a shared spreadsheet. It identifies the authorised reviewers and the message-delivery evidence needed to establish exposure.

Illustrative reconciliation after authorised review

Initial dashboard group	Number	Subsequent finding
Unopened	5	No unrelated rate observed in the inspected drafts
Manual review	8	Two drafts contain the unrelated rate and remained internal
Marked sent	4	Three were delivered and one remained queued; one delivered message contains the unrelated rate

The groups reconcile to 17 drafts. Review identifies three affected drafts, of which one was delivered externally. Delivery evidence does not establish that the recipient opened the message, and this selected time window does not prove there were no earlier occurrences. These limits belong in the situation report alongside the confirmed facts.

The investigation next determines whether retrieval, conversation state, source selection or another component introduced the rate. It records competing explanations and the evidence needed to distinguish them. A configuration change made during containment should have its own timestamp so the team does not later test a repaired state and mistake it for the state that produced the incident.

Contain the consequence while preserving a useful service boundary

Containment should target the affected capability and credible exposure path. Options may include pausing a workflow, disabling a tool permission, isolating a source collection, stopping queued messages or moving a business activity to an approved manual process. The correct choice depends on the architecture and consequence; the plan should identify available controls before an incident makes experimentation urgent.

Check pending work as well as new requests. Stopping generation does not necessarily stop a message already queued for delivery. Revoking an application's permission may not cancel an accepted downstream transaction. The operating owner needs evidence of what was stopped, what remained in progress and what requires reconciliation.

Do not move the affected data to an unapproved model or supplier merely to restore speed. A fallback can change the processing boundary and create a second problem. Use an agreed alternative whose relevant access, data handling and authority have been assessed, or retain the manual route until a suitable recovery decision is made.

Record the business cost of containment without allowing it to erase the risk question. The incident lead may need to present a narrower continuation option, but the authorised role should see its conditions and uncertainty. The exception process can record an appropriate temporary decision; it cannot make an otherwise unauthorised activity permissible.

Preserve the evidence needed to reconstruct the event

Identify the relevant system and configuration versions, source references, retrieval results where available, request and output identifiers, tool calls, approvals, delivery or transaction receipts and timestamps. Record what each source can establish. A generated response is evidence of text produced; a separate delivery record is evidence of transmission. Neither alone proves the recipient's later actions.

Keep the handling record for collected material: who obtained it, from where, when and with which access. Preserve original records through the organisation's approved process and use controlled working copies where appropriate. Do not prescribe indefinite logging of all prompts simply because an incident is possible; collection and retention still need a defined purpose and applicable handling requirements.

Missing evidence is itself a finding. If the supplier cannot identify the model configuration used, state that limitation and its effect on the investigation. Avoid inventing a precise root cause from a plausible reproduction. A later reproduction can support a hypothesis while differing from the original event in source state or configuration.

Link the incident record to model and system documentation and the use inventory. This lets the investigation locate owners and approved boundaries without rediscovering them. It also helps identify other uses that share the affected component and may require targeted examination.

Separate incident assessment from notification decisions

Maintain a facts-and-obligations record for the relevant specialists. Include the affected information, people or counterparties, likely consequences, confirmed and possible exposures, applicable contractual commitments and the facts still being established. A confidential commercial rate is not automatically personal data; the assessment follows the actual content and context.

Saudi privacy and sector requirements can depend on the organisation, incident and processing activity. The PDPL and AI governance guide supports the relevant privacy work. The plan should assign responsibility for identifying applicable duties and clocks; it should not publish one universal notification deadline for every kind of AI incident.

Draft communications should distinguish confirmed facts from continuing investigation, identify the audience and preserve approval history. Do not claim that no information was disclosed merely because the source database remained secure. Generated text, logs, cached material or downstream actions may create a separate route of exposure.

Where specialist assessment concludes that no particular notification is required, retain the reasoning and its factual basis. That conclusion can change if new evidence emerges. Conversely, the organisation should not postpone a required decision simply because the final technical cause remains unknown; the responsible specialists determine what the applicable requirement demands.

Make recovery a new evidence-based decision

Recovery requires more than the supplier saying the issue is fixed. Identify the failure path, the change made and the checks that address the observed consequence. In the supplier-email example, test separation between supplier contexts, queued-message handling and the intended human review under the repaired configuration. Preserve the configuration and evidence used for that decision.

Set a bounded return to service where appropriate: specified users, sources or actions, enhanced observation and clear stop conditions. Reconcile pending work before resuming so an old affected draft is not delivered after the repair. Assign who verifies the conditions and who authorises resumption; those responsibilities should not disappear into a generic change ticket.

Record what remains uncertain, including any historical scope still under investigation. Resuming a repaired activity does not close every question about earlier consequences. The risk acceptance record can preserve an authorised decision about remaining risk, while the incident record retains its own open investigation and communication actions.

Keep communications accurate while the scope is still uncertain

The supplier-email scenario requires a communication record as well as a technical timeline. The incident coordinator should identify who needs which information to take an immediate action. The operations team may need to stop pending messages; the privacy or legal reviewer may need the contents and recipient context; executives may need the service boundary and unresolved exposure. These audiences do not need identical packets of sensitive detail.

Use a short factual structure: what is confirmed, what remains unknown, what has been contained, what decision is pending and when the next update is due. In this example, one external delivery containing the confidential rate is confirmed. Whether that recipient opened or forwarded it remains unknown. The earlier period remains under investigation. Preserve all three statements rather than compressing them into either “no exposure” or an unsupported claim of widespread disclosure.

Assign an owner to each material unknown. Determining whether a queued message actually left the system is different from determining whether a delivered message was read. A reliable delivery record can answer the first question without answering the second. If a question cannot be resolved with available evidence, record that limit and its effect on the decision.

Prepare any external communication through the organisation's authorised route. The message should be accurate for its audience, avoid unnecessary further disclosure and preserve the distinction between confirmed facts and investigation findings. An operational request to a recipient, a contractual notice and a legally required notification can have different purposes and approval requirements. Identify the applicable route before treating them as interchangeable.

Keep a communication log containing the version approved, authorising role, intended recipients, time sent and any subsequent correction. If new evidence changes an earlier account, record the change openly and link it to the underlying finding. Quietly replacing the first version can make the organisation unable to reconstruct what recipients were told and when.

The next exercise should challenge this discipline. Give the team a draft executive update that incorrectly counts all seventeen drafts as external disclosure, then ask participants to reconcile it with the delivery evidence. Introduce a later finding about the earlier period and observe whether the coordinator updates the scope without rewriting the original facts. The acceptance criterion is an accurate, traceable account and an authorised decision route, not merely a fast message.

Include communication handover in shift changes. The incoming coordinator needs the current facts, open questions, next promised update and restrictions on onward sharing. A technically contained event can still be mishandled if the organisation sends inconsistent explanations or loses ownership of a time-sensitive communication decision.

Exercise the plan and turn findings into governance changes

Run the tabletop with the actual roles and access arrangements. Introduce a missing delivery log, an unavailable owner and a supplier who can only provide a delayed response. Observe whether the team can contain the activity, preserve facts and reach the next decision. The exercise should produce a decision trail and corrective actions, not just an attendance list.

Review the event without forcing a single technical explanation to account for every weakness. The initiating defect, the reason it reached users, the delay in detection and the difficulty of recovery can have different causes. Each corrective action needs a clear owner and evidence of completion. Track overdue actions in executive reporting and revisit relevant approval or procurement requirements.

Discuss an AI incident plan that your operating teams can exercise with Open for AI. Bring one consequential workflow, its current response arrangements and the decisions that remain unclear. The useful deliverable is a tested path from uncertain observation to controlled action and recovery, supported by evidence your organisation can obtain.