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

This chapter describes the blue team as it works before the transformation the rest of the book follows: what it does, how it is organised around a queue, which tools carry the work, who its neighbours are and how it is measured. It defines the five blue team functions that every later chapter uses, B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn, and maps them to the Functions of the NIST Cybersecurity Framework (CSF) 2.0 and to the roles of a typical team. It concerns all five. The point of the baseline is practical: a change can only be judged against a description of what was there before, and the description has to be specific enough that Nordvik Region and Hansa Mutual can recognise their own teams in it. The chapter also separates craft from routine, because that separation is what Chapters 5 to 11 test function by function and Chapter 4 turns into degrees of delegation.

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

Figure 2.1: 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.

What defenders do

A blue team is the set of people and functions that defend an organisation: they watch, decide whether what they see matters, contain what does and change the defences afterwards. The term sits beside two others that this book keeps distinct. A red team emulates an adversary, under written rules of engagement, to test the defence. A purple team is the joint loop between the two in which a finding becomes a better detection, a better playbook or a better decision right (64, Nordqvist, 2026). The blue team is the party that owns the result.

In most organisations the blue team is not a single department. Its core is usually a security operations centre (SOC), the group of analysts who monitor telemetry and work the alerts that detections raise. Around the core sit specialists who the SOC depends on and who are sometimes inside it and sometimes beside it: engineers who write and maintain detections, analysts who read threat intelligence, an incident-response capability that leads the serious cases, and a forensic capability that preserves and examines evidence. In a small organisation one person may hold several of these roles, and in a large one each has a team of its own.

Seven roles recur, under different titles, and the later chapters use them by these meanings.

  • The security analyst works alerts and cases. Tier 1 analysts triage, tier 2 analysts investigate, and the senior analyst or investigation lead takes the cases that need judgement.
  • The detection engineer writes, tests, tunes and retires the detections that produce alerts, and answers for their quality.
  • The threat-intelligence analyst reads reports and feeds, decides what applies to the organisation and turns it into hypotheses for detection and hunting.
  • The threat hunter looks for activity that no detection has flagged, starting from a hypothesis.
  • The incident commander leads a major incident: assigns work, decides on containment with the business owner, controls communication and keeps the record.
  • The forensic examiner acquires and analyses evidence so that its integrity can be shown.
  • The SOC lead and duty manager run the rota, the queue and the escalation paths, and carry the relationship with the CISO.

Frameworks for cybersecurity roles describe the same families of work. The European Cybersecurity Skills Framework published by ENISA profiles roles such as the cyber incident responder, the cyber threat intelligence specialist and the digital forensics investigator (77, ENISA, 2022). The book does not adopt a framework's role list. It uses the functions below as its unit and treats roles as the way an organisation chooses to bundle them.

Five blue team functions

The function, not the job title, is the unit of this book. Titles differ between organisations and change with every reorganisation; the work that must be done does not. A function is useful as a unit because the questions of the transformation can be asked of it: what does it take as input, what does it produce, what is reversible, who answers for it and where does judgement enter.

The definitions

B1 Anticipate is the function of knowing what is likely to come and where the organisation is exposed. It covers threat intelligence, exposure awareness and the hypotheses that direct detection and hunting. Its output is a statement that an organisation can act on: this technique is being used against organisations like ours, this part of our estate would let it through, and this is what we should look for. Its roles are the intelligence analyst and, in part, the hunter and the vulnerability and exposure managers who work beside the blue team.

B2 Detect is the engineering, running and tuning of the detections that turn telemetry into alerts. It covers the rules, analytics and models in the security information and event management (SIEM) system and the endpoint detection and response (EDR) tooling, the data sources that feed them and the coverage they give against the techniques of MITRE ATT&CK (9, MITRE, n.d.). Its output is an alert with a defined meaning and a known cost in analyst time. Its roles are the detection engineer and, where none exists, whoever owns the SIEM.

B3 Investigate turns an alert into a verified case. It covers triage (is this real, how bad and who needs to know), scoping (how far does it reach), analysis (what happened and how) and forensics (what can be proved). Its output is a case record that says what is known, what is not and how each statement was checked. Its roles are tier 1 and tier 2 analysts, senior analysts, investigation leads and forensic examiners.

