CSA AICM AI Incident Reporting: Build the Record Before the Alert

An AI incident report starts several steps before anybody opens a ticket. The application must have already attached a user or agent identity to the inference request, classified the content, recorded the model destination and preserved the policy decision. Without those fields, an alert saying "suspicious prompt detected" gives the response team a timestamp and very little else.

CSA AI Controls Matrix version 1.1 turns that evidence problem into named controls. The useful reading is a chain, rather than a single incident-reporting row.

TL;DR

• AICM v1.1 places AI incident work across SEF-01, SEF-03, SEF-04, SEF-05, SEF-07, SEF-09 and LOG-07.
• Define categories, severity, escalation, customer communication and regulatory triggers before an event.
• Preserve identity, request and response context, model route, policy version, timeline, containment actions and evidence artifacts.
• DeepInspect covers deliberately routed HTTP traffic between authenticated users or agents and LLMs. Endpoint compromise, model training and legal notification remain outside that boundary.

AICM treats reporting as an incident lifecycle

The CSA AI Controls Matrix version 1.1, released June 22, 2026, contains 247 control objectives. Its Security Incident Management domain gives reporting an operating structure. SEF-01 establishes the governing policy and review process. A response plan and communication strategy sit under SEF-03. Planned exercises after material changes satisfy SEF-04, while SEF-05 covers reporting metrics for the incident programme. Timely response by category and severity appears in SEF-07. Finally, SEF-09 requires a secure repository of incident records.

Those controls describe a lifecycle. Detection creates a candidate event for further review. Triage assigns a category and severity. Investigation builds the timeline and identifies affected assets, identities, services and data. Containment changes the running system under documented authority. Communication sends an approved account to internal teams, customers, supply-chain parties or regulators. The secure repository then preserves the record for analysis and corrective action.

This article focuses on that lifecycle. The AICM controls mapping covers the wider domain-to-control relationship, while the AICM audit-evidence guide addresses the full assessment package.

The report needs request-level facts

CSA's AICM v1.1 implementation guidelines for application providers specify the fields expected in an incident record under SEF-09. They include a unique incident ID, detection and closure times, category and severity, affected assets and data, indicators of compromise, a timeline, containment and recovery actions, root-cause analysis, lessons learned, corrective actions and evidence such as logs or forensic data.

For an LLM incident, several additional facts make that list usable. Record the authenticated person or agent represented by the request. Preserve the model endpoint and version. Store the policy version and decision outcome. Capture the content classification applied to the prompt and response. Keep a correlation ID that joins the gateway record to application, identity and provider telemetry.

Picture the incident bridge at 09:17 on a Tuesday: one analyst has a SIEM alert, another has an API request ID on a whiteboard and legal asks which customer records crossed the boundary. A report assembled from correlated fields answers that question. A screenshot of a chatbot transcript creates another lead to investigate.

LOG-07 supplies the forensic spine

LOG-07 requires organizations to define which events and metadata enter logging scope. CSA names authentication and authorization events, configuration changes, data access, errors, administrative actions, security alerts, model-lifecycle events and third-party API calls. The shared guidance also calls for timestamps, user or service identity, source IP, resource, action, result code and request ID so investigators can correlate events.

Application-provider guidance adds client and API interactions, input and output transformations, processing errors and model inference requests. The related auditing guidance asks assessors to verify that scope includes successful and failed interactions, model requests and responses, prompt-injection events and content-policy violations. It also expects updates when a new AI capability or model integration changes the threat environment.

That gives an incident program a concrete precondition: decide what the report will need, then instrument those fields before production traffic arrives. The AI incident response playbook covers containment and recovery in more detail. AICM adds the control ownership and evidence discipline around it.

Sensitive payload handling still needs a separate decision. CSA's implementation guidance allows masking, tokenization or pseudonymization when collecting sensitive data. A report can preserve classification, hashes, selected evidence and controlled payload references without turning the incident repository into an unrestricted copy of every prompt.

Severity and notification triggers belong in the plan

SEF-03 asks for classification criteria, severity thresholds and escalation procedures. CSA explicitly includes conditions that may trigger regulatory notification, contractual reporting or executive escalation. Application providers should translate that into a decision tree grounded in the AI service they operate.

