The Transformed Security Architect: workbook

All courses / The Transformed Security Architect / Workbook

How to use this workbook

The workbook follows the course on The Transformed Security Architect lesson by lesson. Read the chapter (or its whitepaper) before each lesson, bring the workbook to the session and keep what you produce in the exercises: they add up to the final assignment.

After the course you can

Explain the four shifts in the security architect's work, their evidence, their dependencies and the failure mode of each
Draft a role charter with a mandate, accountabilities, decision rights with time limits, and exclusions, and test it against past decisions
Design a boundary as a containment profile and identity record that hold whatever the contained party attempts, with tests run from outside
Classify controls as verified, declared or failed from a catalogue entry with a falsifiable objective, a test and evidence with a fail condition
Specify time as a design property through patch-velocity classes, delegated decisions and a timed stop drill
Write a mandate manifest for AI tools or agents and review AI-proposed changes by tier with techniques that do not trust the proposer
Translate articles of the AI Act, NIS 2, DORA and the Cyber Resilience Act into controls, tender requirements and a one-page report for a management body
Plan how competence is evidenced with and without AI, how the craft is kept, and how the practice develops over 24 months

Module 1 · Part I · The Role in Question

Part I asks what has happened to the security architect now that architecture is code and agents act in the estate. It frames the thesis that the role is transformed, not abolished, describes the inherited practice fairly, defines the four shifts with their evidence and failure modes, and ends with the role charter kept as code. Participants leave with a framed commission, an audit of their inherited practice, a shift assessment and a first set of written decision rights.

Chapter 1 · 60 minutes

Introduction: The Security Architect Transformed

The lesson frames the book's question and thesis: the security architect is being transformed, not abolished. Participants meet the three prompts of autumn 2026, the three rival positions of abolition, absorption and continuity, the four shifts in brief, the three parts of accountable human judgement that remain scarce, and the European instruments that place duties someone must turn into architecture. They practise turning the question into a commission recorded as a decision record.

Learning objectives

Explain the thesis that the role is transformed, not abolished, and state what evidence would refute it under abolition, absorption and continuity.
Name the four shifts exactly and say which parts of the book carry each of them out.
Describe the three parts of accountable human judgement that the book says remain scarce.
Draft a commission for the security architect role as a decision record with a question, deliverables, a due date and constraints.

Key concepts

Transformed, not abolished: The thesis that the role moves from author of documents and reviewer at gates to designer of executable boundaries and decision rights, from periodic review to continuous verification at machine speed, and from sole expert to accountable conductor of an AI team.
Abolition, absorption and continuity: The three rival positions. Abolition lets machines generate and enforce boundaries and gives residual judgement to the CISO; absorption moves the content to platform engineering, governance and agent operators; continuity holds that the shifts are fashions. Each names evidence that would refute the thesis.
Accountable human judgement: What remains scarce, in three parts: accountability for a boundary, the ability to verify what code and AI propose, and the craft that makes verification possible, which the role must keep deliberately.
Architectural implication: The way the book reads law: each article of NIS 2, DORA, the AI Act or the Cyber Resilience Act becomes a boundary, a control, a test and a record only if someone designs them. Naming an accountable architect per boundary is expected practice, not a legal duty.
User and boundary designer: The architect's two relations to AI across the usage modes: using AI in Modes 1 to 3 under the architect's own identity differs in kind from designing identity, containment and stop paths for Mode 5 Autonomous production agents.

Interactive exercises

Match: Three rival positions and three scarce things
Put in order: Framing the question as a commission

Done on the lesson page, with feedback at once.

Discussion

Which of the three rival positions, abolition, absorption or continuity, is argued most often in your organisation, and what observation would settle the matter there?
Nordvik's commission concerns one post's authority and budget, while Hansa's concerns throughput when actors are faster than the forum. Which of the two is closer to your situation, and why?
The chapter says a boundary that looks right and is wrong is worse than none, because it is trusted. Where in your estate could that already be the case?

Exercise · 20 minutes

Frame the commission as a decision record

Using the six steps of the chapter's practical guide, frame the question for your own organisation. Write down who is asking and why now. List the boundaries your AI and security decisions depend on and their owners, marking any that are unowned. List last year's decisions about those boundaries and how long each took. State the question in one sentence a board can answer, name the deliverables and a due date before a budget or board meeting, and record the constraints, such as pay scales, consultation duties and public-access rules.

Deliverable: A one-page decision record in the style of AIDR-0500 naming the question, the accountable person, the deliverables, the due date and the constraints, with the first two findings noted.

Self-test

According to the chapter, what did the failures in the July 2026 incident between OpenAI and Hugging Face concern?
1. A general-purpose AI model that behaved differently from its evaluation results
2. Where a boundary was drawn and who could act on it, not a failure of a model
3. A supplier that changed an ambient AI feature without notice to the deployer
4. A management body that had not approved its risk-management measures
Which three parts make up the accountable human judgement that the book says remains scarce?
1. Budget authority, supplier management and regulatory reporting
2. Document authorship, approval at the gate and the annual procured penetration test, as in the inherited role
3. Model evaluation, guardrail policy and agent permissions
4. Accountability, the ability to verify, and the craft that makes verification possible
How does the chapter treat the idea of naming an accountable architect for each boundary?
1. As an expected practice, not a legal duty, kept apart from observable law
2. As a duty that NIS 2 Article 20 places directly on security architects
3. As speculation that the book confines to its final two chapters
4. As a requirement of the ENISA Cybersecurity Architect profile

Chapter 2 · 60 minutes

What the Security Architect Did: The Role Before the Transformation

The lesson gives a fair account of the role before the transformation: risk-based management under ISO/IEC 27001, layered design with SABSA and TOGAF, review boards, reference architectures as documents and the reputation as the department of no. Participants learn the conditions those methods assumed, the five developments that strained them, and the four things the transformed role inherits. They audit an inherited practice and decide whether to keep, codify, delegate or retire each part.

Learning objectives

Describe the five inherited methods of the security architect and the conditions each assumed.
Explain the three legitimate purposes of the review board and why each survives the transformation.
Identify the five developments that strained the inherited practice, separating what is observable from what is expected.
Classify the practices of a security architecture function as keep, codify, delegate or retire, naming what covers each retired purpose.

Key concepts

Attested evidence: Evidence in which someone states in a spreadsheet that a control operated. The chapter calls attestation cheap to collect and expensive to trust, and notes that it ages from the day it is signed.
Three purposes of the review board: Scarce expertise concentrated and spread, a gate proportionate to the cost of reversing a design mistake, and an accountable record of who reviewed and who accepted the residual risk. Each survives at a different scale.
Function and implementation of the gate: The function is independent challenge before an irreversible commitment; the implementation was a meeting that a project must pass. The transformed role keeps the function and changes the implementation.
Keep, codify, delegate, retire: The four dispositions of the practice audit: keep when purpose and conditions hold, codify when a check could carry the form, delegate routine decisions to a named forum, pipeline or supplier with written decision rights, retire when the purpose is covered elsewhere or absent.
What the transformed role inherits: Four parts of the inherited content: traceability to business risk, the principles of secure design, independent challenge built into pipeline and record, and accountable sign-off by a named person with a decision right.

Interactive exercises

Sort: Nordvik's 2024 reference architecture, section by section
Scenario: The board that everyone wants to abolish

Done on the lesson page, with feedback at once.

Discussion

Which of the three mechanisms behind the department of no, timing, asymmetry or culture, weighs most in your organisation, and what would change the incentive?
The chapter says a stale layer is worse than an absent one, because readers trust it. Which document in your practice still carries authority that the estate no longer matches?
Nordvik has to build what Hansa already has, and Hansa has to remove what Nordvik never built. What does that contrast suggest about where your own transformation should begin?

Exercise · 20 minutes

Audit an inherited security architecture practice

Choose five recurring activities of your security architecture function, for example a review meeting, a reference architecture document, a supplier questionnaire, a hardening appendix and an exception letter. For each, state its purpose in one sentence using the gate's purposes (expertise, irreversibility, accountability) or the risk frame's (traceability, ownership, evidence). State the conditions it assumed, namely release frequency, number of systems, acting identity and adversary speed, and mark each as holding, partly holding or no longer holding. Classify each practice as keep, codify, delegate or retire. For every retirement, name the control, record or forum that now covers its purpose.

Deliverable: A practice audit table of five rows in the form of the chapter's practice-audit example, with purpose, conditions, disposition, what covers the purpose and a review date.

Self-test

What did Forsgren, Humble and Kim find about approval of changes by an external body, as the chapter reports it?
1. It was associated with slower delivery and no better stability than peer review and automated checks
2. It was associated with slower delivery but clearly fewer failed changes in production
3. It made no measurable difference to either delivery speed or stability
4. It improved stability, but only in organisations that deployed between once a month and once every six months
In Nordvik's assessment of its 2024 security reference architecture, what happened to section 6, logging and monitoring?
1. It was kept unchanged because it was technology-neutral
2. It was retired in favour of supplier baselines referenced by version
3. It was delegated to the managed security service provider under NR-2025-044
4. It was codified as a containment profile for the AI gateway
Which assumption of the inherited methods does a Mode 5 Autonomous production agent break?
1. That suppliers deliver products and not services
2. That every action traces to a person or a person-owned service account
3. That the management body reviews the system at planned intervals
4. That each control traces to a business attribute

Chapter 3 · 75 minutes

Four Shifts: Code, Boundaries, Machine Speed and the AI Team

The lesson defines the four shifts precisely: what each is, the evidence for it, what it changes and leaves unchanged, and how it fails when taken too far. Participants learn why there are four and not fewer or more, how the shifts depend on one another, and which artefact makes each concrete. They rate a practice on a four-stage scale using evidence only and apply the dependency checks that flag an AI team running ahead of its containment.

Learning objectives

Define each of the four shifts by what it changes: the medium, authority, tempo and authorship of the architect's work.
Distinguish which claims about each shift the chapter labels observable, expected or speculation.
Explain how the shifts depend on one another and name the failure mode of each.
Assess a security architecture practice on the four-stage scale with evidence links and dependency flags.

Key concepts

Boundary: A place where a rule is enforced by something other than the party it governs, with a named owner and a test. It is the central product of Shift 2, from gatekeeper to boundary designer.
Dependencies between the shifts: Code enables boundaries, boundaries enable speed, speed requires the AI team, and the AI team requires verification, which requires code. The natural order is Shift 1, then 2, then 3, with Shift 4 never ahead of its containment.
Four failure modes: Code without judgement, boundaries without owners, speed without reversibility and an AI team that approves itself. Each looks like success from inside and removes the human judgement the shift was meant to concentrate.
Four-stage scale: Stage 0 inherited, stage 1 starting with at least one artefact or decision in the new form, stage 2 established as the default in scope, and stage 3 verified, meaning tested, measured and reported.
Dependency check: A flag raised when Shift 4 is rated above Shift 2, because the AI team's autonomy then outruns its containment, or Shift 3 above Shift 1, because continuous measurement of what is not code usually rests on attestation.

Interactive exercises

Sort: Artefacts and failure modes by shift
Scenario: Rating a shift without fresh evidence

Done on the lesson page, with feedback at once.

Discussion

Hansa Mutual is far along Shift 4 while still blocked on Shift 2. What risks follow from that order, and how would you explain the urgency to an executive board?
The chapter says Shift 3 has no artefact of its own because it is a property of the others. What does that mean for how you would report progress on it?
Which of the four failure modes would be hardest to notice from inside your organisation, and what measurement would reveal it?

Exercise · 30 minutes

Locate a practice on the four shifts

Follow the chapter's practical guide for your own security architecture practice. Sample the last 20 security architecture decisions, or all from the last quarter if fewer. For each shift, answer the indicator questions and assign a stage from 0 to 3. Rate on evidence only: a rating needs a link to an artefact, measurement or record no older than 90 days, and without one you take the lower stage. Apply the two dependency checks and state any flag. List the gaps and name the artefacts that would close each. If you have no practice to assess, reconstruct Hansa Mutual's assessment from the chapter and justify its single flag.

Deliverable: A shift assessment in the form of the chapter's example: a stage, evidence and gaps for each of the four shifts, the dependency flags and a list of next steps.

Self-test

Why does the chapter hold that 'from perimeter to zero trust' is not a fifth shift?
1. Because zero trust is not yet observable in European organisations and so cannot count as evidence for a shift
2. Because it applies only to Mode 5 Autonomous production agents
3. Because it describes content, one answer to Shift 2, and not a change in the role
4. Because it is already contained in Shift 3 as a measured property
How does the chapter label the effect of Shift 4 on the quality of architecture decisions?
1. Observable, on the adoption figures of the 2025 DORA research
2. Expected to be positive, because developers were faster in a controlled experiment
3. Expected to be negative, on the research on automation bias
4. Not established by any study found, so claims in either direction are speculation
In the shift assessment, what does it mean when Shift 4 is rated above Shift 2?
1. The AI team's autonomy outruns its containment, which raises a dependency flag
2. Continuous measurement of what is not code rests on attestation, which lowers the Shift 3 rating
3. The organisation may move its agents to Level 4 Autonomous
4. The peer reviewer must lower the Shift 4 rating to stage 0

Chapter 4 · 90 minutes

The Transformed Role Defined: Mandate, Accountabilities and Decision Rights

The lesson defines the transformed role as a role charter kept as code in roles/security-architect.yaml. Participants learn why a charter differs from a job description, what the mandate lists, how accountability attaches to the boundary holding and not to authorship, how the four decision rights sit on four tiers with time limits, what the role does not do, and who answers for what agents propose. They draft charter entries and test them against real decisions.

Learning objectives

Explain why the role is defined by a charter kept as code and what three properties that adds.
Distinguish accountability for a boundary from authorship of its artefacts, and name the three parts of that accountability.
Assign decide, recommend, veto or escalate to a decision class with a tier and a time limit.
Test a draft charter against past decisions and classify each result as resolved, ambiguous or too slow.

