Which COBIT objectives matter most for AI?

APO12 on risk, APO13 and APO14 on security and data, DSS06 on business process traceability, and MEA04 on assurance independence carry the weight for AI traffic. EDM01 and EDM03 sit above them and get graded on whether the management objectives below actually produced evidence, so a weak DSS06 record pulls the governance domain down with it.

Does COBIT require an AI-specific control set?

No. ISACA's 2025 white paper applies the existing 40 objectives across the AI lifecycle rather than adding new ones. The practical consequence is that AI controls have to produce the same class of work product COBIT expects from any technology process, which means measured outputs and independently held records instead of approved documents.

How does this mapping relate to ISO 42001 Annex A?

They ask for overlapping artifacts from different angles. ISO 42001 Annex A controls describe an AI management system, while COBIT grades the capability of the enterprise processes running it. Identity-bound request records with prompt classification and independently written logs satisfy the evidence expectations of both.

Do these controls require changing the model?

They operate at the HTTP boundary between the application and the model endpoint, so they are model-agnostic and require no retraining or vendor-specific integration. The application keeps supplying identity context, which is its role in any identity-aware design, while classification, routing, enforcement, and recording happen in the request path.

What does BAI06 change control mean for a model upgrade?

Repointing a route from one model version to another changes the behavior of a production decision path, so it falls inside managed change. The practical requirement is that the active model and policy version is stamped onto every decision record, so a later review can reconstruct which configuration handled a specific request rather than which configuration is live today.

COBIT AI Controls Mapping: 40 Objectives Against One HTTPS Request

ISACA extended COBIT to AI systems in a 2025 white paper without writing a single new objective. The framework's existing 40 governance and management objectives already cover the questions an AI programme raises, because each one attaches to a management practice rather than to a technology. That design decision is why a COBIT assessment of an AI programme lands differently from a framework built for AI: the auditor arrives with the same capability scale, the same evidence expectations, and no willingness to grade intent.

Most COBIT-to-AI work I see stops at the mapping table in a governance deck. The objective gets a row, the row gets an owner, and the control column reads "AI usage policy approved by the AI governance committee." What goes unwritten is the enforcement point, meaning the specific moment in the request path where the control either fires or fails to. I want to set that out objective by objective.

The control point: one HTTPS request

Every mapping below resolves to the same moment. An application assembles a context window and sends an HTTPS POST to a model endpoint. At that instant, the caller's identity is knowable, the classification of the payload is evaluable, the destination is selectable, and a decision is either recorded or lost. A control that lives only in a committee charter describes the objective without enforcing it.

EDM01 and EDM03: governance framework and risk optimization

EDM01, Ensured Governance Framework Setting and Maintenance, requires the board to establish a governance system and keep it current. EDM03, Ensured Risk Optimization, requires risk appetite to be defined and actual risk to be held inside it. The control is a policy decision point evaluating every AI request against the stated appetite, with a fail-closed default on ambiguity. The evidence is the per-request policy decision record, which is what turns an approved appetite statement into something a board can monitor.

APO12: managed risk

APO12 requires risk to be collected, analyzed, held in a profile, and responded to. For AI traffic the control is continuous measurement at the boundary: counts of requests by classification, by role, and by destination, plus the rate at which policy blocked a transmission. The evidence is a measured residual position rather than a workshop rating, and it feeds the same numbers an AI risk assessment template asks a team to justify.

APO13 and APO14: security and data management

APO13 covers the information security management system, and APO14 covers data classification and lifecycle. AI traffic collapses both into the context window, because a prompt assembles fragments from several stores into a payload that no catalogue ever classified as a unit. The control is prompt-level classification evaluated before transmission, tied to per-role policy. The evidence is a per-request classification decision, produced by prompt-level DLP rather than by a document label inherited from a source system.

DSS05 and DSS06: security services and business process controls

DSS05 covers running security services. DSS06 covers ownership, execution, and traceability of controls embedded in business processes, and traceability is the demanding word. A business process that routes a decision through a model needs a per-transaction link from the named person or agent to the AI call that shaped the outcome.

Shared service credentials break that link. The application authenticates the user, then calls the model with one API key that carries no user context, so the traceability DSS06 requires ends one layer before the data leaves. The control is identity binding at the request boundary, described in identity-aware AI gateway architecture, and the evidence is an identity-bound request record.

BAI06 and BAI10: change and configuration

BAI06, Managed IT Changes, and BAI10, Managed Configuration, apply to AI in a way teams routinely miss. Swapping a model version, changing a system prompt, or repointing a route to a different provider each alter the behavior of a production decision path. The control is versioned policy and route configuration with the active version stamped onto every decision record. The evidence is a configuration history that can be joined to traffic, so a reviewer can answer which model and which policy handled a request on a given afternoon.

MEA02, MEA03 and MEA04: monitoring, compliance and assurance

Internal control monitoring sits in MEA02, external obligation compliance in MEA03, and assurance planning with independence in MEA04. Independence is the objective that governs how every other artifact gets read. An audit record written by the application making the AI call is a self-attestation, so the control is write-path independence: the record is produced by a system the application has no custody over. The evidence is an externally written, signed log, and the reasoning behind it is set out in AI audit log immutability.

The mapping at a glance

Capability level is the real output

COBIT grades each objective 0 to 5, and level 3 is where most internal audit functions set the bar for regulated technology processes. Level 3 asks for a defined process producing documented work products on every run. An AI governance committee that meets monthly and approves a policy earns level 1 for EDM01, because the process exists without managed outputs. Attaching the evidence column above moves the same objective to a defensible level 3 with nothing else changing.

My frank opinion: the mapping table is the least valuable artifact any AI governance programme produces, and it is the one that gets the most attention, because it can be finished in an afternoon and it looks finished. The enforcement column takes a quarter and it is the only column an auditor tests.

DeepInspect

Each row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call, evaluates identity, classification, and destination on every request, enforces per-role and per-route policy with a fail-closed default, and writes a signed record of the decision before the response returns. The COBIT mapping stops being a governance deck and becomes a running control with evidence attached.

For an internal audit function grading an AI programme against DSS06 traceability and MEA04 independence, that means each objective has a per-decision record standing behind it. The COBIT AI audit evidence view covers what each artifact looks like under review. Book a technical deep dive at deepinspect.ai.