A blocked prompt-injection attempt can remain a security event when the request never reached the model and no downstream action occurred. Permitted traffic containing restricted customer data can qualify as an incident immediately when it reaches an unapproved model destination. Exposure of another tenant's content in a model response adds a different data and customer impact. Compromise of the model endpoint may trigger supply-chain communication alongside containment.

Each branch needs an owner. Security can assign technical severity and lead containment. Privacy or legal determines statutory notification after reviewing jurisdiction and affected data. Product owns customer-facing behavior during degradation. Vendor management contacts the model or orchestration provider. Executive escalation follows a defined threshold instead of the loudest person on the call.

My view is blunt: an AI incident severity matrix that omits the request destination and data classification is a generic security worksheet wearing a new title.

Testing has to exercise the model route

SEF-04 calls for planned exercises or testing after significant changes. CSA's application-provider guidance names degraded model performance, unexpected output, service disruption, monitoring and alerting, escalation, function disablement, fallback logic and model rollback. It also asks teams to update playbooks with lessons from the exercise.

Run one scenario through the real reporting chain. Start with an authenticated support agent whose prompt includes a customer account number and reaches a model endpoint outside the approved route. Confirm the monitoring system opens an event with the request ID. Have the analyst retrieve the identity, classification, destination, policy decision and response record. Exercise route disablement or deny policy, then document who approved it and when. Draft the customer or regulator facts without sending them.

The test should expose missing evidence and unclear authority. It should also verify degraded service behavior. If the approved model endpoint is disabled during containment, the application might use a reviewed fallback, defer the response or require human handling. Those choices sit with the application provider. A proxy can enforce the route decision, while product code determines what the user sees next.

Repeat the exercise after a material model, route, policy or application change. A calendar-only test can leave a newly introduced inference path untouched for months.

Reporting metrics should measure decision quality

SEF-05 requires incident metrics, but AICM leaves room for organizations to choose metrics suited to their systems. Raw incident counts can mislead the review team. Ten prompt-injection alerts could mean ten blocked attempts with complete records or ten successful exposures discovered after a customer complaint.

Track elapsed time between detection, confirmation, containment and closure. Measure how often investigators can identify the authenticated actor, content classification, model destination and policy version without manual reconstruction. Record the share of incidents with complete timelines and completed corrective actions. Keep reopened incidents visible because they show weak root-cause analysis or incomplete remediation.

For request-boundary incidents, one useful quality check is a reconstruction sample: select a closed incident ID and reproduce the sequence of decisions using retained records. The analyst should be able to move through the correlated request IDs and explain which traffic was allowed, denied or redacted. That test measures evidence usability directly.

STAR for AI uses the AI-CAIQ self-assessment at Level 1, according to the official STAR for AI programme. A concise answer to an incident-control question should point to the policy, one tested playbook, a recent exercise result, selected metrics and a secured incident record. Assertions without those artifacts leave the self-assessment thin.

The boundary separates shared responsibilities

AICM's ownership model matters during incident reporting because several actors may hold different parts of the timeline. The application provider sees user interaction and application behavior. An orchestration provider may hold tool-call or retrieval traces. Model providers see service and model telemetry. Infrastructure evidence comes from the cloud provider. An AI customer may own the affected business process and notification duty.

DeepInspect's relevant boundary is narrower and explicit. It covers authenticated user or agent traffic deliberately routed through the HTTP proxy to an LLM endpoint and the response that returns through the same path. It can support evidence for identity, classification, route authorization, policy decision and request-response correlation.

Local process execution, STDIO transport, endpoint malware, stolen credentials used around the proxy, training-data poisoning inside a provider and direct traffic that bypasses the configured route sit outside that boundary. Customer communication, regulatory interpretation, root-cause ownership and the final decision to notify also remain human and organizational duties. The report should state those limits so an assessor can distinguish evidence coverage from incident coverage.

DeepInspect

DeepInspect sits inline on the authenticated HTTP path between users or agents and LLM APIs. For traffic deliberately routed through it, the policy decision can use application-supplied identity and role, content classification, model destination and route. Each decision creates a signed, tamper-evident record outside the calling application's write path.

During an AICM incident investigation, that record can establish which principal initiated a request, which model endpoint received it, which policy version applied and what decision occurred. It can also enforce a containment change, such as denying a destination or restricting a role, on subsequent routed requests. Host forensics, provider internals, offline model behavior and legal notification remain outside the product boundary.

Book a technical deep dive at deepinspect.ai.