AI Incident Response Runbook: The Steps a SOC Actually Runs When an LLM Interaction Goes Wrong

AI incidents share their reporting timelines with the reporting rules the security team already lives under. The SEC 8-K rule requires disclosure of material cybersecurity incidents within four business days. The EU AI Act Article 26.4 requires deployers of high-risk AI systems to report serious incidents to the market surveillance authority immediately, in any case not later than 15 days after becoming aware. HIPAA sets 60 days for breach notification. The technical response has to run in parallel with the reporting clock. When the SOC does not have a working runbook, the technical response and the reporting clock both slip.

I want to walk through the six-phase incident lifecycle a working AI incident runbook covers, the specific queries the SOC runs against the audit log at each phase, the roles that own each step, and the artifact pack the CISO hands to regulators when the reporting timers expire.

Phase 1: Detect

The detection phase surfaces the incident from the noise of the operational log stream. Detection sources fall into four categories.

Automated detectors on the AI gateway audit log. The gateway records the classifier outcome on each request. A spike in high-severity classifier verdicts (PII leak, prompt injection attempt, prohibited data class) triggers the detector.

Automated detectors on the AI provider's abuse signals. OpenAI, Anthropic, and Google surface abuse signals through their enterprise APIs. Volume anomalies on the account, model refusal rate spikes, and account suspension events all indicate a potential incident.

User reports. Employees, customers, or partners report AI-generated output that concerns them. The user-report queue has to reach the SOC within the same channels as other security reports.

External signals. Regulator inquiries, media coverage, or partner outreach can be the first indication of an incident at the operator's environment.

The detection phase closes when the SOC opens an incident record and assigns it a severity. The severity determines whether the reporting clock starts under any regulatory regime.

Phase 2: Triage

The triage phase determines whether the alert is a true incident and, if so, the initial scope. The SOC on-call runs the triage against the audit log within 60 minutes of detection.

The triage queries against the AI gateway audit log:

The triage output classifies the incident: confirmed data exposure, confirmed policy violation, confirmed compromise, false positive, or awaiting investigation.

Confirmed data exposure triggers the containment phase and starts the applicable reporting clock. Confirmed policy violation runs through the remediation phase without a reporting obligation unless the violation caused a downstream impact. Confirmed compromise runs the full incident response process with elevated coordination. False positive closes the incident with a note in the detector tuning queue.

Phase 3: Contain

The containment phase stops the incident's ongoing impact. For AI incidents, containment operates at the identity, the route, or the model.

Identity containment revokes the affected user's or agent's access to the AI gateway. The revocation propagates within 60 seconds through the gateway's identity provider integration. The user retains other access to their normal systems; only the AI request path closes.

Route containment blocks the affected route (a specific AI provider endpoint, a specific model, or a specific application-to-provider path) at the gateway. Requests to the blocked route return a deny response with a defined error code.

Model containment blocks all requests to the affected model version. Model containment is the widest response and typically requires CISO or SVP approval because it affects business operations broadly. Model containment is common when an incident is caused by a model provider's own issue (a jailbreak that affects all deployments of a given model version, for example).

The containment phase closes with the containment action taken and the timestamp recorded on the incident record.

Phase 4: Investigate

The investigation phase reconstructs the incident's timeline, scope, and root cause. The investigation runs against the full audit log series without the time windows of the triage phase.

The investigation queries include:

The investigation output includes the incident timeline with timestamps, the data classes exposed and their counts, the affected identities (users, customers, agents), the downstream propagation path, and the root cause classification.

The root cause classification names one of six categories: model behavior (jailbreak, prompt injection, unintended output), policy configuration (misconfigured rule, missing rule, exception), identity compromise (stolen credential, compromised token, session hijack), application logic (unsafe prompt construction), data classifier failure (classifier missed the pattern), or provider-side incident (the AI provider suffered a security event that affected the operator).

The investigation phase closes when the CISO accepts the root cause classification and the scope.

Phase 5: Report

The report phase produces the regulatory disclosures and internal communications the incident requires. The applicable disclosures depend on the incident's characteristics and the operator's regulatory footprint.

For a publicly traded operator whose incident is material, the SEC Form 8-K disclosure runs within four business days of the materiality determination.

For a deployer of a high-risk AI system under the EU AI Act, Article 26.4 requires the deployer to report serious incidents to the market surveillance authority immediately, in any case not later than 15 days after becoming aware. Article 3 defines "serious incident" to include incidents that lead to death or serious harm to a person's health, disruption of critical infrastructure, infringement of fundamental rights, or serious damage to property or the environment.

For a HIPAA covered entity, the Breach Notification Rule requires notification to affected individuals within 60 days of discovery when the breach involves more than 500 individuals. The HHS notification runs concurrently for large breaches.

For a state law breach obligation (California CCPA, Colorado SB 26-189, New York SHIELD, and others), the applicable state's notification obligation runs on its own timeline.

The reporting artifacts include the incident summary, the timeline, the affected identities count, the data classes involved, the containment actions taken, and the remediation plan. The artifacts have to be authoritative because the regulator will hold the operator to what the reporting document said.

Phase 6: Remediate

The remediation phase closes the gap the incident exposed. Remediation actions include: policy configuration changes, classifier tuning, identity or access control changes, application code changes, model or provider changes, user communication and retraining.

Each remediation action gets tracked as a work item with an owner and a due date. The CISO reviews the remediation status at the next incident review cycle.

The runbook closes each incident when the CISO accepts the remediation as complete and the incident record moves to the closed state. Closed incidents feed the annual security review and the metrics the CISO reports to the board.

The artifact pack for regulators

The artifact pack the CISO hands to the regulator on request includes: the audit log excerpt covering the incident window (specific fields the regulator's authority requires), the incident record from the SOC system with timestamps for each phase, the containment actions taken with timestamps, the investigation report with the root cause classification, the remediation plan with owner and due date, and the executive summary of the incident.

The audit log excerpt has to survive the regulator's own verification. The regulator will ask about the log's integrity: how does the operator know the excerpt was not modified after creation? The tamper-evident properties of the storage layer answer this question.

DeepInspect

The DeepInspect gateway produces the per-decision audit records that support every phase of the incident runbook. Phase 2 triage runs the 10 queries the SOC uses against the gateway's indexed record store. Phase 3 containment blocks identity, route, or model at the gateway with a policy update that takes effect in under 60 seconds. Phase 4 investigation reconstructs the conversation history and the classifier verdicts across the incident window. Phase 5 reporting produces the audit log excerpt as an authoritative artifact for regulators.

The gateway's integration with the SOC's SIEM (Splunk, Datadog, Chronicle, Sentinel) forwards the classifier verdicts and the policy events as detection sources. The SIEM's detection rules run on the gateway signals alongside the SIEM's existing rule catalog.

If your team is preparing an AI incident response runbook or a regulatory readiness exercise, book a technical deep dive at deepinspect.ai.