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

The first three chapters of this book describe what the blue team does and what presses on it. This chapter defines what it becomes, and it does so in the form the series uses for anything that must hold whatever anyone intends: as an artefact. The transformed blue team is a team whose mandate, decision rights and degrees of delegation are written down, versioned and enforced, so that the question every security operations centre (SOC) now faces, which of the work a system may do and who answers for it, has an answer that can be read, tested and changed. The definition covers all five functions of Chapter 2, B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn, and it introduces the three artefacts that Parts II to V apply: the team charter, the delegation profile (DLG-*) and the delegation register. It answers which functions may be delegated to AI and to what degree, and adds who decides, how the decision is recorded and when it is reviewed.

The transformed blue team defined: mandate, five functions, delegation profile per function, and the accountability that stays with named people

Figure 4.1: The transformed blue team defined: mandate, five functions, delegation profile per function, and the accountability that stays with named people.

The chapter builds on what the series has settled. AI Red Team, Chapter 6, set five autonomy levels per action, from Level 0 Advisory to Level 4 Autonomous, and drew the line that matters most between Level 2 Supervised, where a person approves each action, and Level 3 Bounded, where a system takes the action inside a codified playbook that a policy decision point outside the model enforces (64, Nordqvist, 2026). The same chapter distinguished the usage modes, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, and concluded that the mode, not the model, sets the risk: in Modes 1 to 3 the AI borrows a person's identity, while a Mode 5 agent has an identity and permissions of its own. The Transformed Security Architect, Chapter 4, showed how to write a role down as a versioned artefact with a mandate, accountabilities and decision rights (66, Nordqvist, 2026). This chapter applies both to a team.

A team is an artefact

A role charter in The Transformed Security Architect states what a role is for, what it may decide, what it may only recommend and who may overrule it. It lives in version control, it has an owner and a review date, and it is the first place anyone looks when a decision is disputed. A team needs the same, for a reason that is easy to miss: a team that cannot state what it has delegated has delegated more than it knows. In both organisations of this book the delegations arrived one at a time. Hansa Mutual's investigation agent HM-SEC-001 was given Level 3 Bounded for two reversible actions by a single decision record (AIDR-0311). Nordvik Region's managed security service provider (MSSP) began closing low-severity alerts out of hours with its own AI under a framework agreement that says nothing about it, which is the Mode 0 blind spot of AI Red Team, Chapter 8 (64, Nordqvist, 2026). Each delegation was defensible or invisible. Nobody had written down the sum.

A team charter differs from a role charter in three respects. Several people and several systems share the mandate, so the charter must say who holds which part. Some of the work is done by machines with identities of their own, and some by a provider, so the charter must cover both. And the team's own AI is part of the estate it defends, so the charter must put the agents under the same mandate as the people and the same containment as any other privileged insider, the conclusion of AI Platform and Security, Chapter 19 (63, Nordqvist, 2026).

The charter is the top of a short stack of artefacts, each answering a different question and changing at a different pace.

Artefact Question it answers Owner Changes
Team charter (ROLE-*) What is the team for, who answers, who decides what? CISO and SOC lead Rarely; reviewed twice a year at first
Delegation profile (DLG-*) At which level may each capability act, per function and action class? SOC lead, with a named grant authority Whenever a level is decided
Mandate manifest (MND-*) What is this agent allowed to do, with which identity and budget? Agent owner Per agent, at each review or model change (Chapter 13)
Playbook manifest and closure policy (PBK-*) Under what conditions may a system take this action or close this class? Playbook or class owner Per playbook or class (Chapters 7 and 10)
Delegation register What is the sum of what has been delegated, and can each delegation be undone? SOC lead Continuously
AI Decision Record (AIDR) Why was the decision taken, by whom, and when is it reviewed? The decider Once per decision

The files sit in the SOC's repository under team/, so that a level cannot change without a pull request, a reviewer and a record. The working claim, tested in Parts II to V, is that the profile is the artefact that matters most in daily work, because it is the one that the policy decision points read.

Mandate and decision rights

A mandate has three parts. The scope says what the team defends: the organisation's information, services and people, and also the team's own platform and AI. The authority says what the team may do about it and who granted that authority. The obligation says what the team must be able to show: that it can do the work, that the work was done within the authority and that it can stop and undo what it started. The transformed team differs from its predecessor mostly in the third part. A queue-bound SOC could show its work by its tickets. A team that delegates must show, in addition, what it delegated and that it could take the work back.

Decision rights say, for each decision the team meets, who decides, who recommends, to whom the team escalates and who may overrule. The series' rule of The Transformed Security Architect, Chapters 7 and 17, applies: routine decisions are delegated to pipelines and forums under written decision rights, as gates instead of meetings (66, Nordqvist, 2026). The table below uses the action classes of Chapter 10, which are needed here first. The class follows the effect of a wrong action, not the confidence of the model.

