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 most common misread is treating it like a checklist. It is not. The four functions — Govern, Map, Measure, Manage — are outcomes you have to show evidence for, not boxes to tick. The companion **AI 600-1 Generative AI Profile** published in July 2024 (https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook) is where the real operational meat lives for LLM teams: 12 risks specific to generative systems, including confabulation, harmful bias, data privacy, intellectual property, obscene/violent content, and value chain. Read the GenAI Profile before you read the base RMF.

**MITRE ATLAS** (Adversarial Threat Landscape for AI Systems) is the threat-actor knowledge base maintained by MITRE 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, Initial Access, ML Model Access, Execution, Persistence, Exfiltration, and Impact, with techniques like prompt injection (T0051), data poisoning (T0020), and model evasion (T0015). The case studies — including the Microsoft Tay incident and the Tesla model evasion experiments — are the most useful 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. If you only read one OWASP document this quarter, read this one.

**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 just a news feed — incidents are 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 the high-risk obligations come into force in 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 a serious incident causing harm, and 2 days for incidents involving widespread infringement or harm to critical infrastructure. The full timeline and definitions are 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 in December 2023 (https://www.iso.org/standard/81230.html). If you are familiar with 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 the standard you certify against if you want a third-party-audited claim that your AI governance is real, not a slide deck.

**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 Profile risk of confabulation, this is a category-one foreseeable failure. The mitigation pattern — retrieval-grounded responses, refusal-to-answer for policy questions, and a clear human-fallback path — is exactly the kind of control ISO 42001 Annex A.7.2 would have flagged as missing in an internal 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 (T0018), and under NIST AI RMF the failure is in the Measure function — insufficient evaluation across edge cases before promotion. The lesson is not that diverse outputs are bad; it is that the evaluation suite did not cover historical-figure prompts, and the rollback path worked, which is a process win even though the launch was a loss.

**Microsoft Tay, March 2016** — The grandparent incident. A Twitter chatbot was prompt-injected and data-poisoned by users in under 16 hours, generating racist and inflammatory tweets. Microsoft pulled it. Tay is the founding case study for MITRE ATLAS adversarial-input techniques and the canonical lesson for OWASP LLM03 (Supply Chain) and LLM04 (Data and Model Poisoning). It is also the cleanest example of a fast containment decision — Microsoft killed it the same day, which is the right call when an LLM is actively producing reputational damage.

**Meta Galactica, November 2022** — A scientific-paper LLM survived three days before Meta withdrew it after researchers documented confident-sounding fabricated citations and biased outputs. Under the NIST AI RMF Govern function, the unanswered question is who had authority to call the launch — and the unanswered question under ISO 42001 is whether a documented risk treatment plan existed before launch. Galactica's lesson is that 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, which is 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. Tabletop this one with your legal team.

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

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

Third, **user feedback signals** — the thumb-down, the abuse flag, the support ticket. These are your highest-precision low-recall signal, and the OWASP LLM Top 10 explicitly calls out feedback loops as a control under LLM09 (Misinformation). 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/Twitter, Reddit, Hacker News, LinkedIn, and the AI Incident Database submission form. Tools like Brand24, Mention, or a $30/month Google Alerts plus Slack-webhook setup are the floor. The Cursor incident broke on Hacker News before it broke in the internal Slack — assume your incidents will too. Wire the alert into your on-call channel, not into a marketing inbox no one reads on weekends.

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

Finally, **adversarial monitoring** — a small portion of your eval traffic should be MITRE ATLAS techniques (https://atlas.mitre.org/techniques) running 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 of these channels is missing, fix that before you tune your playbook. A perfect incident-response process applied late is more expensive than a mediocre process applied within 30 minutes. For the deeper attack-surface layer, see LLM jailbreak prevention, and to map your audit logging requirements see AI audit trail requirements 2026.

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

Triage in the first 10 minutes. Assign severity using a documented rubric — most teams adopt a 1-to-4 scale where Sev 1 is widespread harm or regulatory exposure, Sev 2 is significant user impact, Sev 3 is contained user impact, and Sev 4 is internal-only. 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 will usually be one notch higher because you want to over-respond, not under-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 or capability? If yes, do it. Can you **geo-fence** to limit exposure (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. You need three artifacts: an internal status update for employees, a public acknowledgment for users (a tweet, a status-page entry, or a banner in the product), 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 a non-technical audience — 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 becomes the source material for both the EU AI Act Article 73 notification (if it applies) and the internal post-mortem. The NIST AI RMF Manage function expects this evidence trail; ISO 42001 auditors will ask for it. The team that writes nothing down during the incident writes a fictional post-mortem two weeks later.

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

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

**Regulator notifications under EU AI Act Article 73** are the most time-bound. For a serious malfunction in a high-risk system, the window is 15 days from awareness; for an incident causing harm to a person's health, the window is 10 days; for widespread infringement or harm involving critical infrastructure, the window is 2 days. The notification goes to the relevant 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 the implementing regulation specifics with EU counsel — these obligations may have tightened by the time you read this.

**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 of the incident, 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 a follow-up. The fuller statement should include root-cause framing, named accountability, and a concrete remediation timeline. The NIST GenAI Profile risk treatment language is useful as a starting point but is too technical for press — translate it.

**Internal communication** matters more than most leaders think. Employees will be asked by friends, family, and recruiters about the incident; arming them with a clear, factual internal FAQ within 24 hours reduces both bad external commentary and internal anxiety. Tay's internal Microsoft post-mortem was reportedly fast and frank — that culture is part of why Microsoft's AI safety practice in 2026 is one of the strongest in the industry.

**AI Incident Database submission.** After the incident is contained and the legal review is done, consider submitting the case to https://incidentdatabase.ai/. This is voluntary, but for incidents that became public anyway, contributing a structured account is a public-interest act and a credibility signal. Several major vendors (Microsoft, IBM, Salesforce) submit their own incidents — the corpus is more valuable when it is not only journalists who report failures.

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

The NIST GenAI Profile risk taxonomy (AI 600-1) is the complementary lens. The 12 generative-specific risks include confabulation, dangerous or violent recommendations, data privacy, environmental impact, harmful bias and homogenization, human-AI configuration, information integrity, information security, intellectual property, obscene/violent content, value chain and component integration, and CBRN. Tagging the incident against one or more of these risks gives you both the post-mortem vocabulary and the mitigation library to consult.

Use a structured 5-whys or fishbone analysis but extend it for LLMs. The traditional 5-whys assumes deterministic causation; for an LLM you need to ask additional questions: was the failure reproducible (run the prompt 100 times — what's the failure rate), was the failure model-version-specific (run on the previous version), was the failure system-prompt-specific (run with the previous system prompt), was the failure context-dependent (which retrieved documents were in scope). The Cursor incident was reproducible; the Gemini image issue was prompt-dependent. Different root causes, different fixes.

Distinguish proximate cause from contributing factors. Proximate cause for the Air Canada incident was the chatbot's confabulation about bereavement fares. Contributing factors included the absence of retrieval grounding, the absence of a 'I don't know' refusal path for policy questions, the absence of an output safety filter for policy-related responses, and the deployment of the chatbot for a use case it 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-up actions is the format that gets read; the 30-page post-mortem document is the format that gets filed. The 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. Both are satisfied by the two-page format if you do it well.

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 — this is the discipline that separates teams whose incidents repeat from teams whose incidents teach. JailbreakBench (https://jailbreakbench.github.io/) is the public example of this discipline applied to jailbreak research.

The 'blameless post-mortem' tradition from Google SRE and Etsy is the right starting point for AI incidents, but it needs adaptation. Blameless does not mean accountability-free; it means the incident review focuses on systemic factors rather than individual blame, while leadership separately addresses any governance failures with the people responsible. The ISO 42001 Annex A.6.1 control on roles and responsibilities exists precisely 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 the detail. Invite the on-call team, the application owner, the security on-call, a legal observer, and an executive sponsor. The executive sponsor's job is to authorize follow-up actions on the spot, not to grade the response. The Air Canada and Galactica post-mortems were reportedly run without executive authority in the room, which slowed the follow-through.

Structure the post-mortem around five questions: what happened, what was the impact, what went well, what went poorly, what will we change. Time-box each section. The 'what went well' section is the most often-skipped and the most important — celebrating fast containment or good comms builds the muscle you want for next time. The 'what will we change' section should produce a small number of high-leverage commitments, not a wish list of 40 minor tweaks.

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

Publish the post-mortem internally and, when possible, a sanitized version externally. Stripe, GitLab, and Cloudflare have built credibility through public post-mortems for non-AI incidents — the same pattern is just starting to take root for AI. The Cursor post-incident note is closer to a public post-mortem than to a press statement, and it worked. The AI Incident Database (https://incidentdatabase.ai/) will accept structured submissions if you want the public-corpus contribution.

Run a tabletop exercise on the post-mortem learnings 30 days later. Take the incident scenario, change the variables (different model, different region, different user impact), and walk the team through the response. This is the closing loop of the playbook — the muscle memory you want when the next incident lands at 11pm on a Friday. Teams that tabletop quarterly handle real incidents in half the time of teams that only respond to real incidents.

An incident response that does not change your governance posture is wasted. The NIST AI RMF Govern function is where the post-incident learnings need to land: updated risk register entries, revised acceptable-use policies, new launch-gate criteria, expanded evaluation requirements, and refreshed third-party assessment templates. The framework is explicit at https://www.nist.gov/itl/ai-risk-management-framework that the four functions are iterative, not sequential — incidents are the feedback signal that drives the Govern loop.

Update your **AI risk register** with the new failure mode, the proximate cause, the contributing factors, the affected systems, and the residual risk after mitigation. ISO 42001 Annex A.6.4 expects this register to be a living document with named owners. Most enterprise programs keep this in their GRC platform (OneTrust, Vanta, Drata); some keep it in a Notion or Confluence page. The platform matters less than the discipline of updating it within 30 days of every incident.

Update your **launch-gate criteria** to add the evaluation that would have caught this incident. Every confirmed incident should yield at least one new gate. Over 12 months, this discipline produces an evaluation suite that is materially better than any off-the-shelf benchmark — because it reflects your actual failure surface, not an industry-average failure surface. This is the moat that distinguishes serious AI safety programs from compliance theater.

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

Update your **incident-reporting workflow** to reflect what you learned. If the bridge call was slow because the on-call rotation was unclear, fix the rotation. If the regulator clock was missed because legal was looped in too late, change the page list. If the containment decision was delayed because no one had authority to disable the feature, document the authority. The NIST AI RMF Playbook (https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook) has worked examples for each of these workflow refinements.

Finally, share what you can externally. Vendor trust programs — the Microsoft Responsible AI Transparency Report, the Anthropic Responsible Scaling Policy updates, the Google AI Principles annual report — set the bar in 2026. You do not need to publish at that scale, but a quarterly internal-then-blog summary of what you fixed, what you learned, and how your governance changed is a credibility signal that compounds. The companies that are public about their failures are the companies that get trusted with the bigger contracts in 2027.