Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers

A security architecture that only its author understands protects nobody for long. The boundaries, controls and evidence that Chapters 5 to 11 describe are used by people who never read the model: a board that must approve risk and answer for it, a supervisor who asks what the organisation knows about itself, an auditor who samples, an engineer who needs to know today whether a change is acceptable, and a supplier who must be told what to build and what to prove. Each needs a different thing, in a different form, at a different speed. The traditional answer is to write a different document for each, and the documents drift apart within a quarter. This chapter describes the answer the transformed security architect gives instead: one architecture, held as a model, a control catalogue and an evidence manifest, from which every audience's view is generated, so that no audience is told something the others cannot check.

The chapter concerns two of the four shifts mainly and touches the other two. Shift 1, from documents to code, is what makes generated views possible: the model, the catalogue and the decision records are versioned artefacts, and a view is a query over them, not a document someone maintains. Shift 3, from periodic to continuous, at machine speed, is what the views must now report: patch velocity, containment test results, recoverability and control status are properties measured continuously, and an annual report on them is out of date before it is read. The chapter also touches Shift 2, from gatekeeper to boundary designer, in the messages that gates send to engineers, and Shift 4, from sole author to conductor of an AI team, in how the architect says honestly what AI contributed (Chapter 13).

One model and catalogue feeding generated views for the board, supervisors, auditors, engineers and suppliers, each with its form and its metrics

Figure 19.1: One architecture model, control catalogue and evidence manifest feeding generated views for five audiences, with the same five indicators and a return path for findings.

One architecture, several audiences

This section explains why communication is an architecture problem and sets the rule that every later section applies: a view is generated from the single source and never edited by hand.

The standard for architecture description says that an architecture is described through views, each addressing the concerns of identified stakeholders, and that the relations between views must be recorded so that they can be checked for consistency (28, ISO/IEC, 2022). Rozanski and Woods build their method on viewpoints chosen for the stakeholders, with perspectives such as security cutting across them (75, Rozanski & Woods, 2011). The C4 model gives the technique for the structural views, a hierarchy from context to container to component drawn from one underlying model (59, Brown, n.d.), and Structurizr expresses that model in a text language from which several views are defined and rendered (60, Structurizr, n.d.). Architecture as Code (Chapter 6) showed the Structurizr workspace as the architecture model of a large estate (167, Nordqvist, 2025), and FINOS CALM is an emerging alternative that adds machine-checkable controls to the same idea (61, FINOS, n.d.). What is new is the consequence of Shift 1: when the model, the control catalogue (Chapter 9) and the evidence manifest are all code, the consistency that the standard demands can be enforced by a pipeline instead of requested in a review.

The failure that generated views remove is familiar. A board paper written in March describes 160 controls, the audit file lists 172 and the supervisor pack, assembled in a hurry after a letter, says 158. Each document was true on the day it was written, by a different person, from a different copy, and the explanation of the differences costs more credibility than the differences deserve. A view generated from a commit of the model and a commit of the catalogue cannot disagree with another view generated from the same commits. If it differs from last quarter's, the difference is the diff between the two commits, which is something the architect can show.

Three rules follow, and the rest of the chapter applies them.

  1. One source, many projections. Every figure and every diagram in a view carries the commit of the model, the catalogue and the evidence manifest it came from. A view that cannot name its sources is a draft.
  2. Audiences differ in question and form, not in facts. The board wants a decision, the supervisor a demonstration, the auditor a sample, the engineer a verdict and the supplier a testable requirement. What changes is selection, aggregation and language.
  3. Findings travel back. Every question an audience asks that the views cannot answer is a finding against the architecture, and it returns to the model or the catalogue as a pull request, in the same loop that AI Red Team, Chapter 26, used for exercise findings (170, Nordqvist, 2026).

The table sets out the five audiences that this chapter treats.

Audience Question it asks Form Source of truth Cadence
Board or management body What must we decide, and what happens if we do not? One page, at most three decisions Catalogue status, indicators, risk and threat registers Quarterly, and on trigger
Supervisors Can the organisation show how it manages and tests this risk? CSF profile and evidence pack answered from the programme Catalogue, evidence manifest, test results, decision records On request, from a standing pack
Auditors Is the control operating, and can I check it myself? Read-only access to the evidence and a sampling interface Evidence manifest and raw evidence Continuous access
Engineers and product teams Is my change acceptable, and why? Verdict, rule and decision record in the pull request Policies, ADRs, AI Decision Records, model At every change
Suppliers What must we build, and what must we show? Testable requirement annex and evidence schedule Catalogue entries with tests At tender and at renewal