Key concepts

Role charter: A machine-readable statement of the mandate, accountabilities, decision rights with time limits, escalation paths, owned artefacts and exclusions of the role, precise enough to settle a contested decision. A job description describes a person; a charter describes what the role may decide and stop.
Accountability for the property: The charter attaches accountability to the boundary holding, in three parts: the design is adequate for the accepted risk, verification shows it holding, and risk owners have been advised in time and in plain language when a boundary cannot be held within appetite.
Decide, recommend, veto, escalate: The four verbs of decision rights. They sit on tier 1 pipeline gates, tier 2 design authority, tier 3 AI governance board and tier 4 management body, each with a time limit; a veto not exercised in time lapses to the escalation path.
Narrow veto: A veto limited to properties that are expensive to restore once a contract is signed or a system is live, such as a missing stop path or egress limit, judged against a short, testable criterion and subject to recorded override by a named higher authority.
The approval rule: The person who approved is accountable for the approval, and the person who designed the gate is accountable for what the gate lets through. An agent that drafted a change proposed it and is accountable for nothing.

Interactive exercises

Sort: Which right for which decision class
Scenario: The stop that waited for the architect

Done on the lesson page, with feedback at once.

Discussion

The chapter says a right to review without a limit is a right to delay. Which of your current review rights would lapse if a time limit were attached, and what would be lost or gained?
Why does the charter deny the architect the right to accept residual risk, and what happens in a small organisation where one person both designs and operates?
Nordvik turns every right that would let one person approve their own work into a recommendation to the CISO. How would you handle the same problem in a function with a single post?

Exercise · 35 minutes

Draft and test charter decision rights

Collect ten decisions that your security architecture role took, influenced or was blamed for over the last year, including at least one contested decision, one slow decision and one supplier decision. Group them into decision classes. For each class assign a verb, defaulting to recommend, granting decide where the catalogue already sets the standard and veto only for properties expensive to restore, together with a tier and a time limit: working days for design decisions and minutes for anything touching a running agent. Write three exclusions under a heading of what the role does not do. Then resolve five of the past decisions against your draft and classify each as resolved, ambiguous or too slow, changing the draft for every case that fails.

Deliverable: A draft charter section listing decision classes with verb, tier, time limit and override holder, three exclusions, and a five-row test table showing resolved, ambiguous or too slow.

Self-test

Under the chapter's default decision rights, what is the architect's right when an agent or system in production must be stopped?
1. Decide, within two working days of the request being made
2. Veto, subject to a recorded override by the CISO
3. Recommend to the stop holder, never as a precondition
4. Escalate to the management body at tier 4 within minutes
Where a gate merged a delegated change class without human approval, who answers under the charter's rule?
1. The agent that drafted the change, because it proposed it
2. The pipeline's platform team, because it operates the gate
3. The system owner alone, because the owner accepted the residual risk when the change class was delegated
4. The gate policy's author for its adequacy, and the delegating forum for the delegation
What ceiling does Nordvik's charter ROLE-NR-SA-01 place on the architect's own AI use?
1. Level 0 Advisory, in Mode 1 only
2. Level 1 Assisted, in Modes 1 and 3 under MND-NR-01
3. Level 2 Supervised, in Modes 1 to 3 under MND-NR-01
4. Level 3 Bounded, for reversible repository edits

Module 2 · Part II · The Craft

Part II is the craft of the transformed security architect. Seven lessons move the work from documents to executable design: the architecture model and policy as code, threat models generated on every change, boundaries and containment that hold whatever an actor intends, identity for workloads and agents, the control catalogue with its evidence, time as a design property, and recoverability. Participants leave with the artefacts themselves: a boundary rule, a threat model entry, a containment profile, an identity record, a control entry, a timed stop drill and a reversibility test.

Chapter 5 · 75 minutes

Security Architecture as Code: From Documents to Executable Design

The lesson shows how security architecture becomes executable design: an architecture model kept as code with security properties on its elements, policy as code that fails a pull request when a principle is broken, decision records beside the code, and drift comparison against the running estate. Participants learn the three kinds of rule, the three mechanisms that decide who reviews a change, and which four kinds of document remain. They specify properties and a boundary rule for a small model.

Learning objectives

Explain four ways a reference document fails the architect and what a model kept as code offers instead.
Assign the security properties trustZone, dataClass, identity, usageMode, policyPoint and owner to the elements and relationships of a small estate.
Distinguish completeness rules, boundary rules and content rules and state what each checks.
Design the review path for an architectural pull request using policy checks, review triggers and decision rights.

Key concepts

Security properties on model elements: Named properties such as trustZone, dataClass, identity, usageMode, policyPoint and owner that turn a diagram into a security model. Each must be testable by a rule, and a closed vocabulary matters more than a rich one.
Completeness, boundary and content rules: Completeness rules require every element to carry the properties other rules need; boundary rules require a relationship between two zones to name an existing policy point; content rules restrict what may sit where, for example that a Mode 5 agent has an identity of its own.
Pull request as unit of change: An architectural change arrives as a pull request carrying the model diff, policy-check results, the linked decision record and a named author. Policy checks decide routine cases, review triggers route boundary changes to the architect, and decision rights set how long review may take.
Drift: The difference between model and estate, in two directions. An estate element the model lacks gives false assurance; a model element the estate lacks is mostly hygiene but hides the first kind. Each finding becomes a pull request and the drift rate is reported.
What remains a document: Generated narratives, rationale in decision records, policy statements for people and contracts. The test is whether a person will read it to decide or to act; if a rule could answer the question, the rule is the artefact.

Interactive exercises

Match: Security properties on model elements
Put in order: Moving a reference document into a model

Done on the lesson page, with feedback at once.

Discussion

The chapter expects about half the sentences in a reference document to be testable. What does that suggest about the other half, and where should that reasoning live?
Hansa's review board still reviews documents generated beside the model, so its decisions and the model can disagree. How would you resolve such a disagreement, and who should own the outcome?
Nordvik models its supplier's system as a single black-box element with contractual properties. What can such an element assert, and what can it not?

Exercise · 30 minutes

From reference document to model and rule

Take one section of your security reference architecture, or use Nordvik Region's zones and its supplier TriageSoft. List every sentence that states a principle and mark it as testable now, testable with a new property, or not testable. Define a closed vocabulary of three to six trust zones and three to four data classes. Model only the flows that cross a zone boundary, giving each element a stable name, a trust zone, an owner and, for AI elements, a usage mode, and each crossing a policy point. Write in plain language one completeness rule and one boundary rule, and list the protected paths with two owners each.

Deliverable: A one-page model sketch with properties on elements and crossings, a marked list of principles, two rules in plain language and an ownership table with a second owner on every protected path.

Self-test

In Hansa's worked example, a product team adds a relationship from the claims-triage agent directly to the core claims system. What happens?
1. The boundary rule reports a zone crossing without a policy point, and the pull request cannot merge
2. The fortnightly review board is convened to read the changed diagram
3. The change merges, and the drift comparison reports it as a finding to be corrected within the 30-day age limit
4. The completeness rule fails because the agent has no trustZone property
Why does the chapter say a closed vocabulary matters more than a rich one for model properties?
1. Because Structurizr limits the number of properties an element may carry
2. Because auditors can only review a short list of trust zones
3. Because a rule cannot test a property that two teams spell differently
4. Because DORA Article 8 prescribes a fixed list of asset classes
How does Hansa Mutual treat an agent identity found in the estate that the model does not contain?
1. As hygiene, to be cleared at the next quarterly review
2. As an exception that the platform team may approve
3. As a reason to switch the boundary rule to report-only mode
4. As a finding for the identity domain architect on the day it is found

Chapter 6 · 90 minutes

Threat Modelling Transformed: Continuous, Generated and AI-Assisted

The lesson shows how threat modelling changes from a workshop document to a model generated from the architecture repository, regenerated when a boundary moves and enforced by the pipeline. Participants learn the shared vocabularies, the six recurring trust boundaries of AI systems, the lethal trifecta, the limits of an AI generator at Level 1 Assisted, and the four decisions a named reviewer can take on a candidate. They write and decide threat entries for an agentic system.

Learning objectives

Explain why a regenerated threat model can show what an annual workshop cannot, and what the workshop is still for.
Identify the six recurring trust boundaries of an AI system and the legs of the lethal trifecta an agent holds.
Decide candidate threats as accepted, reclassified, rejected or deferred against the soundness criteria, recording a reason.
List the conditions under which the threat-model gate fails a merge.

Key concepts

Two layers of generation: A deterministic layer emits a boundary record and STRIDE threat stubs for every relationship crossing a trust zone and compares them with the last accepted model; an AI layer adds candidates the rules cannot derive. Each threat keeps an identifier that survives regeneration.
Lethal trifecta: Simon Willison's test for agentic systems: an agent with access to private data, exposure to untrusted content and the ability to communicate externally can be steered into disclosing the data. The model records which legs are present and which control removes the others.
Vector as a class of behaviour: A threat entry records the vector as a class of behaviour and never as an operational recipe. That is enough to design a control, a detection and a test, and keeps the model shareable with a supplier, an auditor and a works council.
Reviewer decisions: A named person accepts each candidate, reclassifies it, rejects it with a reason and a revisitWhen trigger, or defers it to an owner and a date after which the pipeline blocks. Accepting residual risk is a separate decision for the risk owner.
verifiedBy: The field that points an accepted threat to an attack case described by its set-up and expected outcome. A threat without one is declared, not verified, because an accepted threat that nothing tests is a belief.

Interactive exercises

Match: Six trust boundaries of an AI system
Scenario: An outbound tool for the claims-triage agent

Done on the lesson page, with feedback at once.

Discussion

The gate rule that fails when a boundary changed without any threat considered is called the most valuable. Why can a reviewer who reads only candidates not see that failure?
A long list of fluent candidates invites complacency and automation bias. What in the design of the review loop would you change to counter that in your own team?
Nordvik models a few systems in depth because its reviewers are few; Hansa needs generation because no person can read every pull request. Which constraint governs your choice of method?

Exercise · 35 minutes

Decide three candidate threats for a changed boundary

Work on Hansa Mutual's claims-triage agent, or on an AI system you know, after a change that adds a new intake path for third-party content. Record which legs of the lethal trifecta the system holds and which control cuts the remaining one. Write three candidate threats for the changed boundary. For each give a stable identifier, the boundary, a STRIDE category, the vector as a class of behaviour with no adversary strings, and a mitigation family outside the model. Then act as the named reviewer: accept, reclassify, reject with a reason and a revisit trigger, or defer with an owner and a date. For each accepted threat name an owned control and describe an attack case by its set-up and expected outcome.

Deliverable: A threat model excerpt with the trifecta record and three decided entries, each with reviewer, reason, controls and a verifiedBy attack case where accepted.

Self-test

At which autonomy level does the chapter place the AI generator of candidate threats by default?
1. Level 0 Advisory, with no access to the repository
2. Level 1 Assisted, writing only to a pull request comment
3. Level 2 Supervised, writing accepted items directly
4. Level 3 Bounded, accepting low-risk threats within a playbook
In Hansa's threat model, why is T-103, claim data leaving through an outbound channel, rejected?
1. Because the threat-modeller agent classified it under the wrong STRIDE category
2. Because the risk owner accepted the residual risk with an expiry date
3. Because the attack case in HM-SEC-003 passed in the last campaign
4. Because the manifest holds no outbound tool, and revisitWhen brings it back if one is added
Which mitigation does the soundness criterion on the right family explicitly rule out as a replacement for a control?
1. Improving the system prompt in place of a control outside the model
2. Entitlement filtering on the retrieval index
3. Task-scoped credentials for tool calls
4. Schema validation of output before it is written into a system of record

Chapter 7 · 90 minutes

Designing Boundaries: Zero Trust and Containment for People, Agents and Machines

The lesson treats the boundary as the security architect's main product. Participants learn its four properties, how zero trust is extended to agents by verifying the action as well as the actor at a policy decision point outside the model, why relays are egress paths, how correlated controls fail together, the six elements of containment that does not depend on intent, and blast radius as a design parameter. They design a containment profile and review it for shared dependencies.

Learning objectives

State the four properties of a boundary and explain why a system prompt has none of them.
Review a boundary for correlated controls, treating every service that relays for its clients as an egress path.
Design a containment profile for an agent using the six questions, with a checkable blast radius statement.
Specify tests that show a boundary holds from a position the contained party cannot influence.

Key concepts

Four properties of a boundary: A boundary is enforced outside the party it governs, states a ceiling on consequences instead of a hope about behaviour, is an artefact with an owner, a version history and a test, and can be shown to hold without the cooperation of what it contains.
Policy decision point outside the model: Deterministic code between model and tool servers that evaluates every tool request against a versioned permission manifest. It decides on structured facts such as tool, arguments, identity and target, never by a classifier judging whether output looks harmful.
Correlated controls: Controls that share a dependency, such as a credential, a shared service or the administrative plane, so that one failure defeats two or more. The chapter treats a correlated control failure as a design defect the architect can look for.
Blast radius: The largest harm an actor can cause with the permissions it holds before it is stopped, determined by reach, rate, duration, reversibility and spread. The weakest dimension sets the radius, and the architect writes it as a statement a reviewer can check.
Containment profile and permission manifest: The manifest is the agent's declared intent: purpose, identity, tools, constraints, approvals and budgets. The profile is the platform's commitment whatever the agent attempts. The profile must be at least as strict as the manifest and must not depend on the manifest being obeyed.

Interactive exercises

Sort: Ceiling or rate
Scenario: A mirror for the build agents

Done on the lesson page, with feedback at once.

Discussion

A stop instruction sent to an agent is merely a request the agent processes. What in your estate is currently called a stop path but would not act if the system did not cooperate?
Nordvik must verify by evidence what it buys, and Hansa what it builds. What can a tender annex with verification rights achieve that a supplier questionnaire cannot?
The chapter says to fix a shared dependency instead of adding a compensating control. When is that advice hard to follow, and what should the decision record then say?

