Regulation as Constraint: DORA, TIBER-EU, NIS 2, the AI Act, the GDPR and Employee Rights

An emulation is an authorised attack on one's own estate, and the law has views on every word of that sentence: who may authorise, who may be the tester, which systems may be touched, what happens to personal data, which people must be told and which must not, and what must be reported if the exercise goes wrong. This chapter sets out that frame for the two stages it constrains most directly, P1 Target, where the scenarios and the rules under which they may run are chosen, and P2 Emulate, where adversary behaviour is run by people, AI-assisted tooling or a pipeline. It also marks where the instruments reach P3 Observe, P4 Improve and P5 Verify, because the duty to remedy and to assess effectiveness does not stop when the window closes.

Each statement below is attributed to an instrument and an article and read as an architectural implication: what a manifest, a policy decision point, a register or a contract has to contain so that the organisation can show it acted within the frame. None of it is legal advice, and national law decides where the chapter names a national example. The article numbers were checked against the official texts when the chapter was written; the practical guide makes that check a recurring control, because the text moves.

Instruments in three groups attached to the stages they govern most directly: DORA and NIS 2 at P1, P2 and P4; the AI Act and the Cyber Resilience Act at P2 and P4; the GDPR, co-determination and criminal law at P2 and P3. The articles are in the table of this chapter.

Figure 21.1: The instruments that constrain the loop, in three groups, each attached to the stages it governs most directly.

The chapter builds on conclusions that earlier volumes recorded: that in public authorities legality comes before capability (AI Governance, Chapter 17; F31) (88, Nordqvist, 2026); that reporting deadlines are design constraints on the logs (AI Platform and Security, Chapters 17 and 21; F46) (89, Nordqvist, 2026); that regulation places duties on named people (3, European Union, 2022) and cannot be delegated to a system (The Transformed Security Architect, Chapter 18; F78) (92, Nordqvist, 2026); that co-determination and data-protection law govern the monitoring of staff (11, Bundesrepublik Deutschland, n.d.) (7, European Union, 2016) (AI Boss, Chapters 13 and 23; F86) (93, Nordqvist, 2026); and the mapping of the instruments onto the blue team as clocks, records and named people (AI Blue, Chapter 19; F106) (94, Nordqvist, 2026). The chapter does not repeat the clocks; it adds the regulation of testing, testers, exercise data and exposed staff, and the criminal-law line that authorisation draws.

Which regime applies to whom

The two organisations stand in different places, and the difference decides which sections below are law for them and which are borrowed practice. Nordvik Region is a regional public authority. NIS 2 applies to public administration entities at regional level that a Member State has defined and that provide services whose disruption could have a significant impact on critical societal or economic activities (Article 2(2), point (f)) (3, European Union, 2022); the book assumes the Region is within that definition. DORA does not apply to it, so threat-led testing is practice it may borrow and no supervisor requires.

Hansa Mutual is a group of insurance entities, and its German entity is a financial entity within DORA (2, European Union, 2022). Where a sector-specific Union act is at least equivalent in effect to NIS 2, NIS 2 Article 4(1) disapplies the corresponding provisions for those entities; whether the equivalence is met is a question for counsel and the authority. Hansa's UK and Swiss entities answer to their own law.

Both organisations are within the GDPR, employ staff under national labour law and use AI systems to which the AI Act applies; those are the common ground of the chapter.

DORA and threat-led penetration testing

DORA devotes a chapter to digital operational resilience testing, and its structure matches the loop closely. Financial entities other than microenterprises must establish, maintain and review a testing programme as part of the ICT risk-management framework, on a risk-based approach (Article 24(1) and (3)); Article 25(1) names scenario-based tests and penetration testing among its tests (2, European Union, 2022). Three paragraphs of Article 24 bear directly on the book. Article 24(4) requires tests to be undertaken by independent parties, internal or external, with conflicts of interest avoided; it is the legal ancestor of the independence principle (Chapter 15), which goes further by requiring independence between the AI on the two sides of a check. Article 24(5) requires procedures to prioritise, classify and remedy all issues revealed by tests and internal validation to ascertain that all identified weaknesses are fully addressed, which is the closure rule of Chapters 4 and 11 in regulatory form. Article 24(6) requires appropriate tests at least yearly on systems supporting critical or important functions, a floor that prescribes no technique and does not say that continuous testing is required or sufficient.

Advanced testing is in Article 26. Entities that the competent authorities identify, on the criteria of Article 26(8), must carry out threat-led penetration testing (TLPT) at least every three years, a frequency the authority may change (Article 26(1)). Each TLPT covers several or all critical or important functions and is performed on live production systems (Article 26(2)). The entity must ensure that ICT third-party providers in scope take part and remains fully responsible (Article 26(3)), applies risk-management controls against impact on data, damage to assets and disruption (Article 26(5)), and at the end gives the authority a summary of findings, remediation plans and documentation and receives an attestation that allows mutual recognition (Article 26(6) and (7)). Article 27 requires testers of the highest suitability and reputability, with specific expertise, certified or adhering to formal codes of conduct and insured against misconduct and negligence (Article 27(1)); internal testers need the authority's approval and an external threat intelligence provider (Article 27(2)).

