Nordvik Region and Hansa Mutual: Cyber Defence Conclusions

Every chapter of this book has ended by asking how its subject plays out for two fictional organisations: Nordvik Region, a regional public authority in a Nordic member state, and Hansa Mutual, a mutual insurance group headquartered in Hamburg. This chapter draws those threads together. For each it records the starting point, the decisions across the six CSF Functions, what worked, what was hard and a 24-month plan, and then compares their CSF profiles as code.

Nordvik's question is how to use AI to stretch a small team without giving up sovereignty over security data or accountability to the public. Hansa's is how to give AI bounded autonomy at machine speed while proving to supervisors, works councils and its management body that people remain in command. Both started where the earlier volumes left them: AI is now both a target and a source of threat (72, Nordqvist, 2026) (73, Nordqvist, 2026).

The two organisations' paths from a shared starting point to the same programme shape

Figure 27.1: The two organisations' paths from a shared starting point to the same programme shape.

Nordvik Region

Starting point

Nordvik's security unit had fourteen people, of whom six were analysts working office hours. A European managed security service provider monitored the estate out of hours under framework agreement NR-2025-044, which requires processing and log storage inside the EU/EEA. Detection rules were mostly supplier defaults, and offensive testing meant an annual penetration test. The only security AI was a phishing-report classifier switched on by the email-security vendor (Mode 0), and analysts used the approved enterprise assistant (Mode 1) without pasting telemetry into it. Significant incidents were reported to the national CSIRT under the national transposition of NIS 2 (3, European Union, 2022). Its constraints were capacity, procurement lead times and public-access rules; its advantages were a single legal regime, a clear mandate and reserved, self-hosted AI capacity in a Nordic data centre.

Cyber defence decisions across the book

Govern. The regional director approved a one-page programme charter (NR-SEC-PROG-2027, Chapter 1) that caps security AI at Mode 4, offensive work at Level 2 and irreversible actions at Level 1, keeps security data inside the EU/EEA and names who can stop any capability, including the MSSP's shift lead; the risk-appetite statement of Chapter 5 turns these ceilings into tolerated error rates. Signed rules of engagement preceded the first exercise (RoE-NR-2027-001, Chapter 7), and the amended MSSP agreement bounds the provider's own AI features (Chapter 8).

Identify. The Region reconciled its AI register with discovery, including supplier-enabled AI features (Chapter 9), made threat modelling continuous for its citizen-facing services (Chapter 10) and pushed patch service levels into supplier contracts (Chapter 11). It contracted a threat-led exercise against the benefits-explanations service and the citizen-service assistant, with its own analysts as the blue team (Chapter 12), and red teams its assistants as NR-SEC-002 (Chapter 13).

Protect, Detect and Respond. Call-back verification for supplier payment changes resists synthetic media (Chapter 14), and alert data stays on reserved capacity (Chapters 15 to 17). NR-SEC-001, a Mode 4 triage assistant with a read-only identity, runs at Level 1 Assisted beside the MSSP: it drafts triage notes and an analyst decides (Chapter 18). The Region now writes and tests its own detections as code (Chapter 19), and one reporting configuration starts every applicable clock (Chapters 20 and 21).

Recover, verification and improvement. Recovery plans became code, with citizen-facing services first, and monthly AI-assisted restore drills compensate for a small team (Chapters 22 to 24). NR-SEC-004 runs twelve chaos experiments weekly in test environments with the AI planner in advisory mode (Chapter 25), and the first purple session closed the exercise's findings, among them FND-NR-2027-007, with re-test evidence (Chapter 26).

What it built first

Nordvik built the mandate before the tools, because a public authority must be able to explain to its board, its auditors and its residents why it lets AI touch security work at all. The first capability, the triage assistant, relieved the scarcest resource; the second was restore drills, because the Region had never tested whether it could meet its published recovery objectives.

What worked and what was hard