B4 Respond is containment, eradication, recovery coordination, communication and reporting. It covers the actions that stop an intrusion spreading, the removal of the adversary's access, the coordination with the teams that restore service, the communication to management and the notifications that law and contract require. Its output is a contained incident and an accurate account of it. Its roles are the incident commander, the on-call analyst who executes containment and the teams in IT operations that carry out recovery.

B5 Learn is the post-incident review, purple teaming and the improvement of detections, playbooks and mandates that follow. Its output is a change that is verified: a detection that now fires on the replayed behaviour, a playbook that now asks for a second source. Its roles are everyone, but its owner is whoever chairs the review and tracks the findings to closure.

The functions form a loop. Intelligence directs detection, detection feeds the queue, investigation produces cases, response contains them and learning feeds detection and intelligence again. Figure 2.1 shows the loop with the tiers, the tools and the neighbours that touch each step. The loop is the book's own structure, not an industry standard, and it is chosen because each function has a different relationship to time, to reversibility and to judgement, which are the three properties that decide how much of it can be delegated.

The mapping to CSF 2.0

The CSF 2.0 organises cybersecurity outcomes under six Functions: Govern, Identify, Protect, Detect, Respond and Recover (17, NIST, 2024). The blue team functions cut across these rather than coinciding with them, which is why the book needs its own names. The table gives the mapping at the level of Functions and the Categories that carry most of the work.

Blue team function CSF 2.0 Function and Categories Note
B1 Anticipate Identify, notably ID.RA Risk Assessment Intelligence and exposure feed risk assessment; the hunt hypothesis is an application of it
B2 Detect Detect: DE.CM Continuous Monitoring, DE.AE Adverse Event Analysis The engineering of detections is the means of both Categories
B3 Investigate Detect (DE.AE) and Respond (RS.AN Incident Analysis) Serves both Functions: it receives what detection produced and supplies what response needs
B4 Respond Respond: RS.MA Incident Management, RS.MI Incident Mitigation, RS.CO Incident Response Reporting and Communication; Recover: RC.RP Incident Recovery Plan Execution The blue team coordinates recovery; IT operations and platform teams execute most of it
B5 Learn Identify, ID.IM Improvement Includes the improvement of detections, playbooks and mandates

The NIST incident response profile is written against the same Functions and is the reference for how the Respond and Recover work is organised (19, NIST, 2025). Two consequences matter later. First, B3 sits in the middle of a seam between Detect and Respond in the CSF, and that seam is where much of the transformation happens, because it is where AI can reduce the volume that reaches a person. Second, the CSF is a framework, not law. The legal instruments that bear on the two organisations, NIS 2 as nationally transposed for Nordvik Region (3, European Union, 2022) and DORA for Hansa Mutual's EU financial entities (2, European Union, 2022), attach obligations to B4 in particular: NIS 2 Article 23 sets out incident notification, and DORA Articles 17 to 19 cover the management, classification and reporting of ICT-related incidents. Read as architectural implications, these mean that the reporting step of B4 needs a record that can be produced on a deadline, whatever tool produced the analysis.

Boundaries between the functions

Four boundaries are drawn in this book, and neighbouring chapters hold to them.

  1. Triage belongs to B3 Investigate, not to B2 Detect, even though the alert is the product of detection. B2 answers for whether the alert should exist; B3 answers for what it means. Chapter 7 treats this boundary in detail.
  2. Containment belongs to B4 Respond, even when it is requested during an investigation. The investigator proposes and the responder, or a playbook, acts. The separation matters because B3 reads and B4 changes the estate, and some of what it changes cannot be undone.
  3. Hunting belongs to B1 Anticipate in its hypothesis and to B3 Investigate in its execution. A hunt record carries both (Chapter 9).
  4. Vulnerability management and exposure management are neighbours, not part of the blue team, except where their output becomes a hypothesis or a detection priority.

Tiers, shifts and the queue

