Across Boundaries: Suppliers, Managed Providers, Sector Exercises and Authorities

Most of what the earlier chapters of Part V and Part IV describe happens inside one organisation. The loop does not stay there. Its emulation may pass through a managed provider's pipeline or a cloud provider's platform, its observation may depend on a provider's tagged-event outcomes, its changes may have to be made by a supplier, its findings may concern a product that someone else built, and its evidence may be wanted by a peer group, a computer security incident response team (CSIRT) or a supervisor. This chapter treats the loop where it crosses the boundary of the organisation. It concerns P2 Emulate, because the stage that touches other people's systems needs their consent and a stop path they can use, P3 Observe, because what a provider or a peer sees is part of the evidence, and P4 Improve, because a change that belongs to someone else is a request and not a merge, and because a finding in someone else's product has to be disclosed.

The chapter builds on conclusions of the earlier volumes. Vendor AI inside a managed service is the Mode 0 blind spot, and its use and autonomy are established and required by contract before they are relied on (F57, AI Red Team, Chapters 8 and 28) (90, Nordqvist, 2026). Annex MS-2 turned that into six contract terms, and a contract right is only a promise until the first sample, seed or stop request shows that it works (F97 and F111, AI Blue, Chapters 7 and 16) (94, Nordqvist, 2026). Sovereignty is a set of verifiable properties and not a location (F47, AI Platform and Security, Chapter 13) (89, Nordqvist, 2026), and the July 2026 incident showed what happens when controls at a boundary share a dependency: one credential shared across clusters made a single theft cluster-admin everywhere (73, Larcher et al., 2026) (F28, AI Governance, Chapter 19) (88, Nordqvist, 2026). Chapter 6 gave the rules of engagement for third parties in outline and Chapter 13 gave the injected test. This chapter adds the protocol that makes both usable across a boundary, the sector and disclosure paths, and the evidence a supervisor receives.

The organisation loop with the paths across its boundaries: consent and notice to a managed provider, notice and rules to a cloud provider, sanitised sharing with a sector group, disclosure to a CSIRT and vendor, and a summary to the supervisor, with the white team holding the stop.

Figure 22.1: Organisation loop with managed provider, cloud provider, sector group, CSIRT and supervisor: consent, notice, sharing and disclosure paths.

Testing through a provider

A test crosses a provider boundary in one of three ways, and they need different permissions. The distinction is the book's own, drawn from the cases in Chapters 6 and 13.

  1. Through the provider's pipeline. The organisation causes a seeded incident to arrive in a provider's queue and measures what the provider's staff and AI do with it. This is the injected test of Chapter 13. The provider's platform is the instrument of the measurement, not its target; the target is the provider's handling of the organisation's case.
  2. Through the provider's response chain. The organisation runs a scenario on its own estate and watches whether the provider's out-of-hours chain detects, pages and acts as the contract says. The activity is the organisation's, the observation is the provider's, and the provider's staff may be woken.
  3. Against the provider's platform. The organisation, or a tester it hired, probes the provider's infrastructure, its other customers' tenants or its staff. This is outside the organisation's authority to grant. A customer can authorise a test of what it owns; it cannot authorise a test of what the provider owns, and the book's rule is that no manifest includes it.

The first two need the provider's consent, given in advance in the contract. The third is excluded in every manifest.

The same split applies to the observation side. Under annex MS-1, Nordvik Region's provider returns the outcomes for tagged events within five working days, and that return is the P3 evidence for the out-of-hours chain. A loop that depends on a provider for its observation depends on the provider's clock, and the expectation sheet of Chapter 9 has to be written with that delay in mind: the session cannot close in the week of the run.

The stop path crosses the boundary too, and it is where the independence rule of Chapter 4 is easiest to lose. The stop must be held outside the system it stops, and in a provider test two systems are involved. The Region's stop holders can revoke the test identity at the Region's identity provider, which stops the activity, but they cannot stop the provider's own handling of seeds already in its queue. The annex therefore gives the Region a written stop instruction with a response time, and gives the provider's shift lead the right to stop the activity on its side without justification. A stop in good faith is never a failure, and that holds when the provider is the one who stops.

What can be undone is also a boundary question. A seeded case in a provider's queue is undone by closing it as a tagged test, and MS-2 states that seeds are not treated as incidents. A person paged at 02:00 cannot be un-paged. The protocol therefore limits the number of out-of-hours pages per window and names them in the notice, and Chapter 23 returns to the cost of exercises to the people who answer them.

Consent is a chain with one link per party that owns a boundary: the organisation's management body, the provider, the tester, and, where staff are involved, their representatives. A manifest that records only the first and the third is incomplete. The consent the provider gives has three levels, and mixing them is the commonest defect.

