Team Design and Roles: After the Tier-1 Pyramid

Part III described the AI team that works inside the security operations centre (SOC). This chapter describes the human team around it: which roles grow when triage is largely automated, which shrink, which are new, what shape the team takes, how a role is written down as a versioned charter, how the night is staffed when agents act while people sleep, and where the team meets the security architect, platform engineering, IT operations and the business. It concerns all five blue team functions: B2 Detect gains the detection engineer, B3 Investigate the investigation lead and the class owner, B4 Respond the incident commander and the agent operator who can stop what the team has started, B1 Anticipate the intelligence analyst, and B5 Learn the purple team coordinator and the evaluation engineer who test the machinery that the others rely on.

The chapter applies two earlier conclusions. A role is itself a versioned artefact, with a mandate, accountabilities and decision rights written in a charter that a reviewer can read and a test can check (The Transformed Security Architect, Chapter 4) (66, Nordqvist, 2026). And organisational design is architecture by other means: the structure of a team determines the structure of the systems it builds and the seams where they fail (AI Governance, Chapter 12) (62, Nordqvist, 2026). The question of where the next generation of analysts comes from is left to Chapter 23. This chapter shows the shape of the team that has to answer it.

Figure 17.1: From pyramid to diamond: the roles that grow and shrink and the seams to neighbouring teams.

The pyramid under strain

The traditional SOC is a pyramid. A wide base of tier 1 analysts watches the queue, validates alerts, enriches them and escalates what looks real. A narrower tier 2 investigates the escalations. A small tier 3 hunts, reverse engineers and builds detections. A manager sits at the top. The shape was a response to volume: most alerts were noise, validating them was repetitive, and the cheapest labour that could do it was the least experienced. It was also a school. A new analyst learned what normal looks like by seeing thousands of ordinary alerts, and was promoted when the pattern recognition was good enough to be trusted with an investigation.

Both functions of the base are under strain at once. The first is the work. Chapter 7 showed that triage is now increasingly done by AI that enriches, correlates and, in defined classes under a closure policy, closes alerts without a person reading them. A qualitative study of SOC analysts' views of security alarms, whose title reports a 99 per cent false-positive experience, takes the validation of alarms by SOC analysts as its subject (69, Alahmadi et al., 2022), and a survey of the research treats alert fatigue in SOCs as a challenge in its own right (72, Tariq et al., 2025). Removing the repetitive classes from human hands answers a problem that this literature documents. The second is the school. If the base is removed, the route through which experts were made is removed with it. Bainbridge's analysis of automation names the mechanism: automation leaves the human with the tasks it cannot do and takes away the routine practice that would have kept the human able to do them (75, Bainbridge, 1983). AI Threat, Chapters 6 and 14, applied the point to professions in general and concluded that automating junior work removes the route by which experts are made (65, Nordqvist, 2026).

The labour market does not make the problem go away. The ISC2 2025 workforce study, an online survey of 16,029 practitioners and decision-makers, reports that professionals are more concerned about critical skill needs than about staffing numbers, and that 73 per cent believe AI will create more specialised cybersecurity skills (73, ISC2, 2025). That is what a self-selected survey of practitioners reports about their expectations, and it does not measure what organisations will do with their entry posts. It is consistent with the direction this chapter takes: the scarce thing is specialised judgement, and the question is how it is produced.

What happens to the tier 1 functions

Tier 1 as a label does not disappear in a night. Its functions divide. Chapter 7 named four parts of the analyst's work once repetitive classes are closed by class: reviewing closures, handling the residual queue, owning classes, and teaching the system what it did not know. Each lands in a different place in the team.

Tier 1 function	Where it goes	Role that carries it
Validating repetitive alerts	Closed by class at Level 3 Bounded, or recommended at Level 1 or 2	Triage agent under a mandate; class owner answers
Sampling and reopening closures	A weekly or daily review from a stream	Analyst on rota; class owner reads the escape rate
Working the residual queue of ambiguous and novel alerts	Resembles tier 2 work, with hypothesis and query	Analyst, investigation lead for the hard cases
Learning what normal looks like	Must be designed in, because the queue no longer teaches it	Apprenticeship route (Chapter 23)
Writing down why an alert was noise	Becomes a detection change	Detection engineer