The SOC is organised as a pyramid around a queue. Detections raise alerts, the alerts enter a queue in the SIEM or the case-management system, and tier 1 analysts take them in order of priority. Each alert is closed, or escalated to tier 2 with the evidence gathered so far. Tier 2 investigates, closes, escalates to tier 3 or hands the case to incident response. Tier 3, where it exists, holds the most experienced analysts, who take the hard cases, hunt, support forensics and often write or review detections. The pyramid is wide at the bottom because volume is high there, and narrow at the top because judgement is scarce.

The structure carries four assumptions. The tests that follow in Chapters 5 to 11 are tests of these assumptions, so they are worth stating.

  • Volume is handled by headcount. The queue is cleared by adding tier 1 analysts or by closing alerts faster. A rising volume is met with a larger bottom of the pyramid.
  • Skill is acquired by doing the routine. Tier 1 is both the place where the queue is worked and the place where analysts learn. Chapter 23 returns to this assumption, because if the routine is automated the entry rung disappears with it.
  • The queue is the interface. Everything the team knows arrives as an alert in a queue, and anything not alerted is invisible. Hunting exists because this assumption is known to be false.
  • A person reads each alert. The SOC measures and staffs itself on the premise that every alert is seen by a human, even if only for a minute.

Coverage in time adds shifts. A 24/7 SOC runs three shifts, or a follow-the-sun rota in which sites in different time zones hand over at the end of their working day. Smaller teams work office hours and buy the rest: an on-call arrangement for the duty analyst, or an out-of-hours monitoring service from a managed security service provider (MSSP). Escalation paths define who is called, in what order and with what authority: the duty manager, the incident commander, the CISO and, where the incident may meet a notification threshold, the privacy officer and the legal function. Handover between shifts and between organisations is a known source of loss, since what an analyst knew at the end of a shift has to be written down for the next one. A qualitative study of SOC issues examines where a SOC's arrangements match or mismatch its needs, and this book follows it in treating the SOC as a sociotechnical system rather than a set of tools (71, Kokulu et al., 2019).

The picture also varies widely between organisations. The two below are not averages. They are two plausible points on the range.

Tools and data

Six kinds of tool carry the work, and the data they hold determines what the team can see and what privacy law applies to the team itself.

Tool What it holds or does Functions it chiefly serves
SIEM Collects, normalises and stores logs; runs detections; raises alerts; supports search B2 Detect, B3 Investigate
EDR Records endpoint activity; detects on it; can isolate a host or kill a process B2 Detect, B3 Investigate, B4 Respond
Case management and ticketing Holds alerts, cases, assignments, evidence references and the audit trail B3 Investigate, B4 Respond, B5 Learn
SOAR Orchestrates enrichment and response steps as playbooks across tools B3 Investigate, B4 Respond
Threat-intelligence platform Holds indicators, reports and context; exchanges them in standard formats B1 Anticipate, B2 Detect
Log pipeline Collects and forwards telemetry from identity, endpoint, network, cloud and applications B2 Detect (all functions depend on it)

Standards exist for the interchange between them. STIX 2.1 is the format in which threat intelligence is exchanged between platforms, and TAXII 2.1 the protocol that carries it (22, OASIS Cyber Threat Intelligence (CTI) TC, 2021). Sigma is an open format for describing detections in a way that converters translate to the query language of a particular SIEM (27, SigmaHQ, n.d.). Both matter here because they are the form in which B1 and B2 can become code, which is the theme of Chapters 5 and 6. In the baseline, however, many teams keep their detections inside the SIEM as configuration that nobody has exported, and their playbooks as pages in a wiki.

The data deserves its own attention. Security telemetry is not neutral. Logs of authentication, email, web access and endpoint activity record what named people did, and in a public authority or an insurer they also contain what citizens, claimants and patients did. A mailbox alert may quote a subject line; a case record may include a claimant's health information; an endpoint log records an employee's browsing. Three consequences follow for the baseline.

  1. The SOC processes personal data on behalf of the controller and needs a lawful basis, retention limits and access control. GDPR Article 32 requires appropriate security of processing, and the SOC's own data is within it (8, European Union, 2016).
  2. A security tool that can monitor employees' behaviour engages employee representation. In Germany the works council co-determines such tools under the Works Constitution Act, which Hansa Mutual's agreement with the Konzernbetriebsrat reflects. Chapter 19 treats the legal frame; here the point is that the tools the team uses to watch the estate can also watch the team.
  3. Where the data sits decides what a model may be given. The location of the log pipeline, the SIEM and the case store decides whether an AI capability can be introduced without moving restricted data, which is why Nordvik Region prefers self-hosted capacity for alert data.