The method of the test is set by Commission Delegated Regulation (EU) 2025/1190, published on 18 June 2025, which mirrors TIBER-EU (8, European Commission, 2025), and DORA applies from 17 January 2025. The entity appoints a control team lead responsible for the day-to-day management of the test (Article 4(1)). Knowledge of a test is limited on a need-to-know basis to the control team, the management body, the testers, the threat intelligence provider and the authority; the control team consults the test managers before involving any blue team member, is informed of any detection, and contains any resulting escalation (Article 4(2)). The testers must meet experience and reference requirements, must not modify assets in an uncontrolled way, compromise the continuity of critical functions intentionally or include out-of-scope systems, and must restore, including command-and-control deactivation and scope and date kill switches (Article 7(1)). At least three scenarios are selected (Article 10(3)); the active phase lasts at least twelve weeks (Article 11(5)); and the control team lead may suspend the test (Article 11(10)). In the closure phase the blue team is told, the blue team reports within ten weeks, and the blue team and testers replay the actions while the control team conducts a purple teaming exercise on topics jointly identified (Article 12(1), (4) and (5)).

Five consequences follow for the loop.

A TLPT is a regulated project that the loop receives, not a form of the loop. The closure phase makes the replay and a purple teaming exercise mandatory, which is P3 Observe and P4 Improve by another name. The attestation and remediation plan are evidence for the supervisor; the finding, regression case and evidence manifest of P5 Verify are the entity's own evidence that the remediation worked.

Continuous emulation is not a TLPT, and the manifest says so. A TLPT is covert towards the blue team, threat-led, run by testers who meet Article 27, active for at least twelve weeks and closed by an attestation. A rolling pipeline of catalogued S1 scenarios (Chapter 8) is known to the SOC, catalogue-led and unattested; it belongs to the programme of Articles 24 and 25 and to the entity's own assessment of effectiveness. RoE-HM-2028-001, the manifest of HM-SEC-004, and RoE-HM-2027-TLPT are therefore separate instruments with separate authorities, and the evidence of one is never presented as the evidence of the other. The Delegated Regulation treats purple teaming during the active phase as a limited last resort, validated in advance by the authority (Article 11(10) and recital 23, which names catch-and-release, war gaming and collaborative proof of concept).

Covertness and a continuous pipeline interfere, and the interference is designed away. A pipeline that keeps running against systems under a TLPT can mask the test, reveal it by the pattern of its own tagged traffic or contaminate the evidence. Hansa's decision AIDR-0877 (2028-03-13) creates a hold list, HLD-HM-TLPT-01, populated by the control team lead alone and read by the policy decision point of HM-SEC-004: systems on it are removed from the pipeline's targets for the active phase, and the pipeline's operators see that a hold exists but not what it contains. The control team lead also owns the channel by which the SOC's deconfliction reaches the control team (Article 4(2), points (b) and (c)).

The Regulation says nothing about AI, and the tester remains a person and a firm. The Delegated Regulation contains no provision on automated tools or AI. Its conditions on testers concern people and organisations: curricula vitae, certifications, references, experience and insurance (Article 7(1)). The book's own conclusion is that an agent used in a TLPT is the tester's tool: the named testers remain responsible, the control team approves its use in the red team test plan, and the authority sees it described there. Whether a supervisor accepts a Mode 5 emulation agent in a threat-led test is a question the organisation puts to the authority before it plans.

Third parties are brought in by contract. DORA requires contracts for services that support critical or important functions to include the provider's obligation to participate and fully cooperate in the entity's TLPT (Article 30(3), point (d)), and a register of information on all contractual arrangements (Article 28(3)). As Chapter 6 concluded, the rules of engagement of a supervised test cite the clause that makes participation possible, and a provider whose contract lacks it is a gap in scope that the entity closes before the authority validates the scope.

TIBER-EU and the national frameworks

TIBER-EU is the European Central Bank's framework for threat intelligence-based ethical red-teaming (20, ECB, 2025). Chapter 2 described its participants; the one that matters here is the control team, the small team in the tested entity that alone knows the test is happening. The framework was updated to align with the DORA technical standards, and it is adopted in a number of Member States including Germany and Sweden, where national teams run the tests with the entities in their jurisdictions. DORA itself directs that the technical standards follow TIBER-EU (Article 26(11)), which is why the Delegated Regulation reads like a legal form of the framework.

