Book Blueprint and Chapter Briefs

This blueprint records the editorial intent of AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities, Book 8 of The Architecture as Code Series. It is the brief every chapter is written against. The chapter briefs below are generated from scripts/outline_data.py by python3 scripts/generate_outlines.py; edit the data file, not the generated section. The conclusions of the earlier volumes that each chapter builds on are recorded in SERIES_FOUNDATIONS.md (F1 to F91) together with the open questions the book takes up (Q1 to Q12).

Premise

The first seven volumes of the series made architecture, governance, the AI platform and cyber defence executable, examined whether the AI threat is real, described what has happened to the security architect and asked what happens when AI takes the manager's chair. AI Red Team put AI to work in cyber defence, Function by Function of NIST CSF 2.0, under a written mandate, at an autonomy level matched to reversibility. It described what AI can do for detection, investigation and response. It left one thing to a later volume: the team that does the defending.

That team is changing now. Alerts are enriched, correlated, summarised and in places closed by AI before an analyst opens them. Managed detection services embed their own AI that acts on behalf of the client. Adversaries use AI to shorten the time from disclosure to exploitation and to scale social engineering. The security operations centre (SOC) was built around a queue and a pyramid of tiers that assumed human triage at volume; both assumptions are under strain. At the same time the people in the team are asked to supervise agents, to engineer detections as code, to command incidents with machine-speed tools and to keep skills that the tools make less necessary every day. Europe has set the frame: NIS 2, DORA, the Cyber Resilience Act, the GDPR and the AI Act place duties on named people and management bodies, set reporting clocks and limit the monitoring of employees.

This book asks what the blue team becomes, for European enterprises and public authorities. It answers through what the team did before (Part I), how each of its five functions is transformed (Part II), the team's own AI and how to verify and protect it (Part III), the team in the organisation: operating models, roles, decision rights, regulation and measurement (Part IV), the people who do the work and how they are made (Part V), and what two organisations experienced and what follows (Part VI).

Thesis

The working thesis has five parts, tested in Parts II to V and judged in Chapters 24 and 28.

The blue team is transformed, not abolished. What remains scarce is accountable human judgement under uncertainty: the ability to verify what AI concludes, to decide on containment and to answer for it.
The work moves from the queue to the loop. Handling alerts gives way to engineering detections, playbooks and agent mandates as code; every alert is evidence of a detection not yet engineered and every incident ends in a verified improvement.
Autonomy is matched to reversibility, and the stop path lies outside the system it stops. AI may act inside a written mandate; Level 4 Autonomous is never used for an irreversible containment action or for an action that decides about a named person's access to work.
The defenders' AI is part of the defended estate. The SOC reads text that adversaries can write; its agents are privileged insiders and its platform a tier-0 asset.
The route by which analysts are made, and their wellbeing, are design questions. If AI does the junior work, the craft must be kept and renewed on purpose, and people who work at machine speed and on call must be managed with the care AI Boss describes.

The thesis would be shown wrong by evidence that fully autonomous detection and response, without a human who can verify and stop it, performs better over years than a team with those properties, or that AI-handled triage leaves the capacity to investigate novel intrusions intact without people who practise the craft.

Audience

Chief information security officers and heads of security operations; SOC managers, shift leads, analysts, detection engineers, intelligence analysts, hunters and incident commanders; security architects and AI architects; boards and management bodies with duties under NIS 2 Article 20 and DORA Article 5; procurement and vendor managers who buy managed detection and response; works councils, unions and employee representatives; data protection officers; internal audit; and public-sector leaders. Chapter 1 gives reading paths.

Boundaries

Not a second AI Red Team. AI Red Team maps AI capabilities onto the CSF Functions. This book takes that map as given and describes the team: roles, craft, decision rights, operating models, careers and daily experience. It refers to AI Red Team for the technical design of detection engineering, the AI-assisted SOC and incident management and does not repeat it.
Not a second The Transformed Security Architect. That book treats one role and its AI team. This book treats the team of defenders and borrows its artefacts (role charter, mandate manifest, competence record) and its method for verifying AI proposals.
Not a second AI Boss. Analysts are managed by metrics like other workers; Chapter 21 applies AI Boss to the SOC and does not repeat it.
Defensive only. Adversary behaviour is described by technique, at the level needed to design detections, tests and decisions; no exploit code, payloads, jailbreak or injection strings and no step-by-step intrusion instructions. Code examples are detections, playbooks, mandates, policies and records.
Blue team, not red or purple. The red team appears as the source of findings; its tradecraft is not described.
Legal content is attributed to the instrument and article and framed as architectural implication, not legal advice.

Red threads

The five blue team functions. B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond, B5 Learn; every chapter in Parts II to V names, in its opening and Summary, the functions it concerns.
Usage modes and degrees of delegation. Every narrative chapter has an ### Across the usage modes or ### Across the degrees of delegation subsection.
The loop. From telemetry to detection, case, response and learning, as records.
Stop paths and reversibility. Every chapter that concerns B4 Respond says what can be undone and who can stop it.
Observable, expected, speculation. Every outlook carries one label; the author's projections stay in Chapters 24 and 28.
Two organisations. Nordvik Region and Hansa Mutual in every narrative chapter.

Status

The repository was bootstrapped on 2026-11-10 from the engine of AI Boss, and the first full draft followed. The table of contents, the series foundations, the blue team profile of the two organisations, the chapter briefs and the bibliography exist; all 28 chapters are drafted. Parts II and III were written first, because the later parts rest on them; the glossary and Appendix A were compiled from the finished chapters. Open points are in HANDOVER.md.

Length and weighting

Narrative chapters run 3,600 to 5,500 words; Chapters 7, 10, 13 and 19 may run to 6,500 words. A chapter that grows beyond about 6,500 words, or a section beyond about 2,500 words that treats a distinct subject, is split into a companion chapter, recorded here.

Chapter briefs

Part I: The Blue Team in Question

Chapter 1: Introduction: The Blue Team Transformed

File: 01_introduction.md
Status: draft
Purpose: Introduce the book on its own terms. In 2026 the blue team's queue is read, enriched, triaged and in places acted on by AI, while its adversaries use AI to move faster, so the question is no longer whether AI will enter the security operations centre but what the team becomes when it has. State the question the earlier volumes did not ask directly: AI Red Team mapped what AI can do for cyber defence, Function by Function, and The Transformed Security Architect described one role; this book describes the team that does the defending. State the working thesis (the blue team is transformed, not abolished; the work moves from the queue to the loop; autonomy is matched to reversibility with a stop path outside the system it stops; the defenders' AI is part of the defended estate; the route by which analysts are made and their wellbeing are design questions), name the five blue team functions and the degrees of delegation, say what would show the thesis wrong, and explain why the question is a European organisational question in 2026 under NIS 2, DORA, the Cyber Resilience Act, the GDPR and the AI Act.
Builds on: F48, F49, F50, F71, F72, F70, F81, F5, Q1, Q12
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: A night in two security operations centres; The blue team in 2026; The question the series had not asked of a team; The working thesis; Five functions and five degrees; Why Europe, and why now; Rules of the book; Two organisations; How to read this book
Practical guides: A first inventory of the AI that already takes part in a team's work, including vendor AI in managed services that acts at an autonomy nobody decided
Worked examples: The CISO's commission at Nordvik Region recorded as AIDR-0700 and the Hansa Mutual executive board's request recorded as AIDR-0750, both written as decision records with reviewers and a report date
Nordvik Region and Hansa Mutual: Nordvik's CISO is commissioned in autumn 2026 to say what the Region's six analysts, a managed provider and a procured SIEM become when AI enters (AIDR-0700); Hansa Mutual's executive board asks the group CISO what a 24/7 SOC across two sites and seven regimes looks like when an investigation agent already acts on two reversible actions (AIDR-0750). Both follow the July 2026 incident and their AI threat assessments.
Usage modes and degrees of delegation: The chapter introduces the usage modes as the series uses them and the distinction between AI that assists an analyst with the analyst's identity (Modes 1 to 3), AI built or procured to perform a blue team function (Mode 4) and agents that act with identities of their own (Mode 5).
Observable, expected, speculation: AI in SOC tooling and AI-enabled attackers are observable; machine-speed adversaries as the normal case are expected; the end of the SOC as a function is speculation, treated in Chapter 24. The thesis is the book's own claim, tested in Parts II to V and judged in Chapters 24 and 28.
Figure: The blue team at the centre of the book: the five functions around the loop from telemetry to learning, the degrees of delegation as rings, and the chapters that treat each function

