The Control Catalogue, Evidence and Assurance as the Architect's Artefacts

Every conclusion in the earlier volumes of the series ends in a control: a rule that a policy point enforces, a test that a pipeline runs, a record that someone can inspect. The controls were built in four different books and live in four different places. Someone has to hold them together, say which threat each one answers, which obligation each one helps to meet and whether it works today. This chapter argues that this someone is the security architect, and that the three artefacts through which the work is done are the control catalogue, the evidence manifest and the assurance relationship with the people who test the architect's work. It concerns Shift 1, from documents to code, because the catalogue, the mappings and the evidence are versioned and testable instead of living in a spreadsheet and a folder of screenshots, and Shift 3, from periodic to continuous, at machine speed, because a control that is verified once a year is declared for the other 364 days, and agents now change the estate daily.

The chapter does not read the regulations; Chapter 18 does. Here the instruments appear only as columns in a mapping.

Figure 9.1: The catalogue sits between the threats a control answers and the obligations it helps meet; each control is built from a configuration and a test, produces signed evidence and is classified as verified, declared or failed, and auditors read the same artefacts.

Why the catalogue is the architect's artefact

AI Platform and Security, Chapter 17, concluded that every threat names a control, every control names a configuration and every configuration produces evidence, and that a pipeline should fail when a threat has no control or a control has no owner (169, Nordqvist, 2026). Architecture as Code (Chapter 9C) had earlier made risk a versioned record with an owner and expiring exceptions (167, Nordqvist, 2025), and Architecture as Code (Chapters 10 and 11) had set the principle of assure once, comply many: write a control once and map it to every obligation it serves (167, Nordqvist, 2025). This book builds on those conclusions and asks who maintains the joins.

In many organisations nobody does. Controls are described in policy documents, implemented by platform and operations teams, listed in a spreadsheet for the annual management review and evidenced by screenshots collected when an audit is announced. Each of the four has a different owner and vocabulary, and the connections between them exist in the heads of the people who built them. The security architect sees all four, and the control catalogue records what the architect sees.

Three connections need an owner. The first runs from threat to control: the threat models of Chapter 6 name the controls that answer each threat, and the catalogue holds an entry for each. The second runs from control to boundary: the containment profiles and permission manifests of Chapters 7 and 8 are the configurations the catalogue points to. The third runs from control to obligation: ISO/IEC 27001 Annex A, NIS 2, DORA, the AI Act and national schemes each ask for measures the catalogue must show to be in place (23, ISO/IEC, 2022). The architect does not operate the controls. A platform team operates the gateway, an operations team patches, and a named system owner answers for each system. What the architect owns is the catalogue's structure, the quality of each entry and the correctness of each mapping.

That ownership has a limit. An architect who designs a control and also declares that it works marks their own work, so the catalogue leaves the judgement that a control is effective to a test and, above that, to people independent of the architect.

Anatomy of a control entry

A control entry is complete when a stranger can answer five questions from the entry alone: what is this control meant to prevent, detect or correct, who is accountable for it, where is it implemented, how is it tested and where is the proof. The fields are these.

• Identifier. CTRL- followed by a domain code and a number, as in CTRL-AGT-002. The identifier never changes and is never reused, so that old evidence and old decision records keep their meaning.
• Objective. One sentence in the form of a property that can be falsified: an agent cannot call a tool that its manifest does not name. An objective that cannot be falsified, such as "access is appropriately managed", cannot be tested and so cannot be verified.
• Owner and architect. The role that answers for operation, and the architect accountable for the design and the mappings. Roles, not personal names, because people move.
• Threats. The identifiers from the threat model or the AI threat register that the control answers (THR-*; AI Threat, Chapter 32).
• Implemented by. A path that the pipeline resolves to a configuration, a policy rule or a contract clause. If the path disappears, the build fails. This single rule removes the most common catalogue defect, the control that lingers in the audit table after the configuration behind it was renamed or deleted.
• Dependencies. The shared components on which the control relies: a tool gateway, an identity provider, a log store, a supplier. These matter for coverage, as the section on coverage explains.
• Test. The procedure that re-runs the scenario the control guards against, its cadence and the events that trigger an extra run.
• Evidence. The query or artefact that shows the control operating, a fail condition stated as what would be seen if the control had failed, and the maximum age of acceptable evidence.
• Mappings. The obligations and framework clauses the control helps to meet, each with the relation (satisfies, supports or partly addresses) and the person who reviewed it.
• Exceptions. Accepted deviations, each with an owner, a reason and an expiry date, following the risk-as-code pattern of Architecture as Code (Chapter 9C).
• Status. Verified, declared or failed, derived by a rule and not typed in.