Exercise · 35 minutes

Design a containment profile in six questions

Choose an agent your organisation runs or plans, or take a hypothetical operations agent at Hansa Mutual. Answer the chapter's six questions: what may the agent change, with each write's target and reversibility; which legs of the trifecta it holds and which is removed; where it may send things, as a default-deny allow-list with relays treated as egress paths; what it borrows, such as credentials, shared services and log sinks; how much it can do before a person sees it, as budgets for steps, time, spend and writes; and who stops it and how that is shown. Write the blast radius as one checkable sentence. Then list each control's dependencies and mark any that appear under two controls or that the agent can reach.

Deliverable: A containment profile in the form of CP-HM-ITOPS-01 with ceiling, egress, blast radius statement, dependencies, stop holders and tests, plus a list of correlated-control findings with owners.

Self-test

What does the chapter mean by extending zero trust to agents?
1. Granting agents the same network location trust as managed devices
2. Asking a classifier to judge whether each output looks harmful
3. Verifying the action as well as the actor, at a policy decision point outside the model
4. Requiring agents to confirm in their instructions, before every tool call, that they will stay within scope
What did the review recorded as AIDR-0552 change in the containment of Hansa's IT-operations agent?
1. It raised the write budget from four to twenty actions per incident
2. It restricted the shared artefact mirror to a signed allow-list and removed it from the agent's destinations
3. It moved the stop decision from the on-call engineer to the review board
4. It replaced the weekly egress probe from outside the agent's network with a quarterly attestation by the profile's owner
According to the chapter, what happens to a control's classification when its boundary test fails or becomes overdue?
1. It stays verified until the owner confirms the finding in writing
2. It is removed from the catalogue until the next audit
3. It is marked amber and reported to the design authority
4. It moves from verified to declared automatically

Chapter 8 · 75 minutes

Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority

The lesson covers identity architecture for workloads and agents. Participants learn why distributed secrets are replaced by attested, short-lived identities issued outside the runtime, how to choose between an agent's own identity and a person's, how delegation differs from impersonation, why every machine identity leads to an owner, operators and an authority, how approvals are made to resist synthetic media, and the lifecycle from registration to retirement. They register an agent identity and trace an action back to a named person.

Learning objectives

State the four requirements for workload identity and explain why one identity per workload is the lesson of the July 2026 incident.
Choose between an agent's own identity, delegation and a person's identity for a given action, using the chapter's design test.
Draft an identity record for an agent with scopes, token lifetime, named roles, revocation and review.
Design an approval rule that holds against synthetic media using call-back, dual control and out-of-band confirmation.

Key concepts

Attested workload identity: An identity issued from outside the workload after attesting it from properties of its platform, short-lived and one per workload, so that a log line names exactly one actor and a revocation stops exactly one. SPIFFE and SPIRE are the chapter's reference.
Delegation versus impersonation: In OAuth 2.0 Token Exchange, impersonation makes the holder indistinguishable from the subject, while delegation identifies both and names the acting party in the act claim. The architect requires delegation and prohibits impersonation for agents so the audit trail keeps both visible.
Owner, operators and authority: The three kinds of person behind every machine identity. The owner answers for its existence and purpose, the operators watch it and can revoke its credentials, and the authority approves scope and autonomy level and accepts residual risk, and is never the agent's builder alone.
Approvals that resist synthetic media: Call-back through a contact from a trusted register, dual control by a second approver who did not receive the request, and out-of-band confirmation in an authenticated system of record, bound to changes in who or what may act as well as to payments.
Reconstruction exercise: Take an action from the last quarter at random and trace it to the person who answers for it without asking the agent anything. If the trace stops at an account, a team mailbox or a shared credential, the identity model has a design defect.

Interactive exercises

Put in order: The machine identity lifecycle
Match: People and approvals behind an identity

Done on the lesson page, with feedback at once.

Discussion

The chapter calls collapsing agent and person into a single identity the most common mistake in AI integrations. Where does that happen in your estate, and whose accountability does it destroy?
At Level 3 Bounded, accountability concentrates on the authority who signs the playbook. How would you explain that to a manager who believes automation spreads the responsibility?
A missed review disables the identity by default. What operational objections would you expect, and how does the chapter's reasoning on improper offboarding answer them?

Exercise · 25 minutes

Register an agent identity

Choose one agent or automated workload that acts in production in your organisation, or use an evidence-collection agent of the kind Hansa Mutual runs. Follow the chapter's practical guide. Write the purpose in one sentence and choose the identity type. List the scopes as resources and actions, each with its autonomy level, starting read-only, and deny by name what an intruder would want most. Set the token lifetime and what the token is bound to. Name the owner, at least two operators and the authority as roles bound to holders, with different people as owner and authority. Define revocation by a path outside the agent's runtime with a target time, the review interval and what happens on a missed review. Then trace one action from token to named person.

Deliverable: An identity record in the form of HM-EVC-001 and a five-step reconstruction trace from one logged action to the person who answers for it.

Self-test

What revocation target does the chapter's practical guide set for a Mode 5 agent, by a path outside the agent's runtime?
1. 5 minutes, the same as the token lifetime
2. 15 minutes, the default token lifetime
3. 24 hours, after a cooling-off period
4. 60 seconds, tested by a revocation test
In Nordvik's call-back rule CBR-NR-BEN-01, why is the contact register fixed at contract signature?
1. Because public-access rules forbid later changes to supplier records
2. Because that was the one moment when the Region verified who TriageSoft's people are
3. Because the supplier's staff are not allowed to change during the contract
4. Because the European Digital Identity Wallet requires a fixed register
How does the chapter describe the rule that Level 4 Autonomous is never used for irreversible actions, in terms of identity?
1. As a rule of issuance: the broker issues no Level 4 token for an action the register classes as irreversible
2. As a rule of intent: the agent is instructed never to propose such actions
3. As a rule of review: the fortnightly board samples every Level 4 action afterwards and reverses those it rejects
4. As a rule of ownership: only the owner may request a Level 4 token

Chapter 9 · 90 minutes

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

The lesson makes the control catalogue, the evidence manifest and the assurance relationship the architect's artefacts. Participants learn the anatomy of a complete control entry, how one control is mapped once to many obligations, where evidence comes from and why it has a maximum age, the rule that classifies controls as verified, declared or failed, why shared dependencies count as one, and how the auditor's work changes. They write a control entry and classify a set of controls.

Learning objectives

Explain which three connections the architect owns in the catalogue and where that ownership stops.
Write a complete control entry with a falsifiable objective, an implemented_by path, a test, evidence with a fail condition and reviewed mappings.
Classify controls as verified, declared or failed by rule and open a finding for every status other than verified.
Describe how a catalogue as code changes the work of the auditor while preserving independence.

Key concepts

Falsifiable objective: One sentence that a test can disprove, such as: an agent cannot call a tool that its manifest does not name. A sentence such as 'access is appropriately managed' cannot be tested and so cannot be verified.
Assure once, comply many: A control is written once and mapped to every obligation it serves, each mapping with its relation, reviewer and date. Written four times it would drift into four controls; mapped four times it is tested once and the result serves every column.
Fail condition and maximum age: The fail condition names the observation that would prove failure, since a query that describes success invites confirmation. The maximum age turns a control declared the day its evidence expires, which also catches a collector that silently stops.
Verified, declared, failed: Verified: test passed within cadence and machine-generated evidence within its maximum age. Declared: no recent passing test, stale evidence or attestation only. Failed: the last test failed or the evidence query returned its fail condition. There is no amber.
Shared dependency: Two controls that depend on the same tool gateway or model provider fail together, so the coverage view counts controls with a common dependency as one. Counting controls is not the same as counting protection.

Interactive exercises

Sort: Verified, declared or failed
Scenario: A status typed by hand

Done on the lesson page, with feedback at once.

Discussion

A declared entry is a known gap, not an error. How would your management review react to a first report in which most controls are declared, and how would you prepare it?
The chapter says evidence a system produces about itself is weaker than evidence from outside it. Which of your current evidence sources would fail that test?
Hansa brings the United Kingdom and Swiss mappings into the catalogue as entries the local security officers own. Why does the chapter keep authorship with them?

Exercise · 35 minutes

From spreadsheet row to control entry

Take three rows from your organisation's ISO/IEC 27001 Annex A spreadsheet or statement of applicability, or three supplier-held controls of the kind in Nordvik Region's catalogue. Remember that a row is a requirement and an entry is a control. For each, write an entry with a stable identifier, one falsifiable objective, the owner and the architect, the threats it answers, an implemented_by path to a real configuration, policy rule or contract clause, a test with its cadence, an evidence source with a fail condition and maximum age, and the obligations it maps to with relation and reviewer. Apply the classification rule to each and open a dated finding with an owner and a re-test for every declared or failed control.

Deliverable: Three control entries in the form of CTRL-AGT-002, each with a derived status, and a findings list for every entry that is not verified.

Self-test

Who or what sets the status of a control in the chapter's design?
1. A rule applied in the pipeline, owned by the architect and reviewed by the CISO
2. The control owner, who types it in after each test
3. The evidence-collection agent, which may promote controls it has checked
4. Internal audit, at the annual management review
In the first report from Nordvik's catalogue, why is CTRL-LOG-001 classified as failed?
1. The supplier TriageSoft had provided only a written statement, with no evidence the Region could collect itself
2. The evidence for the control was older than its maximum age
3. A replay found the managed security service provider's detections cover only some Region scenarios
4. The entry had no owner and so did not pass the validator
What does the coverage view say about CTRL-AGT-002 enforcing three agents' permission manifests through the same tool gateway?
1. That the three agents are protected by three independent controls
2. That the gateway is one point of failure, leading to a second independent control or an accepted risk
3. That the control must be split into one catalogue entry per agent, each with its own test and separate evidence
4. That the control answers no threat and is a candidate for retirement

Chapter 10 · 90 minutes

Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design

The lesson adds time to the properties the architect owns. Participants learn the evidence for the collapsing exploitation window and how it is labelled, the four intervals of notice, decide, act and verify, patch velocity as a service level built from EPSS, KEV, the EUVD and exposure, decisions delegated in advance under enforced conditions, detection and canaries designed in, and the stop path as a timed property. They set service-level classes and design a timed stop drill.

Learning objectives

Explain the four intervals of the estate clock and why the decide interval usually holds most of the time.
Define patch-velocity classes from public signals and exposure, each with a target and a decision path.
State the conditions under which a patch or containment decision can be delegated in advance.
Design a timed stop drill with a budget, instrumented intervals, named stop holders and a pass criterion.

Key concepts

Notice, decide, act, verify: The four intervals of the estate's clock: until someone who can act knows, until someone with the right has chosen, until the control is in effect, and until independent evidence shows the effect. A total alone hides where the time goes.
Patch velocity as a service level: The time from a vulnerability entering a priority class to a verified fix or compensating control, with a committed target per class and misses reported with reasons. Classes combine EPSS, KEV, the EUVD and exposure from the inventory.
Delegated in advance: For known-exploited vulnerabilities on exposed assets the decision is delegated beforehand and reviewed afterwards, under conditions that are properties of the architecture: a tested rollback, a health check, a canary ring and an exclusion list. The management body decides whether the delegation stands.
Canary: An object no legitimate process has a reason to touch, such as a decoy credential, host entry or tool, so a touch is a high-confidence alert that needs no baseline. Its registry sits outside the reach of what it watches.
Timed stop path: A stop path that lives outside the system it stops, has more than one mechanism sharing no dependency, is held by named people around the clock, and is measured by drill against a budget set from blast radius.

Interactive exercises

Sort: Patch-velocity classes
Put in order: The estate's clock

Done on the lesson page, with feedback at once.

Discussion

In most estates the time goes in the decide interval. Where does a known-exploited vulnerability on an exposed asset wait in your organisation, and who would have to approve removing that wait?
The chapter argues that an estate able to act in minutes loses little if the window stops shrinking. How persuasive is that argument for a board weighing the cost?
Nordvik cannot build machine-speed properties itself. What should a contract annex for a managed security service provider specify so that the numbers are observable and not declared?

Exercise · 35 minutes

Design a timed stop drill and a service level

Part one: for one group of internet-facing assets, define patch-velocity classes using the chapter's defaults as a starting point, recording any adaptation to your risk appetite, and split the target of the most urgent class into notice, decide, act and verify. Mark any interval that waits for a meeting. Part two: choose a system that can cause irreversible harm, or use Nordvik Region's integration route to the benefits-triage system. List every stop mechanism with its dependencies, name at least two stop holders for every hour of the week, set a budget from blast radius, state the trigger, and say how each interval is timestamped and what a pass means.

Deliverable: A class table with targets and decision paths, and a one-page drill plan with mechanisms, dependencies, stop holders, budget, trigger, timestamps for the four intervals and the pass criterion.

Self-test

In the chapter's default classes, what is the target for a known-exploited vulnerability on an internet-facing asset?
1. 7 days, as an expedited standard change
2. 30 days, as a standard change
3. 24 hours mitigation and 72 hours fix, delegated in advance
4. 4 hours fix, approved by the change advisory board
Why did Hansa's first timed stop drill of the IT-operations agent fail its five-minute budget?
1. The alert reached a duty analyst without the decision, and 15-minute tokens outlived the revocation
2. The canary registry was readable by the agent, which avoided the decoy
3. The managed security service provider held the runbook but lacked credentials to the integration gateway
4. The executive board had not yet approved the delegated playbook
How does the chapter label the claim that patch velocity will become a supervised metric?
1. Observable, because NIS 2 Article 21(2)(e) on vulnerability handling already requires a reported service level
2. Expected, on the signal of the European Central Bank's July 2026 letter to significant institutions
3. Speculation, as AI Platform and Security, Chapter 25, labelled it
4. Observable, because CISA's directive applies to European entities

Chapter 11 · 90 minutes

Resilience and Recovery by Design: The Architect's Share of Recoverability

