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

Every blue team sits inside an operating model, a decision about which of its work is done by the organisation's own people and which is bought. AI changes that decision in three ways: it lowers the cost of the repetitive work that providers sell, it removes the volume that justified a large in-house shift, and it adds a party to the arrangement, the provider's AI, which may act on the customer's behalf at a level of autonomy nobody on the customer's side has decided. This chapter describes the operating models open to a European enterprise or public authority, what must stay in-house whichever model is chosen, how the provider's AI is made visible by contract, and how regulation, sovereignty, procurement and exit shape the arrangement. It concerns all five blue team functions: B1 Anticipate, because intelligence is often bought; B2 Detect, because detection content and its ownership are the first thing a contract either secures or loses; B3 Investigate, because the case record must outlive the provider; B4 Respond, because decision rights for containment cannot be outsourced with the monitoring; and B5 Learn, because a provider's findings must reach the customer's learning loop.

The chapter builds on three conclusions of the earlier volumes. AI Red Team, Chapters 8 and 28, concluded that vendor AI in security products and managed services is the Mode 0 blind spot: it may already act at an autonomy nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on (64, Nordqvist, 2026). AI Platform and Security, Chapter 13, concluded that digital sovereignty is a set of verifiable properties and not a location: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails (63, Nordqvist, 2026). AI Governance, Chapter 6, treated model origin as a risk question separate from hosting, decided by a risk-tiered position that is reviewed rather than set once, and Chapter 12 of the same volume showed that organisational design is architecture by other means, so that the shape of an organisation appears in the shape of its systems (62, Nordqvist, 2026).

Figure 16.1: Four operating models with the retained decision rights, the provider's AI and the exit path marked.

Four models

The purpose of this section is to name the models, so that the later sections can say what each retains and what each puts at risk.

In-house. The organisation employs the analysts, detection engineers and incident commanders, runs or contracts the tooling, and owns every function end to end. It buys products, not people. The SOC of Hansa Mutual is the example: about 38 people across Hamburg and the Polish service centre on a follow-the-sun rota with a UK late shift. In-house gives full control of detection content, case records and decision rights, and it asks for scale: the rota has to be staffed around the clock, and the skills have to be hired and kept.

Managed security service provider (MSSP). The provider operates monitoring on the customer's behalf, usually on the provider's own platform, and pages the customer for what it judges to need attention. The service is defined by hours covered and by the escalation it owes. Nordvik Region buys out-of-hours monitoring in this way under framework agreement NR-2025-044.

Managed detection and response (MDR). The provider adds response to monitoring: it triages, investigates and takes defined containment actions, usually with an agent on the customer's endpoints. The line between the two is commercial more than technical. What matters here is what they share: the provider triages the customer's telemetry and, increasingly, does so with its own AI.

Hybrid. The organisation keeps some functions and buys others. One split keeps detection content, the incident commander role and the case record, and buys round-the-clock monitoring and first triage (Nordvik Region). Another keeps the home markets in-house and buys managed detection where local law makes it sensible (Hansa Mutual, for its UK and Swiss entities).

Two variants cut across the four. A follow-the-sun model spreads a team over sites in different time zones so that the night shift is somebody's day, trading the cost of night work against the cost of coordination and of telemetry and case data moving between jurisdictions. A sovereign variant requires processing and storage inside a stated jurisdiction, a provider subject to its law and a tested ability to move. Any of the four models can have or lack that property.

An operating model is organisational design, and organisational design is architecture by other means (62, Nordqvist, 2026). A model that keeps detection content in the provider's platform produces a detection estate that only the provider can read, whatever the contract says about ownership; one that keeps the case record on the provider's ticketing system produces investigations the customer cannot reproduce.

What AI changes

The purpose of this section is to say which parts of the choice AI moves and which it leaves alone.

The first change is on the supply side. A provider that serves many customers can train, evaluate and operate one set of models over the telemetry of all of them, and can spread the cost of evaluation, of red teaming its own agents and of keeping them current over a large base. For repetitive work, in particular the closure of low-risk alert classes and the first enrichment of an alert, this is an economy of scale that a single organisation with six analysts cannot match. It raises the question of what a customer is then buying: hours of attention from people, or the output of a model that people supervise. The contract should say which, because the answer decides what the customer can ask to see.

