Structures, defense lines, and what reaches the board
Lesson 4 of 4 in Board-Level AI Governance: ISO/IEC 38507 and Organizational Accountability.
Direction without structure evaporates. This lesson covers the machinery that keeps the EDM loop honest: how 38507 wires into 42001, the organisational structures that carry AI governance, and the reporting that lets a board monitor without micromanaging.
The 38507–42001 wiring is precise. The board’s Direct enters the management system through 42001 clause 5: top management demonstrates leadership, establishes the AI policy (5.2), and assigns roles, responsibilities, and authorities (5.3) — the clause is the legally-shaped receptacle for board direction. The board’s Monitor is fed by clause 9.3 management review: the mandated, minuted checkpoint where top management confronts audit results, objective performance, incidents, and improvement decisions. A distilled version of exactly that packet is what should travel up to the governing body. If your organisation runs a 42001 AIMS, the board-reporting pipeline is already 80% built — the remaining 20% is deciding what crosses the altitude boundary, and that is this lesson’s last topic.
Structures. Three recur across mature organisations, and 38507 is deliberately agnostic about labels:
- An AI governance committee — cross-functional (risk, legal, technology, business, often the DPO), owning the AI policy’s operation, portfolio-level risk acceptance within delegated limits, and escalation triage. This is management machinery, typically chaired at executive level, reporting up.
- An ethics review function — advisory depth on contested cases (new use categories, vulnerable populations, dual-use questions). The Google ATEAC lesson from the trustworthiness module applies with full force: give it process hooks — a gate it can hold — or it is theatre.
- Board-level ownership — a named committee of the governing body (risk committee, audit committee, or a dedicated technology committee) whose charter explicitly includes AI. "The whole board owns it" reliably means nobody prepares, nobody follows up, and AI appears on the agenda the meeting after an incident.
Beneath the structures runs the accountability pattern borrowed from financial services and adapted for AI — the three lines of defense:
| Line | Who | Day job for AI | When the biased screening model surfaces… |
|---|---|---|---|
First line | The business and its developers/operators — the people who own and run the AI system | Owns the risk: builds, tests, documents, monitors; runs impact assessments; operates human oversight | Pulls the model or activates fallback, notifies per incident procedure, begins root-cause analysis — TR 24027 taxonomy in hand |
Second line | Risk, compliance, and AI-governance functions | Sets the methodology: risk criteria, assessment templates, policy interpretation; challenges first-line conclusions; aggregates portfolio risk | Verifies the response followed procedure, assesses regulatory exposure (notification duties?), checks whether sibling systems share the flaw, updates risk register and criteria |
Third line | Internal audit — independent, reporting to the board or its audit committee | Provides assurance that lines one and two actually work: audits the AIMS (clause 9.2 machinery plus independent scope), tests evidence, not assertions | Asks the uncomfortable question: why did our controls not catch this before deployment? — and reports the answer to the board, not to the executives who own the failure |
What actually reaches the board. Boards drown in detail or starve on reassurance; the discipline is a short, stable packet:
- KPIs — is the direction being achieved? Portfolio inventory coverage (what share of AI in use is registered and risk-assessed — shadow AI makes this the most honest number in the pack), objective attainment against the clause 6.2 targets, assessment-gate completion rates.
- KRIs — is risk approaching appetite? Drift alerts open past SLA, human-review override rates trending toward zero (the rubber-stamp early-warning signal), incidents by severity, supplier concentration on critical models.
- Escalation thresholds, pre-agreed — which events interrupt the calendar rather than wait for it: any harm event above defined severity, any regulator contact, any appetite breach. Deciding during the incident what the board should hear is how boards end up learning from journalists.
- Assurance — periodic third-line (and where warranted, external) opinions on whether everything above is true, delivered to the board directly.
Map the accountability end-to-end and the three standards you now know click together into one ladder:
| Rung | Accountable for | Which standard speaks to it |
|---|---|---|
Governing body | Direction and oversight of AI use: appetite, policy principles, monitoring, non-delegable answerability to stakeholders | ISO/IEC 38507 (via the 38500 EDM model) |
Top management / executive | Establishing and resourcing the AIMS; AI policy; assigning roles and authorities; management review | ISO/IEC 42001 clause 5 (5.1, 5.2, 5.3) and 9.3 |
AI system owner / governance functions | Per-system risk and impact assessments, lifecycle controls, incident response, supplier management | ISO/IEC 42001 clauses 6 & 8; Annex A controls A.3, A.5, A.6, A.10 |
Developers, operators, users | Building, operating, and using systems within the controls; raising concerns through the A.3 channel | ISO/IEC 22989 role vocabulary (AI provider, producer, developer, user) + operational procedures |
Key terms: three lines of defense, management review, key risk indicator, internal audit, escalation threshold
Tool: AIMS Builder & Audit — Draft the governance layer yourself: set a risk appetite, cascade it into an AI policy, and wire the board reporting pack in the AIMS Builder.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.