What the Loop Did Before: Penetration Tests, Red Teams, Tabletops and Purple Sessions

Before AI joined the work of testing a defence, organisations tested it in six recognisable ways: the penetration test, the red team engagement, the threat-led test, the tabletop, the purple session and breach-and-attack simulation. Each was a sound answer to a particular question, and each produced a record. This chapter describes them as they ran before the transformation, because the rest of the book changes them, and a change can only be judged against a baseline that has been stated. The chapter concerns all five stages of the purple loop, defined in Chapter 4, by name: P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify. Its argument is that each form tended to leave one stage unfinished, usually P4 Improve or P5 Verify. That classification is the book's own reading of its sources, not a measurement and not independent evidence for the thesis.

Figure 2.1: Five stages of the purple loop with the stage that three groups of testing forms usually leave unfinished.

What the chapter treats as the baseline

The baseline is testing as it was practised before AI took part in the emulation, the observation or the improvement, which means before the usage modes of the series entered the loop (AI Governance, Chapter 2) (88, Nordqvist, 2026). People wrote the scenarios, ran the attacks, read the telemetry and made the fixes. Tools helped, as scripts, scanners, libraries of tests and dashboards, and a few of them already contained machine-learning features. The chapter notes where those features sit, because AI Red Team, Chapter 8, concluded that vendor AI in security products and managed services may already act at an effective autonomy nobody decided (90, Nordqvist, 2026). That is a procurement question about the baseline, and the chapter does not claim to know which products contain such features.

The baseline matters for a second reason. The earlier volumes treated the loop from each side: AI Red Team, Chapter 26, from the red side, as the sequence of finding, control, re-test and evidence, and AI Blue, Chapter 11, from the blue side, as the second half of B5 Learn (90, Nordqvist, 2026) (94, Nordqvist, 2026). Both argued that a finding is closed only when a re-test passes. This chapter asks why, before that rule, so many findings did not close, and what each form of testing contributed and lacked.

A short history of the terms

The vocabulary of red, blue, white and purple is used loosely, and a book that fixes its terms in Chapter 4 should say where the older terms came from. The history below is limited to what could be verified against a primary text. The colours may have older origins, but the chapter found no source it could check and omits what it could not verify.

The earliest source the chapter could verify is a 1972 planning study for the United States Air Force, written by James P. Anderson. It describes "tiger teams" that had "expended a moderate amount of energy in demonstrating the security inadequacy" of commercial and nominally secured systems, and it is sceptical of their value as a measure: the results were "highly dependent on the quality and experience of the personnel assigned to the teams", their activities "can only reveal system flaws and provide no basis for asserting that a system is secure in the event their efforts are unsuccessful", and "none of the known tiger team efforts has failed to date" (38, Anderson, 1972).

By 2008 the penetration test had a definition in guidance prepared for United States federal agencies, which other organisations could use voluntarily. NIST Special Publication 800-115 defines it as "security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network", notes that it "often involves launching real attacks on real systems and data", and includes a template for rules of engagement as an appendix (36, Scarfone et al., 2008).

The glossary of the NIST Computer Security Resource Center, which carries the definitions of the Committee on National Security Systems (CNSSI 4009, edition 2022), gives the three older team terms. A red team is a group authorised and organised to emulate a potential adversary's attack or exploitation capabilities. A blue team is the group that defends the organisation's use of information systems against the red team, in a realistic operational setting and under rules overseen by a neutral white team. The white team refereed the engagement: it helps to establish the rules of engagement and the metrics, observes, resolves problems and "normally has responsibility for deriving lessons-learned, conducting the post engagement assessment, and promulgating results" (40, NIST Computer Security Resource Center, 2022). The last clause is the one to remember. In the older vocabulary, the white team already owned the lessons. Nothing in it owned the change that followed.