The configuration that drives the views is itself a small artefact. The following illustrative file, kept in the architecture repository, states for each audience which sources a view may read, which sections it contains and which checks must pass before publication, so that view definitions are reviewed like any other change.

# views/audiences.yaml (illustrative)
version: 3
sources:
  model: architecture/workspace.dsl
  catalogue: controls/catalogue.yaml
  evidence: evidence/manifest.json
  decisions: [decisions/adr, decisions/aidr]
publishChecks:
  - every-figure-has-source-commit
  - evidence-age-below-limit
  - ai-drafted-sections-have-verifier
audiences:
  board:
    sections: [decisions, indicators, control-status, changes-since-last]
    maxDecisions: 3
    maxPages: 1
  supervisor:
    sections: [csf-profile, control-evidence, test-results, decisions]
    redact: [credentials, internal-hostnames]
  auditor:
    access: read-only
    sampling: enabled
  engineer:
    delivery: pull-request-comment
    include: [rule-id, rationale, decision-record]
  supplier:
    sections: [requirements, tests, evidence-schedule]
    exclude: [internal-threat-detail]

Boards and management bodies

This section describes what a management body needs from the architect and why the form is a single page that asks for decisions.

The European instruments place the duty on the management body, not on the architect. NIS 2 Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures taken under Article 21 and to oversee their implementation, allows them to be held liable for infringements, and requires them to follow training so that they can assess risks and practices (6, European Union, 2022). DORA Article 5 makes the management body of a financial entity responsible for defining, approving, overseeing and answering for the ICT risk-management framework, and Article 5(4) adds a duty to keep up to date knowledge and skills sufficient to assess ICT risk (9, European Union, 2022). Chapter 18 treats these duties in full. The architectural implication here is narrow: a body that must approve and oversee needs material from which it can do so, and material it cannot read discharges the duty for nobody. The UK National Cyber Security Centre's board toolkit makes the same point from the practitioner's side, framing cyber security as a business risk that boards must be able to discuss in their own terms (211, NCSC, 2019). Hohpe's architect in the elevator has the matching skill: the same subject explained at the level of the penthouse and the engine room, without a different truth at each floor (74, Hohpe, 2020).

Three rules shape the board view.

Risk language, not control language. A board does not decide whether a policy decision point should sit in front of the claims-triage agent. It decides whether the group accepts that an agent with write access to the core claims system can be stopped within a stated time, or funds the work to make it so. The control appears only as the evidence behind the statement.

Decisions, not information. AI Threat, Chapter 32, concluded that a report that asks for no decision is a briefing, and that the board page should ask for at most three decisions, each with its cost, its reversibility and what it affects (171, Nordqvist, 2026). The architecture page adopts the rule. If the architect has more than three requests, the architect prioritises, because a board that receives seven decides none of them.

Movement, not state. A page that shows the same indicators in the same colours each quarter teaches the board to stop reading. The page shows which indicators crossed a threshold, which findings closed, which exceptions expire and which earlier decisions have taken effect. Because every figure comes from commits, the comparison with the previous page is a query.

Practical guide: Writing a one-page architecture report for a management body

Purpose. Produce, each quarter and on trigger, a single page that equips the management body to approve, oversee and decide, generated from the architecture's own sources. Roles. The security architect (author and verifier), the CISO (sponsor, who signs the page), the company secretary or equivalent (who schedules and records decisions) and, in a group, the chief risk officer's office.

  1. Fix the template once. Agree with the CISO and the company secretary the sections of the page: decisions asked for, five indicators with thresholds, control status in three counts, changes since the last page and the provenance block. Keep the template in views/, so that changing it is a pull request and the board sees a stable page.
  2. Set thresholds in advance. Choose the indicators defined under Metrics the architect reports, give each an owner and agree its threshold before the data arrives.
  3. Generate the page from commits. The pipeline blocks publication if a figure lacks a source commit or evidence is older than its limit.
  4. Select at most three decisions. For each, write the decision in one sentence, the consequence of not deciding, the cost, whether it can be reversed and what it affects. Where the decision is the expiry of an exception, say who accepted it and when it ends.
  5. Write the narrative last, in five sentences. Say what changed, what is within threshold, what is not and what the board is asked to do. Link the evidence; do not explain controls.
  6. State what the page does not know. Name each indicator whose evidence is declared and each area without measurement. A page that is green only because the red is unmeasured is the commonest cause of a bad surprise.
  7. Disclose AI's part with the provenance block described later in this chapter.
  8. Rehearse and record. Send the page to the CISO and one non-technical reader five working days ahead, and feed the reader's questions into the next template. Record each decision as an AI Decision Record or an ADR and link it from the next page.