The second change is on the demand side. The tier-1 work that once justified a large in-house shift is the work AI closes first (Chapter 7), which shifts the in-house case from volume to judgement. The reasons to buy a function are availability around the clock, scale in the models and breadth of telemetry across customers; the reasons to keep one are in the next section.

The third change is that the provider's AI adds an unrecorded delegation. When an organisation's own analyst closes an alert, the case record shows who. When the provider's AI closes it, the customer sees a line in a handover list, as in CASE-NR-0231 of Chapter 7, where every step carried the field delegated_by: none recorded. The operating model has not removed the delegation; it has moved it to a place where the customer cannot read it. Bainbridge's observation applies with extra force: automation leaves people the residual tasks and removes the routine practice that kept them able to do them (75, Bainbridge, 1983). If the provider's AI takes the routine alerts, the customer has outsourced its learning ground along with its queue (Chapter 23).

How far this goes is a question about the future, and the three labels apply. That hybrid models, in which the customer keeps content and decision rights and buys round-the-clock monitoring, are in use at European public authorities and enterprises today is observable, and the two organisations of this book are examples. That providers will operate AI that acts at Level 3 Bounded across many clients, within playbooks the provider defines, is expected: vendor AI is already embedded in managed services at an effective autonomy nobody decided, as AI Red Team, Chapter 8, recorded (64, Nordqvist, 2026), and the Five Eyes agencies' guidance on the careful adoption of agentic AI services treats the adoption of agentic AI services as a present security question (35, Five Eyes agencies, 2026). A fully autonomous managed SOC, with no named human decider and sold to organisations that cannot inspect it, is speculation. This book's conclusion is that such an arrangement could not meet the duties of NIS 2 Article 20 or DORA Article 5, because no named person could answer for it.

What must be kept

The purpose of this section is to list what stays with the organisation whichever model it chooses, and to give the reason for each item.

Detection content. The organisation owns the logic of its detections, in a repository, with identifiers, versions, owners and tests (Chapter 6). A detection that exists only as a provider default is declared, not verified, in the coverage map. Ownership matters for two reasons. The organisation cannot test or explain what it cannot read, and when it leaves a provider the detections must leave with it. The Transformed Security Architect, Chapter 9, recorded the managed provider's detections in Nordvik's control catalogue as failed, because the Region could not show that they ran (66, Nordqvist, 2026).

Decision rights for containment and disclosure. The incident commander is the named human decider (Chapter 10), and the decision rights for isolation of production hosts, the disabling of accounts and disclosure sit with the organisation (Chapter 18). A provider may propose, and may execute a narrow playbook that the organisation has codified and enforces at its own policy point, but the organisation cannot delegate the accountability for an action that can stop its business.

The case record. The verified account of what happened, with its provenance, evidence references and the actor and level of each step, is the organisation's record, in the organisation's repository, subject to its archive and disclosure rules (Chapter 7). For Nordvik Region, public-access rules make a case record in a provider's system a document the Region must be able to produce.

The ability to leave. An organisation that cannot switch a provider off without losing its detections, its history and its monitoring has a dependency and not a service. Leaving is designed in, as the exit section describes.

Enough skill to supervise. An organisation must keep people who can read a provider's output critically, sample its closures and run a manual queue when the provider fails. A team that cannot triage a sample cannot check the provider; the quarterly degraded-mode drill of Chapter 13 applies to a managed service as to an agent team.

The same list can be read as a table of who does what in each model.

Function and artefact	In-house	MSSP or MDR	Hybrid (Nordvik pattern)
B1 intelligence and hypotheses	Own cell or analyst	Provider's feed, often undisclosed in origin	Own, with the provider's feed as one input
B2 Detect: detection content	Own repository	Provider's platform	Own repository for rules that matter, adopted one at a time
B2 round-the-clock monitoring	Own rota	Provider	Provider, to the customer's policy
B3 first triage and closure	Own analysts and agents	Provider's analysts and AI	Provider, by classes the customer has approved
B3 case record	Own	Provider's system	Own
B4 containment decision	Incident commander	Provider proposes or acts under playbook	Incident commander; provider executes a narrow playbook
B5 post-incident review	Own	Provider's report	Own, with provider findings entered in the register

The provider's AI

The purpose of this section is to turn the Mode 0 blind spot into terms that a contract can carry and a team can check.