Three European developments set the shape of the threat-led test. The Bank of England has run CBEST since 2014, an intelligence-led penetration-testing approach that mimics the actions of cyber attackers (42, Bank of England, 2024). The European Central Bank and the national central banks published the TIBER-EU framework in May 2018, and the ECB has since updated it to align with the technical standards under DORA (20, ECB, 2025) (39, ECB, 2018). In 2022 the ECB published best practices for purple teaming within TIBER-EU tests, and in January 2025 it replaced them with a revised Purple Teaming Guidance (34, ECB, 2025). DORA, Regulation (EU) 2022/2554, was adopted in December 2022 and applies from 17 January 2025; its Article 26 makes threat-led penetration testing (TLPT) a legal duty for the financial entities that the competent authorities identify, and the Commission's Delegated Regulation (EU) 2025/1190 sets the technical standards (2, European Union, 2022) (8, European Commission, 2025). The point for the book is the direction: the threat-led test moved from a voluntary framework run by central banks to a duty written into law, and the purple session moved from an improvisation to a named, bounded part of that framework.

A map of testing forms

The six forms differ in the question they answer, who knows that they are running, who acts, what they produce and how often they run. The table sets them side by side, and the sections that follow describe each. The classification of what each form usually leaves unfinished is the book's own, drawn from the sources cited below; it describes the common case and not every instance.

Form	The question it answers	Who knows	Who acts	Usual output	Stage usually left unfinished
Penetration test	Which vulnerabilities in this system can be used, and how far do they reach?	The system owner and the security office; the defenders often, not always	Contracted or internal testers	A report of findings with severity and advice	P5 Verify
Red team engagement	Can an adversary reach this objective without being stopped, and would we notice?	A few people; the defenders do not	A red team, internal or contracted	A report and often a replay	P4 Improve
Threat-led test (TIBER-EU, TLPT)	The same, against live critical functions, with intelligence on the actors that matter	The control team and the authority; the blue team does not	Threat intelligence provider and testers, under supervision	Test reports, a remediation plan, a summary and an attestation	P5 Verify
Tabletop	Do the people and the plan hold up when we talk the incident through?	Everyone in the room	Participants, with a facilitator	An after-action report with action items	P2 Emulate (none performed) and P5 Verify
Purple session	What did each side do at each step, and what do we change now?	Everyone in the session	Red and blue together	A shared record and live changes	P5 Verify
Breach-and-attack simulation	Do our controls stop or detect this catalogue of behaviours, repeatedly?	The operators of the tool	Software, on a schedule	A pass or fail per control and test	P4 Improve

The penetration test

The penetration test answers a question about a system. The assessors work to a scope, often with some knowledge of the target, and they report vulnerabilities and the paths that combine them. NIST SP 800-115 describes the iterative nature of the work, where minimal access is used to reach greater access, and its warning that the test poses "a high risk to the organization's networks and systems" because it uses real exploits against production systems (36, Scarfone et al., 2008). The TIBER-EU framework gives the complementary view: penetration tests have provided "a detailed and useful assessment of technical and configuration vulnerabilities, often within isolation of a single system or environment", but they "do not assess the full scenario of a targeted attack against an entire entity" including people and process (39, ECB, 2018). The test is strong at P2 Emulate inside a scope and produces the raw material for P3 Observe, but the observation is about the target, not the defence. Whether the defenders detected the testers is often not recorded, or the defenders were told in advance and the question is moot.

The red team engagement

The red team engagement widens the question from the system to the objective. A red team emulates an adversary against the organisation's people, process and technology, usually without the knowledge of most defenders, and the question includes whether the defence notices. It produces a path to an objective and, in good practice, a replay with the defenders, in which each action is set beside what was seen. Its strength is at P2 Emulate and P3 Observe together: the engagement measures the defence, not only the target. Its weakness is that the people who understand the finding best, the red team, leave when the engagement ends, and the people who must act on it, the owners of detections, controls and playbooks, receive a report. That is why the table marks P4 Improve as the usual gap.

The threat-led test

The threat-led test is the red team engagement with a threat intelligence phase, a supervisor and a legal frame. Under TIBER-EU the sequence is initiation, scoping, threat intelligence, red-team testing, the blue team and red team reports with a replay, and a closure phase that agrees a remediation plan and ends with a test summary and an attestation. The framework states that the test is performed without the knowledge of the target's security and response staff, with only a small group aware, and the ECB states that the outcome "is not a pass or fail" (39, ECB, 2018) (20, ECB, 2025). Under DORA Article 26, a financial entity identified by its competent authority carries out TLPT at least every three years, although the authority may increase or reduce that frequency, on live production systems that support critical or important functions (2, European Union, 2022). Article 26(6) and (7) require a summary of the findings, the remediation plans and the documentation to go to the authority, and give the authority's attestation, which allows mutual recognition between authorities. The threat-led test is the most complete of the six forms at P1 Target, because intelligence selects the scenario, and the only form with a legal duty to deliver a remediation plan to the authority. The chapter returns to what that plan does and does not require.