Class What it covers Default ceiling
AC-0 Preserve Snapshots, log holds and copies of volatile data; changes nothing in the estate Level 3 Bounded
AC-1 Narrow and reversible Isolating one end-user workstation, revoking one session, quarantining one message, blocking one indicator; a person undoes it at once Level 3 Bounded, inside a playbook
AC-2 Wide or business-critical A server or production host, a service account that systems depend on, a service taken offline Level 2 Supervised
AC-3 Partly reversible, or about a person Disabling a user account, resetting an executive's credentials, rotating a shared secret Level 2 Supervised, with a named human approver
AC-4 Irreversible or external Wiping a host, deleting data, notifying a regulator, a public statement, a ransom negotiation Level 1 Assisted: the system drafts, a named person acts

An action decides about a named person's access to work when it removes or suspends that person's account, role or entitlement as a measure about them. That is AC-3. Temporarily isolating a device or revoking a session is reversible containment, not such a decision; it may run at Level 3 inside a playbook, and the person is told promptly.

The decision table shows a default set for a SOC. It is a starting point, and each row must be adapted to the organisation's structure and, where staff are affected, to its works agreement.

Decision Who decides Who may overrule, or decides instead
Close an alert in a class that has a closure policy The class owner, within the policy; an agent may execute at Level 3 The duty manager disables the class at once; the SOC lead
Declare an incident and appoint the incident commander The duty manager The SOC lead, the CISO
Contain a wide or business-critical asset (AC-2) The SOC lead at Level 2; the incident commander on shift as deputy when the SOC lead cannot be reached in the decision time The CISO, if the service owner contests
Disable the account of a named person (AC-3) The incident commander, with the named people of Chapter 18; never the agent The CISO
Take an irreversible or external action (AC-4), including a regulator notification A named person; AI may draft The CISO; legal and privacy officers where the action concerns them
Accept a residual risk The system owner; the team recommends The management body
Raise a degree of delegation The grant authority named in the profile; the team recommends The management body
Lower a degree of delegation, stop an agent Any holder of the stop right, at once Restart is the owner's decision, after review

The last two rows are deliberately asymmetric. Raising a level is slow and deliberate, and lowering it is fast and cheap. This follows the conclusion of AI Threat, Chapter 30, that the right to stop must be cheaper to exercise than the right to continue, and that a stop in good faith is never a failure (65, Nordqvist, 2026).

Practical guide: Writing a team charter and a first delegation profile in one working session

Purpose. Produce a first charter and delegation profile for a SOC in one half-day session, good enough to be adopted and then corrected by use.

Roles. The CISO or the SOC lead sponsors the session. The detection engineering lead, a shift lead or duty manager, the agent operator (where agents exist) and the senior analyst who owns the rules are the authors. The privacy officer joins for the data questions. Where a works council or union holds co-determination rights, as at Hansa Mutual under BetrVG §87(1) no. 6, its representative is invited or briefed before the session, not after. A team of six, as at Nordvik Region, will have one person in several of these roles; the steps do not change.

  1. Inventory the capabilities (20 minutes). List every AI that takes part in the team's work, by name, usage mode and identity: assistants analysts use, features inside the SIEM, EDR and SOAR products, built applications, agents, and the provider's AI where work is bought. Include Mode 0 features that nobody decided on. Chapter 1's first inventory is the input.
  2. List and classify the actions (30 minutes). For each capability, list what it can do, not what it is meant to do. Give each action a response class from Chapter 10 (AC-0 to AC-4) or a closure class from Chapter 7, or mark it as having no effect on the estate. An action that cannot be classified is not delegated.
  3. Set the ceiling (45 minutes). Apply the five questions of Chapter 10 to every action above Level 1: can a person undo it without the AI and how fast, what is the largest effect of a wrong action, does it decide about a named person's access to work, how many independent sources must agree, and can the stop path reach it. The lowest ceiling any answer gives governs.
  4. Name the people (30 minutes). For every entry, name the owner, the holders of the stop right, the grant authority and, for Level 2 and above, the decider. An entry without a name is a finding and is set to Level 0 until it has one.
  5. Write the mandate and decision rights (30 minutes). Use the two tables above as the draft. Record what is not delegable to any system, including Level 4.
  6. Set tests and review triggers (30 minutes). For each Level 2 and Level 3 entry, define the reversibility test and the date of the next one. Defaults: Level 3 entries reviewed every six months, Level 2 every twelve, the charter every six months in its first year and then yearly, and every trigger of the last section of this chapter.
  7. Record and commit (30 minutes). Write the decision as an AI Decision Record, commit the files, enter the first rows of the delegation register, and brief the employee representatives on anything that touches monitoring of staff.