Chapter 2: What the Blue Team Does: Five Functions, Tiers and the Alert Queue

File: 02_what_the_blue_team_does.md
Status: draft
Purpose: Describe the blue team before the transformation, as the frame for everything later: what its five functions are, how a SOC is organised in tiers around a queue, which tools carry the work (SIEM, EDR, SOAR, ticketing, threat-intelligence platforms), who the neighbours are (IT operations, the CISO, the privacy officer, the business) and how the work is measured today. Define B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn, map them to the CSF 2.0 Functions and to the roles in a typical team, and separate what is craft from what is routine. This is the baseline against which Chapters 5 to 11 describe change.
Builds on: F5, F6, F48, F49, F60, F7, Q7
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: What defenders do; Five blue team functions; Tiers, shifts and the queue; Tools and data; Neighbours and handovers; How the work is measured; Craft and routine
Practical guides: Mapping a team's work: who performs each function today, with which tools, and which parts already sit in automation
Worked examples: A function map as code, team/function-map.yaml, for Nordvik Region's security unit and Hansa Mutual's group SOC
Nordvik Region and Hansa Mutual: Nordvik's security unit of 14 has six analysts working office hours, a managed provider out of hours (framework agreement NR-2025-044), supplier-default detections and no detection engineering; B2 Detect is largely the supplier's. Hansa's group SOC runs 24/7 from Hamburg and the Polish service centre with a UK late shift, beside a threat-intelligence cell, a detection-engineering team and an incident-response team, so every function has an owner.
Usage modes and degrees of delegation: The chapter shows where Mode 0 features already sit in SIEM and EDR products and which functions each deployed AI capability touches, as the baseline for the delegation profiles of Chapter 4.
Observable, expected, speculation: The structure of the team and its measures today is observable; the claim that the five functions are the right unit for delegation is the book's own and is tested in Chapters 4 and 18.
Figure: The five blue team functions as a loop from telemetry to learning, annotated with the tier, the tools and the neighbours that touch each function

Chapter 3: The Pressure on the Blue Team: Machine-Speed Adversaries, Alert Volume and Scarce Talent

File: 03_the_pressure_on_the_blue_team.md
Status: draft
Purpose: Describe the pressure that makes the transformation unavoidable rather than optional: adversaries that use AI to shorten the time from disclosure to exploitation, to scale social engineering and to automate parts of intrusion; telemetry volumes and alert counts that exceed human capacity; and a market in which skilled analysts are scarce. Summarise the evidence of AI Platform and Security, Chapter 18, AI Red Team, Chapter 2, and AI Threat, Chapter 18, from the standpoint of the team, and add what the team experiences: the collapse of the exploitation window, the arrival of AI-orchestrated campaigns and the effect on alert load. State what the evidence does and does not show, and label each outlook observable, expected or speculation.
Builds on: F35, F36, F29, F67, F46, F66, Q7, Q9
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: A team at the edge of its capacity; Adversaries with AI; The collapsing exploitation window; Telemetry and the alert queue; Scarce talent and strained people; What the pressure does not justify; Observable, expected, speculation
Practical guides: Writing the team's pressure register: the three or four pressures that matter locally, with their evidence and their review date
Worked examples: A pressure register team/pressure-register.yaml with each entry labelled observable, expected or speculation, for Hansa Mutual's group SOC
Nordvik Region and Hansa Mutual: Nordvik's pressures are capacity and procurement: six analysts, a provider that closes alerts with its own AI, and public-sector pay scales. Hansa's are scale and attack surface: seven regimes, agents of its own in production, and a SOC that must keep a night shift staffed in two countries.
Usage modes and degrees of delegation: Pressure differs by mode: an attacker's Mode 5 agent acts at machine speed; the defender's Modes 1 to 3 tools speed up the analyst but keep human speed in the decision.
Observable, expected, speculation: AI-assisted exploitation and phishing are observable; machine-speed adversaries as the normal case are expected (AI Platform and Security, Chapter 18); fully autonomous campaigns at scale against European targets are speculation.
Figure: The pressures on the team: attacker speed, alert volume and scarce talent, set against the capacity of a tiered SOC

Chapter 4: The Transformed Blue Team Defined: Mandate, Functions and Degrees of Delegation

File: 04_the_transformed_blue_team_defined.md
Status: draft
Purpose: Define the transformed blue team: its mandate, its five functions, the degrees of delegation per function and the accountability that does not move. Put the contributions of AI Red Team (usage modes, autonomy levels, the Level 2 to Level 3 line, mandate and rules of engagement) and The Transformed Security Architect (role as artefact, mandate manifest, boundaries that hold whatever anyone intends) to work for a team: a team charter, a delegation profile per function and action class, and a delegation register that shows the sum of what has been delegated. State where Level 4 is never used, who answers for what, and how the charter is reviewed.
Builds on: F50, F51, F73, F74, F75, F69, F81, F82, F45, Q1, Q2
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: A team is an artefact; Mandate and decision rights; Degrees of delegation per function; Where Level 4 is never used; The delegation register; Accountability that does not move; Reviewing the charter
Practical guides: Writing a team charter and a first delegation profile in one working session
Worked examples: team/charter.yaml and a delegation profile DLG-HM-SOC-01 with levels for B1 to B5, ceilings per action class and review triggers, for Hansa Mutual; the lighter DLG-NR-SEC-01 for Nordvik Region, including what is delegated to the managed provider
Nordvik Region and Hansa Mutual: Nordvik's charter must describe a hybrid team in which the provider's detections and its AI are part of the function; its delegation profile therefore includes contractual levels for what the provider's AI may do. Hansa's charter governs its own agents, with HM-SEC-001 at Level 2 and Level 3 for two reversible actions, and a stop path that does not run inside the SOC platform.
Usage modes and degrees of delegation: The chapter defines the delegation profile as the pair of mode and level per capability and per function: the mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.
Observable, expected, speculation: The charter and register are the book's own design and are tested in Parts II and III; the claim that the register's sum matters is carried over from AI Threat, Chapter 26.
Figure: The transformed blue team defined: mandate, five functions, delegation profile per function, and the accountability that stays with named people

Part II: The Craft

Chapter 5: Anticipate: Threat Intelligence and Exposure at Machine Speed