Two points matter for this book. The first is vocabulary: earlier TIBER-EU documents, including the 2022 purple teaming best practices (122, ECB, 2022), called the governing body the White Team, while the current framework, the January 2025 purple teaming guidance (34, ECB, 2025) and the Delegated Regulation call it the control team. The book keeps "white team" for the role in any exercise (Chapter 7); in a TLPT the white-team lead is the control team lead. The second is purple teaming, which the January 2025 guidance treats as a standard element of the closure phase (34, ECB, 2025) and which the Delegated Regulation now makes a required step of closure (Article 12(5)), so that for an entity in scope the purple session after a threat-led test is an obligation.

The national variants matter because the authority that validates scope, selects test managers and issues the attestation is national (Article 26(9) and (10) of DORA). Hansa Mutual runs its German test under TIBER-DE, an arrangement the book marks as illustrative, and mutual recognition of the attestation (Article 26(7)) is what makes a joint test possible. Nordvik Region has no TLPT authority and no attestation; TIBER-EU can be used by entities in all critical sectors (20, ECB, 2025), and the Region borrows its roles by contract.

NIS 2

NIS 2 is addressed to Member States, which transpose it, so the national law is the operative text. Three provisions carry the weight for the loop.

Article 20(1) requires Member States to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements of Article 21, without prejudice to national rules on public institutions and officials; Article 20(2) requires them to follow training (3, European Union, 2022). The person who signs the rules of engagement is therefore identifiable, the record shows what the management body delegated to the CISO, and nothing in Article 20 moves to a tool.

Article 21(2) lists the minimum measures on an all-hazards basis. Point (f), policies and procedures to assess the effectiveness of cybersecurity risk-management measures, is the one that concerns the loop; points (d) and (e) name supply-chain security and vulnerability handling and disclosure. Article 21(4) requires an entity that finds it does not comply to take, without undue delay, all necessary, appropriate and proportionate corrective measures. The Directive does not prescribe a technique for assessing effectiveness and does not mention red teaming or emulation, so no reader should say that NIS 2 requires a purple loop. What the loop provides is an evidenced answer to the question that point (f) poses: a record of what was tested, when, with what result, and what changed (Chapters 11 and 17). That is the book's own conclusion and an architectural implication, not a statement of the Directive. The urgency classes of Chapter 10 (14, 30 and 90 days) record each corrective measure and date for Article 21(4).

Article 23 matters when an exercise becomes an incident: if a scenario causes or is capable of causing severe operational disruption or considerable damage to others, it may be a significant incident (Article 23(3)), with an early warning within 24 hours and a notification within 72 hours (Article 23(4)). After any stop involving real impact the white team asks the incident process whether a clock has opened. Managed security service providers are named in Article 21(5) among the providers for which Implementing Regulation (EU) 2024/2690 sets technical requirements (4, European Commission, 2024), which is relevant to Nordvik's out-of-hours provider and the Region's test rights under annex MS-2.

The AI Act

The AI Act touches the loop in four places, and its dates need care.

First, the systems under test. The Regulation excludes testing before a system is placed on the market, but not testing in real-world conditions (Article 2(8)) (1, European Union, 2024). High-risk AI systems must achieve appropriate accuracy, robustness and cybersecurity throughout their lifecycle (Article 15(1)), be resilient to errors and faults, in particular from interaction with people or other systems (Article 15(4)), and resist unauthorised third parties who try to alter their use, outputs or performance, with measures against data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws where appropriate (Article 15(5)). The provider tests against prior defined metrics before placing the system on the market (Article 9(6) and (8)). The deployer uses the system according to its instructions, assigns competent human oversight, monitors operation and informs the provider and the market surveillance authority of a risk, keeps the logs under its control for at least six months, and informs workers' representatives and affected workers before workplace use (Article 26(1), (2), (5), (6) and (7)). Adversarial testing of a deployed system (Chapter 12) gives the deployer evidence that it monitors operation and that the provider's claims hold in its context, and its findings are information for the provider. The exercise must not alter outputs that affect a person, which is why Nordvik excludes the production scoring of the benefits-triage system, an Annex III system, from its rules of engagement.

Second, general-purpose models with systemic risk. Their providers must perform model evaluation, including conducting and documenting adversarial testing to identify and mitigate systemic risks, report serious incidents and ensure adequate cybersecurity protection (Article 55(1), points (a), (c) and (d)), and may rely on a code of practice until a harmonised standard is published (Article 55(2)) (6, European Commission, 2025). These duties fall on the model provider and not on a deployer such as Hansa or Nordvik. Their consequence is contractual: the deployer asks for the documented adversarial testing in its procurement clause (AI Threat, Chapter 19, gives the pattern in HM-PROC-GPAI-MISUSE-01) (91, Nordqvist, 2026) and states in its own rules of engagement what it tests in its deployment on top of what the provider tested in the model.

