COBIT AI Incident Reporting: The Operating Chain Behind One Alert

A blocked prompt becomes a COBIT incident only after somebody classifies it and assigns an owner. The same process preserves the decision record and closes the case against a stated acceptance test. The gateway event is the trigger. The incident process is the operating chain around it.

That distinction matters for COBIT AI incident reporting. ISACA describes COBIT 2019 as a framework for governance and management of enterprise information and technology, built around 40 governance and management objectives. It supplies the accountability and control structure behind incident handling. A statutory breach clock still comes from the applicable law and contract. The same applies to a regulator notice or customer disclosure.

TL;DR

• EDM03 and APO12 set the risk threshold that turns an AI traffic event into an incident requiring ownership and response.
• DSS02 carries the case through classification and investigation. It also carries containment and recovery, followed by closure and the service-desk record.
• DSS05 operates the security controls that detect or stop a routed request. MEA01 and MEA02 test performance and control effectiveness over time.
• DeepInspect contributes identity-bound evidence for deliberately routed HTTP requests and responses. The incident commander retains the wider case and every external reporting decision.

COBIT assigns the chain rather than the disclosure clock

ISACA's 2025 COBIT and AI paper applies the COBIT core model across AI design and deployment, followed by operations and monitoring. Its core-model figure names DSS02 as Managed Service Requests and Incidents and DSS05 as Managed Security Services. MEA01 appears separately as Managed Performance and Conformance Monitoring, with the paper connecting that objective to defined monitoring targets for AI performance.

Those objectives solve different parts of one incident. EDM03, Ensured Risk Optimization, establishes risk appetite. APO12, Managed Risk, turns that appetite into assessment and response rules. DSS05 runs the protective service, while DSS02 owns the operational case. MEA01 measures performance and conformance. MEA02, Managed System of Internal Control, checks that the control remains embedded and effective.

My view: calling a blocked prompt an "incident report" before DSS02 has an owner and a closure criterion is governance theatre. It is an event with a red badge.

The DSS02 case begins with a classified event

Take one authenticated finance agent sending an HTTPS POST to an approved LLM endpoint. The application supplies the agent identity and role. An inline control classifies the prompt as containing payroll data and compares the destination against version 42 of policy. It blocks the transmission and writes a signed event at 14:07:33 UTC.

DSS02 starts when the service operation converts that event into a managed case. The case needs an impact class and a priority. It also needs a named owner and an investigation path. The closure decision must be documented. A red row in a gray SIEM timeline is the concrete starting point. The service desk record is the work queue that follows.

The COBIT AI compliance checklist asks whether those operating controls run consistently. This incident-reporting view goes deeper into the handoff after one control fires. It identifies who accepts the alert and which evidence travels with it. It also identifies which finding returns to governance.

DSS05 contains the request at the HTTP boundary

DSS05 owns the managed security service that detects and responds on the controlled route. For authenticated HTTP AI traffic, that can mean blocking a prompt containing restricted data or redacting a matched field. It can also mean denying an unapproved model destination or requiring an escalation decision before forwarding. Each action occurs before the LLM receives the routed payload.

The containment record should preserve eight fields:

• event and correlation identifiers;
• UTC request and response timestamps;
• authenticated user or agent identity supplied by the application;
• role and workflow context used by policy;
• prompt and response classification results;
• provider and model; endpoint and destination region;
• policy version plus the outcome. The outcome is permit, redact, block, or escalation;
• signature and storage location. The record must also preserve the linked DSS02 case identifier.

The COBIT AI controls mapping maps objectives to enforcement points. Incident governance begins one step later. DSS05 produces the security action and its event; DSS02 accepts that event into an accountable process.

EDM03 and APO12 decide when escalation is mandatory

Every blocked request carries different consequences. A test account sending synthetic text to an unapproved model may remain a low-priority service event. A payroll agent attempting to send employee bank details to that same destination can cross the enterprise's risk threshold and require an incident commander and privacy review. Executive notification can also be required.