Two choices deserve comment. Test and evidence are separate fields because a control can be tested rarely and observed constantly: a containment test may run quarterly, while a daily query of the gateway's denial log shows the control still being applied between tests. And the fail condition names the observation that would prove failure, which makes the control falsifiable; an evidence query that describes success invites confirmation.

The catalogue uses the vocabulary of existing catalogues on purpose. NIST SP 800-53 shows how a large catalogue can be organised into families with stable identifiers and assessment procedures (32, NIST, 2020), and ISO/IEC 27002 gives each of the 93 controls of the 2022 edition of Annex A an attribute and a purpose (24, ISO/IEC, 2022). The architect's catalogue copies neither: it holds the organisation's own controls, each tied to a configuration that exists, and treats the standards as obligations to map to.

Worked example: A control entry and its evidence manifest

Illustrative example. The entry below belongs to Hansa Mutual's catalogue of about 180 controls. CTRL-AGT-002 is the control that the series has used since AI Platform and Security: a policy decision point outside the agent denies any tool call that the agent's permission manifest does not name. The identifiers of the test and of the evidence-collection agent are fictional.

# Illustrative. catalogue/agents/CTRL-AGT-002.yaml
id: CTRL-AGT-002
title: Tool calls outside the permission manifest are denied outside the agent
objective: >
  An agent with an identity of its own cannot call a tool or reach a
  resource that its permission manifest does not name, whatever it is told.
owner: head-of-group-ai-platform
architect: ai-domain-security-architect
threats: [THR-HM-03]
applies_to: [claims-triage-agent, it-operations-agent, HM-SEC-001]
implemented_by: policies/ai/agents/permission_manifest.rego#deny_unlisted_tool
depends_on: [tool-gateway, policy-decision-point]
test:
  id: RT-LIB-AGT-004
  kind: containment-test
  cadence: quarterly
  also_on: [policy-change, manifest-change]
  max_result_age_days: 100
evidence:
  source: evidence://tool-gateway/denials?window=30d
  fail_condition: any_allowed_call_absent_from_manifest
  max_age_days: 2
mappings:
  - {framework: iso_iec_27001, refs: [A.5.15, A.5.18, A.8.2], relation: satisfies}
  - {framework: iso_iec_42001, refs: [A.6, A.9], relation: supports}
  - {framework: nis2, refs: ["21(2)(f)", "21(2)(i)"], relation: supports}
  - {framework: dora, refs: ["9"], relation: supports}
  - {framework: ai_act, refs: ["14", "15"], relation: supports}
  - {framework: uk_operational_resilience, owner: uk-local-security-officer, relation: pending-review}
  - {framework: swiss_finma, owner: swiss-local-security-officer, relation: pending-review}
exceptions: []
status: verified   # applied by the classification rule, confirmed on the pull request

The manifest below is what the evidence-collection agent publishes for the controls in scope each morning. It references the entry by identifier and carries the hashes of what was read, so that the proof of what happened does not depend on trusting the agent that gathered it.

# Illustrative. evidence/manifests/2026-11-05.yaml
apiVersion: evidence.example/v1
kind: EvidenceManifest
metadata:
  catalogueCommit: 4d2a9c1
  producedAt: 2026-11-05T06:00:11Z
  producedBy: HM-EVC-001
  collectorLevel: 3-bounded
controls:
  - id: CTRL-AGT-002
    status: verified
    confirmedBy: ai-domain-security-architect
    evidence:
      - type: denial-log-query
        uri: evidence://tool-gateway/denials?window=30d
        sha256: "9c1e0d73aa41"
        result: no-allowed-calls-outside-manifest
        ageDays: 0
      - type: containment-test
        uri: evidence://red-team/RT-LIB-AGT-004/2026-q3
        sha256: "71d0b5e2c9f3"
        result: pass
        ageDays: 44
    sharedDependencies: [tool-gateway]
