Red Team Rules of Engagement: Scope, Limits and Practices

Red team exercises mimic how cybercriminals move, where they strike, and how quickly defenses respond. But when these tests are conducted without clear rules of engagement, teams may end up chasing the wrong objectives, or worse, disrupting critical systems offline. 

This damage isn’t hypothetical. An exercise with unclear scope can cost as much as an actual breach. A solid RoE is what keeps a red team exercise focused. 

In this blog, we’ll discuss various aspects of red team rules of engagement, the core elements of RoE, and best practices for executing red team rules of engagement. 

What Are Red Team Rules of Engagement(RoE)?

Red Team Rules of Engagement (RoE) are formal documents that clearly define the scope, boundaries, permitted activities, and limitations of a red team operation. It tells what they can do, where they can attack, and to what extent. 

It brings clarity in the process as each of the involved parties understand the parameters of the simulated attack. 

A well-defined RoE minimizes risks, prevents unintended disruptions, and maximizes the value of the red team exercise by aligning expectations and establishing clear communication protocols.

It’s a legally binding document that protects both the red team and the client, by clearly scoping responsibilities, limitations, and escalation procedures. 

Let’s understand this with an example: 

A hospital hires a red team to test defenses against ransomware.

Without Rules of Engagement:

Without clear rules, red teamers might attack life‑support systems or patient data servers, which may risk patient safety.

With Rules of Engagement:

It lets the hospital measure its response to threats without endangering patients or breaking laws.

• Only administrative networks and staff email are in scope.
• Medical devices and patient records are off-limits.
• Ransomware simulation must use dummy files, not real encryption.
• Any disruption must be reported to the IT head right away.

Why Rules of Engagement (RoE) Matters

• Precise RoE helps organizations avoid legal pitfalls, for instance, restricting tests that might breach data protection frameworks like GDPR, HIPAA, or PCI DSS. 

• Set by widely accepted ethical standards, such as NIST and the Offensive Security Certified Professional (OSCP) programs.  
• Minimize potential harm from accidental data loss, leaks, or service disruption.
• Build trust between red team, defenders, and business stakeholders by ensuring ethical conduct.

Learn about HIPAA Compliance Checklist 2025

Core Elements of an Effective RoE

Scope and Objectives

Red teaming is like an actual attack and that’s why setting the boundary is important. Else, the chance of failure will be high. Red teams should know what they are going to test and at what depth.  

• Focus on goals that matter, such as finding blind spots, testing detection, or probing how far an attacker can go. 
• Chooses systems based on what’s most critical to the business, and not just what’s easiest to hit.
• Sets success metrics clearly.

Prior Approval and Authorization

Robust Rules of Engagement require formal prior approval from senior leadership to ensure accountability and alignment. For example:

• Approval must be granted by at least one layer of the Security Incident Response Team (SIRT) leadership, from SIRT managers up to the CISO.
• The Senior Manager responsible for the Red Team must approve each operation.
• All “trusted participants” involved in stealth or sensitive exercises must sign off during the logistics phase.
• Approvals are documented clearly within the logistics planning to maintain transparency and traceability.

Authorized and Prohibited Actions

Spells out which tactics the red team can use, and what’s not allowed—so the test is useful, safe, and legally sound.

• Tactics like phishing, USB drops, or fake badge access might be allowed, if they’re safe and scoped.
• Some actions—like pulling live customer data or crashing a system, are clearly off-limits.
• Prevents unnecessary risk by putting legal and ethical guardrails in place.
• Keeps all parties aligned on what’s approved, avoiding surprises later.

Target Space and Boundaries

It includes details on which systems, networks, or physical locations can be tested, and sets the timeframes to avoid disruptions.

• Includes  test environments, public web apps, or office entry points.
• Excludes production databases, sensitive employee systems, or any critical infrastructure.
• Time limits may keep tests to off-hours or avoid periods like audits and major releases.

These guardrails help the red team go deeper without triggering unplanned outages or risk.

Data Handling

It is about how the red team will deal with the sensitive data during the operation. The RoE clearly states

• Explicitly state which data types are considered sensitive (e.g., patient records, financial accounts, personal identifiers).
• Define strict limits on when and how the red team accesses any sensitive system.
• Require prior written authorization for any real data access.
• Prohibit direct alteration of live sensitive data, such as changing medical records or financial balances.
• Mandate the use of approved scripts or sandboxed environments if data integrity testing is required.

Roles and Responsibilities

The Red Team ROE should clearly state who’s involved in the red teaming operations, what they’re responsible for, and how coordination will happen during the test.