The tabletop

The tabletop belongs in this baseline because it is the form most often meant when an organisation says that it "exercises". NIST SP 800-84 defines a tabletop exercise as a discussion-based exercise in which personnel with roles in a plan meet to discuss their roles and responses to a scenario presented by a facilitator; it "does not involve deploying equipment or other resources", typically lasts two to eight hours, and ends in an after-action report (41, Grance et al., 2006). The tabletop tests the plan and the people's grasp of it, and it is cheap. It does not test whether a control stops a technique or whether a detection fires, because no technique is run. In the loop's terms it enters at P1 Target with a scenario and at P3 Observe with the discussion, performs no P2 Emulate, and produces action items that nothing re-tests. Its value is real and different: it surfaces decision rights, the order of calls and the gaps between documents, which the technical forms rarely reach.

The purple session

The purple session is the joint form. The TIBER-EU purple teaming guidance defines purple teaming as a collaborative activity that involves both the red team and the blue team and their corresponding offensive and defensive actions, with insight into attack phases, detections, defensive actions and test reports, and says that it ranges from tabletop discussions to specific technical testing activities. It also says it is "not intended to replace the confidential active red teaming phase of a TIBER test": in the testing phase limited purple teaming is a last resort, to continue a test that could otherwise not be continued in a safe or meaningful way, and in the closure phase it is a standard element of the testing process, held after the replay exercise (34, ECB, 2025). The Delegated Regulation repeats the limit: a limited purple teaming exercise, with methods such as catch-and-release, war gaming and collaborative proof of concept, is a last resort in exceptional circumstances (8, European Commission, 2025). Outside the supervised frame the purple session had no such limit and became a regular working meeting. Its strength is at P3 Observe and P4 Improve, because the person who ran a step and the person who owns the detection sit in the same room and can change something live. Its weakness is P5 Verify: a live change confirmed by running the step once while the red operator watches shows the change worked once, in that session, for that variant.

Breach-and-attack simulation

Breach-and-attack simulation (BAS) is software that runs a catalogue of emulated attack behaviours on a schedule. A practitioner explainer describes it as an "automated and continuous software-based approach to offensive security" which, unlike penetration testing and red teaming, is fully automated, and which is "not intended to replace" other protocols (81, Schneider, 2024). The open-source libraries behind many such tests map them to MITRE ATT&CK: Atomic Red Team publishes small tests mapped to techniques, and MITRE Caldera automates adversary emulation, both open and neither needing a model (32, Red Canary, n.d.) (33, MITRE, n.d.) (17, MITRE, n.d.). BAS answers a narrower question than the others, whether this control blocks or detects this behaviour today, and it answers it often. It is the one form in the baseline with a cadence faster than the estate changes. It produces a result per control and test, which is strong evidence at P2 Emulate and P3 Observe for the layers it can see: prevention, and the telemetry and detection of the tested endpoint or network path. Its weakness lies at P4 Improve, because a failing test is a signal that a person has to turn into a change, and in the layers beyond detection, because a tool that confirms that a rule fired has not shown that anyone triaged the alert. The outcome taxonomy of Chapter 9 names those later layers, and the baseline tool rarely measured them.

Who plays what

The forms use the same cast under different names. The table sets the roles as the sources define them and as this book uses them. Two of the roles, the trusted agent and the exercise controller, are the book's terms for responsibilities that the verified texts distribute differently, and the table says so.

