13 ISO 42001 Controls Every AI Governance Program Needs

The first ISO 42001 control is scope. The organization must know which AI systems, departments, workflows, providers, data classes, and environments the AI management system covers. Without scope, every control becomes debatable. A team can always claim a risky workflow was outside the program, and auditors will struggle to understand the boundary.

A strong scope control includes an approved scope statement, exclusion rules, change triggers, and a review cadence. It should describe employee chat, copilots, APIs, agents, RAG systems, vendor AI features, and internal tools in plain language. Exclusions should be explicit and controlled. If a sandbox is out of scope, it still needs boundaries that prevent regulated data, customer records, secrets, or production access from entering it.

The test is simple: an auditor should be able to pick a workflow and determine whether it is inside the management system within minutes. If the answer depends on hallway interpretation, the scope control is not mature enough.

The practical evidence is a scope statement with version history, approval, exclusions, and change logs. When a new copilot, model API, agent, or vendor AI feature appears, the scope owner should either bring it into the management system or record why it remains outside with compensating boundaries.

Scope control also needs a discovery mechanism. Procurement intake, software approval, cloud deployment, API key requests, and usage telemetry should all feed the same scope decision process. Otherwise the scope statement will be tidy on paper while new AI activity appears through side doors.

The most useful scope test is traceability. Select a new AI workflow from the last quarter and confirm that it entered the scope process, received a decision, and either joined the inventory or received a documented exclusion. If that trace does not exist, the scope control is reactive rather than operating.

Scope evidence should be reviewed whenever business structure changes. A new subsidiary, product line, region, or customer segment can change which AI workflows matter. If the scope is not updated after those changes, the AI management system may certify a boundary that no longer reflects the operating business.

An AI inventory control keeps the program anchored in real systems. Every material AI workflow should have a record with owner, purpose, users, model, data inputs, output use, risk tier, controls, supplier, region, retention, and evidence source. The inventory should include formal applications and informal tools that became part of work.

The control should define how new AI workflows enter the inventory. Procurement intake, API key creation, new RAG deployments, copilot rollouts, and agent pilots should all trigger inventory updates. If the inventory is updated only before an audit, it is not a control. It is a reconstruction exercise.

Inventory records should also have a freshness signal. A workflow that has not been reviewed since the model, supplier, data source, or owner changed should be marked stale. Staleness is often where audit findings begin.

The inventory should be usable by business teams, not just auditors. A good record tells an employee which workflow is approved, what data can be used, who owns the workflow, and where to request a change. That visibility turns inventory from a compliance artifact into the operating map for AI adoption.

Inventory control should define minimum viable fields. At a minimum, capture owner, purpose, users, model route, data class, supplier, risk tier, control set, review date, and evidence source. Optional fields can mature later, but missing owner or data-class information makes the inventory hard to use.

Strong inventories reconcile top-down and bottom-up signals. A procurement list shows purchased AI tools. Logs show actual model usage. Department interviews show informal workflows. The control should specify how discrepancies are resolved, because those gaps are where unmanaged AI often hides.

The inventory control should also feed employee enablement. When the approved record is visible, teams can find sanctioned workflows instead of creating duplicates. A hidden inventory satisfies an auditor for a moment but does little to move employees away from unapproved tools.

Risk tiering turns inventory into action. ISO 42001 programs need a repeatable way to distinguish low-risk drafting from high-impact workflows that affect customers, employees, regulated data, legal commitments, financial reporting, or security decisions. A simple low, medium, high, and restricted model is enough if each tier changes required controls.

The tiering control should document criteria and outcomes. Criteria may include data sensitivity, automation level, external exposure, tool access, affected groups, reliance on output, and reversibility of harm. Outcomes should include model restrictions, redaction requirements, human review, supplier review, monitoring, and management review.

The program should keep examples for each tier. Examples prevent teams from debating every workflow from scratch and help new business owners classify AI use consistently.

The evidence should show both the original tiering decision and later changes. If a workflow starts as internal drafting and later writes to customer systems or uses restricted data, the tier should change and the control record should explain why.

Risk tiering should include clear disqualifiers. For example, a workflow that handles secrets, regulated records, employment decisions, or autonomous external actions should not remain low risk because the business owner says the use case is simple. Disqualifiers prevent optimistic scoring from weakening the program.

The tiering control should also capture residual risk acceptance. If a high-risk workflow proceeds because business value is high and controls are in place, the record should identify who accepted remaining risk, when they accepted it, and when the decision must be reviewed.