File: 05_anticipate.md
Status: draft
Purpose: Describe B1 Anticipate as transformed: threat intelligence, exposure awareness and hypothesis generation, where AI reads reports, extracts indicators and techniques, correlates them with the estate and drafts candidate hypotheses, and where the analyst's job becomes deciding which of them matter. Cover intelligence as code (STIX and TAXII pipelines), the exposure feeds (EPSS, KEV, EUVD) and their combination with local asset context, the risk of hostile or poisoned sources, and the quality tests for AI-extracted intelligence. Connect to patch velocity as a measured service level and to the horizon register.
Builds on: F1, F36, F29, F54, F55, F48, Q4
Blue team functions: B1 Anticipate; B2 Detect
Sections: From report to hypothesis; Intelligence as code; Exposure at machine speed; What AI does well and badly; Verifying extracted intelligence; Hostile sources; The sharing duty
Practical guides: Setting up a weekly intelligence-to-detection routine with a named reviewer and a measured conversion rate
Worked examples: An intelligence record INTEL-HM-0142 converted into hypothesis HNT-HM-0031 and detection requirement DET-HM-0455, with the reviewer, the grounding check and the review date
Nordvik Region and Hansa Mutual: Nordvik has no intelligence analyst; it consumes the national CSIRT's reporting and the regional-government sharing group's, and an exposure prioritiser at Level 0 Advisory (NR-SEC-003). Hansa's three-person intelligence cell uses a drafting assistant at Level 1 and feeds the detection-engineering team directly.
Usage modes and degrees of delegation: Mode 1 and 2 assistants summarise reports; a Mode 4 pipeline extracts and maps at Level 1 Assisted; a Mode 5 agent that changes detection content is not used for intelligence in this book's recommendations.
Observable, expected, speculation: AI extraction of intelligence is observable; automated conversion of intelligence into deployed detections at Level 3 is expected for narrow classes; autonomous attribution is speculation.
Figure: From report to hypothesis to detection requirement, with the human decision points and the verification step marked

Chapter 6: Detect: Detection Engineering as Code

File: 06_detection_engineering_as_code.md
Status: draft
Purpose: Describe B2 Detect as transformed: the move from supplier-default rules and hand-tuned alerts to detection engineering as code, where each detection is a versioned record with logic, data sources, ATT&CK mapping, test cases, an owner and a review date, and where AI drafts candidate detections from reports and incidents under review. Cover Sigma and similar formats, testing detections against replayed and simulated telemetry, detection debt and coverage maps, and the discipline that a detection is not accepted until a test shows it fires and a measure shows its cost in false positives.
Builds on: F1, F4, F7, F41, F43, F48, F59, F60, F62, Q7
Blue team functions: B2 Detect
Sections: From rules to records; Detection pipelines; AI as drafter; Testing; Coverage and cost; Vendor-supplied detections; Detection debt
Practical guides: Taking a supplier-default rule into the repository: record, test, owner, review date and an alert budget
Worked examples: Detection record DET-HM-0455 in YAML with logic reference, test cases, ATT&CK mapping and review date; the first DET-NR-0001 that Nordvik Region takes over from a supplier default
Nordvik Region and Hansa Mutual: Nordvik's step is to create its first detection-engineering practice by taking ownership of the rules that matter and requiring annex rights in the provider contract; Hansa's four detection engineers manage detections as code and ask whether the drafting assistant HM-SEC-002 raises quality or only volume.
Usage modes and degrees of delegation: Mode 4 drafting assistants sit at Level 1 Assisted; vendor Mode 0 content cannot be tested by the team unless the contract grants it; no agent merges a detection into production at Level 3 without a passing test and a named approver.
Observable, expected, speculation: AI-drafted detections are observable in practice; automatic deployment of drafted detections for narrow classes is expected; self-tuning detection estates without review are speculation.
Figure: A detection record's path from requirement to draft, test, review, rollout and review date, with the test gate marked

Chapter 7: Triage Transformed: From Alert Queue to Verified Case

File: 07_triage_transformed.md
Status: draft
Purpose: Describe triage as transformed: the work that defined tier 1, deciding whether an alert is real and how bad it is, is now increasingly done by AI that enriches, correlates, summarises and in places closes alerts. State the central question honestly: what is lost and what is gained when a machine closes the alert, who is accountable for a missed intrusion, and how triage quality is shown. Cover the verified case, the closure policy by class, sampling and seeded incidents, and the vendor-embedded triage of managed services. Stage a constructive debate on whether AI should be allowed to close alerts.
Builds on: F21, F51, F52, F57, F66, F76, F84, Q2, Q4, Q7
Blue team functions: B2 Detect; B3 Investigate
Sections: The alert as a claim; What AI does in triage; The closure policy; Measuring triage quality; The verified case; Managed triage; The debate; What the analyst does now
Constructive debate: Concern: AI that closes alerts removes the learning ground of analysts, hides intrusions behind a plausible summary, and moves accountability to a tool; escape rates are measured on known cases while the dangerous ones are the unknown. Calm: Human triage is already shallow and inconsistent at current volumes; AI closes the repetitive classes faster and more consistently, and frees people for the cases that need them; sampling measures escape. Where they meet: Both accept that closure must be by class, that escape rate must be measured against seeded and retrospective cases, and that someone named owns each class. What can be done: Close by class with a named owner, sample and seed, keep a share of triage unassisted for skill, and stop delegation when the measure fails.
Practical guides: Writing a closure policy for three alert classes, with sampling and a stop condition
Worked examples: Closure policy triage/closure-policy.yaml and a case record CASE-NR-0231 for a phishing report that the provider's AI closed and an analyst reopened on sampling
Nordvik Region and Hansa Mutual: Nordvik's triage assistant NR-SEC-001 runs at Level 1 Assisted on self-hosted capacity because alerts contain personal and health data (AIDR-0301), while the provider's out-of-hours AI closes alerts under terms Nordvik cannot yet audit. Hansa's HM-SEC-001 closes defined low-risk classes at Level 3 Bounded with 5 per cent sampling and a named class owner.
Usage modes and degrees of delegation: Mode 0 triage inside products acts without a decision; Mode 4 triage services sit at Level 1 or Level 2; Mode 5 agents may close defined classes at Level 3 under a codified playbook; Level 4 is not used for closure of any class that can hide an intrusion in progress.
Observable, expected, speculation: AI closure of low-risk classes is observable; extending it to medium-risk classes is expected where sampling shows low escape rates; unsupervised closure of all alerts is speculation.
Figure: The alert-to-case path with closure classes, the evidence needed to close, sampling and the point where a person decides

Chapter 8: Investigate: Hypotheses, Timelines and Evidence with AI

File: 08_investigation_and_forensics.md
Status: draft
Purpose: Describe B3 Investigate as transformed: scoping, timeline reconstruction, log and endpoint analysis and forensics, where AI queries data lakes, assembles timelines, proposes hypotheses and drafts the case narrative, and where the investigator's work becomes steering, challenging and verifying. Cover the hazards: evidence that the adversary can write, fluent but ungrounded narratives, loss of chain of custody, and the privacy and proportionality duties when investigating people's activity. Show how evidence is preserved, how reasoning is recorded, and how an investigation is reproducible without the AI.
Builds on: F40, F54, F46, F76, F67, F68, F20, Q4, Q8
Blue team functions: B3 Investigate
Sections: The investigation loop; Timelines and queries; Forensics and chain of custody; Hostile content in evidence; Reproducibility; Investigating people; Writing for others
Practical guides: A review checklist for an AI-assisted investigation: five checks before a case is closed
Worked examples: Case record CASE-HM-1207 with the evidence manifest, the queries run, the AI-drafted timeline and the analyst's corrections
Nordvik Region and Hansa Mutual: At Nordvik the investigator is an analyst with a Mode 1 assistant and the provider's forensic retainer; sensitive social-care data limits what may be sent to external models. Hansa's investigation agent works across seven regimes, so its data access carries per-market overlays and its output is reviewed by a named analyst in the market concerned.
Usage modes and degrees of delegation: Modes 1 to 3 assist with the investigator's identity; a Mode 5 investigation agent has read-only identities and permission manifests that set a ceiling; Level 3 applies to evidence collection from defined sources, never to altering evidence.
Observable, expected, speculation: AI-assisted timeline assembly is observable; reproducible agentic investigation with machine-checked reasoning is expected; autonomous investigation of complex intrusions end to end is speculation.
Figure: The investigation loop with the AI's contribution marked, the evidence manifest and the verification step