Role	What the role does	In the verified sources	In this book
Red team	Emulates the adversary within the agreed scope	Authorised and organised to emulate a potential adversary (40, NIST Computer Security Resource Center, 2022); testers and a threat intelligence provider in TIBER-EU and TLPT	Internal or contracted; a role of the loop, not a separate party to it
Blue team	Defends, in a realistic setting	The defending group; in TIBER-EU and TLPT the staff who are unaware of the test	The analysts, detection engineers and responders whose work the loop measures (AI Blue, Chapter 17)
White team	Referees: sets rules and metrics, observes, derives lessons	CNSSI definition above; the White Team in the TIBER-EU framework of 2018; the control team in the current ECB text and in the Delegated Regulation	The control group that governs an exercise (Chapters 6 and 20)
Trusted agent	Knows of the exercise from inside the defended organisation, so that real incidents are not mistaken for it and the stop can be reached	No verified source uses the term in this sense; the TIBER-EU white team is the nearest equivalent	One named person on the defended side, such as the shift lead of a managed provider
Exercise controller	Holds the schedule, the scope and the stop	The control team lead is "the staff member of the financial entity responsible for the conduct of all TLPT-related activities" (8, European Commission, 2025)	A named member of the white team with authority to halt
Purple team coordinator	Owns the register of what the loop produces	Not in the baseline sources	A role defined in AI Blue, Chapter 17, taken over in Chapter 4

The naming deserves a note. The 2018 TIBER-EU framework calls the small group aware of the test the White Team, whereas the current ECB page and the Delegated Regulation call the corresponding group of the tested entity the control team, defined in Article 1(1) as the team of staff of the tested financial entity, with staff of its third-party service providers where relevant, who manages the test (39, ECB, 2018) (20, ECB, 2025) (8, European Commission, 2025). A reader moving between older practitioner material and current supervisory text will meet both names for the same function. The book keeps "white team" for the control group of an exercise, as Chapter 4 fixed it, and says "control team" where it quotes the regulation.

Three observations about the cast matter for what follows. First, the knowledge asymmetry is deliberate. A blue team that is unaware measures real detection and response, and a blue team that is aware measures the plan; the forms differ here, and the report must say which was tested. Second, the white team is the only role that crosses the line between red and blue, and in a small organisation one person may hold more than one of these roles, which weakens the separation that the forms assume. Third, none of the roles in the baseline owns the result after the report. The white team owns the lessons, the blue team the defence, the red team the attack, and the closure of a finding belongs to the owner of whatever must change, who is rarely a member of any of the three.

The report as the end of the loop

In every form except the purple session and the simulation, the product is a document. The penetration test produces a report, the red team engagement a report and a replay, the threat-led test a set of reports, a remediation plan, a summary and an attestation, and the tabletop an after-action report. The document is the right product for the question each form asks, because the question is "what did we find?". It is the wrong product for a different question, "what did we change, and does it work?", because a document records a state at a date and cannot show that anything has since moved.

The flow of a result shows where the document stops. In a typical penetration test the report goes to the security office and the system owner, findings are copied into a tracker or a spreadsheet, and the owners of the affected systems are asked to fix them. In a threat-led test the replay workshop joins the blue and red teams, the entity drafts a remediation plan, and the supervisor receives the summary and the plan. In a tabletop the facilitator's after-action report lists actions and assigns owners. In each case the last step the form controls is the delivery of a record. What happens next is governed by the organisation's ordinary change processes, which the form neither measures nor, in general, observes.

The sources agree that this is not where a test should end. NIST SP 800-115 says that "a security test is much more valuable if it also results in a mitigation strategy being developed and implemented", describes the post-testing steps as analysis, a report and the carrying out of mitigation, and in its remediation section tells organisations to verify the implemented actions by auditing or retesting, noting that the test team can verify implementation "only if a mirror copy of the original test is performed" (36, Scarfone et al., 2008). The guidance for closing the loop therefore existed in 2008. TIBER-EU also expects a remediation plan "including planning for follow-up testing" (39, ECB, 2018). The report was the end of the loop in practice, not in the advice.

Why findings stalled

Three causes recur, and the sources support each in part. The first is the backlog. A finding is one more item in a queue of change, patching and feature work, and its priority depends on how its severity is argued, not on the test that produced it. The second is ownership. A test is commissioned by a security office and carried out by testers, whereas the fix belongs to a platform team, a detection engineer, a supplier or a business system owner who did not commission the test and may not have been in the replay. The third is the missing re-test: nothing in the ordinary course of work checks that the fix worked, so a finding is marked done when the change is made, not when the behaviour is shown to have changed.