Definition of done. The page is one page; every figure names its commit; at most three decisions are asked; every indicator has an owner and a threshold; AI-drafted sections are marked and verified; and last meeting's decisions appear with their status. A quarterly page is a default for a stable estate; an organisation whose agents act in production may add a monthly page for the machine-speed indicators.

Worked example: A generated board page for Hansa Mutual's executive board

The following page is illustrative. It is the machine-readable source of a one-page report that Hansa Mutual's pipeline renders for the executive board in Hamburg, the management body for DORA purposes, from the Structurizr workspace, the control catalogue of about 180 controls and the evidence manifest. The rendered page shows the same content as a single sheet.

# reports/board/2026-Q4.yaml (illustrative, generated)
kind: ManagementReport
id: MGT-HM-2026-Q4
audience: executive-board
period: 2026-Q4
generatedFrom:
  workspace: architecture/workspace.dsl@4f2c9a1
  catalogue: controls/catalogue.yaml@b81d07e
  evidence: evidence/manifest-2026-11-02.json
controlStatus: {verified: 121, declared: 52, failed: 7, total: 180}
indicators:
  - id: patch-velocity
    meaning: hours from listing as known exploited to fix or compensating control, internet-facing services
    policyClass: HM-PATCH-SLO-2027/exploited-exposed   # fix within 72 hours, Chapter 10
    median: 31
    p90: 118
    threshold: {p90: 72}
    status: above-threshold
  - id: containment-tests
    meaning: containment profiles that passed an independent test in the last 90 days
    value: "11 of 12"
    failing: [HM-SEC-001 egress allow-list too broad]
    status: retest-scheduled
  - id: recoverability
    meaning: critical services with a restore drill in the interval and a restore time within objective
    drillInInterval: "33 of 38"
    withinObjective: "29 of 38"
    status: below-threshold
  - id: review-quality
    meaning: team-level measures of review of agent proposals, not individuals
    tier2MedianMinutes: 22
    rejectionRate: 0.17
    seededErrorsCaught: 0.86
    status: within-threshold
decisionsAsked:
  - id: D1
    ask: Confirm delegated emergency patching for the two remaining platform segments
    cost: none
    reversible: true
    affects: [patch-velocity]
  - id: D2
    ask: Fund restore drills for the five services without a drill in the interval
    cost: two engineer-quarters
    reversible: true
    affects: [recoverability]
  - id: D3
    ask: Accept declared status for nine UK and Swiss mapping controls until 2027-03-31
    cost: residual risk, logged
    reversible: true
    affects: [control-status]
provenance:
  aiDrafted:
    - {section: narrative, agent: MND-HM-01/reviewer, verifiedBy: head-of-security-architecture}
  recordedAs: AIDR-0559

Three features matter more than the figures. The decisions are phrased as choices with a cost and a reversal, so the board can answer them in the meeting. The failing containment profile is named, because a board told that eleven of twelve pass will ask which one fails. And the page marks nine controls as declared by decision D3, not by omission, so the exception has an owner and an end date.

Worked example: Nordvik Region's one-page briefing to the regional executive committee

The following briefing is illustrative. It answers the regional director's commission, AIDR-0500, for a committee of elected members who will set the 2027 budget. It is written in plain language, avoids operational detail that public-access rules would expose, and asks for three decisions. By the time of the briefing the catalogue had grown from the first ten entries of Chapter 9 to 24. The same source renders the page and the generated views that the CISO and the audit committee receive.

# briefings/executive-committee-2026-11.yaml (illustrative)
kind: ManagementBriefing
audience: regional-executive-committee
answers: AIDR-0500
generatedFrom:
  catalogue: controls/catalogue.yaml@e07a512
  charter: roles/security-architect.yaml@c3d94b0
summary: >
  The Region now runs a high-risk benefits-triage system and AI assistants
  that its suppliers operate. One security architect holds the boundaries
  between them and the Region's data, mostly through contracts. The role has
  no written decision rights and no deputy.
