Does COBIT prescribe one AI risk scoring method?

COBIT supplies governance and management objectives that an enterprise can tailor to its design factors and risk profile. The enterprise can use its established qualitative or quantitative method, provided the scale has defined criteria and produces consistent decisions. The important controls are the link to risk appetite, the scenario-level rationale, the treatment owner, and evidence supporting residual exposure. A five-by-five matrix can support that process. It cannot replace scenario analysis or control testing.

Which COBIT objective owns the AI risk assessment?

EDM03 directs risk optimization against enterprise appetite and tolerance. APO12 manages the operational risk process, including structured assessment and treatment. Other objectives contribute controls and assurance. DSS05 supports security services, APO14 covers managed data, BAI06 supports controlled changes, and MEA01 and MEA02 monitor performance and internal control. The accountable owner for a specific use case should still be named in the enterprise's governance structure.

Should the assessment score the vendor or the use case?

Score scenarios arising from the actual use case and route. Vendor evidence informs those scenarios, particularly provider access, retention, service security, deployment, and contract terms. The same provider can support a low-impact drafting use with public text and a high-impact workflow handling regulated records. One inherited vendor score hides that difference. Keep provider due diligence beside the use-case assessment and connect each relevant claim to the scenario it changes.

What evidence proves that a treatment operates?

Use artifacts produced by the control and its test. For a routed request, preserve identity, classification, destination, policy version, outcome, timestamp, and record integrity. Add a permitted request and a prohibited request using synthetic test data. Configuration exports, change approvals, access reviews, and provider documents can complete the package. A written policy describes intent. Operating evidence shows the control acted on a real decision path.

When should a COBIT AI risk assessment reopen?

Reopen it when the purpose, affected population, data class, retrieval source, connector, provider, model, route, retention, or downstream action changes. Reassessment also follows a control failure, policy exception pattern, incident, material provider change, or expired risk acceptance. Record those triggers when approving the use case so the product team can identify a governance event before production traffic changes.

COBIT AI Risk Assessment: Turn Scenarios into Owned Decisions

A COBIT AI risk assessment starts with a named use case and ends with an owned decision. Between those points, the team identifies plausible risk scenarios and evaluates impact and likelihood under existing controls. It then selects treatments and defines evidence that will show the treatment still works. A heat map merely displays the result after those decisions exist.

I want to walk through that operating sequence for an enterprise LLM route. The assessment covers an authenticated user or agent sending an HTTP request to an LLM endpoint, along with the returned response and the decision evidence created at that boundary.

TL;DR

EDM03 sets risk appetite and tolerance; APO12 turns that direction into scenarios and ratings, with responses assigned to named owners.
Assess the use case and request path, rather than assigning one inherited score to an LLM vendor.
A treatment needs an enforcement point, a test, retained evidence, an accountable owner, and a review trigger.
DeepInspect can enforce and evidence controls on deliberately routed HTTP AI traffic. Model training and endpoint compromise remain outside that boundary. Identity issuance and local execution also require other controls. Provider operations require separate evidence and controls.

COBIT frames risk as a governance decision

ISACA describes COBIT as a framework for governance and management of enterprise information and technology. Its current core model contains 40 governance and management objectives across five domains. The framework can be tailored to the enterprise instead of applied as a generic checklist.

The ISACA paper on COBIT and AI governance assigns distinct roles to two objectives. EDM03, Ensured Risk Optimization, aligns risk management with enterprise appetite and tolerance. APO12, Managed Risk, supports structured assessment and treatment of AI risk. That split gives the assessment an executive boundary and an operating method.

The risk committee should state which consequences require avoidance or reduction. It should also state which may be accepted by a named authority. APO12 then records the scenarios and analysis beneath those decisions. The COBIT AI compliance checklist tests whether those governance activities operate consistently. This guide focuses on the narrower assessment record for one LLM use case.

Scope begins with the use case and request path

Write the use case in operational terms. "Customer service uses an LLM" hides the affected people and data. It also hides actions and destinations. "Authenticated support agents summarize customer cases containing contact details through an approved model endpoint, with the summary returned to the case system" gives the assessor something concrete to test.

Map the HTTP path before scoring anything. Record the acting identity and role supplied by the application. Show the source systems and prompt assembly step. Name the provider and model, then record the endpoint and destination region. Add the response consumer and every retained copy. Include every downstream action in the same map. Mark the point where policy evaluates the request.

The whiteboard should show one box per system and one arrow per transfer. A red sticky note beside the model route marks the first place customer data leaves the application boundary. That small physical detail often settles an argument that a vendor-wide risk label leaves unresolved.

The COBIT AI controls mapping helps assign objectives to these components. The assessment has a different job: it decides which scenarios matter for this use and which treatments reduce them to an approved level.

Scenario statements connect causes with events and consequences

ISACA's AI governance paper groups example AI risk into five categories: ethical usage; policy and governance; technology and infrastructure; operational and organizational; and emerging and strategic risk. It also says the enterprise risk profile requires relevant scenarios, followed by impact and likelihood assessment in light of current mitigation controls. Those categories are prompts for analysis. They are not final risk entries.

A usable scenario begins with a cause and an event. In this case, the cause is an authenticated support agent including restricted customer data in a prompt assembled from the case system. The event occurs when the application routes that prompt to a model destination that lacks approval for the data class.

The consequence is an unauthorized disclosure that causes the enterprise to lose contractual control of the payload. The enterprise also lacks evidence of an approved policy decision.

