NIST AI 600-1 incident disclosure: what it requires

What NIST AI 600-1 asks for in NIST AI 600-1 incident disclosure

NIST AI 600-1 has no certification, and it does not set a federal channel for reporting AI incidents. The Generative AI Profile expects your organization to define what counts as an AI incident, log and analyze it, and report it under your own processes and the legal duties that already apply to you. When a customer questionnaire or contract clause asks how generative AI incidents are disclosed, the honest answer is a description of your process, your records and your obligations, not a reference to a NIST filing. The profile itself says formal channels to report and document AI incidents do not currently exist, and public incident databases decide ad hoc what to track.

The right answer depends on your sector, on whether you build or buy the generative AI systems involved, and on the breach reporting laws already in force, such as HIPAA breach reporting or GDPR breach notification. The profile's MANAGE 4.3 actions point to these external rules, and GV-6.2-003 asks that third-party incident response plans be reviewed against breach reporting, data protection and privacy laws. Confirm with your legal and compliance team which regimes apply to each system before you write any disclosure language, because the same generative AI event can trigger different clocks and recipients in different jurisdictions.

Your organization owns the incident process, including who decides what is reported and to whom. A implementation partner can prepare the systems this depends on: incident logs, change records, version history, metadata and response plans that name who owns each step. Only your legal and compliance functions decide what is disclosed to regulators, customers or affected people, and only an independent assessor or auditor can issue an opinion or attestation about the controls. Ask any partner to state in writing which of these outputs it prepares and which it does not sign or certify.

Which events count as an AI incident under the Generative AI Profile

NIST AI 600-1 defines an AI incident as an event where the development, use or malfunction of an AI system contributes to harm. The five categories below are the harm types that turn an ordinary defect or misuse into an incident, so each one should be mapped against the systems your organization runs or buys.

Harm to health

Covers events where a generative AI system contributes to physical or mental harm to a person, such as clinical summaries that omit a drug interaction or a patient-facing assistant that gives unsafe guidance. Check whether any system output reaches a clinical, safety or wellbeing decision without human review. Illustrative example: a chatbot that invents a dosage and a user follows it. Map each deployed system to this category to decide whether its failures need escalation.

Disruption of critical infrastructure

Covers events where AI development, use or malfunction disrupts services that society depends on, such as energy, water, transport or financial market plumbing. Generative AI tools that feed operational runbooks or control-room summaries can carry this risk even when the model itself sits outside the operational technology network. Identify every system that touches an operational or critical service and record its dependencies. Illustrative example: an assistant that drafts maintenance instructions with an error that is acted on before anyone notices.

Violations of rights and legal obligations

Covers events that violate human rights or legal obligations protecting fundamental, labor and intellectual property rights. For generative AI this often appears as discriminatory screening output, unauthorized reproduction of protected material or an assistant that exposes personal data. Map the legal obligations attached to each use case before the system goes live, not after an event. Illustrative example: a resume-summary tool that consistently downgrades candidates based on a protected characteristic.

Harm to property

Covers events where AI development, use or malfunction damages physical or digital property, including company data, customer assets and third-party systems. Prompt injection through a connected tool, or an agent that writes to a production database, can fall here. Confirm which tools, plugins and write permissions each generative AI system holds. Illustrative example: an agent that deletes records in a shared folder after reading an instruction embedded in a document.

Harm to communities or the environment

Covers events that harm communities or the environment, such as generated content that misleads a local population, or compute-heavy deployments with unmanaged resource use. This category asks organizations to consider effects beyond their own users. Identify which communities a system's outputs can reach, including people who never interact with the system directly. Illustrative example: a content generator that produces mass misinformation about a local emergency.

Why NIST says no formal AI incident reporting channel exists yet

NIST AI 600-1 states that formal channels to report and document AI incidents do not currently exist, and that publicly available incident databases decide on an ad hoc basis what they will track. For a buyer or operator, the practical result is that there is no standard regulator form to file against under this framework. Disclosure of a generative AI incident therefore depends on three things: the terms in your contracts with vendors and customers, the reporting duties set by your sector regulator, and the incident records your own organization keeps. The Generative AI Profile does not fill that gap with a reporting mechanism of its own, so the absence of a channel is something to plan around rather than wait for.

