MANAGE 4.3 Incident and error communication: evidence

What MANAGE 4.3 incident and error communication requires in practice

MANAGE 4.3 asks your organization to communicate AI incidents and errors to the relevant AI actors, including affected communities, and to follow and document how you track, respond to and recover from them. If you are the compliance lead or engineer who has to show this, the question an assessor will ask is simple: when something went wrong with a deployed AI system, who was told, when, what was done, and where is the record? The risk this outcome addresses is that problems stay inside one team, so the people operating, using or affected by the system never learn that harm occurred or that a fix is in place. The NIST AI RMF is voluntary and has no certification, so nobody will hand you a NIST seal. An assessor, internal auditor or customer will test your records, and they will look for a single trail that runs from detection through notification to recovery.

This is hard for three reasons. First, the evidence is scattered. A model owner may see a drift alert in a monitoring tool, support may receive the complaint in a helpdesk, a security analyst may open a ticket for the same event, and legal may discuss reporting obligations by email. Second, communication to affected individuals and communities is the step teams most often skip, because no one owns it and the audience is outside the company. Third, near misses rarely get recorded at all. The NIST AI RMF Playbook suggests a database of reported errors, near misses and incidents with dates, impact assessments and responses, plus a log of system changes and version history. Confirm with your own AI and legal teams which stakeholders, communities and regulators apply to each system before you build that register.

Start with three decisions. Name an owner for each class of incident and define who receives notice, through which channel and within what internal deadline. Decide what counts as an error or near miss so that minor events still enter the record. Then connect the register to your system change history, so that every fix can be traced to the incident that prompted it. Open-source service management tools can hold this trail. GLPI's Assistance module tracks tickets, problems and changes under ITIL practices, and Zammad consolidates customer messages from email, chat, telephone and social media into one ticket system. For security-relevant AI incidents, DFIR-IRIS keeps a case with assets, tasks, evidence and an audit trail. Confirm that these tools fit your data handling rules, and remember that a tool produces evidence only if people use it consistently.

Which AI systems, incidents and parties this requirement reaches

MANAGE 4.3 applies once an AI system is in production, so the first scoping decisions are which systems are live and which events count as incidents. The cards below set out the systems, incident types, relevant AI actors and third-party or generative AI components that determine how much work the communication and tracking process carries.

Systems in production

MANAGE 4.3 is tied to deployed systems, so start with an inventory of every AI system that is live, including pilots that real users or real decisions touch. Confirm which systems the organization owns, which it configures from a vendor, and which run inside business tools that staff use without a formal project. Each live system needs a named owner who receives its error and incident records, because a system missing from the inventory will not be covered by the process.

Incident and error types

Define what counts before the first event occurs. Most programs cover three categories: errors where the output was wrong, near misses where harm was avoided by chance or by a control, and negative impacts reported by people affected by the system. The Playbook asks organizations to keep a database of reported errors, near misses and incidents with dates, impact assessments and responses, so each category needs a field in that record. Write the thresholds in the policy so staff know when a complaint becomes an incident.

Deployment and operations staff

Deployment, operations and monitoring staff detect most errors first, so they are the primary reporters and the first recipients of incident notices. Identify who on the operations side can open an incident, who approves external communication, and who can pause or roll back a system. Their duties should appear in the incident procedure and in the role assignments that MANAGE 4.3 expects the organization to document.

End users, domain experts and affected communities

The Playbook tags MANAGE 4.3 with end-users, human factors, domain experts and affected individuals and communities, so the scope extends beyond the internal team. End users report symptoms, domain experts judge whether an error is material, and affected people need a route to raise harm and receive a response. Decide which groups get notices, through which channel, and in what language. Confirm these routes exist before go-live, not after the first complaint.

Third-party AI components

A vendor model, API or dataset that fails inside your product is still your incident to track and communicate. Scope in every third-party AI component and confirm, in contracts or service terms, how the vendor reports its own incidents, how quickly it notifies customers, and what logs it can provide. The gap between vendor notice and internal notice is where many communications fail, so record it as a dependency in the incident process.

Generative AI and external reporting duties

NIST AI 600-1 adds three suggested actions for MANAGE 4.3 covering confabulation, data privacy, information integrity and information security. These actions include after-action assessments of generative AI incidents and reporting in line with legal requirements, with the profile citing examples such as HIPAA breach reporting. Check which sector rules apply to your system, because a generative AI incident may trigger a legal notice that runs on its own deadline and must be routed to legal and compliance staff.