Create separate scenarios for excessive agent authority and inaccurate output entering a customer record. Add prompt injection influencing a connected workflow and missing request evidence. Include model or provider change without reassessment. Each scenario needs its own consequence and owner. Some treatments can land with privacy or security. Others can land with product or procurement. Data governance may own another.

My view: a risk register entry called "LLM hallucination" should be rejected until the author names the business action that consumes the output and the person harmed when it is wrong.

Ratings must reflect current controls

Rate inherent exposure before considering controls, then evaluate residual exposure under controls that actually operate. The distinction matters because a policy document changes no request. An inline destination rule can change a request, provided the route is covered and the rule is tested.

For each scenario, document impact dimensions that fit the enterprise risk method. These may include customer harm; privacy or confidentiality loss; legal exposure; service interruption; financial loss; and decision integrity. Record likelihood assumptions and the evidence behind them. Keep unsupported percentages out of the rating. A qualitative scale can work when its definitions are concrete and reviewers apply them consistently.

The next step tests the current controls against these scenarios. A destination restriction needs configuration evidence and a denied request. For a data-class rule, preserve a seeded payload and the resulting classification. Human-review controls need a sampled approval with the reviewer identity and timestamp. Vendor terms need a current contract and the approved service configuration.

Ratings should change only when evidence shows that the control changes probability or consequence. A badge in the risk platform is an administrative state. It carries no control effect by itself.

Treatments need ownership, testing, and evidence

APO12 turns the scenario analysis into a response. A treatment may avoid the activity, reduce exposure, transfer a defined portion through contract or insurance, or accept the residual risk through the enterprise's authority model. The record should preserve the chosen response and the rejected alternatives.

For a routed LLM request, a reduction plan might require these elements:

application-supplied identity and role on every request;
prompt and response classification against approved data categories;
destination and model authorization tied to the use case;
an outcome that permits or redacts, with separate block and escalation paths before forwarding;
a versioned policy with a named owner and change record;
a signed decision record joined to the application transaction;
a permitted test and a prohibited test retained with the assessment.

DSS05, Managed Security Services, operates relevant security protections, while APO14, Managed Data, supports responsibilities for metadata and data quality. BAI06, Managed IT Changes, gives model and policy changes a controlled path. The ISACA paper connects those objectives to AI security and data governance, with change management providing the release discipline. One treatment can involve several owners, but each task and evidence artifact needs one accountable name.

Acceptance records make residual risk visible

Residual risk acceptance should identify the scenario and current rating. It should also name the treatment status and remaining exposure. Record the accepting authority and approval date. Add the expiry or review date. Add conditions that would void the acceptance, such as a new data class, a broader user population, a model destination change, or a new downstream decision.

The approval packet should include the request-flow diagram and scenario register. Add the rating rationale and control design. Test results and open remediation complete the packet. Include the vendor evidence that supports provider claims, while keeping that material separate from enterprise operating evidence. A SOC report can support provider due diligence. It cannot prove that a finance agent was authorized to send payroll data in a particular request.

The AI governance audit framework provides the wider evidence cadence. For this assessment, the test is reconstructability: another reviewer should be able to follow the scenario into the treatment, find the control, inspect its test, and identify the person who accepted what remained.

MEA monitoring keeps the assessment current

MEA01, Managed Performance and Conformance Monitoring, supports monitoring targets for AI performance. MEA02, Managed System of Internal Control, checks that security and compliance controls remain embedded and supports corrective action. Use those objectives to define the life of the assessment after approval.

Choose indicators tied to the scenarios. Track requests blocked by data class and destination, but also sample permitted requests for correct identity and policy version. Measure policy exceptions and expired acceptances. Review classification errors, route bypasses, model changes, and incidents linked to the use case. A volume chart alone says little about control quality.

Define event-based reassessment triggers in the approval. A new connector or retrieval source changes the data path. A new provider changes the destination and contract. Expanded agent authority changes consequence. A material model update can change output behavior. A policy revision changes the decision basis. Each trigger should open a review before the changed path enters production.

The assessment also needs a calendar review because quiet systems still drift. MEA02 sampling can compare live configuration and decision records with the approved design. Findings return to APO12 for treatment and to EDM03 when the exposure challenges risk appetite.

The HTTP boundary limits the control claim

This assessment includes traffic deliberately routed over HTTP between authenticated users or agents and LLM endpoints. The application supplies identity and relevant workflow context. An inline policy layer can inspect the request and response, evaluate the model destination, enforce a decision, and create an independent record for that route.

Several exposures require controls elsewhere. Identity proofing and credential issuance belong to IAM. Endpoint compromise belongs to endpoint and application security. Local model execution and STDIO tool calls bypass the HTTP route. Provider training and model development require provider evidence. Internal operations require provider evidence too. Direct requests that bypass the gateway require network or application records. Provider records may also be needed. Output truth and business-process review remain with the consuming workflow.

State those exclusions inside the risk record. Their presence prevents an inline control from receiving credit for risk reduction beyond its actual reach. The wider COBIT governance system still assigns owners to the excluded scenarios.

DeepInspect

DeepInspect sits inline on deliberately routed HTTP traffic between authenticated users or agents and LLM endpoints. It evaluates application-supplied identity and role with content classification, model destination, and versioned organizational policy. It can permit, redact, block, or escalate before the request reaches the model.

Each decision creates a signed, tamper-evident record outside the calling application's write path. That record can support the treatment test for a routed scenario and give MEA02 a stable artifact to sample. DeepInspect leaves risk appetite, scenario ownership, residual acceptance, vendor review, and business-impact analysis with the enterprise. It also leaves identity issuance, local execution, provider operations, and downstream output decisions outside its enforcement boundary.

Book a technical deep dive at deepinspect.ai.