The best quantitative evidence the chapter found for the third cause is a vendor's own record, and it should be read with that caveat. AppSec Labs, an application-security firm whose engagements include retesting at no extra cost, analysed its engagements from October 2021 to August 2026 and reported 4,956 findings delivered to clients, of which 1,237 were submitted for retest, about a quarter. Of the 1,159 retests that reached a verdict, 846 (73.0 per cent) were fixed and the rest were not fixed, partly fixed or mitigated without a fix. The median time from report to a fix being submitted was 33 days, and the median organisation had verified 19 per cent of its findings. Of the customers with ten or more findings, 28 never submitted one for retest (107, AppSec Labs, 2026). The sample is a vendor's, retesting is initiated by the client, and the figures describe application-security findings, not threat-led tests. What they show is narrower and still useful: a fix that is submitted for verification is not always a fix, and in this record most findings were never submitted for verification at all. The chapter treats the figures as an indication of the mechanism, not as a rate for any sector.

The regulatory text addresses the first two causes more than the third. The Delegated Regulation requires the financial entity to provide the remediation plan within eight weeks of the TLPT authority's notification that the red team and blue team test reports are complete (Articles 12(7) and 13(1)), and requires, for each finding, a description of the shortcomings, the proposed measures with their prioritisation and expected completion, a root cause analysis, the staff or functions responsible, and the risks of not implementing the measures (Article 13) (8, European Commission, 2025). That list answers the backlog, by prioritisation and expected completion, and ownership, by naming the responsible staff or function. A verification step is not among the items of Article 13(2), and the chapter does not claim that no other provision requires follow-up testing; it observes only that the remediation plan, as specified, is a plan for change and not a proof of it. DORA Article 24(1) states the programme's purpose as assessing preparedness, identifying weaknesses, deficiencies and gaps, and "promptly implementing corrective measures" (2, European Union, 2022). The purpose is correct. The architecture for proving that the corrective measure worked is what the baseline lacked and what P5 Verify supplies.

This is the book's own conclusion, and the chapter labels it as such. The observable part is that guidance has long recommended retesting, that supervisory templates specify ownership and prioritisation, and that the one dataset found shows low retest uptake. The conclusion is that the structural reason findings stalled was that closure had no owner and no test: it follows from the loop of Chapter 4 and has not been measured across the field.

Cost and cadence

The rhythm of testing in the baseline was set by cost, and the cost was mostly the scarcity of skilled hours. NIST SP 800-115 reasoned from cost and impact to an annual rhythm, which it called "may be sufficient" for a network (36, Scarfone et al., 2008). The threat-led test is more demanding. Under the Delegated Regulation the active red team testing phase lasts at least 12 weeks (Article 11), the control team must check that the threat intelligence provider and the testers meet the requirements that DORA Article 27 sets for testers, and the supervisor may object to a selection (8, European Commission, 2025) (2, European Union, 2022). Tests of this kind cannot be run weekly, and the frame does not intend them to be.

The table sets the baseline cadences against the pace of change they could follow. The cadences of the legal frames are from the instruments; those of the other forms are the usual practice of the baseline and are the book's description, not a statistic.

Form	Cadence in the baseline	What sets it	Follows a change to a detection or control?
Penetration test	Annual per system is the usual rhythm	Cost and impact (36, Scarfone et al., 2008)	No, until the next test
Red team engagement	Annual or less	Skilled hours and the cost of an engagement	No
Threat-led test	At least every three years under DORA Article 26(1), unless the authority adjusts it; 12 weeks or more of active testing	Law and supervisory selection (2, European Union, 2022)	No
Tabletop	Periodically, and after changes to a plan	Planning and attendance (41, Grance et al., 2006)	Only for the plan
Purple session	Occasional, or quarterly where an organisation chose it	Calendar time of two teams	Only for what the session re-ran
Breach-and-attack simulation	Scheduled, often daily or weekly	Licence and operator time	Yes for the catalogue, but with no one to act on a failure

Two things follow. First, no form in the baseline could follow the estate's rate of change except the simulation, and the simulation's catalogue was usually the vendor's, chosen by availability and not by threat. Chapter 3 treats the pressure that this puts on the loop. Second, the scarcity was upstream of the report: skilled red-team hours were the constraint on P2 Emulate, so organisations spent them on discovery, the stage that appears most valuable, and had little left for the repeated re-test that closure needs. Observable: these rhythms are documented in the sources cited above. Expected: that the scarcity eases for the stages where AI can assist is the premise of Chapters 7 and 8 and is judged there.

What each form can and cannot show