A missing channel does not remove obligations that already exist. Breach notification duties under data protection and privacy law, sector rules for financial, health, critical infrastructure and public sector entities, and the notice clauses in your customer and supplier agreements can all apply when a generative AI system contributes to a harmful event. Whether a specific event triggers a specific duty depends on the data involved, the jurisdiction, your role as provider or deployer, and the contract language, so confirm with counsel which existing laws and contracts apply to each system you run or buy. Ask your legal team to map those obligations to the AI systems in your inventory before an incident occurs.

Until a formal channel exists, the work that makes disclosure possible falls to your own records. Confirm that your incident logs capture the AI system involved, the version and change history at the time of the event, the third-party components and plugins in use, and the people who decided what to report. Confirm also who in your organization holds the authority to notify a customer, regulator or affected party, and how that person is reached outside working hours. These are internal decisions and evidence items you can assign, test and document now, and they are the inputs any future reporting duty will require.

How to build an incident disclosure process from MANAGE 4.3

This sequence turns the generative AI incident definition in NIST AI 600-1 into a repeatable path from detection to external disclosure, with a named record or decision at each stage. It is a structure for your own program, not a finished legal process, and it should be reviewed with counsel.

Define what counts as a generative AI incident
Start by adopting the AI 600-1 definition of an AI incident: an event where the development, use or malfunction of an AI system contributes to harm to health, disruption of critical infrastructure, violations of human rights or legal obligations protecting fundamental, labor and intellectual property rights, or harm to property, communities or the environment. Have the AI governance lead and the security or incident response owner agree on the harm categories that apply to your generative AI systems, and write down which internal triggers (user complaints, output review findings, vendor notices) open an incident. The output is a written incident definition and trigger list, approved by the accountable executive and linked to your AI inventory.
Log and record each incident
Open an incident record for every event that meets the definition, including near misses that your criteria capture. Record the date, the system and version, the affected users or communities, the observed impact, the relevant prompts, outputs or logs, and any related change records or third-party plugin involvement. AI 600-1 points to logging, recording and analyzing incidents along with change management records, version history and metadata as the practices that let teams respond. The output is a complete incident record in a store that the response team can query, and a check that each record links to the system's version history.
Triage and contain the incident
The incident owner classifies severity against the harm categories, decides whether the affected generative AI component should be restricted, rolled back or deactivated, and assigns the investigation. Where the incident involves a third-party model, plugin or dataset, confirm whether the vendor's incident response plan applies, as GV-6.2-003 suggests defining ownership of response functions for third-party generative AI technologies. The output is a triage record that names the owner, the containment decision and the open questions to be answered in the after-action review.
Run the after-action assessment
Under MG-4.3-001, conduct an after-action assessment of the incident once containment is in place. Reconstruct the timeline from the incident record, identify the root cause (model behavior, data, prompt handling, access control, human oversight or integration), and record whether existing measurements and controls would have caught it. Include the people who operated and relied on the system, not only the engineers. The output is an after-action report with findings, corrective actions and owners, and updates to the risk register, test plans or acceptable use rules where the findings call for them.
Decide on external sharing with affected parties
The Playbook suggests regularly sharing information about errors, incidents and negative impacts with stakeholders and affected parties. Decide what to share, with whom, through which channel and at what level of detail, using the after-action report and the impact on each group. Document the reasons for sharing or not sharing, including any confidentiality or security considerations. The output is a disclosure decision memo signed by the accountable executive and reviewed by legal, plus a log of the notices actually issued.
Map the reporting step to legal and regulatory duties
Before any formal report is filed, identify which legal or regulatory reporting duties the incident may trigger. MG-4.3-003 calls for reporting in line with legal and regulatory requirements, citing examples such as HIPAA breach reporting and NHTSA autonomous vehicle crash reporting. Your counsel should map the incident to the regimes that apply in your sector and jurisdictions, including breach notification and data protection rules that GV-6.2-003 asks you to check against your response plan. Note that AI 600-1 says formal channels to report AI incidents do not currently exist, so the mapping is your own work. The output is a reporting obligations register for the incident with deadlines confirmed from the applicable law, and the filed or declined reports recorded against the incident.
Feed results back into governance and testing
Close the loop by keeping the incident database current, with dates, impact assessments and responses for each entry, and by updating the system's documentation, change records and monitoring plan. Review the incident trends at the governance forum so that the incident definition, triggers and testing priorities reflect what has happened. Confirm that the lessons are reflected in the next version release and that the incident record is marked closed only after its open actions are verified. The output is an updated incident database, a closed incident record with verified actions, and a governance summary for the accountable executive.