Standing consent is given once, in the contract: the classes of test the customer may run, the seeds' synthetic nature, the right to a stop and the knowledge rules. Window notice is given each time: the classes, the window, the white-team contact and the number of out-of-hours pages, delivered a stated number of working days before the window opens. Run-level knowledge is what the provider's staff and AI know while the test runs, which is that tests exist and nothing about which alerts are tests. Standing consent without window notice leaves the provider unable to plan its staffing or to tell a test from an incident that coincides with it. Window notice that tells the provider which alerts are tests removes the measurement.

Cloud providers' published rules

A cloud provider publishes the rules under which customers may test what they run on it. The rules differ, and they change, so the protocol records the date on which each was read and re-reads it before every window. As of 2026-11-10 the three pages read for this book say the following.

Provider (source) Notification or approval What it says about third parties Prohibited or conditional Vulnerability in the provider's own service
Microsoft Azure (79, Microsoft, 2026) No pre-approval and no notification; the Microsoft Cloud Unified Penetration Testing Rules of Engagement apply Third parties may test with explicit written authorisation from the resource owner, which Microsoft does not grant on the customer's behalf Denial-of-service testing of any kind; credentials that are not the customer's own; post-compromise action against Microsoft services beyond proof of concept Stop and report through the Microsoft Security Response Center
Amazon Web Services (83, AWS, 2026) No prior approval for the listed services; command-and-control hosting needs prior approval; covert adversarial simulations (listed under red, blue and purple team testing), simulated phishing and malware testing need a Simulated Events form, and all simulated-event requests are submitted at least two weeks ahead The customer is responsible for third parties it contracts complying with the policy Denial-of-service including simulated forms; request flooding; some DNS and takeover techniques Report to AWS Security within 24 hours of completing the test
Google Cloud (84, Google Cloud, n.d.) The customer is not required to contact Google Not addressed in the FAQ entry read Customers must follow the Acceptable Use Policy and Terms of Service, and the test must affect only the customer's own projects Report through Google's Vulnerability Reward Program

Two lessons follow, and both are the book's own. First, the rules disagree about the very thing this book is about: one provider names red, blue and purple team tests as a category and requires a form, submitted two weeks ahead, for the covert adversarial simulations within it, while another requires no notice at all (83, AWS, 2026) (79, Microsoft, 2026). A manifest that says "notice given" without saying under whose rule is therefore not evidence. The protocol records the provider, the page, the date it was read and the form or reference number where one exists. Second, every provider's rule has a clause that turns a finding into a duty: stop and report a vulnerability in the provider's own service. A scenario that reaches a provider's own service has left the signed scope in the sense of Chapter 6, and the manifest lists that event as a stop condition for the line of testing, with the provider's reporting channel named.

Providers can also interrupt activity. Microsoft's page states that it may, at its discretion, interrupt activity in progress whether or not the test is valid, and advises customers to keep their authorisation documents at hand (79, Microsoft, 2026). The protocol treats such an interruption as a stop held outside the organisation: the runner halts, the white team records it, and nothing counts as failed.

Shared responsibility in the contract

Shared responsibility, the cloud industry's name for the division of duties between provider and customer, decides what the loop can claim. The customer tests its configuration, its identities, its detections and its logs; the provider is responsible for its platform. A coverage statement (Chapter 17) therefore names the layer: "the Region's tenant configuration, tested on a date" is a statement the loop can evidence, whereas "the cloud is covered" is not. NIS 2 Article 21(2) lists supply-chain security among the measures essential and important entities take, and Article 21(3) asks them to take into account the vulnerabilities and security practices specific to each direct supplier (3, European Union, 2022). For financial entities, DORA Article 30(3)(d) lists, among the contractual provisions for services that support critical or important functions, the obligation of the provider to participate and fully cooperate in the entity's threat-led penetration test (2, European Union, 2022). As architectural implications, not legal advice: the right to test is a requirement placed in the contract before the provider is chosen, and the right must survive exit and substitution, because a sovereignty claim that the organisation can move or continue without a provider (F47) is itself a claim that needs a test.