Keeping security AI at Mode 4 and below worked. Analysts trust the triage assistant because they make every decision, and its read-only identity limits a manipulated alert to a poor draft. Self-hosting removed the hardest legal question, whether alert data containing health and social-care information may leave the Region's control. Restore drills found two services whose recovery depended on an undocumented supplier step, which no audit had found.

Capacity, however, remained the binding constraint, so the Region relied on its MSSP and contracted testers. Amending the MSSP agreement took two procurement cycles. Above all, the Region found that its most autonomous security AI was not one it had built: vendor features already quarantined mail and blocked processes at what amounted to Level 3, without anyone at the Region having decided it.

A prioritised plan for the next 24 months

  1. Record the effective autonomy of every Mode 0 vendor feature that acts automatically (0–6 months).
  2. Extend the triage assistant to out-of-hours alerts with the MSSP, still at Level 1 (0–6 months).
  3. Write the remaining supplier-default detections as code and test them against the exercise's emulation data (6–12 months).
  4. Run a second threat-led exercise that includes AI-enabled techniques and tests the MSSP's stop path (12–18 months).
  5. Decide, through the security board and the regional director, whether a narrowly scoped Mode 5 capability, such as automatic session revocation for confirmed credential theft, is justified, and record the decision either way (18–24 months).

Hansa Mutual

Starting point

A group CISO in Hamburg reports to the chief risk officer, with a dotted line to the group AI governance board. The group SOC runs 24/7 from Hamburg and the Polish service centre, alongside a red team of five, a threat-intelligence cell of three, four detection engineers already managing detections as code, and an incident-response team for seven markets. The German entity had been identified for threat-led penetration testing under DORA, run under the TIBER-DE framework (2, European Union, 2022) (13, ECB, 2025). Hansa already used vendor verdicts in endpoint and email protection (Mode 0), embedded assistants in SOAR and ticketing (Mode 2), coding agents for detection engineers in isolated ranges (Mode 3), and an investigation agent, HM-SEC-001, that enriched alerts and proposed containment at Level 2 Supervised.

Cyber defence decisions across the book

Govern. The group AI governance board, chaired by the chief risk officer, decided in AIDR-0311 to let HM-SEC-001 execute two reversible containment actions, isolating a managed workstation and revoking user sessions, at Level 3 Bounded, while every other action stays at Level 2 and data deletion at Level 0 (Chapter 6). The group CSF profile HM-CSF-2027 maps every Category to DORA, NIS 2 and the UK and Swiss regimes through one control catalogue (Chapter 3), and every provider model change triggers reassessment (Chapter 8).

Identify. The red team added AI-enabled techniques to its TIBER-DE exercise (RoE-HM-2027-TLPT) and runs continuous automated red teaming as HM-SEC-004 (Chapter 12), while HM-SEC-003 red teams the claims assistant, the claims-triage agent and the IT-operations agent, including their stop paths (Chapter 13).

Protect, Detect and Respond. Agent credentials are task-scoped, short-lived and bound to the acting entity (Chapter 14), and data-residency overlays per market govern where telemetry is processed (Chapter 16). HM-SEC-001 runs as a Mode 5 agent with its own workload identity, a permission manifest and a stop path held by the SOC shift lead, the group CISO and the incident commander (Chapter 18), and HM-SEC-002 drafts detections for engineers to review (Chapter 19). One incident is routed to DORA, AI Act, data-protection and UK and Swiss reporting within hours (Chapter 21).

Recover, verification and improvement. Recovery is orchestrated across Frankfurt and the Polish service centre under DORA (Chapter 22), and the claims-triage agent can be restored with its identity, credentials and pending actions (Chapter 23). HM-SEC-006 runs AI-planned chaos experiments at Level 3 Bounded in production within working-hours windows (Chapter 25), and quarterly purple sessions tie findings to verified controls (Chapter 26).

What it built first