The Mode 0 problem has three parts. The customer does not know which of the provider's AI acts, on which action classes, at what level. It cannot test it, because the provider's platform is not the customer's. And the provider can change it without telling the customer, since a model update is, from the provider's side, product maintenance. A contract silent on all three leaves the customer with a closure policy it did not write.

An auditable contract needs terms that answer each part. Chapter 7 listed the duties triage requires of a provider: a class list, evidence to close, sampling, seeding rights, notice of model change and a stop right. Chapter 15 listed what a security AI supplier owes the SOC's defence: levels and actions, quarterly samples, notice of change, location, retention and training, controls with a right to audit, a stop path and an exit plan. Chapter 6 added provenance, logic access, tuning rights and test rights for detection content. The requirement set of AIDR-0722 is the Region's statement of these duties; annex MS-2 to NR-2025-044 groups the same content into six contract terms, so that a contract manager can hold six things in mind and a team can test six things.

1. Levels and actions. The classes of alert the provider's AI may close and the actions it may take, each at a stated autonomy level, with an explicit list of what it may never do. A new class or a higher level needs notice and the customer's agreement. The customer holds a stop right outside the provider's platform.
2. Quarterly sampling. A defined number of closed items per class each quarter, returned to the customer with the evidence and reasoning the provider used, and a quarterly report of the provider's own escape findings.
3. Audit rights. The customer's right to audit the service, including the location of processing, subprocessors, retention and any use of the customer's data to train models, and the competent authority's access to the same.
4. Evidence. For every closure or action, a record in agreed fields that names the class, the level, the model or rule version and the evidence that supported it, delivered to the customer and retained for a stated period.
5. Tuning and test rights. Provenance and logic access for the detections that run, the customer's right to suppress, narrow or add exceptions under its own version control, and the right to inject authorised, seeded incidents and receive the result.
6. Notice of model change. 20 working days' notice before any model, rule or threshold that affects closure or action changes, with a shorter, after-the-fact notice for emergency security changes.

The class list and the stop right of Chapter 7 are term 1; its sampling is term 2 and its evidence to close is term 4. Its seeding rights join the provenance, logic access, tuning rights and test rights of Chapter 6 in term 5. The notice of model change is term 6, and the location, retention, training, controls and audit items of Chapter 15 are term 3. Conditions that apply to all six terms, among them data protection, processing location, the provider's notice of its own incidents and exit, sit in a conditions block and not in a seventh term.

Practical guide: Writing the annex that makes a provider's AI visible

Purpose. Produce an annex to an existing managed-service agreement that states what the provider's AI does, lets the customer check it and gives notice of change.

Roles. The CISO sponsors the annex. The senior security analyst or detection owner writes the technical terms and owns the sampling. The procurement lead and the legal adviser check the annex against the framework agreement and the procurement rules. The data protection officer reviews the data terms. Employee representatives are informed where the annex creates logs of analysts' work. The provider's service manager and security lead negotiate.

1. Establish the facts first. Ask the provider in writing which AI acts in the service, on which classes, with what actions, at which model version, in which location. Record the answer, or its absence, as a finding. Do not negotiate from an assumption.
2. List the classes and set the level for each. Start from the classes the provider already closes. Give each a level: Level 3 Bounded only for a narrow, reversible class whose evidence to close is stated in fields; Level 1 Assisted or Level 2 Supervised otherwise. Write the never-list: servers, accounts, citizen-facing or claims-settlement services, and disclosure. Level 4 Autonomous does not appear.
3. Name the evidence to close. For each class, state the fields that must support a closure, taking them from the failures of the last year. A closure that rests on a classifier score alone is the pattern of CASE-NR-0231.
4. Set the sample. Default: at least 100 closures per class per quarter, or all if fewer, returned within 5 working days with the provider's evidence. The customer's own weekly draw from the handover list continues.
5. Write the notice period. Default: 20 working days before a change to a model, rule or threshold that affects closure or action, with the customer able to ask for the previous version to remain in force during the period. An emergency security change may take effect at once, with notice within 2 working days.
6. Write the stop right. The customer can order closure by class to cease and alerts to be escalated to a person, by written instruction to a named address, and can revoke the provider's credential in the customer's own console. State a target (default 15 minutes, the budget for stopping the provider's AI; it is not the Region's own out-of-hours stop budget of Chapter 18) and test it once a year out of hours.
7. Write the audit and data terms. Location of processing and storage, subprocessors, retention, no training on the customer's data without written consent, and access for the competent authority.
8. Write the exit schedule. What returns, in what format, by when, and the day-one runbook the customer follows when the service stops.
9. Check against the framework agreement and the procurement rules before signing.