The conclusion this table supports is the book's own. The count of posts is the wrong starting point, because the functions that remain are different in kind from the ones that went. The right question is which roles the remaining functions need, who holds them, and how a person comes to hold them.

Roles that grow

Five roles grow when triage is automated. None is invented by this book; all exist in some SOCs already. What changes is that they become the centre of the team instead of its edge.

The detection engineer

The detection engineer owns the detection records of Chapter 6: the logic, the tests, the scenario that proves it fires, the review date and the escape findings. Under B2 Detect this is the role that takes noise out at the source. A closure class that an agent handles at Level 3 is a sign that a detection is producing the same alert for the same benign reason every day, and the better answer is often to change the detection. The detection engineer also reviews what the detection-drafting agent proposes. At Hansa Mutual that agent produced 48 drafts and 15 merged in the first quarter of 2027, and the engineers who read them are the limiting resource, which is the subject of Chapter 14. The role needs engineering skills (version control, testing, query languages, data modelling) and threat knowledge in the same person, and that combination is scarce.

The investigation lead

The investigation lead is the successor to tier 2 and the senior end of tier 1. The role takes the hard cases of B3 Investigate (Chapter 8): scoping, timeline, forensic questions and the verified case record. It also takes a duty that did not exist in this form before, which is reproduction. When an AI system drafts a hypothesis, the lead is the person who can reproduce it independently from the evidence before the case is closed, and who decides, in the words of Chapter 14, whether the review that happened was real. The lead mentors, because the lead is where the craft is concentrated.

The incident commander

The incident commander is accountable for the decisions of B4 Respond during an incident: containment, communication, escalation and the written record of each decision. Chapter 10 treated response as playbooks that run actions at the right level; the commander is the person who approves Level 2 actions, who invokes the stop, and who answers to the management body. The role is not new, but its content shifts, because with agents proposing containment at machine speed the commander's scarce skill is declining or reversing a proposal quickly and correctly. The commander is normally an assignment on a rota, not a post: a senior analyst, an investigation lead or the duty manager takes the role for an incident. Chapter 18 sets out which decisions it carries.

The agent operator

The agent operator is the role that AI Governance, Chapter 14, introduced as one of the roles that follow the usage modes: the person who watches Mode 5 agents and may revoke their credentials (62, Nordqvist, 2026). In the SOC, Chapter 13 gave the operator its place in the chain of accountability: the operator answers that the agent runs within budget and that its telemetry is watched, runs the stop drill, and holds the right to pause an agent without asking. The right is deliberately cheap to exercise. The operator's skills are those of a platform engineer, not those of an analyst, and that is why the role sits on the platform team's rota in both organisations.

The class owner and the intelligence analyst

The class owner is a senior analyst who owns the closure of one alert class at Level 3: reads the sampling, tunes the definition with the detection engineer, and pauses the class when an escape appears. It is a role held in addition to another, but it carries a named accountability, and the book's rule is that a closure class with no owner is a defect. The intelligence analyst serves B1 Anticipate (Chapter 5): turns reports into hypotheses for the detection engineer and the hunter. In small teams the role is a fraction of one person's week, and its charter says so.

New roles

Three roles are new in the sense that most SOCs have not had them as named positions.

The purple team coordinator runs the joint loop between the red team and the blue team under B5 Learn (Chapter 11): schedules the exercises, makes sure that the findings reach the detection engineer and the playbook owner in a form they can act on, and tracks the age of open findings. At Hansa Mutual the group red team of five runs quarterly purple exercises with the detection-engineering team, and the coordinator role is the named owner of the register of what came out of them. Where there is no red team, as at Nordvik Region, the coordinator is the person who commissions and receives the annual penetration test and any contracted exercise, and the role is a fraction of the detection owner's duties.

The evaluation engineer for security AI measures whether the agents and assistants of the team do what the mandates say: seeded incidents, held-out sets of closed alerts, regression tests when a model changes, and the oversight-quality metric of Chapter 14. The role matters because the person who builds or runs an agent has an interest in its looking good. AI Governance, Chapter 14, introduced the evaluation engineer for AI systems in general (62, Nordqvist, 2026); the SOC needs one who knows what a missed intrusion looks like. In a small organisation the role is held by a platform or AI team member on loan, and the independence from the agent's builder is the property to protect.