Hansa built control around the AI it already had before adding more. Its first decision was to give the investigation agent a workload identity of its own, a permission manifest and a stop path outside its runtime, because the July 2026 incident had shown how a capable agent in a security context can exceed its mandate (64, OpenAI, 2026); only then did the board consider bounded autonomy. The second was the group CSF profile as code, because seven supervisors ask overlapping questions and one profile, mapped to each regime, answers them from the same evidence.

Seven jurisdictions, one security operation

Reporting differs across Hansa's markets: the EU entities report under DORA, the UK and Swiss entities under their own regimes, and a serious incident involving an AI system may also fall under Article 73 of the AI Act (1, European Union, 2024). Works councils in Germany, the Netherlands and Sweden must be consulted before any tool that can monitor employees goes live, so HM-SEC-001 rolls out entity by entity. Hansa therefore answered with one baseline and per-market overlays as code, so that one control produces evidence for every regime.

What worked and what was hard

Separating identity from capability worked. Once HM-SEC-001 had its own identity and permission manifest, the board could debate specific actions rather than the agent as a whole, and approved Level 3 for two of them. Containment times for credential theft fell sharply, while a monthly chaos experiment tested the stop path. Continuous chaos engineering found silent failures that annual testing had missed, such as a log source in the Polish service centre that stopped forwarding after an upgrade.

The hardest problem was attacker-controlled input. Alert fields, email bodies and file names reach the investigation agent, and HM-SEC-003 campaigns showed that crafted content could steer its proposals. The answer was architectural, not a better prompt: the permission manifest and the policy point outside the model cap what any manipulated proposal can do. Analysts also approved some Level 2 actions in seconds, which the oversight design flags as possible rubber-stamping. Works-council consultation slowed rollout but improved the design, and the Level 3 decision remains contested: some business owners would accept more automation, while the CRO insists that every extension pass through the board.

A prioritised plan for the next 24 months

  1. Re-run HM-SEC-003 campaigns against HM-SEC-001 after every model change, and block promotion if injection thresholds are exceeded (0–6 months).
  2. Add approval-quality measures to every Level 2 action and act on rubber-stamping signals (0–6 months).
  3. Extend Level 3 Bounded to one further reversible action only if six months of Level 3 operation show no unintended containment (6–12 months).
  4. Include the HM-SEC-006 chaos platform in the next TIBER-DE exercise and test its stop path from the adversary's side (6–12 months).
  5. Bring the UK and Swiss entities into the same reporting-clock configuration and report recoverability quarterly (12–24 months).

The two CSF profiles as code

Both organisations keep their current and target CSF profiles as code (Chapter 3), summarised below by Function with the maturity scale of Appendix A.

Worked example: CSF profiles of the two organisations

# Illustrative: CSF 2.0 profiles summarised by Function, end of the book
kind: CsfProfileSummary
scale: [initial, repeatable, defined, measured]
organisations:
  - id: nordvik-region
    profile: NR-CSF-2027
    maxUsageMode: 4
    functions:
      govern:   {current: defined,    target: defined}
      identify: {current: repeatable, target: defined}
      protect:  {current: repeatable, target: defined}
      detect:   {current: repeatable, target: defined}
      respond:  {current: repeatable, target: defined}
      recover:  {current: defined,    target: measured}   # AI-assisted restore drills
    verification: {program: NR-SEC-004, environments: [test], plannerLevel: 0}
    nextDecision: narrowly scoped Mode 5 for session revocation (months 18-24)
  - id: hansa-mutual
    profile: HM-CSF-2027
    maxUsageMode: 5
    functions:
      govern:   {current: defined,  target: measured}
      identify: {current: defined,  target: measured}
      protect:  {current: defined,  target: measured}
      detect:   {current: measured, target: measured}
      respond:  {current: defined,  target: measured}
      recover:  {current: defined,  target: measured}
    verification: {program: HM-SEC-006, environments: [isolated-range, test, production], plannerLevel: 3}
    nextDecision: one further reversible Level 3 action, subject to evidence

