Rules of Engagement

Legal

In an authorized red team engagement the rules of engagement are an operating document, not a formality. They settle who can stop the work, how the client's defenders tell your activity apart from a real intruder, and which assets you may touch. Getting any of those three wrong is how engagements turn into incidents.

Sign-off comes from an executive who owns the systems in scope

A red team operation must be authorized by a named executive with authority over the systems and people in scope — typically the CISO, the CEO, or General Counsel. Record a primary and an alternate authoriser, each with a monitored 24/7 number. A mid-level IT manager cannot authorize activity that can disrupt operations or touch employee privacy, and an authoriser nobody can reach is not an authoriser.

This page is one layer of a longer document

The full rules-of-engagement template — approval tables, signature blocks, insurance and indemnity language — lives on Rules of Engagement template. Use that document as the contract and this page as the red-team annex that sits inside it. Country-by-country legal analysis is maintained on Legal Considerations, not here.

The Red-Team Annex

Four clauses do the safety work, and they are the ones engagements most often get wrong: deconfliction, stop authority, scope by asset list, and disclosure when a responder treats the activity as real. The template below keeps only those plus the evidence-handling clauses that depend on them.

red-team-annex.md

# Red Team Annex - Rules of Engagement

## 1. Authorization
- Authorising executive (primary): CISO, name, signature, date
- Authorising executive (alternate): name, signature, monitored 24/7 number
- Legal review: General Counsel, separate signature and date
- Engagement window: 1 Feb - 31 May 2026, activity hours 08:00-18:00 UTC
- Review cadence: annex re-signed at each window extension

## 2. Scope - client-supplied asset list
- In scope: the entries in Annex A only (asset IDs, hostnames, IPs, OUs, sites)
- Anything not listed in Annex A is out of scope - including RFC1918 space,
  which frequently resolves to managed or third-party systems
- Excluded unless listed: production databases, cardholder-data environment,
  safety systems (fire, HVAC, alarms), third-party and SaaS tenants,
  personal devices, executive assistants and executive offices
- Asset list owner: client-side, named, with a change procedure

## 3. Deconfliction
- Channel: designated client contact plus out-of-band phone, staffed for every
  hour the engagement is active
- Marker: ticket tag "RT-2026-014" and the agreed verification phrase, issued to
  the SOC and the help desk before the first action
- Log every deconfliction call with a UTC timestamp on both sides
- The channel is never switched off to protect the test

## 4. Stop authority and escalation
- Stop authority: engagement lead, primary authoriser, alternate authoriser,
  and the client duty security officer on shift
- Any of them may halt the engagement; the red team stops first and resolves
  the disagreement afterwards
- Halt conditions: suspected real intrusion, business disruption, scope
  ambiguity, safety risk, law-enforcement contact, media contact

## 5. Disclosure to responders
- If any responder treats the activity as a real intrusion, the operator
  discloses to the designated contact immediately, before continuing
- No clause in this document authorizes withholding that disclosure, and no
  objective is worth an unreported incident

## 6. Objectives and success criteria
- Objective: demonstrate access to the agreed target and prove the
  exfiltration path using synthetic or canary records only
- Success: objective reached, path evidenced, control response measured
- Real client data is not the proof of the finding; the path is

## 7. Data handling
- Credentials: approved test accounts only, no real user password storage
- Data movement: synthetic canary records, training tokens, approved collectors
- Evidence encrypted at rest, access list recorded, retention and deletion
  dates fixed before the first action

## 8. Persistence and cleanup (separately initialled annex)
- Each persistence mechanism, host, and removal procedure listed with an owner
- Requires its own initials from the primary authoriser - the general
  authorization above does not cover it
- Removal completed and evidenced within 48 hours of the closing window

## 9. Operator safety
- Named welfare contact, check-in schedule, and a no-questions stop for any
  operator who reports distress, coercion, or a safety concern
- Physical entry work: insurance certificate, local law check, escort rules

## 10. Post-engagement
- Debrief within 5 business days, executive report within 2 weeks
- Detection timeline shared with the defenders who were tested

---
Signatures:
Primary authoriser: ___________  Date: _______
Alternate authoriser: _________  Date: _______
General Counsel: ______________  Date: _______
Red Team Lead: ________________  Date: _______
Persistence annex initialled: __  Date: _______

Common ROE Pitfalls

Suppressing the deconfliction channel: an annex that tells operators to conceal their status from the client's own analysts converts a possible real intrusion into an unreported one. The agreed phrase exists so a responder can ask, and get an answer within minutes.
Supernet scope: listing 10.0.0.0/8 as in scope silently authorizes systems the client does not own, including third-party managed hosts. Scope by asset list, and state that anything unlisted is out of scope.
Single authoriser: one named executive who goes on leave mid-engagement leaves nobody able to stop the work or extend the window.
Missing stop conditions: define the halt triggers in writing, not as a shared intuition — suspected real intrusion, unresponsive production system, scope doubt.
Objectives that need real data: "exfiltrate 10GB of client records" creates a data-protection event the client then has to report. Prove the path with canary records instead.
No data handling policy: say how captured credentials, screenshots, and artefacts are stored, who can read them, and when they are destroyed.
Email approval only: get signatures on the document, and a separate initialled annex for anything the base authorization does not cover.
No evidence discipline: every action needs a timestamped record. If a lawyer or a regulator asks, the log is the only thing that distinguishes an authorized test from an intrusion.

Document everything, including the stops

Keep a timestamped log of all activity, and log the deconfliction calls and stop commands as carefully as the offensive actions. An engagement that was halted correctly and can prove it is a successful engagement; one that continued through a suspected incident is a finding against the red team.

Legal Review Belongs to the Lawyers

This page deliberately does not summarize statutes. Authorization-to-test law differs by jurisdiction, changes without notice, and is the one part of an engagement that must be read in its current form rather than recalled from an operations page. The maintained material is:

Legal Considerations — country-by-country analysis, including computer-misuse and data-protection obligations that apply to testing.
Rules of Engagement template — the signature-ready document this annex attaches to.
Compliance checklist — the pre-engagement checks to complete before the first action.

Have counsel review the signed annex for the specific jurisdictions in scope. A red team page, this one included, is the wrong place to keep an answer to a legal question.