• The red team is primarily responsible for attack simulation and they need to stay within the defined scope. 
• The blue team is responsible for monitoring and defending, and they should be aware of what the red team is going to do. 
• A separate team watches over everything, and they step in whenever needed. 

The separation of roles and responsibilities avoids confusion or duplication of effort during real incidents.

Legal & Compliance Safeguards

It protects everyone involved by ensuring the test is authorized, documented, and aligned with laws and industry rules.

• Takes into account compliance needs, such as PCI, HIPAA, GDPR, or others.
• Requires formal sign-off, letters of engagement, indemnity, or executive approvals.
• Maintains a full record of the test for audit or legal defense.
• Everyone involved knows the test is above board—and covered from a liability standpoint.

Common Mistakes to Avoid in Red Team ROE

Vague Scope

• Defining rules too narrowly limits realistic testing, while too loose definitions increase risk of damage.

For example, specifying only web servers as in-scope may miss gaps in internal networks; setting no clear boundaries can cause accidental impact on production databases.

• Clearly delineate which assets are in-scope and explicitly exclude critical systems.

Lacks Insufficient Access Control Explanation

• Not standardizing access controls leads to inconsistent enforcement and unauthorized testing.

For example, without specifying privilege levels, red teamers might escalate privileges inappropriately or access restricted HR data.

• Establish clear policies on resource access and permissible privilege escalation.

Ignoring Social Engineering Risks

• Failing to limit social engineering tactics risks legal violations or harm to employees.

For example, allowing unrestricted phishing campaigns could target executives’ personal emails, causing distress or real-world impact.

• Define allowed tactics (e.g., internal phishing only) and prohibit high-risk targets like HR or finance staff.

Inadequate Communication and Escalation Protocols

• Lack of real-time reporting slows incident responses and increases risk.

For example, a red team accidentally disrupts a critical service but fails to notify IT promptly, delaying mitigation.

• Assign an empowered point of contact and clear escalation paths for emergencies.

Poor Coordination with Blue Team

• Informing defenders too early undermines the fidelity of detection tests.

For example, the blue team receives advance notice of every test phase, invalidating true attack detection assessments.

• Delay defender notification until key detection milestones are reached.

Neglecting Data Handling Rules

• Using live sensitive data without safeguards risks compliance breaches and data loss.

For example, encrypting real patient records during ransomware simulation causes compliance violations and patient risk.

• Require dummy or sanitized datasets and sandboxed environments for sensitive data tests.

Micromanagement

• Excessive oversight disrupts red team creativity and realism.

For example, constant check-ins and approvals during tests break engagement flow and reduce authenticity.

• Trust red teams to operate within agreed boundaries, involving you only when critical issues arise.

Best Practices for Red Teams Rules of Engagement (ROE)

1. Involve Stakeholders Early

• Engage all crucial stakeholders from compliance, HR, and infrastructure as security doesn’t exist in a vacuum. 
• Builds trust and avoids pushback during execution or reporting.

2. Map Scope to Business Impact

• Don’t just list IP ranges or domains. Connect each asset to business functions.
• Prioritize systems with high data sensitivity, financial exposure, or operational reliance.
• Test what actually matters to business resilience, not just random attack surfaces.

3. Use Threat-Informed Scenarios

• Base scenarios on real-world adversary behavior (e.g., FIN7, APT29) using frameworks like MITRE ATT&CK.
• Mimic real tactics attackers use in your industry (e.g., phishing in finance, third-party pivoting in healthcare).
• Supports purple teaming and detection tuning based on known gaps.

Learn More on MITRE ATT&CK framework and core tactics

4. Define Clear Escalation Paths

• Clearly spell out what constitutes a critical event.
• Name the responsible contacts from the red team, white cell, and business owners.
• Include multiple communication modes, such as phone, email, secure chat) for redundancy.

5. Specify Tool and Technique Restrictions

• List approved vs. prohibited tools explicitly (e.g., no ransomware simulators on prod).
• Don’t use risky techniques that can damage systems (e.g., brute-forcing AD, production DoS).

6. Time the Engagement Strategically

• Coordinate with business calendars to avoid peak activity or change freezes.
• Schedule after-hours tests only if explicitly approved.
• Avoid reputational fallout from accidental disruptions.

7. Document Role Separation

• Avoid dual-role confusion (e.g., blue teamers involved in red activities).
• Maintains integrity of the engagement and results.

8. Account for Legal and Regulatory Boundaries

• Check if your RoE violates laws around employee surveillance, data sovereignty, or consent.
• Include sign-offs from legal counsel, especially if sensitive systems are in scope.
• Include jurisdiction-based exceptions (e.g., GDPR restrictions on personal data).