Each form produces evidence of a particular kind, and the evidence has limits that the form's name does not announce. The table states what a result can support and what it cannot, and ends with the question an auditor or board member should ask. Anderson's sentence of 1972 governs the first column of the whole table: a test that fails to find a flaw shows that it did not find one (38, Anderson, 1972).

Form	Can show	Cannot show	Question to ask of a claim
Penetration test	That a named vulnerability was exploitable in this scope at this date	That the system is secure; that the defence noticed	Was the defence told, and did anyone record whether it noticed?
Red team engagement	That an objective was or was not reached, and what the defence saw on the path taken	That other paths are closed	Which paths were not tried?
Threat-led test	The same, on live critical functions, against actors chosen by intelligence	A pass or fail; coverage of techniques the scenario did not use	Which techniques did the scenario use, and which not?
Tabletop	That the people, roles and plan hold together on paper	That any control or detection works	Which technical claims did the discussion rest on?
Purple session	That a detection or control can be changed to catch a step	That it still catches it later, or a variant	When was the change re-tested, and by whom?
Breach-and-attack simulation	That a control blocked or detected a catalogued behaviour on a tested path	That anyone triaged and acted; that untested behaviours are covered	What does a pass mean at each layer beyond detection?

The last column is the basis of the coverage discipline of Chapter 17, where "covered" is a claim with a date and a result. A claim of coverage that rests on a penetration test report, a closed tabletop action or a green dashboard has the evidence value in this table and no more. Chapter 9 gives the seven outcomes that let a single run separate those cases.

Across the usage modes and the degrees of delegation

The baseline predates AI in the loop, so it sits at the low end of both scales. People ran every form, so the degree of delegation was Level 0 Advisory in the series' terms at every stage, with one partial exception: the simulation tool ran catalogued tests on a schedule without a person starting each run. That property, a codified catalogue enforced outside the executor, is what Chapter 4 later makes the definition of Level 3 Bounded for catalogued safe scenarios. The baseline tool had the property without any of the controls that Chapter 6 requires, because it was not an agent and was not treated as one. The column on Mode 0 Ambient AI records where a feature may already be present without a decision.

Form	Who acts in the baseline	Delegation in the baseline	Where Mode 0 Ambient AI may already sit
Penetration test	Testers, with scanners	Level 0 Advisory	Scanner and tester tooling that ranks or suggests; to be established by asking the supplier
Red team engagement	The red team	Level 0 Advisory	Tooling for reconnaissance or phishing text; to be established
Threat-led test	Testers and intelligence provider	Level 0 Advisory	Intelligence platforms that summarise or cluster reporting
Tabletop	Participants	Level 0 Advisory	Meeting tools that summarise and assign actions (Mode 0 or Mode 2)
Purple session	Red and blue together	Level 0 Advisory	Detection products that suggest rules
Breach-and-attack simulation	Software on a schedule	Scheduled, catalogue-bound; not an agent	Product features that choose or order tests

Observable: products in each category are sold with machine-learning or generative features. Speculation: how many deployed baseline tools already contain a feature that changes what they do without a decision is not known to this book; the chapter recommends only that the question is asked at the next renewal.

Practical guide: Classifying the testing a team already does

The purpose is to produce a register that states, for every testing activity, its form, its cadence, who it informed, what it proved and the stage it left unfinished. The roles are the purple team coordinator, who keeps the register, the CISO or deputy, who owns the answer, a representative of internal audit as reader, and the white-team lead or deputy CISO, who checks that the knowledge asymmetry has been recorded correctly. The register is a precondition for Chapter 4's loop charter: a loop cannot be designed around activities that no one has listed.

1. Collect. List every activity of the last 24 months that was called a test, assessment, exercise, simulation or review of the defence. Draw on contracts and purchase orders, audit reports, the tester's deliverables, the managed provider's reports and the calendar. Include activities run by suppliers on the organisation's behalf.
2. Classify. Assign one of the six forms by asking four questions in order: who knew; who acted (a person, a tester, software); was a technique actually run; was the result a document, a changed control or a shared record. An activity that fits no form is recorded as "other" with a reason, not forced into one.
3. Date and size. Record the last run, the cadence, the scope (systems, functions) and the cost in days or currency, so that the register can later be compared with the cadence the estate needs.
4. Trace each result. For the last run, find where each finding went: the tracker, the owner, the change and any re-test. Record the number of findings, the number with a named owner, the number with a re-test and the age of the oldest open one.
5. Name the unfinished stage. For each form, state which of the five stages was completed with evidence and which was not. Use the book's five finding states of Chapter 4: only closed and verified counts as closed.
6. Assign an owner for the unfinished stage. A form that leaves P5 Verify unfinished needs a person who runs, or commissions, the re-test and is accountable for the evidence. Where that person is also the detection owner, record the weakness, as Chapter 4 did.
7. Set evidence ages. Where no stricter rule exists, treat a result as expired after 180 days, the default of the Region in Chapter 5, and shorten it for priority techniques as Hansa Mutual does. Adapt the defaults to the organisation's risk appetite and to the works agreement where exercises involve staff.

