13. ISO 42001 in Practice: Governing AI Systems When the Controls Outpace the Docs

---

ISO 42001 Documentation Connects Controls to Accountability

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system (AIMS). It sets management-system expectations; it does not prescribe a particular model or algorithm.

Clauses 4–10 address organisational context, leadership, planning, support, operation, performance evaluation, and improvement. Annex A provides a reference control set for AI-specific organisational objectives and risk treatment. The official ISO/IEC 42001 overview describes the standard’s scope and intended use.

A technical control and its governance record serve different purposes. The control acts in a workflow; its policy and supporting records explain why it exists, who is accountable, and how the organisation reviews it. These records should describe the control as it operates, not as someone hopes it will operate.

That is the practical role of ISO 42001 documentation: make the link between a requirement, the control, its owner, and reviewable evidence clear.

In our platform, we connected policy-as-code and audit trails and human-review controls to governance documents and evidence paths. Those articles explain the implementation; this one focuses on documenting ownership, decisions, and readiness.

Back to top . Next: Readiness Measures →

---

The Readiness Figures Answer Different Questions

An internal self-assessment estimated technical-control coverage at about 80% and governance-documentation coverage at about 25%. These were project estimates, not certification scores or an external auditor’s findings.

The control review described several implemented areas:

• Human oversight: policy enforcement, a human-review pause, and escalation when generated narrative conflicts with a deterministic decision.
• Security: policy checks, prompt-injection defenses, lateral-movement detection, and red-team probes.

By contrast, the assessment found gaps in the records needed to assign and review those controls:

• Policy and accountability: controls needed a written policy describing their purpose, scope, owners, and exceptions.
• Management system and roles: the review called for a charter and a responsibility matrix linking governance processes to accountable roles.
• Organisational risk: technical threat models did not replace an AI risk register covering business, regulatory, operational, and reputational consequences.
• Review and responsible AI: the assessment identified governance procedures and measures for teams to document alongside the technical controls.

Consider the human-review pause: the workflow can stop a decision, but the governance record must also say which cases require review, who may decide, and where the decision is recorded. Without those instructions, staff may see a paused case without knowing who owns the next step. The linked human-in-the-loop article describes the pause and resume behavior; here, the lesson is to document the accountable role and review evidence alongside it.

Readiness Measures Use Different Evidence

The 80% and 25% estimates describe coverage of technical controls and governance documents. The 19-of-48 figure counts delivered criteria in a separate readiness register. Each answers a different question; readers should not interpret the criteria count as a recalculation of either estimate or as evidence of current status.

For related reading, the 57-Gap Audit shows how implementation claims were checked against working controls; it covers a code-gap review, not the readiness calculations above. Model Risk, Agentic Risk Management, and the Observability Gap adds a complementary view of model and agent controls, ownership, and operational records. Together, they help distinguish a control that is described or implemented from evidence that people can review.

Back to top . Next: Keeping Shared Details Consistent →

---

Keep Organisation Details Consistent Across Governance Documents

A governance document must identify which organisation, jurisdiction, regulator, and accountable roles it covers. When those details are copied by hand into many policies, an update in one document can leave the others stale.

For example, imagine an AI policy where the organisation name has been filled in, while a related risk procedure still contains [ORGANISATION_NAME]. A reader may not know whether that procedure belongs to the same organisation or is still a draft. In this project, a scan found the placeholder repeated in documents that should refer to a shared constants file. That finding shows the reference was not used consistently; it does not, by itself, prove that the documents contained conflicting regulator or role assignments.

To prevent this kind of ambiguity, keep shared organisation details in one controlled source, have each policy reference it rather than retype the values, and check drafts for unresolved placeholders before approval. A reviewer should also confirm that any exception—for example, a regulator that applies only to cross-border activity—has its scope explained instead of being copied as a universal requirement.

Back to top . Next: The Documentation Sprint →

---

Governance Documents Connect Scope, Policy, and Roles

The governance set used eight documents to answer different management questions: what principles apply, which systems are in scope, who is accountable, what risks matter, and how performance and review are recorded. The shared constants file supplied organisation-wide reference details.

Three documents show how the set works together:

• The synthetic AI Governance Policy connects principles such as human oversight to controls and responsibilities rather than leaving them as broad statements.
• The synthetic AIMS Charter demonstrates how to define a system’s scope and exclusions for an AI management system.
• The synthetic Roles and Responsibilities Matrix shows how to assign authority by role across governance activities. In practice, management records named appointments and approvals separately.