How an assessor tests incident and error communication

The assessor starts with the register of errors, near misses and incidents. The Playbook suggests maintaining a database of reported errors, near misses and incidents with dates, impact assessments and responses. The assessor checks whether that register exists, who can write to it, and whether entries are complete enough to reconstruct what happened without interviewing the team.

Completeness: Sample entries from the period under review and trace each back to its source, such as a monitoring alert, a user report or an internal test finding. Missing sources suggest the register is not the system of record.
Timestamps: Confirm detection, triage and closure dates are recorded and in a consistent time zone.
Impact assessments: Check that each entry records affected users, affected groups and the severity judgment, with the reasoning written down.
Near misses: Ask how near misses are logged. Registers that contain only confirmed incidents often miss the signals the assessor expects to see.
Access and integrity: Review who can edit or delete records and whether changes are logged.

Ask the organization to confirm its register's fields, retention period and owner before the review starts.

Implementing incident and error communication step by step

This sequence turns MANAGE 4.3 into a working process: one register of incidents and errors, a defined path for who hears about them and how, tracked recovery, and reviews that feed back into the system's change history.

Define what counts as an incident or error
Write a short definition set that the AI team, operations and the risk owner all accept. It should separate a model error (a wrong or harmful output), a near miss (an event that could have caused harm but did not), and an incident (an event that caused or is causing negative impact), and it should name the severity levels that trigger escalation. Owners are the accountable AI risk lead with input from domain experts. The output is an approved definition document that the register and the reporting rules both reference, with a review date set by the organization.
Open one incident and error register
Create a single register that holds every reported error, near miss and incident, with the date of occurrence, date of detection, affected system version, impact assessment and response taken. The Playbook suggests keeping this kind of database for MANAGE 4.3, so the register should be the one place people check when they ask what happened. Confirm whether the register lives in a ticketing tool or a case tool, and who may edit entries. The output is a populated register template with at least one tested entry, and a named owner who checks it on a set cadence.
Map who must be told and how
For each severity level, list the relevant AI actors who need the information: deployers and operators, end users, domain experts, and affected individuals or communities where the impact reaches them. Record the channel, the content and the approver for each audience. Separately, identify every legal or regulatory reporting duty that applies to the system's sector and jurisdiction, such as breach reporting or sector-specific incident rules, and confirm the notification route with counsel. The output is a communication matrix signed off by the risk owner and legal, with the reporting duties listed by name.
Run tracking and response through a defined workflow
When an entry is logged, route it through a fixed workflow: triage, assignment, containment, investigation, communication, and closure. Use the ticketing or case tool to hold the state, owner and notes at each stage, so that every action is attributable and time-stamped. Where a security element is involved, a case management tool can keep evidence with chain of custody. The output is a workflow configuration with the required fields and approvals, plus a test ticket that moves through every state and shows the audit trail.
Communicate incidents to the defined audiences
Send the messages set out in the communication matrix at each severity level, using the approved wording and channel. Keep a copy of each notice in the register entry, with the recipient group, the time sent and any follow-up questions received. Where a legal duty applies, file the report through the required route and keep the submission and acknowledgment with the record. The output is a complete communication log attached to each incident, showing who was told, what they were told and when.
Record the post-incident review
Once the incident is contained and impact is assessed, hold a review with the AI team, operations, domain experts and the risk owner. Capture the root cause, the controls that failed or were missing, the actions taken to recover, and the changes proposed to prevent recurrence. The GenAI Profile expects after-action assessments of generative AI incidents, so use the same structure for other systems. The output is a written review linked to the register entry, with each action assigned to an owner and tracked until closed.
Keep the change log and version history in step
Link every corrective change to the system's change log and version history, so that the record shows which version was affected, which version fixed it, and when the fix reached production. Check that the change log entry cites the incident register number and that deployments do not proceed until the linked action is recorded. The output is a traceable chain from each incident to the change that addressed it, which a reviewer can follow without asking the team to reconstruct events.

How the incident record, communication and change log connect

The point of MANAGE 4.3 is that an incident or error leaves a traceable trail, so the organization can show who was told, what was done and which system version was involved. In practice, that means one incident entry that links to four other records: the response ticket, the stakeholder notices sent, the after-action review and the system version that changed. If any link is missing, an assessor reading the record will struggle to confirm that communication and recovery actually followed the process. Open-source tools can hold these records. DFIR-IRIS keeps each case as one record of assets, indicators, tasks and evidence with a full audit trail, which suits security-related incidents. GLPI's Assistance module handles tickets, problems and changes following ITIL practices, which suits operational failures and the change records that follow them. Zammad consolidates customer correspondence from email, chat, telephone and social media into one ticket system, which helps when notices to users must be traced to a specific case.