Definition of done. The annex is signed; every class has a level, a named owner on the customer's side and evidence fields; a first sample has been drawn and reviewed; the stop right has been exercised once; and the decision record names who accepted the residual risk. Adapt the defaults to the volume of alerts, the contract's price structure and the organisation's risk appetite. Send the provider the written question of step 1 this week.

Worked example: Annex MS-2 to NR-2025-044

The annex below is illustrative. It shows the six terms and the conditions block as a machine-readable schedule that the Region keeps beside the contract. The effective date is the target of the draft: the negotiation of model-change notice was not finished at the time of drafting (Chapter 26), and the signed annex is expected by 2028-03-31 (Chapter 27).

annex: MS-2
agreement: NR-2025-044
customer: Nordvik Region
effective: 2027-07-01          # illustrative; target of the draft, in force on signature (expected by 2028-03-31)
decision_record: AIDR-0718
review_by: 2028-01-15
terms:
  levels_and_actions:
    classes:
      MS2-C1: {action: close reported bulk mail, level: Level 3 Bounded}
      MS2-C2: {action: close scanner noise on public hosts, level: Level 3 Bounded}
      MS2-ISO: {action: isolate end-user workstation, playbook: PBK-NR-ISOLATE-01, level: Level 3 Bounded}
      other: {action: summarise and page on-call manager, level: Level 1 Assisted}
    never: [servers, accounts, citizen-facing services, disclosure]
    new_class_or_level: customer agreement in writing
    stop: {by: written instruction or credential revocation, within_minutes: 15, drill: yearly out of hours}
  quarterly_sampling:
    minimum_per_class: 100
    return_within_working_days: 5
    provider_escape_report: quarterly
  audit_rights:
    customer_audit: yearly and after a significant incident
    competent_authority_access: true
    subprocessors: listed and notified
  evidence:
    record_fields: [class, level, model_version, rule_version, evidence_refs, time]
    MS2-C1_close_requires: [url_verdict, gateway_click_log_zero, sender_not_in_protected_groups]
    retention_months: 12
  tuning_and_test:
    provenance_and_logic_access: machine-readable list of active detections
    local_suppressions: kept in customer repository
    seeded_incidents_per_class_per_quarter: 5
    seeds_treated_as_incidents: false
  model_change_notice:
    working_days: 20
    emergency_security_change: notice within 2 working days
conditions:
  processing_and_storage: EU/EEA only
  provider_ai_training_on_customer_data: false
  siem_embedded_assistant: off until provider states location, retention and own AI use
  provider_incident_notice: {to: named reporting roster, within_hours: 4}   # lets the customer's reporting clocks start
  exit: {returns: [detections, case records, log copies], within_days: 30, switch_off_test: yearly}

Three features carry the lessons of the Region's own case. The evidence to close for bulk mail includes the gateway click log, because the closure of CASE-NR-0231 rested on a sender-reputation score while the click log showed that a recipient had clicked. The level of the isolation action matches Chapter 10, where the provider's AI may isolate an end-user workstation under PBK-NR-ISOLATE-01 and nothing more, the isolation policy being owned in the Region's console. And the SIEM provider's embedded assistant stays off, as Chapter 12 recorded, until the provider has stated where it processes data, how long it retains it and how it uses AI itself.

Regulation and third-party risk

The purpose of this section is to show what the law asks of the arrangement, as an architectural constraint and not as legal advice. Chapter 19 treats the reporting clocks; this section treats the supplier.

For the financial entities of Hansa Mutual, DORA is the primary regime and makes the dependence on an ICT third-party provider a matter of governance. Its rules on ICT third-party risk include a register of information on contractual arrangements, contractual requirements for the services a provider supplies, and exit strategies for services that support important functions (2, European Union, 2022). A managed detection service that is not in the register is outside the organisation's own risk view, and the contract must carry terms close to the six of MS-2: rights of access and audit, defined service levels, data location, and an exit with a transition period. The management body, not the SOC, answers for the arrangement (DORA Article 5), which is why Hansa's group AI governance board and the executive board in Hamburg see the register.