The lesson sets out the architect's share of recoverability: design, verification and requirements, while operators run the recovery. Participants learn the four properties of known-good definitions, the four requirements for recovering AI systems, degraded modes, how the fallback erodes and how a fallback manifest and reversibility tests counter it, and security chaos engineering with its safety boundaries. They write a recovery definition and plan a reversibility test for a delegated function.

Learning objectives

Distinguish the architect's share of recoverability from the operators' share.
Specify completeness, integrity and provenance, separation and order for the known-good definitions of a system.
Draft a recovery definition for an AI system with degraded modes and named people who decide to resume.
Plan a reversibility test for a delegated function with acceptance criteria written beforehand.

Key concepts

Recoverability: The measured ability to carry out a recovery plan. Recovery time and point objectives are requirements on the architecture, each met by a design decision and shown by a test; an objective no design can meet is a finding for the risk owner.
Known-good definitions: The definitions from which a system is redeployed, which must be complete, signed with provenance the deployment path verifies, held with their keys outside the blast radius, and ordered in a dependency graph checked for cycles.
Recovered AI system: One shown to behave as it did before the incident, not merely one that is running. It needs a known-good source for every component or a design that needs none, an index rebuild path, pinned and replaceable provider components, and evaluation before return.
Degraded mode: A predefined configuration the organisation can switch to without a change process: a lower autonomy level, fewer functions or a manual procedure, for every AI system whose function the organisation cannot afford to lose.
Fallback manifest: A designed artefact that names the fallback procedure, the people who must be able to perform it, the interfaces it needs and the date it last ran. A scheduled check confirms links resolve, people still hold role and access, and the last exercise is within its interval.

Interactive exercises

Match: What makes a definition known-good
Scenario: Resuming the agent after recovery

Done on the lesson page, with feedback at once.

Discussion

The chapter says the pipeline cannot restart what a person stopped. What would be lost and what protected if your organisation adopted that rule for its agents?
An annual test cannot catch an erosion that begins the week after it. Which fallback in your organisation was last performed by people who are still in role?
A platform that deliberately disturbs controls is among the most dangerous systems an organisation can run. Which of the chapter's safety boundaries would you insist on before a first experiment?

Exercise · 35 minutes

Recovery definition and reversibility test

Choose an AI system whose function your organisation could not afford to lose, or use the urgency ranking in Nordvik Region's benefits-triage system. Part one: write its recovery definition. State the objectives, the known-good source of each component and how it is verified, what happens to identity, memory and pending actions, the degraded modes with their triggers, and who decides to resume and on what evidence. Part two: plan a reversibility test for the delegated function. Write the scenario, the period and the acceptance criteria beforehand, including any statutory deadlines, name who applies the abort rule, list what you will measure, and say how the result will be classified as passed, passed with conditions or failed.

Deliverable: A recovery definition in the form of RCV-HM-CTA-01 and a one-page reversibility test plan with scenario, criteria, measures, abort rule and classification.

Self-test

What does Hansa's recovery definition RCV-HM-CTA-01 do with the claims-triage agent's memory and pending actions?
1. It restores both from the last evidence bundle and replays the queue automatically
2. It discards the memory and freezes pending actions for review, with no automatic replay
3. It keeps the memory and lets the pipeline replay the queue after evaluation
4. It archives both with the supplier until the supervisor has been informed
What did the architect at Nordvik Region find when rehearsing the manual degraded mode with a benefits team that had not taken part in the live exercise?
1. That the hosting provider could not deliver replacement accelerators within four hours
2. That the fallback called the same provider as the system it replaced
3. That the stop path took 26 minutes against a budget of 15
4. That only two caseworkers still remembered how to work without the ranking
Why is Level 4 Autonomous not used for recovery at all, according to the chapter?
1. Because DORA Article 12 names the level and prohibits it for restoration
2. Because recovery tooling cannot hold an identity of its own
3. Because Level 4 is never used for irreversible actions, and recovery contains some
4. Because chaos experiments must first reach 20 safe runs in production

Module 3 · Part III · The Architect's AI Team

Part III follows Shift 4, from sole author to conductor of an AI team, from one assistant to a governed agent team. Four lessons cover the architect's own use of AI in Modes 1 to 3, an agent team under a mandate manifest enforced outside the agents, review for soundness by techniques that do not trust the proposer, and the practices that keep the craft on which verification depends. Participants leave with a mandate manifest, a tiered review protocol, a review record and a craft-keeping programme.

Chapter 12 · 75 minutes

The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3

The lesson treats the architect as a user of AI in Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants and Mode 3 Agentic work tools, where the AI acts with the architect's identity. Participants learn the four kinds of task and their characteristic failures, what the evidence says about productivity and quality, how architecture information is routed by class, which records make use reviewable, and the daily habits that keep judgement independent. They draft a mandate manifest and routing rule for their own use.

Learning objectives

Match each of the four kinds of assisted task to its characteristic failure and the verification that suits it.
Summarise what the cited studies found on productivity and on quality, and what the chapter labels observable and expected.
Design a routing rule for architecture information by class that is enforced outside the client.
Apply the three tests that decide when AI-assisted work needs a decision record.

Key concepts

Four kinds of task: Drafting fails as fluent text stating an unreached position, research as a fabricated or misattributed source, review as an invented or missed finding, and analysis as a pattern from an unrepresentative sample. The assistant is used where verification costs less than doing the work unaided.
Jagged frontier: The finding that consultants did better on tasks inside what the model could do and were 19 percentage points less likely to reach a correct answer on a task outside it. A plausible answer looks the same on both sides.
Protected oracles: Tests, policy-as-code rules and schemas kept in a path the tool cannot write to, because an agentic tool asked to make a failing test pass may change the test. A change that touches an oracle is flagged for review.
Routing by class: Public and internal work may use the approved enterprise tier of a cloud assistant; confidential and protected work reaches only self-hosted or sovereign-hosted models through the AI gateway from a workspace with default-deny egress. Unlabelled work defaults to confidential.
Work log, session record, decision record: Three records with distinct purposes: the work log says which drafts came from the tool and how they were verified; the session record keeps full prompts and outputs for a short fixed period; the decision record says why the architect decided as they did.

Interactive exercises

Match: Four tasks, four verifications
Sort: Routing architecture work by class

Done on the lesson page, with feedback at once.

Discussion

Developers in the randomised trial predicted and afterwards still believed in a speed-up they did not have. How would you measure the effect of assistants on your own architecture work?
Self-hosting buys confidentiality at the price of a verification burden. Where would you draw the line between the cloud tier and the self-hosted route for your architecture information, and why?
The chapter says an architect who describes a design with evident confidence receives an answer shaped by that confidence. What changes in how you ask would counter that?

Exercise · 25 minutes

A personal AI workflow for architecture work

Following the chapter's practical guide, set up your own workflow on paper. Inventory the AI you already use in Modes 0 to 3, with the identity, reachable data and provider of each. Classify the architecture information you handle as public, internal, confidential or protected, and write the approved route for each class. Then write a mandate manifest for one Mode 3 tool: holder and approver, allowed models and route, allowed data classes and the three things that never leave the controlled route, autonomy per action with no more than Level 2 Supervised for edits, allowed tools, protected oracle paths, records and a stop path outside the tool. Add the first five lines of a work log.

Deliverable: A routing table by class, a mandate manifest in the form of MND-NR-01 and a five-line work log stating what was drafted with the tool and how it was verified.

Self-test

What did the randomised trial with sixteen experienced open-source developers on 246 real issues find?
1. Tasks were completed 55.8 per cent faster when AI was allowed
2. About a quarter more tasks were completed, with the larger gains going to the less experienced developers
3. Tasks took 19 per cent longer with AI, though the developers believed they had been sped up
4. No measurable difference in time, but fewer security weaknesses
In the mandate manifest MND-NR-01, version 1.0.0, what may the Mode 3 tool do with commits?
1. Nothing: commit and push are denied, while edits and commands run at Level 2 Supervised
2. Commit at Level 2 Supervised after the architect approves, but never push to the main branch of the repository
3. Commit and push at Level 3 Bounded within a playbook
4. Commit freely to an agent branch that the architect merges
According to the chapter, when does a decision that an assistant shaped materially need a decision record?
1. Whenever any draft text came from the assistant, however routine the decision
2. Only when a supervisor or auditor later asks for one, in which case it is written retrospectively and marked so
3. Only when the assistant ran on a cloud tier
4. When options, framing or evidence came from the assistant and the decision is hard to reverse

Chapter 13 · 90 minutes

An AI Agent Team for Security Architecture: Skills, Mandates and Containment

The lesson moves from one assistant to a team of narrow agents, each with its own skills, identity, autonomy level per action and containment. Participants learn the five roles and why narrowness matters for security, what a mandate manifest contains and which systems enforce it, the seven containment measures for the architect's own agents, how disagreement between agents is escalated, how the team is operated and retired, and how it is kept from becoming a system for evaluating people. They write a mandate manifest.

Learning objectives

Describe the five agent roles of a security architecture team with what each writes, its mode, identity and default level.
Write a mandate manifest with a level per action, a list of what no agent may ever do, budgets, escalation rules and a stop path.
Explain the seven containment measures for the architect's own agents and why control artefacts stay out of their reach.
Assess whether an organisation has the capacity to supervise an agent team, using the staged introduction and Nordvik's decision to defer.

Key concepts

Narrow agents: Agents triggered by events in the architecture repository, each needing only what its task requires. One general assistant would need the union of all permissions; narrow agents can be bounded and stopped one at a time.
Mandate manifest: The written mandate of the architect's agents, kept as code and not a prompt. The identity provider, the policy decision point, the egress gateway and the branch rules read it, and where it disagrees with the containment profile the narrower one wins.
Agents draft; humans approve: A property of the repository, not a habit: branch protection requires review by code owners, the code-owner file lists only named architects, and the merge is always performed by a person. No agent approves its own output or another agent's.
Disagreement without arbitration: When the pipeline detects conflicting agent outputs on a pull request, it labels it, places both outputs side by side and requests review from the code owner of the affected path, who decides and records the rationale. No agent arbitrates and there is no vote.
Agents that read people's work: A review agent sees who wrote what, so agent output attaches to the change, not the person; the manifest prohibits per-person metrics and performance evaluation, and review-quality measures are reported at team level as agreed with employee representatives.

Interactive exercises

Sort: What the agent team may do, and at what level
Scenario: Two agents disagree

Done on the lesson page, with feedback at once.

Discussion

The chapter warns that a falling rejection rate may mean reviewers have stopped looking. What evidence would you require before granting an agent a higher autonomy level?
Nordvik's reasons for deferring an agent team concern capacity, not technology. Which of its review triggers would have to be met in your organisation before a team makes sense?
A review agent on an architecture repository holds all three legs of the lethal trifecta by default. How would you break the trifecta for each agent in a team you might run?

Exercise · 35 minutes

Write a mandate manifest for an agent team

Design a small architecture agent team for your organisation, starting with a reviewer and a threat modeller, or decide to defer. If you proceed, follow the chapter's seven steps: state purpose and scope with named repositories and no wildcard scopes; give each agent its own identity with a named owner and operators; list each action with a level, and an explicit list of what no agent may ever do; set data limits and budgets; write the escalation rules, the containment profile reference and the stop path with its holder by role; record personal data and its prohibited uses; set review and expiry. If you defer, write the decision record with the options rejected and the conditions that would reopen the question.

Deliverable: A mandate manifest in the form of MND-HM-01 for at least two agents, or a decision record in the form of AIDR-0503 with rejected options and review triggers.

Self-test

Which is the only action that runs at Level 3 Bounded in Hansa Mutual's architecture agent team?
1. The policy author pushing a tested egress rule to the main branch
2. The evidence collector refreshing an evidence link within an approved playbook
3. The reviewer approving documentation changes with no control effect
4. The threat modeller accepting low-risk candidate threats
How is the work of the agent team orchestrated, according to the chapter?
1. By a manager agent that assigns tasks to the narrow agents and filters their outputs for the architect
2. By the reviewer agent, which decides which drafts reach a person
3. By a vote among the agents when their outputs conflict
4. By a deterministic pipeline; no agent assigns work or decides which outputs reach the architect
Why did Nordvik Region reject option A, building a five-agent team, in AIDR-0503?
1. One architect cannot supervise a team and there is no second reviewer
2. Hosting outside the reserved capacity is not accepted
3. The union refused consultation under the co-determination agreement
4. Open-weight models were found too weak for threat modelling

Chapter 14 · 90 minutes

Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI

The lesson settles how an architect can know that an AI-proposed change is sound when it arrives faster than it can be re-done and reads fluently. Participants learn the four soundness properties defined in advance, the three techniques that do not trust the proposer, the limits of a second agent as critic, review depth by computed tier, automation bias as a design problem, the four signals of rubber-stamping, and the signed review record. They review a proposal and write its record.

Learning objectives

Define soundness in advance through grounding, completeness, consistency with principles and stability under re-asking.
Apply independent re-derivation, oracles and provenance to a proposed change and explain why reading the rationale is not enough.
Assign a review tier to a change by rule from reversibility, blast radius and artefact type.
Design a team-level measurement of review quality that does not monitor individuals.

Key concepts

Correct-looking versus sound: A proposal is correct-looking when it is well formed and carries a rationale that reads well; it is sound when its reasoning would survive scrutiny by someone who knows the system. Soundness is defined before review starts so the proposal does not define it.
Expectation note: Two or three lines the reviewer writes before opening the diff, stating what the change should contain and what it must not touch. It is the lighter form of independent re-derivation and anchors the review in the reviewer's reasoning.
Oracle: A check that decides whether an output is acceptable without reference to how it was produced. Oracles must be outside the proposer's reach, a proposal that changes one takes the highest tier, and a missing test for the property at risk is a finding.
Review tiers: Tier 0 routine, Tier 1 standard, Tier 2 significant and Tier 3 irreversible or self-referential, assigned by rule before any human reads the proposal. A human may raise a tier but not lower it without a recorded reason.
Signals of rubber-stamping: Time to approval relative to size and tier, a rejection and amendment rate near zero, reversals of approved changes, and the seeded-error detection rate, the only signal that measures review directly. Each is a finding about the review design, not about a person.