The SOC product owner owns the SOC's backlog as a product: detections, playbooks, integrations, agent mandates and the improvements that come out of the learning loop, ranked by value and risk. A SOC that sees itself as a service organisation with a queue builds a queue-shaped system, and one that sees itself as a product team with a backlog builds a system that changes. The product owner is normally the SOC lead or a member of the lead's team, and is explicitly not a manager of people.

Shapes of the team

Three shapes are in use. The pyramid has been described. A diamond has few tier 1 posts, a wide middle of analysts, investigation leads and detection engineers, and a narrow top. A flat shape has a small team of generalists who rotate through all the functions with no tiers at all.

Shape	Strength	Weakness	Fits
Pyramid	Clear ladder; cheap volume handling; established pay structures	Needs volume that automation removes; produces few engineers	A SOC with little automation
Diamond	Invests in judgement and engineering; leaves agents the volume	Narrow entry rung; needs apprenticeship by design	A large SOC with agents at Level 3 for defined classes
Flat	Everyone learns everything; no hand-offs	Little depth; fragile when one person leaves	A small team with a managed service for the night

The diamond is the shape this book's argument leads to, and the weak point of the diamond is its bottom. If the entry rung is narrow, nobody becomes a middle analyst unless somebody designs the route. The labels for the outlook matter here. Observable: triage is increasingly automated by vendors and by built agents, and this book documents the practice in the two organisations' plans; a count of how many SOCs have reduced their tier 1 posts is not available in the sources verified for this book, so no claim about the pace is made. Expected: where agents close defined classes at Level 3 under a closure policy, the volume that justified the base is gone, and the book's conclusion from Chapter 7 is that the team's weight moves to the middle. Speculation: a team with no junior analysts at all, entering the profession only as engineers, is plausible but unsupported by present evidence, and it is a risk (Chapter 23) rather than a design goal.

Conway's law explains why the shape matters beyond headcount. The system design mirrors the organisation's communication paths (Architecture as Code (Chapters 17 and 18)) (61, Nordqvist, 2025). A SOC organised in tiers with hand-offs by ticket tends to build playbooks and detections that hand off by ticket, and a SOC that puts detection engineers, investigation leads and the agent operator in one team with a shared backlog tends to build detections as code, closure classes with owners, and mandates that change with the findings. That is the book's conclusion from the principle, not a measured result. Hub-and-spoke designs scale where the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode (AI Governance, Chapter 12) (62, Nordqvist, 2026); the SOC's relationship with the platform team in this chapter takes that form.

Role charters

A role that is written in a job description is difficult to test. A role that is written as a role charter, ROLE-*, is a versioned artefact beside the code. The Transformed Security Architect, Chapter 4, defined the form: a mandate, accountabilities, decision rights with time limits, ceilings on the role's use of AI, a review date and a version, approved by a named person (66, Nordqvist, 2026). This book reuses the form for the blue team without change, adding the blue team functions each role serves and the agents each role conducts or stops. Three properties make a charter useful.

1. Decision rights are verbs with limits. "Decide" and "recommend" and "veto" are different rights, and a charter that says only "responsible for" does not distinguish them. Each right carries a time limit, because the right to decide within the shift is a different right from the right to decide within a quarter.
2. Ceilings are stated per role. A role may approve actions up to a level and no further. The ceilings are the degrees of delegation of the role: the incident commander may approve Level 2 actions, the agent operator may revoke credentials, the class owner owns a Level 3 closure class. No charter grants Level 4 Autonomous for an irreversible B4 Respond action or for an action that decides about a named person's access to work.
3. What the role may not do is part of the charter. A SOC lead's charter that forbids per-person measures of analysts' output states, in a place that a works council can read, a commitment that the tools may not be used to evaluate the analysts quietly.

Worked example: Role charter ROLE-HM-SOC-LEAD