The profiles differ in ambition but share a shape: each names the usage-mode ceiling, the verification programme and the next decision that needs evidence. Nordvik is strongest in Recover, because restore drills were cheap to automate; Hansa in Detect, because it added bounded autonomy to a mature SOC.

The two organisations compared

Question Nordvik Region Hansa Mutual
Starting point Small team, MSSP, no red team 24/7 SOC, red team, detection engineering
Legal frame One jurisdiction, public law, NIS 2 Seven jurisdictions, DORA, NIS 2, UK and Swiss regimes
Highest autonomy Level 1 Level 3 for two reversible actions
First investment Mandate, triage assistant, restore drills Identity and containment for the existing agent, CSF profile as code
Chaos engineering Weekly catalogue in test, planner advisory Continuous, AI-planned, production within limits
Binding constraint Capacity and procurement Legal fragmentation and approval quality

Across the usage modes

Mode Nordvik Region Hansa Mutual
Mode 0 Ambient AI Vendor AI found acting automatically; now documented Vendor verdicts' effective autonomy tested by chaos experiments
Mode 1 Conversational assistants Analysts only, Level 0, no telemetry All security staff, Level 0, approved tier
Mode 2 Embedded workplace assistants Ticketing pilot, Level 0 SOAR and ticketing, Level 0–1, verified summaries
Mode 3 Agentic work tools Platform team in isolated ranges, Level 1 Detection engineers and red team in isolated ranges, Level 1–2
Mode 4 Built AI applications NR-SEC-001, NR-SEC-003, NR-SEC-004 planner, self-hosted, Level 0–1 HM-SEC-002, HM-SEC-005, HM-SEC-006 planner, no estate credentials
Mode 5 Autonomous production agents None, excluded by the charter HM-SEC-001 with own identity, Level 3 for two reversible actions

Three tests for any organisation reading the pair

The comparison yields three tests that a reader can apply to their own organisation, whatever its size. These are the book's own conclusions from the two cases, not findings from an external study.

First, the mandate test: can the organisation state, in one page, the highest usage mode and autonomy level it accepts for security AI, who may change them and who holds the stop path? Nordvik passed this test with a regional director's charter and Hansa with a board decision record (AIDR-0311); neither started with a tool. Second, the inventory test: does the organisation know which vendor features already act automatically, and at what effective autonomy? Both organisations failed it at first, which is why Mode 0 heads each plan. Third, the evidence test: can the organisation show, for the control it relies on most, the last time it was tested and what the test found? Restore drills at Nordvik and chaos experiments at Hansa answer this test with dated results, not with assurances.

An organisation that fails a test has found its first piece of work. The order matters: the mandate before the capability, the inventory before the extension of autonomy, and the evidence before the claim that a Function is mature.

What each organisation can take from the other

Hansa can take from Nordvik the discipline of building the mandate first and the attention to Recover, since its recoverability reporting would be stronger with drills as frequent as Nordvik's. It can also learn that the most autonomous security AI in an estate may be a vendor feature nobody decided on.

Nordvik can take from Hansa the separation of identity from capability. If the Region ever introduces a Mode 5 capability, the decision becomes manageable when the agent has its own identity, a permission manifest, an external stop path and an action-by-action autonomy record.

Summary

Nordvik Region and Hansa Mutual reached different answers to the same questions, and the differences follow from mandate, scale and risk appetite rather than from principle. Nordvik built its mandate first, kept security AI at Mode 4 and below, and found in Recover the Function where AI changed most for a small team. Hansa built control around the AI it already had, giving its investigation agent its own identity and an external stop path, and earned Level 3 Bounded for two reversible actions.

Both share a programme shape: caps on usage mode and autonomy, rules of engagement before offensive work, red teaming of their own AI, chaos engineering, a purple loop with re-test evidence, and CSF profiles as code. Both also found the same blind spot: vendor AI that already acts automatically without anyone having decided it. Chapter 28 turns these conclusions, and those of every chapter, into a consolidated analysis.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. 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)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  4. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (13, ECB, 2025)
  5. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
  6. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  7. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)