Tiering should be recalibrated with incident and exception data. If medium-risk workflows repeatedly create incidents, the criteria may be too permissive. If low-risk workflows constantly request exceptions, the categories may not match real business use. The control should improve as evidence accumulates.

AI data protection controls should cover prompts, file uploads, retrieved context, API payloads, logs, and model outputs. Many AI failures begin when employees give models too much context. The control should define allowed data classes, restricted data classes, redaction rules, blocked data, approved model routes, and exception paths.

This control is stronger when enforced inline. Sensitive data protection can detect customer records, regulated data, secrets, source code, and confidential content before it reaches an AI model. Evidence should show what was detected, what action was taken, and which workflow or model route was involved.

Data protection should cover both input and output. The prompt may be safe, but the generated answer may reveal retrieved content, summarize confidential files, or combine facts in a way that needs review before use.

The control should also define logging boundaries. Full prompt capture may be necessary for some investigations, but it can create a sensitive repository if access and retention are weak. Strong programs store enough evidence to prove control operation while protecting the content that evidence describes.

Data protection rules should be expressed as actions, not slogans. Public content may be allowed. Confidential business data may require approved routes. Customer data may require redaction or restricted models. Secrets should be blocked. Legal material may require review before output leaves the workflow. Employees need those decisions in the product experience, not buried in a policy PDF.

The control should be tested with realistic samples. Use representative prompts, files, code snippets, customer records, and retrieved documents to confirm detection, redaction, blocking, logging, and exception handling. Synthetic tests alone are useful, but real workflow samples reveal formatting and context patterns that simple test strings miss.

Data protection should also include exception handling. If a legitimate workflow needs restricted data, the organization should provide a controlled route rather than forcing users to bypass policy. Exceptions should be approved, logged, time-bound, and tied to compensating controls.

Model access should not be a free-for-all. Different models have different capabilities, costs, retention terms, regions, and risk profiles. ISO 42001 programs need a control that defines which models are approved, which are conditional, which are pilot-only, and which are blocked.

The model access control should connect to identity and workflow. A finance team may have access to a stronger analysis model in an approved workspace. A public marketing workflow may use a cheaper model. A restricted data workflow may require a private deployment or special route. Model governance makes those choices explicit instead of hiding them in prompts or application code.

Model access should also define fallback rules. If a preferred model is unavailable, the workflow should not silently route sensitive content to an unapproved model.

Evidence should include who can use each model, which workflow selected it, what policy allowed the route, and whether any override occurred. This is especially important when teams use multiple frontier models, private deployments, and lower-cost models in the same environment.

The model control should separate capability, cost, and data risk. A more capable model may be appropriate for legal analysis but unnecessary for routine drafting. A cheaper model may be fine for public content but unacceptable for confidential data if retention or region terms are weaker. Model approval should therefore be workflow-specific, not a blanket yes or no.

Version changes deserve the same attention. If a provider releases a new model version, changes default behavior, or deprecates an old route, the control should show who reviewed the change and whether testing, prompts, retrieval settings, or human-review rules need updates.

Model access should include budget constraints when cost affects behavior. If users can select expensive models without reason, spending can hide poor workflow design. A strong control routes work to the right model for risk, quality, and cost rather than treating all model access as equal.

Human oversight should be defined by workflow, not as a generic principle. The control should say which outputs require review, who reviews them, what they check, how approval is captured, and when the output can be exported or used externally. This matters for legal, HR, finance, customer, security, and regulated workflows.

Evidence should include reviewer identity, decision, timestamp, output version, and escalation if rejected. The goal is not to slow every AI output. It is to make high-stakes review visible and testable. A reviewer who merely exists in a policy document does not satisfy the operating need.

Oversight should be calibrated. Low-risk brainstorming may need no approval, while customer commitments or regulated decisions need a stronger review gate. Over-review creates workarounds; under-review creates exposure.

The review should also be meaningful. A checkbox that says "reviewed" is weak if the reviewer cannot see sources, model context, edits, or final output. For high-stakes workflows, the control should preserve the review trail and the version that was approved.

Human oversight should include escalation criteria. A reviewer should know when to approve, edit, reject, escalate to legal, open an incident, or request additional source material. Without escalation rules, reviewers may silently fix outputs that indicate deeper control failures.

The oversight control should be sampled for quality, not only existence. Pick approved outputs and confirm the reviewer had enough context, the decision matched the rule, and the final content did not bypass required review. This keeps oversight from becoming a ceremonial gate.