Third, the dates. The Regulation applies from 2 August 2026, and the general-purpose AI obligations of Chapter V, including Article 55, from 2 August 2025 (Article 113, third paragraph, point (b)). Regulation (EU) 2026/1744, the Digital Omnibus on AI, published on 24 July 2026, replaced point (c): the requirements of Chapter III, Sections 1 to 3, which include Articles 9, 15 and 26, apply from 2 December 2027 for systems high-risk under Article 6(2) and Annex III and from 2 August 2028 for those under Article 6(1) and Annex I (9, European Union, 2026). A register that relied on 2 August 2026 for Annex III systems would be wrong. For the book's year, which begins in January 2028, Article 15 applies to Nordvik's Annex III benefits-triage system.

Fourth, the exercise's own content. Deployers of an AI system that generates or manipulates image, audio or video content constituting a deep fake must disclose that it is artificially generated or manipulated; the exemption that matters for a loop is use authorised by law to detect, prevent, investigate or prosecute a criminal offence, and evidently artistic, creative, satirical or fictional works carry a lighter disclosure duty (Article 50(4)) (1, European Union, 2024). Article 50 applies from 2 August 2026, and the Omnibus does not change paragraph 4 (9, European Union, 2026). The text has no exemption for security testing, and a deepfake approval test whose participants must not know the content is synthetic sits uncomfortably beside a duty to disclose. The book leaves the question to counsel and records two responses: deepfake scenarios stay in safety class S4 on the range (Chapter 6), and the question is an open register entry with a named owner. Nordvik's AIDR-0827 (2028-03-14) holds the next deepfake scenario until its counsel has said how disclosure can be made to participants and representatives without defeating the test. A loop agent that scored named employees would also raise the classification question of Annex III, point 4 (1, European Union, 2024); the rule of Chapter 14 that no loop agent targets or scores a named person keeps the loop outside it.

The Cyber Resilience Act

The Cyber Resilience Act, Regulation (EU) 2024/2847, regulates products with digital elements and their manufacturers (5, European Union, 2024). It reaches the loop from two directions: what the organisation does when an exercise finds a vulnerability in someone else's product, and what it must do when the product is its own.

A manufacturer must handle vulnerabilities effectively during the support period according to Part II of Annex I (Article 13(8)), which requires among other things regular tests of the product's security (point 3), a coordinated vulnerability disclosure policy (point 5) and a contact address for reports (point 6). Article 14, which applies from 11 September 2026 although most of the Regulation applies from 11 December 2027 (Article 71(2)), requires notification of an actively exploited vulnerability through the single reporting platform: an early warning within 24 hours, a notification within 72 hours and a final report no later than 14 days after a corrective or mitigating measure is available (Article 14(1) and (2)). The definition matters for the loop: an actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it without the permission of the system owner (Article 3). An authorised exercise exploits with permission and does not by itself open the clock; evidence that a real actor used the same weakness does, and the finding record carries a clock field for it. A finding in software the organisation places on the market is also a patch decision, which AI Governance, Chapter 24, concluded must be delegated in advance (F29) (88, Nordqvist, 2026).

For a vulnerability in a third party's product, anyone may notify voluntarily the CSIRT designated as coordinator or ENISA, and doing so imposes no additional obligation on the notifier (Article 15(1) and (5) of the CRA). NIS 2 Article 12(1) names the same route: the coordinating CSIRT acts as a trusted intermediary, contacts the entities concerned and negotiates disclosure timelines (3, European Union, 2022). The architectural implication is a clause in the rules of engagement: a vulnerability in a product the organisation does not make is not published, is not exploited beyond the proof the scenario needs, and is routed by the white team to the manufacturer or the coordinating CSIRT, with a record. Chapter 22 treats disclosure across the organisation's boundary in both directions.

The GDPR and exercise data

Exercise data is personal data more often than the plan suggests: log lines, account names, mailbox content, screenshots, the transcripts of an agent that touched a system. Chapter 6 set the design rules; this section places them under the Regulation.

The principles of Article 5(1) apply: purpose limitation (point (b)), data minimisation (point (c)) and storage limitation (point (e)), and the controller must be able to demonstrate compliance (Article 5(2)) (7, European Union, 2016). The lawful basis is recorded in the manifest. A public authority cannot rely on legitimate interests for processing in the performance of its tasks (Article 6(1), last subparagraph), which is why Nordvik records the public task, Article 6(1)(e). A private entity such as Hansa Mutual may record legitimate interests, Article 6(1)(f), with a documented balancing test, and may add that Article 32(1)(d), a process for regularly testing, assessing and evaluating the effectiveness of security measures, makes testing an expected part of the processing's security. That is a reading, not a holding.

Three further provisions have design consequences. A tester who handles personal data on the organisation's behalf is a processor and needs a contract under Article 28; the call-off agreement NR-2026-071 carries those terms. Where an exercise is likely to result in a high risk to individuals, an impact assessment is required before the processing (Article 35(1)) with the data protection officer's advice (Article 35(2)); the register holds a reference, not an assurance. And if an exercise reaches real personal data outside its authorisation, whether it is also a personal data breach, with the 72-hour notification of Article 33(1), is decided by the incident process and not by the exercise team.