For example, when a case pauses for human review, the policy explains the oversight principle, the charter places the workflow inside the management system, and the role matrix identifies who can make or escalate the decision. The evidence record then shows who reviewed the case and what happened. Readers can use the same chain for a control in another domain: requirement, in-scope system, accountable role, and reviewable result.

Back to top . Next: Risk Register vs. Threat Model →

---

AI Risk Register vs. Threat Model

Technical threat models and an organisational AI risk register answer related but different questions. The platform’s STRIDE, PASTA, and MITRE ATLAS review records attack paths and security controls; the organisational register also considers effects on the business, customers, and regulatory obligations.

A threat model asks what an attacker could do to the system. An organisational risk register asks what could go wrong for the organisation because the system exists. The distinction matters even when one event appears in both records:

Record	Example question	What the entry should capture
Technical threat model (STRIDE sample; PASTA scenarios)	Could prompt injection in a customer note alter an agent’s action or expose data?	Attack path, affected components, defenses, and remaining technical exposure.
Organisational AI risk register (synthetic sample)	If the attack changes a customer decision, what harm could follow for customers, the business, or regulatory obligations?	Business impact, likelihood, controls, residual rating, accountable owner, and review trigger.

Risk Ownership and Review

Example: Imagine a customer-uploaded statement contains a prompt injection that tries to make an agent reveal another customer’s details. The threat model records the attack path and tested defenses; the AI risk register records the possible disclosure harm, accountable owner, residual rating, and response. The reviewer checks test evidence before deciding whether to accept the remaining risk or require more work. In this project, the AI Risk Lead owns the register and reviews it quarterly; residual scores of 15 or higher require escalation to the Chief Information Security Officer and Chief Risk Officer, plus board notification. Teams can keep one access-controlled record in a version-controlled repository or an approved governance, risk, and compliance (GRC) system, linking remediation and evidence to the relevant entry. For more on risks across agent handoffs, see model and agentic risk management. Use these three steps at each scheduled or triggered review:

1. Describe the risk. Name the potential harm, affected workflow, controls, owner, and review trigger.
2. Check current evidence. Update the rating after a control change, test result, or trigger event; revisit it at the next scheduled review.
3. Record the decision. A separate reviewer confirms the treatment and authorized disposition. Keep unresolved risks open.

Back to top . Next: Measures and Targets →

---

Choose Metrics That Measure the Control

The Responsible AI Framework defines measures across fairness, explainability, privacy, Sharia compliance, human oversight, and safety and security. A target states what a control is expected to achieve; a result comes from running the check on data and reviewing its output.

Make a Metric Actionable

Approval rate alone can mislead. A system that approves every Murabaha application could show a high rate while failing to assess eligibility properly.

The framework sets 100% fatwa citation coverage: every Sharia decision should record a supporting fatwa. This counts whether a reference is present, not whether it fits the product structure or ruling; a qualified reviewer must check relevance. For any metric, define its denominator, evidence source, review trigger, and response.

Domain	Tempting metric	Framework measure or target
Fairness	Overall approval rate	Disparate-impact ratio ≥ 0.80 by nationality, income band, and segment; weekly audit
Sharia Compliance	Sharia approval rate	Fatwa citation recorded for each decision; 100% target
Human Oversight	Human-review escalation count	Zero auto-approvals on timeout; independent second-person review for every tier change
Explainability	Explanations generated	Framework target: SHAP (SHapley Additive exPlanations) attribution for each credit decision; documented implementation: attribution for the credit score
Privacy	Reported personal-data incidents	Zero unmasked personal data in prompts; check each decision
Safety & Security	Security incidents per quarter	Zero unmitigated critical red-team findings in production after each scan

Illustrative example: If a weekly fairness audit returns 0.79 for one group against the table’s 0.80 target, record the group, data period, sample size, and calculation. A reviewer should check the labels and underlying data, then record the finding and next action; the threshold prompts investigation, not an automatic conclusion about cause. The synthetic AI risk register shows how a risk, control, owner, and review trigger can be recorded. For context on group comparisons and explanation scope, see the article on fairness, explainability, and drift.

Choose a Tool That Fits the Review Workflow