Oversight rules should be embedded close to the point of use. A separate spreadsheet of approvals is weaker than a workflow that routes output to the reviewer, records the decision, and blocks export until review completes. The more frictionless the review path, the more likely teams will follow it.

Important prompts should not live only in personal notebooks or chat threads. A prompt and template control defines how repeatable AI work becomes an approved workflow. It should cover purpose, required inputs, output format, data rules, model route, owner, review requirement, testing, version history, and retirement.

This control is especially useful for common enterprise tasks: contract summaries, customer replies, meeting summaries, support triage, finance analysis, policy Q&A, and code review. Templates reduce variation and make AI behavior easier to test. They also let teams attach controls directly to the workflow instead of hoping every user remembers the right prompt.

Templates should have lifecycle states. Draft, pilot, approved, deprecated, and retired states keep old prompts from drifting into daily use after the risk assumptions have changed.

Treat template changes like product changes. If a prompt now retrieves more documents, calls a tool, changes tone for customer responses, or removes a review step, the update should trigger testing and owner approval before users rely on it.

Template controls should include test cases. A contract-summary template might be tested against missing clauses, conflicting terms, and confidential data. A customer-reply template might be tested for hallucinated commitments, tone, and unsupported claims. A code-assistance workflow might be tested for secrets, licensing risk, and unsafe recommendations.

Retirement matters as much as approval. If an old prompt template remains visible after risk assumptions change, users will continue to copy it. The control should hide deprecated templates, redirect users to replacements, and record when retirement was completed.

Template control should include ownership of examples and source material. A prompt that depends on stale policy text or outdated product claims can produce poor output even if the wording is approved. The owner should maintain the context, test cases, and sample outputs along with the prompt itself.

AI supplier controls should cover model providers, SaaS copilots, data processors, vector databases, agent platforms, evaluation tools, and workflow vendors. The control should evaluate data handling, retention, training use, regions, security commitments, sub-processors, incident notice, and contractual restrictions.

The supplier record should connect to the inventory. If a workflow uses a vendor model or embedded AI feature, the team should know which supplier review applies and which data classes are allowed. Supplier approval without workflow mapping creates false confidence because the same vendor may be safe for one use case and unsafe for another.

Supplier controls should include change monitoring. Model terms, regions, sub-processors, and retention options can change after approval, and the AI management system needs a way to respond.

The supplier control should also define exit paths. If a provider changes terms or fails a review, the organization should know which workflows depend on it, which data is involved, and what replacement route or pause process is available.

Supplier evidence should be reusable. Security, legal, privacy, procurement, and business owners should not repeat the same vendor questions for every department. A central record should show approved use cases, prohibited data classes, contractual limits, renewal dates, and review status.

The supplier control should also monitor embedded AI. Existing SaaS platforms increasingly add AI features after purchase. A feature that summarizes meetings, searches documents, or generates emails may change the data path even if the vendor contract has not changed.

Supplier controls should define review depth by risk. A public-content writing tool may need a light review. A provider that processes customer records, source code, or regulated data needs deeper security, privacy, contractual, and operational evidence. One uniform questionnaire wastes time and misses nuance.

AI incident response should cover sensitive-data exposure, unauthorized model use, unsafe output, prompt injection, tool misuse, unexpected retrieval, supplier changes, and control failures. The control should define severity levels, intake channels, owners, evidence requirements, containment steps, notification paths, and closure criteria.

Incident response should also produce improvement. If an event shows that a team lacks a safe workflow, build one. If a prompt injection attempt reveals tool permissions are too broad, reduce them. If a supplier change affects retention or region terms, update the route. ISO 42001 programs should learn from events rather than treating them as isolated tickets.

The incident record should link to corrective actions. Auditors often care less that an issue occurred and more that the organization contained it, understood it, and improved the control set.

AI incidents should be rehearsed before a live event. A tabletop for a leaked prompt, unsafe autonomous action, or prompt injection event will usually expose missing owners, unclear evidence access, and weak communications long before the external audit does.

The incident control should define severity with AI-specific factors: data sensitivity, vendor status, retention, output distribution, automation level, affected people, and whether downstream systems were changed. A prompt containing public copy and a prompt containing employee medical data should not follow the same path.

Closure should produce evidence of improvement. If an incident exposed a missing redaction rule, weak permission, unsafe template, or unclear supplier term, the corrective action should be linked to the event. That link shows that the management system learns from operational reality.

