NIST IR 8621: The AI Incident-Response Roadmap

On Nov. 2, 2026, NIST’s Computer Security Resource Center posted a news item announcing NIST IR 8621, a 39-page report titled NIST Workshop on SI Incident Management. Think of it as an itinerary rather than a schedule. The report distills a May 14, 2026 workshop that NIST’s announcement says “brought together more than 400 participants” from government, industry, academia, standards bodies and civil society. It then lays out what NIST plans to do next for AI incident response. None of those next steps carries a delivery date.

That missing calendar is the easy way to dismiss the document. It would be a mistake. The direction is visible, the requirements are not final, and the report’s own argument is that incident response plans drafted for conventional software are the thing most likely to break first.

What the report is, and what SI means in it

NIST IR 8621 is a workshop summary and stakeholder synthesis. It is not a standard, not a regulation, and not requirements for any organization. Read it as NIST asking practitioners where current practice breaks and what guidance they need.

The SI in the title stands for super intelligence. It is administration vocabulary. The report’s introduction footnotes Executive Order 14434, “Inaugurating the Era of Super Intelligence,” from Sept. 29, 2026, and notes NIST is updating its communications to use the term as directed. I will not re-litigate the naming here. What matters is the substance: the workshop treated AI incidents in two broad lanes, and the report builds its whole roadmap from that split.

The premise every incident responder should absorb

The report starts from two overlapping categories: what happens when attackers target SI systems, and what happens when the systems themselves misbehave. NIST’s announcement states the pair directly: incidents include “cybersecurity attacks that target SI systems as well as harms that arise from misuse, malfunction, or unintended actions.”

The second lane is the uncomfortable one. A system that passed every security control can still cause harm when a user misuses it, when it malfunctions, or when an agent acts in ways nobody intended. That premise is why incident response for AI cannot be a retrofit of the existing playbook.

Page 9 of the report states it plainly: “Consequently, traditional incident response life cycles built for conventional software systems may fracture or be incomplete when applied to SI, making the updating of incident response in the presence of SI a priority.”

The mechanics behind that sentence matter for planning. Conventional IR assumes deterministic systems, human-speed decisions and a blast radius you can usually enumerate. Probabilistic systems running at machine speed, sometimes acting autonomously across long tasks, do not hold still while you investigate. The report also flags that AI-enabled attacks and agent failures “may unfold faster than traditional human-centered response processes.” Your on-call escalation chain was designed around that constraint.

SP 800-61 is the centerpiece, and the split is the tell

SP 800-61 Revision 3 is the document most IR programs are built on, the current evolution of NIST’s incident response guidance. NIST’s incident-response project page records that it was finalized in April 2025, before the current wave of agentic deployments rewrote assumptions. The workshop sessions treated that vintage as a starting point rather than a solution: Rev 3 is structured as a CSF 2.0 Community Profile focused on cybersecurity incidents, which the report describes as creating “a scoping challenge” because AI incidents may also involve harm-based misuse or malfunction scenarios.

The report’s answer is a two-part update. In the Next Steps section, NIST states it plans to update SP 800-61 “including a potential Part A focused on cybersecurity incidents involving SI systems and a possible Part B focused on the misuse, malfunction, or other unintended actions of SI systems that may lead to harm.”

The word choice is doing real work. Part A covers incidents your security tooling can plausibly detect and classify. Part B covers the rest: harms that come from authorized systems doing unauthorized things. A possible Part B is an acknowledgment that harm response is a discipline, not a policy paragraph.

The companion guidance described in the same section would serve “all stakeholders at risk of an SI-involved cyber incident, including deployers and adopters of SI systems that range in capability and function.” That is general audience language, addressed to companies like yours, not just to frontier labs.

The split also implies two different owners. Part A territory stays with the security operations function that already owns incident response. Part B territory pulls in product owners, legal and whoever holds model risk, because misuse and malfunction questions sit closer to safety and liability than to perimeter work. Few mid-market firms draw that second track on paper, and the possible Part B is a nudge to start.

Six work streams, zero dates

The report closes with six connected activities. NIST frames them as planning: “The scope and specific guidelines are expected to evolve with future feedback and the emerging needs of stakeholders.” Nothing carries a date, nothing is adopted or in effect. Treat every item below as direction of travel.

1. An SI Incident Management Community of Interest: workshops, tabletop exercises and community discussions, feeding targeted guidelines for priority gaps. Nested under it, Task Group 8, “Agent Capabilities, Monitoring, and Containment,” will meet on an ad hoc basis through the NIST AI Consortium, where organizations developing and evaluating the highest-capability SI agents on long-horizon tasks discuss challenges and strategies.