The Playbook's suggested actions for MANAGE 4.3 point to two databases that tie these records together: one of reported errors, near misses and incidents with dates, impact assessments and responses, and one of system changes with version history. The practical check is whether each incident ID appears in the change log with the version it produced, and whether each stakeholder notice cites the same ID. Confirm with your own tools whether an incident can be linked to a change record without manual copying, because cross-references kept by hand tend to drift.

Generative AI systems add two obligations to this chain. NIST AI 600-1 lists three suggested actions for MANAGE 4.3, MG-4.3-001 to MG-4.3-003, tagged to the risks Confabulation, Data Privacy, Information Integrity and Information Security. The profile's examples include conducting after-action assessments of generative AI incidents, and reporting incidents in line with legal and regulatory requirements, citing HIPAA breach reporting and NHTSA autonomous vehicle crash reporting as illustrations. For your organization, the after-action review should therefore be a required linked record, and a reporting decision field should sit on the incident entry. Ask your legal team which regimes apply to your sector and jurisdiction, since the profile's examples do not establish which reporting duties affect you.

Evidence that passes an audit for MANAGE 4.3

No assessor can certify MANAGE 4.3 because the AI RMF has no certification, so your organization must show its own records. The artifacts below connect incident handling, stakeholder communication and change history into one trail that a reviewer can sample and trace. Keep each one current between reviews, not just before a review.

Incident and error database

A single register of reported errors, near misses and incidents, each with a date, impact assessment, owner and response. The Playbook suggests maintaining this database, so it is the first thing a reviewer will ask to see. Check that every entry has a closure status and that near misses are logged as well as harms. Review the register monthly and reconcile it against tickets.

Stakeholder communication records

Copies of notices, advisories and updates sent to users, deployers, affected individuals and communities, with dates, recipients and channels. MANAGE 4.3 expects information about errors, incidents and negative impacts to be shared with affected parties, so a reviewer will compare these records against the register. Keep the approved wording and the approver's name alongside each message. Confirm which channels your legal team requires for notices.

Response and recovery tickets

Ticket histories showing who triaged each incident, what actions were taken, when service was restored and how the fix was verified. Ticketing tools that follow ITIL practices, such as GLPI, can link problems, changes and incidents so the chain is visible. An assessor will sample a few incidents and trace them from report to closure. Check that timestamps and reassignments are preserved and cannot be edited silently.

After-action reviews

Written reviews of significant incidents covering root cause, what worked, what failed, and which changes were agreed. For generative AI systems, NIST AI 600-1 suggests after-action assessments, and reporting obligations under applicable law may apply. Schedule the review within a period your incident policy sets, and confirm with your legal counsel which incidents require external reporting. Track each agreed action to completion.

System change database and version history

A record of model, data, prompt and configuration changes with the reason, approver and deployment date, plus the version history that links each change to the incidents it addressed. This lets a reviewer see whether an incident led to a fix and whether the fix reached production. Keep the history under version control so that past states can be reproduced. Check that emergency changes are logged with the same fields as planned ones.

What meeting MANAGE 4.3 costs in money and effort

This table lists each cost component of meeting MANAGE 4.3, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No figures are published for this work, so use the quote questions in the final column to compare offers on equal terms.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Incident tooling and licenses	Software vendor or open-source project, plus hosting staff	Licenses recur if commercial; open-source platforms such as DFIR-IRIS, GLPI and Zammad remove license spend but not hosting or upkeep	Number of incident sources, hosting model and whether a commercial support contract is needed
Engineering to wire alerts and tickets	Internal platform engineers or an implementation partner under a fixed-scope agreement	One-time for integration, then recurring for maintenance as sources change	Number of SIEM, EDR and REST sources, custom ticket fields and workflow rules
Communications and stakeholder notices	Internal legal, communications and product staff	Recurring, tied to each incident or error	Number of affected parties, notice obligations in applicable law and how many templates exist
After-action reviews	Internal incident responders, system owners and domain experts	Recurring, per incident and per near miss	Incident frequency, severity, and how much of the review is reused from a standard template
Incident and change database upkeep	Internal operations or GRC staff	Recurring, as records are added and reviewed	Volume of records, required fields and whether changes are captured automatically from the ticket system
Evidence upkeep and version history	Internal engineering and document owners	Recurring, with a one-time setup of retention rules	Retention period set by the organization, number of systems and frequency of model or prompt changes
External review of the process	Independent assessor or consultant, selected by the organization	Usually one-time per review cycle, repeated at each assessment	Scope of systems reviewed, sample depth and whether prior evidence can be reused
Auditor sampling	Independent auditor or certification body, if the organization is assessed against a contract or regulation	Recurring at each assessment cycle	Number of incidents in the period, how well records are indexed and how quickly records can be produced