Neighbours and handovers

The blue team does not act alone and cannot. Most of its decisions need the authority of someone outside it, and most of its containment actions are carried out in systems that others own.

  • IT operations and platform teams own the systems the blue team isolates, patches and restores. A containment action that is safe in a SOC console may take down a production service; the handover agreement states who may do what to which classes of asset and who is called when the answer is not clear.
  • The privacy officer decides, with legal advice, whether an incident involves a personal data breach that must be notified to the supervisory authority. GDPR Articles 33 and 34 set the notification duties, and the European Data Protection Board's guidelines on breach notification explain how the controller's awareness is to be understood (79, EDPB, 2023). The blue team's contribution is a timeline that the privacy officer can rely on.
  • Providers, including the MSSP, the SIEM vendor and the EDR vendor, hold part of the function by contract. Where the provider closes alerts, the provider is carrying out part of B3 Investigate on the organisation's behalf, and the contract is the control.

The CISO, legal and communications, the business owner of a system and the national CSIRT and competent authority complete the circle: they decide on declaring a major incident, speak to regulators and the public, know what an outage costs, and receive the reports that NIS 2 and DORA require, which the blue team supplies the facts for.

These handovers matter for the transformation because AI changes one side of each of them. When an agent proposes containment, the IT operations team receives a different kind of request; when an assistant drafts a notification timeline, the privacy officer needs to know how it was produced. Chapter 10 returns to the response handovers and Chapter 16 to the contracts.

How the work is measured

The measures a SOC reports are few and have remained stable for years. They are useful, and they carry incentives that the transformation will expose.

Measure What it is What it rewards if used alone
Mean time to detect (MTTD) Time from the start of malicious activity to its detection Broad, early detections; it is also easy to improve by redefining when the clock starts
Mean time to respond (MTTR) Time from detection to containment or resolution Speed of action; it does not distinguish a correct containment from a hasty one
Alert volume Alerts raised per period Nothing directly; it is the load the team carries
Closure rate and time to close Share of alerts closed, and how fast Closing quickly, including closing without reading
False-positive ratio Share of alerts judged not to indicate malicious activity Pruning detections, including those that would catch the rare real event
Escalation rate Share of alerts passed up a tier Analysts who escalate little or a lot, depending on how it is read
Coverage Share of relevant ATT&CK techniques with a detection Writing detections to fill a map

The first, second and fifth are the programme metrics that Architecture as Code (Chapter 9B) names for security operations: mean time to detect, mean time to respond and the false-positive ratio (61, Nordqvist, 2025). They are sound as indicators of the programme and weak as measures of the people, because each can be improved without the team becoming better at defence. A team that closes alerts faster improves its closure rate and its time to respond; whether it made fewer mistakes is a different question. The term false positive hides a distinction that practitioners draw between an alert that is wrong and one that is accurate but benign, and the research literature on alert fatigue treats the volume of alerts as a problem of its own (69, Alahmadi et al., 2022) (72, Tariq et al., 2025). Chapter 3 takes up volume. Chapter 7 shows how the distinction changes what an AI is asked to do.

Each measure in the table counts speed, volume or coverage, and none counts the quality of a judgement. When AI makes closing and acting cheap, the numbers can improve while the thing they were meant to indicate does not. Which measures show the quality of a blue team's judgement is the question Chapter 20 takes up; this chapter concludes only that the baseline measures describe throughput.

Two further points on measurement belong in the baseline. First, measures that are reported by name become measures of people, with the effects on behaviour and wellbeing that follow; the unions at Nordvik Region have negotiated that closure rates and similar measures are never reported by name, and the Konzernbetriebsrat at Hansa Mutual co-determines tools that log analysts' actions. Second, analyst burnout has been studied as a human-capital problem for the organisation to manage and not as a personal failing (70, Sundaramurthy et al., 2015). The baseline measures say nothing about this, and Chapters 21 to 23 do.