Nordvik Region is a regional government entity in a member state, so NIS 2 applies to it as nationally transposed, to the extent regional government entities fall within scope. NIS 2 Article 21 requires cybersecurity risk-management measures that cover the security of the supply chain, including the relationship with direct suppliers (3, European Union, 2022). For Hansa, whether NIS 2 also reaches non-financial parts of the group depends on national transposition and is a question for the group's legal function; DORA is the primary regime. The Commission's Implementing Regulation (EU) 2024/2690 sets technical and methodological requirements for the entity types it names (4, European Commission, 2024), and ENISA's technical implementation guidance helps entities to evidence that they meet them (7, ENISA, 2025). The architectural reading is the same under both regimes. A managed provider is a supplier whose service sits inside the entity's detection and response path, so the supplier relationship is a control in the entity's catalogue, with an owner, evidence and a test. A provider may itself be in scope of NIS 2 as a provider of managed security services; the customer should ask, and the answer does not discharge the customer's own duty. Where a managed provider contributes to the awareness that starts a reporting clock, the case record has to show when the provider's AI or analyst first flagged the alert, since the early warning of a significant incident is due within 24 hours of becoming aware (NIS 2 Article 23) (3, European Union, 2022). That is why the conditions block carries a duty on the provider to tell the customer of its own incidents and flags promptly.

The GDPR adds the data layer. Alert and case data contain personal data, and in Nordvik Region's social-care and health contexts special-category data. A provider that processes them for the customer acts as a processor, which requires a contract with defined terms and security of processing, and transfers outside the EU and EEA need a lawful basis (8, European Union, 2016). The processing terms belong in the conditions block of the annex and in the data protection officer's review.

The UK and Swiss entities of Hansa are outside DORA, NIS 2 and the AI Act. Hansa holds their managed detection service to the group's baseline as group policy, labelled as policy and not as law, and lets the local security officers add what local law requires.

Sovereignty and data location

The purpose of this section is to apply the four properties of sovereignty to the question where detection and response AI may run.

AI Platform and Security, Chapter 13, defined sovereignty by four verifiable properties (63, Nordqvist, 2026). Applied to a managed security service, each becomes a term that can be tested.

Property	The question for a managed SOC	Where it is written
Where workloads run	Where are telemetry, cases and the provider's AI inference processed and stored, including backups and support access?	Conditions block; audit term
Which law governs them	Which law governs the provider and its subprocessors, and which authority can compel disclosure of the customer's data?	Conditions block; data protection review
Ability to move	Can detections, case records and integrations be exported and the service replaced?	Exit schedule
Ability to continue if the provider fails	What does the team do on the first day, and how long can it sustain the manual queue?	Exit schedule; degraded-mode drill

Model origin is a separate question from hosting, as AI Governance, Chapter 6, concluded (62, Nordqvist, 2026). A provider may host in the EU a model whose origin and update path lie elsewhere, so the contract should ask which models the provider's AI uses, where they are hosted and who can change them. For an authority whose alert data contains health and social-care information, the position can be strict: such data goes only to models on capacity the Region controls, as Chapter 12 set for the analysts' own assistants. Where a managed provider cannot meet that, the classes it handles are the ones that do not carry such data, or the processing stays in the Region's tenant.

For Nordvik Region the answer is a framework agreement that requires processing and log storage inside the EU and EEA, a conditions block that extends the same rule to the provider's AI inference and to any training, and an audit right that makes the claim checkable. For Hansa Mutual the answer is more fragmented, because telemetry from the UK and Swiss entities reaches Hamburg and the Polish service centre under transfer arrangements that the group's market overlays encode (Chapter 12). Buying managed detection for those two entities is one way to keep their telemetry and first triage in their own jurisdictions, and to pass up to the group only what the group needs for coordination and for the major-incident role of its incident-response team. The cost is a second operating model and a second source of case data to reconcile in the group's record.

Procurement

The purpose of this section is to show how a public authority buys a SOC service with AI so that the award rewards evidence and not slogans. The point applies to any buyer; the authority's constraints are the sharpest.

A public authority buys under national public procurement law that transposes the EU procurement directives, in Nordvik Region's case Directive 2014/24/EU as transposed. This book's conclusion, not a reading of particular articles, is that two features of that setting matter here. Criteria that are stated in advance and can be checked suit evidence and do not suit assertions. And because changing a contract after award is constrained, the terms a buyer will need, such as those of MS-2, are much easier to obtain at the tender than as an amendment. That is the case for writing the annex of this chapter into the tender documents of the next procurement. Where an existing framework agreement must be amended, the procurement lead and the legal adviser check whether the added terms are a permissible modification before the annex is signed; the answer depends on national law and on the agreement, and this book does not give it.