Who does what: your team, an implementation partner and the auditor

Your organization owns MANAGE 4.3 in full. Deciding what counts as an error, who must be told about an incident, and what affected people and communities receive are management decisions that no vendor or auditor can make for you. The NIST AI RMF Playbook's suggested actions for this subcategory describe the same internal work: sharing information about errors, incidents and negative impacts with stakeholders, and keeping records of reported errors, near misses and their responses.

Incident definitions and severity: Set the thresholds for logging an error, a near miss or an incident, and name who may declare one.
Communication decisions: Decide who receives notices, including affected individuals and communities, and approve the wording before release.
Record ownership: Name the owners of the incident database, the system change history and the post-incident review.
Reporting duties: Confirm which notification obligations apply in your sector and jurisdictions, and who signs off on each one.

Check that every one of these roles has a named person, a documented backup and a written record of each decision.

Where organizations fall short on AI incident communication

Most gaps under MANAGE 4.3 are not missing policies. They are records that never capture near misses, notices that reach executives but not the people affected, and evidence scattered across tools. Each card below names one gap, why it weakens the outcome, and the fix an assessor or auditor would expect to see.

No near-miss capture

Teams often log only incidents that reached customers, so errors caught in testing or by monitoring never enter any record. The Playbook suggests maintaining a database of reported errors, near misses and incidents with dates, impact assessments and responses. Fix: create one intake path for all three, with a required field for impact and a named owner who reviews near misses monthly. Ask to see the log and check that near misses appear in it.

Notices sent only to executives

Incident updates often go to leadership and legal while the people affected by the AI system hear nothing. MANAGE 4.3 names affected communities and end users among the relevant AI actors, so a communication plan that stops at the executive team leaves that outcome unmet. Fix: map each AI actor category to a channel and message template, including end users and affected individuals, and record who was notified and when.

Records split across chat and email

Responders discuss a model fault in chat, approve a rollback by email and log the fix in a spreadsheet, so no single record shows the full sequence. Assessors look for a traceable case history. Fix: route every incident into one ticketing or case system, link the chat thread and email to it, and keep timestamps for detection, notification, containment and recovery in that record.

Missing links to system versions

An incident report that does not say which model version, prompt, dataset or configuration was live cannot show what changed or whether a fix worked. MANAGE 4.3 expects processes for recovering from incidents, which depends on knowing what was running. Fix: require the affected version identifier in every incident record and keep a change history that links each release to its tickets and rollback steps.

No after-action review

Teams fix the immediate problem and close the ticket without asking what allowed it. The generative AI profile suggests after-action assessments of generative AI incidents, and the outcome requires documented follow-up. Fix: hold a short review for every material incident, record root causes and corrective actions as tracked items, and check later that those items were completed.

Reporting duties not mapped

Some incidents trigger external reporting obligations under sector or privacy rules, yet nobody owns the decision to report. Generative AI actions under MANAGE 4.3 point to reporting in line with legal and regulatory requirements. Fix: agree with counsel which incident types create reporting duties, assign an owner for each, and confirm the clock and recipient in the runbook before an incident happens.

Questions buyers ask about MANAGE 4.3

How much effort does MANAGE 4.3 take to meet?

The effort depends mostly on how many AI systems are in scope, how many incident and error sources feed your records, and how many external parties must be notified. No supplied figure sets a duration, so ask any implementation partner for a fixed-scope estimate built from your inventory. The main work falls into three parts: defining what counts as an incident or error, setting up a register of reported errors, near misses and incidents with dates, impact assessments and responses, and writing communication procedures for internal teams, deployers, end users and affected communities. Costs recur whenever a new system enters production or a notification rule changes, so plan for ongoing upkeep rather than a single project.

