AI Incident Response Playbook 2026: NIST AI RMF, MITRE ATLAS, OWASP LLM Top 10, EU AI Act Article 73, and ISO 42001 Mapped to Real LLM Disasters

**NIST AI RMF 1.0** is a voluntary framework, not a regulation, and the common misread is treating it like a checklist. The four functions — Govern, Map, Measure, Manage — are outcomes you must show evidence for. The companion **AI 600-1 Generative AI Profile** published July 2024 (https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook) is where the operational meat lives: 12 risks specific to generative systems, including confabulation, harmful bias, data privacy, intellectual property, and value-chain risk. Read the GenAI Profile before the base RMF.

**MITRE ATLAS** (Adversarial Threat Landscape for AI Systems) is the threat knowledge base at https://atlas.mitre.org/. It uses the same tactic-and-technique structure as ATT&CK, so your existing SOC can map it onto familiar workflows. Tactics include Reconnaissance, ML Model Access, Execution, Exfiltration, and Impact, with techniques like prompt injection, data poisoning, and model evasion. The case studies — including Tay and the Tesla model-evasion experiments — are the best starting point for red-team scoping.

**OWASP Top 10 for LLM Applications** is what your AppSec team will actually adopt because it speaks their language. The 2025 update at https://owasp.org/www-project-top-10-for-large-language-model-applications/ promoted system prompt leakage, vector and embedding weaknesses, and unbounded consumption to top-tier risks. LLM01 (Prompt Injection) and LLM02 (Sensitive Information Disclosure) remain the categories you will see in real incident write-ups.

**The AI Incident Database** at https://incidentdatabase.ai/ is run by the Partnership on AI with editorial review by the Responsible AI Collaborative. It is a structured corpus, not a news feed — incidents tagged by harm type, affected parties, technology stack, and contributing factors. Use it for tabletop exercises: pick an incident from your sector, walk your team through how your stack would have responded, and use the gaps to update your runbook.

**EU AI Act Article 73** is the only item on this list that is law. Once high-risk obligations come into force August 2026 (with GPAI obligations live from August 2025), providers and deployers must report serious incidents to national market surveillance authorities. The clock is 15 days from awareness for a serious malfunction, 10 days for harm to a person, and 2 days for widespread infringement or harm to critical infrastructure. The full timeline is at https://artificialintelligenceact.eu/article/73/. Verify with counsel — implementing regulations may tighten these windows.