2. The SP 800-61 update discussed above, with the possible Part A and Part B split.

3. Monitoring and log-management work that could inform updates to or resources for SP 800-92, including “model life cycle events, SI telemetry, provenance, and forensic evidence.”

4. Incident information sharing: examining SI-specific requirements and how guidance such as SP 800-150 could accommodate SI-related information.

5. A conceptual SI traceability and observability effort, possibly a dedicated NIST publication.

6. An ongoing workstream that keeps identifying and addressing emerging gaps as incidents, exercises and SI technology produce new lessons.

Three of these deserve attention from mid-market teams. The Community of Interest is the open engagement vehicle, and its output will shape whatever comes next. The SP 800-92 lane is where you can pre-position cheaply, because logging upgrades pay off under any future standard. The traceability and observability effort is the one to watch if you are building toward ISO 42001 evidence expectations, since auditors are already asking reconstruction-grade questions about system behavior. Traceability also happens to depend on identity and authorization hygiene; our recent coverage of NIST’s agent identity tenets walks through that prerequisite.

The October companion document is not general deployer guidance

One more NIST product belongs in this picture, with a scope warning. In October, NIST CAISSI, NSA’s Super Intelligence Security Center and CISA jointly published PP-26-4396, “Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation”. It is marked TLP:CLEAR and spells out “ten voluntary key practices” across the incident management lifecycle.

Its own scope statement is narrow: the practices are “primarily intended for organizations training or evaluating highly capable SI agents on long-horizon tasks with limited human supervision.” It also notes they may apply to deployers of such SI agents. If your company trains frontier-scale models, this document is addressed to you. If you deploy AI the way most mid-market fintech and SaaS companies do, treat it as a window into how the labs and the government think about incident readiness, not as a playbook with your name on it. Porting its practices into a deployer policy would misquote the document’s intent and misstate your own operating reality.

Why to act before NIST publishes anything

IR plans assume humans make the calls at human tempo, and the report’s workshop findings push directly against that. Attackers automate, agents fail, and events “may unfold faster than traditional human-centered response processes.” Containment authority, escalation thresholds and evidence collection need explicit design for machine tempo.

The evidence angle is quieter but just as consequential. The SP 800-92 lane and the observability effort point in the direction auditors already travel: record what the system did, when, under whose authority, and make that record reconstructable. That is the same evidence shape ISO 42001 certification bodies probe and SOC 2 maintainers are building toward.

The regulatory argument needs no extrapolation. The SEC’s FY 2027 exam priorities already pull AI-driven social engineering and firms’ own SI use into examination scope. You can be asked to show an incident response plan that contemplates AI harms before NIST finalizes anything on the subject.

What to do this quarter

Start with the inventory, because you cannot respond to incidents in systems you never inventoried. List where AI and agents act autonomously, what data they touch, and what business decisions depend on them. Our shadow-AI roadmap piece is a reasonable starting structure.

Then upgrade logging expectations, keyed to the SP 800-92 direction rather than to a hypothetical Part B. The practical questions are concrete: can you reconstruct what an agent did after the fact, which human or identity authorized it, and what the model’s lifecycle events were around the incident window? That means deciding in advance which events to retain: what prompt led to the action, which tools or systems the agent invoked, which approvals were granted, and what changed in deployment around the window. Retention choices made during a fire are worse than the ones made in a quiet week.

Run a tabletop with one scenario where an agent does exactly what it was authorized to do, badly. The interesting failures in this lane are not policy violations; they are correct execution with unexpected outcomes. Give the exercise a script with timestamps, a product owner defending the agent, a legal voice asking about disclosure, and a scribe reconstructing the sequence from whatever logs exist. Test detection, escalation and who holds containment authority. The gap these exercises usually expose is evidence, not response.

Last, watch the Community of Interest and Task Group 8. Their work products will define eventual guidance, and the Community of Interest is the open channel for tracking it. Reading the output as it lands is cheaper than re-reading your assumptions later.

The honest close

The report’s conclusion puts the timeline question to rest: “The workshop established that SI incident management is not an abstract future problem.” It also balances the ambition well: “Existing cybersecurity incident-response foundations remain indispensable, but SI introduces new challenges in observability, control, evidence, governance, the value chain, the speed of incident occurrence, identification, the assessment of harm, and response.”

There are no dates in this document, and that absence is not an excuse to wait. The work most mid-market teams need, an accurate inventory, lifecycle logging and reconstructable evidence, earns its keep under any future NIST output, during the next ISO 42001 audit, or inside the next SOC 2 cycle. A roadmap without dates still tells you where the roads will go. Build now in the direction the signs already point.

NIST’s AI Incident-Response Roadmap: What IR 8621 Means for Incident Teams