Definition of done. The charter and the profile are in version control and approved by the CISO; every entry has a class, a level, a named owner, a stop holder and a review date; the policy decision points read the profile, or a ticket exists to make them do so; and the register has its first rows. Adapt the review intervals to the size of the team, the contract and the works agreement.

Worked example: Hansa Mutual's team charter

Illustrative. This is the charter of Hansa Mutual's group SOC, adopted by AIDR-0772 on 2027-01-26. It names no agents; the agents and their levels live in the profile, so that a new agent changes the profile and not the charter.

# Illustrative: Hansa Mutual, team/charter.yaml
id: ROLE-HM-SOC-01
version: 1.0.0
decision_record: AIDR-0772
effective: 2027-02-01
team: Group SOC, Hamburg and the Polish service centre
granted_by: group CISO, for the executive board
mandate:
  purpose: Detect, investigate and respond to threats against the group, and learn from each
  scope: [group entities in seven legal regimes, the SOC's own agents and platform]
  functions: [B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond, B5 Learn]
accountable:
  mandate_and_resources: group CISO
  conductor_of_agents: group SOC lead
  function_owners:
    B1: threat-intelligence cell lead
    B2: detection engineering lead
    B3: investigation leads
    B4: incident commander on duty
    B5: group SOC lead
decision_rights:
  team_decides: [alert dispositions within closure policy, incident declaration, Level 2 containment]
  recommends: [risk acceptance, raising a level]
  escalate_to_group_ciso: [Level 2 containment of a production service, any AC-4 action]
  may_overrule_team: [group CISO, executive board]
not_delegable:
  level_4: never used for an irreversible B4 Respond action or a decision about a named person's access to work
  to_any_system: [residual risk acceptance, regulator notification, decisions about analysts]
stop_and_restart:
  may_stop: [duty analyst, incident commander, agent operator, shift lead]
  restart_by: group SOC lead
  stop_path_independent_of: [soc-platform, soar]
delegation:
  profile: DLG-HM-SOC-01
  register: team/delegation-register.yaml
  levels_above_2_granted_by: group AI governance board
  lowering_a_level: any function owner at once, reported to the SOC lead
people:
  employee_representation: Konzernbetriebsrat under KBV-IT-2024, SOC annex
  oversight_metrics: aggregate only, no measures by person
review:
  every_months: 6
  also_on: [model change, incident with a finding on delegation, change of mode or identity, new instrument, failed reversibility test]
  next: 2027-08-01

Three entries carry the design. The not_delegable block states the series' bright line in the charter itself, where a reviewer or an auditor will look, and not only in the profile. The stop_and_restart block gives four roles the right to stop and one role the right to restart, which is the asymmetry of the previous section in writing. And the people block records the agreement with the Konzernbetriebsrat that oversight measures are aggregate, so that the charter does not become a means of measuring individual analysts.

Degrees of delegation per function

A delegation profile states, for every capability the team uses, the pair that this book treats as the unit of delegation: the usage mode and the level. The mode describes how the AI is deployed and whose identity it uses. The level describes who decides each action. Both are needed. A Mode 3 tool at Level 2 and a Mode 5 agent at Level 2 look alike in a table, but the first acts with an analyst's access and leaves an audit trail that cannot tell the analyst from the tool, and the second has a workload identity of its own that can be revoked.

The level for an action is set from the inputs of AI Red Team, Chapter 6: reversibility, blast radius, confidence and the decision tier, to which this book adds a fifth, exposure to attacker-controlled input (64, Nordqvist, 2026). The input matters because the text an AI system reads in an alert, a ticket or a log field may have been written by the adversary, as Chapter 15 sets out with its trust classes T0 to T3. The higher the share of attacker-writable input behind an action, the more the corroboration must come from independent sources that do not share a data path, and the lower the ceiling if it cannot. Confidence is the input that does least. A model score changes whether an action is proposed; it does not change what a wrong action costs, so it does not lift the ceiling (Chapter 10).

Six rules make the profile enforceable.

  1. An action that is not listed is not delegated. The profile is a list of permissions, not a list of prohibitions.
  2. The lowest ceiling governs. If the class, the asset, the hour and the state of the evidence give different ceilings, the lowest applies.
  3. Modes 1 to 3 stay at or below Level 2. The AI uses a person's identity, and a Level 3 action under that identity would blur who is accountable (Chapters 10 and 12).
  4. Level 3 names its enforcement. Every Level 3 entry names the playbook or closure policy that bounds it and states that a policy decision point outside the model enforces it. Without that, the entry is Level 2.
  5. Levels above 2 have a named grant authority. Anyone with a stop right may lower a level at once. Only the authority raises it, by a recorded decision.
  6. Level 4 is not an entry. The profile schema rejects it, and a test in the pipeline fails if a playbook or mandate asks for a level the profile does not allow.

The defaults differ by function, because the consequences of a wrong action differ. The table gives the ceilings that Chapters 5 to 11 argued for.

Function What may be delegated Default ceiling Reason
B1 Anticipate Extraction from reports, ranking of exposure, drafting hunt queries Level 0 Advisory to Level 1 Assisted; hunting packs at Level 2 Supervised The output is a proposal; intelligence is written by third parties who include adversaries (Chapter 5)
B2 Detect Drafting detections and tests; closure of named alert classes Drafting Level 1 Assisted; closure Level 3 Bounded for named classes only A draft changes what the SOC sees and a person decides; closure is reversible only in part, so classes stay narrow (Chapters 6 and 7)
B3 Investigate Enrichment, timelines, hypotheses; evidence collection from defined sources Level 1 Assisted; collection Level 3 Bounded Findings are evidence for a person; collection alters nothing (Chapter 8)
B4 Respond Preservation and narrow reversible containment; wider, person-related and irreversible actions AC-0 and AC-1 Level 3 Bounded; AC-2 and AC-3 Level 2 Supervised; AC-4 Level 1 Assisted The ceiling follows the effect of a wrong action (Chapter 10)
B5 Learn Drafting reviews, proposing changes, opening findings Level 1 Assisted for drafts; Level 2 Supervised for proposed changes to detections and playbooks Changes to the team's own controls need a human owner (Chapter 11)

Worked example: Hansa Mutual's delegation profile

Illustrative. The profile DLG-HM-SOC-01 as it stands on 2027-07-01, after the incident INC-HM-2027-0455 and its review. Each line is one entry; the function, capability, mode, action, class, level and the person or record that answers for it are all on that line.

# Illustrative: Hansa Mutual, team/delegation-profile.yaml
profile: DLG-HM-SOC-01
version: 1.4.0
as_of: 2027-07-01
charter: ROLE-HM-SOC-01
owner: group SOC lead
grant_authority_above_level_2: group AI governance board
unlisted_actions: not delegated
level_4: none granted
ceilings: {AC-0: 3, AC-1: 3, AC-2: 2, AC-3: 2, AC-4: 1}
amended_by: [AIDR-0753, AIDR-0765, AIDR-0768, AIDR-0771]
entries:
  - {fn: B1, capability: HM-SEC-005, mode: 4, action: rank exposure, class: none, level: 0, answers: patch owner}
  - {fn: B1, capability: HM-SEC-002, mode: 5, action: extract techniques from reports, class: none, level: 1, answers: intelligence cell reviewer}
  - {fn: B1, capability: HM-SEC-007, mode: 5, action: run approved hunt packs read-only, class: none, level: 2, answers: hunter approves each pack, reason: own identity and attacker-writable input}
  - {fn: B2, capability: HM-SEC-002, mode: 5, action: draft detections and tests, class: none, level: 1, answers: detection engineer reviews every change}
  - {fn: B3, capability: HM-SEC-006, mode: 5, action: close SC-01 and SC-02, class: SC, level: 3, answers: class owner, policy: CLOSE-HM-SOC}
  - {fn: B3, capability: HM-SEC-006, mode: 5, action: close SC-03, class: SC, level: 2, answers: class owner}
  - {fn: B3, capability: HM-SEC-001, mode: 5, action: hypotheses and timeline, class: none, level: 1, answers: investigation lead}
  - {fn: B3, capability: HM-SEC-001, mode: 5, action: collect evidence from defined sources, class: AC-0, level: 3, answers: investigation lead}
  - {fn: B3, capability: HM-SEC-001, mode: 5, action: image a host, class: AC-0, level: 2, answers: investigation lead}
  - {fn: B4, capability: HM-SEC-001, mode: 5, action: propose isolation of a workstation; the playbook runner executes, class: AC-1, level: 3, playbook: PBK-HM-ISOLATE-01, user_told: promptly}
  - {fn: B4, capability: HM-SEC-001, mode: 5, action: propose revocation of standard-user sessions; the playbook runner executes, class: AC-1, level: 3, playbook: PBK-HM-REVOKE-01, user_told: promptly}
  - {fn: B4, capability: HM-SEC-001, mode: 5, action: block an indicator, class: AC-1, level: 2, answers: senior analyst of the market}
  - {fn: B4, capability: HM-SEC-001, mode: 5, action: isolate a server or production host, class: AC-2, level: 2, answers: SOC lead (incident commander as deputy)}
  - {fn: B4, capability: HM-SEC-001, mode: 5, action: disable an account, class: AC-3, level: 2, answers: incident commander}
  - {fn: B4, capability: any, mode: any, action: wipe or delete or notify or publish, class: AC-4, level: 1, answers: named person acts}
  - {fn: B5, capability: HM-SEC-001, mode: 5, action: draft review timeline, class: none, level: 1, answers: facilitator verifies}
reversibility_tests: {stop_drill: quarterly, degraded_mode_drill: quarterly, manual_queue_target_minutes: 15, stop_target_seconds: 120}
review: {level_3_entries_months: 6, others_months: 12, on_trigger: charter list}

Read the profile from the ceilings down. Two entries sit below the default ceiling of their class: Hansa runs imaging and indicator blocking at Level 2, although AC-0 and AC-1 would allow Level 3, because it has not asked for the extra delegation. The class is a ceiling, not a target. The hunting agent HM-SEC-007 stays at Level 2 although it only reads: it runs on its own identity, its queries load shared platforms, and what it reads may have been written by an adversary, so a person approves each pack. Only the isolation and revocation playbooks, evidence collection and two closure classes reach Level 3, which is the sum that the register of a later section reports. In the two isolation lines the agent proposes and the playbook runner executes; the playbook starts only on a proposal from the agent's identity that meets the corroboration rule, which is why the register counts them as depending on that identity. No entry reaches Level 4, and the last B4 line states the position for any system, whatever its mode: irreversible and external actions are drafted by AI and taken by a named person.

Worked example: Nordvik Region's delegation profile

Illustrative. Nordvik's profile is shorter, and its distinguishing feature is that it records what the Region cannot see. The provider's AI is part of the function, so the profile has entries for it, with levels set by contract where they are set at all. The version shown is that of 2027-03-22, after the weekly sample of the provider's closures found CASE-NR-0231.

# Illustrative: Nordvik Region, team/delegation-profile.yaml
profile: DLG-NR-SEC-01
version: 1.1.0
as_of: 2027-03-22
charter: ROLE-NR-SEC-01
decision_record: AIDR-0716
owner: CISO
maintained_by: senior security analyst
grant_authority: CISO
unlisted_actions: not delegated
level_4: none granted
entries:
  - {fn: B1, capability: NR-SEC-003, mode: 4, action: rank exposure, level: 0, answers: security unit}
  - {fn: B1, capability: hunting query pack, mode: 1, action: draft hunt queries, level: 1, answers: senior security analyst reviews every query}
  - {fn: B2, capability: detection-drafting assistant, mode: 4, action: draft on rules the Region owns, level: 1, answers: senior security analyst}
  - {fn: B3, capability: NR-SEC-001, mode: 4, action: summarise and recommend, level: 1, mandate: MND-NR-SOC-01}
  - {fn: B3, capability: provider AI, mode: 0, action: close low-severity alerts out of hours, level: not established, interim_control: weekly sample AIDR-0712, contract: annex MS-2}
  - {fn: B3, capability: SIEM embedded assistant, mode: 0, action: any, level: off until annex MS-2}
  - {fn: B3, capability: email gateway classifier, mode: 0, action: classify user-reported phishing, level: not established, interim_control: inventoried}
  - {fn: B4, capability: provider AI, mode: 0, action: isolate an end-user workstation, class: AC-1, level: 3, playbook: PBK-NR-ISOLATE-01, enforced_in: Region-owned endpoint console, user_told: promptly}
  - {fn: B4, capability: provider AI, mode: 0, action: servers or accounts or citizen-facing services, class: AC-2 and AC-3, level: not delegated, answers: named on-call manager}
  - {fn: B4, capability: any, action: wipe or delete or notify or publish, class: AC-4, level: not delegated, answers: named person}
stop_for_provider_ai: contractual instruction the Region can give and test (15-minute budget in the draft annex MS-2)
review: {months: 6, on_trigger: model change notice under MS-2, incident, new instrument}

Two features distinguish it from Hansa's profile. The Region cannot enforce a level on the provider's closures, so the entry records the truth, not established, and the control that stands in for the missing level: the sample, reviewed by the senior security analyst. The only delegation it does enforce is the one that runs through the console it owns, where the isolation policy and PBK-NR-ISOLATE-01 bound what the provider's AI may do. The line for the SIEM assistant records a decision to leave a feature off. A profile that lists only what is switched on omits the decisions that protect the team.

Where Level 4 is never used

Two kinds of action are excluded from Level 4 Autonomous by the series' rule, and this book applies it without exception: an irreversible B4 Respond action, and an action that decides about a named person's access to work (64, Nordqvist, 2026) (67, Nordqvist, 2026).

The first exclusion follows from reversibility. Wiping a host, deleting data, destroying or altering evidence, notifying a regulator or the people affected, making a public statement and negotiating with an extortionist cannot be recalled. At Level 4 no person stands between a wrong decision and its effect, and for these actions there is nothing to undo afterwards. AC-3 therefore stops at Level 2 Supervised with a named decider, and AC-4 stops at Level 1 Assisted, where the system drafts and a named person acts.

The second exclusion follows from accountability. AI Boss, Chapters 4 and 33, concluded that AI may direct work but may not on its own decide about people: every function that carries consequences for a person has a named human decider who can be identified, contested and held to account (67, Nordqvist, 2026). The blue team meets this in two places. The first is containment aimed at a person. Disabling the account of a member of staff, or suspending their access, is a measure about that person and a technical action with a consequence for their ability to work, so it is AC-3: Level 2 at most, and a named human approves. Temporary isolation of a device or revocation of a session is reversible containment, not a decision about the person's access to work; it may run at Level 3 inside a playbook, and the person is told promptly. The line is narrow on purpose, and it is the reason AC-1 stays narrow, time-limited and reversible. The second place is the team's own people. The tools that record analysts' queries and actions could, in principle, feed decisions about them. The charter therefore places decisions about analysts, their performance, access, rota and progression with named managers, and the oversight metrics that Chapters 14 and 20 describe are aggregate by agreement with the employee representatives.

In both organisations, Level 4 is not used for any action at all. That is a stronger position than the rule requires, and a deliberate one: a bright line that is stated in the charter and rejected by the profile's schema is cheaper to hold than a ceiling that is argued afresh each time a vendor offers a faster product.

The delegation register

A profile shows what has been decided. A register shows the sum. AI Threat, Chapter 26, concluded that small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists, and that the remedy is a register of what has been delegated together with reversibility tests that check each delegation can be undone, with further delegation frozen where a test fails (65, Nordqvist, 2026). Chapter 13 applied the idea to the agent team: a class that no analyst on shift can handle unassisted goes into the register as a dependency.

Each row of the register records the delegation, the function and class, the level, the record that granted it, the fallback if the AI is removed, and the date of the next reversibility test. Each test asks three things: can a person do the task without the AI within the stated time, can the action be undone within the stated time, and can the stop path reach the action. The register's value lies less in any row than in the sum, and the sum is read four ways: how many delegations stand at each level, in which functions they cluster, how many depend on the same platform or model (a shared dependency makes two delegations one), and how many people can still do the delegated work by hand.

Illustrative. The table shows the Level 3 entries of Hansa Mutual's register on 2027-07-01.

Delegation Function and class Level Granted Fallback Next test
HM-SEC-006 closes SC-01 and SC-02 B2, B3; closure classes 3 AIDR-0765 Manual-queue runbook, queue worked within 15 minutes Quarterly drill, 2027-09-30
HM-SEC-001 isolates a workstation B4; AC-1 3 AIDR-0753, AIDR-0311 Release of isolation within 5 minutes; analysts isolate through the console Stop drill, passed 2027-06-03, due 2027-09-03
HM-SEC-001 revokes standard-user sessions B4; AC-1 3 AIDR-0311 Duty analyst revokes at the identity provider Stop drill, due 2027-09-03
HM-SEC-001 collects evidence from defined sources B3; AC-0 3 MND-HM-SOC-02 Analyst collection by runbook Quarterly drill, 2027-09-30

Read as a sum, the table says: five delegations at Level 3 in four rows, none at Level 4, all in AC-0, AC-1 and two narrow closure classes, three of them dependent on one agent identity. The last observation is the one a profile does not show. If HM-SEC-001's identity is revoked, as the stop path is designed to do, the proposals that start the two playbooks and the evidence collection stop, so three delegations fall back at once, and the register is where the SOC checks that its analysts can absorb them. A failed test freezes new delegation in that function until the test passes, and lowers the failed entry by one level until it does, which matches the default of Chapter 11 for a stop path that has not been exercised in 180 days.

Nordvik's register has fewer rows and a different shape. Its largest entries are the ones it cannot test: the provider's closures, the email gateway classifier and the provider's out-of-hours capacity, recorded as dependencies without a verified fallback. The single largest delegation is the one the Region has not yet written down in a contract.

Accountability that does not move

Delegation moves work. It does not move accountability. The instruments say so for the organisations in this book. NIS 2 Article 20 places the approval and oversight of cybersecurity risk-management measures on the management bodies of essential and important entities (3, European Union, 2022), and DORA Article 5 places the management of ICT risk, including its governance arrangements, on the management body of the financial entity (2, European Union, 2022). AI Red Team, Chapter 6, concluded from these that responsibility does not pass to a tool, and that at Level 3 the human approval moves from the action to the playbook and the decision record, which concentrates accountability instead of diluting it (64, Nordqvist, 2026). These are implications for design, not legal advice, and a national transposition may add detail. DORA is the primary regime for Hansa Mutual's EU financial entities; whether NIS 2 also reaches non-financial parts of the group depends on national transposition and is for the group's legal function. For Nordvik Region NIS 2 applies as nationally transposed, to the extent regional government entities fall within scope.

The charter turns this into a chain in which every link is a named person, and the chain is the same at every level of delegation.

Position Answers for Evidence
Management body Approving the mandate and the resources; accepting residual risk Minutes, the charter's approval
CISO The charter, the profile, and the team's compliance with the mandate Charter, AI Decision Records
Grant authority Every level above 2: that the conditions for it were met when it was granted The AI Decision Record
SOC lead The conduct of the agent team, the register, and the conditions under which people review Register, review protocol, oversight-quality metrics
Class or playbook owner The definition, the sampling and the stop condition of what the system executes Closure policy, playbook manifest
Incident commander and approvers Each Level 2 decision and each decision about a named person Case record

The hardest case for this chain is one that The Transformed Security Architect, Chapter 14, and AI Boss, Chapter 26, raised: a missed intrusion that AI closed and an analyst accepted without reading the evidence. This chapter's answer is the book's own conclusion, and it has four parts.

First, accountability follows the decision record. If the closure was a Level 3 closure under a class policy, the class owner answers for the class definition and the grant authority for having granted the level, and no analyst answers for a decision that was not theirs.

Second, if the closure was a Level 2 proposal that an analyst accepted, the analyst answers for the acceptance only to the extent that the conditions allowed it to be a review. Those conditions are the SOC lead's: the load per reviewer, the time, the access to evidence, and the seeded errors that show whether review works. Chapter 14 reports what happens when they are not met: at Hansa, as the volume of HM-SEC-001 proposals tripled, the median approval time fell sharply, which is a warning that review has stopped being review unless seeded errors show otherwise. The person accountable for that is whoever set the volume.

Third, the post-incident review asks about the design of the delegation first and about the acceptance second, and it records conditions and not blame, as PIR-HM-0455 did.

Fourth, accountability never reaches the tool: a model that scored an alert is not a party to the review, and "the AI closed it" is a statement of mechanism, not of responsibility.

Reviewing the charter

A charter that is not reviewed becomes a description of last year's team. The charter and profile therefore carry both a calendar and a set of triggers, and any trigger reopens the affected entries without waiting for the calendar.

Trigger What is reviewed Default
Calendar The charter; Level 3 entries; other entries Charter every six months in its first year, then yearly; Level 3 entries every six months; others yearly
Model change Every entry that runs on the changed model, including the provider's Before the change takes effect where the contract gives notice (20 working days at Nordvik under the requirements for annex MS-2); at once for Hansa's own agents
Incident or exercise Entries touched by a post-incident review finding about delegation Within the review's action window; FND-HM-0455-2 and -3 changed a playbook and a stop control
Move between modes Entries whose identity or mode has changed Before the change; HM-SEC-002 kept Level 1 when it gained a Mode 5 identity, and the profile records the new mode
New instrument or guidance Entries affected, and the accountability table When the instrument is decided, not when it applies
Failed reversibility test The failed entry, and new delegation in its function Immediately: the entry drops one level and further delegation is frozen
Change to the works agreement Entries that record or analyse staff behaviour Before the change, with the employee representatives

The review reads the register, the latest drills, the sampling results and the oversight-quality metrics, and it ends in a new version of the files and an AI Decision Record. Raising a level needs the grant authority and evidence that the previous level was stable. Lowering needs only the stop right, and a review confirms it afterwards.

Three points close the chapter. First, the instruments place responsibility for cybersecurity risk management on management bodies (NIS 2 Article 20, DORA Article 5), and the book assumes, as the premise of the register, that security agents with identities of their own are in operation in the organisations it describes; the two organisations are illustrations, not evidence. Second, a management body that must oversee delegation needs the profile, the register and the stop-path tests to do it, so the design recommendation is to keep them in a form that can be shown to a supervisor or an auditor. Third, a profile that adjusted its own levels from measured performance, without a recorded human decision, is a design this book does not adopt: raising a level is always a decision by a named authority. The charter, the profile and the register are this book's own design, applied in Parts II to V and judged in Chapters 24 and 28.

Across the degrees of delegation

The table shows what the profile records for each usage mode and the default ceiling it applies. The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.

Usage mode What the profile records Default ceiling in the profile Who is named
Mode 0 Ambient AI The vendor's or provider's AI, as not established until a contract states its level Set by contract; otherwise none Contract owner; the CISO
Mode 1 Conversational assistants Drafting and summarising with the analyst's identity Level 0 Advisory to Level 1 Assisted The analyst
Mode 2 Embedded workplace assistants Recommendations inside the SOAR or EDR console Level 1 Assisted The analyst
Mode 3 Agentic work tools Actions with the analyst's identity Level 2 Supervised at most The analyst; the agent operator
Mode 4 Built AI applications Services with their own service identity Level 1 Assisted for analysis; response applications as in Chapter 10 (Level 3 for AC-0, Level 2 for AC-1 until a recorded decision) The service owner
Mode 5 Autonomous production agents Agents with an identity and permissions of their own Level 3 for AC-0 and AC-1 inside a playbook; Level 2 for AC-2 and AC-3; Level 1 for AC-4 The agent owner; the grant authority

No row reaches Level 4 Autonomous, for any function or action class.

Nordvik Region and Hansa Mutual

Nordvik's charter, ROLE-NR-SEC-01, adopted by AIDR-0716 on 2027-01-25, describes a hybrid team. Six analysts work office hours, the provider monitors out of hours under framework agreement NR-2025-044, and the provider's detections and its AI are part of the function. The charter says what the Region keeps (the decision about severity, every action above AC-1, every irreversible action, the content of detections it owns under annex MS-1) and what it buys, and its profile records the provider's AI with levels set by contract. The Region's levers are the console policy, the weekly sample and the contract, and the work of the year is to turn its not established entries into levels. The CISO is both owner and grant authority, which suits a unit of 14 and means that the reviewer of a level is also the person who set it; the charter compensates by recording each level change as an AI Decision Record reviewed by the data protection officer and the AI architect, as AIDR-0700 names them.

Hansa's charter, ROLE-HM-SOC-01, adopted by AIDR-0772 on 2027-01-26, governs a SOC of about 38 people in two countries and five agents of its own. Its levers are the platform, the manifests and the stop path, which does not run inside the SOC platform. The difficulties are of scale: a profile that stays consistent across two sites and seven legal regimes, a group AI governance board that grants the levels above 2 on evidence from the register, and a Konzernbetriebsrat whose agreement shapes what the register and the oversight metrics may contain. Both organisations name a person at every link, and both can lower a level without asking permission.

Summary

This chapter defined the transformed blue team as an artefact. A charter states the mandate (scope, authority, obligation), the decision rights and what no system may do. A delegation profile states, per function and per action class, the mode and the level at which each capability may act, with the lowest ceiling governing and any unlisted action left undelegated. The delegation register states the sum, and a reversibility test checks that each delegation can be undone. The five functions are covered: B1 Anticipate and B5 Learn at the low default ceilings of drafting and proposing, B2 Detect and B3 Investigate at Level 3 Bounded only for named closure classes and evidence collection, and B4 Respond by action class from Level 3 for narrow reversible actions to Level 1 for irreversible ones.

Level 4 Autonomous is never used for an irreversible B4 Respond action, and never for an action that decides about a named person's access to work. Neither organisation uses it for anything. The accountability that does not move runs from the management body, under NIS 2 Article 20 and DORA Article 5, through the CISO, the grant authority and the SOC lead to the owner of each class and playbook and the incident commander who decides. When AI closed an alert and an analyst accepted the closure, the record decides who answers: the class owner and the grant authority for a Level 3 closure, the analyst for a Level 2 acceptance that the conditions made it possible to review, and the SOC lead for those conditions.

The charter is reviewed on a calendar and on triggers: a model change, an incident, a move between modes, a new instrument, a failed reversibility test and a change to the works agreement. Lowering a level is immediate and raising one is a decision by a named authority. The artefacts are the book's own design and are tested in the chapters that follow.

For Nordvik Region the chapter means writing down a hybrid team, including what it cannot yet see in its provider's AI. For Hansa Mutual it means keeping a team of agents and people inside one profile across two sites and the agreement of its works council. A reader can begin with one action: list every AI that takes part in the team's work, classify what it can do, and write against each action the level, the person who answers and the date of its review. Chapter 5 turns to B1 Anticipate, where the first delegation of Part II is made: what intelligence work may be delegated when the reports an extraction pipeline reads may have been written by the adversary.

Sources

  1. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (64, Nordqvist, 2026)
  2. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (66, Nordqvist, 2026)
  3. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (65, Nordqvist, 2026)
  4. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (67, Nordqvist, 2026)
  5. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (63, Nordqvist, 2026)
  6. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
  7. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)