Staff and their representatives

Some exercises involve staff, and the instruments above give only part of the answer. The GDPR leaves Member States to make more specific rules, by law or collective agreement, for the processing of employees' data, with suitable measures to safeguard dignity and fundamental rights, with particular regard to transparency and monitoring systems at the workplace (Article 88) (7, European Union, 2016). Two national examples are used.

In Germany the works council co-determines, where no statute or collective rule exists, the introduction and use of technical devices designed to monitor the behaviour or performance of employees (BetrVG § 87(1), no. 6) (11, Bundesrepublik Deutschland, n.d.). The statute's word is "bestimmt"; the Federal Labour Court holds, in its decisions of 8 March 2022 (1 ABR 20/21) and 16 July 2024 (1 ABR 16/23), that a device is "bestimmt" for monitoring when it is objectively suitable to collect and record information on the behaviour or performance of employees, and that the employer's intention to monitor is irrelevant (16, Bundesarbeitsgericht, 2022) (121, Bundesarbeitsgericht, 2024). That is why Hansa's works agreement covers the SOC's tools and the loop's. In Sweden an employer bound by a collective agreement must negotiate on its own initiative with the union before deciding an important change in its activity or in members' employment conditions (Lag (1976:580), 11 §), and the union may require negotiation in other matters concerning a member (12 §) (15, Sveriges riksdag, 1976). Nordvik's union agreement follows the pattern of that Act; the Swedish text is the example.

The consequence, as in AI Boss for monitoring systems generally, is that agreements govern classes of exercise and not single dates. Exercises on systems only need the general information the organisation gives about security testing. Exercises that involve staff action (social engineering, a deepfake approval test, a mailbox exercise) are class S4, run on the range or with the consent and notice the agreement requires, and reported in aggregate, never by name. A threat-led test is a third class with a difficulty: Article 4(2) of the Delegated Regulation requires secrecy towards the blue team, so the representatives cannot be told the date. Hansa's AIDR-0878 (2028-03-20) records the answer agreed with the chair of the Konzernbetriebsrat, Thomas Brandt: each January the representatives are told that a threat-led test may take place during the year, which systems of work it may touch and what it will not measure, but not when; no individual is named (Chapter 23 sets the rule that no result enters an appraisal), and clause KBV-IT-2024-SOC-05 applies to its results as to the quarterly sessions.

Nothing in this chapter describes monitoring of staff without their representatives' knowledge or any attempt to defeat their rights; an exercise that cannot be run within those rights is not run.

Criminal law and the written authorisation

An emulation does what, without authority, is a criminal offence. The Directive on attacks against information systems requires Member States to criminalise, when committed intentionally and without right, illegal access where a security measure is infringed (Article 3), system interference (Article 4), data interference (Article 5), interception (Article 6) and the making available of tools intended to commit those offences (Article 7) (10, European Union, 2013). The element that carries the weight is "without right": conduct not authorised by the owner or another right holder of the system or of part of it, or not permitted under national law (Article 2(d)). The owner's authorisation is part of the definition of the offence and not a defence added afterwards.

The national offences follow the pattern. The German Criminal Code punishes whoever, without authorisation (unbefugt), obtains access to specially protected data not intended for them by overcoming the access protection (§ 202a StGB) (12, Bundesrepublik Deutschland, n.d.), and the preparation of that offence by, among other acts, making accessible passwords or computer programs whose purpose is to commit it (§ 202c StGB) (13, Bundesrepublik Deutschland, n.d.). The Swedish Criminal Code punishes whoever unlawfully (olovligen) gains access to data intended for automated processing or alters, erases, blocks or enters such data (4 kap. 9 c §) (14, Sveriges riksdag, 1962). The national text is the authority; "unbefugt" and "olovligen" are where the signed authorisation does its work.

Four consequences follow for the manifest. First, authorisation comes from the owner or right holder of each asset, which is why the manifest carries a consent field per boundary (Chapter 6): the CISO's signature covers the Region's own systems and not the MSSP's platform, the cloud provider's infrastructure, a SaaS vendor's product or a member of staff's personal device. Second, the authorisation is bounded in time and scope, and conduct outside the bounds is outside it; the default-deny policy decision point is therefore also a legal control, and its decision log is the proof that the emulation stayed inside. Third, an emulation agent that left its scope would be acting without right, and who answers is a question for national law that the book does not settle; the sound design is that the question does not arise, because the agent's actions are enforced from outside it and the people who authorised its mandate are named. Fourth, a signed authorisation is evidence of authority and not a guarantee of immunity: testers and staff are protected in practice by an authorisation that is specific, current and followed.

Design consequences: from instrument to control