EDM03 should define the risk appetite behind that distinction. APO12 should express it as operational criteria that the intake team can apply without assembling an emergency committee for each alert. Criteria can include data class and identity type. They can also cover model destination and control outcome. Recurrence count and the affected business process provide further criteria. Evidence that any payload reached the provider completes the assessment.

A clean escalation rule states who receives the case and the decision deadline. The rule also records the reason when an event remains below threshold. That negative decision matters because MEA02 later needs to test consistent classification across similar cases.

Evidence handoffs keep the incident reconstructable

ISACA's guidance on evaluating security incident management programs calls out program design and tools and technologies as assurance areas. It also covers reporting practices and lessons learned. For an AI request incident, each area needs a visible evidence handoff rather than a screenshot pasted into a ticket.

Four handoffs make the chain reconstructable:

• Gateway output sends the signed decision event and correlation identifier to the SIEM or event bus.
• SIEM intake creates or enriches the DSS02 case without replacing the original evidence object.
• Incident ownership records impact and containment in the case system. It also records recovery and external-notification decisions.
• Closure review returns confirmed control gaps and policy changes to APO12 and DSS05 owners. It also returns them to MEA01 or MEA02 owners, along with monitoring actions.

The COBIT AI audit-evidence guide covers the artifacts an assessor requests across the framework. Here, the narrow evidence test is continuity. One identifier must connect the routed request and security decision to the incident case and approval history. It must also connect the closure record without relying on timestamps alone.

MEA01 measures response performance and recurrence

MEA01 turns incident handling into a monitored process. Useful measures include alert-to-ticket latency and the owner-assignment interval. The containment interval and evidence completeness provide further measures. Recurrence by policy version and the reopening rate complete the measure set. Each metric needs a target and an owner.

A monthly count of blocked prompts gives volume without showing process quality. Pair the count with the percentage that received the correct severity and the percentage closed with a verified evidence chain. Track the number recurring after a policy change separately. MEA02 then tests samples against the defined intake rule and closure standard.

Closure requires evidence that the immediate route is controlled and the cause has an assigned treatment. Each policy change must carry a new version. A mistaken classification needs a documented tuning decision. Traffic that bypassed the gateway belongs with the network or application owner because the gateway never observed it.

The authenticated HTTP boundary is explicit

This COBIT application covers AI requests and responses deliberately routed over HTTP between an authenticated user or agent and an LLM endpoint. The application supplies identity and relevant workflow context. The inline layer can classify content and evaluate destination and model authorization. It can also enforce versioned policy and produce a signed decision event.

Local model execution and STDIO tool calls sit outside that boundary. Endpoint compromise and identity issuance also sit outside it. The same applies to provider-internal processing. Direct calls that bypass the proxy also sit beyond its visibility. DSS02 still owns the wider incident, but evidence for those paths must come from endpoint and IAM systems. It may also come from application, provider, or forensic systems.

That boundary keeps the report honest. A DeepInspect event can establish what happened on a routed request and which control decision occurred. Full blast-radius analysis and legal-notification decisions require evidence and judgment elsewhere. The same applies to provider activity on another path.

DeepInspect

DeepInspect sits inline on authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates application-supplied identity and role together with content classification and destination. It also evaluates model authorization and versioned policy. It can permit, redact, block, or escalate a request and write a signed, tamper-evident decision record before forwarding permitted traffic.

That record gives DSS05 a containment event and gives DSS02 a stable evidence object to attach to the case. Security operations can pass the correlation identifier into a SIEM or service desk. They can preserve the original record and join later investigation and closure decisions to the exact policy state that handled the request. DeepInspect remains one evidence producer inside the COBIT operating chain. Incident ownership and recovery stay with the enterprise, as do legal analysis and regulator reporting. Book a technical deep dive at deepinspect.ai.