The charter below is illustrative. ROLE-HM-SOC-LEAD is a role charter under the group SOC's team charter ROLE-HM-SOC-01 (AIDR-0772, 2027-01-26, effective 2027-02-01); it shows how Hansa Mutual's group SOC lead holds a mandate that conducts the agent team without being able to grant it more authority than the group AI governance board has given.

# Illustrative role charter, Hansa Mutual group SOC lead
role_charter:
  id: ROLE-HM-SOC-LEAD
  under: ROLE-HM-SOC-01        # team charter, AIDR-0772, effective 2027-02-01
  version: 1.0.0
  organisation: Hansa Mutual
  effective: 2027-10-01
  review_by: 2028-10-01
  approved_by: group CISO
  consulted: [Konzernbetriebsrat, Polish employee representatives]
  reports_to: group CISO
  functions: [B2 Detect, B3 Investigate, B4 Respond, B5 Learn]
  mandate: >-
    Run the group SOC on two sites and conduct its agent team so that
    every conclusion has a named person who answers for it.
  accountabilities:
    - Mandate manifests MND-HM-SOC-01 to MND-HM-SOC-05 are current
    - The delegation profile DLG-HM-SOC-01 matches what runs
    - The sum of delegations is known, measured and stoppable
    - Quarterly degraded-mode drills are run and recorded
  decision_rights:
    - decision: pause or withdraw a closure class
      right: decide
      within: same shift
    - decision: designate the incident commander for a major incident
      right: decide
      within: 15 minutes
    - decision: raise an agent above its current level
      right: recommend
      decided_by: group AI governance board
    - decision: stop any SOC agent
      right: decide
      within: immediately
  ceilings:
    own_ai_use: Level 2 Supervised
    approves_actions_up_to: Level 2 Supervised
    level_4_autonomous: not used
  conducts: [HM-SEC-001, HM-SEC-002, HM-SEC-006, HM-SEC-007, critique-agent]   # MND-HM-SOC-05
  may_not:
    - produce or request measures of output per named analyst
    - decide about a named person's access to work by tool output
  evidence: [reviews/protocol/soc-tiers.yaml, OQM-HM-SOC-01]

Worked example: Role charter ROLE-NR-SEC-DET

Nordvik Region has no detection function at the start of the book, and the charter below, also illustrative, is the first role charter the Region writes for it, under the unit's team charter ROLE-NR-SEC-01 (AIDR-0716, 2027-01-25). The holder, Karin Lund, already owns the rules in practice (AIDR-0701); the charter makes the ownership a post.

# Illustrative role charter, Nordvik Region detection engineer
role_charter:
  id: ROLE-NR-SEC-DET
  under: ROLE-NR-SEC-01        # team charter, AIDR-0716, 2027-01-25
  version: 1.0.0
  organisation: Nordvik Region
  effective: 2027-07-01
  review_by: 2028-07-01
  approved_by: CISO
  holder: Karin Lund
  reports_to: CISO
  functions: [B1 Anticipate, B2 Detect, B5 Learn]
  mandate: >-
    Own the detection content the Region runs, whoever operates the
    platform, and keep it tested, reviewed and current.
  accountabilities:
    - Detection records DET-NR-* have an owner, a test and a review date
    - Supplier default rules are taken over one at a time (AIDR-0701)
    - Weekly sample of the provider's closed alerts is reviewed (AIDR-0712)
    - One weekly hour of intelligence work is done and recorded (AIDR-0705)
  decision_rights:
    - decision: merge a detection change
      right: decide
      condition: second analyst has reviewed
      within: 5 working days
    - decision: retire a rule that has not fired in its review period
      right: decide
      within: 5 working days
    - decision: ask the provider to change a rule under annex MS-1
      right: recommend
      decided_by: CISO
  ceilings:
    own_ai_use: Level 1 Assisted
    approves_actions_up_to: Level 1 Assisted
  may_not:
    - merge own change without a second reader
    - grant a closure class above Level 2 Supervised
  cover: second analyst, named in the rota

The two charters show the difference between the organisations without declaring either better. Hansa's charter governs a team and an agent team and is mostly about who may raise and who may stop. Nordvik's governs one person, and its distinctive line is the second reader, because a single post cannot review itself.