A tender for a SOC service with AI should ask for evidence on five points, and score the answers.

1. A statement of the provider's AI: which models act, on which action classes, at which level, with which model versions, and where they run. A supplier that cannot give the statement scores zero on this criterion.
2. A demonstration against a seeded replay set: the buyer supplies a set of recorded or synthetic alerts, including seeded incidents, and the supplier's service processes them in a test tenant. The result is scored on catch rate by class and on the completeness of the evidence record.
3. The terms of the annex: acceptance of the six terms, scored by the degree to which they are accepted without exception.
4. The exit: a described and tested switch-off, a statement of what is returned and in which format, and the references of an earlier customer who has left.
5. Price, weighted so that it cannot outweigh the others.

These criteria reward the ability to be checked. The five points are the book's own conclusion from CASE-NR-0231; adjust the weights to the buyer's risk appetite and its adviser's view of the procurement rules.

Exit

The purpose of this section is to make exit a tested capability and not a clause. The provider's AI makes leaving harder in a particular way: its closure rules, shaped by the customer's history and by other customers', are not portable.

Three things must leave with the customer. The first is data: the logs, case records, alert history and closure evidence, in a documented format that the customer's tools can read. The second is detection content: the rules and queries that run, with their identifiers, versions and tuning; if the customer owns its content in its repository, as Chapter 6 advises, this is a matter of confirming that the provider's deployed version matches. The third is knowledge of behaviour: the classes the provider closed, the thresholds it used and its own review findings, which are the starting point for the replacement's closure policy.

Practical guide: A tested one-day switch-off

Purpose. Show that the organisation can run without the provider for a day and replace it within a defined period.

Roles. The CISO sponsors the test. The incident commander leads it. The senior security analyst or SOC lead runs the manual queue. The procurement lead owns the contract side. The provider is informed.

1. Choose a window. A weekday, with the provider's agreement, out of hours for at least one run a year.
2. Cut the feed. Revoke the provider's credentials and stop the telemetry feeds at the customer's side, leaving the sources intact.
3. Run the manual queue. The customer's analysts triage the alerts that reach the customer's own console, using the day-one runbook, with the incident commander on call.
4. Measure. Time to first triage of a seeded alert, the share of sources still visible, the number of actions that could not be taken, and the time to restore.
5. Restore, review and file findings. Each gap becomes a finding with an owner and a re-test date.

Definition of done. The manual queue was worked within its target, the exported data and detections loaded into the customer's tools, and every gap has a finding. A six-analyst team will not manage a full day at office strength; record that as a finding and decide whether the answer is a second provider, a longer transition period or more staff, instead of passing the test by narrowing it.

Comparing the two organisations' models

Across the usage modes

The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action. Under each operating model the same two questions decide whether the AI is governed: who decides the level, and who sees the record.

Operating model	Typical mode of the AI that acts	Who decides the level	Who sees the record
In-house, own agents	Mode 5 Autonomous production agents with their own identities	The organisation, in the mandate manifest and delegation profile	The organisation, in its case record
In-house, vendor product	Mode 0 Ambient AI inside a product	Nobody, until the organisation establishes and records it	Partly: the product's logs
MSSP or MDR, no annex	Mode 0 Ambient AI on the provider's platform	The provider	The provider; the customer sees a handover list
MSSP or MDR with an annex like MS-2	Mode 0 for the customer, with levels now stated by contract	Customer and provider, in the annex, at Level 3 Bounded at most for narrow classes	The customer, through the evidence term and the sample
Hybrid, provider executes the customer's playbook	Mode 5 identity, issued and revocable by the customer	The customer, enforced at the customer's policy point	The customer

Nordvik Region and Hansa Mutual