position:
  controlsTracked: 24
  verified: 9
  declared: 13
  failed: 2
  declaredMeans: the supplier states it; the Region has not yet checked it
decisionsAsked:
  - id: D1
    ask: Adopt the role charter ROLE-NR-SA-01, giving the post written decision rights over stop-path and egress requirements in tenders
    cost: none
    reversible: true
  - id: D2
    ask: Fund one deputy post in the 2027 budget, so that the role is not a single point of failure
    cost: one post at the same grade
    reversible: true
  - id: D3
    ask: Require the evidence schedule of the security annex in the renewal of tender NR-2026-117
    cost: supplier price effect, to be assessed in the tender
    reversible: true
notKnown:
  - evidence for most supplier controls is declared, not verified
  - out-of-hours detection rules are supplier defaults
disclosure:
  aiDrafted: summary
  tool: Mode 3 agentic work tool, open-weight model on the Region's reserved capacity
  mandate: MND-NR-01
  verifiedBy: security-architect
classifiedAnnex: operational-detail withheld under public-access rules

It reports fewer controls than Hansa's catalogue because the Region has migrated only the controls it must verify in suppliers' systems, and it says plainly that most evidence is declared, because members who are told that everything is green and later learn otherwise will not trust the next page.

Supervisors

This section shows how the architect answers a supervisor from the programme's own evidence, so that no narrative has to be prepared for the occasion.

A supervisor does not decide for the organisation. It forms a view of whether the organisation manages a risk, by asking for documents, data and demonstrations. DORA Article 6(5) requires the ICT risk-management framework to be documented and reviewed at least once a year and after major incidents, with a report on the review available to the competent authority on request (9, European Union, 2022). NIS 2 Articles 32 and 33 give competent authorities supervisory powers over essential and important entities, including requests for information, and Article 21(2)(f) lists policies and procedures to assess the effectiveness of risk-management measures among the measures an entity must take, which is the legal root of testing evidence (6, European Union, 2022). In insurance, EIOPA's opinion on AI governance and risk management sets supervisory expectations on top of the sectoral framework (20, EIOPA, 2025). These are architectural implications: they say what must be demonstrable, not how.

It is observable that supervisors now ask about AI-enabled threats directly. The European Central Bank wrote in July 2026 to the chief executives of the significant institutions it supervises about AI-enabled cybersecurity threats (21, ECB, 2026). The letter is addressed to banks, not insurers, but it shows the direction. That other supervisors will adopt machine-speed measures such as patch velocity is expected, signalled and not yet uniform; the UK NCSC's warning of a coming wave of vulnerability patches is the kind of signal that precedes such expectations (140, NCSC, 2026).

Three practices let the architect answer from evidence.

A standing pack, not a prepared narrative. The supervisor view is a set of queries over the catalogue and the evidence manifest that exists before anyone asks. AI Red Team, Chapter 3, described a CSF profile kept as code that maps each Category to the obligations it helps meet (170, Nordqvist, 2026) (29, NIST, 2024). A question about, for example, third-party risk is answered by following the mapping to controls, tests and evidence. The architect keeps the mapping honest: each control states the obligations it serves, and each obligation resolves to at least one control with evidence of known age.

Show failures first. A supervisor's trust rests less on what passes than on how the organisation treats what fails. The pack opens with failed and declared controls, their owners and expected closure dates, followed by findings closed in the period and the re-tests that verified them, which is the purple loop of AI Red Team seen from outside.

One answer for all supervisors. Hansa's baseline controls are the same in every entity and the market overlays add national requirements, so the pack for the Dutch entity differs from the German one by the overlay it includes, not by the facts it states. Where the UK and Swiss mappings still sit outside the catalogue, the pack says so and gives the date they enter it.

The supervisor view is also a controlled output. A pack that describes the weaknesses of an estate in detail is sensitive, so it is redacted for credentials and internal names, shared through the supervisor's secure channel and logged.

Auditors

This section describes what changes when evidence is code: the auditor becomes a sampler of the programme's own records, not a recipient of a file assembled for the occasion.

Architecture as Code (Chapter 15A) defined evidence as machine-collected, signed and versioned, and AI Governance, Chapter 11, defined the evidence manifest and the distinction between attestation, in which a person asserts, and evidence, which a system produces (168, Nordqvist, 2026). Chapter 9 made the catalogue the architect's artefact and classified every control as verified, declared or failed. The auditor's view follows: read-only access to the manifest and the underlying records, a sampling interface that returns a random or risk-weighted selection of control instances with their raw evidence, and the test definitions that produced the results, so that the auditor can re-perform a sample independently of the architect.