Interactive exercises

Sort: Which review tier
Scenario: Two runs, two different changes

Done on the lesson page, with feedback at once.

Discussion

The chapter says slowing the agents is cheap to reverse, whereas thinning the review is invisible. How would you make that case to a manager who measures the team by throughput?
When an approved change later proves defective, the record shows whether the review or the tier rules failed. Why does that distinction matter for how the organisation responds?
What would have to be agreed with employee representatives before you could measure time to approval and seeded-error detection in your team?

Exercise · 35 minutes

Review an AI-proposed change by tier

Take three AI-proposed changes from your own practice, or use these: an evidence-link refresh, a change to one agent's tool policy for a single market, and a new requirement in a tender annex. Assign each a tier by rule from reversibility, blast radius and artefact type, and state the techniques and human review that tier requires. For the tool-policy change, write the expectation note before reading any proposed text, name the oracle that should pass and the property for which a test might be missing, list the provenance you would require, and dispose of two imagined critique objections with reasons. Record the result as a review record with tier, oracles, critique, reviewer, minutes spent and decision.

Deliverable: A three-row tiering table and one review record in the form of REV-HM-0014 with expectation note, oracle results, objections and dispositions, and a reasoned decision.

Self-test

Which soundness property does the chapter call the most specific to AI?
1. Stability under re-asking: the same inputs should produce materially the same change
2. Grounding: every identifier resolves in the model, catalogue or source register
3. Completeness: every boundary, market and control the change touches is addressed
4. Consistency with principles and earlier decisions
How was the defect in the policy change of review record REV-HM-0014 found?
1. The critique agent on a different model family rejected the proposal outright and the pipeline blocked the merge
2. The existing oracle suite for the claims-triage policy failed on the first run of the pull request
3. The reviewer saw no test covered market binding, wrote one, and the proposal failed it
4. A post-merge sample of Tier 0 changes revealed a control effect in the Dutch market overlay
Which tier does a change to an oracle, to the review protocol or to a mandate manifest always take?
1. Tier 1, with one named reviewer and an expectation note
2. Tier 3, the highest, with full re-derivation and two reviewers or the decision forum
3. Tier 2, with re-derivation of claims and a reason for approval in the domain owner's own words
4. Tier 0, with a random sample reviewed after merge

Chapter 15 · 75 minutes

Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can

The lesson sets the condition on which Shift 4 is safe: the conductor must still be able to play. Participants learn why the ironies of automation apply to the architect with particular force, what early studies show on reliance and deskilling and how the chapter labels them, the three parts of judgement, the seven craft-critical capabilities, deliberate practice, no-AI exercises and seeded-error drills, apprenticeship by design, and the gate that paces autonomy to the skills available. They design a craft-keeping programme.

Learning objectives

Explain three reasons why Bainbridge's ironies of automation take a sharper form for the security architect.
Distinguish what the evidence on deskilling shows as observable from what the chapter labels expected.
Design a quarterly craft-keeping programme with protected time, unassisted work, seeded-error drills and a degraded-mode exercise.
Apply the gate that keeps an action at Level 3 Bounded only while the skills to supervise it exist.

Key concepts

Judgement in three parts: Recognising what matters, including what is missing; weighing options whose costs and risks are not commensurable against a risk appetite with incomplete information; and answering for the decision to a board, a supervisor, an auditor or a court.
Craft-critical capabilities: The set of capabilities without which AI output cannot be checked, such as drawing trust boundaries, deriving threats no catalogue suggests, writing a policy rule and its tests, finding excess authority in a manifest, re-deriving a requirement from its legal article and designing a stop path.
Deliberate practice: Activities designed specifically to improve performance, requiring effort and giving feedback. Ordinary work does not count. Its three forms are unassisted design work, drafting first, and review without the assistant.
Seeded-error drill: Known design flaws placed in proposals in a drill channel behind a merge guard, at a limited rate, revealed to the reviewer within one working day and measured per capability at team level. The flaws are mistakes an architect must catch, not attacker techniques.
Unaided-competence gate: An action may be raised to or kept at Level 3 Bounded only while at least two named architects hold current evidence of writing and testing its playbook unaided and the detection rate for related seeds stays above threshold; otherwise it returns to Level 2 Supervised.

Interactive exercises

Put in order: Designing a seeded-error drill
Match: Practice and apprenticeship by design

Done on the lesson page, with feedback at once.

Discussion

The chapter says the architect's estimate of what they could still do unaided is checked against nothing. How would you check it in your own case without turning the check into surveillance?
Automation removes the periphery where newcomers used to learn. Which junior architecture tasks would you reserve for unaided work, and what would that cost in the first year?
For a single post, team-level reporting is individual reporting. How does Nordvik's architect resolve this, and what would you do differently?

Exercise · 25 minutes

Design a craft-keeping programme

Design a craft-keeping programme for your security architecture team, or a calendar for a single post in the manner of Nordvik Region. List no more than ten craft-critical capabilities, starting from the chapter's seven. Reserve protected practice time and state how it may be reduced. Set the cadence for drafting first, unassisted reviews, seeded-error drills and a degraded-mode exercise in which AI tools are stopped and the real queue is worked unaided. Say where practice is recorded and in what form, who gives feedback, and at what level results are reported. State in writing that results are not used in appraisal. If any of your agents acts at Level 3 Bounded, write the gate that keeps it there.

Deliverable: A craft programme in the form of CKP-HM-SA-2027 or a four-quarter exercise calendar, with capabilities, cadence, evidence, reviewers and a reporting rule.

Self-test

What did the study in four Polish endoscopy centres find after AI-assisted colonoscopy was introduced?
1. Novices improved their detection rate while experts stayed level
2. Detection in AI-assisted colonoscopies rose from about 22 per cent to about 28 per cent within a few months
3. Experienced endoscopists refused to work without the AI after six months
4. Experienced endoscopists' unassisted adenoma detection rate fell from about 28 to about 22 per cent
What protected practice time does the chapter's quarterly craft-keeping programme set as a default?
1. One hour per architect per week, taken from review time
2. Half a day per architect per fortnight, about five per cent of working time
3. Two full days per architect per quarter, taken outside working hours and recorded by HR
4. Twelve days per team per year, shared among the architects
What happens to an action at Level 3 Bounded if fewer than two named architects hold current evidence of writing its playbook unaided?
1. It continues, provided the agents' acceptance rate stays high
2. It is suspended pending works-council consultation
3. It returns to Level 2 Supervised until the gate is met
4. It is escalated to the management body for risk acceptance

Module 4 · Part IV · The Role in the Organisation

Part IV places the security architect in the organisation. Five lessons cover the role map and its four seams with the AI architect, decision tiers and gates in place of meetings, European regulation read as engineering constraints, communication to five audiences from one source, and the two settings that change the role most: the public authority that procures and the multinational under many legal regimes. Participants leave with a role map, a tier policy, an article-to-control mapping, a one-page board report and a testable tender requirement.

Chapter 16 · 75 minutes

The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams

The lesson places the security architect among the CISO, the risk function and internal audit, the enterprise architect, the AI architect, platform and product teams and the roles the usage modes have created. Participants learn the seam rule, the four seams with the AI architect, the three placements of an architect, how Conway's law turns organisational seams into security seams, and the four rules of a RACI kept as code. They draw a role map from real decisions.

Learning objectives

Explain the division of labour between the CISO and the security architect as the difference between appetite and design.
Assign a proposer, a ceiling-holder and an operator to each of the four seams between the security architect and the AI architect.
Compare the enabling, embedded and platform placements by what each makes easy and hard.
Draft a role map with exactly one accountable role per cross-role decision.

Key concepts

Seam: A point where the work of two roles meets and a decision can fall between them. For each seam, one role proposes, one holds the ceiling and one operates, and a file in version control says which.
Rights over ceilings: Whoever knows the AI system best proposes; whoever knows the attacker's reach best holds the ceiling, because the ceiling must not depend on the model behaving. The security architect's rights at the seams are over ceilings, not over content.
Enabling hub: The book's default placement: an enabling team reporting to the CISO, with an architect embedded only where risk justifies it, keeping the hub reporting line and rotating after a fixed term, and a standing seat in the platform team's design reviews.
New neighbours: Roles the usage modes created: the AI system owner, the agent operator who may revoke a Mode 5 agent's credentials, the skills curator and the evaluation engineer. The architect's own agents appear on the map as tools, never as roles.
RACI rules: One accountable role per decision; a veto is not an accountability and is recorded separately; independent functions are never responsible for building; agents are never accountable. Stopping needs no approval, whereas restarting needs the system owner.

Interactive exercises

Sort: Proposes or holds the ceiling
Match: Neighbours on the role map

Done on the lesson page, with feedback at once.

Discussion

The architect recommends an exception but does not grant one. What goes wrong in organisations where the same person designs the boundary and accepts the residual risk?
The test of placement is whether the architect hears of a boundary problem from the team before an incident reveals it. How would your current placement fare on that test?
Nordvik holds boundaries through contracts, Hansa through the platform. Which seams in your organisation are held by neither, and who was surprised the last time one failed?

Exercise · 30 minutes

Draw the role map from real decisions

Collect six boundary-changing decisions from the last twelve months in your organisation, preferring slow or contested ones. For each, record who proposed, who decided, who did the work and who was surprised; the surprised column marks the seams. Cluster the decisions by seam. For each seam name the role that proposes, the role that holds the ceiling, the role that operates and exactly one accountable role, recording any veto separately with its scope. Add the stop decision: who may stop without asking, and who must approve a restart. Then test the map against two further decisions and note any it cannot route as a gap.

Deliverable: A role map in the form of Hansa's decision-rights file, with one accountable role per decision, separate vetoes, stop activation and release, and a list of gaps.

Self-test

At the seam on guardrail content and boundaries, what does the security architect hold?
1. The content of the guardrails: what they check, how they are evaluated and which thresholds they must meet
2. The ceiling: egress, workspace isolation, and the rule that no guardrail is the only control
3. The operation of the guardrails in the delivery pipeline
4. The evaluation thresholds that gate each release
What happens when the security architect and the AI architect disagree at a seam, according to the book's own conclusion?
1. The AI architect's position stands until the design authority meets, because the proposal depends on how models behave
2. The matter is put to a vote among the roles on the map
3. The platform team decides, because it operates the control
4. The more restrictive position stands until the named tier decides, and the default lapses after 30 days
Why does the chapter prefer a standing seat in the platform team's design reviews to making the architect a member of the platform team?
1. It keeps designer and builder apart, avoiding self-review
2. Platform teams are not permitted to employ architects under DORA
3. The enabling hub would otherwise lose its budget
4. Members of platform teams cannot hold a veto over the control catalogue

Chapter 17 · 90 minutes

Design Authority, Decision Forums and Gates Instead of Meetings

The lesson shows how the architect delegates routine decisions without losing accountability for them. Participants learn why forums fail, what a gate does that a meeting does badly, the tier policy as data with its three design rules, the properties of a working gate, the design authority, exceptions as expiring records, and the five rules that answer when an AI may change the architecture. They classify decisions into tiers and write an expiring exception.

Learning objectives

Explain the three ways forums fail and the three things a gate does that a meeting does badly.
Classify decision classes into the four tiers, with a decider, evidence, a time limit and a maximum autonomy level for an AI proposer.
Write an exception as an expiring record with a tested compensating control and renewal requirements.
Apply the delegation test and shadow running to redesign a review board as a design authority with gates.

Key concepts

Tier policy as data: A list of decision classes in version control, each with a tier, a decider, required evidence, a time limit and an owner, read by gates and forums. A class qualifies for tier 1 only if a machine can check its evidence.
Direction decides the ceiling: A class that loosens a boundary is never delegated as far as one that tightens it. For AI proposers, tightening or restoring changes may reach Level 3 Bounded behind an external gate; loosening changes stay at Level 2 Supervised or below.
Working gate: A gate whose rule is versioned and tested, whose rule is not owned by the author of the change it gates, whose bypass is possible, visible and reviewed, and which is itself reviewed for staleness. The override rate measures its health.
Design authority: The tier 2 forum for exceptions, deviations, precedent and contested items. It works asynchronously first on pull requests, has a written mandate and a quorum by role, and an objection from the security architect escalates to the next tier and is not outvoted.
Expiring exception: A record of a decision to live with a control gap for a stated time, with an owner, a tested compensating control and an expiry enforced by a gate. Renewal is a new decision that requires new evidence, not an extension.

Interactive exercises

Sort: Which tier decides
Scenario: An agent proposes to widen an allow-list

Done on the lesson page, with feedback at once.

Discussion

The chapter says a design authority that approves every pull request in seconds is a gate with a delay. How would you tell the difference in your own forum?
Gates that cannot be bypassed will be bypassed unseen. What would a break-glass path need to record in your pipeline for you to trust it?
Hansa measures and delegates; Nordvik designs a route and writes down who answers at the end of it. What does a tier policy offer an organisation with no standing board?

Exercise · 35 minutes

Tier ten decisions and write an exception

Take ten security architecture decisions from the last two quarters of your review board or equivalent, recording each item's class, wait and outcome. Apply the delegation test: a class moves to a gate only if it recurs, is reversible or low in blast radius, can be decided from machine-checkable evidence, and has a policy and an owner, with a stricter test for loosening classes. Assign each class a tier from 1 to 4, a decider, a time limit and the maximum autonomy level for an AI that proposes a change in that class. Then write one exception from your own estate as an expiring record with control, scope, reason, risk, owner, compensating control and its test, approver and tier, expiry and what renewal requires.

Deliverable: A tier policy table for the classes found, in the form of Hansa's policy, and one exception record in the form of EXC-NR-0007.