Which records show that an AI incident was handled

This table lists the records an assessor or regulator can ask to see after a generative AI incident, what each record shows and the NIST source that points to it. Read each row as a question you must be able to answer with a retrievable document, not as a file you create once and forget.

Record	What it shows	NIST source
Incident log with dates, impact assessments and responses	Each reported error, near miss or incident with its date, the impact assessed and the response taken	Playbook suggestion under MANAGE 4.3; MANAGE 4.3 actions in AI 600-1
System change database	Every change made to the generative AI system, such as model, prompt, plugin or configuration updates, so responders can link a change to a malfunction	Playbook suggestion under MANAGE 4.3; AI 600-1 change management practices
Version history	Which model or system version was running when an incident occurred and what changed between versions	Playbook suggestion under MANAGE 4.3; AI 600-1 documentation practices
Change management records	Approvals, testing and rollback decisions behind each change, showing who authorized it and why	AI 600-1 documentation practices for incident response
System metadata	Identifiers, configuration and deployment details of the generative AI system at the time of the incident	AI 600-1 documentation practices (logging, recording and metadata)
Third-party inputs and plugin records	Which third-party data, plugins and content sources were connected, their access controls and what they delivered	AI 600-1 guidance on third-party inputs and plugins; GV-6.2-003
Incident disclosure and reporting records	Which stakeholders, affected parties or regulators were notified, when and against which legal requirement	MANAGE 4.3 actions on sharing information and reporting in line with legal requirements

Who owns incident disclosure: your team, a partner and the independent assessor

Your organization owns every decision about whether an event is an AI incident, whether it is reportable and what is disclosed to whom. AI 600-1 frames incident handling as something the AI actors in the organization carry out together, so no single function can run it alone. Security operations, legal, product owners, the AI system owner and senior executives each hold part of the decision, and the responsibilities should be written down before an incident happens.

Classification and triage: Security operations and the AI system owner decide whether a suspected event meets the organization's own definition of an AI incident, based on the harm categories in the Generative AI Profile.
Reportability decisions: Legal and compliance decide whether a breach notification, sector regulator or contract obligation applies, and on what timeline.
Disclosure and communication: Senior executives approve what is shared with customers, affected parties and regulators.
Product and model decisions: Product owners decide on pausing, rolling back or changing a system after an incident.
Records of decisions: The incident record must show who decided what and when.

Confirm internally that these roles have named owners, that legal review sits inside the response path, and that someone other than the system owner can declare an incident.

How third-party plugins and models change incident response

NIST AI 600-1 says that documenting and reviewing third-party inputs and plugins matters especially for incident disclosure, because content delivered through plugins is often distributed with inconsistent or insufficient access control. For a buyer, the practical consequence is that an incident may start in a component you did not build, host or log. Before go-live, ask which plugins, retrieval sources and pre-trained models feed the system, who approves each one, and which of them can pass content into your environment without your own access checks. Record that inventory with versions so that, when something goes wrong, you can tell whether a given component was involved.

The Generative AI Profile's suggested action GV-6.2-003 addresses this directly. It calls for incident response plans for third-party generative AI technologies that define who owns each incident response function, are rehearsed at a regular cadence and are reviewed for alignment with breach reporting, data protection and privacy laws. In practice, the plan should name the owner for detection, customer notification, regulator notification and communications with affected people, and it should show which of those steps the vendor performs and which fall to you. Rehearsal should include the vendor's contact path, not only your internal team. Confirm the rehearsal cadence and the legal reviewers in your own documentation rather than assuming them.

Contract terms, not the framework, decide what a vendor must provide. Ask for the vendor's incident notification commitments in writing, including the time to notify, the content of the notice and the cooperation duties after notice. Ask which logs and metadata the vendor makes available to you, such as access records, plugin invocation records, model or version identifiers and change history, and in what format and retention period. Ask how the vendor rehearses joint response with customers and whether it will take part in your exercises. NIST sets no reporting deadlines of its own, so these commitments must be negotiated and checked against the legal duties that apply to your organization.

What usually breaks AI incident disclosure and how to prevent it

Most failed AI incident disclosures trace back to gaps that exist before any incident happens: undefined terms, records that cannot be traced, unowned third-party events and untested plans. The cards below name each failure, the fix and the record or step that addresses it, so the organization can show its work when a regulator, customer or affected party asks.

No shared incident definition