attestation:
  format: in-toto
  signature: evidence://attestations/2026-11-05.sig

Three details carry the argument. The United Kingdom and Swiss mappings are marked pending review, because the local security officers own them and the entry's classification does not depend on them. The test and the evidence query have separate ages and limits. And the manifest names the shared dependency, the tool gateway, which the coverage section uses. The clause references are illustrative and are checked against the editions in force.

Mapping once to many obligations

A single control usually serves several obligations. CTRL-AGT-002 helps to meet an access-control measure in ISO/IEC 27001 Annex A, a risk-management measure under NIS 2 Article 21(2) (6, European Union, 2022), the ICT risk-management duties of DORA Article 9 (9, European Union, 2022) and the human-oversight and cybersecurity requirements of the AI Act, Articles 14 and 15 (1, European Union, 2024). Written four times, the control would drift into four slightly different controls with four sets of evidence. Written once and mapped four times, the control is tested once and the result serves every column.

The mapping is a claim, and claims need review. A mapping says that this control, as configured, helps to meet that clause, and a person who understands both makes the judgement. The entry therefore records the relation (satisfies, supports or partly addresses), the reviewer and the date. A tool, and increasingly an AI agent, can propose mappings from the text of a clause, and Chapter 14 treats the verification of such proposals. What the architect keeps is the decision that a mapping is correct, because the organisation relies on that decision when it answers a supervisor.

Once the mappings are data, the view from obligation to controls is generated and never written by hand. ISO/IEC 27001 requires a statement of applicability that lists the controls chosen and the justification for including or excluding each Annex A control (clause 6.1.3), and the catalogue produces that statement as a report (23, ISO/IEC, 2022). An AI management system under ISO/IEC 42001 adds its own Annex A controls as a further column (27, ISO/IEC, 2023). Where an entity falls under Commission Implementing Regulation (EU) 2024/2690, the technical and methodological requirements it sets for the entity types it covers become another column (7, European Commission, 2024), and the regulatory technical standards on ICT risk-management tools, methods, processes and policies under DORA become a further one for financial entities (10, European Commission, 2024). National schemes enter in the same way. BSI's IT-Grundschutz Compendium is a German catalogue of requirements by module (162, BSI, 2023), and BSI's C5 criteria catalogue is the basis on which cloud providers obtain audit reports that a customer can read as evidence of supplier-held controls (161, BSI, 2020).

When the instruments change, the catalogue changes by pull request, and the diff shows which mappings are affected. For organisations that need to exchange catalogues, profiles and assessment results with tools or authorities, NIST's Open Security Controls Assessment Language defines machine-readable formats for catalogues, profiles, assessment plans and assessment results (188, NIST, n.d.). OSCAL is observable as a published NIST standard. Its use between European supervisors and regulated entities is not established, so the architect keeps the schema simple enough to export to it without committing to it.

Practical guide: Turning a spreadsheet of Annex A controls into a catalogue as code

Purpose. Replace the spreadsheet kept for the annual management review with a catalogue in version control, without importing the spreadsheet's faults.

Roles. The security architect leads. The CISO approves the schema. Control owners confirm the entries that name them. The records officer or equivalent agrees which entries are sensitive.

Steps.

1. Freeze the spreadsheet at its last management-review state and commit it as read-only history.
2. Write the schema first, with a validator that rejects an entry missing an owner, an objective, a test or an evidence source.
3. Do not turn the 93 Annex A rows into 93 entries. An Annex A row is a requirement and a catalogue entry is a control, and one requirement may need several controls while one control may serve several rows. Begin from controls that exist: choose 10 to 20 for which a configuration, a contract clause or a procedure can be named, and write those entries first.
4. For each entry, point implemented_by to a real path. If the control is a contract clause, point to the clause in the contract repository or the tender annex.
5. Map each entry to the Annex A rows it helps to satisfy, recording the relation and the reviewer.
6. Write entries for the remaining applicable rows as declared entries with the honest statement that no test exists yet. A declared entry is a known gap, not an error.
7. Generate the statement of applicability and the management-review table from the catalogue and compare them with the spreadsheet. Resolve every difference by correcting one of them.
8. Run both for one review cycle, then retire the spreadsheet.