Independence is preserved by access, not by distance. An auditor who can query the evidence store does not rely on the architect's summary. The auditor draws the sample, and the architect answers questions about meaning, not about which records to show.

Internal audit has a regulatory place. DORA Article 6(6) requires the ICT risk-management framework of a financial entity, other than a microenterprise, to be subject to internal audit in line with the audit plan (9, European Union, 2022), and the management review of ISO/IEC 27001 is a required periodic input to the management system (23, ISO/IEC, 2022). Both receive the same evidence manifest; neither receives a special version.

Auditors sample the agent's work. Where an AI agent collects or refreshes evidence, the auditor tests it instead of repeating it: the agent's evidence links are checked against the source system, and its mandate manifest against what it did. Machine-collected evidence is more consistent than evidence assembled by hand, and its failure modes differ: stale links, a source system that changed shape, a collector whose permissions drifted. The test of the collector is therefore a control in the catalogue with evidence of its own. Evidence from suppliers' systems is often declared, not verified, and the honest view says so, with the contract clause that obliges the supplier to provide evidence and the date of its last review.

Engineers and product teams

This section covers the audience the architect reaches most often and informs worst: the people who build, and who meet the architecture as a refusal or a ticket.

Engineers need a verdict on a change, the rule behind it and the reason, at the moment of the change. The pull request is where they work, so it is where the architecture speaks. Architecture as Code (Chapter 4) set out the Architecture Decision Record as a short, numbered, immutable note beside the code, with context, options and consequences (167, Nordqvist, 2025), following Nygard's original form (63, Nygard, 2011). Chapter 5 made the pull request the unit of architectural change and Chapter 17 moved routine decisions to gates. What remains to communicate is the content of the gate's message and the discoverability of the decisions behind it.

A good message from a gate has four parts: the rule identifier, which links to the catalogue entry; the observed fact, such as the egress destination the change adds; the reason in one sentence, usually a link to the decision record that created the rule; and the way forward, which is a change that passes or the route to an exception. A message that says only that a policy check failed teaches engineers to ask the architect, who remains the gatekeeper; Shift 2, from gatekeeper to boundary designer, needs the gate to explain itself. A message that names the rule and the way forward lets the engineer resolve the failure alone, and shows over time which rules are unclear: the rules that draw the most repeat questions are the rules to rewrite.

The paved road is the second channel. The platform provides reference modules whose defaults already satisfy the rules, so that the secure way is the easy way and the architecture is communicated by what the engineer does not have to decide. The third is a short, regular exchange, not a review: a fortnightly open session in which the architect shows the changes to the catalogue and the most common gate failures removes much of the argument that otherwise happens in tickets.

Engineers are also a source of evidence about the communication itself. Accelerate found that software delivery performance is measured by throughput and stability, in lead time, deployment frequency, time to restore and change failure rate, which are outcomes and not activity counts (81, Forsgren et al., 2018). The architect borrows the principle and asks how long a compliant change takes from commit to merge, and how often the gate stops a change that was in fact acceptable. A security architecture that raises lead time without lowering failures is a cost the engineers will route around.

Suppliers

This section treats suppliers as an audience of the architecture, to whom the architect states what is required and from whom the architect expects evidence in return. Chapter 20 develops requirements as code and contracts as controls; here the concern is the communication.

A supplier cannot satisfy a requirement it cannot test. The architect therefore writes each requirement as a statement with a measurable acceptance condition and a named evidence artefact: not that the supplier will provide adequate logging, but that every administrative action on the service is logged with the actor, the time and the target, that logs are delivered to the customer's store within a stated time, and that the supplier supplies a sample on request. The requirement is taken from a catalogue entry, so the supplier's annex is a projection of the same controls the organisation applies to itself.

Procurement law shapes the form. Directive 2014/24/EU requires contracting authorities to treat economic operators equally and without discrimination and to act transparently and proportionately (Article 18(1)) (18, European Union, 2014). Requirements that every tenderer can read, test and price satisfy that duty better than requirements that depend on a conversation with the architect. In a financial entity, DORA Article 28 requires a register of information on ICT third-party arrangements and a risk-based approach to them, and Article 30 lists the contractual provisions that arrangements supporting critical or important functions must include (9, European Union, 2022), so the same annex must serve the contract and the register.

