ISACA AAISM: AI Incident Response Governance

AI incident response governance defines how an organization makes accountable decisions when an artificial-intelligence system creates, amplifies, or participates in a security incident. The technical response may involve disabling an endpoint or revoking a credential, but governance determines who can take that action, which evidence must be preserved, when customers or regulators are notified, how business continuity is protected, and what must be proven before the system returns to service.

The topic sits naturally inside Enterprise AI Governance. ISACA’s current AAISM exam outline explicitly includes AI-specific incident investigation, documentation, reporting, containment, notification, escalation, eradication, recovery, and continuity. That is a useful reminder that AI incidents are not a separate universe: they use familiar incident-management disciplines, but the assets, evidence, and failure modes require additional preparation.

Define what counts as an AI incident

Not every bad answer is a security incident. Governance should distinguish routine quality defects from events that threaten confidentiality, integrity, availability, safety, legal obligations, or material business decisions. A hallucinated draft may be a product defect; leakage of restricted data into an external model may be a security and privacy incident; an agent using excessive permissions to change production can be both a security incident and an operational outage.

Create decision rights before containment

AI containment can be disruptive. Disabling a model may stop a revenue process, removing tool access may block operations, and freezing a knowledge source may make a service unusable. Governance therefore needs clear authority for emergency actions. Security teams should know what they can isolate immediately, what requires a business owner, and when an executive incident leader can override normal change procedures.

Preserve AI-specific evidence

Investigators need more than host and network logs. Depending on the system, relevant evidence can include prompts, system instructions, retrieval results, model version, safety settings, tool calls, identities, authorization context, output, user feedback, vector-store changes, deployment metadata, and provider-side event logs. Without that context, the team may know that something failed but not why.

Contain the system in layers

Containment should target the compromised capability without causing unnecessary damage. Options include revoking tool credentials, disabling a connector, blocking a retrieval source, changing model routing, forcing manual approval, suspending a feature, rolling back a prompt or policy version, or isolating the entire service. The best choice depends on which layer is actually unsafe.