Security teams and the AI product team often classify an event differently. NIST AI 600-1 defines an AI incident by its effects, including harm to health, disruption of critical infrastructure, violations of human rights or legal obligations, and harm to property, communities or the environment. Agree on that definition in writing, with examples of model behavior that qualifies, and check that both teams use the same triage criteria. The record that fixes this is the incident taxonomy and triage procedure, reviewed by both teams.

Logs not tied to model versions

An incident review fails when the team cannot establish which model version, system prompt, retrieval configuration or plugin set produced the output. NIST AI 600-1 recommends logging and recording generative AI incidents alongside change management records, version history and metadata. Check that every logged interaction carries the model identifier, configuration hash and prompt template version in effect at that time. The record that fixes this is a change log linked to the inference log.

Plugin and third-party events without an owner

Content delivered through plugins and third-party components is often distributed with inconsistent or insufficient access control, and it is easy for each party to assume the other will report it. NIST AI 600-1 stresses documenting and reviewing third-party inputs and plugins for incident disclosure. The Generative AI Profile action GV-6.2-003 suggests incident response plans for third-party generative AI that define who owns each response function. The record that fixes this is a responsibility matrix covering each vendor, plugin and model source.

Response plans never rehearsed

A written incident response plan that has never been exercised usually fails on its first real use, because contact lists are stale and decision rights are unclear. GV-6.2-003 calls for third-party incident response plans to be rehearsed at a regular cadence and reviewed against breach reporting and data protection laws. Run a tabletop exercise that starts from a generative AI event, such as leaked training data or a harmful output shipped to customers, and record the gaps. The record that fixes this is an exercise report with dated action items.

Disclosure decided without legal review

Teams sometimes publish or notify before counsel has assessed whether a reporting obligation applies. MANAGE 4.3 actions call for reporting incidents in line with legal and regulatory requirements, and the Playbook points to examples such as HIPAA breach reporting. Build a decision point where legal, privacy and the incident lead assess each incident against applicable notification duties before any external statement. The record that fixes this is a notification decision log that names the approver and the reasoning.

Public statements outrunning controls

Public descriptions of safety testing, monitoring or human review can exceed what the organization can demonstrate. When an incident occurs, the gap between the statement and the evidence becomes the issue. Before publishing, compare each claim against a named control and its evidence, such as test results, monitoring dashboards or review records. The record that fixes this is a claims register that maps every public statement about AI safety to its supporting evidence and owner.

What the AI Action Plan changes for AI incident response

The main point for readers is that America's AI Action Plan recommends changes to incident response, but it does not impose them on private organizations. The plan asks NIST to work with industry so that AI is included in incident response standards and frameworks, and it recommends that CISA's Cybersecurity Incident and Vulnerability Response Playbooks be modified to cover AI systems. It also suggests that CISOs consult their Chief AI Officers. These are policy recommendations to federal agencies. A private organization does not become bound by them because it reads the plan, and no revised standard or playbook has been announced as adopted. NIST also states that AI RMF 1.0 is being revised as part of the Action Plan and that no revised version had been published as of October 2026, so the exact wording of any future AI incident guidance remains open.

Because the target documents are still moving, the practical step is to keep AI incident records in a form that can be mapped to whichever incident response standard is eventually adopted. In practice, that means recording for each event the date, the AI system and version involved, the affected people or systems, the impact assessment, the response taken and the after-action review, which mirrors the database fields the Playbook describes under MANAGE 4.3. Teams should also keep change management records and version history tied to each incident so responders can establish what changed before a failure. Confirm with your legal and compliance leads which sector rules already require reporting, since those obligations apply now regardless of how the federal plan develops.

Before you plan any change to your incident response procedures, confirm the status of any CISA playbook change directly with CISA rather than relying on secondary summaries of the Action Plan. Ask whether a modified playbook has been issued, whether it applies to private operators or only to federal agencies, and whether it names specific AI incident categories. Record the answers with their dates, because a playbook revision may land after your own documentation is written. An implementation partner can prepare the logging and incident records, but the organization owns the incident response decisions and any disclosures it makes.

Questions buyers ask about AI incident disclosure

Does NIST AI 600-1 require us to disclose AI incidents, and to whom?