Across the instruments, each obligation resolves into a field in a manifest, a rule in a policy decision point, a record in a register or a clause in a contract, with an owner and a date. The practical guide turns that pattern into a method, and the worked example shows the result for the two organisations.

What can be undone, and who can stop it. The frame agrees with the book on both. DORA requires risk controls against impact on data, damage to assets and disruption (Article 26(5)); the Delegated Regulation requires restoration, scope and date kill switches and removal of tooling (Article 7(1), points (g) and (h)) and lets the control team lead suspend the test (Article 11(10)). The stop paths of Chapter 6 are the book's answer.

Purpose. To make each legal obligation that touches the loop appear in a record that a supervisor, an auditor or a works council can follow, and to keep the record true when the text changes.

Roles. The white-team lead owns the register. The CISO signs it for the management body. The data protection officer reviews entries on personal data, counsel reviews the restatement of each obligation, and the employee representatives review entries that touch staff.

Steps.

  1. Name the instrument, article, paragraph and point, and the date on which the live text was read. Copy the numbers from the text and not from a summary, because secondary summaries are a known source of wrong article numbers.
  2. Restate the obligation in one sentence in architectural terms, naming the addressee (entity, management body, provider, manufacturer, deployer). For a Directive, name the national transposition relied on.
  3. Name the stage the obligation constrains and the control that meets it: a manifest field, a policy-point rule, a contract clause, a runbook step or a record.
  4. Name the evidence artefact, its holder and its age limit. An obligation met by a document has an evidence age equal to the document's term; one met by a technical control has an age equal to the control's test interval.
  5. Name the owner, a deputy and the review date: six-monthly by default, and on any amendment, any change of the organisation's classification under the instrument and any change of national transposition.
  6. Mark an entry open where the answer is not known, with the question and the person who will answer it. An open entry is a legitimate state; an entry that claims compliance without a control is not.
  7. Have counsel confirm the restatement and the representatives the entries on staff, and record both.
  8. At each review, compare the stored consolidation date of each text with the live one; a changed date opens a review.

Defaults. Six-monthly review; 180 days of evidence age for a document, 90 days for a technical control; adapt to the supervisor, the works agreement and the risk appetite.

Definition of done. Every instrument in Figure 21.1 that applies has at least one entry; every entry has a control, an evidence artefact with an age, an owner and a review date; every open question has an owner; and the management body has been told in the report on the loop which entries are open.

Worked example: Obligation registers for the two organisations

The first record is Nordvik Region's register OBL-NR-2028-01, adopted by AIDR-0826 on 2028-03-07, six-monthly review (next 2028-09-01); the table is illustrative.

Obligation Instrument Stage Control Evidence Owner
Management body approves and oversees the measures and can be held liable NIS 2 Article 20(1) P1, P2 Rules of engagement signed by the CISO under written delegation from the management body; charter LOOP-NR-2028-01 Signature record, AIDR-0802 CISO
Policies and procedures to assess effectiveness NIS 2 Article 21(2)(f) P3, P5 Coverage records and evidence manifests with an age COV-NR-*, EVD-NR-* Karin Lund
Corrective measures without undue delay NIS 2 Article 21(4) P4 Urgency classes of 14, 30 and 90 days; escalation at twice the target Findings register POL-NR-FND-01 Karin Lund
Authorisation by the owner of each asset Directive 2013/40/EU Article 2(d); national offence (Swedish example: Brottsbalken 4 kap. 9 c §) P2 Consent field per boundary (MSSP, cloud provider); default-deny policy point Signed RoE-NR-* with consent records Deputy CISO
Lawful basis and minimisation of exercise data GDPR Articles 5(1)(c), 6(1)(e), 35 P2, P3 Synthetic accounts; basis and impact-assessment reference in the manifest Manifest block, data protection officer review Data protection officer
Negotiation before important change; exercises that involve staff pattern of Lag (1976:580) 11 §; union agreement P2 Ten working days' written notice; aggregate reporting only Notice record CISO's delegate
Disclosure of vulnerabilities in third-party products NIS 2 Article 12(1); CRA Article 15 P4 White team routes to manufacturer or coordinating CSIRT Disclosure record Deputy CISO
Disclosure of synthetic content in a deepfake scenario AI Act Article 50(4) P2 Scenario held; question open with counsel (AIDR-0827, 2028-03-14) Open entry OBL-NR-08 Deputy CISO

The second record is Hansa Mutual's register, OBL-HM-2028-01, adopted by AIDR-0876 on 2028-03-06. The extract shows four entries, including the hold list that AIDR-0877 created.

