Obligation, Assurance and Maturity Tools
A practitioner who has to answer a supervisor, an auditor or a board meets the same three questions in different words. Which obligations apply, and which control answers each of them? Is the control working, and who other than its owner says so? How far along are we, and what do we do next? This chapter collects the tools of the series that answer these questions. It serves the activity of demonstrating: turning what an organisation does into something that a second person can check. The tools are of all four kinds. Most are artefacts (mapping matrices, registers, catalogues, test procedures, metrics and reports), a few are methods (assure once and comply many, the internal algorithmic audit, the maturity assessment), one is an own tool (the Maturity Radar of Architecture as Code) and the rest are standards and frameworks that the series maps to (ISO/IEC 42001, ISO/IEC 27001, the NIST frameworks, OSCAL). They come mainly from Architecture as Code (1, Nordqvist, 2025), AI Governance (2, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), with contributions from AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), AI Threat (5, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026) and AI Blue (8, Nordqvist, 2026).
Laws are not tools. The AI Act, DORA, NIS 2 and the GDPR appear here only as the things the tools are mapped to, and every statement about them is attributed to the instrument and article and framed as an architectural implication, not as legal advice (195, European Union, 2024) (197, European Union, 2022) (198, European Union, 2022) (196, European Union, 2016). What this chapter treats is the machinery that makes a mapping to those instruments testable.
The chapter proceeds in five families. Obligation mapping holds the tools that start from an article and end at a control and a piece of evidence. Control catalogues holds the records that hold the controls. Assurance and audit evidence holds the tools by which a control is tested and its oversight is shown to be real. Maturity models and profiles holds the tools that measure where an organisation stands. Reporting and transparency holds the tools that carry the result to a management body, to workers and to the public. Compliance checks that run inside the pipeline (Rego policies, pipeline definitions, infrastructure templates) are tools of delivery and are treated in Chapter 5 and Chapter 6; this chapter says where they connect.
Figure 8.1: Assure once, comply many. Several obligations map to one control; the control is tested once against evidence whose age is recorded; the independent test result, not the owner's assertion, flows to the report.
Obligation mapping
An obligation is a sentence in an instrument. A control is something an organisation does, and evidence is something it can show. A mapping tool joins the three in a form that a pipeline can check. The series reaches the same design from five directions, and the differences between the tools lie in what they take as the starting point and what they require beside the row.
The method that organises all of them is assure once, comply many. Architecture as Code (Chapter 10) states it for policy design: execute and evidence a control once, then map it to many frameworks. AI Red Team (Chapter 3) applies it to NIST CSF 2.0 and the European obligations (53, NIST, 2024), and The Transformed Security Architect (Chapters 5 and 9) applies it to the assurance of a property at design time. Three inventory entries carry this name and they are the same method; the tools below are its instruments.
Assure once, comply many
| Kind | Method |
| Origin | Architecture as Code (Chapter 10, with Chapters 11, 12 and 15a and Appendix D); AI Red Team, Chapter 3; The Transformed Security Architect, Chapters 5 and 9 |
| Purpose | Execute and evidence a control once and map it to many frameworks, so that one test serves many obligations. |
| Use when | The same property (encryption, access, logging, oversight) is demanded by more than one instrument or standard. |
| Inputs | A control with an identifier; the obligations that it serves; an assurance artefact that evidences it. |
| Outputs | A mapping row per control, and an evidence item that every obligation on the row can cite. |
The method fails in a characteristic way. If the mapping is a list of articles with no evidence beside each row, it reproduces the spreadsheet that it replaced. The tools that follow differ chiefly in what they refuse to leave out: Architecture as Code refuses a row without an assurance artefact; AI Governance refuses an obligation without a gate and a resolvable evidence path; AI Purple and AI Operations refuse a row without an evidence age and an owner.
Control Mapping Matrix
| Kind | Artefact |
| Origin | Architecture as Code (Chapters 12 and 15a, Appendix D) |
| Purpose | A table that links each control identifier to its assurance artefacts and to ISO 27001, SOC 2, NIST 800-53, GDPR and internal controls. |
| Use when | Auditors, risk managers and engineers need one source of truth for how a control satisfies several frameworks. |
| Inputs | Control identifiers from the governance repository; evidence manifests; the clause or article of each framework. |
| Outputs | A matrix that is kept current and validated, so that a missing mapping fails a pipeline. |
| Identifier family | SEC-* (for example SEC-ID-001) |
| Full template | Architecture as Code, Appendix D (Control Mapping Matrix Template) |
The template is a header row and a five-step procedure: identify the control, describe it in a short action-oriented title, link machine-generated evidence, record the clause or identifier in each framework, and keep the matrix current by automating validation. The columns, in the order of the published version of Architecture as Code (2025), are:
| Control ID | Control Title | Assurance Artefact(s) | ISO 27001 | SOC 2 | NIST 800-53 | GDPR | Other Frameworks / Internal |
The matrix is the simplest tool in the chapter and the one with the widest reach, because it asks nothing of the reader but a table. Its limit is that it holds clause references and not tests: nothing in the template says how old the evidence is, who owns the row or what happens when a framework changes. The later volumes add those fields. SOC 2 appears as a column in the template but is not a source of this book's claims; the series does not otherwise describe it.
EU AI Act obligation mapping
| Kind | Artefact |
| Origin | AI Governance, Appendix A |
| Purpose | Maps AI Act obligations to repository artefacts, evidence and owners for providers, deployers, general-purpose AI model providers and Article 50. |
| Use when | An organisation is a provider or deployer of AI systems and wants the AI Act read as a component of its architecture, tested by the pipeline. |
| Inputs | The regulation's article structure and its ELI identifier; the control implementations; the evidence patterns of the platform. |
| Outputs | A versioned mapping; generated tables for the second axis of ISO/IEC 42001 clauses; failing tests when a gate or an evidence path does not exist. |
| Identifier family | governance/aiact/obligation-mapping.yaml; obligation identifiers such as art26-deployer-obligations |
| Full template | AI Governance, Appendix A |
The appendix gives five rules for maintaining the mapping as code: version it against the regulation by recording the ELI identifier and a mappingVersion; reuse the same identifier strings in the mapping, the classification policy and the evidence manifest; test that every gate exists and that evidence resolves; generate the tables from the YAML; and change it only through pull requests, so that the history shows how the organisation's reading of the law developed. The excerpt of the book (version 2026.1) reads:
# governance/aiact/obligation-mapping.yaml
apiVersion: ai-architecture.example.eu/v1
kind: ObligationMapping
metadata:
regulation: Regulation (EU) 2024/1689
eli: http://data.europa.eu/eli/reg/2024/1689/oj
mappingVersion: 2026.1
owner: head-of-ai-governance
spec:
gates: [design, build, evaluate, release, operate, change]
obligations:
- id: art26-deployer-obligations
article: "26"
appliesTo: [deployer-high-risk]
controls:
- id: log-retention-six-months
implementation: platform/logging/retention.yaml
parameters:
minimumRetentionDays: 183
evidence:
- pattern: evidence/{aidr}/{system}/{version}/log-retention-policy.json
owningRole: business-owner
gates: [design, release, operate]
iso42001Clauses: ["8.4", "9.1"]
The iso42001Clauses field is the bridge to the management-system auditor (58, ISO/IEC, 2023). What to watch: the file records one reading of the law at one date. AI Operations (Chapter 23) records that the Digital Omnibus amended the timetable of the AI Act (10, Nordqvist, 2026); the amending text sets 2 December 2027 for high-risk systems under Article 6(2) and Annex III and 2 August 2028 for those under Article 6(1) and Annex I (199, European Union, 2026), so a mapping that is not re-read against the live text is stale by construction.
Regulatory mapping (MAP-*) and Turning an article into a control
| Kind | Artefact and method |
| Origin | The Transformed Security Architect, Chapter 18 |
| Purpose | An article-to-control mapping of kind RegulatoryMapping, and the method of converting one article into a catalogue control with a test and evidence. |
| Use when | One system (an agent, a platform) has to be shown against specific articles, with a named reviewer. |
| Inputs | The system, its AI Act classification record, the scope of laws and group policy by country, the controls of the catalogue. |
| Outputs | Rows with article, property, control, test, cadence and status; a review date. |
| Identifier family | MAP-* (for example MAP-HM-CLAIMS-TRIAGE-01) |
The book's example maps DORA Article 6(2) (every model, prompt and tool configuration of the agent is a registered ICT asset) to CTRL-ICT-006 with a daily reconciliation test, and DORA Article 28(3) (no model provider is callable unless it is in the register of information) to CTRL-ICT-028. A row can carry an applies_if condition, as the AI Act rows do, so that the mapping stays correct when the classification changes. The method behind it takes one article at a time: state the property the article requires, choose or write the control, write the test and name the evidence.
Obligation register (OBL-*)
| Kind | Artefact, with the method Mapping obligation to control and evidence |
| Origin | AI Purple, Chapter 21 and Appendix A |
| Purpose | Maps legal obligations (DORA, the TLPT delegated regulation, NIS 2, the AI Act, the GDPR) to loop controls and evidence. |
| Use when | Testing and emulation are regulated, and the organisation has to show which obligation each part of the purple loop serves. |
| Inputs | The instrument and article; the loop stage (P1 to P5); the control; the evidence and its age; the owner. |
| Outputs | A register with a review date and a six-monthly cycle. |
| Identifier family | OBL-* (for example OBL-HM-2028-01) |
An entry in the book's example names the instrument ("Delegated Regulation (EU) 2025/1190, Article 12(4) and (5)"), the obligation in a sentence, the stage (P3), the control, the evidence (PRP-HM-2027-04), evidence_age_days and the owner. The register also records text_read_on, the date on which the instrument's text was last read, which is the field that the AI Act mapping above lacks.
Regulation-to-control mapping record (RCM-*)
| Kind | Artefact, with the method Regulation-to-control mapping |
| Origin | AI Operations, Chapter 23 |
| Purpose | One row per control with the instruments it serves, the owner (second line), the evidence age and the review dates. |
| Use when | A supervisor or an executive committee asks what the organisation would show for one service. |
| Inputs | The service record, the controls and the instruments; evidence records such as restore tests; the independent owner of the mapping. |
| Outputs | A mapping per service with a result for each row (failed, open, proposed, reviewed, not_tested, in_force) and the next action. |
| Identifier family | RCM-* (for example RCM-HM-OPS-2028-01) |
AI Operations adds two ideas to the mapping. The owner of the record is independent of operations (independent_of: operations), so the mapping is itself a second-line artefact. And a failed test withdraws the claim: the row for restoring from immutable backup carries result: failed and status: claim_withdrawn until a re-test passes. An abbreviated extract of the version in the book (an illustrative, fictional example) follows.
mapping_record: RCM-HM-OPS-2028-01
date: 2028-11-28
decision_record: AIDR-0973
owner: {role: head_of_operational_resilience, line: second, independent_of: operations}
operations_owner: <name of the operations owner>
text_read_on: 2028-11-28 # re-verify every 6 months and on amendment
next_review: 2029-05-28
service: {id: SVC-HM-001, tier: 1, cif: true}
rows:
- control: "Restore from immutable backup into a segregated target"
serves: ["DORA 11(6)(a)", "DORA 12(2)", "DORA 12(3)", "DORA 24(6)", "GDPR 32(1)(c)"]
functions: [O4]
evidence: {record: RST-HM-2027-004, result: failed, date: 2027-06-15, status: claim_withdrawn}
age_limit_days: 180 # book default; the legal floor is 12 months
next_action: "re-test; independent attester; probe OBS-HM-0001"
- control: "Change record with provenance, tests, approval and independent verification"
serves: ["DORA 9(4)(e)", "DORA 8(3)", "NIS 2 21(2)(e)"]
functions: [O3]
evidence: {record: "CHG-HM-6000 series, sampled 25 per quarter", result: open}
age_limit_days: 90
I quote the AI Operations text as published in its repository at the time of writing and have removed four of the six rows and the name of the operations owner. Note the comment on age_limit_days: the group's limit (180 days) is stricter than the legal floor (twelve months) for restore tests, and the record keeps both in view.
AI Act control set and the reporting-clock configuration
Two further mapping artefacts serve a single regime. The AI Act control set of AI Boss (Chapter 21, management/ai-act-controls.yaml) maps the obligations for AI systems that manage people to controls in a group baseline, with dates that follow the AI Act as amended by the Digital Omnibus, and records in a market overlay whether a control applies in each country as law or as group policy. The reporting-clock configuration of AI Red Team (Chapter 21, INC-HM-*) maps one incident to the clocks of every reporting regime (AI Act, DORA, NIS 2, GDPR, CRA); it is a mapping of obligations in time, and Chapter 13 treats it with the response tools.
OSCAL
| Kind | Third-party tool (open standard), with three artefacts of Architecture as Code |
| Origin | Architecture as Code (Chapter 10, Appendix A) |
| Purpose | OSCAL, the Open Security Controls Assessment Language, is a NIST-led set of open, machine-readable formats in XML, JSON and YAML for control catalogues, baselines and information about how controls are implemented (61, NIST, n.d.). |
| Use when | Controls and their implementation have to be exchanged between tools and organisations without re-typing, or a system security plan is to be generated. |
| Inputs | A control catalogue (for example NIST SP 800-53) (54, NIST, 2020); organisation-specific selections and parameters. |
| Outputs | Profiles, component definitions and system security plans as documents. |
| Identifier family | 10_CODE_2 (profile), 10_CODE_3 (component definitions), 10_CODE_4 (SSP generator) |
| Full template | Architecture as Code, Appendix A |
Architecture as Code (1, Nordqvist, 2025) shows three artefacts: a profile for regulated financial services that merges SP 800-53 controls with GDPR Article 32 and national network-segmentation expectations (the regional-catalog.json import refers to the organisation's own catalogue and is not reproduced), component definitions for reusable cloud modules, and a Python generator that assembles a system security plan from them. The book shows OSCAL as a way to hold such mappings as data; whether a given supervisor or assessor accepts an OSCAL document is a question for that body, and the series makes no claim about it.
Control catalogues
A mapping row points at a control. A control catalogue is where the control lives with its owner, its enforcement, its evidence and its test. The series has two catalogues with the same identifier prefix and different shapes, which is recorded in Chapter 25 and in the findings of this chapter.
Control catalogue entry (CTRL-*)
| Kind | Artefact |
| Origin | The Transformed Security Architect, Chapter 9 and Appendix A (09_CODE_CTRL); AI Platform and Security, Chapter 17 (the catalogue of the AI security engineering chapter) |
| Purpose | A control with an owner, the obligations it serves, its enforcement, an evidence source and freshness, a test and a status. |
| Use when | Controls are to be managed as code, so that an auditor reads the catalogue and the pipeline checks it. |
| Inputs | The control statement; obligations; the enforcement mechanism (for example policy-as-code); the evidence source; the test. |
| Outputs | A catalogue as code, with a status per entry (the book's example shows generated). |
| Identifier family | CTRL-*; in AI Platform and Security the sub-families CTRL-GW, CTRL-RAG, CTRL-AGT, CTRL-SEC, CTRL-OVR |
| Full template | The Transformed Security Architect, Appendix A (09_CODE_CTRL) |
The excerpt of Hansa Mutual's catalogue in the book (version of the repository at the time of writing) is:
# controls/catalogue.yaml (Hansa Mutual, excerpt)
- id: CTRL-AGT-002
title: Tool calls outside the permission manifest are denied outside the agent
owner: Head of group AI platform
obligations: [ISO/IEC 27001:2022 Annex A 5.15, DORA Article 9, AI Act Article 15]
enforcement: policy-as-code
evidence: {source: platform-telemetry, collected_by: evidence-collection agent, freshness_days: 7}
test: tests/controls/ctrl_agt_002.rego
status: generated
Three fields do the work. enforcement says whether the control is a policy, a pipeline gate or a procedure. evidence.freshness_days says how old the evidence may be before the control stops counting. And test makes the entry executable: an entry without a test is a statement. The Transformed Security Architect adds a method for the common starting point, a spreadsheet of ISO/IEC 27001 Annex A controls (57, ISO/IEC, 2022): move the rows into a catalogue as code with a validator, starting with ten entries, as Nordvik Region's catalogue (nordvik-controls) did. AI Platform and Security (Chapter 9) maps the risks of the DevSecMLOps loop to Annex A controls with evidence in a table, the Annex A control mapping with evidence, which is the same idea in prose form.
The market overlay (overlays/markets/*.yaml, The Transformed Security Architect, Chapter 20) sits over a pinned version of a baseline catalogue and adds the law of one jurisdiction without altering the baseline; its method, Adding a market overlay without weakening the baseline, is the rule that a country may add controls and never remove one. Hansa Mutual's overlays for the UK and Swiss entities are the book's example.
Assurance and audit evidence
A mapping says what should be true. Assurance says whether it is, and says it by someone other than the control's owner. The series separates three things: the test of a control's design and operation (the audit test procedure), the evidence that the humans in the loop are not merely approving (oversight-quality metrics), and the structure that decides who may assure whom (the Three Lines Model and the assessment procedures of NIST).
Audit test procedure (TP-AI-*) and the internal algorithmic audit
| Kind | Artefact and method |
| Origin | AI Governance, Chapter 11 |
| Purpose | An internal audit test procedure for an AI control, and the method of auditing an AI system with test procedures and an evidence pack. |
| Use when | Internal audit has to test an AI control for design and for operating effectiveness. |
| Inputs | The control and the system; the oversight design specification; samples of events; the evidence pack sections. |
| Outputs | A finding per deficiency, raised as an issue labelled audit-finding with an owner and a due date. |
| Identifier family | TP-AI-* (the book's example is TP-AI-014) |
The book's example tests Nordvik Region's caseworker override control (CTRL-OVR-001, system ai-system/benefits-triage) against AI Act Article 14(4)(b) and (d) and Article 26(2). It has a design test (a reorder cannot be saved without a reason), an operating-effectiveness test (a sample of forty ranking reviews plus all reorders, capped at sixty; review time of at least 45 seconds with a tolerance of two in forty; the weekly override rate recomputed from raw events and required to match the metric exactly; agreement on the 5% blind sample compared with agreement on scored cases) and an interview of three overseers. The deficiency criteria are explicit: a reorder without a reason or by an untrained actor, or a mismatch in the recomputed rate. Two steps carry most of the value. Recomputing the override rate tests the metric pipeline as well as the control, and comparing blind and scored agreement is the only direct measure of automation bias in the procedure. The sample sizes are fictional defaults; internal audit sets its own.
The test procedure depends on a second artefact, the human-oversight design specification (oversight_design, AI Governance, Chapter 10), which defines oversight roles, the overseer's view, reorder reasons, the default action when nobody acts, the blind-sample rate, override-rate alert limits, the stop function and the competence module. The specification is what the audit tests. Its fields are chosen so that every one of them can be checked, for example never_auto_accept: true and a stop function that returns the queue to date order within sixty seconds, tested quarterly.
Oversight-quality metrics (OQM-*) and the oversight record
| Kind | Artefact (metric, record and report) and method (Setting up an oversight-quality metric) |
| Origin | AI Threat, Chapter 14; AI Boss, Chapter 26, Appendix A and B.5, B.6; AI Blue, Chapters 14, 20 and 21 and Appendix B.12 |
| Purpose | Show whether human oversight of an AI system is real, by override rate, seeded-error catch rate and review time, reported for groups and never to evaluate individual overseers. |
| Use when | A person confirms, approves or reviews the output of an AI system, and the organisation has to show the review is more than a signature. |
| Inputs | Review events; seeded known-wrong items; review times; the agreed aggregation rule and excluded uses. |
| Outputs | A metric with floors and ceilings, an oversight record per period, a quarterly oversight report. |
| Identifier family | OQM-*, OVR-* |
Three volumes define this tool, and they do not define it identically. AI Threat introduces the oversight-quality metric as a way of detecting rubber-stamping, with signals for the seeded-detection rate (alert below 0.85), the ratio of overrides to agent errors, the share of fast approvals, and a fallback-drill accuracy, and with a minimum group size of eight. AI Boss makes the metric a thing agreed with the workers' representatives before any figure is collected, with figures that have floors or ceilings, an aggregation that protects the overseers, the uses it is barred from and the trigger that changes the degree of delegation; its oversight record (OVR-NR-ROS-2027-2) states the recorded degree and the period. AI Blue turns it into a review protocol with tiers, seeded-incident rates and proposal caps and reports it quarterly as OQM-HM-SOC-01. The common rules are the series' own conclusion: the metric is reported at team level, never per person, it is never used to evaluate the overseers, and it is introduced only after consultation where the metric observes employees. The identifier clash and the divergence of the definitions are recorded in the findings of this chapter.
Soundness criteria for a security conclusion
AI Blue (Chapter 14) gives criteria that a conclusion must meet before it is accepted, in the context of a conclusion reached by an AI system. It is a method and not a template, and it is the nearest the series comes to an audit of reasoning rather than of controls.
Standards of assurance
| Name | Kind | Origin | What the series uses it for |
|---|---|---|---|
| ISO/IEC 42001 | Standard | AI Governance, Chapters 9, 12 and 13; AI Platform and Security, Chapters 8, 9 and 17 (with ISO/IEC 27001); The Transformed Security Architect, Chapter 9 | An AI management system standard (58, ISO/IEC, 2023) whose clauses are codified as repository artefacts and used as the second axis of the AI Act mapping. |
| ISO/IEC 27001 and 27002 | Standard | AI Red Team, Chapters 1, 3 and 9; AI Platform and Security, Chapters 8, 9 and 17; The Transformed Security Architect, many chapters | Information security management and the Annex A controls that catalogues are mapped to (57, ISO/IEC, 2022). |
| NIST SP 800-53 | Standard | AI Operations, Chapter 8 | A security and privacy control catalogue (54, NIST, 2020) mapped in the matrix and used as input to OSCAL profiles. |
| NIST SP 800-53A | Standard | The Transformed Security Architect, Chapter 9 | Control assessment procedures (59, NIST, 2022), against which an assessor's test of a catalogue entry can be written. |
| Three Lines Model | Model | The Transformed Security Architect, Chapters 9 and 16 | A model of the roles in governance and assurance (132, Institute of Internal Auditors, 2020), used in the series to place the owner of a mapping outside the function mapped (as RCM-* does). |
| NIST AI RMF 1.0 and the Generative AI Profile | Framework | AI Governance, Chapters 8 and 21; AI Threat, Chapters 4 and 32; AI Operations, Chapter 18 | A framework for AI risk functions (50, NIST, 2023) (60, NIST, 2024); AI Threat cites it for the point that hard-to-measure risks are not therefore low. |
| International AI Safety Report | Report | AI Threat, Chapters 5 and 32 | A periodic report used as evidence and as a source of review triggers (131, Bengio et al., 2026). |
The series does not claim that holding a certificate under any of these standards shows that the controls work; it uses them as vocabularies for mapping and as procedures for assessing.
Maturity models and profiles
A maturity tool answers the third question: where does the organisation stand, and what is the next move? The series has two maturity models of its own and a profile technique taken from NIST. Each states its own limit, and the reader should keep the three apart.
Architecture as Code Maturity Model, checklist and Maturity Radar
| Kind | Artefacts (model, checklist, export), method (assessment) and own tool (the Radar) |
| Origin | Architecture as Code, Appendix D (supplement architecture_as_code_maturity_model.md) |
| Purpose | Six maturity levels, from ad hoc to innovative and AI-assisted, assessed across ten "as code" disciplines with a checklist of 50 yes/no questions, plotted on a radar chart. |
| Use when | An organisation wants to know how far its codification of infrastructure, architecture, policy, governance, compliance, testing, documentation, knowledge and management has gone. |
| Inputs | Answers to the checklist, one question at a time. |
| Outputs | A radar chart; prioritised improvement suggestions with chapter references; a JSON export that can be re-imported; a PDF report. |
| Full template | Architecture as Code, architecture_as_code_maturity_model.md; the tool is maturity_model_radar.html |
The levels are Level 0 (initial, ad hoc), Level 1 (repeatable and version-controlled), Level 2 (defined and automated), Level 3 (managed and integrated), Level 4 (optimised and AI-assisted) and Level 5 (innovative, next-generation). The book's procedure has six steps: assess the current position (taking the lowest common level as the baseline), identify gaps, plan to move up one level at a time, invest in people and culture, automate validation and evidence collection early and prepare for AI augmentation. The Radar is an interactive HTML tool: the user answers the checklist, the tool plots the radar, lists suggestions and exports the answers. The first limit is the unit: the model assesses practices, not outcomes, so it cannot say whether a control works. The second is the self-assessment: nothing in the tool tests an answer. Use it to start a conversation and as an input to the next family of tools, not as evidence.
Maturity model (five levels, eight dimensions) and the maturity self-assessment
| Kind | Method (model) and artefact (self-assessment record) |
| Origin | AI Governance, Appendix B |
| Purpose | A self-assessment of governance maturity with five levels (Exploring, Piloting, Industrialising, Governing, Optimising) over eight dimensions (data, platform, model lifecycle, governance, security, evaluation, organisation, sustainability), with observable indicators and the step that most often unlocks the next level. |
| Use when | A governance function wants to see where the next investment belongs and to show progress to a board. |
| Inputs | Indicators per dimension and level; evidence; the previous assessment. |
| Outputs | A YAML record per assessment; the diff between two records is the progress report. |
| Identifier family | governance/maturity/assessment-*.yaml |
| Full template | AI Governance, Appendix B (self-assessment template) |
An organisation is at a level in a dimension when it meets the indicators of that level and of every level below it; one overall level, where needed, is the lowest dimension; the assessment is repeated twice a year with the same assessors. The book notes that four of the dimensions (platform, model lifecycle, security and evaluation) describe engineering rather than governance practice, and are included because governance maturity cannot outrun the platform that enforces it. The record of the book (abbreviated; the dimensions after the first are shortened in the original in the same way) is:
# governance/maturity/assessment-2026-11.yaml
apiVersion: ai-architecture.example.eu/v1
kind: MaturitySelfAssessment
metadata:
organisation: example-authority
scope: enterprise # enterprise | business-unit | agency | programme
assessedOn: 2026-11-15
nextAssessment: 2027-05-15
previousAssessment: governance/maturity/assessment-2026-05.yaml
dimensions:
sustainability:
currentLevel: 2
targetLevel: 3
targetDate: 2027-06-30
indicatorsMet:
- Costs attributed per use case through the gateway
indicatorsNotMet:
- No carbon accounting
evidence:
- reports/finops/2026-10.json
actions:
- id: SUS-01
description: Introduce Software Carbon Intensity estimates per model tier
owner: head-of-ai-governance
due: 2027-06-30
data: {currentLevel: 3, targetLevel: 4}
platform: {currentLevel: 4, targetLevel: 4}
summary:
overallLevel: 2
method: lowest-dimension
narrative: >
Sustainability is the constraining dimension and receives the next
investment.
The two models are not interchangeable. Their level scales differ (Architecture as Code counts from Level 0 to Level 5; AI Governance from 1 to 5), their subjects differ (codification of disciplines against governance of AI), and the word "optimising" means something different in each. Both take the lowest value as the overall result. Do not average across the two or report them under one name.
CSF profile as code with an AI focus
| Kind | Artefact, with the method Building a current and target CSF profile with an AI focus |
| Origin | AI Red Team, Chapter 3 and Appendix A (03_CODE_PROFILE); Chapter 27 for the summary of the two organisations |
| Purpose | Records current and target maturity per CSF Category, with targets for the three focus areas of the Cyber AI Profile (securing AI systems, AI-enabled cyber defence, thwarting AI-enabled attacks), the implementing controls and the obligations the same evidence serves. |
| Use when | A security function wants its CSF profile kept in version control over the controls and obligations it already maps. |
| Inputs | The CSF 2.0 Functions and Categories (53, NIST, 2024); the Cyber AI Profile (55, NIST, 2025); control identifiers; the obligations. |
| Outputs | A profile per organisation with current and target levels; a side-by-side summary. |
| Identifier family | HM-CSF-* (for example HM-CSF-2027); nordvik-region and hansa-mutual for the summary |
| Full template | AI Red Team, Appendix A (03_CODE_PROFILE) |
An entry in the book's example for the Category DE.AE gives current: repeatable and target: measured, a target and outcome for each of the three focus areas, three controls (CTRL-SOC-004, CTRL-SOC-011, CTRL-AGT-002) and two obligations (DORA Article 10; NIS 2 Article 21(2)(b)). The Cyber AI Profile is a preliminary draft at the time of the series and should be read as such. The CSF is a framework, not law. AI Purple adds that the profile can be kept as code over coverage records, and AI Blue maps its five blue-team functions to the CSF Functions; the frameworks themselves are the same ones in every volume.
Measurement and maturity references
| Name | Kind | Origin | What the series uses it for |
|---|---|---|---|
| NIST Cybersecurity Framework 2.0 | Framework | AI Red Team (all chapters); The Transformed Security Architect, Chapters 9, 11 and 19; AI Blue, Chapters 1, 2, 8, 10 and 11; AI Purple, Chapter 17; AI Operations, Chapters 1, 4, 19 and 32 | Six Functions and their Categories as the frame against which profiles, functions of a book and reports are organised (53, NIST, 2024). |
| NIST Cyber AI Profile (IR 8596, preliminary draft) | Framework profile | AI Red Team (all parts); AI Purple, Chapter 17 | Adds three AI focus areas to the CSF Categories (55, NIST, 2025). |
| NIST SP 800-55 Measurement Guide | Guide | AI Purple, Chapter 18 | A guide for selecting and developing information security measures (56, Schroeder et al., 2024), used behind the loop's board page. |
Reporting and transparency
The last family carries the result to the people who have to act on it or who are entitled to know it. Their audiences differ: a management body, a supervisor, workers and their representatives, the public. The series keeps the same discipline for all of them: each line of a report points at a record, and each record has a date.
Management report and the one-page report method
| Kind | Artefact (MGT-*) and method (One-page architecture report for a management body) |
| Origin | The Transformed Security Architect, Chapter 19 |
| Purpose | A generated one-page, quarterly report for a management body, with decisions asked, indicators, control status and provenance. |
| Use when | A board or executive committee receives architecture and security status and must be able to ask where each figure came from. |
| Inputs | The control catalogue and its test results; indicators; decision records. |
| Outputs | A page per quarter, generated from the repository. |
| Identifier family | MGT-* (for example MGT-HM-2026-Q4) |
Because the page is generated, it cannot drift from the catalogue it summarises, and its provenance can be inspected. AI Governance (Chapter 16) supplies the companion artefacts: the AI risk report to the management body, the entity reporting profile (reporting/profiles/entities.yaml, one per group entity) and the one-page report is its quarterly form.
Board page for the loop (LPG-) and verification status (BTP-)
| Kind | Artefacts |
| Origin | AI Purple, Chapters 11 and 18 and Appendices A and B.18 |
| Purpose | A one-page quarterly board report on the purple loop, and the computed status that sits behind each of its lines. |
| Use when | A board is told that the organisation's defences have been tested, and wants to know what share of the priority techniques is verified within an expiry and why the rest is not. |
| Inputs | Coverage records and their evidence ages; retest results; a debt list; the independence statement for AI work. |
| Outputs | A page with the verified share, the generalisation gap, the learning cohorts, the debt, the AI work and the decisions requested; a status that lists every non-verified technique with a reason and an action. |
| Identifier family | LPG-*, BTP-* |
The rule behind both is AI Purple's own: no chapter says that something is covered without saying what was tested, when and with what result. In the example, 27 of 34 priority techniques are verified within expiry (against a baseline of 25), seven are not (evidence expired, retest failed, never tested), and the oldest passing test is 81 days old against an expiry of 90. The reporting level is team, never by person, with a minimum group size of five. AI Purple's decision record for the loop (AIDR-08xx, with AIDR-0800 to 0849 for Nordvik Region and 0850 to 0899 for Hansa Mutual) answers a board-level question and ties the page to a decision.
Transparency to affected people
Four artefacts carry transparency to those whom a system affects, and each names the provision it serves. The system-level transparency record (AI Governance, Chapter 10) is a JSON record of system-level information in the style of Article 13 of the AI Act. The transparency notice to affected persons (same chapter) is a plain-language notice to residents about automated triage. The FRIA summary for publication and the legal-basis / algorithm descriptor (AI Governance, Chapter 17) are the public-sector counterparts: a publishable summary of the fundamental rights impact assessment and a JSON record of the legal basis for administrative use of AI. For workers, AI Boss (Chapter 28) defines the worker information notice (WIN-*), which tells workers and their representatives which systems manage them, at which degree, with which data and how to contest, serving Article 26(7) of the AI Act, the GDPR and the Platform Work Directive; the transparency register (management/transparency-register.yaml) lists inside the organisation the systems that take part in managing people with their notices and profiles; and the explanation template (Appendix B.9) gives the affected person the main factors, the role of the system and of the human decider and the route to contest. Chapter 22 treats these as tools for managing people with AI; they are named here because they are also the reporting artefacts of the same mapping.
Across the usage modes
The mapping and maturity tools do not depend on how AI is used: a matrix row, a register entry or a maturity record is the same artefact whether the system is Mode 0 Ambient AI or Mode 5 Autonomous production agents. What changes is the content of the rows, and the series says so in four places.
| Tool | How it differs across usage modes and degrees of delegation | Origin |
|---|---|---|
| Control catalogue entry | For an agent that acts with its own identity, entries such as CTRL-AGT-002 require tool calls outside the permission manifest to be denied outside the agent; the evidence is platform telemetry, with seven-day freshness in the example. |
The Transformed Security Architect, Chapter 9 |
| Oversight-quality metric and record | The record states the recorded degree (for example Level 2 Supervised) and the trigger that changes it; Level 4 Autonomous is never used for an M3 Consequence in AI Boss, so the metric guards the higher levels below it. | AI Boss, Chapter 26 |
| Review protocol and oversight report | Review tiers, seeded-incident rates and proposal caps apply to what AI proposes to a blue team; the report states proposals reviewed, the caught-seed rate and the reproduction rate. | AI Blue, Chapter 14 |
| Obligation register and board page | Where AI sits on both sides of a check, an independence statement (IND-*) with an age and a validity date accompanies the figures. |
AI Purple, Chapters 15 and 18 |
| Regulation-to-control mapping record | A row exists for the delegation profile (ceilings, budget and stop path), covering functions O3 and O4. | AI Operations, Chapter 23 |
Nordvik Region and Hansa Mutual
Nordvik Region is the regional public authority among the two organisations of the series. Its AI governance example is the benefits-triage system, whose caseworker override control is tested by TP-AI-014. Its control catalogue (nordvik-controls) started with ten entries. In AI Operations it applies the Swedish Cybersäkerhetslag to its Tier 1 services as an essential operator and has no DORA register, and its mapping record lacks evidence for the continuity rows because the portal failover test failed (RST-NR-2027-002); the claim stays withdrawn until a re-test passes. Its oversight-quality metric for roster approval (OQM-NR-ROS-01) was agreed with the two unions and reports at least five people at a time.
Hansa Mutual is the larger financial group with entities in several countries. It keeps a catalogue (CTRL-AGT-002 above), an article-to-control mapping for its claims-triage agent (MAP-HM-CLAIMS-TRIAGE-01), market overlays for the UK and Swiss entities, a CSF profile (HM-CSF-2027), the loop's obligation register (OBL-HM-2028-01, owned by the white-team lead) and board page (LPG-HM-2028-Q1), and, with DORA as its regime, the mapping record RCM-HM-OPS-2028-01, owned by the head of operational resilience independently of operations. Its claims-core restore test failed on time, so the row reads failed. The two organisations thus show the same tools at different weights: Nordvik Region has the duties of an essential operator and little evidence yet, and Hansa Mutual has more duties, to a financial supervisor, with more evidence and more seams.
Entries treated and entries left to other chapters
The slice for this chapter holds 132 inventory entries. This chapter treats or names 76 of them, in the principal entries above and in the family tables, and Appendix A lists every entry with its origin and purpose. The remaining 56 entries belong to neighbouring chapters and are left to them: pipeline definitions, Rego policies, infrastructure templates and the tools of supply-chain assurance (Chapters 5 and 6), classification and risk (Chapter 7), supplier terms (Chapter 9), response clocks (Chapter 13), restore and capacity measures (Chapters 15 to 17), decision forums, roadmaps and plans (Chapters 4 and 24), and the tools for roles, competence and managing people (Chapters 21 and 22). They are listed by name in the findings file of this chapter under "Reassign", for the editor.
Summary
The tools of this chapter answer three questions in a fixed order: which obligation applies and which control answers it, whether the control works according to someone independent of its owner, and where the organisation stands. The mapping tools differ in what they refuse to leave out: the Control Mapping Matrix requires an assurance artefact, the AI Act mapping a gate and a resolvable evidence path, the obligation register and the regulation-to-control record an evidence age and an owner. The catalogue is where the answer lives, and an entry without a test is a statement. Assurance needs the audit test procedure and a metric that shows whether human oversight is real, and the series' rule that such a metric is reported for groups and never to evaluate individuals is the condition on which the representatives agree to it. The maturity models measure practice, not outcome, and a self-assessment that nobody tests is a conversation starter.
Two conclusions of this chapter are its own. First, the tools form one chain from article to board page, and the chain is only as strong as its weakest field: a mapping without an evidence age, or a report without a link to a record, breaks it. Second, the same names are used for different things in different volumes (the OQM-* and CTRL-* families, the word "optimising"), so a reader who combines tools from several volumes must check which definition applies; Chapter 25 draws the cases together.
Sources
- Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
- Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
- Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
- Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
- Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (5, Nordqvist, 2026)
- Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
- Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
- Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
- Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
- Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). (50, NIST, 2023)
- NIST. The NIST Cybersecurity Framework (CSF) 2.0. (53, NIST, 2024)
- National Institute of Standards and Technology. Security and Privacy Controls for Information Systems and Organizations. (54, NIST, 2020)
- National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (55, NIST, 2025)
- Schroeder, K., Trinh, H., Pillitteri, V. Measurement Guide for Information Security: Volume 1, Identifying and Selecting Measures. (56, Schroeder et al., 2024)
- International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. (57, ISO/IEC, 2022)
- International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. (58, ISO/IEC, 2023)
- National Institute of Standards and Technology, Joint Task Force. Assessing Security and Privacy Controls in Information Systems and Organizations. (59, NIST, 2022)
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. (60, NIST, 2024)
- National Institute of Standards and Technology. OSCAL: the Open Security Controls Assessment Language. (61, NIST, n.d.)
- Bengio, Y. International AI Safety Report 2026. (131, Bengio et al., 2026)
- Institute of Internal Auditors. The IIA's Three Lines Model: An update of the Three Lines of Defense. (132, Institute of Internal Auditors, 2020)
- European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
- European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (196, European Union, 2016)
- European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (197, European Union, 2022)
- European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (198, European Union, 2022)
- European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). (199, European Union, 2026)