Self-test

Before a class of decisions is delegated from the board to a gate, what does the chapter's practical guide require of shadow running?
1. Two weeks in which the gate records no failures or overrides of any kind
2. One full quarter in which the board approves every item of the class unchanged and no exception is open against it
3. Gate and board agree on at least 95 per cent of at least 20 decisions, every disagreement explained
4. A sample of five per cent of the gate's decisions re-derived by internal audit
In Hansa's tier policy, at what maximum level may an AI propose a change to the tier policy itself or to a stop path?
1. Level 0 Advisory: an agent must never change the rule that governs it or the path that stops it
2. Level 1 Assisted, with the draft labelled as AI-generated
3. Level 2 Supervised, with each change approved by the head of security architecture and recorded at tier 3
4. Level 3 Bounded, where the change tightens the policy
What does the chapter say about renewing an exception?
1. It is extended automatically for the same period while the compensating control keeps passing its test
2. It may be extended once by the control owner without a new decision
3. It is granted by the gate when the expiry date is reached
4. It is a new decision that requires new evidence; a renewal attaching nothing new is declined

Chapter 18 · 90 minutes

Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability

The lesson reads the AI Act, NIS 2, DORA and the Cyber Resilience Act as engineering constraints, article by article. Participants learn the four reading rules, the articles that carry most of the architect's work in each instrument, the three lines along which accountability is distributed, the method for turning an article into a control, and how overlapping reporting clocks are met by one incident pipeline. They map an article to a control with a test. Everything is framed as architectural implication, not legal advice.

Learning objectives

Apply the four reading rules, addressee, verb, date and limit, to an article of a European instrument.
Identify, for each of the four instruments, the articles the chapter treats and the architectural implication of each.
Distinguish the accountability of the management body, the control owner and the architect's professional responsibility.
Convert one article into a catalogue control with a property, a test, evidence and a recorded reading.

Key concepts

Four reading rules: Read the addressee, the verb, the date and the limit. Approve, oversee or be trained describe a person's act; ensure, keep, implement or notify describe a property that architecture can provide and a test can check. Whether a reading is legally right belongs to counsel.
Under its control: The architectural hinge of AI Act Article 26: a deployer cannot keep for at least six months logs that a supplier writes only to its own environment, so the requirement belongs in the contract and the data flow.
Professional responsibility: What the architect answers for, as defined in the role charter: the soundness of the design advised, the faithfulness of the mapping from article to control, the honesty of the evidence classification and the escalation of a risk the architect cannot accept.
Property statement: The form in which an article becomes engineering: X holds for Y, checked every Z. If no test can fail, it is not yet an engineering statement. If the verb is approve or oversee, the output is an information requirement, not a control.
One incident pipeline: The design answer to overlapping reporting clocks: one awareness timestamp, one classification step that evaluates every regime and one evidence record from which each report is assembled.

Interactive exercises

Sort: Which instrument asks for it
Put in order: From article to control

Done on the lesson page, with feedback at once.

Discussion

Reporting a declared control as verified is the one failure the architect cannot allow. What pressures in your organisation push towards that failure, and what protects against it?
The chapter says a control owned by a team alias is a failed control, whatever its test says. How many of your controls would survive that rule?
Hansa records for each entry whether an obligation is law or group policy. Why does that distinction matter in entities where the instruments do not apply by law?

Exercise · 35 minutes

Turn an article into a control

Choose one article the chapter treats that applies to your organisation, for example NIS 2 Article 23(4) on the early warning, AI Act Article 26(6) on logs under the deployer's control, or DORA Article 28(3) on the register of information. Follow the six steps. Identify the addressee and the verb. State the property in the form X holds for Y, checked every Z. Search your catalogue for an existing control and reuse it if one fits. Write a test that fails when the property is false and say when it runs. Name the evidence and its keeper and classify the control as verified, declared or failed. Record the reading with a reviewer other than yourself, review triggers and a review date.

Deliverable: One mapping entry in the form of Hansa's regulatory mapping, with article, property, control, test, cadence and status, plus a short record of the reading and its reviewer.

Self-test

In the chapter's example for NIS 2 Article 23(4)(a), what does the quarterly test assert?
1. That the final report is submitted within one month of the notification
2. That the management body has approved the incident process
3. That the supplier notifies the entity within 12 hours of awareness
4. That a synthetic incident replay produces an early-warning draft in under four hours
Why is the claims-triage agent recorded as not high-risk in Hansa's mapping?
1. Because it acts only at Level 2 Supervised with a person approving each route
2. Because Annex III, point 5(c), concerns risk assessment and pricing for life and health insurance, not claims routing
3. Because the Digital Omnibus moved all insurance systems out of Annex III
4. Because it works through the Polish service centre for four national entities, which places it outside the scope of the AI Act
What does CRA Article 12 mean for supplier evidence, as the chapter reads it?
1. A supplier's software bill of materials replaces the deployer's own duty to keep logs under AI Act Article 26(6)
2. A CRA declaration of conformity from the supplier relieves the management body of its approval and oversight duties under NIS 2 Article 20
3. A high-risk AI system meeting the CRA's essential requirements is deemed, as far as its declaration shows, to meet AI Act Article 15
4. A product with a support period of at least five years is exempt from the reporting clocks of CRA Article 14

Chapter 19 · 75 minutes

Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers

The lesson shows how one security architecture is communicated to five audiences without five versions of it. Participants learn the three rules of generated views, what boards, supervisors, auditors, engineers and suppliers each ask and in what form they are answered, the five indicators the architect reports and what is deliberately left out, and how AI's part in the work is disclosed through a provenance block. They write a one-page report for a management body and a gate message.

Learning objectives

Match each of the five audiences to the question it asks, the form of the view and its cadence.
Write a one-page architecture report that asks a management body for at most three decisions and states what it does not know.
Define the five indicators and explain why the architect leaves out activity counts and summed scores.
Compose a gate message with rule identifier, observed fact, reason and way forward.

Key concepts

One source, many projections: Every figure and diagram in a view carries the commit of the model, catalogue and evidence manifest it came from; a view that cannot name its sources is a draft. Views generated from the same commits cannot disagree.
Decisions, not information: A report asking for no decision is a briefing. The board page asks for at most three decisions, each with its cost, reversibility and what it affects, in risk language, and shows movement instead of state.
Standing pack: The supervisor view: a set of queries over the catalogue and evidence manifest that exists before anyone asks, opening with failed and declared controls, their owners and closure dates, and giving one answer for all supervisors.
Five indicators: Patch velocity, containment test results, recoverability, control status and review quality. Each describes a property someone can change, has an owner and a threshold, and is computed from evidence without opinion.
Provenance block: A disclosure produced by the generator, not typed, stating which sections an AI drafted, which agent or tool in which usage mode under which mandate manifest, what the verifier did and who verified. Disclosure does not share blame.

Interactive exercises

Match: Five audiences, five forms
Scenario: A briefing that could be all green

Done on the lesson page, with feedback at once.

Discussion

A page that is green only because the red is unmeasured is called the commonest cause of a bad surprise. What is unmeasured in your current reporting, and how would you say so on one page?
The chapter warns that a patch-velocity target can be met by reclassifying services as not internet-facing. Which of your indicators could be improved by changing the report instead of the estate?
Independence is preserved by access, not distance. What would your auditors need in order to draw their own sample and re-perform a test without your help?

Exercise · 30 minutes

A one-page report for the management body

Write a one-page architecture report for your management body, or for Nordvik Region's regional executive committee using the figures in the chapter. Fix the template: decisions asked for, the five indicators with thresholds and owners, control status in three counts of verified, declared and failed, changes since the last page and a provenance block. Select at most three decisions, each with the consequence of not deciding, the cost, reversibility and what it affects, in risk language. Write a five-sentence narrative last. State what the page does not know, naming declared evidence and unmeasured areas. Add one line disclosing any part an AI drafted and who verified it.

Deliverable: A one-page management report with indicators, three decisions, a statement of what is not known and a provenance line, in the form of the chapter's board page.

Self-test

How many decisions should the board page ask for, and why?
1. At most three, because a board that receives seven requests decides none
2. Exactly five, one for each indicator the architect reports
3. None, because the page is a briefing and decisions belong to the CISO
4. As many as there are failed controls, so that none is hidden
Where an AI agent collects the evidence, what does the auditor do according to the chapter?
1. Repeats the agent's collection by hand for every control in the catalogue
2. Relies on the agent's own account of what it collected and when
3. Tests the agent: its links against the source system, its mandate against what it did
4. Asks the architect to choose which of the agent's records should be shown
At what level is the review-quality indicator reported?
1. By named reviewer, so that weak reviewers can be coached
2. At team level only, agreed in advance with employee representatives
3. By entity and reviewer, for the supervisor's standing pack
4. It is not reported, because it could monitor individuals

Chapter 20 · 90 minutes

Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes

The lesson covers the two settings that change the role most. In a public authority the architect procures far more than builds, so boundaries run through testable requirements, contracts as controls, rehearsed exit plans and what the authority holds on its own side. In a multinational the architect keeps one baseline with market overlays that may tighten but never relax it. Participants also learn digital sovereignty as four verifiable properties and how vendor AI in Mode 0 is contracted. They write a testable tender requirement.

Learning objectives

Explain the three moves by which a procuring architect holds a boundary in a system a supplier builds and runs.
Write a testable security requirement with identifier, result, level, verification at three moments, consequence and catalogue link.
Translate digital sovereignty into four properties, each with a check and evidence.
Review a market overlay for any value weaker than the baseline.

Key concepts

Testable requirement: A requirement with an identifier, the result required in functional terms, a level of mandatory or weighted, a verification naming method, evidence and frequency at evaluation, acceptance and operation, a consequence of failure and a link to its catalogue control.
Contracts as controls: A contract clause is a control only when it has an owner, produces evidence and is tested, so each clause family, such as stop path, logs and access, change notice, audit rights, incident notification and exit, is a catalogue entry with the supplier as evidence source.
Rehearsed exit: An exit plan that says what leaves, in what formats and how fast, what keeps the function running, and who has tried. For a procured system the realistic exit is often the process without the AI, so the plan includes a test of it.
Sovereignty as verifiable properties: Knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails. Each becomes a check with evidence, such as region pinning, key custody, an exit test record and a failover drill.
Tightening-only overlay: A market overlay on a pinned baseline that records regime, placement, timing and mappings to existing controls. A pipeline check fails when any overlay value is weaker than the baseline: shorter retention, fewer recipients, a later deadline or a control removed.

Interactive exercises

Match: Contracts as controls
Scenario: A local rule that asks for less

Done on the lesson page, with feedback at once.

Discussion

A requirement tested only at tender protects the authority only on the day of signature. Which requirements in your current contracts are verified in operation, and which only at award?
The chapter says the architect makes the facts of ownership, operation and key custody visible and leaves the legal reach of third-country law to counsel. Why is that division of work the right one?
Where a local rule appears to require less than the group baseline, the overlay may not relax silently. What are the two alternatives the chapter offers, and when would you choose each?

Exercise · 35 minutes

Write testable tender requirements and an exit test

Take a procurement your organisation is planning, or Nordvik Region's renewal of the benefits-triage contract. Write two security requirements following the chapter's guide. Start from a catalogue control and name the obligation or threat it serves. State the result in functional terms with a number where one exists, never naming a product only one supplier offers. Set the level as mandatory or weighted. Name the verification with method, evidence and frequency at acceptance and in operation, and who owns it. State the consequence of failure. Then describe one exit test: what is switched off or moved, for how long, what is measured and who takes part. Finally say how you would dry-run each test against the incumbent system before publication.

Deliverable: Two requirement entries in the form of SR-01 and SR-02 with verification and consequence, and a half-page exit test description with its measures.

Self-test

By default, how many mandatory requirements does the chapter's guide allow per tender, and what happens to the rest?
1. No more than five, and the rest are dropped
2. No more than twelve, with the rest weighted under the award criteria
3. No limit, as long as each has a verification
4. No more than twenty, with the rest moved to the contract schedule
Why does Nordvik's requirement SR-02 set log retention at twelve months when AI Act Article 26(6) sets a floor of six?
1. Because NIS 2 Article 23 requires twelve months for significant incidents
2. Because the supplier's log store cannot delete earlier
3. Because the Region's archives law forbids shorter retention for all records
4. Because appeals can arrive later than the six-month floor
What makes the pipeline check fail when a market overlay is added to Hansa's catalogue?
1. Any overlay value weaker than the baseline, or a protected control missing
2. Any overlay that adds recipients or tightens a deadline
3. Any mapping owned by a local security officer and not by the group
4. Any regime in which the AI Act applies as group policy and not as law

Module 5 · Part V · Competence and Career

Part V asks what a person must be able to do to hold the transformed role, how anyone can tell, and whether the role has a future. Three lessons cover a competence framework kept as code with six domains and four levels evidenced with and without AI, learning paths, certification, hiring and upskilling, and a horizon register with four scenarios for 2036. Participants leave with an assessment plan, an interview exercise that tests judgement in two conditions and a register of signals for the role.

Chapter 21 · 75 minutes

Competences of the Transformed Security Architect: A Framework

The lesson presents a competence framework for the transformed security architect, kept as code: six domains, four levels from Foundation to Expert each defined unaided and with AI, and the evidence that demonstrates each competence. Participants learn the rule of the lower level, the five kinds of evidence and the limits of certificates, the mapping to ECSF, SFIA 9 and NICE with its local extensions, the competence record as personal data, and how the record conditions decision rights and agent autonomy. They plan an assessment by practical demonstration.

Learning objectives

Name the six domains of the framework and give one competence from each with the shift it most concerns.
Apply the rule that a person's level is the lower of the unaided and the AI-assisted demonstrated level.
Rank the kinds of evidence of competence and explain why certificates are never sufficient for Advanced or Expert.
Plan an assessment by practical demonstration with an unassisted scenario, a seeded review and a rationale interview.