The project uses Fairlearn for repeatable fairness metrics in its Python pipeline. For interactive notebook-based analysis, Microsoft’s Responsible AI Toolbox is another option; the Azure ML Responsible AI dashboard fits teams working in Azure ML. Choose according to where data and models run, how reviewers inspect results, and whether the output can be retained with a decision record.

Back to top . Next: Trace Claims to Controls →

---

Trace ISO 42001 Documentation Claims to Running Controls

Writing the governance documents gave the team a structured way to compare policy statements with the implementation and its evidence.

For each ISO 42001 documentation claim, trace the policy to the code, configuration, test, or operational record that supports it. If the evidence covers only part of the statement, narrow the claim or record the unresolved part.

For example, the synthetic AI Governance Policy says a person makes the final eligibility decision. A team adapting that policy should test a case that requires review: confirm the system pauses, the reviewer can see the information needed, and the decision is recorded. To claim that a customer can access an explanation, test the customer-facing route and its authorization checks too; a stored explanation alone does not establish access.

The framework sets a target for explanations on every credit decision, while its implementation description places SHAP attribution on the credit score. Keep the claim within that scope; one score attribution does not cover every factor in a wider decision process.

Separate ISO 42001 Documentation from Operational Evidence

The captured readiness register recorded evidence in 0 of its seven operational categories: fairness audits, drift runs, audit findings, training completions, red-team scans, management-review minutes, and Langfuse traces (records of model calls). A later end-to-end run does not, by itself, establish evidence in every category. For example, a drift-evidence record should identify the model and version, observation period, result, and reviewer or follow-up. The synthetic risk register illustrates fields for documenting a risk, control, owner, and review trigger; it is a template, not proof that a control ran.

To report a current status, inspect the source record for each category and state its environment and evidence period. The earlier readiness comparison explains why delivered criteria, coverage estimates, and operational evidence should be reported separately; The 57-Gap Audit describes how implementation claims were checked against working controls.

Review Role Assignments as Work Changes

A role matrix can become stale when responsibilities or reporting lines change. The project matrix assigns approval authority for policy and autonomy-tier changes; review assignments when roles change and at the document’s scheduled review. The synthetic roles matrix shows example activity-to-role assignments. Before using one, check that each approver has the authority, independence, and escalation route needed for the decision.

Back to top . Next: Recommendations →

---

Separate Control Evidence from Readiness

Assess implementation, governance records, operational evidence, and approvals as distinct parts of readiness.

For example, a claim that human review is required should point to the workflow trigger, authorized reviewer, and recorded decision—not just the policy sentence. Use the following checks to test that chain and the rest of the readiness evidence.

1. Map each requirement to evidence. Start with a policy claim, such as human review for a final decision, and link it to the relevant test or operating record. The synthetic AI Governance Policy is an example of how to frame the claim.
2. Keep one authoritative risk register. Choose an access-controlled repository or approved GRC system, then link remediation tasks and evidence to the canonical entry. The synthetic risk register demonstrates example risk, control, owner, and review-trigger fields.
3. Separate targets from results. A policy metric describes the expected result; a run record shows what happened in a particular environment and when. For example, an illustrative 0.79 fairness result against a 0.80 target needs a recorded review, not a claim that the target was met.
4. Review shared document values. Maintain one controlled source for organisation-wide details, reference it from policies, and check drafts for unresolved placeholders or conflicting values.

Back to top . Next: Key Lessons Learnt →

---

Key Lessons Learnt

The review surfaced a few practices worth carrying into another system.

Lesson	Recommendation
Technical controls and governance records answer different readiness questions.	Map each control to its policy, owner, test or runtime evidence, and review record.
A policy statement can overstate the behavior of a partial control.	Keep claims within the evidence; state limitations and the path for handling failures.
Threat models and organisational risk registers answer two different questions.	Record business and regulatory consequences in one authoritative, access-controlled register; link tasks and evidence to it.
A documentation review can expose claims that outrun their evidence.	Trace every documented claim to the code or record that proves it before publishing it.
A high outcome rate can hide missing control evidence.	Pair outcome measures with process checks, such as recorded source citations, and expert review.
A shared value copied into many documents drifts from its source.	Centralise the value and add a check that fails when a copy appears.
Readiness status must distinguish live evidence from documents.	Report what ran, for which environment and period, and what remains unverified.

---