9. Limit Persistence and Lateral Movement Windows

• Define how long red teamers can stay undetected before revealing access.
• Set rules for how far and wide they can pivot across systems.
• Prevent red team from unintentionally creating persistence that outlives the engagement.

10. Require Post-Engagement Sanitization

• The red team must remove test malware, credentials, C2 infrastructure, and temp files.
• Prevents backdoors or leftover tools from being misused later.
• Includes documentation clean-up and access revocation.

11. Version and Archive Each RoE

• Every engagement should have its own signed RoE with a timestamp.
• Document who approved it and when.
• Maintain an archive for audit trails, incident response, or future planning.
• Prevents disputes over what was authorized if something goes wrong.

Red Team RoE Template and Guidance

A comprehensive Red Team RoE typically includes the following key sections:

1. Executive Summary

The purpose of this section is to provide a high-level overview of the engagement, its objectives, and the key stakeholders involved. 

Additionally, the executive summary part in the rules of engagement  should briefly outline the anticipated scope, timelines, potential business impact, and how results will be communicated to decision-makers.

2. Introduction to Rules of Engagement

The introduction section sets the stage for the detailed provisions that follow. It explains the context of the red team exercise, why it is being undertaken, and establishes the overall tone for operational boundaries and cooperation. 

3. Purpose

This section clearly defines the goals and objectives of the red team engagement that includes testing specific security controls, evaluating incident response capabilities, or identifying critical vulnerabilities. 

It also aligns these objectives with the organization’s risk appetite, compliance requirements, and strategic cybersecurity initiatives for measurable security improvement.

4. References

This section lists relevant supporting documents, policies, or standards, such as internal security policies, legal frameworks, or industry best practices. 

The primary purpose of the reference section in ROE is to lend credibility to the document. 

5. Scope

This section precisely defines what is in scope and, equally important, what is out of scope for the engagement. 

It specifies the following: 

•  Target systems (IP ranges, domains, applications)
•  Personnel and physical locations
• Specific attack vectors that are permitted or prohibited.

6. Definitions

Provides a glossary of terms and acronyms used throughout the document. It adds to the clarity of the document as users of the document may not be aware of the jargons used in the doc.  

7. Rules of Engagement and Support Agreement

This section details the following: 

• General rules governing the red team’s conduct, such as authorized methodologies, tools, and techniques. 
• Clearly outlines the support that the client will provide to the red team, such as access to facilities, network resources, or points of contact.

8. RoE Provisions (Requirements, Restrictions, and Authority)

This includes the following:

• Requirements: What the red team is expected to achieve or adhere to.
• Restrictions: Prohibited activities, such as denial-of-service attacks, social engineering against specific individuals, or actions that could lead to data loss or system instability. This also includes off-limit IP lists or critical systems.
• Authority: The extent of the red team’s authorization to conduct activities, including access levels, exploitation techniques, and data exfiltration methods.

9. Ground Rules

This covers the basic dos and don’ts for how the team will operate. It includes how everyone will stay in touch, when and how to report findings, what to do if something goes wrong, and when the team can actually work. 

You can think of it as a playbook that keeps everyone safe and on the same page.

10. Resolution of Issues/Points of Contact (POC)

Here’s who to call when things get problematic and disputes emerge among stakeholders. This section contains a list of the main people on both sides as your go-to contacts for quick decisions, emergency situations, or whenever you need to escalate something fast. Having the right phone numbers can make or break an engagement.

11. Authorization

This is where everyone puts their signature on the line. All the key players need to sign off: executives, legal teams, security folks, IT managers, and sometimes compliance officers too. 

This documentation protects you when security systems start going crazy and alarms. You can point to this document and prove you’re supposed to be there. Without it, you look like a real attacker.

The authorization creates a paper trail. It shows the organization knew exactly what they were getting into. Everyone understands the risks and takes responsibility for moving forward. This section usually contains specific dates and boundaries and also puts some technical limits.

12. Appendices

Appendices provide supplementary information that supports the main ROE document. This contains extra stuff that didn’t fit in the main document but might come in handy later. 

This may include technical details, step-by-step methods, any legal fine print, and compliance checklists, or any other supporting materials that help explain how things will actually work in practice.

Closing Thoughts

ROE are inherently iterative documents and it must be regularly reviewed and revised through active stakeholder engagement so that they adapt to new threats, organizational changes, and evolving compliance landscapes. This dynamic approach ensures the ongoing effectiveness and relevance of red team exercises in real-world contexts.

Ignoring red team rules of engagement can be as risky as real attack. It requires a matured and experienced red team to conduct offensive security testing. Contact us now to learn more.

FAQ’s