Chapter 9: Threat Hunting Transformed: Hypotheses, Data and Agents

File: 09_threat_hunting_transformed.md
Status: draft
Purpose: Describe threat hunting as transformed: the hypothesis-driven search for intruders that detections missed, now with AI that proposes hypotheses, writes and runs queries, and clusters anomalies, and where the hunter's judgement is deciding which hypotheses are worth the data. Cover hunt records, the conversion of hunt findings into detections, and the discipline that a hunt that finds nothing still produces a coverage statement. Address the risks: generated queries that are costly or wrong, over-trust in anomaly rankings, and hunts that drift from the threat to the data.
Builds on: F1, F43, F44, F48, F59, F60, F76, Q4, Q7
Blue team functions: B1 Anticipate; B2 Detect
Sections: Hypothesis-driven hunting; Agents as hunting assistants; The hunt record; From finding to detection; Null results; Cost and safety; The hunter's craft
Practical guides: Running a four-week hunt cycle with a hunt record, a coverage statement and a conversion target
Worked examples: Hunt record HNT-HM-0031 for a stolen service-account credential at the Polish service centre, with its conversion to DET-HM-0455
Nordvik Region and Hansa Mutual: Nordvik hunts at most twice a year with the provider's help and uses the hunt as a test of the provider's detections; Hansa's hunters work a standing cadence aligned to intelligence and the quarterly purple exercise.
Usage modes and degrees of delegation: Hunting assistants in Modes 1 to 3 draft queries; Mode 5 hunting agents with read-only identities run approved query packs at Level 2; no hunting agent changes the estate.
Observable, expected, speculation: AI-assisted hunting is observable; continuous agentic hunts with human review of findings are expected; fully automated hunting that replaces hypotheses is speculation.
Figure: A hunt from hypothesis to query, finding, detection and coverage statement

Chapter 10: Respond: Playbooks, Bounded Containment and the Stop Path

File: 10_response_transformed.md
Status: draft
Purpose: Describe B4 Respond as transformed: containment, eradication, recovery coordination, communication and reporting, where the response is increasingly codified as playbooks and parts of it run at machine speed. This is where the series' rule on autonomy bites hardest. Cover the playbook manifest, action classes by reversibility, Level 3 Bounded defined by a codified playbook enforced by a policy decision point outside the model, the stop path, the approval quality metric, break-glass credentials and the incident commander's role. Cover the reporting clocks as design constraints and show a worked containment that was approved, stopped and reversed.
Builds on: F19, F45, F46, F50, F51, F52, F63, F74, F81, Q1, Q6
Blue team functions: B4 Respond
Sections: Response is a decision; Action classes; The playbook manifest; Level 3 in practice; The stop path; Break-glass and the incident commander; Communication and reporting; Recovery handover
Practical guides: Setting the ceiling for a response action: five questions and a default table
Worked examples: Playbook manifest PBK-HM-ISOLATE-01 for host isolation at Level 3 Bounded with corroboration, rate limits, rollback and a two-minute stop target; a reversed containment recorded in INC-HM-2027-0455
Nordvik Region and Hansa Mutual: Nordvik cannot give its provider's AI more than the isolation of an end-user workstation, and its runbook requires a call to the duty analyst for anything touching a citizen-facing service. Hansa lets HM-SEC-001 isolate a workstation and revoke a session at Level 3 Bounded and keeps account disablement for executives and production hosts at Level 2.
Usage modes and degrees of delegation: The chapter sets the default ceilings: Modes 1 and 2 recommend; Mode 5 agents act at Level 3 on reversible actions inside a playbook; irreversible containment and actions deciding about a named person's access to work stay at Level 2 or below.
Observable, expected, speculation: Level 3 containment of reversible actions is observable in vendor and in-house tools; extending it to broader action classes with strong corroboration is expected; unsupervised autonomous response across a production estate is speculation.
Figure: A containment from trigger through corroboration, policy decision, action and rollback, with the stop path outside the loop

Chapter 11: Learn: Post-Incident Review, Purple Teaming and Detection Debt

File: 11_the_learning_loop.md
Status: draft
Purpose: Describe B5 Learn as transformed: the post-incident review, the purple loop and the maintenance of detections, playbooks and mandates, where AI drafts reviews, proposes improvements and tracks closure, and where the blameless, evidence-based discipline of review is at risk of becoming a generated formality. Cover the finding-to-verified-control path of AI Red Team, Chapter 26, the post-incident review record, detection debt, the use of chaos experiments, and the rule that a finding is closed only when a re-test passes. Cover learning across teams and across organisations.
Builds on: F60, F59, F43, F44, F62, F64, F14, Q7
Blue team functions: B5 Learn
Sections: Review as engineering; AI in the review; The finding-to-control path; The purple loop; Detection debt and playbook debt; Learning across boundaries; Measuring learning
Practical guides: Running a blameless review in 90 minutes with an evidence pack and three committed changes
Worked examples: Post-incident review PIR-HM-0455 with findings linked to DET-HM-0455, PBK-HM-ISOLATE-01 and a re-test, closed on the passing re-test
Nordvik Region and Hansa Mutual: Nordvik's reviews are written for the committee and the provider; the learning that matters is changes to the provider contract and to detection ownership. Hansa runs quarterly purple exercises and a finding register in the repository.
Observable, expected, speculation: Continuous verification by chaos experiments and purple exercises is observable at advanced teams; AI-planned experiments are expected; self-improving defences without review are speculation.
Figure: The learning loop from incident or exercise through finding, change, re-test and verified control

Part III: The Blue Team's AI Team

Chapter 12: The Analyst's Own Use of AI: Querying, Drafting and Summarising in Modes 1 to 3

File: 12_the_analysts_own_use_of_ai.md
Status: draft
Purpose: Describe the analyst's own use of AI in Modes 1 to 3: querying, drafting and summarising, and the discipline needed to use assistants safely when the data is sensitive. Cover data classification and routing, what must not leave the organisation, the logging of AI use in casework, prompt hygiene in the sense of data minimisation, the distinction between assistance and delegation, and the policy that makes the analyst's use of AI auditable. Do not repeat the risk analysis of AI Platform and Security, Chapter 16; apply it to the work of the SOC.
Builds on: F12, F15, F25, F39, F57, F75, Q1, Q11
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: A day with an assistant; Classification and routing; What not to paste; Recording use; Assistance versus delegation; Shadow AI in security; Works councils and the analyst
Practical guides: A one-page acceptable-use sheet for analysts, with routing by data class
Worked examples: AI-use policy team/ai-use-policy.yaml with classes, models, log requirements and review date
Nordvik Region and Hansa Mutual: Nordvik's analysts use the approved enterprise assistant and a self-hosted model on reserved capacity for alert data; Hansa routes by classification in a hybrid set-up and agreed the logging of AI use with the Hamburg works council.
Usage modes and degrees of delegation: The chapter's table maps Mode 1, 2 and 3 tools to data classes and to the levels the policy allows for each.
Observable, expected, speculation: Analyst use of assistants is observable; local models good enough for sensitive alert data are expected; none of this removes the need for review.
Figure: An analyst's tools by mode and data class, with the routing and logging that apply