Craft and routine

Every function contains both craft and routine, and the transformation is, at root, a redistribution between them. The terms are used in a plain sense. Routine is work that follows a known procedure, is repeated in the same form and can be checked against a rule. Craft is work in which the right action depends on judgement about a situation the procedure did not foresee, and where an expert's choice differs from a novice's in ways that can be seen only afterwards.

Function Mostly routine Mostly craft
B1 Anticipate Collecting reports and feeds; normalising indicators; matching indicators to the estate Deciding what applies to this organisation and why; forming a hunt hypothesis
B2 Detect Onboarding a log source; translating a rule to a query language; closing a stale rule Deciding what behaviour to detect and at what cost; tuning against the organisation's own normal
B3 Investigate Enriching an alert; looking up an account or a host; assembling a timeline; writing the first summary Forming and separating hypotheses; deciding what is not yet known; reading an adversary's intent from partial evidence
B4 Respond Executing an agreed containment step; sending a status update; completing a notification form Choosing between containment and observation; weighing the business cost of an outage; leading people under pressure
B5 Learn Collecting the timeline; drafting the review; filing the findings Finding the cause beneath the cause; deciding which change is worth its cost

The table is a first judgement, not a measurement, and the later chapters revise it function by function. It is also not a verdict on people. Routine work is done by skilled people, and a large part of becoming a good analyst is learning, through repetition, what normal looks like. The book's working hypothesis, tested function by function in Chapters 5 to 11, is narrower: the left-hand column is the part that is delegated first, with the checks the series prescribes, and the right-hand column remains a person's. Treat it as expected, not established. Whether that division is stable, and what it does to the people who learned through the left-hand column, are the questions of Chapters 4, 18 and 23.

Practical guide: Mapping a team's work

The guide produces the function map for a team, the first artefact of the book. It can be done in a day by the SOC lead with the people who do the work, and it should be repeated whenever the team or its tools change.

Roles. The SOC lead (or the senior analyst in a small team) owns the map. Analysts, the detection engineer and the intelligence analyst, where they exist, contribute. The CISO reviews. Where a provider holds part of a function, its account manager contributes.

Steps.

  1. List the five functions as the rows of the map.
  2. For each function, name the person or provider who performs it today, including cases where the answer is one person with several roles or a supplier. If nobody performs it, record that it is unowned; this is a finding, not an omission.
  3. Record the tools that carry the function and where the data sits, including any location outside the organisation's jurisdiction.
  4. Record the tier or role at which the work is done and the hours it is covered.
  5. Mark the parts of the function that already run without a person reading, whether they are vendor features, SOAR playbooks or a provider's own processes, and name who agreed to them. These are the Mode 0 and automation baseline.
  6. Mark the current measures for the function and who sees them.
  7. Mark, with a short reason, the parts that you judge to be craft.
  8. Store the map in version control, review it with the CISO, and give every row a review date no more than six months ahead.

Definition of done. Every function has a named owner or an explicit "unowned" with a plan; every automation that closes or acts without a person reading has an owner and a record of who accepted it; and the map is in the repository where the delegation profiles of Chapter 4 can refer to it.

Worked example: A function map as code

The map below is illustrative. It is stored as team/function-map.yaml and shows two rows of Nordvik Region's map and the corresponding rows of Hansa Mutual's, in the form that Chapter 4 extends into delegation profiles. Headcounts and owners agree with the organisation profiles; the dates are illustrative.

