8.3a Rules of Engagement
8.3a Rules of Engagement
What you're building: The written safety and authorization boundary for the engagement. This is the document legal, leadership, operations, and the engagement team align on before testing starts.
Rules of Engagement are the safety contract for the engagement. They protect the client, the operators, the legal team, and internal stakeholders by defining exactly what is allowed, what is forbidden, who can approve changes, and when testing must stop. If the RoE is vague, the engagement will drift into confusion, unplanned risk, and political fallout.
At minimum, the RoE should be reviewed by legal, the executive sponsor, the technical owner of the environment, and the defensive stakeholders who may need to deconflict activity (SOC, IR, NOC, cloud ops, or MSP).
| RoE Section | What Must Be Captured | Why It Matters |
|---|---|---|
| Business Objective | Why the engagement exists, success criteria, primary objectives, assumed threat model | Keeps the exercise aligned with leadership intent instead of turning into unscoped "try everything" testing |
| Authorization | Named client sponsor, statement of authorization, legal approval, contract/SOW reference, dates of validity | Proves the activity is authorized and bounded in time |
| In Scope | IP ranges, domains, applications, cloud accounts, offices, user groups, subsidiaries, APIs, wireless ranges | Prevents accidental testing of assets the client did not approve |
| Out of Scope | Critical systems, life-safety systems, payment environments, production databases, third-party systems, regulated enclaves | Reduces the chance of business disruption and legal issues |
| Permitted Activities | What is allowed: internal testing, phishing, password spraying, physical access attempts, cloud simulation, persistence checks | Stops disputes later about whether a technique was approved |
| Prohibited Activities | What is forbidden: denial of service, ransomware simulation on production, destructive payloads, data deletion, unsafe malware detonation | Protects availability and safety |
| Testing Windows | Start/end dates, daily hours, blackout periods, change freezes, maintenance windows, holidays | Keeps testing away from sensitive operational periods |
| Safety Boundaries | Maximum spray rate, lockout thresholds, bandwidth caps, data exfil simulation limits, no-touch assets | Prevents operational impact from otherwise valid test activity |
| Stop Conditions | Conditions that require immediate pause: service instability, patient/customer safety issue, severe business impact, legal concern, mistaken third-party impact | Gives operators a clear trigger to stop before damage spreads |
| Escalation Path | 24/7 contacts, phone numbers, backup contacts, who can approve scope changes, incident bridge process | Ensures fast coordination when something unexpected happens |
| Deconfliction Plan | Whether SOC/IR is informed, what detections are expected, how false positives or real incidents are handled | Avoids collisions between the engagement and live response processes |
| Evidence Handling | How screenshots, logs, packets, credentials, and sensitive files are stored, transmitted, encrypted, and destroyed | Protects sensitive client data and supports legal defensibility |
| Data Handling Limits | Whether real data may be accessed, copied, or only sampled; redaction requirements; approval needed for high-risk evidence | Reduces privacy and compliance exposure |
| Credentials & Accounts | Use of supplied accounts, test accounts, emergency admin accounts, credential storage rules, password rotation after the test | Prevents credential misuse and cleanup gaps |
| Third-Party Coordination | MSPs, cloud providers, ISPs, SaaS owners, building security, or facilities teams that must be informed | Shared environments often create the biggest legal and operational surprises |
| Communications Plan | Daily updates, status cadence, critical finding notification threshold, report delivery expectations | Keeps leadership and technical teams informed during the engagement |
| Cleanup & Restoration | Removal of payloads, accounts, firewall rules, persistence, redirects, cloud artifacts, and temporary infrastructure | Ensures the environment is returned to an agreed state |
| Sign-Offs | Legal, executive sponsor, engagement lead, infrastructure owner, SOC/IR lead, and any third-party owner if applicable | Confirms all relevant stakeholders accepted the risk and boundaries |
Practical RoE Template
## Rules of Engagement
### 1. Authorization
- Executive Sponsor: [Name, Title]
- Legal Approval: [Name / Ticket / Contract Reference]
- Engagement Dates: [Start] to [End]
### 2. Objectives
- Primary Objective: [e.g., validate whether an assumed-breach attacker can reach crown-jewel systems]
- Secondary Objectives: [phishing resilience, detection validation, cloud privilege escalation, etc.]
### 3. Scope
- In Scope: [IPs, domains, apps, offices, cloud accounts]
- Out of Scope: [life-safety systems, payment systems, third-party assets, named servers]
### 4. Allowed Techniques
- [e.g., phishing, password spraying, authenticated internal testing, cloud role abuse simulation]
### 5. Prohibited Techniques
- [e.g., DoS, destructive actions, data deletion, unsafe malware execution]
### 6. Time Windows
- Testing Hours: [e.g., 19:00-05:00 local]
- Blackout Periods: [Month-end close, patch window, board meeting, change freeze]
### 7. Safety Limits
- Account lockout threshold: [X attempts]
- Max request rate: [X requests/sec]
- Data access rule: [sample only / metadata only / no production data export]
### 8. Stop Conditions
- [Any service instability, customer impact, legal concern, or third-party impact requires immediate pause]
### 9. Communications & Escalation
- Primary Contact: [Name, phone]
- Secondary Contact: [Name, phone]
- Critical Finding Notification SLA: [e.g., within 1 hour]
### 10. Evidence Handling
- Storage: [encrypted container]
- Retention: [duration]
- Destruction: [method and owner]
### 11. Cleanup
- Remove test accounts, payloads, persistence, firewall rules, and temporary infrastructure by [date]
### 12. Approvals
- Legal: __________
- Executive Sponsor: __________
- Technical Owner: __________
- SOC/IR Lead: __________
NOTE: If a red team engagement does not have a written RoE signed by the right stakeholders, treat that as a process failure. The RoE is not paperwork - it is the document that prevents outages, misunderstandings, and unauthorized activity.
Companion to 8.3 Technical Report Writing.