Nordvik Region runs the hybrid model. It keeps the detection content it takes into its repository one rule at a time (AIDR-0701), the incident commander role, the case record and the isolation policy in its endpoint console, and it buys 24/7 monitoring under NR-2025-044. Its question is how much the provider's AI may do. AIDR-0717 (2027-03-22; illustrative) records the operating-model decision: the Region stays hybrid, lists the four retained items above as non-delegable, and instructs the CISO to obtain annex MS-2. AIDR-0718 (2027-05-10; illustrative) sets the ceilings in the worked example, Level 3 Bounded for two closure classes and for workstation isolation under PBK-NR-ISOLATE-01, Level 1 Assisted for the rest, and records the Region's acceptance of the residual risk that sampling will not catch every escape. The annex builds on the requirement set of AIDR-0722. The Region's weakness is capacity. Six analysts working office hours cannot run the manual queue for a full night, so the exit test is partial and the Region keeps a conservative ceiling. Its strength is that the contract is its lever, and a single legal regime keeps the contract simple.

Hansa Mutual runs in-house on two sites for the group and the EU markets, and buys managed detection for the UK and Swiss entities, where local law matters. AIDR-0773 (2027-06-21; illustrative) records that decision: the provider monitors and triages telemetry from the two entities inside their own jurisdictions, the group SOC keeps detection content, the major-incident role stays with the group incident-response team, and the local security officers hold containment decisions in their entities. AIDR-0774 (2027-07-19; illustrative) sets the provider's levels: its AI may close only classes defined as SC-01 and SC-02 in the group's closure policy at Level 3 Bounded, with 5 per cent sampling by the local security officer and the group SOC, and five seeded incidents per class per quarter; it proposes containment at Level 2 Supervised and holds no response credentials. The service is entered in the register of information. Hansa's weakness is a second model and second data stream to reconcile across seven regimes. Its strength is that the provider's AI is held to the same closure policy as its own triage agent.

The comparison does not rank the two. Both keep detection content, the decision to contain and the case record. Nordvik buys time, because it cannot staff nights, and Hansa buys jurisdiction, because two of its entities sit under law the group platform does not cover. In both, the provider's AI may act only as far as a written level, a sample and a stop right allow.

Summary

This chapter described the operating models open to a European organisation, in-house, managed security service provider, managed detection and response and hybrid, with follow-the-sun and sovereign variants, and what AI changes in the choice. It concerned all five blue team functions: B1 Anticipate, B2 Detect, B3 Investigate, B4 Respond and B5 Learn. AI moves the economics by giving providers scale in their models and removing the volume that justified a large in-house shift, and it adds a delegation that the customer cannot see. Hybrid models are observable; provider AI that acts at Level 3 Bounded across clients is expected; a fully autonomous managed SOC with no named human decider is speculation.

The book's conclusion on what must be kept is that detection content, the decision rights for containment and disclosure, the case record, the ability to leave and enough skill to supervise stay with the organisation in every model. Annex MS-2 turns the Mode 0 blind spot into six terms, levels and actions, quarterly sampling, audit rights, evidence, tuning and test rights, and 20 working days' notice of model change, plus conditions for data and exit. The terms gather the duties listed in Chapters 6, 7 and 15, and an organisation can write them into a contract or a tender and check them. The same terms answer the regulators: DORA's register, contract and exit rules for Hansa's financial entities, NIS 2's supply-chain measures for Nordvik Region (and for any Hansa entity that the group's legal function places in its scope), and the GDPR's rules for a processor.

The book's conclusion on sovereignty and data location is that sovereignty is tested by four properties and not by a postcode. An authority such as Nordvik Region can meet them by contract in a single jurisdiction; a group such as Hansa Mutual meets them by placing first triage for the UK and Swiss entities inside their own jurisdictions and holding the provider to the group's closure policy. Procurement should reward evidence, a statement of the AI, a seeded replay and a tested exit, and not slogans. Exit is a capability tested once a year; a team that fails the test says so and decides what to change.

Chapter 17 turns from the operating model to the shape of the team inside it: which roles grow, which shrink and which appear when triage is automated and the first rung of the old pyramid has been removed.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
2. 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). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
3. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. Official Journal of the European Union, 18 October 2024. (4, European Commission, 2024)
4. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. ENISA, June 2025. (7, ENISA, 2025)
5. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (8, European Union, 2016)
6. Five Eyes cyber security agencies. Careful adoption of agentic AI services. Joint guidance, 1 May 2026. (35, Five Eyes agencies, 2026)
7. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (62, Nordqvist, 2026)
8. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (63, Nordqvist, 2026)
9. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (64, Nordqvist, 2026)
10. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (66, Nordqvist, 2026)
11. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (75, Bainbridge, 1983)