Rotas and the night

A rota is where the roles meet the hours. The SOC works around the clock, agents act at night, and the human question is who is awake, with what authority, and for how long.

Follow-the-sun. Hansa Mutual's group SOC runs from Hamburg and the Polish service centre, with the UK entity taking the late shift. A follow-the-sun rota has the advantage that nobody works the small hours as a rule, but it creates a hand-over at each boundary, and the hand-over is a place where state is lost. The hand-over record is the case record, and the rule that every conclusion names whether a person or an agent reached it (Chapter 13) is what makes a hand-over survivable. At night the shift lead at the Polish service centre holds the right to disable a closure class, as Chapter 7 recorded.

On-call. A small team cannot follow the sun. Nordvik Region buys its out-of-hours monitoring from a managed security service provider under framework agreement NR-2025-044, and annex MS-1 fixes the paging times and the Region's ownership of detection content. The Region's own people are on call by exception, not by routine. The agent operator role is on the platform team's on-call rota, with stop right through platform on-call. This is a deliberate division: the people who can revoke an agent's credentials are the people who run the platform that holds them, and they do not need to be analysts.

Load. Whether AI reduces or intensifies on-call load and the stress of incident work is a question that Chapter 21 treats. A study of analyst burnout proposes a human capital model for mitigating it (70, Sundaramurthy et al., 2015). The design implication, stated here as the book's own conclusion and not as a finding of that study, is that a rota should be designed for the load that remains once the repetitive classes are closed. The remaining work is concentrated: fewer alerts, each harder. A team that keeps the old rota with the old thinking out of habit gets a night shift made of difficult cases and no relief.

Defaults. The following defaults are starting points to be adapted to the collective agreement, the works agreement and the organisation's risk appetite:

Item	Default
Night shift length	No longer than the national working-time rules allow, and handed over in writing
Open proposals per reviewer at night	8, as in the review protocol of Chapter 14
Agent operator reachable	Within 5 minutes by page, on the platform rota
Stop invoked	By the duty analyst or the incident commander, without asking
Degraded-mode drill	Quarterly, one agent in one shift and the team in another

The employee representatives are party to the rota, not only to the tools. In Germany a works council co-determines on tools that can monitor employees' behaviour or performance (BetrVG §87(1) no. 6), as Chapter 13 noted for SOC tooling that logs analysts' queries and actions, and on how working time is arranged (AI Boss, Chapter 23) (67, Nordqvist, 2026). That AI Boss is the only source cited here for the German statute is a limit of the bibliography; the legal adviser confirms the provision before a works agreement relies on it. The reporting rules that Hansa agreed (team level, never by analyst) apply to the rota as well.

The seams

A SOC does not stand alone. Its roles meet other teams' roles at defined seams, and the incidents that go wrong usually go wrong at a seam. The seams are the places where a handover assumes that the other side holds a right that it does not.

Seam	Blue team side	Other side	What crosses
Security architect	Detection engineer, SOC lead	Security architect	Control catalogue entries for detection and logging; the stop path and containment profile; findings from incidents
Platform engineering	Agent operator, SOC lead	Platform team	Agent identities, budgets, the policy decision point and the platform on-call rota
IT operations	Incident commander	IT operations on call	Isolation, account disablement, restore; the asset owner's exclusion tags
The business	Incident commander, SOC lead	Service owner, communication, legal	Taking a service offline; disclosure; the cost of containment

The security architect. The Transformed Security Architect, Chapter 16, drew the role map between the CISO, the enterprise architect, the AI architect, and platform and product teams (66, Nordqvist, 2026). The division of labour is short to state. The architect owns the design of boundaries, the control catalogue and the stop path as an architectural property; the blue team owns the detections that run, the operation of the playbooks and the response. The AI architect, as AI Governance, Chapter 14, concluded, owns the seams between the architecture roles and the AI-specific threats, guardrail policy and agent permissions (62, Nordqvist, 2026). The blue team feeds back what incidents show: a control that claims to detect and fails is a finding for the catalogue, as the failed logging control for the managed detections at Nordvik was. The seam works when a finding from the SOC has a named recipient in the architects' team and a time limit.