Can we do MANAGE 4.3 in-house without outside help?

Yes. NIST AI 100-1 is voluntary, so an organization owns its own approach and nothing requires an external provider. Teams that already run incident response and a service desk can extend those processes to AI systems. Outside help is most useful when the AI inventory is incomplete, when no one has mapped which regulations require incident reporting, or when the team lacks people who understand both model behavior and reporting obligations. An implementation partner can prepare systems and evidence, but the organization must still decide what gets communicated and to whom.

How long does it take to build the incident and error records?

No supplied fact gives a timeline, so confirm durations with your team or a partner before committing. The time usually depends on how much historical data exists. Teams that already log tickets can start with a defined schema and backfill only recent events. Teams starting from nothing need to agree on severity levels, required fields such as date, impact assessment and response, and who can close a record. Expect the first months to produce mostly process decisions, then steady records as monitoring feeds in. Ask any provider to show how the record structure will be tested against a sample incident before the build is declared complete.

What does MANAGE 4.3 require from our staff?

It requires clear roles across several groups. Engineers need to report and tag errors consistently. Incident responders need a documented procedure for tracking and recovery. Legal and privacy staff must judge which events trigger external notice. Communications staff need approved templates for affected communities, and domain experts need to judge real-world impact. NIST's Playbook tags this subcategory with AI deployment, operation and monitoring, end-user, human factors, domain expert and affected community actors, so each group needs a named responsibility. Ask your partner to produce a responsibility matrix as part of the documented process.

Does an assessor certify our MANAGE 4.3 implementation?

No. The AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. Any assessment is an internal review or a review commissioned by a customer or contract. An implementation partner prepares the records, procedures and evidence, but only an independent auditor or assessor issues an opinion on them, and that opinion is not a NIST certificate. When a customer asks for proof, agree in advance on what evidence they will accept, such as a documented register, communication templates and sample after-action reviews.

How does MANAGE 4.3 relate to generative AI actions?

NIST AI 600-1, the Generative AI Profile published July 26, 2024, adds three suggested actions for MANAGE 4.3, numbered MG-4.3-001 to MG-4.3-003. They are tagged to the generative AI risks Confabulation, Data Privacy, Information Integrity and Information Security. The profile suggests conducting after-action assessments of generative AI incidents and reporting them in line with legal requirements, citing examples such as HIPAA breach reporting and NHTSA autonomous vehicle crash reporting. For an organization running generative AI, this means the incident register should capture model-specific failures such as fabricated outputs and data exposure, and the reporting procedure should name the regulators relevant to the sector. The profile is a suggestion set, not a checklist, so tailor it to your deployment.

Which tools can hold MANAGE 4.3 records and tickets?

Several open-source tools can cover parts of the workflow, and the right mix depends on your processes. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, indicators of compromise, tasks and evidence with a full audit trail, and it can triage alerts from SIEM, EDR and REST sources. GLPI (GPL-3.0-or-later) provides an Assistance module for tickets, problems and changes following ITIL practices. Zammad (AGPL-3.0-only) consolidates customer communication from email, chat, telephone and social media into one ticket system. Confirm each tool's fit for AI-specific fields such as model version and affected population before adopting it, because none of these was described as AI-specific in the supplied sources.

How DeployOpen works on this

DeployOpen prepares the systems and records an organization needs to show how it communicates AI incidents and errors and how it tracks and recovers from them. The organization still owns the policy, the decisions about who is notified, and the outcome of any assessment, which an independent auditor or assessor reviews.

How we scope

Agree in writing which AI systems, incident sources and affected parties the MANAGE 4.3 work covers.
Confirm which relevant AI actor groups, such as end users and affected communities, need a defined communication path.
Engagements are fixed-scope, with deliverables and timelines set out before any work begins.

How we build

Configure a case or incident record that holds assets, timelines, tasks and evidence for each AI error or incident.
Set up a ticket workflow for intake, response and recovery steps, with dated entries that create an audit trail.
Test the intake, escalation and notification path with the client's staff before the workflow is relied on.

How we hand over

Deliver a documented procedure for communicating incidents and errors, with named roles and approval points.
Provide an error and incident register holding dates, impact assessments, responses and system change history.
Hand over runbooks and records in formats the client's own teams can maintain after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for the systems in scope.
Review how the register and workflows perform after real incidents or exercises, and update them as needed.
Ask your auditor or assessor early which records they expect to see for MANAGE 4.3 before fixing the design.