Definition of done. The validator passes in the pipeline; every applicable Annex A row appears in the generated statement either with a control or as a recorded gap; every entry has a named owner role; the management review is held from the generated report; and the spreadsheet is archived.

Nordvik's migration shows the guide at small scale.

Worked example: The first ten entries of Nordvik Region's catalogue

Illustrative example. Nordvik's catalogue starts with ten entries chosen because the Region holds the risk and a supplier holds the control. The statuses are those of the first generated report. Contract identifiers are those of the Region's agreements; the owner roles are fictional.

# Illustrative. catalogue/controls.yaml, first ten entries (AIDR-0502)
catalogue: nordvik-controls
version: 2026.11
entries:
  - {id: CTRL-SUP-001, objective: Decision logs of the benefits-triage system exported to the Region archive, held_by: TriageSoft, owner: system-owner-benefits, annex_a: [A.8.15, A.5.33], test: monthly export with hash comparison, status: declared}
  - {id: CTRL-SUP-002, objective: A stop path outside the supplier system that the Region can trigger, held_by: TriageSoft, owner: system-owner-benefits, annex_a: [A.5.20, A.5.22], test: drill with named Region holders, status: declared}
  - {id: CTRL-SUP-003, objective: Supplier incidents notified to the Region within the contract time, held_by: TriageSoft, owner: ciso, annex_a: [A.5.19, A.5.24], test: notification drill, status: declared}
  - {id: CTRL-SUP-004, objective: Sub-processor and model changes notified before they take effect, held_by: european-cloud-provider NR-2026-031, owner: platform-team-lead, annex_a: [A.5.21, A.5.22], test: contract change log review, status: declared}
  - {id: CTRL-IAM-001, objective: Caseworker access to the triage system through the Region identity provider with strong authentication, held_by: region, owner: platform-team-lead, annex_a: [A.5.15, A.8.5], test: weekly identity provider export, status: verified}
  - {id: CTRL-LOG-001, objective: Managed security service provider detects Region-specific scenarios and not only default rules, held_by: mssp NR-2025-044, owner: ciso, annex_a: [A.8.16], test: replay of five Region scenarios, status: failed}
  - {id: CTRL-AIG-001, objective: Only approved models are reachable through the AI gateway, held_by: region, owner: platform-team-lead, annex_a: [A.8.9], test: gateway configuration snapshot, status: verified}
  - {id: CTRL-AGT-001, objective: The Mode 3 work tool acts only within MND-NR-01, held_by: region, owner: security-architect, annex_a: [A.8.2], test: permission audit of the tool, status: verified}
  - {id: CTRL-BKP-001, objective: Case data of the triage system restored from backup within the agreed time, held_by: TriageSoft, owner: system-owner-benefits, annex_a: [A.8.13], test: annual restore test, status: declared}
  - {id: CTRL-REC-001, objective: Architecture decision records archived under the archives law, held_by: region, owner: records-officer, annex_a: [A.5.33], test: quarterly archive sample, status: verified}

Four are verified, five declared and one failed. The Region's own controls are verified because the evidence is its own to collect. Most supplier-held controls are declared because the only evidence so far is the supplier's statement, and the first generated report makes that visible. The failed entry shows the other use of the catalogue: the replay of five Region-specific scenarios found that the managed security service provider's detections cover only some of them, and the finding goes to the CISO for the contract discussion that Chapter 10 describes. The Region's public-access rules apply to the repository like any other record, so the architect agrees in advance with the records officer which entries are security-sensitive.

Evidence as a by-product

AI Governance, Chapter 11, concluded that evidence is a by-product of delivery and that attestation is a person asserting where evidence is machine-generated (168, Nordqvist, 2026). Architecture as Code (Chapter 15A) described the mechanics: automated checks capture evidence deterministically, store it in immutable storage with a cryptographic signature and link it to the commit and the change that produced it (167, Nordqvist, 2025). This book adds the observation that the catalogue is what makes the by-product usable. Evidence without a control to attach to is a pile of files, and a control without evidence is a statement of intent.

The evidence for a control comes from one of four kinds of source.