The evidence returned by the supplier is the other half of the communication. The annex states the schedule on which evidence arrives, in what format, and what the customer does with it. A supplier attestation is recorded as declared until the customer has verified it by a test, an exercised audit right or a sample. The supplier view leaves out internal threat detail, which a supplier does not need.

Metrics the architect reports

This section defines the management reporting that the architect owns, and says which measures to leave out.

A metric earns its place in management reporting when it describes a property of the architecture that someone can change, when it has an owner and a threshold, and when it can be computed from evidence without opinion. Site reliability practice uses the same logic for service levels: choose a few indicators that reflect what users experience, set objectives for them, and report against the objectives (212, Beyer et al., 2016). Five indicators meet the test and recur through this book's chapters.

Indicator Definition Evidence source Reader's decision
Patch velocity Time from listing of a vulnerability as known exploited, or from a defined exploitation signal, to remediation or a compensating control, for internet-facing and critical services; reported as median and 90th percentile Vulnerability scanner, CISA KEV, EPSS, ticket and pipeline timestamps Fund or delegate faster patching
Containment test results Share of containment profiles and stop paths that passed an independent test in the last interval, with the time the stop path took Containment test runs and their logs Accept or fund work on a failing boundary
Recoverability Share of critical services with a successful restore drill in the interval and a measured restore time within objective Drill records and recovery test definitions Fund drills or accept the objective gap
Control status Counts of controls verified, declared and failed, with the age of the oldest evidence Catalogue and evidence manifest Accept declared status, with an end date, or fund evidence
Review quality Team-level measures of review of AI and human proposals: approval time, rejection rate, reversals, seeded errors caught Pull request metadata and drill results Adjust review tiers or staffing

Patch velocity uses public prioritisation sources that the architect does not own: the Known Exploited Vulnerabilities catalogue (152, CISA, n.d.), the Exploit Prediction Scoring System (151, FIRST, n.d.) and the European Vulnerability Database (153, ENISA, 2025). AI Governance, Chapter 24, concluded that patch velocity belongs in management reporting as a risk indicator and that patch decisions must be delegated in advance (168, Nordqvist, 2026). NIST's guidance on enterprise patch management describes the maintenance plan that the indicator measures (35, Souppaya & Scarfone, 2022). Chapter 10 sets the service level it reports against, and AI Red Team, Chapters 24 and 28, added recoverability beside it (170, Nordqvist, 2026).

Review quality is the newest of the five and needs most care. It addresses the risk, recorded in the research on automation, that people who supervise a reliable automated system become complacent (107, Parasuraman & Manzey, 2010). Chapter 14 defined the measures. In reporting, the measures are always aggregate, at the level of a team and never of a named person, and where employee representatives have rights over measures that could monitor individuals, the aggregation and the use are agreed with them before the first report. Hansa's works councils in Germany and the Netherlands and the unions in Sweden are the examples in this book.

The architect also leaves things out. The architect does not report counts of activity, such as reviews held, documents produced or vulnerabilities found without exposure, because an activity count rewards the activity. The architect does not sum the five indicators into a score or draw a heat map, for the reasons given in AI Threat, Chapter 32: a single score hides which property is failing, and a heat map hides the difference between a measured rate and a guess (171, Nordqvist, 2026). And the architect watches for the effect described by Strathern's formulation of a rule often attributed to Goodhart: when a measure becomes a target, it ceases to be a good measure (213, Strathern, 1997). A patch-velocity target met by reclassifying services as not internet-facing has improved the report and nothing else. The defence is to compute the indicator from the model, in which internet-facing changes only by a reviewed pull request, and to sample the underlying cases.

Disclosing AI's part in the work

This section states how the architect says honestly which parts of a communication AI drafted, and how they were verified. It follows from the rule that accountability for an artefact stays with a named person, whatever drafted it (Architecture as Code (Chapter 20) and AI Red Team, Chapter 6) (167, Nordqvist, 2025) (170, Nordqvist, 2026).

