Chapter 6 fixed the rules of engagement, the safety classes and the stop path, and Chapter 4 named the roles that hold the loop. Neither settled the decisions around them: who may authorise an emulation, change its scope mid-window, stop it, restart it, accept a finding that will not be fixed, close a finding and declare a technique covered, and who decides within minutes that an alert belongs to the exercise or does not. This chapter assigns those rights. It concerns P1 Target, where the rules under which scenarios may run are authorised, P2 Emulate, where the window, the scope and the stop are controlled, P4 Improve, where a finding leads to a change or to a recorded decision to leave it, and P5 Verify, where closure and the claim of coverage are declared. It treats the white team, the control group that governs an exercise, as the body that holds most of these decisions.
A loop with AI in it makes more decisions than an annual test did, and makes them faster. A pipeline that exercises each priority technique at least every 30 days, as the Hansa Mutual runner does, takes a decision to run, a decision about what it may touch and a decision to stop for every run, and it produces findings at a rate that makes informal decisions impossible. Without holders three failures recur: nobody holds the decision and it drifts upwards until a senior person without context takes it late; several people hold it and act in conflict; or the holder exists on paper and cannot be reached in the time allowed.
Accountability does not pass to a tool. DORA Article 5(2) makes the management body responsible for defining, approving and overseeing the ICT risk management arrangements and, in point (a), gives it ultimate responsibility for managing ICT risk (2, European Union, 2022). NIS 2 Article 20 places approval and oversight of cybersecurity risk-management measures on the management bodies (3, European Union, 2022). As an architectural implication, not legal advice, the management body does not sit in the exercise window: it approves in advance the file that says who does, and is informed afterwards of what the file routes to it. The Transformed Security Architect, Chapter 18, recorded that someone must turn each such article into a control (92, Nordqvist, 2026). The decision-rights file is that control for the loop.
Primary topics explored
- Why the loop needs its own decision rights
- Decisions for the loop
- Authorisation
- The white team and the trusted agent
- Stopping
- Acceptance of risk
About AI Purple
AI Purple is Book 9 of The Transformed Architecture. It takes the loop between the red team and the blue team as its subject and asks what happens when AI sits on both sides of the table: the five stages of the loop (target, emulate, observe, improve, verify), rules of engagement and safe emulation, continuous emulation, the independence principle, coverage as a claim that needs evidence, the loop's own AI and how to defend it, operating models, decision rights, regulation, and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss and AI Blue.
Chief information security officers, heads of security operations, red-team leads, penetration testers, SOC managers, detection engineers, purple-team coordinators and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 20: Decision Rights, Authorisation and the White Team in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Loop in the Organisation” and is one of 33 drawn from the manuscript.