• Policy evaluation. The policy engine's decision logs and the result of evaluating a rule against a snapshot, as with Open Policy Agent, whose unit tests and evaluations can be run by a pipeline and stored (62, Open Policy Agent, n.d.).
• Configuration and telemetry. Snapshots of the effective configuration, denial logs from the gateway, the identity provider's records and the results of scans.
• Test results. The output of containment tests, red-team scenarios, restore tests and stop-path drills, each tied to the control it exercises.
• Declared records. Training completions, approvals and meeting minutes, produced by people. These are evidence that a person asserted something, and the catalogue treats them as such.

A signature binds an artefact to the identity that produced it and the time it was produced, and Sigstore provides keyless signing and verification for software artefacts (52, Sigstore, n.d.). The in-toto attestation framework defines a format for statements about artefacts, such as which pipeline produced them and what checks they passed (190, in-toto Project, n.d.), and the evidence manifest of AI Governance uses it. The store is append-only with retention locks, and each manifest refers to the previous one, so that deleting or editing a past record is detectable.

Two cautions apply. First, the pipeline that collects evidence is itself a control and appears in the catalogue, with an owner, a test and a fail condition. An evidence collector that silently stops produces no evidence and no alarm, which looks identical to a control that is working. The maximum age on each evidence item catches this: evidence older than its limit turns the control from verified to declared on the day it expires. Second, evidence that the system produces about itself is weaker than evidence produced from outside it. The denial log of a gateway is credible when the gateway is outside the agent it constrains. It is not credible when the agent writes it.

NIST SP 800-137 describes information security continuous monitoring as maintaining ongoing awareness of security, vulnerabilities and threats to support risk decisions (192, Dempsey et al., 2011). In the catalogue, the cadence is the monitoring frequency and the maximum age is the point at which monitoring has lapsed.

Verified, declared and failed

AI Threat, Chapter 30, concluded that a control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and that, for containment, it has to hold without the cooperation of the system it contains (171, Nordqvist, 2026). The classification follows from that conclusion.

Status	Condition	What it means for the reader of a report
Verified	The control's test passed within its cadence and the evidence is machine-generated and within its maximum age	The control worked when last tested and is still operating
Declared	The control exists on paper or in configuration, but no test has passed within its cadence, the evidence is stale or the only evidence is an attestation	The control is claimed, and the claim has not been checked recently
Failed	The last test failed, or the evidence query returned its fail condition	The control did not work, and a finding is open

The classification is deliberately blunt. There is no amber and no percentage: a control that is nearly verified is declared, and the pressure to move it is the point. The classes also resist the drift in compliance reporting where the number of controls "implemented" rises while nobody can say how many work.

Classification is applied by a rule, and the rule is owned by the architect and reviewed by the CISO. The pipeline applies it mechanically, so the owner of a control cannot type its status in. A change to the rule, an accepted exception and a promotion from declared to verified are decisions by named people, made on a pull request. The evidence-collection agent refreshes the evidence the rule reads but cannot alter the rule, the tests or the exceptions.

Shared dependencies undermine counting. Two controls that depend on the same tool gateway, the same identity provider or the same model provider fail together, and presenting them as two layers overstates the defence. Charles Perrow's analysis of normal accidents is the standard reference for why failures that appear independent combine in complex, tightly coupled systems (79, Perrow, 1984). The entry therefore lists its dependencies, and the coverage view counts controls with a common dependency as one.

Practical guide: Classifying controls as verified, declared or failed

Purpose. Give every control in the catalogue a status that a board, an auditor or a supervisor can rely on, and turn every status other than verified into a finding with an owner.

Roles. The architect owns the classification rule. Control owners own the tests and the findings. A named architect confirms promotions to verified. The evidence-collection agent supplies inputs and writes none of the statuses.

Steps.