Chapter 13: An AI Agent Team for the SOC: Skills, Mandates and Containment

File: 13_an_ai_agent_team_for_the_soc.md
Status: draft
Purpose: Describe the AI agent team of the SOC: triage, enrichment, investigation, detection-drafting and response agents, each with its own mandate manifest, identity, tools, data and autonomy level, and a human conductor. Reuse the mandate and containment designs of AI Red Team, Chapter 18, and The Transformed Security Architect, Chapter 13, adapted for the SOC. Cover orchestration and the chain of accountability, budgets, the policy decision point, the kill switch and the evidence the team produces for itself. Show how an agent team is introduced step by step and how it is retired.
Builds on: F12, F13, F27, F45, F50, F51, F67, F75, F88, Q1, Q2
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: Agents as a team; Identity and permission; Mandate manifests; Orchestration and accountability; Budgets and brakes; Introducing an agent; Degraded mode; Retiring an agent
Practical guides: Introducing a SOC agent in four steps with exit criteria for each
Worked examples: Mandate manifest MND-HM-SOC-02 for the investigation agent HM-SEC-001: tasks, tools, data, levels per action class, approvals, budget and expiry
Nordvik Region and Hansa Mutual: Nordvik has no agent team; its mandate manifest governs the single triage assistant and the contractual limits on the provider's agents. Hansa's agent team has four agents under the group SOC lead as conductor, and a Mode 5 identity for each.
Usage modes and degrees of delegation: The chapter lays out agent roles by mode and level and states which are Level 3 Bounded and why.
Observable, expected, speculation: SOC agent teams are observable in vendor products and pilots; multi-agent SOC platforms with governed mandates are expected; fully autonomous SOCs are speculation.
Figure: A SOC agent team with its conductor, mandates, identities, policy decision point and independent stop path

Chapter 14: Verifying What the AI Concludes: Review for Soundness When the Analyst Depends on the AI

File: 14_verifying_what_the_ai_concludes.md
Status: draft
Purpose: Describe how an analyst verifies what AI concludes when the analyst depends on the AI to read the data at all. Apply the review-for-soundness approach of The Transformed Security Architect, Chapter 14, and the oversight-quality metric of AI Boss, Chapter 26, to security conclusions: independent reproduction, seeded incidents, a critique agent on a different model family, review that does not start from the AI's answer, and approval quality measured by time to approval, rejection rate and reversals. Cover automation bias, approval fatigue and the design of review that stays real at volume.
Builds on: F21, F52, F53, F66, F76, F84, F68, Q2, Q4, Q9
Blue team functions: B2 Detect; B3 Investigate; B4 Respond
Sections: Dependence; Soundness criteria; Independent reproduction; Seeded incidents; Oversight-quality metrics; Fatigue and volume; The works-council dimension
Practical guides: Starting a seeded-incident programme: five seeds a month, a catch-rate threshold and a stop rule
Worked examples: Review protocol reviews/protocol/soc-tiers.yaml with tiers, seeded-error rates and a cap on open proposals; a quarterly oversight report for Hansa Mutual with caught-seed rate 0.86
Nordvik Region and Hansa Mutual: At Nordvik one lead analyst seeds errors into three of five AI summaries a month; at Hansa the median approval time fell as volume tripled, which triggered the review protocol.
Usage modes and degrees of delegation: Review depth by level: Level 1 and 2 outputs are reviewed individually; Level 3 moves review to the playbook, the sample and the seeded incident.
Observable, expected, speculation: Automation bias is documented; machine-checkable reasoning traces are expected; self-verifying AI that needs no human check is speculation.
Figure: Review for soundness: independent reproduction, seeded incidents and oversight metrics around an AI conclusion

Chapter 15: Defending the Defenders' AI: Poisoned Telemetry, Hostile Tickets and the SOC as Tier 0

File: 15_defending_the_defenders_ai.md
Status: draft
Purpose: Describe the defence of the defenders' AI: the SOC reads text that adversaries can write, in logs, tickets, emails, filenames and threat reports, so its agents are privileged insiders that can be manipulated, and its platform is a tier-0 asset. Apply the architectural lesson of AI Platform and Security (prompt injection is a property of the architecture) and AI Red Team (policy decision point outside the model, permission manifests as ceilings) to the SOC. Cover poisoned telemetry, hostile tickets, detection tampering, the compromise of the agent platform and the supply chain of security AI, and the red-teaming of the SOC's own AI.
Builds on: F39, F40, F45, F54, F56, F57, F62, F67, Q4, Q5
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: The SOC reads the adversary's text; What a manipulated agent can do; Controls outside the model; Tampering with detection; The SOC as tier 0; Supply chain of security AI; Red teaming the SOC's AI
Practical guides: A pre-production checklist for a new SOC AI capability: ten questions on inputs, permissions, stop and exit
Worked examples: Containment profile CP-HM-SOC-01 for the investigation agent with deny-by-default egress, a 5-minute token life and a canary ticket; a finding from a red-team exercise recorded in the finding register
Nordvik Region and Hansa Mutual: Nordvik's exposure is largely contractual: it needs the provider's controls, evidence and an exit plan for the provider's AI. Hansa's agents run in its own platform, so its exposure is architectural and tested by its own red team.
Usage modes and degrees of delegation: The exposure rises with the mode: Mode 0 hides it, Modes 1 to 3 inherit the analyst's access, Mode 5 is a privileged insider with an identity of its own.
Observable, expected, speculation: Indirect prompt injection of security AI is observable in research and early incidents; targeted attacks on SOC agents are expected; mass compromise of SOC platforms through AI is speculation.
Figure: The SOC's AI inside its own attack surface: attacker-writable inputs, the policy point, tier-0 controls and the stop path

Part IV: The Team in the Organisation

Chapter 16: Operating Models: In-House, Managed, Hybrid and Sovereign Security Operations

File: 16_operating_models.md
Status: draft
Purpose: Describe the operating models available to a European organisation: in-house SOC, managed detection and response (MDR), managed security service provider (MSSP), hybrid and sovereign variants, and how AI changes the choice. Cover what is retained when work is outsourced, the Mode 0 blind spot when a provider's AI acts on your behalf, contract terms that make autonomy visible, DORA and NIS 2 third-party requirements, sovereignty and data-location questions, public procurement for authorities, and exit. Compare Nordvik's hybrid model with Hansa's in-house group SOC without declaring either the answer.
Builds on: F30, F47, F57, F22, F10, Q5, Q11
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: Four models; What AI changes; What must be kept; The provider's AI; Regulation and third-party risk; Sovereignty and data location; Procurement; Exit
Practical guides: Writing the annex that makes a provider's AI visible: levels, actions, evidence and notice of change
Worked examples: Contract annex MS-2 to NR-2025-044 with delegated levels for the provider's AI, quarterly sampling, audit rights and a 20-day notice of model change
Nordvik Region and Hansa Mutual: Nordvik keeps detection content, the incident commander role and the case record, and buys 24/7 monitoring; its question is how much the provider's AI may do. Hansa runs in-house on two sites and buys a managed detection service for the UK and Swiss entities where local law matters.
Usage modes and degrees of delegation: The chapter tabulates, by operating model and mode, who decides the level of autonomy and who sees the record.
Observable, expected, speculation: Hybrid models are observable; provider AI that acts at Level 3 across clients is expected; fully autonomous managed SOC at consumer prices is speculation.
Figure: Four operating models with the retained decision rights, the provider's AI and the exit path marked