**ISO/IEC 42001:2023** is the management-system standard published December 2023 (https://www.iso.org/standard/81230.html). If you know ISO 27001, the structure rhymes: context, leadership, planning, support, operation, performance evaluation, improvement. Annex A lists 38 controls covering AI policy, risk treatment, lifecycle, third-party, and continual improvement. It is what you certify against to make a third-party-audited claim that your AI governance is real.

**Air Canada chatbot, February 2024** — A bereavement-fare hallucination cost the airline a tribunal loss and a viral PR cycle (https://www.bbc.com/travel/article/20240222-air-canada-chatbot-misinformation-what-travellers-should-know). Under OWASP LLM09 (Misinformation) and the NIST GenAI confabulation risk, this was category-one foreseeable. The mitigation pattern — retrieval-grounded responses, refusal-to-answer for policy questions, clear human fallback — is exactly the kind of control ISO 42001 Annex A.7.2 would have flagged as missing in an audit.

**Google Gemini image generation, February 2024** — Image generation produced historically inaccurate outputs after over-correction for representational diversity. Google paused the feature within days. Under MITRE ATLAS this maps to model-behavior shifts during fine-tuning; under NIST AI RMF the failure is in Measure — insufficient evaluation across edge cases before promotion. The lesson is not that diverse outputs are bad; it is that the eval suite did not cover historical-figure prompts, and the rollback path worked.

**Microsoft Tay, March 2016 and Meta Galactica, November 2022** — Tay, the grandparent incident, was prompt-injected and data-poisoned by Twitter users in under 16 hours. Microsoft pulled it the same day — the founding case study for MITRE ATLAS adversarial inputs and the cleanest example of fast containment. Galactica, Meta's scientific-paper LLM, survived three days before withdrawal after researchers documented fabricated citations. Under NIST Govern, the open question was who had authority to call the launch; under ISO 42001, whether a documented risk treatment plan existed. A fast pull is not the same as a controlled rollback if the launch itself was ungoverned.

**NYC MyCity chatbot, March 2024** — The city's small-business chatbot was reported by The Markup as giving advice that would have caused users to violate housing and labor law. The city kept the chatbot online with a disclaimer rather than pulling it — a defensible and contested risk decision under the NIST Manage function. Under EU AI Act terms, a comparable system serving EU residents would have been a high-risk public-services use case requiring conformity assessment and incident reporting.

**Cursor.com support bot, April 2025** — A support bot fabricated a 'one device per subscription' policy, users hit Hacker News, and the founder issued a public apology with refund and process update. The post-mortem cited insufficient grounding and missing human-review escalation. Under OWASP LLM05 (Improper Output Handling) and the NIST GenAI confabulation risk, textbook. The recovery — fast acknowledgment, named owner, concrete fix, refund — is why brand damage was contained.

Detection is the part of the playbook most teams underinvest in, then regret. The bare-minimum detection layer has four channels. First, **output safety filters** on every generation — Llama Guard, OpenAI's moderation endpoint (https://platform.openai.com/docs/guides/moderation), or a hosted equivalent like Lakera catches obvious policy violations before they ship. Second, **structured logging** of every prompt, system message, retrieved document, model output, and user feedback signal, with retention long enough to support 30-day root-cause analysis.

Third, **user feedback signals** — thumbs-down, abuse flag, support ticket. These are your highest-precision low-recall signal, and OWASP LLM09 calls out feedback loops as a control. The mistake most teams make is collecting feedback and not routing it to a real human queue within 24 hours. By the time you read the negative feedback batch on Monday, the Twitter screenshot is already in tech journalism.

Fourth, **external monitoring** — branded keyword search across X, Reddit, Hacker News, LinkedIn, and the AI Incident Database. Mention, Brand24, or a $30/month Google Alerts plus Slack-webhook setup is the floor. The Cursor incident broke on Hacker News before it broke in internal Slack — assume yours will too. Wire alerts into your on-call channel, not a marketing inbox no one reads on weekends.

Above the basics, instrument **evaluation drift detection**. Run a golden set of prompts against production every hour and alert on regression. NIST AI RMF Measure requires this kind of continuous evaluation for GenAI systems (https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook). The drift detector caught the Gemini issue inside Google before it caught it externally — the question was whether the launch gate respected the drift signal, which is a Govern question.

Finally, **adversarial monitoring** — a small portion of eval traffic should be MITRE ATLAS techniques (https://atlas.mitre.org/techniques) on a schedule: prompt-injection probes, data-exfiltration probes, jailbreak suite runs. JailbreakBench (https://jailbreakbench.github.io/) provides a maintained corpus. The point is not to score perfectly; the point is to detect when your score drops because a model update or system-prompt change opened a new attack surface. If any channel is missing, fix it before you tune your playbook. For deeper coverage see LLM jailbreak prevention and AI audit trail requirements 2026.

The first hour determines whether you are managing a controllable problem or a public-relations event. Open an incident channel and a video bridge. Page the named incident commander, LLM application owner, security on-call, legal and comms on-call, and the executive sponsor. ISO 42001 Annex A.6.2 expects this rotation to be documented and rehearsed; if you have not run a tabletop in six months, your bridge will be slower than it should be.

Triage in the first 10 minutes. Assign severity using a documented rubric — most teams use 1-to-4 where Sev 1 is widespread harm or regulatory exposure, Sev 2 is significant user impact, Sev 3 is contained, Sev 4 is internal. The EU AI Act Article 73 definitions at https://artificialintelligenceact.eu/article/73/ are useful inputs but they are legal thresholds, not operational ones — your operational severity is usually one notch higher because you want to over-respond.

Containment in the next 20 minutes. The decision tree is short: can you **rollback** the model or prompt version that introduced the issue? If yes, do it now and confirm reversion. Can you **disable** the specific feature? If yes, do it. Can you **geo-fence** (turn off in EU, turn off for unauthenticated users)? If yes, do it. The Air Canada lesson is that the chatbot kept answering during the dispute — every additional answer was incremental liability. Microsoft killed Tay the same day for the same reason.

Comms in the next 20 minutes. Three artifacts: an internal status update, a public acknowledgment for users (tweet, status-page entry, or banner), and a holding statement for press. The Cursor incident showed that named acknowledgment with a real human and a concrete next step beats a corporate-comms statement. Do not lie. Do not blame the model. Do not call it 'hallucination' to non-technical audiences — call it 'incorrect information' and explain what you are doing about it.

Document everything in the last 10 minutes. Timestamped log of decisions, who made them, what was disabled, what was preserved for forensics, what was communicated to whom. This is source material for the EU AI Act Article 73 notification (if it applies) and the internal post-mortem. NIST Manage expects this trail; ISO 42001 auditors will ask for it.

If you do nothing else from this playbook, run a one-hour tabletop this quarter against the Cursor scenario. A team that has rehearsed once is materially better than one that has read the runbook three times. Reps help more than frameworks.

External communication is where most incidents are won or lost in 2026. Order matters: internal team first (so they hear it from you, not Slack rumors), then affected users, then regulators (per legal timelines), then press (after a holding statement is ready). Galactica demonstrated this in reverse — researchers reported failures publicly while Meta was deciding what to say, and outsiders set the narrative.

**Regulator notifications under EU AI Act Article 73** are the most time-bound. For serious malfunction in a high-risk system: 15 days; for harm to a person's health: 10 days; for widespread infringement or critical-infrastructure harm: 2 days. Notification goes to the national market surveillance authority in the EU member state where the incident occurred. The European AI Office (https://digital-strategy.ec.europa.eu/en/policies/ai-office) coordinates cross-border cases. Verify with EU counsel.

**User communication** should be specific, named, and actionable. The Cursor post-incident note worked because it said: this is what we did wrong, this is what we changed, here is a refund, here is the human you can email. The Air Canada response failed in part because the airline argued the chatbot was a separate entity rather than apologizing — which made the news cycle worse than the original fare dispute. Users tolerate mistakes; they do not tolerate deflection.

**Press communication** requires a single spokesperson, a holding statement within 60 minutes, and a fuller statement within 24 hours. The holding statement should acknowledge the incident in factual terms, name a containment action already taken, and commit to follow-up. The fuller statement should include root-cause framing, named accountability, and a concrete remediation timeline. NIST GenAI Profile risk-treatment language is useful as a starting point but too technical for press — translate it.

**Internal communication and AI Incident Database submission.** Employees will be asked by friends, family, and recruiters; arming them with a clear internal FAQ within 24 hours reduces both bad external commentary and internal anxiety. Tay's internal Microsoft post-mortem was reportedly fast and frank — part of why Microsoft's AI safety practice in 2026 is one of the strongest in the industry. After containment and legal review, consider submitting the case to https://incidentdatabase.ai/. For incidents that became public anyway, a structured account is a public-interest act and a credibility signal. Microsoft, IBM, and Salesforce submit their own — the corpus is more valuable when it is not only journalists reporting failures.

Root-cause analysis for LLM incidents is harder than traditional software because the failure mode is often statistical, not deterministic. MITRE ATLAS (https://atlas.mitre.org/) gives you the threat-actor lens: adversarial input (prompt injection, jailbreak), upstream issue (poisoned training data, compromised supply chain), or deployment-time issue (system prompt regression, model swap, retrieval bug)? Starting with ATLAS tactic categories prevents the 'must be a bad prompt' tunnel vision that wastes the first 48 hours.

The NIST GenAI Profile risk taxonomy (AI 600-1) is the complementary lens. The 12 generative-specific risks include confabulation, dangerous recommendations, data privacy, harmful bias, human-AI configuration, information integrity, intellectual property, and value-chain integration. Tagging the incident gives you both the post-mortem vocabulary and the mitigation library to consult.

Use a structured 5-whys or fishbone analysis, extended for LLMs. The traditional 5-whys assumes deterministic causation; for an LLM you need additional questions: was the failure reproducible (run the prompt 100 times), model-version-specific, system-prompt-specific, or context-dependent (which retrieved documents were in scope). Cursor was reproducible; Gemini was prompt-dependent. Different root causes, different fixes.

Distinguish proximate cause from contributing factors. Proximate cause for Air Canada was the chatbot's confabulation about bereavement fares. Contributing factors: no retrieval grounding, no 'I don't know' refusal path for policy questions, no output safety filter, deployment for a use case the bot was not evaluated against. Fixing only the proximate cause leaves you exposed to the next incident with a different proximate cause.

Document the analysis in a format your team will actually read. The two-page incident report with timeline, contributing factors, immediate actions, and follow-ups is the format that gets read; the 30-page post-mortem is the format that gets filed. NIST AI RMF Playbook (https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook) suggests outcome-based reporting; ISO 42001 Annex A.8.4 wants evidence of corrective action.

Loop the analysis back into your evaluation suite. Every confirmed root cause should generate at least one new evaluation prompt that would have caught this incident pre-deployment. Over time the eval suite becomes a regression test for past incidents — the discipline that separates teams whose incidents repeat from teams whose incidents teach. JailbreakBench (https://jailbreakbench.github.io/) is the public example.

The 'blameless post-mortem' tradition from Google SRE and Etsy is the right starting point, but it needs adaptation. Blameless does not mean accountability-free; the incident review focuses on systemic factors rather than individual blame, while leadership separately addresses governance failures with the people responsible. ISO 42001 Annex A.6.1 on roles exists so accountability is clear before the incident, not assigned after it.

Run the post-mortem within 5 to 10 business days of containment. Sooner is too raw; later loses detail. Invite the on-call team, the application owner, security on-call, a legal observer, and an executive sponsor. The sponsor's job is to authorize follow-up actions on the spot, not grade the response. Structure around five questions: what happened, what was the impact, what went well, what went poorly, what will we change. Time-box each.

Follow-up actions need owners and dates, tracked in your normal project tooling. The most common failure mode is producing a thoughtful action list no one is on the hook to ship. ISO 42001 Annex A.8.4 (corrective action) and the NIST Manage function both expect this loop to close in evidence; auditors will ask to see the action items, owners, and completion dates 6 months later.

An incident response that does not change your governance posture is wasted. Update your **AI risk register** with the new failure mode, contributing factors, and residual risk. Update your **launch-gate criteria** to add the evaluation that would have caught this incident. Over 12 months this discipline produces an eval suite materially better than any off-the-shelf benchmark — because it reflects your actual failure surface.

Update your **third-party assessment template**. If the incident involved a vendor model, retrieval system, or guardrail product, the new vendor questionnaire should include the question that would have surfaced this exposure during procurement. OWASP LLM03 (Supply Chain) covers this surface — most enterprises have a 200-question security questionnaire and a 20-question AI questionnaire, and the AI one is where the real exposure is hiding.

Finally, share what you can externally. Vendor trust programs — Microsoft's Responsible AI Transparency Report, Anthropic's Responsible Scaling Policy, Google's AI Principles report — set the bar in 2026. A quarterly summary of what you fixed and how governance changed is a credibility signal that compounds. Companies public about failures are trusted with bigger contracts in 2027.