1. Set a cadence for each control from its risk. As defaults, test preventive technical controls on every change and weekly; test containment controls and stop paths quarterly and on any change to the policy or manifest they enforce; test procedural controls and supplier-held controls at least twice a year. Shorten these where the organisation's risk appetite is lower, and write the reason into the entry.
2. Set the maximum age of evidence at twice the cadence for tests and at two days for continuous telemetry. Evidence older than this limit makes the control declared.
3. State the fail condition for each evidence query before the first run.
4. Check that the test is independent of the control. A test must not call the component under test to decide whether it passed. Where the control is a containment, the test must hold when the contained system does not cooperate.
5. Run the rule. Verified requires a passing test within cadence and machine-generated evidence within age. Anything with attestation only, a missing test or stale evidence is declared. Any failing test or returned fail condition is failed.
6. Open a finding for every control that is declared or failed, with an owner, a date and a re-test. Close a finding when the test passes again, never on a statement.
7. Review shared dependencies quarterly and update the coverage view.
8. Report the counts by status to the CISO monthly, generated from the catalogue.

Definition of done. Every entry has a derived status; no status was typed by hand; every declared or failed control has an open finding with a date; and the report to the CISO was generated from the catalogue.

Coverage against threats

A catalogue shows what the organisation has; coverage shows what it is protected against. The join is the threat model: the threat models generated from architecture code (Chapter 6) name the controls that answer each threat, and the catalogue holds the entries those names refer to. AI Threat, Chapter 30, introduced the control-to-threat coverage matrix, which joins the AI threat register to the control catalogue, records shared dependencies and turns each gap into a finding (171, Nordqvist, 2026). The security architect maintains the join, and the rules that follow are checks in the pipeline.

• A threat with no control fails the build. A control that answers no threat is a candidate for retirement.
• A control without an owner role, a test or an evidence source fails the build.
• An observable or expected threat needs at least one verified preventive control and one verified detective control, counted after merging controls that share a dependency. This is the rule that Hansa's coverage matrix applies, and the organisation may set a stricter one.
• A threat that is covered only by declared controls is reported as a gap, not as coverage.

The distinction between counting controls and counting protection becomes concrete in Hansa's estate. The claims-triage agent, the IT-operations agent and the security operations agent each have their own permission manifest, but CTRL-AGT-002 enforces all three through the same tool gateway. Three agents protected by one control that depends on one gateway are one point of failure, and the coverage view says so. The finding may lead to a second, independent control, such as detection on the downstream systems the agents call, or to an accepted risk with an expiring exception.

The CSF profile of AI Red Team, Chapter 3, is another view over the same data. It maps each Category of NIST CSF 2.0 to the controls that serve it and to the obligations it helps meet (170, Nordqvist, 2026), so that boards and supervisors are answered from the programme's own evidence (29, NIST, 2024). Findings from exercises, red-team campaigns, chaos experiments and incidents end as verified controls once the re-test passes, the purple loop of the same volume.

The architect and the auditor

Auditors do not become unnecessary when evidence is code, but their work changes. The Three Lines Model of the Institute of Internal Auditors places operational management and risk and control functions in the first and second lines and internal audit in the third, independent of the first two and reporting to the governing body (191, Institute of Internal Auditors, 2020). DORA expresses a similar separation for financial entities, requiring segregation of ICT management, control and internal audit functions and an internal audit of the ICT risk-management framework (Article 6(4) and (6)) (9, European Union, 2022). The architect designs and maintains the controls and so sits on the design side of that line; internal and external auditors give the independent opinion, which is a reason to keep the architect's artefacts open to them.

NIST SP 800-53A describes three assessment methods: examining artefacts, interviewing people and testing the control (189, NIST, 2022). With a catalogue as code, the first becomes a query of the repository and the evidence store, the second is reserved for what no artefact can show, such as why a mapping was judged correct, and the third becomes something the auditor can do alone. This changes what the auditor needs from the architect.

• Read access to the sources. A read-only identity on the catalogue repository and the evidence store, so that the auditor reads the controls, the history of every change and the evidence directly. The architect does not curate what the auditor sees.
• Reproducibility. Every evidence query can be run again, and every test can be re-performed in a non-production environment. The auditor re-performs a sample of tests and compares the result with the recorded one.
• Explanation of judgement. Mappings, thresholds, cadences and exceptions are the architect's decisions, and the auditor tests them. The reasoning is written in the pull request.
• Evidence about the evidence. The collection pipeline, the signing keys and the classification rule are controls, and the auditor tests them like any other.