The definition of done is a register that an auditor can read and test: every activity has a form, a date and an owner, every form has a named unfinished stage, and no entry claims a stage that has no record behind it.

Worked example: A testing-forms register for Nordvik Region and Hansa Mutual

The register below is illustrative. It reconstructs, in the fictional organisations, the baseline forms before the loop of Chapter 4 was designed, and it is written in the form that step 7 of the guide produces. The identifiers TFR-NR-01 and TFR-HM-01 are new and belong to this chapter. Records that already exist in the earlier volumes keep their identifiers.

# Illustrative: testing-forms registers, baseline before the loop (reconstruction)
register: TFR-NR-01            # Nordvik Region
owner: {role: purple-team-coordinator, person: Karin Lund}
forms:
  - form: penetration-test
    source: procured, scoped per system
    cadence: annual per system
    blue_team_aware: not recorded
    output: tester report to the CISO's office
    retest: only on request; no standing rule
    unfinished_stage: P5
  - form: threat-led-test
    status: not run before RoE-NR-2027-001 (window 2027-03-15 to 2027-04-02)
    unfinished_stage: not applicable
  - form: tabletop
    status: not recorded in the baseline; a gap, not a claim that none was held
  - form: injected-test (managed provider)
    source: annex MS-2, quarterly, five seeded incidents per class
    nearest_form: breach-and-attack simulation, run by the provider on its own detection
    unfinished_stage: P4
  - form: breach-and-attack-simulation
    status: none
evidence_expiry_days: 180
---
register: TFR-HM-01            # Hansa Mutual
owner: {role: purple-team-coordinator, person: "named in Chapter 19"}
forms:
  - form: red-team-engagement
    source: group red team, five staff, lead Mareike Hartmann
    cadence: annual threat-led engagement
    blue_team_aware: no
    unfinished_stage: P4
  - form: threat-led-test
    source: TLPT for the German entity, RoE-HM-2027-TLPT (TIBER-DE, illustrative)
    cadence: set by the competent authority
    unfinished_stage: P5
  - form: purple-session
    source: RoE-HM-2027-PURPLE, quarterly, chaired by the white-team lead
    unfinished_stage: P5
  - form: tabletop
    example: TTX-HM-2027-Q3-01 (2027-07-13)
    unfinished_stage: P2 and P5
  - form: breach-and-attack-simulation
    source: simulation tool, atomic tests weekly
    unfinished_stage: P4
measured: {finding_to_control_median_days: 19, record: BTP-HM-2027-Q3}
evidence_expiry_days: {priority_techniques: 90, other: 180}

Nordvik Region and Hansa Mutual

Nordvik Region buys its testing. It procures an annual penetration test scoped per system, and before the exercise of spring 2027 it had never run a threat-led test. The first purpose-built exercise, RoE-NR-2027-001, was run by a contracted tester, Elin Berglund, with the Region's own analysts as the blue team, over a three-week window from 2027-03-15 to 2027-04-02. The Region's senior security analyst, Karin Lund, commissions and receives the penetration test and the contracted exercises as a fraction of her other duties. Its baseline exhibits the pattern of the chapter in its simplest form: a document arrives, the findings go to the owners of the systems, and the question that the audit committee later puts, what the first exercise proved beyond a list of closed findings (AIDR-0800, recorded 2028-01-11), is the question about P5 Verify that a report cannot answer. The managed provider's quarterly injected tests under annex MS-2 are the only form with a rhythm faster than annual.