Incident response should include communications rules. Employees need to know what to stop, what safer route to use, and where to report related events. Leaders need concise facts and uncertainty. Legal and privacy teams need enough detail to assess obligations without delaying containment.

Exceptions are inevitable. A team may need a new model, a different region, temporary access, broader context, or a higher budget. The exception control should make those requests time-bound, owned, reviewed, and visible. It should document business reason, risk, compensating controls, approver, expiration, and follow-up.

Uncontrolled exceptions become hidden policy. If a temporary approval never expires, it becomes the real operating model. Good exception controls make flexibility possible without weakening the AI management system. They also show auditors that the organization can handle business needs without abandoning control.

Exception metrics should be reviewed monthly. Aging exceptions, repeat requests, and expired approvals are signals that the standard control either needs redesign or needs stronger enforcement.

The best exception process is fast enough that employees use it. If the process takes weeks for a low-risk request, teams will route around it. Give common exception types standard evidence, standard approvers, and clear expiration rules.

Exception control should include compensating controls. A team might receive temporary access to a stronger model only for sanitized data, named users, and a defined project. A supplier exception might require additional review, restricted uploads, or shorter retention. The exception record should explain why the residual risk is acceptable.

Repeated exceptions are a design signal. If many teams ask for the same exception, either the standard control is too restrictive or the organization lacks an approved workflow for a real business need. Reviewing exception patterns helps improve the control set.

Exception evidence should show closure, not just approval. At expiration, the record should show whether access was removed, the exception was extended, the workflow was redesigned, or the exception became a standard approved path. Open-ended exceptions become unmanaged policy.

Monitoring should show whether controls operate and whether AI usage is creating value. Useful metrics include approved workflow adoption, policy blocks, redaction events, model route changes, high-risk usage, exceptions, incident trends, review failures, budget variance, and stale inventory records.

Metrics should be reviewed by the owners who can act. Security needs data protection trends. Finance needs spend and model routing. Legal needs high-stakes output review. Business owners need adoption and workflow quality. Usage analytics helps turn AI management from annual documentation into continuous operation.

The program should distinguish health metrics from vanity metrics. Prompt volume alone does not prove safe adoption. A better metric shows whether approved workflows are replacing risky behavior while incidents and exceptions trend down.

Metrics should also drive decisions. If sensitive-data blocks are concentrated in one department, the program may need a safer workflow there. If a model route is expensive but rarely used, it may need access changes, training, or retirement.

Each metric should have an owner and an action threshold. For example, expired exceptions over 30 days trigger the exception owner. Repeated restricted-data blocks trigger the data-control owner. High-risk reviews below target trigger the workflow owner. A metric without an action path is just reporting.

Metrics should distinguish adoption from approved adoption. More AI usage is not automatically better. The control should show whether employees are moving from unsanctioned tools into approved workflows, whether risk events are decreasing, and whether high-value workflows are producing measurable outcomes.

Metric quality should be reviewed periodically. Definitions change when new controls launch or workflow categories evolve. If the team changes what counts as a redaction, block, high-risk workflow, or exception, management review should understand the impact on trends.

Audit evidence should be generated by normal work wherever possible. Evidence should show who used AI, which model was selected, what policy applied, whether sensitive data was detected, what action occurred, which review happened, and who approved exceptions. It should be timestamped, protected, searchable, and tied to a control.

Manual screenshots may support early maturity, but they should not be the foundation. AI workflows change too quickly. Audit trails give teams a better way to prove that controls operated over time. Evidence should be designed before the audit, not assembled during it.

Evidence quality should be tested through sampling. Pick a workflow, a date, and a control decision, then confirm the record explains who acted, what happened, why it was allowed, and which policy applied.

Evidence should have owners just like controls. Someone should know where the record lives, how long it is retained, who can access sensitive content, and how to export it without manually rebuilding the story from screenshots.

Audit evidence should be designed around sampling. Auditors may ask for one month of access changes, a sample of high-risk workflows, evidence that sensitive prompts were blocked, or proof that supplier changes were reviewed. The evidence control should make those samples retrievable without engineers writing one-off queries under pressure.

Evidence protection is part of the control. Prompt logs, file metadata, reviewer comments, and incident records may contain sensitive information. The organization should define who can view metadata, who can view content, who can export records, and how audit packages are shared securely.