No. NIST AI 600-1 is a voluntary profile of the NIST AI RMF, and no federal rule makes it mandatory for most organizations. The profile says formal channels to report and document AI incidents do not currently exist, and public incident databases decide ad hoc what to track. Disclosure duties usually come from elsewhere: sector rules, privacy law, breach notification statutes, or contracts. The Playbook's MANAGE 4.3 actions point toward sharing incident information with stakeholders and affected parties, and MG-4.3-003 cites examples such as HIPAA breach reporting. Ask counsel which notice obligations apply to your AI systems, which regulator or customer receives each notice, and what deadlines they set.

Is there a certificate for AI incident disclosure under NIST AI 600-1?

No. NIST does not certify, accredit or endorse organizations for using the AI RMF or its Generative AI Profile, and it describes no conformity assessment program for either. An assessor can review your incident records, plans and evidence against the profile's suggested actions, and a customer or regulator may ask for that review. However, any report that results comes from the assessor or auditor, not from NIST or from a consultant. Confirm with the buyer which document they expect, such as an internal assessment, a third-party review or a contractual attestation, before you agree on scope.

What incident records would an assessor ask us to produce?

Assessors typically ask for evidence that you log, record and analyze generative AI incidents, as AI 600-1 describes, along with the records that show how the system changed. In practice that means an incident register with dates, impact assessments and responses, after-action reviews, change management records, version history, and metadata for model and prompt configurations. For third-party components, expect requests for documented plugin and input reviews and incident response plans for third-party generative AI technologies, including GV-6.2-003. Ask the assessor to list the exact evidence items and sampling approach in writing before you collect anything.

Can we build an AI incident disclosure process ourselves?

Often yes, if your security incident response team already runs a mature process and has clear ownership of AI systems. The main cost drivers are the number of generative AI systems in scope, how many third-party models and plugins they depend on, the state of your logging, and how many legal regimes your notices must follow. Internal work usually covers ownership, the incident taxonomy, logging design, and tabletop rehearsals. Counsel must still define notice triggers and wording. Confirm your internal capacity against the Playbook actions and the AI Action Plan's direction to fold AI into incident response standards, which NIST and CISA are still working on.

What does an implementation partner prepare, and what does it not do?

A partner such as DeployOpen can prepare systems, controls and evidence for an assessment. That can include setting up centralized logging for self-hosted AI platforms inside your own infrastructure, documenting configuration and version history, drafting incident response runbooks, scheduling rehearsals, and organizing the incident register. The partner does not own your controls, decide your legal notice obligations, or issue audit reports or certifications. Only an independent auditor, assessor or certification body does that. Write these roles into the statement of work, and confirm with the partner exactly which deliverables and timelines are fixed before work starts.

How should a customer contract describe AI incident notice?

Describe the trigger, the timing, the recipient and the content in plain terms, then link each term to your incident definition. Use the AI 600-1 definition of an AI incident as a starting point, but tie it to harms your contract actually covers, such as health, critical infrastructure, legal obligations, property and data. Specify who notifies whom, which channel is used, what the notice must contain, and how the supplier handles third-party components and plugins. Avoid promising outcomes or fixed response times until counsel and operations confirm they are achievable in your environment. Ask the buyer which regulations they must satisfy, because their obligations may require notice terms you have not considered.

How DeployOpen prepares AI incident logging and response evidence

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure. For NIST AI 600-1 incident disclosure, we help organizations set up the logging, documentation and response records that their own incident process depends on, while the organization keeps ownership of its controls and decisions.

How we scope

We agree a written scope before work starts, naming which generative AI systems, logs and response records are covered.
We confirm with you which legal and regulatory reporting duties apply, since those set what must be recorded and how fast.
We list third-party models, plugins and vendors whose incidents must flow into your records and response plans.

How we build

We configure logging and incident records for the self-hosted platforms in scope, covering prompts, outputs, changes and versions.
We set up an incident database with dates, impact assessments, responses and after-action notes, following the Playbook's MANAGE 4.3 prompts.
We test that logs capture enough detail to reconstruct an incident, and document the access controls that protect those logs.

How we hand over

You receive configuration records, logging standards, incident record templates and the runbooks your team operates.
We document how third-party incident response ownership maps to GV-6.2-003, including contacts and rehearsal plans you run.
We provide an evidence map that shows which records support which NIST subcategories, for your internal review or your assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed in writing.
We can rehearse incident scenarios with your team in a private cyber range and record the lessons learned.
An independent auditor or assessor reviews your evidence. DeployOpen prepares the evidence but does not issue reports or certificates.

NIST AI 600-1 incident disclosure for generative AI