# Illustrative. Extract of OBL-HM-2028-01 (AIDR-0876, 2028-03-06). Owner: white-team lead.
register: OBL-HM-2028-01
text_read_on: 2026-11-10
review: six-monthly
next_review: 2028-09-01
entries:
  - id: OBL-HM-01
    instrument: "Regulation (EU) 2022/2554, Article 26(3); Article 30(3)(d)"
    obligation: "ICT third-party providers in scope take part in the TLPT; contracts say so."
    stage: P2
    control: "RoE-HM-2027-TLPT cites the clause; the register of information records it."
    evidence: "Contract annex reference per provider"
    evidence_age_days: 180
    owner: white-team lead
  - id: OBL-HM-02
    instrument: "Delegated Regulation (EU) 2025/1190, Article 4(2)(a) to (c)"
    obligation: "Need-to-know on the TLPT; control team consulted before the blue team is involved."
    stage: P2
    control: "HLD-HM-TLPT-01 read by the policy point of HM-SEC-004 (AIDR-0877, 2028-03-13)."
    evidence: "Hold-list change log, held by the control team lead"
    evidence_age_days: 90
    owner: control team lead
  - id: OBL-HM-03
    instrument: "Delegated Regulation (EU) 2025/1190, Article 12(4) and (5)"
    obligation: "Blue team report and replay with purple teaming within ten weeks of the active phase."
    stage: P3
    control: "Purple session record opened at the end of the active phase."
    evidence: "PRP-HM-2027-04"
    evidence_age_days: 180
    owner: white-team lead
  - id: OBL-HM-04
    instrument: "Regulation (EU) 2016/679, Articles 28 and 88; BetrVG section 87(1) no. 6"
    obligation: "Processor terms for testers; works agreement covers exercises that involve staff."
    stage: P2
    control: "KBV-IT-2024-SOC-05; yearly TLPT notice class (AIDR-0878, 2028-03-20)."
    evidence: "Signed addendum; January notice to the Konzernbetriebsrat"
    evidence_age_days: 365
    owner: group CISO

Observable, expected, speculation

Observable. The current text and dates are cited above: DORA applies from 17 January 2025, the Delegated Regulation on TLPT was published on 18 June 2025, Article 14 of the Cyber Resilience Act applies from 11 September 2026, the AI Act's general-purpose AI obligations from 2 August 2025 and its Annex III requirements from 2 December 2027 as the Omnibus amended them (9, European Union, 2026). That TIBER-EU is adopted in a number of Member States is observable (20, ECB, 2025).

Expected. That supervisors will accept the evidence of continuous, catalogued testing as part of a DORA programme under Articles 24 and 25, beside and not instead of the threat-led test, is expected: the text supports a programme of a range of tests. That authorities will issue guidance on AI tooling inside a threat-led test is expected, because the Delegated Regulation is silent and the practice is arriving.

Speculation. That the treatment of AI-assisted emulation, of deepfake exercises under Article 50(4) and of co-determination for exercises will be harmonised across Member States is speculation; no instrument provides for it.

Across the usage modes and degrees of delegation

The obligations attach to the use and to the actor, not to the mode in which AI is deployed. A tester who drafts a scenario with an assistant (Modes 1 to 3) is bound by the same Article 27 conditions and by the same authorisation as one who does not. What changes is where the AI Act and the Cyber Resilience Act add duties for the provider or the deployer of the tooling, and how fast the stop must act.

Mode or level What the legal frame adds Control in the loop
Modes 1 to 3: assistants and agentic work tools used by testers, white team and analysts Data in prompts is personal data (GDPR Articles 5, 28); logs that identify staff reach co-determination (BetrVG § 87(1) no. 6; Lag 1976:580 11 §) Use declared in the call-off agreement or the work agreement; no named-person scoring; aggregate reports
Mode 4: built AI applications (curator, correlator, critic) The organisation is deployer, and possibly provider if it builds the system, under the AI Act; Annex III point 4 if the output evaluates people Classification recorded in the mandate; the agent is keyed to system identity, not to a person
Mode 5: autonomous production agents (the emulation runner, the re-test runner) A tool of the tester under DORA Article 27 and the Delegated Regulation; conduct outside the owner's authorisation is without right (Directive 2013/40/EU Article 2(d)) Policy decision point outside the agent; stop in 60 seconds; supervisor asked before use in a TLPT
Level 3 Bounded Only for catalogued S1 scenarios inside the signed scope Manifest enforced outside the agent; decision log as proof of scope
Level 4 Autonomous Never for an emulation action that is irreversible, leaves the signed scope, touches personal data beyond authorisation or targets a named person Level 4 excluded in DLG-*

Nordvik Region and Hansa Mutual

Nordvik Region is within NIS 2 through its Member State's definition, under national criminal law, the GDPR on the public-task basis, the union agreement and the AI Act as deployer of an Annex III system. It has no TLPT authority and no attestation. Its register OBL-NR-2028-01 is short on supervisory entries and long on authorisation and consent, because its exercises cross the boundaries of an MSSP, a hosting provider and a contracted tester. It met the union's joint committee before its first exercise that involved staff, RoE-NR-2027-002, on the ten-working-day notice, and its open entry is the disclosure question for deepfake scenarios (AIDR-0827).