# team/function-map.yaml (illustrative)
reviewed: 2026-11-30
next_review: 2027-05-31
organisations:
  nordvik-region:
    functions:
      B1-anticipate: {owner: unowned, plan: part-time intelligence role, decided in Chapter 5}
      B2-detect:
        owner: Karin Lund (senior security analyst, in practice SIEM owner)
        tools: [siem-service, edr]
        detections: supplier default, few local rules
        engineering_function: none
        automation_without_reader:
          - name: phishing-report classifier in email gateway
            mode: Mode 0 Ambient AI
            accepted_by: not recorded
        measures: [alert volume, false-positive ratio]
      B3-investigate:
        owner: security unit (six analysts, office hours)
        out_of_hours: MSSP under framework agreement NR-2025-044
        automation_without_reader:
          - name: MSSP closes low-severity alerts out of hours with its own AI
            mode: Mode 0 Ambient AI
            accepted_by: not recorded
            rule_stated_in_contract: false
        measures: [closure rate, time to close]
      B4-respond: {owner: unowned, plan: named incident commander and isolation playbook}
      B5-learn: {owner: unowned, plan: review after every significant incident}
  hansa-mutual:
    functions:
      B1-anticipate: {owner: threat-intelligence cell (3), tools: [intel-platform]}
      B2-detect: {owner: detection-engineering team (4), tools: [siem, edr], detections: managed as code}
      B3-investigate:
        owner: group SOC, tiers 1 to 3 (about 38 people)
        coverage: Hamburg, Polish service centre, UK late shift
        tools: [siem, soar, case-management]
      B4-respond: {owner: incident-response team, execution: SOC and IT operations}
      B5-learn: {owner: group SOC lead, exercises: quarterly purple sessions with the red team}

The point of the example is Nordvik Region's accepted_by: not recorded and its three unowned functions: the map shows, before any transformation begins, an automation that closes alerts and that nobody agreed to on the Region's behalf, and three functions that no one holds by name.

Across the usage modes

AI is already in the baseline, usually unannounced. The series' usage modes describe how it is deployed and whose identity it uses (AI Governance and AI Platform and Security, Chapter 2) (62, Nordqvist, 2026) (63, Nordqvist, 2026). Mode 0 Ambient AI is AI the organisation did not choose or switch on: it is a feature of a product or a service. The baseline of a blue team is largely Mode 0, and AI Red Team, Chapter 8, shows why it matters that this mode is not an acquisition decision but a property of what was bought (64, Nordqvist, 2026).

Function Where Mode 0 already sits in the baseline Where the other modes are not yet present
B1 Anticipate Ranking and de-duplication in the intelligence platform; vendor-supplied relevance scores Conversational and agentic use by analysts (Modes 1 to 3)
B2 Detect Behavioural and statistical models in EDR and SIEM; the phishing classifier in the email gateway Detection drafting by assistants or agents
B3 Investigate Alert grouping and risk scoring in the SIEM; the MSSP's closure of low-severity alerts out of hours Investigation assistants and agents
B4 Respond Automated isolation rules in EDR; SOAR playbooks that do not use a model Agentic proposals of containment
B5 Learn Little Drafting of reviews and tracking of findings

Two observations follow. The Mode 0 features are the baseline the delegation profiles of Chapter 4 begin from, and in the two illustrative organisations they are the part nobody decided. And the table shows that in the baseline the functions with the most Mode 0 behaviour are those closest to the queue, B2 and B3, which is also where Chapters 6 and 7 find the first large changes. The usage mode says how the AI is deployed; the autonomy level, Level 0 Advisory to Level 4 Autonomous, says who decides each action (64, Nordqvist, 2026). Chapter 4 sets the levels per function and action class. The baseline here has no levels, because most of what runs has never been given one.

The claim that the five functions are the right unit for delegation is the book's own conclusion, drawn from the observation that they differ in reversibility and in how far a mistake propagates. It is tested in Chapters 4 and 18, and Chapter 28 states what remains of it.

Nordvik Region and Hansa Mutual

The two organisations start in the same autumn from different places, and the function map shows it.

Nordvik Region's security unit of 14 has six security analysts who work office hours, and out-of-hours monitoring comes from a European MSSP under framework agreement NR-2025-044. The SIEM is a procured service whose detections are mostly the supplier's defaults, and Karin Lund, the senior security analyst, in practice owns it and its few local rules. There is no detection engineering, no intelligence analyst and no hunting practice. B2 Detect is largely the supplier's. B3 Investigate is shared between a small in-house team by day and a provider by night, and the provider's AI closes a class of low-severity alerts without a rule that the Region has seen. The unit's other eight posts cover governance, identity, policy, the security architect and the annual penetration test. B2 and B3 are therefore partly owned by someone, while B1, B4 and B5 are owned by nobody in a sense that could be written down.