Chapter 17: Team Design and Roles: After the Tier-1 Pyramid

File: 17_team_design_and_roles.md
Status: draft
Purpose: Describe team design and roles after the tier-1 pyramid: what happens when triage is largely automated and the entry rung of the career ladder shrinks. Cover role charters for the roles that grow (detection engineer, investigation lead, agent operator, incident commander, intelligence analyst, purple team coordinator), the roles that shrink, the shape of the team (pyramid, diamond or flatter), rotas and on-call, the relationship with platform and IT operations, and the division of labour with the security architect. Reuse the role-charter artefact and the competence framework of Book 6.
Builds on: F22, F23, F24, F73, F75, F9, F10, F66, F77, Q3, Q10
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: The pyramid under strain; Roles that grow; New roles; Shapes of the team; Role charters; Rotas and the night; The seams
Practical guides: Drawing the role map for your team in a day and testing it on three recent incidents
Worked examples: Role charter ROLE-HM-SOC-LEAD and ROLE-NR-SEC-DET in YAML with mandate, accountabilities, decision rights, ceilings and review date
Nordvik Region and Hansa Mutual: Nordvik cannot afford a diamond: its first move is to convert one analyst post into a detection-engineering post and to share an agent operator role with the platform team. Hansa shifts four tier-1 posts into detection engineering and investigation lead roles over two years, in consultation with the works council.
Usage modes and degrees of delegation: Role ceilings by level: the incident commander may approve Level 2 actions, the agent operator may revoke credentials, the class owner owns a Level 3 closure class.
Observable, expected, speculation: The shrinking of tier 1 is observable in staffing plans; a diamond-shaped team is expected; teams without any junior analysts are speculation and a risk, treated in Chapter 23.
Figure: From pyramid to diamond: the roles that grow and shrink and the seams to neighbouring teams

Chapter 18: Decision Rights and Escalation: Who May Contain, Isolate and Disclose

File: 18_decision_rights_and_escalation.md
Status: draft
Purpose: Describe decision rights and escalation for the transformed team: who may isolate a production system, disable an account, take a citizen-facing service offline, disclose an incident to a regulator or to affected people, pay or refuse a ransom, and stop an agent. Apply decision tiers, stop decisions named in advance and the right to stop being cheaper than the right to continue. Cover the incident commander's authority, delegation to agents at Level 3, escalation to the management body under NIS 2 Article 20 and DORA Article 5, and the written record of every decision.
Builds on: F17, F18, F19, F63, F74, F51, F81, Q6, Q2
Blue team functions: B3 Investigate; B4 Respond
Sections: Decisions that cannot wait; Decision tiers; Stop decisions; Disclosure decisions; Delegation to agents; The record; Many regimes
Practical guides: A decision-rights table for ten incident decisions, tested in a tabletop
Worked examples: team/decision-rights.yaml for Hansa Mutual with holders, deputies, response times and escalation, and a tabletop result for decision 7
Nordvik Region and Hansa Mutual: Nordvik's provider can page the duty analyst within five minutes but cannot isolate a citizen-facing service; the decision belongs to a named on-call manager. Hansa's group SOC lead can isolate production hosts, and the group CISO decides on regulator notification across the seven regimes.
Usage modes and degrees of delegation: The chapter tabulates decision rights by action class and level: what the agent decides at Level 3, what the incident commander decides at Level 2, and what always goes to a named human.
Observable, expected, speculation: Pre-assigned stop rights are observable at mature teams; decision rights expressed as code and enforced by the platform are expected.
Figure: Decision rights by action class and level: who decides, within what time and with what record

File: 19_regulation_as_constraint.md
Status: draft
Purpose: Describe regulation as a constraint on the blue team's design: NIS 2 (Articles 20, 21 and 23), Commission Implementing Regulation (EU) 2024/2690, DORA (Articles 5 and 17 to 19 and the register of information), the Cyber Resilience Act's reporting duty for actively exploited vulnerabilities, the GDPR (Articles 5, 32, 33 and 34), the AI Act (Articles 3, 14, 26 and 73) and the Cyber Solidarity Act, together with national transposition. Show the reporting clocks as design constraints on logs, case records and decision rights; the duties of the management body; the rules on employee data in security monitoring; and the position of the AI that is part of the SOC. Attribute to articles, frame as architectural implications.
Builds on: F46, F78, F18, F25, F86, Q8, Q6
Blue team functions: B3 Investigate; B4 Respond; B5 Learn
Sections: A map of obligations; The reporting clock; Evidence by design; The management body; Employee data in monitoring; The AI Act and the SOC's AI; National differences
Practical guides: Building the incident clock: a table of deadlines and owners that starts at the moment of awareness
Worked examples: Reporting-clock configuration for Hansa Mutual's incident INC-HM-2027-0455 across NIS 2, DORA and the GDPR, with owners and generated timestamps
Nordvik Region and Hansa Mutual: Nordvik reports to the national CSIRT and competent authority under the national NIS 2 transposition and to the data protection authority; its clocks are shorter than its out-of-hours staffing assumes. Hansa has parallel DORA and GDPR clocks and different regimes for the UK and Swiss entities.
Observable, expected, speculation: The reporting duties are in force or decided; their effect on the design of the SOC is a mix of observable practice and expected consolidation of reporting channels; the Digital Omnibus changes may alter details and are labelled expected until adopted.
Figure: One incident, four reporting clocks: the timeline from awareness to final report with the owners marked

Chapter 20: Measuring the Transformed Blue Team: Speed, Coverage and Quality of Judgement

File: 20_measuring_the_transformed_blue_team.md
Status: draft
Purpose: Describe how to measure the transformed blue team without rewarding the wrong thing. Mean time to detect and respond, closure rate and alert volume reward closing alerts faster; they say little about whether intrusions are caught. Propose measures of speed, coverage and quality of judgement: verified detections, coverage by threat and asset, escape rate on seeded and retrospective cases, oversight-quality metrics, time from finding to verified control, recoverability and the cost per verified case. Cover reporting to the board in one page, benchmarks and their limits, and the rule that measures about people are agreed with employee representatives first.
Builds on: F62, F64, F65, F52, F58, F60, F5, Q7, Q8
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: What the old measures reward; Speed; Coverage; Quality of judgement; Learning; The board page; Measures about people
Practical guides: Replacing a closure-rate target with three measures and a gaming check
Worked examples: reporting/blue-team-page.yaml for Hansa Mutual's board with speed, coverage, judgement and learning measures and the three decisions requested
Nordvik Region and Hansa Mutual: Nordvik's board gets a quarterly page that includes the provider's measures only after Nordvik obtained the data in its annex; Hansa's page reports caught-seed rate 0.86, containment 11 of 12 and finding-to-control median 19 days.
Observable, expected, speculation: The gaming of operational measures is documented in management research; the proposed measures are the book's own and are tested in Chapter 26.
Figure: Measures arranged by speed, coverage, judgement and learning, with the gaming checks marked

Part V: People and Career

