Operating Models and Team Design: In-House, Contracted, Hybrid and Sovereign Loops
Part V takes the loop out of the exercise and puts it into the organisation. Chapter 17 asked what "covered" means and Chapter 18 asked how a loop is measured. This chapter asks who runs the loop. The question has two halves. The first is structural: whether the red side, the detection side and the register are run by the organisation's own people, bought from a contracted tester and a managed provider, split between the two, or drawn from a pooled sector capability. The second is individual: which roles a working loop needs, how each is chartered, and which pairs of roles must never be held by the same person. The chapter concerns all five stages of the purple loop. P1 Target and P4 Improve are the stages that usually stay inside the organisation, P2 Emulate is the stage most often bought, P3 Observe is the stage where the boundary between a customer and a provider is most easily blurred, and P5 Verify is the stage where the independence of the roles decides whether the loop produces evidence or only a record.

Figure 19.1: Four operating models, what the organisation holds in every model, what is bought or shared, and the register of record.
The chapter builds on conclusions of the earlier volumes and does not repeat them. AI Blue, Chapter 16, compared in-house, managed, hybrid and sovereign security operations and concluded that, whatever the model, 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 (94, Nordqvist, 2026). AI Blue, Chapter 17, set out what happens to the team once the tier-1 pyramid gives way to closure by class, and introduced the purple team coordinator as a role of the blue team's loop. AI Governance, Chapter 12, held that organisational design is architecture by other means, that control functions keep their independence through gates and records rather than meetings, and that exceptions are routed as expiring records (88, Nordqvist, 2026). AI Governance, Chapter 14, added that new roles follow the usage modes. The Transformed Security Architect, Chapter 4, held that a role is itself a versioned artefact, with a charter that states mandate, accountabilities and decision rights (92, Nordqvist, 2026). AI Platform and Security, Chapter 13, defined sovereignty as a set of verifiable properties and not a postcode (89, Nordqvist, 2026). Architecture as Code (Chapter 18) observed that the design of a system mirrors the communication paths of the organisation that builds it (87, Nordqvist, 2025). This chapter's own conclusion is that the loop has a design problem of exactly that kind: the roles and the contracts decide which stage can lie, and the charter is the place to prevent it.
The chapter answers five questions: which operating models can run the loop, which roles it needs, how independence is kept between roles even in a team of six, who owns the findings and the test data, and how testing and simulation tools are procured.
Four operating models
An operating model answers three questions per stage: who does the work, who is accountable, and where the records live. Four models recur, and an organisation usually runs a mixture, so the unit is the stage.
| Model | Who runs P1 to P5 | What it buys | What it leaves exposed |
|---|---|---|---|
| In-house | Own red team, own detection engineers, own coordinator and white team; own pipeline | Simulation tool licences, perhaps a threat-intelligence feed | Overfitting to one's own habits; a loop that nobody outside questions (Chapter 15) |
| Contracted | Contracted tester for P2; managed provider for P3 out of hours; the organisation for P1, P4 and the closure of P5 | Fieldwork, scenario authoring, round-the-clock monitoring | A loop that starts only when the contract renews and stops when the tester leaves; the provider's AI as the Mode 0 blind spot |
| Hybrid | Own pipeline and detection engineering for routine emulation, a bought tester for the novel and the threat-led | A tester's independent view, specialist skills, surge capacity | Two sets of records that disagree; a seam at which the finding is lost |
| Sovereign or sector | A pooled or shared capability for testing, intelligence and scenarios, with data, findings and keys held by the organisation or inside a jurisdiction it controls | Shared scenarios and testing capacity; for a small body, a capability it could not afford | Dependency on a shared platform; the register of every member in one place |
In-house. An organisation with an engineering culture and enough people runs the loop itself, as Hansa Mutual does. Its advantage is speed and depth: the red team knows the estate and the pipeline of Chapter 8 runs on the organisation's schedule. Its characteristic risk is the one Chapter 15 named. The people who write the scenarios and the people who write the detections drink from the same well, and the loop reports success on what both of them think of. An in-house loop needs an outside check built into it, and the roles below supply part of it.
Contracted. An organisation without a red team buys the offensive work and often the monitoring. Nordvik Region does both: a contracted tester under call-off agreement NR-2026-071, and out-of-hours monitoring from a managed provider under framework agreement NR-2025-044. The leverage is the contract. What cannot be bought is the part of the loop that is a decision: which scenarios matter, what to change, and when a finding is closed. AI Blue, Chapter 16, put this as a list of what stays with the organisation, and the loop adds to it the register and the coordinator (94, Nordqvist, 2026). A contracted loop that has no coordinator on the buyer's side turns into a periodic report with nobody accountable for what happens next.
Hybrid. Most organisations that run a pipeline also buy a tester, and the hybrid model is where the regulatory text points for the financial sector. Regulation (EU) 2022/2554 (DORA), Article 26(8), requires financial entities that use internal testers for threat-led penetration testing (TLPT) to contract external testers at least every three tests, and Article 27(2) makes the use of internal testers subject to approval by the competent authority, which verifies dedicated resources and the avoidance of conflicts of interest (2, European Union, 2022). Commission Delegated Regulation (EU) 2025/1190 adds that an internal testing team has a test lead and at least two further members who have been employed by the entity, or by an intra-group ICT service provider, for the preceding twelve months, and that the use of internal testers must not weaken the entity's defensive capabilities (Article 15) (8, European Commission, 2025). For exercises that are not TLPT these rules on internal and external testers do not apply, although Article 24(4) of DORA still requires tests to be undertaken by independent parties, whether internal or external (2, European Union, 2022). The TLPT rules show what a supervisor expects: a named control function, a limit on who knows, and a rotation that keeps the internal view from being the only view. The hybrid model is observable in the financial sector today.
Sovereign or sector. A body that cannot afford a red team, or must keep data inside a jurisdiction, can draw on a shared capability. The sector information-sharing group that Nordvik Region already belongs to is a source of scenarios; the TLPT regulation itself provides for pooled and joint tests, in which several financial entities that use the same ICT provider are tested together (Articles 6 and 8) (8, European Commission, 2025). Sovereignty here follows the test of AI Platform and Security, Chapter 13: a set of verifiable properties, which are knowing where the loop's workloads and records are, which law governs them, being able to move them, and being able to continue if the provider fails (89, Nordqvist, 2026). A sector capability that cannot show those four properties for the register is a risk dressed as a saving.
The two organisations illustrate two of the four models, Hansa Mutual in-house and Nordvik Region contracted; the hybrid and sector models are argued here from the instruments, and no worked case in this book shows them closing the loop.
What can be undone, and who can stop it. In every model only S1 scenarios are reversible by design (Chapter 6); anything above S1 needs the white team's approval (Chapter 20). Any named stop holder can stop an emulation at a point outside the emulating system, whoever employs the tester, and the contract of a bought model says so.
Practical guide: Choosing an operating model with a decision record and exit criteria
Purpose. Choose, per stage, who runs the loop; record the choice so that it can be reviewed; and write down in advance what would make the organisation change its mind. A model chosen without an exit is a lock-in with a friendly name.
Roles. CISO (decides), purple team coordinator (drafts and keeps the record), white-team lead (reviews independence), procurement lead, data protection officer, internal audit (reads the record), employee representatives where the model changes who is measured.
- List the five stages and, for each, the party that runs it today. Include the parties that appear only in practice, such as a provider's AI that closes alerts out of hours.
- Mark what must stay. Use the list of AI Blue, Chapter 16, extended by Chapter 16 of this book: detection content, decision rights, the case record, the register of record, the right to stop, the ability to leave and enough skill to supervise. Mark any stage where the organisation holds none of these.
- Score each candidate model on five questions: can it show evidence of the stage within the expiry of Chapter 17; can its independence be shown on the five kinds of independence of Chapter 15 and the role pairs of this chapter; where do findings and test data live and under which law; what does it cost per verified technique and not per hour; how long would an exit take.
- Write the decision as an AI Decision Record with an owner, a review date no later than twelve months ahead, and exit criteria stated as numbers: for example, evidence age past expiry for more than a stated share of priority techniques for two consecutive quarters, a failed stop drill twice in a year, or a notice of model change not given.
- Test the exit on paper. Write down what moves, to whom, in how many working days, and what the organisation would do in the meantime. If the answer is "we could not", the model is a dependency and the record says so.
- Review on the date and on trigger. Triggers are a change of provider model, a merger, a failed independence test and a supervisor's request.
Definition of done. One decision record per organisation names the model for each stage, the parties, the data location and the exit criteria; the CISO and the white-team lead have signed it; and a drill or a paper exercise has shown that the exit is feasible.
Worked example: Operating-model decision for Nordvik Region
The Region's loop is contracted at P2 and P3 and internal at P1 and P4, with P5 split across the tester and the provider (Chapter 4, LOOP-NR-2028-01). The decision below, taken in March 2028, confirms that arrangement and states what would end it. It is illustrative.
# Illustrative: Nordvik Region, operating-model decision
kind: AIDecisionRecord
id: AIDR-0820
date: 2028-03-07
subject: Operating model of the purple loop, per stage
decided_by: CISO
reviewers: [internal-audit, ai-architect, data-protection-officer]
review: 2029-03-07
model:
P1: {run_by: region, role: ROLE-NR-SEC-PRP}
P2: {run_by: contracted-tester, agreement: NR-2026-071, declared_ai: modes-1-to-3}
P3: {run_by: mssp, agreement: NR-2025-044, annex: MS-1}
P4: {run_by: region, role: ROLE-NR-SEC-DET}
P5: {run_by: [contracted-tester, mssp], annex: MS-2, closure: ROLE-NR-SEC-DET, countersign: deputy-ciso}
data:
register_of_record: region-tenant # AIDR-0803, POL-NR-FND-01
tester_access: FC-3-own-findings-only
hosted_models: none-for-findings
retained_by_region: [detection-content, containment-rights, register, stop-right, closure]
exit_criteria:
- {measure: priority-techniques-with-expired-evidence, over: "25 percent", for: 2-consecutive-quarters}
- {measure: failed-stop-drills, over: 1, within: 12-months}
- {measure: model-change-notified-late, over: 0, within: 12-months}
exit_plan:
second_source: sector-testing-capability # to be qualified by 2028-09-30
transfer_of_scenarios_days: 10
transfer_of_register_days: 0 # the register never left
The register stays in the Region's own tenant, so an exit costs nothing for the register and ten working days for the scenarios, the Region's target until the first paper exercise tests it. The second source is a qualification task and not yet a contract.
Roles and charters
The loop needs roles and not teams. Chapter 4 listed six: the red team or contracted tester, the blue team, the white team, the purple team coordinator, the closure owner and the agent operator. A working loop breaks these into the seven functions below, and the point of the list is that every function has a holder in every operating model, even where the holder is a contract clause.
| Role | What it does | Accountable for | Never |
|---|---|---|---|
| Purple team coordinator | Schedules sessions and runs; sees that findings reach owners in a usable form; tracks the age of the register | The flow and legibility of the register | Deciding what red or blue should do; owning the changes |
| Emulation engineer | Builds and maintains scenarios, emulation plans and the runner's catalogue; adapts them to the estate | The quality and safety class of the scenarios; the emulation record | Writing the detection that the scenario tests; closing its own finding |
| Detection engineer | Turns findings into detections, playbooks and mandate changes; owns the alert budget | The change and its test | Marking a change verified without a passing re-test |
| Exercise controller | Runs a window under the rules of engagement: starts it, watches it, calls the halt | That the exercise stays inside its scope and abort conditions | Taking part in the red or blue work of the window |
| White team | Authorises the exercise, approves scenarios above S1, holds the stop with others, reviews classification | That the exercise stays within its authority | Belonging to the red team or the SOC |
| Closure owner | One named person per class of finding; signs the closure once the re-test and its variant have passed and the evidence is attached | The closure | Closing on attestation or closing a finding the person authored |
| Agent operator | Runs a loop agent under its mandate manifest; may revoke its credentials | That the agent works within its manifest | Widening the manifest |
The functions map only in part onto the competence profiles that European practice uses. ENISA's European Cybersecurity Skills Framework describes role profiles, among them the penetration tester (102, ENISA, 2022), and SFIA defines skills by level of responsibility (103, SFIA Foundation, 2024). Neither names the coordinator, the exercise controller or the closure owner, which is a reason to chart them. Chapter 24 returns to competences.
What a role charter holds
A role charter is a versioned artefact, as The Transformed Security Architect, Chapter 4, established (92, Nordqvist, 2026). In this book a ROLE-* charter holds six things: the mandate, the accountabilities, the decision rights with the holder, the deputy and the second deputy, the prohibitions (what the holder may not do and what no system acting for the holder may do), the delegation to AI per stage and action class, and the records the role signs. It names a person and, separately, a deputy, because a role without a deputy stops when its holder is on leave. It is reviewed on a date, and it changes by decision record. Employee representatives can read it, and it states that measures about the role are reported for the role and in aggregate, never by named person (Hansa's clause KBV-IT-2024-SOC-05; the aggregate-reporting agreement at Nordvik).
AI changes the charter's content in a particular way. An AI system does not hold a role. A person holds it and answers for what agents do under the role's mandates, so the charter lists the agents by mandate manifest and states what the role must verify before relying on them. Where an agent runs under the role, the role is accountable for the agent and the agent operator is the person who can stop it.
The purple team coordinator
The coordinator is the role most often misread, so the charter below states what it is and is not. The coordinator is a translator and the owner of the loop's records. It makes sure that a finding raised in P3 arrives at its owner in P4 in a form the owner can act on, that the change reaches P5, and that the register's age is known. It does not own the findings, which belong to their authors and owners, does not own the changes, which belong to the detection engineer or playbook owner, and does not close anything. It is the role of Chapter 4, not a team, and it does not decide what the red team tests or what the blue team builds.
Nordvik Region's coordinator is Karin Lund, for a fraction of her time, as Chapter 4 recorded. Hansa Mutual's coordinator was not named in the earlier chapters. The group CISO's office names it in March 2028: the post is ROLE-HM-SEC-PRP, held from 2028-03-01 by Sofia Keller, an investigation lead from the Hamburg SOC, full time. She reports for line purposes to the head of detection engineering, Lena Vogel, and has a standing right of direct access to the group CISO on the age of the register, so that the coordinator can say that the register is old even when the line manager is the owner of the oldest findings. She is not part of the white team and not a detection engineer.
Worked example: Role charter for the purple team coordinator
The charter is Hansa Mutual's. It is illustrative.
# Illustrative: Hansa Mutual, role charter for the purple team coordinator
kind: RoleCharter
id: ROLE-HM-SEC-PRP
version: 1.0.0
decision: AIDR-0871
effective: 2028-03-01
review: 2028-09-01
holder: {person: Sofia Keller, deputy: detection-engineering-duty-lead}
reports_to: head-of-detection-engineering
escalation: {to: group-ciso, on: register-age-past-twice-target, no_approval_needed: true}
mandate: >
Run the schedule of the loop, keep the register legible, and see that every
finding reaches its owner in a form the owner can act on.
accountable_for:
- flow of findings from P3 to P4 to P5
- age of the register, reported by class and in aggregate
- completeness of the session record PRP-* within 5 working days
decision_rights:
schedule_sessions: holder
route_finding_to_owner: holder
escalate_stale_finding: holder
choose_scenarios: none # P1 owners
accept_risk: none # Chapter 20
close_finding: none # closure owner per class
prohibitions:
- authoring a detection for a finding the holder routed and then closing it
- sitting on the white team for an exercise the holder scheduled
- reading FC-4 content beyond the register view granted by POL-HM-FND-01
agents_under_role:
- {mandate: MND-HM-EMU-03, level: 1, verify: "classification re-done by a person for a sample"}
- {mandate: MND-HM-EMU-05, level: 1, verify: "owner and route confirmed before notification"}
delegation: {P3: 1, P4: 1, P5: 1}
measures: {reported_as: role-and-aggregate, never: named-person, works_agreement: KBV-IT-2024-SOC-05}
The charter's decision rights say as much by what they refuse as by what they grant. The coordinator can escalate a stale finding without approval and cannot close one, choose a scenario or accept a risk. The two agents listed under the role are the ones that touch the register: the observation correlator and the finding triager of Chapter 14. The charter names what the holder checks before relying on them, which is the AI Blue, Chapter 14, rule that review does not start from the AI's answer (94, Nordqvist, 2026).
The exercise controller and the white team
The white team is the control group that governs an exercise (Chapter 4), and the exercise controller is the member of it who runs a single window. TIBER-EU names the equivalent function for a threat-led test as the control team, a small group in the tested entity that alone knows the test is happening (earlier TIBER-EU documents called the governing body the White Team), beside the authority's TIBER cyber team (20, ECB, 2025). The TLPT regulation uses the same terms, a control team in the entity and test managers on the side of the TLPT authority. It limits who may know of a test to a need-to-know group and requires the control team to consult the test managers before involving any member of the blue team (Articles 3 and 4) (8, European Commission, 2025). Where this book writes "white team" for exercises in general, the regulation's control team does the same work for TLPT.
The exercise controller starts the window, watches the abort conditions of the emulation plan, calls the halt, and records the window in the session record. The controller is not the tester and not a member of the defending team that is measured. At Nordvik Region the duty security officer acts as exercise controller for each window and the contracted tester's fieldwork lead reports to that officer for the duration, under the white-team lead, who is the CISO's delegate (the deputy CISO). At Hansa Mutual the exercise controller is a deputy of the white-team lead for human-led exercises; for the continuous pipeline the equivalent of a window is the run, and the right to stop belongs to the agent operator and to the white team, held outside the runner (Chapter 6).
Worked example: Role charter for the exercise controller
Nordvik Region's charter is short because the Region's exercises are few. It is illustrative.
# Illustrative: Nordvik Region, role charter for the exercise controller
kind: RoleCharter
id: ROLE-NR-SEC-XCT
version: 1.0.0
decision: AIDR-0821
effective: 2028-03-14
review: 2029-03-14
holder: {role: duty-security-officer, deputy: second-duty-security-officer}
reports_to_for_window: white-team-lead # the deputy CISO
mandate: >
Run each exercise window under its rules of engagement, call the halt when an
abort condition is met, and record the window.
decision_rights:
start_window: holder # after white-team lead signature on the RoE
halt_window: holder # no prior justification; a halt in good faith is not a failure
approve_scenario_above_S1: none # white-team lead, per run
tell_blue_team: none # trusted agent only
prohibitions:
- taking part in the tester's fieldwork or in the blue team's response during the window
- receiving the expectation sheet before it is sealed
- holding detection ownership or closure for the findings of the window
stop:
halt_target_minutes: 5 # RoE-NR-2027-001
identity_revocation_seconds: 120
held_outside: region-identity-provider
agents_under_role: none
records_signed: [EMU-*, PRP-*]
Two entries deserve a comment. The controller has no right to tell the blue team about the plan, which belongs to the trusted agent alone (Chapter 6). And the controller receives the expectation sheet only after it is sealed, because the person who runs the window must not be able to adjust the record of what was expected.
Independence between roles
Chapter 15 gave the independence principle for systems: the side that tests and the side that is tested must be able to fail in different ways. The same principle applies to roles, and in a small organisation it is the roles and not the models that are most likely to share a failure. A person who writes a scenario, writes the detection for it, runs the re-test and closes the finding has built a loop of one, and it will report success on whatever the person thinks of. The rule is easy to state: nobody marks their own work.
The pairs below set out what that means in practice. A pair is forbidden when the same person (or the same agent chain) on both sides would let a single blind spot produce a pass.
| First role or act | Second role or act | Same person? | Compensation if unavoidable |
|---|---|---|---|
| Authors the scenario | Authors the detection tested by it | No | Held-out scenario written by a third party (Chapter 15) |
| Authors the change (P4) | Closes the finding (P5) | No | Countersignature by a named second person; sample by internal audit |
| Exercise controller or white team | Red team, SOC, or detection owner of the window | No | None accepted; use a deputy or the contracted test lead |
| Trusted agent | Detection owner making tuning decisions in the same window | Not in the window | The second analyst takes tuning decisions until the window closes |
| Coordinator | Closure owner | Allowed in a small team | Coordinator does not close findings routed by the same person; register age reported to the CISO |
| Access reviewer of the register | A user of the register | No for one's own access | The CISO's delegate reviews the reviewer's access |
| Agent operator | Approver of the agent's mandate widening | No | The widening is an AI Decision Record signed by the delegator, not the operator |
| Tester | Detection owner or tuner of the client's rules | No | A contract clause (Nordvik: the firm is not the Region's detection owner and does not tune the Region's rules) |
Authorship and closure. The weakness Chapter 4 recorded in the Nordvik charter is the second row. Karin Lund accepts the P4 change and also holds the P5 closure. The charter compensated with the tester's re-test and the provider's seeded incidents, which are independent of her. The decision of March 2028 (AIDR-0822, dated 2028-03-21) adds a rule that applies where she authored the change herself: the deputy CISO countersigns the closure, and internal audit samples closed findings twice a year, as the audit committee has a right to do. The rule costs the deputy CISO about an hour a month at the Region's current volume. It converts "she closes her own work" into "she closes her own work and a second person looked at the evidence".
The trusted agent and the detection owner. Chapter 7 defined the trusted agent as the person on the blue side who knows, and in a small team it is the person who commissioned the exercise. At Nordvik that is Karin Lund. The detection owner, who is also Karin Lund, must not tune rules in response to the exercise while it runs. The charter therefore gives the hat for the window to one role: for the length of the window she acts as trusted agent only, the second analyst takes any tuning or triage decision that is not the exercise's, and the expectation sheet was sealed before the window opened. Without the rule the same person's judgement is both the instrument and the object of the measurement.
Access review. Karin Lund owns the monthly access review of the register; the CISO's delegate reviews her own entry. An auditor finds that kind of rule first.
Agents and roles. An agent does not hold a role, so the independence question for agents is about the people who run them and about the chain of models, which Chapter 15 treated in full. The additional rule of this chapter is that the operator who can stop an agent is not the person who can widen its mandate. At Hansa Mutual, the agent operator of the pipeline runner (MND-HM-EMU-01) holds the stop; widening the mandate needs a decision of the group AI governance board, with the CISO as delegator. A stop in good faith needs no justification, and continuing after a stop needs the owner, who restarts at a lower level (94, Nordqvist, 2026).
Closure owners by class
Chapter 4 added the closure owner as one named person per class of finding. The classes are the routes of Chapter 10: detection, control, playbook, mandate and recorded risk acceptance. The owner for a class is the person who can read the re-test evidence for that class and is not its author. At Hansa Mutual, the detection class closes under the head of detection engineering, Lena Vogel, except for changes she authored, which close under the SOC lead; the control class under the head of security architecture; the playbook class under the SOC lead; and the mandate class under a delegate of the chair of the group AI governance board. Risk acceptance does not close anything and is decided as Chapter 20 sets out. Decision AIDR-0872 (dated 2028-03-14) records that the author of a change never closes it and that each class has a named deputy. A closure owner who is on leave without a deputy stops the register, and the coordinator reports the stoppage.
Small teams
The loop must be viable at the size of the smallest organisation that needs it. A viable minimum loop has three properties: the five stages exist, each stage has an owner and a deputy even where one person holds several, and the pairs in the table above are kept apart by contract, by countersignature or by sampling where they cannot be kept apart by person.
Nordvik Region's security unit of fourteen has six analysts, one detection owner and no detection-engineering function. The Region's minimum loop is as follows.
- Own, two people. Karin Lund (coordinator, detection owner, closure owner, trusted agent, access reviewer, each as a separate hat with a separate record) and the second analyst, who is the deputy for every one of those hats.
- Bought, two counterparties. The tester for P2 and for the held-out scenario; the managed provider for P3 out of hours and for the seeded incidents of P5.
- Borrowed, two people. The deputy CISO as white-team lead and countersigner; the duty security officer as exercise controller.
- Sampled, one body. Internal audit samples closed findings.
That is five of the Region's people, none of them full time on the loop, plus two counterparties, and the rest is contract. The weakness is concentration. Karin Lund holds more hats than any role chart should give one person, and the second analyst is the single point of resilience. The compensation is documentation and rotation: each hat has a charter, the second analyst runs one session a year as coordinator to keep the skill alive, and the exit criteria of AIDR-0820 treat the loss of either person as a trigger for review. The honest statement for the audit committee is that the Region's loop is small, depends on two people and two contracts, and shows in its register where it is weakest.
The smallest viable loop is not a smaller version of Hansa Mutual's. It lacks a pipeline, a curator and a critic, and its best protection is the independence that the contract buys. A hat can be added to a person's duties without any time being taken from their other work, so each charter states a time allowance, which the CISO and the union review with AIDR-0820.
Sovereignty and findings
Where findings and test data may live follows from what they are. Chapter 16 classified findings by what their content lets a reader do, from FC-1 Aggregate to FC-4 Exploitable, and concluded that the register of record belongs in its own store, segregated from the scenario repository and the SOC platform. The operating model decides who sits next to that store.
Four rules hold in every model. The register of record is the organisation's, not the tester's and not the provider's: the organisation holds the keys, the access log and the exit. Test data and telemetry from an exercise are classified before the exercise, because telemetry in Nordvik's case contains personal and health data and the legal basis and classification of exercise telemetry are recorded in the rules of engagement (Chapter 6). A contractor or provider receives the view of the finding that its work needs, at FC-3 for its own findings and FC-2 as a reference in a provider's queue, and loses access one working day after the engagement ends. And hosted models receive FC-1 and FC-2 only, as POL-NR-FND-01 and POL-HM-FND-01 state.
The sovereign question is sharper where the loop is pooled. DORA Article 27(3) requires that contracts with external testers provide for sound management of TLPT results, so that the handling, reporting and destruction of data does not create risks for the financial entity (2, European Union, 2022). A sector capability must meet the same standard for every member. The test is that of AI Platform and Security, Chapter 13: where the workload runs, which law governs it, whether the register can be moved, and whether the member can continue if the provider fails (89, Nordqvist, 2026). For Hansa Mutual, with seven regimes, the findings of the UK and Swiss entities enter the group register only where the data-transfer decision permits, and the managed detection provider must consent before a test crosses its boundary; where consent or transfer is missing, the gap is recorded as an FC-4 finding and not as an absence.
Public authorities carry one further obligation. Nordvik Region's findings are security-sensitive under the public-access rules of its member state, and its records officer has recorded the exemption beforehand (Chapter 16). The operating model changes who must be told: a contracted tester that keeps copies in its own systems has created a second record that may be requested, and the contract must say that it does not.
Procurement
Buying the loop is buying a right to learn from a result and not only a service. The tools and services fall into three groups: testers, simulation and emulation platforms, and managed services that observe or respond. The procurement test is the same for all three: the contract must make the loop's records and stop path the organisation's, whatever the supplier's technology.
Testers. The call-off agreement NR-2026-071 is the Region's template. It fixes test rights, a rules-of-engagement template, data-handling terms and the clause that the firm declares any AI it uses in Modes 1 to 3 and uses no Mode 5 emulation agent against the Region's systems without a signed mandate. The TLPT regulation sets selection criteria that are also a sound baseline for non-TLPT purchases: references from prior penetration and red-team assignments, a manager with at least five years' experience and further testers with at least two (Article 7) (8, European Commission, 2025).
Simulation and emulation platforms. Open-source libraries and platforms such as Atomic Red Team (32, Red Canary, n.d.) and MITRE Caldera (33, MITRE, n.d.) are building blocks, and commercial breach-and-attack simulation tools wrap similar content. What matters is what the purchase brings in: scenario content that arrives as code and can be versioned and reviewed, safety classes that the tool respects, a stop that the organisation can hold outside the tool, tamper-evident logs, and a way to export the results into the register. A tool whose results live only in its own console fails the register test.
Managed services. For monitoring and response the contract terms are those of annex MS-2 in AI Blue, Chapter 16: levels and actions, quarterly sampling, audit rights, evidence, tuning and test rights, and 20 working days' notice of a model change (94, Nordqvist, 2026). Chapter 15 added the independence terms MS-2-IND-1 and MS-2-IND-2. A provider's AI that closes alerts is a Mode 0 system from the buyer's side, and a contract right is only a promise until the first sample, seed or stop request shows that it works.
Four terms should appear in every purchase of the loop, and a supplier who will not accept them has told the buyer something. The organisation owns the scenarios and findings produced for it. The supplier declares the model family and the Mode of any AI that touches the engagement, and notifies a change. Findings and test data are returned and destroyed on a stated schedule, and are not used to train a model. The organisation can stop the activity without the supplier's consent and can leave within a stated period with its records. For financial entities the same terms sit inside the third-party risk regime of DORA, which Hansa Mutual's register of information covers for every testing and simulation service (2, European Union, 2022).
Across the usage modes
Roles differ by mode. In Modes 0 to 3 AI extends a person: the role is performed by the person with a tool, and the charter regulates the tool as a working instrument. In Modes 4 and 5 the role includes accountability for an agent that holds its own identity and permissions, and the charter must list the agent and the mandate.
| Role | Modes 0 to 2 (ambient, chat, embedded assistant) | Mode 3 (agentic work tool) | Modes 4 and 5 (application and autonomous agent) |
|---|---|---|---|
| Coordinator | Drafts session notes; summarises findings | Assembles the register view for the owner | Accountable for the correlator and the triager (Level 1) |
| Emulation engineer | Drafts scenario text | Proposes variants for a catalogued scenario | Owns the runner's catalogue; operator holds the runner (Level 3 for S1 inside scope) |
| Detection engineer | Drafts rule text | Drafts a rule with tests in a branch | Reviews the drafter's pull requests (Level 1) |
| Exercise controller | Not used for decisions | Schedules and reminds | Controls a run only through an operator who can stop it |
| Closure owner | Not used for the decision | Assembles evidence | The re-test runner records a passing codified result (Level 3) for S1 regression cases and assembles the evidence; the closure owner signs every closure |
The statement about the future is split by label. That people use AI in Modes 0 to 3 in each of these roles is observable. That roles with accountability for Level 3 agents become common in organisations that run a pipeline is expected, since the instruments that already require clear roles and responsibilities for ICT functions and management-body accountability for cybersecurity risk (DORA Article 5(2); NIS 2 Article 20(1)) do not make that accountability depend on whether the work is done by a person or an agent (2, European Union, 2022) and (3, European Union, 2022).
Across the degrees of delegation
Roles are not delegated; tasks are. The ceilings of Chapter 4 apply to each task a role performs, and the lowest ceiling governs. The coordinator's routing at Level 1 means a person confirms every route. The re-test runner's Level 3 covers recording a passing result; the closure owner signs every closure, and reproduces those that Chapter 15 requires.
Observable, expected, speculation
Observable. The four operating models exist today in European security testing: in-house, contracted, hybrid and pooled arrangements all occur, and the TLPT regulation provides for pooled and internal testing.
Expected. Hybrid and sector models will grow, since the regulation requires external testers in rotation and small bodies cannot fund a red team.
Speculation. A fully vendor-run loop with no named person who can decide, stop and close would satisfy supervisors for a regulated entity; the roles above are the reason this book does not expect it.
Nordvik Region and Hansa Mutual
Nordvik Region buys the loop and its leverage is the contract. Its model is contracted at P2 and P3 and internal at P1 and P4, recorded in AIDR-0820 with exit criteria and a registered second source to qualify by 2028-09-30. Its role charters are ROLE-NR-SEC-PRP (the coordinator, held by Karin Lund for a fraction of her time) and ROLE-NR-SEC-XCT (the exercise controller, the duty security officer), with AIDR-0821, and the countersignature rule of AIDR-0822 compensates for the concentration of hats in a team of six. The Region's strength is that independence comes by contract: the tester is not the detection owner and the provider's AI is not the Region's. Its risk is the loop that stops when the contract does, or that rests on two people.
Hansa Mutual runs the loop and its leverage is the pipeline. Its model is in-house for the pipeline and the quarterly sessions, with an external provider contracted for the next TLPT, in line with the rotation of DORA Article 26(8); the group red team's internal-tester status is not relied on for the quarterly sessions or the pipeline, which are not TLPT (AIDR-0870, dated 2028-02-29). Its charter set (AIDR-0871) names the coordinator, Sofia Keller, and separates the closure owners by class; AIDR-0872 records that the author of a change never closes it. Its strength is the ability to build and to run consistent practice across two sites. Its risk is that a loop that runs without anyone questioning it also runs without anyone noticing that the same few people wrote the scenario, the detection and the review.
Summary
This chapter asked who runs the loop. Four operating models recur, in-house, contracted, hybrid and sovereign or sector, and an organisation runs a mixture, so the decision is made per stage and recorded with exit criteria. What the model buys is capacity and a different view. What it must leave with the organisation is the coordinator, the closure owner, the white team, the register of record and the right to stop. The chapter concerned P1 Target and P4 Improve, which stay inside, P2 Emulate, which is the stage most often bought, P3 Observe, where the seam between customer and provider lies, and P5 Verify, where independence between roles decides whether the loop produces evidence.
Seven roles make the loop work: the purple team coordinator, the emulation engineer, the detection engineer, the exercise controller, the white team, the closure owner and the agent operator. Each is chartered in a ROLE-* file with a holder and a deputy, decision rights, prohibitions and the agents under it. The coordinator is a role and not a team, and Hansa Mutual's is now named: ROLE-HM-SEC-PRP, held by Sofia Keller. The principle of Chapter 15 applies to roles as well as to models: nobody marks their own work, and where a small team cannot keep the pairs apart it uses countersignature, sampling and a contract.
Findings and test data have an owner and a place. The register of record is the organisation's and sits in its own store, the contractor sees what its work needs, and hosted models see only FC-1 and FC-2. Procurement buys the right to learn: the organisation owns the scenarios and findings, the supplier declares its AI, data are returned and destroyed, and the organisation can stop and leave. Chapter 20 takes up the decision rights that these roles exercise: who may accept a risk, who may stop, and who holds the closure when the roles disagree.
Sources
- 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)
- European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
- European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
- European Commission. Commission Delegated Regulation (EU) 2025/1190 (TLPT). (8, European Commission, 2025)
- ENISA. European Cybersecurity Skills Framework (ECSF) Role Profiles. (102, ENISA, 2022)
- SFIA Foundation. SFIA 9. (103, SFIA Foundation, 2024)
- Red Canary. Atomic Red Team. (32, Red Canary, n.d.)
- MITRE Corporation. MITRE Caldera. (33, MITRE, n.d.)
- Nordqvist, G. Architecture as Code. (87, Nordqvist, 2025)
- Nordqvist, G. AI Governance. (88, Nordqvist, 2026)
- Nordqvist, G. AI Platform and Security. (89, Nordqvist, 2026)
- Nordqvist, G. The Transformed Security Architect. (92, Nordqvist, 2026)
- Nordqvist, G. AI Blue. (94, Nordqvist, 2026)