Platform engineering and IT operations. The platform team owns the agent platform and the identities on it. The risk is that the SOC treats the platform as a utility and the platform treats the SOC as a customer with no right to stop anything. The charters settle it: the operator role sits on the platform's rota and holds the stop. IT operations owns the estate on which containment acts. Isolating a host requires that the asset's owner has agreed in advance which assets may be isolated by playbook; the exclusion of assets tagged shared, executive, production or claims-settlement from the isolation playbook (Chapter 10) is that agreement written down.

The business. Taking a citizen-facing service offline or disclosing an incident is not a SOC decision, and Chapter 18 assigns those rights. For the roles in this chapter, the point is that the incident commander has a named counterpart on the business side before the incident, not a telephone number found during it.

Practical guide: Drawing the role map for your team in a day

Purpose. To produce a map of who holds which role for which function and to find the empty and double cells by testing it on real incidents.

Roles. The SOC lead facilitates; a detection engineer, an investigation lead, an agent operator and the platform on-call engineer attend; the security architect and a representative of IT operations join the afternoon; employee representatives are informed of the exercise and the output.

Steps.

1. In the morning, list the people and the roles each plays in the five functions, including the part-time roles (class owner, intelligence analyst, purple coordinator, evaluation engineer). Write one line per role: what it decides, within what time, up to which level.
2. Mark the seams to the architect, the platform team, IT operations and the business. Name the counterpart for each, by role and by person.
3. After lunch, select three recent incidents or near misses. Include at least one in which an agent or a provider's AI took part. For each, list the ten decisions that were made and find the role that held each right.
4. Mark every decision that nobody held (an empty cell), every decision two roles believed they held (a double cell), and every decision taken by a role whose charter does not grant it.
5. Write the findings as changes to the charters. Set a review date no later than 90 days ahead.

Definition of done. Every function has a named holder and a named cover; every closure class has an owner; every agent has an operator on a rota; the three incidents are traced end to end without an empty cell, or the empty cells are on the backlog with an owner and a date.

Across the degrees of delegation

Role ceilings are the degrees of delegation of Chapter 4 applied to people. The table gives the default ceilings for the roles of this chapter; an organisation adjusts them in its charters and records the reasons.

Role	May decide or approve	Ceiling and limits
Analyst on shift	Close or escalate in the residual queue; accept or reject an agent's proposal	Approves Level 2 Supervised actions only inside a playbook with a named incident commander above
Class owner	Open, pause and withdraw a Level 3 closure class	Owns the class; cannot raise its level alone
Investigation lead	Provisional closure of a case after independent reproduction; scope of forensic work	Approves Level 2 actions in an investigation
Incident commander	Approves Level 2 Supervised response actions; invokes or confirms the stop; sets communication	Level 3 playbook runs inside the approved class; Level 4 Autonomous not used for irreversible B4 Respond
Agent operator	Revokes credentials, pauses an agent, freezes write policy	Cannot raise an agent's level or widen its mandate
Detection engineer	Merges and retires detections after a second reader	Own AI use at Level 1 Assisted or as chartered
SOC lead	Pauses any class, stops any agent; designates the commander	Recommends raising a level; the authority decides

No role in the table decides about a named person's access to work by tool output. Where an alert concerns an employee's account or behaviour, a person answers, as in Chapter 7.

Nordvik Region and Hansa Mutual

Nordvik Region cannot afford a diamond. With six analysts working office hours and an MSSP at night, a team of fourteen in the unit, and public pay scales, its first move is small and concrete: it converts one analyst post into a detection-engineering post and shares an agent operator role with the platform team. AIDR-0719 (illustrative, dated 2027-06-14) records both decisions. The converted post is held by Karin Lund and written as ROLE-NR-SEC-DET above. The shared operator role (ROLE-NR-SEC-AGO-01, illustrative) is held by a named platform engineer on the platform's on-call rota with a security analyst as named alternate, and covers the Region's Level 1 assistants and the hunting query pack, where the operator's work is to hold the budgets and the right to revoke. The conversion leaves five analysts and a team that depends more on its second readers, and it keeps one entry rung, the junior post that Chapter 23 treats. The Region does not claim that this is a diamond. It claims that the roles exist and have names.

