What is a stop word in a red-team exercise?

It is a single agreed code word that either side can use to stop all activity at once. Using it requires a call to the named contacts. It sits next to written stop conditions, such as real damage, a real intruder being found or the team reaching an out-of-scope system.

Who has to know a red-team exercise is happening?

The sponsor, legal counsel and usually one security leader, who form a small group called the white cell. The defenders often do not know, because the exercise tests whether they notice. If they escalate, the white cell confirms or denies that the activity is the team's without revealing the plan. Any outside party who might see the traffic, such as a managed detection provider, should be told in advance.

How is a red-team exercise different from a penetration test?

A penetration test looks for as many weaknesses as it can in an agreed system. A red-team exercise has a goal, such as reaching a sensitive file share, and pursues it as a determined attacker would, often over weeks and often without telling the defenders. Because it is covert and broad, its rules of engagement need to be tighter.

Red-Team Rules of Engagement Checklist

Key takeaways

A red team tests people, process and detection as well as technology, so the rules of engagement must cover social engineering, physical access and persistence, which an ordinary penetration test does not.
Written authorization from someone with the legal authority to give it is the foundation. Unauthorized access to a computer can violate the Computer Fraud and Abuse Act, 18 U.S.C. 1030, and permission from the wrong person is no protection.
Define stop conditions in advance: signs of real harm, an unrelated real intruder, an out-of-scope system reached by accident, or a word from the control group.
Deconfliction is how the control group tells the exercise from a real attack. Keep a small white cell who know, and agree a way to confirm or deny activity.
Decide how sensitive data found will be handled before the first day: what may be viewed, copied, shown as proof and when it is destroyed.

How a red team differs from a penetration test

A penetration test looks for as many weaknesses as it can in an agreed system. A red-team exercise has a goal, such as reaching a sensitive file share or proving the ability to move money, and the team pursues it the way a determined attacker would, often over weeks and often without telling the defenders. The question it answers is whether your people and tools notice and stop a realistic attack. Our article on penetration tests, scans and red teams helps choose between them. Because the exercise is covert and broad, its rules of engagement (ROE) need to be tighter.

NIST SP 800-115 describes planning and conducting security testing, including the need for rules of engagement and management approval. NIST SP 800-53 includes red-team exercises as a control enhancement for organizations that want that rigor. The European Central Bank's TIBER-EU framework is a mature public example of how an intelligence-led red-team test is governed, with a control team and a white team.

1. Authorization and parties

A signed authorization from an officer who can authorize testing of every system in scope. If cloud or hosting providers or a managed provider run part of the environment, check their testing policies and get consent where needed. Our article on written penetration test authorization covers the document.
Named people on both sides, with 24-hour contacts for the engagement.
Dates, hours and any blackout windows, such as month-end close or a product launch.
A statement of the exercise objective and the evidence needed to show it was reached.

2. Scope: in, out and gray

In scope: named domains, IP ranges, cloud accounts, applications, sites, and the staff groups who may be approached.
Out of scope: production safety systems, life-safety and medical devices, third-party systems not covered by consent, personal accounts and devices, family members, and anything the leadership will not accept the risk for.
Techniques: whether phishing, phone pretexting, physical entry, wireless attacks, malware and persistence are allowed, and any limits, such as no destructive payloads and no denial of service.
Gray areas: what happens if the team finds a path into an out-of-scope system. The usual rule is to stop, document and ask, not to continue.

MITRE ATT&CK is a common vocabulary for agreeing on which techniques are allowed and for mapping what the defenders saw.

3. Stop conditions and the safe word

Write down the events that pause or end the exercise, and who can call it:

Any sign of real damage, outage or data loss caused by the team.
Discovery that a real intruder is, or was, in the environment. The exercise stops while the real incident is handled.
The team reaches an out-of-scope system, or obtains data the ROE says not to touch.
A person in the exercise is distressed or at risk, for example during physical entry or pretext calls.
A legal or regulatory trigger, such as the discovery of unlawful material, which follows its own agreed procedure.
A single agreed code word, used by either side, that stops all activity at once and requires a call to the named contacts.

4. Deconfliction

If the defenders do not know about the exercise, they will treat it as a real attack, and they should. That is the point. But they need a safe way to learn that it is not, when the cost of a full response would be wrong. The mechanism is a white cell, a small group, often the sponsor, legal counsel and one security leader, who know about the exercise and can answer one question: is this activity ours?

The red team keeps a log of IP addresses, accounts, tools, hostnames and timestamps, shared with the white cell on a schedule.
When the defenders escalate, they ask the white cell, who confirm or deny without revealing the plan.
Agree in advance when a response should be allowed to run its course, and when it must be stopped before it affects customers, law enforcement or the public.
Plan a notification for any outside party who might see the traffic, such as a managed detection provider, so they do not call the authorities.

5. Data handling

Define what counts as sensitive: personal data, health information, card data, privileged material, credentials, secrets and trade secrets.
Prefer proof that does not copy data: a screenshot with the content masked, a directory listing or a harmless marker file placed by the team.
If data must be taken, encrypt it, keep it on controlled systems and delete it at the end, with written confirmation.
Handle credentials the team captures as sensitive: store them encrypted, report them for rotation and never reuse them outside scope.
Make clear who owns the report and its distribution. It will describe exactly how to break in.

6. After the exercise

A debrief with defenders and the white cell: what was seen, what was missed and why.
A timeline mapping the red team's actions to detections.
Cleanup: removal of accounts, implants and test data, verified by the client.
Fixes tracked to closure and a retest of the failed detections.

Our Cybersecurity team writes the ROE with you before a red-team engagement, runs the exercise and the debrief. This article is general information and not legal advice.

Sources

This article is general information, not legal advice. Have counsel review any authorization and rules of engagement before testing begins. Last reviewed November 9, 2026.

Keep reading

Next · SecurityPrompt-Injection Test Cases for a Support-Ticket AI AgentA support agent that reads tickets and can look up accounts or send replies treats every customer message as input it might obey. Here are concrete test cases for injection through tickets and attachments, for tool abuse and for data leaving through links.9 min read

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity

Rules of Engagement for a Red-Team Exercise: Scope, Stop Conditions, Deconfliction and Data