Hansa Mutual's German entity is within DORA and runs a threat-led test under TIBER-DE (illustrative) with an authority, test managers, a control team and an attestation. Its regulatory work is to keep three instruments apart: the TLPT, the quarterly sessions under RoE-HM-2027-PURPLE and the continuous pipeline under RoE-HM-2028-001. The hold list HLD-HM-TLPT-01 keeps the pipeline from contaminating the test, and the January notice class of AIDR-0878 gives the Konzernbetriebsrat what it can be given without breaking the test's secrecy. The organisations differ in what is required of them and agree in what they do: both write authority, consent, legal basis and notice into the manifest and keep the register current.

Summary

This chapter set out the legal frame of P1 Target and P2 Emulate, and its reach into P3 Observe, P4 Improve and P5 Verify, as architectural implications and not as legal advice. DORA requires a testing programme with independent testers, remedy validated as complete, yearly tests of the systems that support critical or important functions and, for entities the authorities identify, threat-led penetration testing at least every three years on live production systems, by testers who meet Article 27 and under the method of Delegated Regulation 2025/1190, with a mandatory replay and purple teaming exercise at closure. TIBER-EU is the framework behind that method. NIS 2 places approval on the management body and asks for policies to assess effectiveness and for prompt corrective measures. The AI Act and the Cyber Resilience Act set resilience, adversarial-testing and vulnerability-handling duties on providers and manufacturers, with dates that the Digital Omnibus changed (9, European Union, 2026). The GDPR places exercise data under minimisation, a lawful basis and processor terms, national co-determination places exercises that involve staff under negotiation and notice, and criminal law makes the owner's authorisation the element that separates an exercise from an offence.

The chapter's own conclusions are four. Continuous emulation is not a threat-led test, and its manifest, authority and evidence are kept apart from the TLPT's, with a hold list that protects the test's secrecy. An agent in a supervised test is the tester's tool, and the supervisor is asked before it is planned. Agreements with staff govern classes of exercise, so that a covert test is notified as a class and not as a date. And the register that maps each obligation to a control, an evidence artefact with an age, an owner and a review date is an artefact of the loop, re-verified against the live text every six months. Chapter 22 takes the loop across the boundaries to which the consent fields point; Chapter 23 turns to the people on both sides of it.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (3, European Union, 2022)
  4. European Commission. Commission Implementing Regulation (EU) 2024/2690. (4, European Commission, 2024)
  5. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). (5, European Union, 2024)
  6. European Commission. The General-Purpose AI Code of Practice. (6, European Commission, 2025)
  7. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (7, European Union, 2016)
  8. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
  9. Nordqvist, G. AI Governance. (88, Nordqvist, 2026)
  10. Nordqvist, G. AI Platform and Security. (89, Nordqvist, 2026)
  11. Nordqvist, G. AI Threat. (91, Nordqvist, 2026)
  12. Nordqvist, G. The Transformed Security Architect. (92, Nordqvist, 2026)
  13. Nordqvist, G. AI Boss. (93, Nordqvist, 2026)
  14. Nordqvist, G. AI Blue. (94, Nordqvist, 2026)
  15. European Commission. Commission Delegated Regulation (EU) 2025/1190 on threat-led penetration testing. (8, European Commission, 2025)
  16. European Central Bank (2025). TIBER-EU Purple Teaming Guidance. (34, ECB, 2025)
  17. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 (Digital Omnibus on AI). (9, European Union, 2026)
  18. European Parliament and Council of the European Union. Directive 2013/40/EU on attacks against information systems. (10, European Union, 2013)
  19. Bundesrepublik Deutschland. Betriebsverfassungsgesetz, § 87. (11, Bundesrepublik Deutschland, n.d.)
  20. Bundesarbeitsgericht. Beschluss vom 8. März 2022, 1 ABR 20/21. (16, Bundesarbeitsgericht, 2022)
  21. Bundesrepublik Deutschland. Strafgesetzbuch, § 202a. (12, Bundesrepublik Deutschland, n.d.)
  22. Bundesrepublik Deutschland. Strafgesetzbuch, § 202c. (13, Bundesrepublik Deutschland, n.d.)
  23. Sveriges riksdag. Brottsbalk (1962:700), 4 kap. 9 c §. (14, Sveriges riksdag, 1962)
  24. Sveriges riksdag. Lag (1976:580) om medbestämmande i arbetslivet. (15, Sveriges riksdag, 1976)
  25. Bundesarbeitsgericht (2024). Beschluss vom 16. Juli 2024, 1 ABR 16/23. Bundesarbeitsgericht. (121, Bundesarbeitsgericht, 2024)
  26. European Central Bank (2022). TIBER-EU Purple Teaming Best Practices. ECB. (122, ECB, 2022)