A red team exercise without signed rules of engagement is an unauthorised intrusion with good intentions, and it leaves the commissioning organisation exposed legally, operationally and reputationally. This template is the governance document the commissioning organisation owns: who authorises the exercise, what is in and out of scope, who sits on the white (control) team, how activity is deconflicted with real incidents, when the exercise pauses or stops, how leg-ups are approved, how data is handled and how results are reported. It is for CISOs, exercise sponsors, control team leads and legal counsel. It deliberately contains no attack techniques or tooling: those belong in the provider's test plan, which this document governs. For how a red team programme works end to end, see the Red Teaming Guide.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [Exercise code name] and [Control Team Lead], must be replaced with your own terms before signature.
- Must and should: "must" is mandatory; "should" is recommended practice where a documented exception is allowed under section 5.
- Keep it restricted: the completed document names flags, trusted agents and the stop code word. Classify it at your highest internal level and share it only with the control team, signatories and the provider's lead.
- Pair it with the right companion documents: for an announced penetration test use the Penetration Test Scoping Checklist instead; for collaborative exercises where defenders know the test is running, see the Purple Teaming Guide.
- Legal review is not optional: this template is not legal advice. Have [Legal] confirm the authorisation chain for every jurisdiction and every third party in scope.
1. Purpose
1.1 This document sets the rules of engagement (RoE) for red team exercise [Exercise code name], commissioned by [Organisation] and delivered by [Provider / internal red team]. It records the authority under which the exercise takes place, the boundaries the red team must respect, and the controls [Organisation] uses to keep the exercise safe.
1.2 The objectives of the exercise are to test [Organisation]'s ability to prevent, detect and respond to a realistic, threat-led attack against [critical business functions], measured against the flags listed in Annex A.
1.3 Where the exercise is run under a regulatory framework, such as TIBER-EU, DORA threat-led penetration testing (TLPT) under Delegated Regulation (EU) 2025/1190, CBEST or the Association of Banks in Singapore (ABS) Adversarial Attack Simulation Exercise (AASE) guidelines, the requirements of that framework take precedence over this document where they conflict. See the Threat-Led Penetration Testing Guide.
2. Scope
2.1 In scope. Only the entities, legal entities, sites, systems, networks, cloud tenancies, applications and people listed in Annex B are in scope. Anything not listed is out of scope.
2.2 Authority to consent. For every item in Annex B, [Organisation] must record the person entitled to authorise testing of it. Under section 17(5) of the UK Computer Misuse Act 1990, access is unauthorised if the person is not entitled to control that kind of access and does not have consent from someone who is. [Organisation] cannot consent on behalf of a supplier, cloud provider, managed service provider or group company it does not control.
2.3 Third parties. Any third-party platform or service in scope requires written permission from that third party, attached to Annex B, or must follow a published testing policy that the provider has confirmed applies to this exercise.
2.4 Exclusions (no-fly zones). The following are out of scope regardless of what the red team discovers: [safety-critical and OT systems], [payment execution], [production customer data stores beyond proof of access], [named individuals, for example staff on leave or under HR process], [personal devices and home networks], [systems of regulators and law enforcement]. Social engineering or physical access is permitted only where Annex B says so explicitly.
2.5 Timing. Active testing runs from [start date] to [end date]. Blackout periods: [quarter end, major releases, peak trading]. DORA TLPT expects an active red team testing phase of at least twelve weeks; set dates accordingly.
2.6 Scope changes. Changes to scope, flags or exclusions must be approved in writing by the [Exercise Sponsor] and the [Control Team Lead], recorded in the change log in Annex E, and, where a third party is affected, by that third party.
3. Roles and responsibilities
| Role | Who | Responsibilities | Authority |
|---|---|---|---|
| Exercise Sponsor | [Executive, e.g. CIO or COO] | Signs the authorisation letter, owns business risk, approves scope and budget | Final approval; may terminate the exercise |
| Control Team Lead (white team lead) | [Name] | Runs the exercise day to day, approves leg-ups, owns deconfliction and the stop decision | May pause or halt the exercise at any time |
| Backup Control Team Lead | [Name] | Covers absence of the lead with the same authority | As lead |
| Control team members (trusted agents) | [3 to 5 names: e.g. security operations manager, IT operations lead, legal, communications] | Keep the exercise secret, deconflict real escalations, advise on business impact | Escalate to the lead; may not tip off defenders |
| Red team lead | [Provider name and lead] | Delivers the test plan within this RoE, keeps the activity log, reports risk events immediately | Must stop when instructed |
| Blue team | [SOC, incident response, IT] | Defend as normal, unaware of the exercise | Normal incident authority |
| Legal counsel | [Name] | Confirms legal basis, third-party permissions, data handling and contract terms | May veto scope items |
| Regulator or test manager (if applicable) | [Authority] | Oversees a regulated exercise | As set by the framework |
3.1 The control team must be kept as small as practicable. All control team members must sign a confidentiality undertaking before scoping begins.
4. Policy statements
4.1 Authorisation and legal basis
- No activity may begin until the authorisation letter in Annex C is signed by the Exercise Sponsor and, where required, the owner of each in-scope entity. The letter names the systems, sites, people, dates, provider and the Control Team Lead's 24x7 contact.
- Each tester must carry a copy of the letter, with a verification method (for example a named contact and phone number the recipient can call), so that anyone who intercepts the activity can confirm it is authorised.
- In the UK, the exercise must be authorised so that no tester commits an offence of unauthorised access under the Computer Misuse Act 1990. In the US, testing must not access a computer "without authorization" or exceed authorised access within the meaning of 18 U.S.C. 1030 (the Computer Fraud and Abuse Act), which also provides a civil action. The US Department of Justice policy of 19 May 2022 says good-faith security research should not be charged under the CFAA, but that policy is prosecutorial discretion, not a defence, and it does not replace written authorisation. Other jurisdictions in Annex B must be reviewed by [Legal].
4.2 Communications and deconfliction
- The red team and control team must use an agreed out-of-band channel, separate from [Organisation]'s production email and chat, with a fallback phone bridge.
- The red team must maintain a timestamped activity log of every action, source address and account used, shared with the Control Team Lead at least [daily].
- When the blue team escalates an incident, the trusted agent on duty must check it against the activity log before it reaches executive incident management, law enforcement, regulators or customers. If the activity is the red team, the control team decides whether to let the response continue or to intervene quietly.
- If the activity is not the red team, it must be treated as a real incident immediately and the exercise paused.
- A stop code word, [code word], held by the control team and red team lead, ends all activity at once when spoken on any channel.
- Out-of-hours cover: a control team member must be reachable 24x7 for the duration of active testing.
4.3 Stop, pause and escalation conditions
The red team must stop the affected activity and contact the Control Team Lead within [15 minutes] if any of the following occurs:
| Trigger | Action | Decision owner |
|---|---|---|
| Unplanned degradation of a production service or safety system | Stop immediately, give full details of the last actions, support recovery | Control Team Lead |
| Evidence of a real compromise or another attacker | Pause, preserve evidence, hand over to incident response | Control Team Lead with CISO |
| Critical vulnerability with immediate risk to [Organisation] or customers | Report immediately rather than at the end | Control Team Lead |
| Access to out-of-scope systems, third-party data or special category personal data | Stop, record what was seen, do not copy | Control Team Lead with Legal |
| Blue team escalation about to reach executives, regulators, police or the public | Control team deconflicts and may pause | Control Team Lead |
| Red team unsure whether an action is in scope or high risk | Ask before acting | Control Team Lead |
The TIBER-EU control team guidance expects the control team to intervene only to prevent unwanted business impact, and to pause when escalation is uncontrolled, for example a decision to shut down critical servers or file a police report. [Organisation] adopts the same principle.
4.4 High-risk actions and leg-ups
- Actions the test plan classes as high risk, such as actions against production availability, financial transactions or customer-facing systems, require written approval from the Control Team Lead before execution, and should be demonstrated in a replica environment where one exists.
- A leg-up (access, credentials or information provided by the control team to let the scenario continue when a stage cannot be completed in the time available) must be requested in writing, approved by the Control Team Lead, logged in Annex E with time and justification, and reported in the final report. A leg-up must never give direct access to a flag or disable a security control.
4.5 Data handling
- The red team must collect the minimum evidence needed to prove a flag: screenshots, hashes or file listings rather than copies of data.
- Personal data must not be exfiltrated outside [Organisation]'s environment. Where proof is unavoidable, it must be stored encrypted in [agreed location] and processed as [Organisation]'s processor under the contract and UK GDPR or GDPR Article 28.
- All exercise data, logs and evidence held by the provider must be securely destroyed within [30] days of report acceptance, with a written destruction certificate.
- Credentials and accounts created or obtained during the exercise must be listed in the clean-up report, and every credential the red team touched, including service account passwords, API keys and tokens, must be rotated. See the Service Account Security Guide.
4.6 Clean-up and reporting
- At the end of active testing the red team must remove every artefact it placed and deliver a clean-up report listing each item, its location and its removal status. The control team must verify removal.
- The provider must deliver a draft report within [x] weeks, including the timeline, flags achieved, detection and response observations, leg-ups used and prioritised findings. A replay or purple team session with the blue team should follow.
- Findings must be logged in [Organisation]'s remediation tracker with owners and due dates, and closure confirmed by retesting the specific behaviour.
5. Exceptions
5.1 Any departure from this document must be requested in writing by the red team lead or a control team member, approved by the Control Team Lead and, for scope or legal matters, by the Exercise Sponsor and [Legal], and recorded in Annex E before the action is taken.
5.2 No exception may authorise testing of an asset whose owner has not consented, nor remove the stop conditions in section 4.3.
6. Compliance and monitoring
6.1 The Control Team Lead must review the activity log against scope at least [daily] and record any breach of these rules.
6.2 Breach of scope or of the stop conditions by the provider is a material breach of contract. The Exercise Sponsor may terminate the exercise and require immediate clean-up.
6.3 The final report must include an RoE compliance statement signed by the red team lead and countersigned by the Control Team Lead, listing exceptions and leg-ups.
| Framework | Reference | What this template evidences |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-8, CA-8(1), CA-8(2) | Authorised penetration testing by an independent team; red team exercises |
| NIST CSF 2.0 | GV.RR-02; ID.IM-02 | Defined roles and authorities; improvements identified from security tests and exercises |
| CIS Controls v8.1 | Control 18 (Penetration Testing) | Programme with defined scope and rules |
| DORA | Delegated Regulation (EU) 2025/1190 | Risk management in TLPT preparation and testing |
7. Review and approval
7.1 This template is owned by [CISO] and reviewed at least annually and after every exercise in which an RoE gap was found.
7.2 Approval of this completed RoE for [Exercise code name]:
| Role | Name | Signature | Date |
|---|---|---|---|
| Exercise Sponsor | [ ] | [ ] | [ ] |
| Control Team Lead | [ ] | [ ] | [ ] |
| Legal counsel | [ ] | [ ] | [ ] |
| Provider authorised signatory | [ ] | [ ] | [ ] |
| Third-party owners (per Annex B) | [ ] | [ ] | [ ] |
Annexes: A, flags and objectives. B, scope register with consenting owner for each item. C, authorisation letter. D, contact sheet and channels. E, change, exception and leg-up log.
Implementation guidance
- Start with the sponsor and legal, not the provider. Agree the business functions, the risk appetite and who can sign before procurement, so the contract can reference this RoE.
- Build the scope register from ownership, not IP ranges. For each asset record the legal owner and hosting party; cloud, SaaS and managed services usually need separate consent or a published policy check.
- Rehearse deconfliction. Run a short tabletop with the control team: a blue team escalation arrives at 02:00; who checks the log, who decides, how the stop word is used.
- Size it to the organisation. A smaller organisation may combine sponsor and Control Team Lead roles, but should keep legal review and a named backup. Large groups need per-entity consent.
- Measure the governance, not just the findings. Track RoE breaches (target zero), leg-ups used, stop events and time to deconflict, alongside detection results.
- Close the loop on identities. Treat the clean-up report and credential rotation as exit criteria: the exercise is not complete until both are verified. See the Red Teaming AI Agents for Identity Abuse where agents or their credentials are in scope.
Standards and references
- legislation.gov.uk: Computer Misuse Act 1990, section 17
- Cornell LII: 18 U.S. Code 1030, Fraud and related activity in connection with computers
- US Department of Justice: New policy for charging cases under the Computer Fraud and Abuse Act
- European Central Bank: TIBER-EU Framework
- Association of Banks in Singapore: Red Team Adversarial Attack Simulation Exercises Guidelines
- NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
Related NHI Mgmt Group resources: Red Teaming Guide · Purple Teaming Guide · Penetration Test Scoping Checklist · Penetration Testing Guide. This template is not legal advice.