AI is useful in this work in specific ways, set out by mode in the table below; Chapter 12 and Chapter 13 describe how each is governed. For this chapter the issue is only what the reader is told. The disclosure is a provenance block, produced by the generator and not typed by the architect, with five elements: which sections or figures an AI drafted; which agent or tool, in which usage mode, under which mandate manifest; what it was given as input; what the verifier did; and who verified. On a board page the block is one line naming the drafted section and the verifier. The supervisor and the auditor receive the mandate and the verification record. The engineer sees it in the pull request comment when an agent drafted the rule explanation. The supplier annex needs no block unless the supplier asks, but nothing in it may rest on an unverified AI statement.

Verification has a precise meaning here. Every figure in an AI-drafted view is recomputed from the sources by the pipeline, so that a number cannot be wrong because a model summarised it. Every claim in AI-drafted narrative is checked against the figure or record it describes, by a reviewer who reads the draft against the sources and not against the AI's own account of them, as Chapter 14 describes. Because people over-rely on automation that is usually right (107, Parasuraman & Manzey, 2010), the architect samples drafts against sources each quarter and records the corrections; a drafting process that never produces a correction has probably stopped being checked.

Disclosure has limits. The architect does not disclose in order to share blame: under the instruments that put the duty on the management body, and under the professional responsibility Chapter 4 assigns to the role, the architect who signs a page owns it. Architecture information also describes an organisation's defences, so a view that contains it is not drafted in a tool that sends it outside the organisation's chosen boundary. Nordvik Region's architect therefore runs the drafting tool only on open-weight models on the Region's reserved capacity, and Hansa's team routes by classification to self-hosted models (AI Platform and Security, Chapter 15) (169, Nordqvist, 2026).

Across the usage modes

The communication task changes with the mode of the AI involved. The table gives the typical use in this chapter's work, what the reader must be told and the check that applies. Level 4 Autonomous is not used for any of these tasks, and no AI publishes a view to a board, a supervisor or an auditor on its own authority; the highest level used is Level 3 Bounded, for refreshing evidence links.

Mode Typical use in communicating architecture What the reader is told Check
Mode 0 Ambient AI Summaries and suggestions inside the reporting, ticketing or diagramming tools the organisation licenses That the tool may apply AI features, recorded in the inventory Feature settings reviewed; output never relied on without the check below
Mode 1 Conversational assistants Drafting narrative, rewording findings for a non-technical reader Which sections were drafted Architect rewrites or verifies each sentence against the figures
Mode 2 Embedded workplace assistants Summarising review threads and meeting notes That a summary was machine-made Summary checked against the thread before it is used
Mode 3 Agentic work tools Querying the model and catalogue, computing indicators, assembling a first draft The mandate manifest and the verifier Figures recomputed by the pipeline; narrative checked by the architect
Mode 4 Built AI applications A view generator with an AI-written summary component The component, its evaluation and its owner Evaluation results and sampling in the catalogue
Mode 5 Autonomous production agents Refreshing evidence links for catalogue controls The agent's mandate, its Level 3 Bounded scope and its logs Auditors sample the agent's links against source systems

What is observable, expected and speculative

Using the labels of AI Governance, Chapter 22, it is observable that views are generated from a model by the Structurizr and C4 tooling (60, Structurizr, n.d.), that supervisors ask about AI-enabled threats (21, ECB, 2026) and that the European instruments place approval and oversight duties on management bodies (6, European Union, 2022). It is expected that supervisors will ask for machine-speed measures such as patch velocity in their reviews of ICT risk, because the exploitation window has shortened and supervisory letters and national agencies now say so (21, ECB, 2026) (140, NCSC, 2026); the expectation is signalled and not yet uniform across sectors or member states. It is speculation that supervisors will one day read machine-readable evidence directly from the organisation's pipeline instead of receiving a pack; no instrument decided in 2026 requires it, and the design of this chapter makes it possible, not necessary.

Nordvik Region and Hansa Mutual

Nordvik's architect communicates to audiences that differ in kind: a regional executive committee of elected members who are not technical and must answer to the public, suppliers reached through tender annexes, and the public itself through access requests, so that anything written may be read by a journalist. The architect therefore writes for the committee in plain language, keeps operational detail in a classified annex that the public-access rules allow to be withheld, and treats every document as one that may be requested. With no audit team of its own, the Region relies on the national audit body and the audit committee, who receive the same evidence manifest. The one-page briefing answers the regional director's commission, AIDR-0500, and the single architect verifies every figure.

