How to Set Rules of Engagement for a Red Team

Key Takeaways

• A rules of engagement document is what turns a red team test from a legal risk into an approved, protected exercise.
• Every RoE needs five things at minimum: objectives, scope, authorized actions, communication protocols, and legal sign-off.
• Autonomous red teaming still needs an RoE. The document just has to account for machine speed and constant testing instead of a two-week window.
• Mapping your test to MITRE ATT&CK gives you a shared language between the red team and the people defending the network.
• Your blue team’s readiness matters as much as your red team’s plan. A test only pays off if someone is watching for it.

A red team at a financial company once used a public LinkedIn post to figure out which software version an employee’s laptop was running. That one post led to a foothold on the internal network. No firewall stopped it. No rule was broken. The team was simply doing what real attackers do, and the rules of engagement they signed beforehand made sure that was expected, not an accident.

That is the whole point of rules of engagement. Without one, a red team test is just unauthorized hacking with better intentions.

What a Red Team Rules of Engagement Document Actually Does

A rules of engagement document, usually shortened to RoE, spells out what a red team is allowed to do, where they can do it, and who signs off on the whole thing. Think of it as the contract that keeps a simulated attack from turning into a real incident.

Without one, things go wrong fast. A test with no clear scope can end up hitting production servers the client never meant to include. A test with no communication plan can leave the security team responding to what they think is a real breach, wasting hours chasing a threat that was never real in the first place.

Red teaming is not the same as a regular penetration test, and that difference matters for how you write the RoE. A pentest usually tries to find and confirm as many vulnerabilities as it can across a wide surface. Red teaming picks one goal, like reaching a specific data set or admin account, and tests whether your people and tools would catch a determined attacker trying to get there through adversary emulation and real-world tactics, techniques, and procedures.

How to Build Red Team Rules of Engagement Step by Step

You don’t need a 40-page legal document to run a solid engagement. You do need to cover these parts, in this order.

Set the Objective First

Before anything else, decide what you’re actually testing. Are you checking if your SOC can detect lateral movement? Testing whether a phishing email can reach finance? Trying to see how far someone could get after stealing a laptop?

Write the objective as one sentence. If you can’t do that, the scope conversation that follows will be a mess.

Define the Scope Boundaries

This is where most disputes happen later, so get specific.

• List exact IP ranges, domains, and applications that are in scope.
• Call out anything that looks close but is off limits, like a shared vendor environment or a production database with real customer data.
• Decide if physical access attempts (badge cloning, tailgating into an office) are part of this round or saved for later.
• Set a start and end date. Red team work that drags on for weeks stops being a focused test and starts looking like an open-ended pentest.

Spell Out What’s Authorized and What’s Not

Vague language here causes real damage. Say plainly what the team can and cannot do:

• Can they view or modify files, including personal data or emails, if it helps prove access?
• Are they allowed to create new accounts, or only modify existing ones without deleting them?
• Is any form of denial of service testing allowed, even briefly?
• Which tools are approved, and which are explicitly banned?

A good rule of thumb: if an action could cause downtime or destroy data, it needs its own line item and its own approval, not a blanket yes.

Build a Communication and Deconfliction Plan

Someone on the client side, often called a trusted agent or white team lead, needs to know the test is happening even if the rest of the SOC does not. This person is your safety valve.

• Set a check-in schedule, whether that’s daily or only at major milestones.
• Agree on a kill switch phrase or process to pause the test immediately if something looks like it’s spiraling.
• Decide how the red team reports a real vulnerability they weren’t expecting to find, like an unrelated open S3 bucket sitting outside the agreed scope.

Get Legal Authorization and Sign-Off

This part protects everyone. The RoE should be signed by someone who actually has authority over the systems being tested, not just a manager who wants the test to happen. Keep a copy on file. If a question ever comes up about whether an action was authorized, this document is the answer.

Plan the Cleanup

Testing doesn’t end when the report is written. The team needs to remove any accounts they created, delete test malware and command and control tools, and revoke any access they were given. Leftover backdoors from a red team test are just as dangerous as ones left by a real attacker.

What Changes When You Add Autonomous Red Teaming and MITRE ATT&CK

Traditional red teaming runs on a calendar. A human team plans an engagement, tests for two or three weeks, then writes a report. Autonomous red teaming doesn’t wait for a quarterly window. AI-driven agents can run continuously, adjusting tactics in real time based on what the environment throws back at them.

That changes what your RoE needs to cover. A few things to add:

• Approval thresholds. Decide which actions the autonomous system can take on its own and which ones need a human to click approve first. Most mature setups keep destructive or ambiguous actions in a human-in-the-loop model, while low-risk, read-only actions run automatically.
• Always-on scope enforcement. Since there’s no human rechecking scope every hour, the system itself has to validate every action against the approved boundary before it fires. Anything discovered outside that boundary should get logged, not probed.
• Review cadence. Continuous testing needs a continuous review schedule too, not just a single report at the end.

This is also where MITRE ATT&CK earns its place in the conversation. ATT&CK is a public library of real tactics, techniques, and procedures used by known threat actors. Anchoring your red team plan to specific ATT&CK techniques does two things. It makes the test realistic instead of random, and it gives your defenders a shared vocabulary to talk about what happened. A finding that says “the team achieved persistence through a registry run key” means something specific and repeatable, in a way that “they got in and stayed in” does not.

FAQs

Conclusion

A rules of engagement document is not paperwork you rush through to get to the fun part. It’s what makes the fun part possible in the first place. Get the objective, scope, authorized actions, communication plan, and sign-off right, and your red team can test like a real adversary without putting the business at risk. Skip any one of those, and you’re not running a red team exercise. You’re just hoping nothing breaks.