Purpose. Make every test that crosses a provider's boundary consented, noticed, stoppable and recorded, without telling the provider which cases are tests. Roles. The purple-team coordinator or detection owner writes it; procurement and legal put the standing consent into the contract; the white-team lead approves each window; the provider's service manager and shift lead sign; the data protection officer reviews what the seeds contain; employee representatives are informed where staff are on shift.

  1. Classify the crossing as pipeline, response chain or provider platform. Refuse the third.
  2. Record the standing consent in the contract annex: classes, synthetic seeds, stop right, treatment of seeds in reporting, and the model-change notice that triggers a re-test (for MS-2, 20 working days' notice and a re-test within 30 days of it).
  3. For a cloud provider, read the current testing rules, record the page and the date, and file any form the rules require. Re-read before each window.
  4. Set window notice: the default is ten working days before the window for a managed provider, and the cloud provider's own period where it has one (AWS names two weeks for a Simulated Events form). The notice names the classes, the window, the white-team contact and the maximum number of out-of-hours pages.
  5. State what the provider may know during the run: that tests exist, the count per class and the scoring. State what it may not know: which alerts, when, with what content.
  6. Name the stop holders on both sides, each with a deputy, and the instrument: revocation of the test identity at the organisation's identity provider, and a written stop instruction to the provider with a response time. Run a stop drill with the provider at least yearly, out of hours.
  7. Name the stop condition for a vulnerability in the provider's own service: the line of testing stops, and the provider's reporting channel is used within the time its rule sets.
  8. State the liability default, the data rule (synthetic data, no training on seeds, retention) and the treatment of the results: what the provider receives for each seed and what it never receives.
  9. Sign, version and record the protocol in an AI Decision Record, and reference it from the rules-of-engagement manifest.

Definition of done. For any test that crossed a boundary, a reader can name the provider, the clause that allowed it, the date of notice, the stop holders on both sides and what happened at the stop drill.

Worked example: A provider annex clause (illustrative)

The clause below is Nordvik Region's amendment to annex MS-2, adopted in AIDR-0829 (2028-03-14). It adds testing across the boundary to the injected tests of Chapter 13, and it applies first to the next round, 2028-05-08 to 2028-05-19.

# Illustrative: Nordvik Region, annex MS-2 clause on testing across the provider boundary
annex: MS-2
clause: MS-2-TST-1
agreement: NR-2025-044
decision_record: AIDR-0829
protocol: CNP-NR-2028-01
effective: 2028-03-14
standing_consent:
  - injected incidents in the closure classes MS2-C1, MS2-C2, MS2-ISO
  - one end-to-end test of the out-of-hours chain per round, one night, S1 only
window_notice:
  working_days_before: 10
  contents: [classes, window, white_team_contact, max_out_of_hours_pages]
  max_out_of_hours_pages: 2
provider_knows: [that_tests_exist, seeds_per_class, scoring]
provider_does_not_know: [which_alerts, timing_within_window, content]
excluded:
  - tests of the provider platform or of other customers
  - denial of service
  - social engineering of provider staff
  - credentials not issued to the Region for the test
stop:
  customer_holders: [Karin Lund, deputy CISO]            # the CISO's delegate leads the white team
  provider_holder: shift_lead                             # may stop on the provider side, no justification
  instrument: written instruction, answered within 15 minutes
  test_identity_revocation_seconds: 120                   # at the Region identity provider
  drill: yearly, out of hours, with consent
vulnerability_in_provider_service: stop that line of testing, report through provider security channel
model_change:
  notice_working_days: 20
  retest_within_days: 30
seeds_treated_as_incidents: false
liability: customer bears disturbance within classes and windows; provider bears it outside them
review: 2028-09-01

The clause changes one thing in practice. Before it, the Region's tests of the out-of-hours chain were negotiated each time. After it, they are scheduled, and the question the audit committee asked in January (what the first exercise proved) can be followed by a question the Region can answer from the annex: what the provider's chain did, on which night, with what result. The next data point is the finding FND-NR-2028-003, whose new rule DET-NR-0012 needs a change on the provider's side (a request due 2028-04-18) and an injected test due 2028-05-02 (AIDR-0805, Chapter 10): the P4 change is a request, and the P5 proof is a seed under the new clause.

Sector exercises

A sector exercise is a different instrument from the loop of this book. It tests coordination between organisations, authorities and sectors under a crisis scenario, and it is organised by an authority or a sector body, not by the organisation's white team. The best documented European example is the Cyber Europe series run by the European Union Agency for Cybersecurity (ENISA). The 2024 edition, which focused on the energy sector, took place on 19 and 20 June 2024 in a hybrid format coordinated from an exercise control centre in Athens, and its after action report was published on 10 December 2024 (58, ENISA, 2024). The report records, from the impressions of observers and feedback collectors, that operators reported incidents effectively to national authorities and CSIRTs, that there was no evidence of information exchange at regional or European level between peer energy operators, and that a gas-storage incident between two Member States showed deficiencies in cross-border incident reporting. Its distribution is limited to the planners and participating organisations, which is itself a lesson about how sector findings travel.

Three points follow for a purple loop. First, a sector exercise supplies P1 Target input: its scenario is a source for the scenario library, tagged with the exercise and taken at the level of technique and expected evidence. Nordvik's profile already lists the sector information-sharing group as one of the sources of its library. Second, its findings are owned by whoever they concern. A finding about the organisation's own detection or playbook enters its register, with an owner, a state and a re-test, exactly like any other (Chapter 4). A finding about the sector's coordination belongs to the sector body, and the organisation's contribution is to record what it will do differently. Third, a sector exercise does not prove detection coverage. It exercises decisions, communication and reporting. The loop's own claim about a technique still needs its own test, and an organisation that reports "we took part in the sector exercise" as evidence of coverage has made the error that Chapter 17 names.

A group of organisations can also run the loop jointly. The threat-led penetration testing of DORA allows pooled testing: where the participation of an ICT third-party service provider in a test is reasonably expected to adversely affect the quality or security of its services to customers outside the Regulation's scope, or the confidentiality of their data, the financial entity and the provider may agree in writing that the provider contracts an external tester, under the direction of one designated financial entity, for a pooled test involving several financial entities that use the provider (Article 26(4)) (2, European Union, 2022). It is observable in the instrument; whether providers of AI services will be tested that way is expected where they support critical or important functions, and that any sector will run continuous emulation jointly is speculation.

Sharing without exposing

An organisation that discovers, through its loop, a detection that works has something peers can use, and an organisation that receives peers' detections has something it must not trust without testing. Both directions need a protocol, because the material of the loop is among the most sensitive an organisation holds (Chapter 16). The scenario library shows what the organisation worries about; the coverage record shows what it cannot see; the findings register is a map of the estate.

The law encourages sharing and leaves its form to the community. NIS 2 Article 29 requires Member States to ensure that essential and important entities can exchange, on a voluntary basis, relevant cybersecurity information, including techniques and procedures, indicators of compromise and recommendations on the configuration of tools to detect attacks, within communities and through arrangements that respect the potentially sensitive nature of the information; entities notify the competent authorities of their participation (Article 29(4)). Article 30 allows voluntary notification of incidents, cyber threats and near misses to the CSIRTs (3, European Union, 2022). DORA Article 45 gives financial entities the same freedom within trusted communities, through arrangements that define the conditions of participation, the involvement of public authorities and of ICT third-party providers, and the operational elements, with notification of membership to the competent authority (2, European Union, 2022). The architectural implication is that the arrangement is a document the organisation signs and a control it operates; the instrument leaves what is shared to the arrangement.

The rule of this book, stated in Chapter 16 for what leaves the library, is to share the technique and the expected evidence and never the target mapping. In practice four things can leave and four cannot.

Can leave (FC-1 and FC-2) Stays inside (FC-3 and FC-4)
The technique identifier (ATT&CK or ATLAS) and the abstract scenario pattern Which systems the scenario ran against, and their names
Detection logic in a portable format such as Sigma (30, SigmaHQ, n.d.), with its data-source requirements and known false positives Which techniques are untested or failed, and the gap list
Aggregate results: share detected, share missed, in a class, without systems Finding text, evidence manifests, telemetry samples and tester identities
Indicators and observations in a structured form such as STIX (27, OASIS Cyber Threat Intelligence (CTI) TC, 2021) Tool configuration, credentials, internal naming and the register's structure

Marking follows the Traffic Light Protocol, version 2.0, whose labels distinguish information restricted to named recipients (TLP:RED), to the recipient's organisation and its clients on a need-to-know basis (TLP:AMBER) or only its organisation (TLP:AMBER+STRICT), to the community but not to publicly accessible channels (TLP:GREEN), and without limit (TLP:CLEAR) (48, FIRST, n.d.). Detection logic shared in a community is TLP:GREEN by default in this book, and TLP:CLEAR is a decision of the owner, because a published detection also tells an adversary what is detected. The protocol records that trade-off and who accepted it.

Two controls make the rule enforceable. The first is the sanitiser: a deterministic export that passes an allow-list of fields and drops everything else, the same pattern as the redaction gateway of Chapter 16. A model may draft the description of a detection at Level 1 Assisted; it never reads FC-3 or FC-4 material and it never releases anything. A person in the intelligence role releases each item at Level 2 Supervised, because publication cannot be undone, and no sharing agent works at Level 3 or above on any external release. The second control is the inbound rule. A rule, an indicator list or a scenario received from peers is text that others can write, and the SOC classifies inputs by who can write them (F101, AI Blue, Chapter 15) (94, Nordqvist, 2026). A received detection is a draft: it enters P4 as a proposed change, is tested against the organisation's own telemetry, carries its own regression case and counts toward coverage only after a local test. Having a peer's rule is not the same as being covered by it.

Worked example: A sector-sharing protocol (illustrative)

Hansa Mutual's protocol SHP-HM-2028-01 (AIDR-0879, 2028-03-01) governs its participation in an insurance-sector information-sharing community of 14 member groups. The first three items were released on 2028-03-08, among them the description of DET-HM-0612, the detection for an extra credential on a cloud service identity (T1098.001) merged on 2028-02-20.

# Illustrative: Hansa Mutual, sector information-sharing protocol
kind: SharingProtocol
id: SHP-HM-2028-01
decision: AIDR-0879
effective: 2028-03-01
community: insurance-sector information-sharing group (14 member groups)
legal_basis: [NIS2-Art29-arrangement, DORA-Art45-arrangement]   # participation notified to competent authorities
owner: {role: threat-intelligence-cell, release_authority: head-of-cell, deputy: head-of-detection-engineering}
outbound:
  allowed_fields: [attack_technique, abstract_scenario_pattern, sigma_logic, data_source_requirement, known_false_positives, aggregate_result]
  classes_allowed: [FC-1, FC-2]
  default_marking: TLP:GREEN
  clear_release: requires CISO and recorded reason
  sanitiser: deterministic-export      # policy as code; drops every field not on the allow-list
  drafting: {mode: 4, level: 1, reads: [FC-1, FC-2]}   # draft text only; cannot release
  release: {by: person, level: 2, per_item: true}
  never: [system_names, gap_list, finding_text, evidence_manifests, tester_identities, tool_configuration]
inbound:
  treat_as: untrusted_input
  path: P4 proposed change -> local test -> regression case -> deployment
  counts_toward_coverage: only_after_local_test
  expiry_days: {priority_technique: 90, other: 180}
withdrawal: notify competent authorities and the community; stop outbound within one working day
review: 2028-09-01

Disclosure

A loop that finds things will, sooner or later, find something in a product it did not build. Disclosure runs in two directions, and each needs a route written before it is needed.

Giving: a vulnerability found in someone else's product or service

When a test, or an agent running a catalogued scenario, reveals a weakness in a supplier's product or a provider's service, three rules apply. The test stops at proof, the manifest having already excluded post-exploitation of third-party assets. The finding is registered as FC-4 while it is open, since it describes a weakness the organisation cannot fix itself. And it is reported through the channel the vendor or provider has published: the provider rules above name theirs (the Microsoft Security Response Center, AWS Security within 24 hours, Google's Vulnerability Reward Program), and a vendor's own security contact serves for products.

Where a vendor has no channel or does not answer, NIS 2 Article 12(1) provides one. Each Member State designates a CSIRT as coordinator for coordinated vulnerability disclosure, acting as a trusted intermediary between the person reporting and the manufacturer or provider, and its tasks include identifying and contacting the entities concerned, assisting the reporter and negotiating disclosure timelines; reporters may report anonymously, and the CSIRT coordinators cooperate within the CSIRTs network where several Member States are affected (3, European Union, 2022). ENISA maintains the European vulnerability database for publicly known vulnerabilities (Article 12(2)) (3, European Union, 2022) and (29, ENISA, 2025). The Cyber Resilience Act supplies the other side of the exchange. Manufacturers of products with digital elements must put in place and enforce a policy on coordinated vulnerability disclosure (Annex I, Part II, point 5) and, from 11 September 2026, must notify an actively exploited vulnerability to the CSIRT designated as coordinator and to ENISA, with an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours and a final report no later than 14 days after a corrective or mitigating measure is available (Article 14 and Article 71(2)) (5, European Union, 2024). Anyone other than the manufacturer may notify a vulnerability voluntarily to the CSIRT coordinator or ENISA, and the CSIRT coordinator informs the manufacturer where the vulnerability is actively exploited; voluntary reporting imposes no additional obligation on the notifier (Article 15). As architectural implications, the organisation that buys a product does not make the manufacturer's notification, but it can require in the contract that the manufacturer tells its customers, and it knows that a report it files about a product reaches the manufacturer through a route the law has defined.

If the loop finds evidence that a weakness is already being exploited against the organisation, the case leaves the exercise: the stop is called, the incident process starts, and the clocks of AI Blue, Chapter 19, run from the earlier awareness timestamp. An exercise finding and an incident are different records, and the manifest says which event converts one into the other.

Receiving: a report about your own estate

The reverse direction is as important and more often neglected. A researcher, a supplier or a resident may find something in the organisation's estate, including its AI systems, and needs somewhere to say so. The organisation publishes a vulnerability disclosure policy and a machine-readable contact file in the form of RFC 9116 (security.txt) (49, Foudil & Shafranovich, 2022); it acknowledges a report within a stated time; it keeps a register of the tags and sources of its own exercise traffic, so that an external report can be told from the activity of its own contracted tester; and it states its position on good-faith research. The last point is for national law and the organisation's counsel: recital 60 of NIS 2 encourages Member States to adopt guidelines on the non-prosecution of information security researchers (3, European Union, 2022), and what protection a reporter has differs by country. A public authority has the additional duty of public-access rules, under which a report and the organisation's reply may be requestable; the register of record and its classification (Chapter 16) already anticipate that.

Hansa Mutual's case shows both directions. During the weekly atomic runs, the simulation tool's collector, a vendor product, stored the exercise service account's token in a local log with permissive access (technique T1552.001, credentials in files). The weakness is the vendor's, the exposure is Hansa's. The finding FND-HM-2028-012 was opened on 2028-03-16 at FC-4, the token was rotated and the file permission corrected through configuration management the same day as the compensating step, the report went to the vendor's security contact on 2028-03-17 and was acknowledged on 2028-03-20. Hansa's policy, recorded in AIDR-0880 (2028-03-17), brings in the national CSIRT coordinator if there is no acknowledgement of substance within 30 days, and keeps the finding at FC-4 until the vendor's fix is released and a re-test with a variant passes, after which it moves to FC-3 (Chapter 16). The same record sets the inbound side: Hansa's disclosure policy and contact file, a 3 working day acknowledgement, and the tag register.

Cross-border

Hansa Mutual operates in seven legal regimes and runs one loop. The loop's design (the stage records, the closure rule, the profile) is the same everywhere; what varies is what a test may touch, who must be told, what may cross a border and who must be consulted. The table is illustrative and frames architectural implications, not legal advice; each entity's supervisor and counsel decide the actual requirement.

Entity What the loop does differently Source of the difference
Germany (headquarters) The threat-led test under RoE-HM-2027-TLPT follows the supervisor's framework; exercises with staff need advance information to the Konzernbetriebsrat under KBV-IT-2024-SOC-05 DORA Article 26; BetrVG co-determination
Netherlands, Sweden Works council or union consulted before an exercise that can monitor or involve staff; the local supervisor's expectations on threat-led testing National labour law; national supervision
Poland (service centre) Telemetry and findings from the claims service for four markets pass through it; its representatives are covered by the exercise clause Group data flows; local representation
Norway EEA entity; the timing of EU instruments can lag, so group policy applies the controls as policy until incorporation EEA Agreement
United Kingdom, Switzerland Outside DORA and the AI Act; the managed detection provider for these entities closes only classes SC-01 and SC-02; tests need the provider's consent under their own regimes; telemetry and findings cross the border on adequacy Local operational resilience regimes; transfer rules

Three design rules apply to the whole table. One loop, local manifests: the group's stage records and handling classes are the same, and each entity gets its own rules-of-engagement manifest or an annex to the group's, listing the local consents, notices and representatives. Transfers are a P3 constraint: GDPR Chapter V governs transfers of personal data to third countries (7, European Union, 2016), and a decision on transfers can decide what the loop can observe. In the session PRP-HM-2028-01 (Chapter 9) the Swiss audit log for technique T1098.001 was not forwarded pending a transfer decision, and the outcome was recorded as no telemetry, not as a pass. The loop treated a legal boundary as a coverage gap and registered it as one. Recognition has limits: TIBER-EU lets entities active in several jurisdictions take part in joint tests with several national cyber teams, and a test summary report and attestation facilitate mutual recognition (20, ECB, 2025). DORA Article 26(7) provides for an attestation that allows mutual recognition of threat-led tests between competent authorities (2, European Union, 2022). As the book's reading, the attestation serves the supervisors bound by the Regulation; the UK and Swiss entities' tests remain a matter for their own supervisors.

Public authorities face a different cross-border problem: not seven regimes but one, and many dependencies. Nordvik Region has one jurisdiction, procurement rules that fix lead times, public-access rules that classify its register, and providers that may sit in other countries. Its sovereignty claim is a set of properties (F47), among which the test right is one, and a provider whose model origin is unknown to the Region has not satisfied the risk position of AI Governance, Chapter 6 (F30). The protocol therefore asks the provider to declare the model family of any AI in the service, as MS-2-IND-1 did on 2028-03-07 (family F), because independence cannot be judged otherwise (Chapter 15).

Evidence to supervisors

A supervisor is a recipient of evidence, and the loop's records are the evidence. What matters is choosing what leaves, to whom and in what form. For a financial entity in scope of DORA, the end of a threat-led test brings a defined duty: after reports and remediation plans have been agreed, the entity and the external testers provide to the authority a summary of the relevant findings, the remediation plans and the documentation demonstrating that the test was conducted in accordance with the requirements, and the authority provides an attestation (Article 26(6) and (7)). The scope of the test is validated by the competent authorities (Article 26(2)), and where third-party providers are in scope the entity takes the measures to ensure their participation while remaining fully responsible (Article 26(3)) (2, European Union, 2022). The regulatory technical standards specify scope, methodology, closure and remediation, and cooperation with the supervisor (8, European Commission, 2025); Chapter 21 treats them. The TIBER-EU purple teaming guidance describes a purple phase within a test and the evidence it produces (34, ECB, 2025).

For an entity outside that regime, the pull is weaker and the principle the same. NIS 2 Article 21(2)(f) lists policies and procedures to assess the effectiveness of cybersecurity risk-management measures, and the management body that approves them under Article 20 will want evidence (an architectural implication, not a prediction of supervisory practice) (3, European Union, 2022). Nordvik's audit committee asked in January 2028 what the first exercise proved (AIDR-0800); its competent authority can ask the same.

The package the loop assembles is the same set of records in a form that fits the recipient.

Item Source record Handling Recipient
Scope and plan, with the approval reference RoE-* manifest, EMU-* plan FC-2 Supervisor; audit committee
Summary of findings by class and state, with age Register view of the five states (Chapter 4) FC-2 Supervisor; board
Remediation plans and closure evidence CHG-*, REG-*, EVD-* FC-2 (summary), FC-3 (detail on request) Supervisor
Independence statement and delegation profile IND-*, DLG-* FC-2 Supervisor; auditor
Coverage record with evidence age COV-* (Chapter 17) FC-2 as a summary Board; supervisor
The gap list and exploitable detail Register, FC-4 Inspected on the organisation's premises or in a read-only view, not copied Supervisor on request, under its own confidentiality

The last row is a decision, not a convention. A supervisor has the authority to demand it, the organisation has a duty to protect it, and the design that serves both is a view the supervisor can read without a copy leaving the register. The record of what the supervisor viewed, and when, is itself evidence. For Hansa Mutual, AIDR-0880 and AIDR-0881 (2028-03-17, 2028-03-24) also set the order of precedence among the group's seven supervisors: the lead supervisor's attested summary is the group's base package, and each local supervisor receives it with the local annex.

Observable, expected, speculation

Observable. That cloud providers publish testing rules which differ and change, that sector exercises report weak spots in cross-border information exchange, that NIS 2 and DORA provide for information-sharing arrangements, and that the Cyber Resilience Act's reporting obligations for manufacturers apply from 11 September 2026 are observable.

Expected. That standardised injected-test and consent clauses become ordinary terms in managed-service contracts, as the illustrative annex MS-2 is for the two organisations, is expected, on the trend of buyers' guidance and the contractual provisions required of providers that support critical or important functions.

Speculation. That a provider's emulation agent will test a customer's detection agent across a boundary under a machine-readable consent, with the stop right exercised automatically, is speculation: no source reviewed for this book documents it. The book's own conclusion is narrower than any of these, and it is not a prediction: whatever the instrument, a boundary crossing is trustworthy when consent, notice and stop are recorded and drilled, and when what leaves the organisation is chosen by a person from a short list.

Across the usage modes

Mode Where it appears at a boundary What the loop requires
Mode 0 Ambient AI A managed provider's or vendor's embedded AI Disclosed in the contract with its model family; testable through injected tests; autonomy not assumed
Mode 1 Conversational assistants A practitioner drafts a disclosure or sharing text FC-1 and FC-2 only into hosted tools; a person reviews before release
Mode 2 Embedded workplace assistants An assistant in the ticket or mail system used for a vendor report Inherits the person's access; no FC-4 material; the person sends
Mode 3 Agentic work tools A tool that fills in a provider's form or portal Not used for notices or disclosures; a person submits
Mode 4 Built AI applications The sharing drafter and the sanitiser; the observation correlator Own identity; allow-listed fields; read FC-1 and FC-2; no release
Mode 5 Autonomous production agents The emulation runner crossing a provider boundary Reads consent and window fields from the manifest at the policy decision point; no run outside a noticed window; stop reachable by the provider

Across the degrees of delegation

Action across a boundary Ceiling Who holds it
Run a catalogued S1 scenario in the organisation's own scope inside a noticed window Level 3 Bounded The manifest, enforced outside the runner
Run a seed through a provider's pipeline under an annex Level 2 Supervised Purple-team coordinator; white team
Any scenario that reaches a provider's own service Not delegated; stop and report White-team lead
Draft a sharing item or a disclosure Level 1 Assisted Intelligence role
Release an item to a community, a CSIRT, a vendor or a supervisor Level 2 Supervised at most, per item, by a person Release authority named in the protocol
Decide to disclose publicly Not delegated CISO

Level 4 is never used for any of these: each either leaves the signed scope, cannot be undone, or both.

Nordvik Region and Hansa Mutual

Nordvik Region needs its managed provider's consent for every test of the out-of-hours chain, and its leverage is the contract. AIDR-0829 adopts CNP-NR-2028-01 and clause MS-2-TST-1; AIDR-0830 (2028-04-04) adopts its disclosure practice, a published policy and contact file for reports it receives and the rule that a weakness found in a supplier's product goes to the supplier and, failing an answer, to the national CSIRT coordinator; AIDR-0831 (2028-04-11) adopts the Region's participation in the regional-government information-sharing group at TLP:GREEN, limited to technique and expected evidence, with participation notified to the competent authority if the Region is in scope of NIS 2 as transposed.

Hansa Mutual shares detections with a sector group under SHP-HM-2028-01 (AIDR-0879) and handles seven regimes with one loop. AIDR-0880 (2028-03-17) records the disclosure routing of FND-HM-2028-012 and the receiving policy; AIDR-0881 (2028-03-24) adopts CNP-HM-2028-01, the consent and notice protocol for the managed detection provider of the UK and Swiss entities and for the cloud providers, first used for seeds in classes SC-01 and SC-02 in the window 2028-04-10 to 2028-04-21, and the order of the supervisor package. Its constraints are the DORA third-party duties for every testing and simulation service, the transfer rules for UK and Swiss telemetry, and works-council consultation in three countries.

Summary

The loop crosses the boundary of the organisation in three ways that need different permissions: through a provider's pipeline, through its response chain, and against its platform, which no manifest includes. P2 Emulate across a boundary needs standing consent in the contract, window notice before each run, and a stop held outside the system being stopped on both sides; the cloud providers' published rules differ, change and in one case name red, blue and purple team tests as a category and require a form for covert adversarial simulations, so the protocol records the page, the date and the form. Every rule has a clause that turns a finding in the provider's service into a duty to stop and report.

P3 Observe across a boundary depends on the provider's clock and on what a legal boundary lets the loop see; a log that cannot cross a border is a coverage gap, recorded as one. P4 Improve is a request when the change belongs to a provider, and the proof is an injected test. Sharing with peers is a choice of fields: technique, detection logic and aggregate results leave through a deterministic sanitiser and a person's release; the target mapping, the gap list and the findings do not, and what comes back in is untrusted input and a draft. Disclosure runs in two directions through routes written in advance: to a vendor or provider, to the CSIRT coordinator under NIS 2 Article 12, and, for manufacturers, under the Cyber Resilience Act; and from a researcher to the organisation's own published channel.

Supervisors receive the loop's records in a form that fits them: scope and plan, findings by state and age, remediation and closure evidence, the independence statement and the coverage with its expiry, with the gap list inspected and not copied. Chapter 21 treats the regulation in full. Chapter 23 turns from the boundaries between organisations to the people inside the loop, and the trust, incentives and wellbeing of the red and blue practitioners who run it.

Sources

  1. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 (DORA). (2, European Union, 2022)
  2. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  3. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act). (5, European Union, 2024)
  4. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (GDPR). (7, European Union, 2016)
  5. European Central Bank. TIBER-EU framework. (20, ECB, 2025)
  6. OASIS CTI TC (2021). STIX Version 2.1 and TAXII Version 2.1. (27, OASIS Cyber Threat Intelligence (CTI) TC, 2021)
  7. European Union Agency for Cybersecurity (2025). European Vulnerability Database (EUVD). (29, ENISA, 2025)
  8. SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. (30, SigmaHQ, n.d.)
  9. Nordqvist, G. (2026). AI Governance. (88, Nordqvist, 2026)
  10. Nordqvist, G. (2026). AI Platform and Security. (89, Nordqvist, 2026)
  11. Nordqvist, G. (2026). AI Red Team. (90, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Blue. (94, Nordqvist, 2026)
  13. European Commission (2025). Commission Delegated Regulation (EU) 2025/1190. (8, European Commission, 2025)
  14. Microsoft. Penetration testing (Azure security fundamentals). (79, Microsoft, 2026)
  15. European Central Bank (2025). TIBER-EU Purple Teaming Guidance. (34, ECB, 2025)
  16. Amazon Web Services. Penetration Testing. (83, AWS, 2026)
  17. Google Cloud. Cloud Security FAQ. (84, Google Cloud, n.d.)
  18. Forum of Incident Response and Security Teams. Traffic Light Protocol (TLP), version 2.0. (48, FIRST, n.d.)
  19. European Union Agency for Cybersecurity (2024). Cyber Europe 2024: After Action Report. (58, ENISA, 2024)
  20. Foudil, E. & Shafranovich, Y. (2022). A File Format to Aid in Security Vulnerability Disclosure (security.txt). RFC 9116. (49, Foudil & Shafranovich, 2022)
  21. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion. (73, Larcher et al., 2026)