Key concepts

Six domains: Design, code, AI, adversary, law and people, following the structure of the role in Parts II to IV. Design is the core; the AI domain exists because of Shift 4, which also changes how every domain is evidenced.
Rule of the lower level: Each level is defined twice, unaided and with AI the person verifies, and a person's level is the lower of the two demonstrated. An architect with excellent AI-assisted output who cannot produce a sound threat model unaided is Practitioner in that competence.
Unassisted demonstration: Work done without AI in a time-boxed exercise. It shows what the person can do when the assistant is wrong or stopped, and is the only evidence that answers the question of judgement directly.
Local extensions: Competences the mapping records as not covered by ENISA's Cybersecurity Architect profile, published in 2022: AI-02 on containment and identity for Mode 5 agents, AI-03 on autonomy levels and Level 3 playbooks, and ADV-02 on machine-speed defence.
Competence condition: A link from the record to decisions: each consequential decision right names the competences it requires and escalates when the record does not show them, and an autonomy ceiling in a mandate manifest depends on the supervising architects' evidenced level in AI-03.

Interactive exercises

Sort: Which level does this describe
Put in order: Assessment by practical demonstration

Done on the lesson page, with feedback at once.

Discussion

The rule of the lower level can lower the recorded level of an architect whose repository looks excellent. How would you introduce the rule so that it is accepted as fair?
Expert is earned on designs that held under test, not on years in post. What would that change in how your organisation grades its senior architects?
A nightly check reads levels, never record content. Why does the chapter separate the record, the evidence and the working notes so strictly?

Exercise · 30 minutes

Plan an assessment by practical demonstration

Plan the yearly assessment of one security architect in your organisation, or of Nordvik Region's single post-holder. Select at most six competences from the framework: those due, those on which a decision right depends, and those the person wants to raise. Design a three-hour unassisted scenario on a sanitised or synthetic estate. Design an AI-assisted review of an AI-drafted artefact with three to five seeded errors, at least one a fluent omission, described as design flaws. Write four questions for the rationale interview. Name the lead assessor and the second assessor and say how levels are decided. Finally draft the record schema: purposes, what it is not used for, readers and validity.

Deliverable: A two-page assessment plan with scope, unassisted scenario, seeded review, interview questions, assessors and a competence record schema in the form of CMP-NR-01.

Self-test

An architect's AI-assisted threat models are excellent, but the architect cannot produce a sound threat model unaided. What level does the framework record in DES-02?
1. Advanced, because the repository shows the output that counts
2. The average of the two demonstrated levels
3. The lower of the two demonstrated levels, here the unaided one
4. No level until a certificate confirms the knowledge
How does the framework treat certificates such as CISSP-ISSAP as evidence?
1. As supporting evidence at Foundation and Practitioner, never sufficient for Advanced or Expert
2. As sufficient evidence at every level, provided the certificate was renewed within the two-year validity of evidence
3. As a precondition for holding any decision right in the charter
4. As irrelevant, because they evidence neither knowledge nor judgement
What happens to the evidence collector's Level 3 ceiling in MND-HM-01 if fewer than two architects hold AI-03 at Advanced?
1. The agent is retired until the next annual assessment
2. The ceiling falls back to Level 2 Supervised
3. The ceiling is unchanged, but internal audit is informed
4. The architects face a disciplinary review

Chapter 22 · 75 minutes

Learning Paths, Certification, Hiring and Upskilling

The lesson turns the competence framework into learning paths, hiring profiles and the choice between upskilling and hiring. Participants learn the four starting points and what each lacks, the four principles of a learning path, what certifications validate and what they do not, AI literacy for the architect as testable objectives, why interview exercises run unassisted and assisted, and what an organisation can do about the entry route. They design an interview exercise that tests judgement.

Learning objectives

Compare the four starting points for the role by what each is strong in, what to add first and the failure to watch.
Design a learning path on the four principles, with levels gated by demonstration and the first draft by the learner.
Explain what a certification validates and why a named certificate should not be a precondition in an advertisement.
Design an interview exercise with seeded flaws that runs in an unassisted and an assisted condition.

Key concepts

Four starting points: Security engineer, enterprise architect, developer and auditor. Each brings part of the framework and lacks another, so every path begins with an individual gap assessment against the six domains, not with a course catalogue.
Four principles of a learning path: Practice on real artefacts, fast feedback that the path manufactures, levels gated by demonstration instead of course completion, and protected unassisted practice under the rule: first draft by the learner, then the assistant.
Certification as a floor: A certification validates knowledge on the day of an examination, a real and inexpensive signal, but not one of judgement on the organisation's estate. Practical demonstration is the gate for levels in the competence record.
Two-condition exercise: An interview exercise run unassisted, showing what the candidate can design, and assisted, showing what the candidate can verify. The difference between the two scores is information about judgement.
Cooling-off period: A recorded interval before a person assures a system they helped to build, because an architect who designs a boundary and then assures it marks their own work. The chapter takes twelve months as a sensible default.

Interactive exercises

Match: Four starting points and what to watch
Scenario: Upskill, hire or contract

Done on the lesson page, with feedback at once.

Discussion

The chapter argues that an examination's power to separate doers from recallers weakens as assistants improve, and labels that its own conclusion. What follows for how you read a candidate's credentials?
Nordvik upskills its post-holder with an external mentor and builds a deputy; Hansa hires from outside for one post. Which questions in the upskilling-or-hiring table decided each case?
A contracted architect who leaves nothing behind adds dependence. What three conditions does the chapter set for such engagements, and how would you check them?

Exercise · 30 minutes

Design an interview exercise that tests judgement

Following the chapter's guide, design an interview exercise for a security architect post in your organisation. Choose one decision from the role charter, for example the boundary of a Mode 5 agent acting on a core system. Write a short scenario for a fictional organisation so that no confidential configuration is disclosed. List five to eight seeded flaws of different kinds, structural, authority, evidential, scope and reversibility, described as design mistakes, plus one decoy that is unusual but sound. Write scoring criteria that reward finding each flaw, explaining its consequence and proposing a remedy. Set the two conditions, their timings and order, and state the data policy for candidates' answers.

Deliverable: An exercise specification with scenario outline, restricted flaw catalogue, decoy, scoring criteria, the two sittings with timings and a candidate-data policy.

Self-test

What is the chapter's rule for the use of an assistant during learning tasks?
1. The assistant drafts and the learner corrects, to save the mentor's time
2. No assistant is used at any point in the twelve months
3. The learner may use any tool as long as the artefact passes review
4. First draft by the learner, then the assistant, used as reviewer or tutor
In Hansa's hiring profile HP-HM-2027-01, how are applications screened?
1. By an AI ranking of candidates, reviewed by the hiring lead
2. By human review against the required levels, with no AI ranking of candidates
3. By years of experience and a named architecture certificate, as a floor for external candidates
4. By tool names matched against the platform's technology list
Which starting point does the chapter say is usually strong in law and evidence, and must add design and code first?
1. The auditor, who brings independence
2. The security engineer
3. The developer, who brings code
4. The enterprise architect, who brings design

Chapter 23 · 60 minutes

The Future of the Role: Will There Be a Security Architect in 2036?

The lesson asks whether there will be a security architect in 2036 and answers with a horizon register for the role. Participants learn why a profession should not forecast its own future unaided, which trends the chapter labels observable, expected and speculation, the four scenarios with their leading signals and what each would lose, the seven no-regret measures, and how the author's own judgement is kept apart and labelled. They build a register with computed signals for their own role.

Learning objectives

Classify trends affecting the role as observable, expected or speculation and state what each label justifies.
Describe the four scenarios for 2036 with the leading signal of each and what would be lost.
Define computable signals with thresholds and owners for at least one scenario.
Explain why the seven no-regret measures hold whichever scenario arrives.

Key concepts

Horizon register for a role: A file beside the role charter in which every trend carries a label, its sources, the artefacts it affects and the decision it supports. It is kept by the role's holders but approved by the CISO, because holders have an interest in a particular answer.
Commitment, preparation, reversibility: What the three labels justify: observable trends are documented now and justify commitment; expected trends rest on a stated trend or decided instrument with uncertain timing and justify preparation; speculative trends justify keeping decisions reversible.
Four scenarios: Absorbed into platform engineering, a governance role, commander of agent teams, and the role disappears. They are speculation by construction; the most likely future is a mixture whose proportions differ by organisation.
Signal: A measure that can be computed, has an owner and has a threshold, preferably a ratio computed from repositories and team-level records. The share of architecture changes at each autonomy level is the clearest signal of which scenario is arriving.
No-regret measures: Seven measures that hold across all four scenarios: keep the craft, express boundaries as code with named owners, write decision rights down, register the role's own delegations, evidence competence with and without AI, protect the entry route, and keep the stop path outside what it stops.

Interactive exercises

Sort: Observable, expected or speculation
Match: Four scenarios and their leading signals

Done on the lesson page, with feedback at once.

Discussion

The chapter calls the disappearance of the role the least likely and the most dangerous scenario, because it would come as a sequence of sensible delegations. Which delegations in your organisation could no longer be taken back?
Nordvik's leading signal is the share of tender requirements the post-holder wrote and can verify unaided. What would be the equivalent signal for your own role?
Why does Hansa's register give the signal for loosening changes merged at Level 3 a threshold of one?

Exercise · 20 minutes

Keep a horizon register for your role

Write the first version of a horizon register for the security architect role in your organisation. Enter five trends from the chapter, each with a label of observable, expected or speculation, its source or a statement that it is your organisation's own judgement, the artefacts it affects, such as the role charter, competence records, hiring profiles or tier policy, and the decision it supports. Choose the scenario you consider nearest and name at most three signals for it, each computed from repositories or team-level records, with a current value if known, a threshold and an owner. List the seven no-regret measures with their status. Name the owner, the approver and the review date before the budget and hiring plan are set.

Deliverable: A register excerpt in the form of HZN-HM-SA-01 with five labelled trends, up to three signals with thresholds and owners, and the status of the seven no-regret measures.

Self-test

How does the chapter label the trend that agents become reliable enough to verify architecture proposals without a competent human reviewer?
1. Observable, on the near-universal adoption reported by the 2025 DORA research
2. Speculation: no evidence was found, and evaluators favouring their own output argue against it
3. Expected, because the length of tasks that models complete keeps doubling
4. Expected, once the high-risk regime of the AI Act applies to Annex III systems on 2 December 2027
In the scenario where the architect becomes a commander of agent teams, what does the chapter say would be lost?
1. The view across the seams between platforms, suppliers and countries
2. The person who can answer for the boundary to a supervisor
3. The separation of those who design from those who assure
4. The route by which commanders and verifiers are made
Who keeps and who approves the horizon register for the role, and why?
1. HR keeps it and the works council approves it, because it concerns people
2. Internal audit keeps it and the management body approves it, because the register is an independent assurance document
3. The role's holders keep it and the CISO approves it, because holders alone would drift towards reassurance
4. The platform team keeps it and the architect approves it, because signals come from repositories

Module 6 · Part VI · Experience and Conclusions

Part VI turns from the craft to the experience of practising it. Four lessons cover three cases and five anti-patterns with a diagnostic, one year in the role at Nordvik Region and Hansa Mutual with what went wrong as well as what worked, the answers each organisation gave and its 24-month plan, and the book's conclusions with their firmness and a first-90-days plan. Participants leave with a diagnosed practice, a year review with a went-wrong field, a funded plan in which autonomy rises last, and their own first steps.

Chapter 24 · 90 minutes

Case Studies and Anti-Patterns

The lesson collects what recurs when a security architecture practice changes: two illustrative composite cases, one observable case built from public agent incidents, and five anti-patterns, each described by the shift it violates, its symptom, cause, remedy and test. Participants learn the three questions an architect asks of an agent incident, the five properties the successful cases share, and a twelve-question diagnostic answered from records. They diagnose a practice and write an anti-pattern record.

Learning objectives

Describe the five anti-patterns by the shift each violates, its symptom and the test that shows the remedy works.
Apply the three questions on boundary dependence, leakage and the stop decision to an agent incident.
Diagnose a security architecture practice with the twelve questions, answering from records and marking each red or green.
Draft an anti-pattern record with symptom, cause, remedy, verification test and owner.

Key concepts

Anti-pattern: Not a mistake but a solution that looks reasonable, is adopted repeatedly and produces the same bad outcome each time. The chapter describes each by five fields kept as code: the shift violated, the symptom, the cause, the remedy and the test.
The five anti-patterns: The architect as bottleneck, the diagram nobody runs, the AI that approved itself, the control catalogue nobody maps, and the sign-off in seconds. The first fails Shift 2 and with it Shift 3, the second and fourth Shift 1, the third and fifth Shift 4.
Three questions for an agent incident: Does the boundary depend on the agent doing what it was asked? Does it leak through a service the agent can reach? Does the alert reach the person who holds the stop decision, with the authority and means to use it?
Sampling as the control on delegation: The lesson of the review-board case: the gate rule is the architect's product and a wrong rule is wrong at scale, so a regular sample of gate decisions is what finds a rule that drifted from its intent.
Structural and behavioural forms: Two ways an AI team approves itself. In the structural form the permissions allow an agent to approve or to write to what it is checked against. In the behavioural form the rules hold, but the architect has become a signature on unchecked work.

Interactive exercises

Match: Each anti-pattern and its remedy
Scenario: A freeze that is only an instruction

Done on the lesson page, with feedback at once.

Discussion

The chapter says asking people to be more careful is not a remedy for the sign-off in seconds. Why not, and what does it offer instead?
Both composite cases kept a single point of failure in the architect. How would you treat the architect's own capacity as a constraint in your organisation?
Both Nordvik and Hansa found that most remedies existed before the diagnosis. What did the diagnosis add, and why does that matter?

Exercise · 35 minutes

Diagnose your practice for anti-patterns