Hansa Mutual runs its testing. It has a group red team of five, led by Mareike Hartmann, a simulation tool that runs atomic tests weekly, quarterly purple sessions under RoE-HM-2027-PURPLE, an annual threat-led engagement and, for the German entity, a TLPT under RoE-HM-2027-TLPT on the cadence set by its competent authority. Its baseline exhibits the opposite pattern: many forms, each producing findings, and no single owner of what happens between a finding and a control. When AI Blue measured the loop at BTP-HM-2027-Q3 (AIDR-0778), containment was 11 of 12, 25 of 34 priority techniques were verified, and the median time from finding to control was 19 days (94, Nordqvist, 2026). Nine priority techniques were not verified: four had evidence past its expiry, three failed a re-test and two had never been tested. A median hides its tail, and the register cannot say how long the slowest findings waited. What it shows is that a group with every form still left P5 Verify to the end.

The two baselines pose the same question from different sides. Nordvik asks whether a small, bought programme gives evidence it can rely on; Hansa asks whether a rich one is converting its findings into controls fast enough to matter. Chapters 5 to 11 answer both stage by stage.

Summary

Before AI, organisations tested their defences in six ways: the penetration test, the red team engagement, the threat-led test, the tabletop, the purple session and breach-and-attack simulation. The terms have a documented history, from the tiger teams of a 1972 study through the NIST definitions of penetration testing and of the red, blue and white teams, to CBEST from 2014, TIBER-EU in 2018 and the threat-led testing of DORA Article 26, which Delegated Regulation (EU) 2025/1190 specifies. The forms differ in the question they answer, who knows, who acts, what they produce and how often they run, and the cast of red, blue, white, trusted agent and exercise controller is similar across them.

Each form produced a record of a particular kind and tended to leave one stage unfinished, in the book's own classification of the common case: the penetration test, the threat-led test and the purple session usually left P5 Verify, the red team engagement and the simulation usually left P4 Improve, and the tabletop performed no P2 Emulate and left P5 Verify. The report was the end of the loop in practice, although the guidance, from NIST SP 800-115 to TIBER-EU, had long advised retesting. The one dataset found suggests that most findings were never submitted for verification and that a submitted fix is not always a fix; it is a vendor's, and the chapter uses it only as an indication of the mechanism. Findings stalled because of the backlog, because ownership was not matched to the test, and above all because closure had no owner and no test. That conclusion is the book's own.

Cost and the scarcity of skilled hours set the rhythm: annual for the penetration test, every three years or more for the legal threat-led test, and faster only for the simulation, which could not tell whether a person acted. Each form supports a particular claim and no more, and the last column of the evidence table is the question to put to any claim of coverage. Nordvik Region has the simplest baseline, a document and an annual cycle, and Hansa Mutual the richest, with every form and a 19-day median from finding to control. Chapter 3 turns to the pressure that makes these rhythms inadequate, and Chapter 4 defines the loop that closes the gap.

Sources

1. 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)
2. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (88, Nordqvist, 2026)
3. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (90, Nordqvist, 2026)
4. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (94, Nordqvist, 2026)
5. MITRE Corporation. MITRE ATT&CK. (17, MITRE, n.d.)
6. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
7. Anderson, J. P. (1972). Computer Security Technology Planning Study, Volume I. (38, Anderson, 1972)
8. European Central Bank (2018). TIBER-EU Framework. (39, ECB, 2018)
9. NIST Computer Security Resource Center. Glossary entries: red team, blue team and white team. (40, NIST Computer Security Resource Center, 2022)
10. Grance, T. et al. (2006). Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. (41, Grance et al., 2006)
11. Bank of England (2024). CBEST Threat Intelligence-Led Assessments: Implementation Guide. (42, Bank of England, 2024)
12. AppSec Labs (2026). We checked 1,237 fixes. One in four was not fixed. (107, AppSec Labs, 2026)
13. Schneider, J. What are breach and attack simulations? (81, Schneider, 2024)
14. European Commission (2025). Commission Delegated Regulation (EU) 2025/1190. (8, European Commission, 2025)
15. Red Canary. Atomic Red Team. (32, Red Canary, n.d.)
16. MITRE Corporation. MITRE Caldera. (33, MITRE, n.d.)
17. European Central Bank (2025). TIBER-EU Purple Teaming Guidance. (34, ECB, 2025)
18. Scarfone, K. et al. (2008). Technical Guide to Information Security Testing and Assessment. (36, Scarfone et al., 2008)