Independence needs to be built in. The architect has no write access to the evidence store. The auditor does not write controls and does not approve designs, since an auditor who has designed a control cannot give an independent opinion on it. Where an auditor finds a defect, the architect fixes the control through a pull request, and the auditor's finding stays open until a re-test passes. Because auditors may not read code, the architect also provides generated views: the statement of applicability, the obligation-to-control table, the list of declared and failed controls and the exceptions register.

Observable. Some organisations already give auditors read-only access to repositories and evidence stores and let them sample machine-generated evidence. Expected. Supervisors will rely on machine-generated evidence in place of attestation, supported by the direction of the decided instruments: NIS 2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures (6, European Union, 2022), and DORA Articles 24 and 25 set requirements for the testing of digital operational resilience (9, European Union, 2022). Acceptance will be uneven across regimes and supervisors, and the architect plans to supply both forms until it is not. Speculation. Continuous machine-checked assurance could replace the periodic audit visit altogether. No decided instrument or documented practice supports this at present.

Keeping the catalogue alive

A catalogue decays unless it is maintained at the rate the estate changes. The cure is the same as for code.

Change by pull request. Every change to an entry, a mapping, a cadence or an exception is a pull request. A code-ownership rule routes changes to the fields that carry judgement, which are the mappings, the classification rule and the exceptions, to the security architect, a mechanism AI Platform and Security, Chapter 17, set up for the threat model. The merge is the decision record, and significant changes also receive an AI Decision Record or an Architecture Decision Record.

Retirement. A control is retired when its threat no longer exists or a stronger control replaces it. The entry changes status to retired, keeps its identifier and its history, and remains readable, because evidence recorded under the identifier must still make sense during its retention period.

Expiring exceptions and mapping drift. An accepted deviation has an owner, a reason, a compensating measure and an expiry date, and a control with an expired exception is reclassified without anyone remembering to do it. When an instrument is amended, the pipeline lists the affected mappings by instrument and article, so that the architect's review is bounded.

Measures of the catalogue itself. The share of controls that are verified, the median age of evidence and the time from a control failing to a finding being opened show whether it is alive.

The agent that refreshes evidence links. Collecting evidence, refreshing links to it, checking its age and reporting what is stale are tasks well suited to an agent. They are repetitive, they require reading and not changing, and a mistake is cheap to reverse.

Across the usage modes and autonomy levels

The architect's own AI use and the agent in the estate differ in identity, and the difference decides who answers for what. In Modes 1 to 3, the architect uses an assistant with the architect's own identity to draft entries, propose mappings, read evidence or review a pull request, and the architect answers for the result. A Mode 5 agent acts with an identity and permissions of its own. The evidence-collection agent is such an agent.

Activity	Mode and identity	Autonomy level	Who decides
Drafting an entry or proposing a mapping	Modes 1 to 3, the architect's identity	Level 1 Assisted	The named architect reviews and merges
Reviewing a pull request that changes the catalogue	Modes 2 and 3, the reviewer's identity	Level 2 Supervised	The named reviewer approves
Refreshing evidence links and collecting telemetry	Mode 5, own read-only identity	Level 3 Bounded	The agent acts within its manifest; the actions are read-only and reversible
Computing the status from the rule	Pipeline, no AI	Not applicable	The rule, owned by the architect
Accepting an exception, changing a mapping or the rule, promoting a control to verified	People	Level 1 or Level 2	A named architect, on a pull request

The evidence collector may act at Level 3 Bounded because its actions are read-only and reversible and a policy decision point outside the agent enforces its scope. Level 4 Autonomous is not used here. Two rules protect the evidence: the agent has no write access to tests, exceptions, mappings or the classification rule, so it cannot make a control look better than it is, and it is itself in the catalogue, with a control, a test and a fail condition.

Nordvik Region and Hansa Mutual

Nordvik Region begins with the controls it must verify in suppliers' systems, recorded in AIDR-0502, as the worked example above shows: four of its first ten entries are verified, five declared and one failed, and the declared entries are almost all supplier-held. The Region mostly procures, so the catalogue's first use is to turn a supplier's statement into a recorded gap. Its single architect starts from the management-review spreadsheet, and the pipeline that generates the review table from the catalogue replaces the spreadsheet after one cycle.