Chapter 21: The Analyst at Work: Fatigue, On-Call and Being Managed by Metrics

File: 21_the_analyst_at_work.md
Status: draft
Purpose: Describe the analyst at work: alert fatigue, on-call, the stress of incident work and the experience of working beside agents, and the fact that the analyst is themselves managed by metrics and monitored by the tools they use. Draw on AI Boss (Chapters 11, 13, 14 and 23) for the effects of algorithmic management on autonomy, pace, health and voice, and apply them to the SOC: queue pace, individual scores, the monitoring of analyst activity and co-determination. Stage a constructive debate on whether AI relieves or intensifies the load. Describe by what studies measured, never by adjectives.
Builds on: F86, F89, F90, F66, F52, F26, Q8, Q9
Blue team functions: B3 Investigate; B4 Respond; B5 Learn
Sections: The analyst's day; What studies measured; Beside the agent; Managed by metrics; Co-determination in the SOC; The debate; What leads can do
Constructive debate: Concern: AI at volume moves analysts from doing to reviewing hundreds of machine conclusions an hour, removes the satisfying work, and adds monitoring of the analyst's own behaviour; on-call stress is unchanged. Calm: AI removes the repetitive triage that burned people out, offers a second pair of eyes at night, and gives analysts time for investigation and engineering. Where they meet: Both accept that effects depend on team design, that review volume must be capped, and that measures about people are agreed with representatives first. What can be done: Cap open proposals, rotate reviewers, protect time for engineering, agree the metrics and review the load each quarter.
Practical guides: A fatigue and on-call review every quarter: five questions to ask, and agreed responses
Worked examples: Works agreement clause for SOC tooling: aggregate reporting only, no individual ranking, access log and review date
Nordvik Region and Hansa Mutual: At Nordvik the analysts' union representative negotiated that closure rates are never reported by name; at Hansa the Hamburg works council and the Polish service centre's employee representatives agreed aggregated oversight metrics and a night-shift cap.
Usage modes and degrees of delegation: Pace and visibility differ by mode: Mode 0 hides monitoring inside products; Modes 1 to 3 log what the analyst asks; Mode 5 agents add pace the analyst did not set.
Observable, expected, speculation: Fatigue and attrition in security operations are observable; the effect of AI on load is expected to vary by team design and is not yet well measured; wellbeing as a competitive factor is speculation.
Figure: The analyst's load before and after AI: the queue, the review volume, the night and the monitoring of the analyst

Chapter 22: Competences, Training and Exercises: A Framework for the Transformed Blue Team

File: 22_competences_training_and_exercises.md
Status: draft
Purpose: Define competences for the transformed blue team and how they are built and evidenced: detection engineering, investigation, hunting, incident command, working with agents (mandates, review, containment), data and query skills, legal and regulatory literacy and communication. Reuse the competence-record approach of The Transformed Security Architect, Chapter 21, and map to the European Cybersecurity Skills Framework and SFIA. Cover training, certification, exercises (tabletops, cyber ranges, purple exercises, chaos experiments) as the main means of assessing competence by practical demonstration, and the Article 4 AI literacy duty.
Builds on: F11, F25, F26, F79, F53, F66, F77, Q3
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: A competence framework; Competence records; Exercises as assessment; Agents literacy; Certification and its limits; Hiring and upskilling; Mapping to frameworks
Practical guides: Assessing a team in a half-day exercise and writing the competence records
Worked examples: Competence record CMP-NR-04 for an analyst assessed on a seeded-incident exercise, and a learning path with protected time
Nordvik Region and Hansa Mutual: Nordvik's learning path uses protected time and a neighbouring region's exercise; Hansa runs quarterly purple exercises and a competence framework with 24 identifiers owned by the group.
Observable, expected, speculation: Skills shortages are observable; competence evidenced by exercises is expected to become standard in regulated sectors; AI tutors replacing exercises are speculation.
Figure: Competences by role and level, assessed by exercises, with the records that evidence them

Chapter 23: Keeping the Craft and Making New Analysts: The Apprenticeship Problem

File: 23_keeping_the_craft_and_making_new_analysts.md
Status: draft
Purpose: Describe the apprenticeship problem: if AI does the junior triage through which analysts learned their craft, where do the next experts come from, and how do experts keep their own skill? Apply the evidence of AI Threat, Chapter 14, and the craft-keeping design of The Transformed Security Architect, Chapter 15, to the SOC: unassisted practice, seeded incidents, rotation between engineering and operations, structured shadowing, apprenticeship routes and the policy of keeping a share of cases unassisted. Stage a constructive debate. End with a plan a team can run.
Builds on: F53, F66, F69, F77, F26, Q3, Q9
Blue team functions: B2 Detect; B3 Investigate; B5 Learn
Sections: The ladder and the missing rung; What the evidence shows; Unassisted practice; Apprenticeship routes; The debate; Degraded mode; A plan
Constructive debate: Concern: If AI takes the junior work, no one will learn to see what machines miss, and experts will lose skill, leaving the team unable to supervise or replace the AI. Calm: Juniors can learn faster with AI as tutor and can be given real engineering and investigation work earlier; the old tier 1 was a poor school. Where they meet: Both accept that learning needs practice with consequences, that unassisted work must be designed in and that skill must be measured. What can be done: Design the route, measure the skills, keep a share of cases unassisted and drill the degraded mode.
Practical guides: Setting up a craft programme: unassisted share, seeded incidents, rotation, and a measure of what the team can still do
Worked examples: Apprenticeship record APP-HM-2027-01 for a junior analyst at the Polish service centre with supervised responsibilities, seeds and exit criteria
Nordvik Region and Hansa Mutual: Nordvik hires one junior analyst and pairs them with the lead analyst; Hansa starts an apprenticeship route with rotation between the SOC and detection engineering, and holds degraded-mode drills each quarter.
Observable, expected, speculation: Evidence on skill loss in other professions is observable; its extension to the SOC is expected; the disappearance of the entry rung is speculation and a risk.
Figure: How an analyst is made when triage is automated: unassisted practice, rotation, seeds and degraded-mode drills

Chapter 24: The Future of the Blue Team: Will There Be a SOC in 2036?

File: 24_the_future_of_the_blue_team.md
Status: draft
Purpose: Look ahead with the series' discipline: will there be a SOC in 2036? Treat the future of the blue team as a horizon register in which each trend is labelled observable, expected or speculation, and the author's own projection is confined to this chapter and Chapter 28. Cover the scenarios of a fully managed, mostly automated detection service; the dissolution of the SOC into engineering and platform teams; the persistence of the human incident commander; and the effect of AI-enabled adversaries on the shape of the work. State what would change the author's mind.
Builds on: F32, F33, F80, F71, F70, Q10, Q12
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: A horizon register; Three scenarios; What stays human; The effect of adversaries; The debate; The author's projection; What would change the view
Constructive debate: Concern: Within a decade a mostly automated detection and response service will replace the SOC as a human function and leave only a few experts with little practice. Calm: Detection and response will become more engineering-centred and more human where accountability must be human; SOCs have survived every previous wave of automation. Where they meet: Both accept that routine triage will largely be automated and that accountability for containment and the ability to verify and stop will remain human. What can be done: Keep the choice open: preserve skills, keep exits, record delegation and review the register yearly.
Practical guides: Writing a horizon register for your team with triggers and a yearly review
Worked examples: Horizon register HZN-HM-BT-01 with eight trends, their labels, triggers and review date
Nordvik Region and Hansa Mutual: Nordvik's horizon register is short and focuses on provider consolidation and public pay scales; Hansa's covers the shape of the SOC, agent autonomy and the regulatory trend.
Observable, expected, speculation: This chapter is where the author's projections are allowed, and each is labelled as such.
Figure: A horizon register with three scenarios for the blue team in 2036