Hansa Mutual has a pyramid to reshape and a works council to agree it with. AIDR-0775 (illustrative, dated 2027-09-20) records a two-year plan from 2027-10-01 in which four tier 1 posts shift, two into detection engineering, where the team of four grows to six, and two into investigation lead roles, where the six senior analysts and leads become eight. The moves take place through vacancies and voluntary transfers with training, in consultation with the Konzernbetriebsrat and the Polish service centre's employee representatives, and are covered by the SOC annex to the group works agreement KBV-IT-2024. The plan's commitment is that no post closes until its holder has been offered a place in the new roles. Lena Vogel, the detection engineering lead in Hamburg, sets the entry requirements for the engineering posts, and Piotr Nowak, shift lead at the Polish service centre, is consulted on the investigation lead posts because the night shift depends on them. The role charter ROLE-HM-SOC-LEAD is the first to be adopted under the plan. The main risk is the opposite of Nordvik's: the detection engineers must not drown in AI-drafted rules, and two additional engineers are only worth having if the review protocol of Chapter 14 holds.

The organisations differ in leverage as they do elsewhere in the book. Nordvik's lever is the contract and the few roles it can write down, and Hansa's is the platform and the capacity to move people across a large team. Both end with charters in version control, and both can say, for each decision in a night, who held it.

Summary

The tier-1 pyramid was a response to alert volume and a school for the craft. Triage by AI removes much of the first and threatens the second. The functions of tier 1 do not disappear; they divide into closure by class, sampling and review, the residual queue, and learning about what normal looks like, and each lands in a different role. The roles that grow are the detection engineer under B2 Detect, the investigation lead under B3 Investigate, the incident commander and the agent operator under B4 Respond, and the intelligence analyst under B1 Anticipate. The new roles are the purple team coordinator and the evaluation engineer under B5 Learn, and the SOC product owner who keeps the backlog.

The shape the evidence points towards is a diamond, with the label expected, and its weak point is the entry rung. A team with no junior analysts is speculation and a risk. Conway's law applies: the way the team is organised shapes the detections, playbooks and mandates it builds.

Roles are written as charters, ROLE-*, with decision rights that carry time limits, ceilings stated per role and a list of what the role may not do. The two worked examples show a charter for a group SOC lead who conducts an agent team and for a single detection engineer who needs a second reader. Rotas are designed for the load that remains, with the agent operator on the platform's on-call rota and the right to stop cheaper than the right to continue. The seams to the security architect, the platform team, IT operations and the business are where handovers assume rights the other side does not hold, and the practical guide finds the empty and double cells by tracing three incidents.

Nordvik Region and Hansa Mutual reach charters by different routes: one converts a post, the other reshapes a pyramid with its works council. Chapter 18 turns from who holds a role to which decisions each role may take, who may isolate, disable, disclose and stop, and in what time. Chapter 22 builds the competences these roles need, and Chapter 23 the route by which a person comes to hold them.

Sources

1. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (66, Nordqvist, 2026)
2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (62, Nordqvist, 2026)
3. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (67, Nordqvist, 2026)
4. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (65, Nordqvist, 2026)
5. Nordqvist, G. Architecture as Code. (61, Nordqvist, 2025)
6. Alahmadi, B. A., Axon, L. & Martinovic, I. (2022). 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. 31st USENIX Security Symposium. (69, Alahmadi et al., 2022)
7. Sundaramurthy, S. C., Bardas, A. G., Case, J., Ou, X., Wesch, M., McHugh, J. & Rajagopalan, S. R. (2015). A Human Capital Model for Mitigating Security Analyst Burnout. SOUPS 2015. (70, Sundaramurthy et al., 2015)
8. Tariq, S., Baruwal Chhetri, M., Nepal, S. & Paris, C. (2025). Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities. ACM Computing Surveys 57(9). (72, Tariq et al., 2025)
9. ISC2 (2025). 2025 Cybersecurity Workforce Study. (73, ISC2, 2025)
10. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6). (75, Bainbridge, 1983)