Hansa Mutual has the catalogue and not the completeness. Its roughly 180 controls are mapped to ISO/IEC 27001, DORA and the AI Act, and the group's CSF profile and coverage matrix read it. Two things are missing. The mappings to the United Kingdom and Swiss regimes live with the local security officers outside the catalogue, and the architects bring them in as mappings entries that the officers own, reviewed by pull request, so that the Hamburg team does not become the author of regimes it does not operate. And much of the evidence is still attested. The team replaces attestation with generated evidence where it can, starting with the controls that protect the agents, and lets the Mode 5 evidence-collection agent refresh evidence links at Level 3 Bounded. Because the agent reads platform telemetry and pull requests, its rollout in each entity follows the works-council and union consultation described in the profile. Internal audit at Hansa is invited to sample the agent's work and not to repeat it: it re-performs a selection of tests, compares them with the recorded results and tests the control that governs the agent.

For Nordvik, Shift 1 means building the catalogue and extending it to controls the Region does not operate; for Hansa, it means completing the catalogue, bringing the regimes into it and shortening the distance between a control failing and someone knowing.

Summary

The control catalogue, the evidence manifest and the assurance relationship are the architect's artefacts because the architect is the role that sees the threats, the boundaries and the obligations together. A catalogue entry is complete when it names a falsifiable objective, an accountable owner, a configuration that exists, a test that re-runs the scenario, evidence with a stated fail condition and mappings that a named person has reviewed. Written once and mapped to ISO/IEC 27001, NIS 2, DORA, the AI Act and the national schemes, the control is tested once and serves every obligation.

Evidence is a by-product of operation when the catalogue gives it something to attach to: collected by machine, signed, kept in an append-only store and limited by a maximum age. The classification into verified, declared and failed follows from tests and evidence, a rule applies it, and people confirm promotions, exceptions and mapping changes. Shared dependencies count as one, so coverage measures protection and not the number of controls. An evidence-collection agent can refresh links and collect telemetry at Level 3 Bounded because its actions are read-only and reversible, and the judgements stay with named people at Level 1 or Level 2.

The chapter concerns Shift 1, from documents to code, in that the catalogue, the mappings and the evidence are versioned artefacts instead of a spreadsheet and a folder of screenshots, and Shift 3, from periodic to continuous, at machine speed, in that a control is verified for as long as its evidence is fresh and declared afterwards. Auditors read the same sources and re-perform tests, the architect explains judgement, and independence is protected by separating those who design controls from those who give an opinion on them.

Evidence that a control works is worth only as much as the speed at which the organisation notices that it has stopped. Chapter 10 takes up time: patch velocity, detection and the stop path as properties the architect specifies, measures and reports.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
2. 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). (6, European Union, 2022)
3. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (7, European Commission, 2024)
4. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
5. European Commission (2024). Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework. (10, European Commission, 2024)
6. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements. (23, ISO/IEC, 2022)
7. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection, Information security controls. (24, ISO/IEC, 2022)
8. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system. (27, ISO/IEC, 2023)
9. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (29, NIST, 2024)
10. National Institute of Standards and Technology, Joint Task Force (2020). Security and Privacy Controls for Information Systems and Organizations. (32, NIST, 2020)
11. Sigstore Project. Sigstore: Signing, verification and provenance for software artefacts. (52, Sigstore, n.d.)
12. Open Policy Agent Contributors. Open Policy Agent Documentation. (62, Open Policy Agent, n.d.)
13. Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. (79, Perrow, 1984)
14. BSI (2020). Cloud Computing Compliance Criteria Catalogue, C5:2020. (161, BSI, 2020)
15. BSI (2023). IT-Grundschutz Compendium, Edition 2023. (162, BSI, 2023)
16. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
17. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
18. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
19. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
20. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
21. National Institute of Standards and Technology. Open Security Controls Assessment Language (OSCAL). (188, NIST, n.d.)
22. National Institute of Standards and Technology, Joint Task Force (2022). Assessing Security and Privacy Controls in Information Systems and Organizations. (189, NIST, 2022)
23. in-toto Project. in-toto Attestation Framework. (190, in-toto Project, n.d.)
24. Institute of Internal Auditors (2020). The IIA's Three Lines Model: An update of the Three Lines of Defense. (191, Institute of Internal Auditors, 2020)
25. Dempsey, K. et al. (2011). Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. (192, Dempsey et al., 2011)