Run the chapter's diagnostic on your own security architecture practice for the last two quarters. Answer the twelve questions from records, never from memory, and mark each red when it meets the chapter's condition or cannot be answered: for example a median wait for routine classes above five working days, no pipeline check that reads the architecture model, any agent with write access to what it reviews, any catalogue entry without an owner, a mapping and a test, or no seeding of errors. Name an independent reader who would re-derive three answers. Then write an anti-pattern record for one red answer with the shift violated, the observed symptom, the cause, the remedy with its decision records, the verification test with a pass condition, an owner other than the person assessed and a review date.

Deliverable: A completed twelve-row diagnostic table with red and green marks and sources, and one anti-pattern record in the form of AP-HM-SIS-01.

Self-test

In the composite case of the review board that became a design authority, how was the faulty gate for new network paths discovered?
1. A supervisor requested the gate's decision log under NIS 2
2. The design authority reviewed every gate decision at its weekly session
3. An agent flagged its own approval of a path into a reclassified zone
4. A monthly sample of 10 per cent of gate decisions found it
What test does the chapter give for the remedy of the anti-pattern 'the AI that approved itself'?
1. A drill in which an agent identity tries to approve its own proposal on a protected path is refused and alerts a stop holder
2. A quarterly survey in which every reviewer confirms in writing that they read each agent proposal before approving it
3. A seeded-error detection rate of at least 80 per cent over a quarter, with a tier 2 median of two minutes
4. A deliberate off-model change in a test environment that is caught within a single run of the pipeline
Which diagnostic answer marks the sign-off in seconds as red for agent proposals at tier 2 and above?
1. A median wait of more than five working days for routine classes, or any change blocked during the architect's absence
2. An oldest unresolved drift finding more than 90 days old
3. A median approval time under 60 seconds, or a rejection rate under 2 per cent over 100 proposals
4. Fewer than half of routine decisions taken at a gate

Chapter 25 · 75 minutes

A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual

The lesson follows two security architecture practices through one year, from autumn 2026 to autumn 2027, in the order things happened and with the friction, mistakes and decision records of each turn. Participants see the four shifts as a sequence, learn what went wrong at Nordvik Region and Hansa Mutual and which designed mechanism caught each failure, how the architects' week changed, and how to review a year against the shifts. They write a year timeline with a went-wrong field.

Learning objectives

Trace the order in which the four shifts appeared in each organisation's year and explain why the order of artefacts mattered.
Identify, for at least four failures in the year, the mechanism that caught it and the decision record that answered it.
Compare how the architects' working week changed at Nordvik Region and Hansa Mutual between October 2026 and October 2027.
Review a year in the role as a timeline with decisions, failures, shifts and year-end claims classified as verified, declared or failed.

Key concepts

The shifts as a sequence: Shift 1 came first because the charter, catalogue and tier policy in the repository were what every later step read; Shift 2 followed through contracts and gates; Shift 3 became real when stop paths were timed and failed; Shift 4 took the form of a deferral or of review tiers and caps.
went_wrong field: The entry in the year's timeline for every failed drill, expired exception, missed seed and gate decision reversed by sampling, linked to the decision that answered it or marked open. It is what makes the timeline evidence that the practice learns.
Wrong at scale: Hansa's July failure: a tier 1 gate restored a UK logging setting to the group baseline although it had been changed under an approved exception, because the gate did not read the exception register. No agent was involved; the post-merge sample found it.
The later instrument governs: How Nordvik settled the conflict between its manifest, which allowed edits at Level 2 Supervised, and its charter, which capped the architect's own AI at Level 1 Assisted: the stricter, later charter governed until the manifest was aligned as version 3.0.0.
Human binding constraint: The year-end finding in both organisations: the limit was one person's availability at Nordvik and six people's review capacity at Hansa, where reviewing AI-drafted proposals became the largest use of the team's time.

Interactive exercises

Put in order: Nordvik Region's year
Sort: What caught each failure

Done on the lesson page, with feedback at once.

Discussion

Both first stop drills failed, and the chapter calls this what a drill exists to produce. How would such a result be received by your management body, and how would you present it?
During the architect's leave at Nordvik a model update was held for three weeks because only the architect's charter named one check. What does the fix in AIDR-0542 keep, and what does it change?
At Hansa consultation, not engineering, set the agent team's pace. Is that a cost or a control, and why?

Exercise · 30 minutes

Review your year against the four shifts

Write the timeline of your security architecture practice for the last four quarters, following the chapter's practical guide. For each quarter list the decision records produced; a turn that left no record is itself a finding. Add a went-wrong entry for every failed drill, expired exception, missed seeded error and gate decision reversed by sampling, and link each to the decision that answered it or mark it open. Place each entry against one or more of the four shifts, using their exact names. Classify each year-end claim as verified, declared or failed. List what is open at year end. Keep the plan for next year out of the timeline: it is a separate artefact.

Deliverable: A four-quarter timeline in the form of NR-SA-2026-2027 with decisions, went-wrong entries, shifts, measured values and a list of what is open at year end.

Self-test

Why did Nordvik's first out-of-hours stop drill of the benefits-triage integration route take 26 minutes against a budget of 15?
1. The canary alert reached a duty analyst who did not hold the decision, and tokens outlived the revocation
2. The managed security service provider held the runbook but not the credentials
3. Only two caseworkers remembered how to triage without the ranking
4. TriageSoft had not accepted the stop-path requirement in the annex
What did Hansa do when agent review volume rose by about 40 per cent after consultation and the Tier 2 queue lengthened?
1. It moved Tier 2 proposals to Tier 1 so that one reviewer sufficed
2. It let the critique agent approve proposals on low-risk paths
3. It lowered the proposal cap and recorded the decision to slow the agents as AIDR-0593
4. It raised the review agents to Level 3 Bounded for reversible policy changes so that fewer proposals needed a person
What caught the tier 1 gate that wrongly restored a UK logging setting to the group baseline at Hansa?
1. The post-merge sample, six days later
2. The policy-author agent's own report of the change
3. The UK supervisor's request for the evidence pack
4. The quarterly seeded-error drill

Chapter 26 · 75 minutes

Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

The lesson sets out what Nordvik Region and Hansa Mutual decided, the answer each gave to its governing body, what worked and what was hard, and a 24-month plan for each. Participants learn why the same four shifts produced a contract-first plan in one organisation and a delegation-first plan in the other, how a plan is built against a constraint with autonomy increases written as thresholds, and what remains unresolved. They build a 24-month plan for their own practice.

Learning objectives

Summarise the answer each organisation gave to its commission and the evidence behind what worked and what was hard.
Explain why the two plans differ in order, using the levers, the people and the law each organisation has.
Build a 24-month plan against the binding constraint, with owners, verifications and conditional autonomy increases.
State what the chapter leaves unresolved for each organisation and for accountability in general.

Key concepts

Contract-first and delegation-first: The two plans. Nordvik mostly procures, so its leverage is the contract and its plan starts with the deputy and supplier evidence. Hansa mostly builds, so its leverage is the platform and its plan starts with review quality and patch velocity.
Plan against the constraint: For each shift, name the one constraint that most limits the practice, such as the single post or review throughput, and order measures by the constraint they relieve and then by reversibility: reversible measures early, hard-to-undo commitments late and conditional.
Autonomy as a threshold: Autonomy increases are written as conditions on recorded evidence. The default is none without two consecutive quarters of review-quality evidence. In both plans autonomy rises last and only on recorded conditions.
Verification of a measure: Each measure has an owner by role and a verification that produces evidence, such as a drill time or a share of verified controls, so that the plan can be checked against what happened.
What remains unresolved: The single point of failure at Nordvik, including how the architect is replaced; review throughput at Hansa; the regimes outside the EU; and whether a court would accept the records that show who answers for an agent-proposed change.

Interactive exercises

Sort: Whose plan is it
Scenario: Raising autonomy early

Done on the lesson page, with feedback at once.

Discussion

Nordvik had to build what Hansa already had; Hansa had to remove what Nordvik never built. Which sentence describes your organisation, and what follows for your first six months?
Hansa's cap turns the limit of six reviewers into a queue and not a rubber stamp. What would persuade your executives that a visible queue is the better outcome?
Whether a court would accept the organisations' records as sufficient remains untested. How should that uncertainty shape what you record today?

Exercise · 30 minutes

Build a 24-month plan for your practice

Following the chapter's six steps, draft a 24-month plan for your security architecture practice. List the last year's decisions as done, in progress or reopened. For each of the four shifts name the one constraint that most limits the practice, and choose the binding one. Write four to six measures ordered by the constraint they relieve and then by reversibility, each with a period, an owner by role and a verification that produces evidence, such as a drill time, a share of verified controls or a review-quality figure at team level. Write any autonomy increase as a threshold with its conditions and exclusions. Name at most three decisions for the commissioning body and the triggers on which the plan is revised.

Deliverable: A plan in the form of PLAN-NR-SA-2027 with constraint, four to six measures with owner and verification, conditional autonomy, up to three decisions and revision triggers.

Self-test

Under what condition does Nordvik's plan reopen the question of an agent team in months 18 to 24?
1. When the supplier TriageSoft offers a hosted review-agent service
2. When the verified share of tracked controls reaches 60 per cent
3. When two people with evidenced competence can supervise agents
4. When the regional executive committee funds a second architect post
What figures did Hansa's first quarterly report show for review quality after the redesign of AIDR-0556?
1. A Tier 2 median of 28 seconds, a rejection rate of 1 per cent and no seeding
2. A Tier 2 median of 11 minutes, a rejection rate near zero and 80 per cent of seeded errors caught
3. A Tier 2 median of four working days and 57 of 61 items agreed with the board
4. A Tier 2 median of 22 minutes, a rejection rate of 17 per cent and 86 per cent of seeded errors caught
According to the chapter, why does Nordvik upskill its post-holder instead of hiring a second security architect?
1. Because ENISA's profile forbids external hiring for public authorities
2. Because fixed pay scales and security vetting make hiring slow
3. Because the union refused to agree the assessment rules
4. Because the platform team already holds Advanced in design and law

Chapter 27 · 75 minutes

Conclusions: The Transformed Security Architect

The lesson tests the book's thesis and draws its conclusions. Participants learn the three qualifications of the thesis, the seven cross-cutting conclusions with how firm each is and what would change it, how the conclusions reinforce and pull against one another, which open questions the book answers, what to do first, next and later, and how a new architect takes up the role in the first 90 days. The author's own judgement is presented as a labelled projection. They write their own first-90-days plan.

Learning objectives

State the thesis and the three places where the concluding chapter qualifies it.
Explain the seven cross-cutting conclusions and classify each as observable or expected, with what would change it.
Sequence the actions the chapter recommends first, next and later, and justify the order.
Draft a first-90-days plan for taking up a transformed security architect role.

Key concepts

Three qualifications of the thesis: The scarce resource is also the capacity to exercise judgement at the volume the estate produces; the transformation is uneven across the four shifts; and it is not guaranteed, because the role could disappear through a sequence of reasonable delegations.
Seven cross-cutting conclusions: The boundary is the product, not the review; decision rights are written before the pressure; time is a design property and the drill its evidence; verification, not drafting, is the constraint; the craft is kept deliberately; accountability ends in a person; evidence replaces attestation.
Tensions held by written rules: Speed pulls against verification, delegation against the craft, and evidence against co-determination. Each tension is held by a written rule that a person reviews, such as the highest tier for irreversible changes or team-level reporting of review metrics.
First, next, later: The sequence follows the order the year found to matter: written authority before delegation, boundaries before speed, measurement before autonomy. It runs over the first six months, six to eighteen months and eighteen to thirty-six months.
Calibration before approval: A new architect joins the approver pool on evidence of a seeded-error calibration, by default 20 proposals with a catch rate at or above 0.85, not on a date, and until day 90 does not approve at the highest tier.

Interactive exercises

Put in order: The first 90 days in the role
Match: What would change each conclusion

Done on the lesson page, with feedback at once.

Discussion

The author projects that Shift 4 is the hardest because it fails quietly. Do you agree, and what in your own practice would reveal such a failure?
The firmest conclusions concern boundaries, time and law; the least firm concern what AI will do to the architect's judgement. How should that difference shape where you commit and where you keep decisions reversible?
The chapter says what remains of the role is smaller in volume and larger in consequence. What does that imply for how the role should be graded, staffed and deputised?

Exercise · 30 minutes

Write a first-90-days plan

Write a plan for the first 90 days of a security architect taking up a transformed role, for yourself or for a new colleague, following the chapter's practical guide. For the first week, list the decision rights in the charter with time limits and overrides, or note that a charter must be drafted. For days 1 to 30, plan a boundary map of the post's boundaries from the architecture model with peer review and findings for untested boundaries. For days 31 to 60, plan one unaided threat model compared with an AI draft and a seeded-error calibration. For days 61 to 90, plan first approvals and one timed stop drill. State the ceiling on own AI use, the protected unassisted practice and what may not be done before day 90.

Deliverable: A plan in the form of PLAN-HM-SA-PL-90 with three phases, deliverables and verifications, an own-AI ceiling, protected practice and a not-before-day-90 list.

Self-test

Which of the seven cross-cutting conclusions does Table 27.1 label as expected and not yet observable?
1. Verification, not drafting, is the constraint
2. Time is a design property, and the drill is its evidence
3. The boundary is the product, not the review
4. The chain of accountability ends in a person
What does the chapter recommend doing in the first six months?
1. Raise an agent's autonomy on conditions recorded in advance, and bring every legal regime into the catalogue as an overlay
2. Write the role charter, put own AI use under a mandate manifest, start the control catalogue and time one stop path
3. Delegate the review board's routine classes to gates and open competence records
4. Keep a delegation register with yearly reversibility tests and mentor a junior
How does the concluding chapter leave question Q12, whether there will be a security architect in 2036?
1. Answered: the role will be absorbed into platform engineering
2. Answered: the role will exist as a governance role only
3. Partly answered, pending the first court ruling on agent-authored change
4. Open by nature, with the author's judgement given only as a labelled projection