Does COBIT have AI-specific controls?

COBIT 2019 contains no AI-specific objectives. ISACA's 2025 white paper on COBIT and AI system governance applies the existing 40 objectives across the AI lifecycle rather than adding new ones, which is why the evidence a COBIT assessment requests for AI looks like the evidence it requests for any other technology process: identity, classification, policy state, and an independently written record.

What capability level should an AI process reach?

Most internal audit functions target level 3, the established process level, for technology processes carrying regulated data. Level 3 requires a defined process that is performed consistently and produces documented work products. An AI usage policy with no per-request enforcement record typically grades at level 1, because the process runs without managed outputs.

How does COBIT relate to ISO 42001 and the NIST AI RMF?

COBIT governs the enterprise technology function and grades process capability. ISO/IEC 42001 certifies an AI management system, and the NIST AI RMF structures risk activity into Govern, Map, Measure, and Manage. The three ask for overlapping artifacts, and identity-bound request records with prompt classification satisfy all three, as the ISO 42001 audit evidence view sets out.

Do vendor dashboards count as COBIT evidence?

Model provider dashboards report the provider's view of API consumption. They carry no identity context from your directory, no record of your policy decisions, and they sit outside your custody, so they fail the MEA04 independence test and the DSS06 traceability requirement. The record has to exist on your side of the boundary.

Where do most AI programmes lose points?

APO12 and MEA04. Risk ratings arrive from workshops rather than from measured traffic, and the audit log is written by the application under review. Both gaps close at the same place, which is the request boundary between the application and the model endpoint.

COBIT AI Audit Evidence: What an ISACA-Aligned Review Asks You to Produce

COBIT 2019 organizes 40 governance and management objectives into five domains: Evaluate, Direct and Monitor (EDM) for board-level governance, then Align, Plan and Organize (APO), Build, Acquire and Implement (BAI), Deliver, Service and Support (DSS), and Monitor, Evaluate and Assess (MEA) for management. ISACA published a white paper in 2025 applying that structure to AI system governance, and internal audit functions have started running AI programmes against it.

A COBIT audit is not a document review in the way most teams expect. The framework grades process capability on a 0 to 5 scale, and capability above level 2 requires evidence that the process ran, produced outputs, and was measured. I want to walk what a reviewer actually asks for when the process in question is an AI request leaving your network, because the gap between a written AI policy and a graded COBIT process is where most programmes stall at level 1.

The governance record (EDM01 and EDM03)

EDM01, Ensured Governance Framework Setting and Maintenance, asks whether the board has established a governance system and whether that system operates. EDM03, Ensured Risk Optimization, asks whether risk appetite is defined and whether actual risk stays inside it. For AI traffic, a reviewer reads the AI usage policy, then asks for the record proving the enforced behavior matched the stated appetite.

The artifact is a per-request log showing which policy was in force at the moment of each AI call and what it decided. An approved policy document with no enforcement record scores as a directed control with no monitoring evidence, which caps EDM03 at capability level 1.

The risk record (APO12)

APO12, Managed Risk, requires that risk is collected, analyzed, maintained in a risk profile, and responded to. AI risk registers I have reviewed usually list prompt injection, data exposure, and model unavailability, each with a residual rating assigned in a workshop.

The reviewer's follow-up is the one that hurts: show me the data behind the residual rating. That means counts of blocked requests by classification, the rate at which sensitive data reached the context window, and the model endpoints actually called during the period. A residual risk rating produced by consensus rather than by measurement fails the APO12 evidence test.

The security and data records (APO13, APO14)

APO13, Managed Security, covers the information security management system. APO14, Managed Data, covers data quality, classification, and lifecycle management. When AI enters the picture, these two collide at one point: the context window.

A reviewer asks for the classification decision applied to prompt content before transmission. Document-level classification in the data catalogue answers a different question, because the prompt assembles fragments from several sources into a payload nobody classified as a unit. Prompt-level DLP is the control that produces the APO14 artifact for AI traffic.

The operational control record (DSS05, DSS06)

DSS05, Managed Security Services, and DSS06, Managed Business Process Controls, are where COBIT asks about running operations. DSS06 specifically covers the ownership, execution, and traceability of controls embedded in business processes.

For an AI-assisted process, traceability means a per-transaction record tying the person or agent to the AI call that shaped the outcome. Most deployments break the chain here, because the application authenticates the user and then calls the model with one shared service credential. The identity DSS06 traceability depends on gets dropped one layer before the request leaves, which is the post-authentication gap in COBIT language.

The assurance record (MEA02, MEA03, MEA04)

MEA02, Managed System of Internal Control, asks whether controls are monitored and deficiencies reported. Under MEA03, Managed Compliance With External Requirements, the question shifts to whether external obligations are identified and satisfied. Planning, scoping, and independence of assurance activity belong to MEA04.

MEA04 independence is the objective that decides how the other artifacts are read. An audit log written by the same application that made the AI call is an attestation by the party under review. That record breaks in three ways: the application records its successes and misses its edge-case failures, the log can be modified by the system that failed, and a crash between the model response and the log commit leaves the action taken with the evidence gone. I set this out in You Own the AI Liability, Not the Vendor, and it is the same independence argument behind AI audit log immutability.

What a level 3 AI process actually needs

My candid view: COBIT is the least fashionable framework in the AI governance conversation and the most honest one, because it grades capability on evidence and refuses to award credit for intent. An ISO 42001 certificate and a COBIT level 1 rating can coexist in the same organization, and I have watched that combination surprise a CISO in the same meeting.

DeepInspect

This is the evidence layer a COBIT assessment reaches for and rarely finds. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request it evaluates identity, data classification, and destination, enforces per-role and per-route policy, then writes a signed, tamper-evident record before the response returns. The record holds the caller, the classification in the prompt, the model endpoint, the policy decision, and the outcome.

When internal audit asks for the DSS06 traceability record or the MEA04 independent log, the answer is a query against records the application never had custody of. The COBIT AI controls mapping shows how each objective lines up with an enforcement point, and the COBIT AI compliance checklist turns that into a sequence of actions. Book a technical deep dive at deepinspect.ai.