Part VI: Experience and Conclusions

Chapter 25: Case Studies and Anti-Patterns

File: 25_case_studies_and_anti_patterns.md
Status: draft
Purpose: Collect case studies and anti-patterns of the transformed blue team, in the series' form: what happened, what failed, what the pattern is and what the control would have been. Draw on public incidents and reports where the evidence is sound (such as the July 2026 OpenAI and Hugging Face incident and the Arup deepfake fraud from the standpoint of detection and response), and on anonymised composites for internal cases. Name the anti-patterns: alert closure by metric, the unowned detection, the unstoppable agent, the provider's black box, the rubber-stamp review, the empty entry rung and the unmonitored monitor.
Builds on: F28, F45, F67, F62, F84, F57, Q2, Q4
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: Reading cases; The July 2026 incident from the blue side; Deepfake fraud and the detection gap; Anti-pattern: closing by metric; Anti-pattern: the black-box provider; Anti-pattern: the rubber stamp; Anti-pattern: the empty entry rung; Anti-pattern: the unmonitored monitor
Practical guides: Running an anti-pattern review of your own team in two hours
Worked examples: Anti-pattern record AP-HM-SOC-01 with the pattern, evidence, control and owner
Nordvik Region and Hansa Mutual: Nordvik's composite case concerns a provider's AI that closed a phishing report cluster; Hansa's concerns an agent whose containment was approved in four seconds.
Observable, expected, speculation: The cases are observable; patterns drawn from them are the book's own interpretation.
Figure: Seven anti-patterns of the transformed blue team, each with its control

Chapter 26: A Year on the Blue Team: Nordvik Region and Hansa Mutual

File: 26_a_year_on_the_blue_team.md
Status: draft
Purpose: Follow four people in the two organisations through a year on the blue team (2027): Karin Lund, senior security analyst and de facto detection owner at Nordvik Region; Piotr Nowak, shift lead at Hansa Mutual's Polish service centre SOC; Lena Vogel, detection engineering lead in Hamburg; and Thomas Brandt, chair of Hansa Mutual's Konzernbetriebsrat. Tell it as a narrative with dated decisions and records: the charter, the first closure policy, the first stop drill, a real incident and its reporting clocks, a review of oversight quality, a quarter of fatigue data, and the works agreement for SOC tooling. Keep every fact consistent with EXAMPLE_ORGANISATIONS.md.
Builds on: F81, F84, F86, F89, F62, F63, Q1, Q2, Q9
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: January: the charter; March: the first closure class; May: a stop drill; July: an incident; September: oversight; October: fatigue; December: review
Practical guides: Writing your own year-in-review from records, not memory
Worked examples: The year's decision records AIDR-0701 to AIDR-0712 and AIDR-0751 to AIDR-0766, and the incident record INC-HM-2027-0455
Nordvik Region and Hansa Mutual: The chapter compares Karin Lund's small team that must borrow capacity with Piotr Nowak's and Lena Vogel's larger one, and Thomas Brandt's role in agreeing the monitoring limits.
Observable, expected, speculation: The narrative is fiction built from the chapters of the book; each element is labelled illustrative.
Figure: A year on the blue team: the dated decisions, records and measures for two organisations

Chapter 27: Nordvik Region and Hansa Mutual: Conclusions for Two Organisations

File: 27_conclusions_for_nordvik_and_hansa.md
Status: draft
Purpose: Draw the chapters together into a conclusion for each organisation: what Nordvik Region and Hansa Mutual should do in the next two years for each of the five functions, what they should stop, and what each should decide at the management-body level. Compare them: the contractual leverage of the one and the platform leverage of the other, the single point of failure and the cross-regime complexity. Provide a plan with measures, owners, dates and a review, as in the closing chapters of the earlier volumes.
Builds on: F81, F62, F65, F69, F70, Q1, Q7, Q10
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: Nordvik Region: the plan; Hansa Mutual: the plan; Similarities and differences; Decisions for the management body; Measures and review; What each should stop doing
Practical guides: Turning a conclusion into a plan with six measures, owners and a review date
Worked examples: Plans PLAN-NR-BT-2027 and PLAN-HM-BT-2027 with conclusion records AIDR-0713 and AIDR-0767
Nordvik Region and Hansa Mutual: Nordvik's plan extends detection ownership, tests the provider's AI and secures the junior route; Hansa's plan extends Level 3 only where seeded-incident catch stays at or above 0.85 and keeps degraded-mode drills.
Observable, expected, speculation: The recommendations are the book's conclusions; they are not forecasts.
Figure: A two-year plan for each organisation across the five functions with measures and a review

Chapter 28: Conclusions: The Blue Team Transformed

File: 28_conclusion.md
Status: draft
Purpose: State the book's conclusions: what the evidence supports about the transformed blue team, which parts of the thesis hold, which are not proved and what would change the view. Return to the five parts of the thesis, give the author's labelled projection and the verdict on Q12, and end with what an individual analyst, a SOC lead, a CISO, a board member and an employee representative can do on Monday. Close the series' argument for the blue team: keep decisions as records that can be corrected, keep the ability to stop outside the system being stopped, keep people able to do the work and judge the output, keep dependence reversible and match autonomy to reversibility.
Builds on: F70, F71, F81, F91, F48, F62, F63, F69, Q12, Q1, Q3
Blue team functions: B1 Anticipate; B2 Detect; B3 Investigate; B4 Respond; B5 Learn
Sections: The thesis tested; The verdict; What would change the view; What to do on Monday; The series' argument; Limits of this book
Practical guides: A one-page plan for the first ninety days
Worked examples: The author's horizon statement, labelled as such
Nordvik Region and Hansa Mutual: Both organisations receive the same final test: can each show, from its own records, who decided what, and can each stop and recover?
Observable, expected, speculation: The author's projections are confined to this chapter and Chapter 24 and labelled as such.
Figure: The thesis in five parts, with the evidence and the conditions that would change the view

Appendices

29_glossary.md: Defines the vocabulary of the blue team and AI: the five blue team functions (B1 Anticipate to B5 Learn), the degrees of delegation and the usage modes, the book's artefacts (detection record, case record, playbook manifest, hunt record, post-incident review, mandate manifest, role charter, competence record, oversight record), and the terms of NIS 2, DORA, the Cyber Resilience Act, the GDPR and the AI Act that bear on a team.
30_appendix_a_code_examples.md: Appendix A: complete versions of the artefacts in the chapters: team function map and charter, delegation profile and register, detection record, closure policy, case record, playbook manifest, hunt record, post-incident review, mandate manifest for a SOC agent, review protocol, role charter, reporting-clock configuration and the board page.
appendix_templates_and_tools.md: Appendix B: templates and tools for mapping a team's functions, writing a charter and a delegation profile, a closure policy, a seeded-incident programme, a pre-production checklist for SOC AI, a provider-annex checklist, a decision-rights table, an incident clock, a fatigue and on-call review and a horizon register.
31_references.md: The only bibliography of the book: European instruments on cybersecurity, resilience, data protection and AI, frameworks and taxonomies, threat assessments, research on AI-enabled threats and defence, and the earlier volumes of the series.
32_about_the_author.md: About the author of The Architecture as Code Series, placed at the very end of the book.