Hansa Mutual's group SOC runs 24/7 from Hamburg and the Polish service centre, with a UK entity covering the late shift, and has about 38 people: 22 analysts, six senior analysts and investigation leads, a duty manager per shift and a SOC lead. It sits beside a threat-intelligence cell of three, a detection-engineering team of four that manages detections as code, and an incident-response team that leads major incidents across the seven markets. The group red team of five runs quarterly purple exercises with the detection engineers. Every function has an owner, and the pyramid is a real one. Hansa's risks are different: a rota to maintain across two countries, seven legal regimes, a works council that co-determines tools that can monitor analysts, and an investigation agent that already acts.

Both receive the same question in the autumn of 2026. At Nordvik the regional director asks the CISO what the unit becomes when AI enters its work, before the 2027 budget is set, and the commission is recorded as AIDR-0700. At Hansa the executive board asks the group CISO to show how the SOC will work when its agents act at night and when adversaries use AI, recorded as AIDR-0750. The function map is where each organisation begins to answer.

Summary

The blue team defends an organisation through five functions. B1 Anticipate knows what is coming and where the organisation is exposed; B2 Detect engineers the detections that turn telemetry into alerts; B3 Investigate turns an alert into a verified case; B4 Respond contains, eradicates, coordinates recovery, communicates and reports; and B5 Learn turns each incident and exercise into a verified change. The functions cut across the CSF 2.0 Functions, with B3 serving both Detect and Respond, and the legal duties of NIS 2, DORA and GDPR attach most heavily to B4.

The baseline organises these functions around a queue and a pyramid of tiers, on shifts or on call, with a SIEM, EDR, case management, SOAR and a threat-intelligence platform as tools and security telemetry that contains personal data. The structure assumes that headcount handles volume, that skill is learned on the routine, that the queue is the interface and that a person reads each alert. The measures it reports, mean time to detect and respond, alert volume, closure rate and the false-positive ratio, describe throughput and not the quality of judgement. That is the opening of the measurement question for Chapter 20.

Each function mixes craft and routine, and the redistribution between them is the core of the transformation. The function map is the first artefact of the book: it names who performs each function, with which tools, which parts already run without a reader and who agreed to them. For Nordvik Region it shows a small hybrid team in which several functions have no owner and an unseen provider automation; for Hansa Mutual it shows a full pyramid with an owner for every function. Chapter 3 turns from the baseline to the pressures that are changing it: adversaries at machine speed, the volume of alerts and the scarcity of talent.

Sources

  1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. (17, NIST, 2024)
  2. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
  3. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST SP 800-61 Rev. 3, April 2025. (19, NIST, 2025)
  4. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). 2022. (2, European Union, 2022)
  5. 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). 2022. (3, European Union, 2022)
  6. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (GDPR). (8, European Union, 2016)
  7. European Data Protection Board (2023). Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0. (79, EDPB, 2023)
  8. SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. (27, SigmaHQ, n.d.)
  9. OASIS Cyber Threat Intelligence (CTI) TC. STIX Version 2.1 and TAXII Version 2.1. 2021. (22, OASIS Cyber Threat Intelligence (CTI) TC, 2021)
  10. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF) Role Profiles. (77, ENISA, 2022)
  11. Nordqvist, G. (2025). Architecture as Code. (61, Nordqvist, 2025)
  12. Nordqvist, G. (2026). AI Governance. (62, Nordqvist, 2026)
  13. Nordqvist, G. (2026). AI Platform and Security. (63, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Red Team. (64, Nordqvist, 2026)
  15. Kokulu, F. B. et al. (2019). Matched and Mismatched SOCs: A Qualitative Study on Security Operations Center Issues. ACM CCS 2019. (71, Kokulu et al., 2019)
  16. Alahmadi, B. A., Axon, L. & Martinovic, I. (2022). 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. USENIX Security 2022. (69, Alahmadi et al., 2022)
  17. Tariq, S. et al. (2025). Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities. ACM Computing Surveys 57(9). (72, Tariq et al., 2025)
  18. Sundaramurthy, S. C. et al. (2015). A Human Capital Model for Mitigating Security Analyst Burnout. SOUPS 2015. (70, Sundaramurthy et al., 2015)