Evidence controls should include retention and deletion. Keeping every prompt forever is rarely necessary and may create new exposure. Keeping too little makes audit and incident response weak. The right balance depends on data class, workflow risk, legal obligations, and investigation needs.

ISO 42001 requires leadership attention. The management review control should summarize AI system performance, risk trends, incidents, exceptions, supplier changes, audit findings, corrective actions, metrics, and improvement decisions. The review should produce actions with owners and due dates.

Management review is where the AI management system improves. Leaders should see whether adoption is growing safely, whether controls create too much friction, whether high-risk workflows need investment, and whether suppliers or models require changes. A review with no decisions is a meeting. A review with tracked actions is a control.

The review package should be short enough for executives to use but specific enough to drive action. Include trend lines, incidents, exceptions, control gaps, resource needs, and decisions that require leadership authority.

The output of management review should be tracked to closure. If leaders approve a supplier restriction, a new data control, a budget change, or an internal audit finding, the next review should show whether the action happened and whether it improved the program.

Management review should receive decisions, not raw dashboards. The package should summarize what changed, what is stuck, where risk is rising, which resources are needed, and which decisions require leadership authority. A long report that nobody acts on is weaker than a short review with clear decisions.

The review cadence should match AI change velocity. Annual review may satisfy a minimum rhythm, but fast-moving AI environments often need quarterly review for supplier changes, high-risk workflows, exceptions, incident trends, and major model updates.

Management review should also examine whether controls create unnecessary friction. If employees repeatedly avoid an approved workflow, the issue may be usability, latency, missing features, or unclear guidance. Reducing friction can be a risk reduction measure when it moves work into controlled channels.

The management review control should connect all other controls into one operating picture. Scope changes show where the program boundary moved. Inventory metrics show what exists. Risk tiers show where stronger review is needed. Data events show whether sensitive information is being handled correctly. Supplier changes show whether external dependencies remain acceptable. Incidents and exceptions show where the design is under pressure.

A useful review package should therefore answer five questions: what changed, what got safer, what got riskier, what decisions are needed, and what actions from the last review are still open. If the package cannot answer those questions, leadership will either receive too much noise or too little signal. Both outcomes weaken the management system.

The review should also include control failure stories, not only charts. A short narrative about a blocked restricted-data prompt, an expired exception, a supplier feature change, or a high-risk output review helps leaders understand how controls behave in real work. Stories make metrics interpretable and help executives decide where investment, policy changes, or staffing are needed.

Finally, management review should make resource gaps explicit. If the team needs better evidence automation, more reviewer capacity, a safer supplier route, or engineering time for model access controls, the decision should be recorded. ISO 42001 controls can look complete on paper while starving operationally. A leadership review that funds and tracks improvements keeps the control set alive.

The best control set is also understandable by the people who use it. Employees should know which workflows are approved, what data is allowed, where to request an exception, and why a request was blocked or routed differently. Business owners should know what they own and what evidence they must maintain. Engineers should know which control decisions need to be enforced in code or platform settings. Auditors should be able to follow the same chain from policy to operation.

That clarity is what prevents the controls from becoming theater. A control that cannot change user behavior, route data, restrict access, trigger review, or produce evidence is not doing enough. A control that is too slow or confusing will be bypassed. ISO 42001 programs need the middle ground: controls that are visible, enforceable, testable, and practical enough that teams actually use them.

A final way to test the control set is to sample across control types in one sitting. Pick one workflow and ask for its scope record, inventory entry, risk tier, data decision, model route, review evidence, supplier status, incident history, exception history, metrics, audit evidence, and management review signal. If the team can move through that chain quickly, the controls are connected. If every answer requires a different person to reconstruct a different spreadsheet, the program still has maturity work to do.

The strongest ISO 42001 control programs therefore feel less like an annual audit project and more like a product operating model for AI. New use cases enter through intake, controls apply automatically where possible, owners review meaningful exceptions, leadership sees trends, and evidence accumulates as work happens. That is what makes the controls durable.

Durable controls also survive disagreement. Security may want stricter data blocks, legal may want stronger review, finance may want cheaper model routing, and business teams may want faster workflows. The control set should make those tradeoffs visible through owners, evidence, exceptions, and management review. When disagreement is handled through the system rather than side conversations, the program becomes more consistent and easier to audit. It also gives employees a predictable path, which keeps controls from becoming a blocker to legitimate AI work. The more predictable the control path, the less incentive teams have to improvise around it. Predictability is not a soft benefit; it is what keeps daily AI usage inside the approved operating model.