Hansa's team of six generates views for the executive board, the group AI governance board chaired by the chief risk officer, BaFin and the other supervisors, internal audit and the national entities, all from one model and one catalogue. The team adds patch velocity, containment test results and review quality to the management reporting that already carries recoverability and control status, and records the decision as AIDR-0559. The evidence-collection agent supplies much of the evidence, so internal audit samples its work. Agreement with the works councils in Germany and the Netherlands and consultation of the unions in Sweden precede the first review-quality report.

The two differ in the scarce resource. At Nordvik it is the reader's attention and the architect's time, so every view is short and every supplier requirement does the work of a conversation. At Hansa it is consistency across seven regimes and many audiences, so the generator and its checks carry the load.

Summary

This chapter showed how one security architecture is communicated to five audiences without keeping five versions of it. The model, the control catalogue and the evidence manifest are the single source, and every view for the board, the supervisor, the auditor, the engineer and the supplier is generated from specific commits of them. This is Shift 1, from documents to code, applied to communication: the architect stops maintaining documents and maintains the sources and the generators of the views.

Each audience has its own form. The board receives one page with at most three decisions, phrased in risk language, showing movement and naming what is not measured. The supervisor receives a standing pack that opens with failures. The auditor receives read-only access and a sampling interface, and samples the work of any agent that collects evidence. The engineer receives a verdict, a rule and a reason in the pull request, and the supplier a requirement it can test and a schedule for the evidence that comes back. Five indicators run through all the views: patch velocity, containment test results, recoverability, control status and review quality, each computed from evidence and not from opinion. This is Shift 3, from periodic to continuous, at machine speed, applied to reporting: properties that decide an outcome in minutes are measured continuously.

AI drafts parts of this work in Modes 1 to 4, and a Mode 5 agent refreshes evidence links at Level 3 Bounded. This is Shift 4, from sole author to conductor of an AI team, applied to communication: the architect conducts the drafting and answers for the result. The architect discloses which parts, under which mandate and with what verification, and recomputes every figure from its source; accountability for what is signed does not move. Generated views are observable today, and the supervisory expectation of machine-speed metrics is expected and not yet uniform.

Chapter 20 turns to the two settings that change the role most, the public authority that procures what it cannot build and the multinational that holds one architecture across many legal regimes, and develops the supplier requirements, sovereignty properties and market overlays that this chapter only touched.

Sources

  1. Brown, S. The C4 model for visualising software architecture. (59, Brown, n.d.)
  2. Structurizr. Structurizr DSL language reference. (60, Structurizr, n.d.)
  3. FINOS. Architecture as Code: What is CALM? (61, FINOS, n.d.)
  4. International Organization for Standardization, International Electrotechnical Commission and Institute of Electrical and Electronics Engineers (2022). ISO/IEC/IEEE 42010:2022 Software, systems and enterprise: Architecture description. (28, ISO/IEC, 2022)
  5. Rozanski, N. & Woods, E. (2011). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. (75, Rozanski & Woods, 2011)
  6. Hohpe, G. (2020). The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise. (74, Hohpe, 2020)
  7. Nygard, M. Documenting Architecture Decisions. (63, Nygard, 2011)
  8. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (29, NIST, 2024)
  9. European Central Bank (2026). Addressing AI-enabled cybersecurity threats. (21, ECB, 2026)
  10. 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)
  11. 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)
  12. European Parliament and Council of the European Union. Directive 2014/24/EU on public procurement. (18, European Union, 2014)
  13. European Insurance and Occupational Pensions Authority (2025). Opinion on Artificial Intelligence governance and risk management. (20, EIOPA, 2025)
  14. 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)
  15. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. (81, Forsgren et al., 2018)
  16. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (107, Parasuraman & Manzey, 2010)
  17. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. (140, NCSC, 2026)
  18. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. (152, CISA, n.d.)
  19. Forum of Incident Response and Security Teams. Exploit Prediction Scoring System (EPSS). (151, FIRST, n.d.)
  20. European Union Agency for Cybersecurity (2025). European Vulnerability Database (EUVD). (153, ENISA, 2025)
  21. Souppaya, M. & Scarfone, K. (2022). Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. (35, Souppaya & Scarfone, 2022)
  22. National Cyber Security Centre (2019). Cyber Security Toolkit for Boards. (211, NCSC, 2019)
  23. Beyer, B., Jones, C., Petoff, J. & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. (212, Beyer et al., 2016)
  24. Strathern, M. (1997). 'Improving ratings': audit in the British University system. (213, Strathern, 1997)
  25. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  26. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  27. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  28. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
  29. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)