Red team rules of engagement should include, at minimum, stop conditions and safe words, an escalation tree with named contacts, a deconfliction process with your security operations team, a written and time-bound authorization letter signed by someone with legal authority, evidence and data-handling terms, out-of-scope and fragile-asset lists, testing windows, third-party notification duties, and liability and insurance terms. On the question that stalls most first-time deals: yes, a red team can in principle disrupt a production system, because real testing runs against real infrastructure. The risk is managed, not zero. The mechanisms that manage it, stop conditions, fragile-asset carve-outs, live-incident deconfliction, and a named escalation path, all live in the rules of engagement. That is why the ROE, not the statement of work, is the document you read most carefully before you sign.
Regulators now agree. On 11 February 2025 the European Central Bank updated the TIBER-EU framework to align with the Digital Operational Resilience Act (DORA), renaming the internal coordination group from "White Team" to "Control Team" and making purple-teaming mandatory, per the ECB's own announcement. On 21 November 2025 the ECB issued its Implementation Guide for how the Single Supervisory Mechanism operationalizes threat-led penetration testing (TLPT) for significant institutions under DORA Articles 26, 27, and 46, requiring each institution to appoint a single point of contact per test, as reported by Norton Rose Fulbright. In Canada, the OSFI Intelligence-led Cyber Resilience Testing (I-CRT) framework has required the same controls for systemically important banks since 2023. The controls a careful buyer wants are the controls a supervisor already expects.
This post is the Stingrai red team's reviewer-side guide to reading a vendor's ROE before you sign. It is written for the buyer, the risk officer, and the legal counsel preparing for a first red team, not for the practitioner drafting the document. The community-maintained redteam.guide ROE template remains the canonical author-side resource, and this checklist is its mirror image: what a reviewer should demand from whatever ROE a vendor puts in front of them. Every regulatory date and framework claim below links to its primary publisher so any point can be audited inline. Where a specific figure could not be traced to a named primary source, it was dropped rather than estimated.
Key takeaways
The ROE is the risk control, not paperwork. A red team runs live tradecraft against live systems. What keeps that from becoming an incident is a set of written controls: stop conditions, deconfliction, carve-outs, and an escalation path. If those are vague in the vendor's ROE, the safety is vague too.
"Can it break production?" has an honest answer, and vague reassurance is a red flag. A vendor who says "we never touch production" is either not doing real red teaming or not being precise. The mature answer is that production risk is deliberately bounded by named safeguards. Demand to see those safeguards written down.
Regulators have standardized exactly these clauses. The TIBER-EU Control Team model, the ECB SSM Implementation Guide, and OSFI I-CRT all require controlled execution, a named coordinating team, and a defined scope. A vendor whose ROE already meets that bar is one you can put in front of an examiner.
Authorization is legal armor, and the signatory matters. NIST SP 800-115 frames written, time-bound authorization from someone with the authority to grant it as the prerequisite for any test. An ROE signed by the wrong person protects no one, including the tester.
Deconfliction protects you twice. It stops the red team from being mistaken for a real attacker mid-exercise, and it stops a real breach from hiding behind the exercise. A serious ROE names how activity is confirmed as red-team activity within minutes, not hours.
What this checklist is built from
This is a reviewer's checklist, so the sources are the frameworks that define what "controlled" testing means and the standards that define authorization and safety. The regulatory anchors are the ECB TIBER-EU framework update of 11 February 2025 and the ECB SSM Implementation Guide of 21 November 2025, both operationalizing DORA's TLPT requirement, and OSFI's I-CRT framework in Canada. The methodology anchors are NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment (September 2008), which sets out authorization and rules of engagement, and the community-maintained redteam.guide ROE template on the practitioner side. The research cutoff for this post is July 2026. Claims that could not be reached against a named primary source were dropped rather than approximated, which is why you will not see an outage-probability statistic here: no defensible primary figure exists, and inventing one would undercut the point of the post.
Can a red team break production? The straight answer
Start here, because it is the objection that stalls the deal.
A red team engagement is adversary simulation against your real environment. That is the value: it tests the systems, people, and detection you actually run, not a sanitized copy. Because it is real, the theoretical possibility of impact is never zero. A brute-force attempt can lock accounts. A crafted request can surface a fragile service. A lateral-movement step can touch a system nobody documented as brittle. Any vendor who tells you the probability of any disruption is flat zero is overselling, and that oversell is itself a warning sign.
The correct answer is that the risk is deliberately bounded. Mature red teaming manages production risk with a stack of named controls, and every one of them belongs in the ROE you are reviewing:
Stop conditions that halt testing the moment a defined threshold is crossed, for example an unexpected service degradation, and a safe word that any party can invoke to pause activity immediately.
Fragile-asset carve-outs, a named list of systems that are out of bounds for intrusive techniques because the business has flagged them as brittle, safety-critical, or revenue-critical.
Deconfliction with your SOC or MSSP so a spike in alerts can be confirmed as the exercise within minutes, and a genuine incident is never masked by it.
A named escalation tree so that when something looks wrong, the operator reaches a decision-maker on your side without hunting for a phone number.
Testing windows and tempo limits that keep the most intrusive activity away from your highest-load periods.
NIST SP 800-115 captures the baseline: rules of engagement should define who must be contacted in an emergency, such as a system crash, and testers must halt when a path crosses into third-party infrastructure. The regulator-driven frameworks go further and require a coordinating Control Team that steers the whole exercise. The takeaway for a buyer is simple. You are not choosing between "risk" and "no risk." You are checking whether the vendor's ROE contains the controls that turn an uncontrolled risk into a governed one. The rest of this post is how to check.
The buyer's ROE review checklist: twelve clauses to verify
For each clause below, you get two things: what a weak vendor ROE looks like, and what you should require. Read the vendor's document with this list beside you and mark each clause present, weak, or missing. A missing safety clause is a renegotiation trigger, not a rounding error.
1. Stop conditions and safe words
Stop conditions are the circuit breaker of the engagement. They define the specific, observable events that force testing to pause or halt: an unexpected outage, data corruption, evidence of a pre-existing compromise, or any impact on a system outside the agreed footprint. The safe word is the human override, a single agreed phrase that any authorized party, on either side, can use to freeze activity at once.
Weak vendor ROE: "The testing team will exercise care to avoid disruption." No defined triggers, no safe word, no time-to-halt commitment. Disruption becomes a judgment call the vendor makes alone, after the fact.
What to require: An enumerated list of stop conditions, a named safe word, and a committed maximum time from safe-word invocation to full stand-down. The ROE should state who on your side is empowered to invoke it and confirm that invoking it never counts as a breach of contract by you.
2. Escalation tree and points of contact
When something looks wrong at 2 a.m., nobody should be searching a shared drive for a phone number. The escalation tree lists who gets contacted, in what order, through which channel, and how fast, on both the vendor side and yours.
Weak vendor ROE: A single generic email address, or "contact the project lead." No out-of-hours path, no backup contact, no response-time expectation.
What to require: Named primary and secondary contacts on both sides, with roles, phone numbers, and a secure channel. A defined response-time expectation for urgent contact. This mirrors the regulator model: the ECB SSM Implementation Guide requires each significant institution to appoint a single point of contact for each test, precisely so escalation has a known destination.
3. Deconfliction with your SOC, MSSP, and live incidents
Deconfliction is the process of confirming, quickly and reliably, that a given piece of suspicious activity is the red team and not a genuine adversary, and vice versa. Without it, your blue team may burn hours chasing the exercise as if it were a breach, or worse, wave off a real intrusion because they assume it is the exercise.
Weak vendor ROE: Deconfliction is mentioned as a goal but has no mechanism. No shared indicators, no query process, no rule for what happens if a real incident is detected mid-test.
What to require: A written deconfliction procedure with a way for your team to query "is this you?" and get an authoritative answer fast. A rule that a confirmed real-world incident triggers an immediate pause so the exercise never shields an actual attacker. If you outsource detection, confirm the MSSP is accounted for in the process. For a deeper split of what the human red team owns versus automated coverage, see autonomous pentesting and production safety.
4. Authorization letter: contents and signatories
The authorization letter, sometimes called the "get out of jail free" letter, is the legal instrument that makes the engagement lawful. It is what separates authorized adversary simulation from a computer-misuse offense. NIST SP 800-115 frames written, time-bound authorization from an official with the authority to grant it as the foundational prerequisite for testing.
Weak vendor ROE: Authorization is implied by the signed statement of work, with no separate letter, no explicit scope, no expiry, and a signatory whose authority to approve intrusive testing of these systems is never established.
What to require: A standalone, dated authorization letter that names the systems and activities authorized, sets a start and end date, and is signed by someone with the actual authority to accept the risk, typically an executive officer or an authorized delegate, not a project manager. If third-party assets or subsidiaries are in scope, the signatory must have authority over those too, or a separate authorization must accompany them. The tester should carry a copy for the duration of the engagement.
5. Evidence handling and data protection
A red team will, by design, access data it should not be able to reach. How that evidence is captured, stored, transmitted, and destroyed is a data-protection question with real regulatory weight under regimes such as GDPR, PIPEDA, and sector rules.
Weak vendor ROE: Silence on evidence handling, or a line saying screenshots "may be taken." No encryption standard, no retention limit, no destruction commitment, no rule about exfiltrating real customer records.
What to require: A minimum-necessary rule for proving access without hoarding sensitive data, encryption for evidence at rest and in transit, a defined retention period, a destruction commitment with confirmation, and an explicit prohibition on removing real personal or regulated data from your environment where a redacted proof will do. This is also where you confirm the report itself will be handled as sensitive.
6. Leg-up and assumed-breach rules
Not every engagement should start from zero. Time-boxing the external phase, or starting from an assumed compromise, produces more findings per dollar for many buyers. The ROE must define exactly when and how the team gets a "leg up."
Weak vendor ROE: No mention of assumed breach, so either the whole budget burns on gaining initial access, or the team quietly grants itself access without a documented trigger and starting position.
What to require: A defined leg-up policy: the conditions under which the team moves to an assumed-breach starting point, the exact starting position granted (a standard user credential, a planted implant on a specified host), and who approves the transition. For the tradeoffs, see the assumed-breach engagement explained and how objectives shape scope in red team objectives and crown-jewels scoping.
7. Out-of-scope systems and the fragile-asset list
Scope has two edges. One is what the team may target. The other, more important for production safety, is what it may not. The fragile-asset list names systems that are explicitly off-limits to intrusive techniques because they are brittle, safety-critical, revenue-critical, or legally sensitive.
Weak vendor ROE: A one-line "production is in scope" with no exclusions, or an exclusions list the buyer is expected to write from scratch with no prompting.
What to require: An explicit out-of-scope list and a distinct fragile-asset list, with a process for adding to it during the engagement. The ROE should require the vendor to actively solicit fragile assets from you, not wait for you to guess. Legacy systems, medical or industrial control devices, and anything with a known stability problem belong here.
8. Testing windows and tempo
When intrusive activity happens matters as much as what it is. Testing windows keep the highest-impact techniques away from your busiest hours, and tempo limits prevent an aggressive burst from looking like a denial-of-service event.
Weak vendor ROE: "Testing may occur at any time," with no window and no tempo constraint. Convenient for the vendor, risky for your operations team.
What to require: Agreed windows for the most intrusive activity, a clear statement of what may run outside those windows (low-impact reconnaissance, for instance), and a rate limit or explicit ban on high-volume techniques against production. Realistic threat actors do operate around the clock, so the goal is a documented, agreed tempo, not an artificially narrow window that defeats the exercise.
9. Third-party and cloud-provider notification duties
Your systems increasingly sit on infrastructure you do not own. Cloud providers have acceptable-use and penetration-testing policies, and a hosted SaaS component may belong to a party who never agreed to be tested. NIST SP 800-115 is explicit that testers must halt when a path crosses into third-party infrastructure, because unauthorized access to a third party is a violation regardless of how the path was found.
Weak vendor ROE: No mention of cloud-provider policy or third-party boundaries, leaving the buyer exposed if the team wanders into a hosted dependency.
What to require: A clause that identifies which assets sit with third parties, assigns responsibility for any required provider notification or approval, and instructs the team to stop and deconflict the moment an attack path leaves your authorization boundary. Clarify who owns notifying a cloud provider when their policy requires it.
10. Liability, indemnity, and insurance
This is where legal counsel earns their seat at the table. If, despite every control, something does break, the ROE and the surrounding contract decide who carries the cost.
Weak vendor ROE: Unlimited liability pushed onto you, no professional indemnity insurance named, or a blanket vendor disclaimer for any and all impact regardless of negligence.
What to require: Evidence of professional indemnity and cyber-liability insurance at a level proportionate to your risk, a liability allocation that holds the vendor accountable for negligence while recognizing that authorized testing carries inherent risk, and a clear statement that the safeguards in the ROE (stop conditions, carve-outs, deconfliction) are contractual obligations, not best-effort courtesies. The companion post on autonomous pentest contract and SLA clauses covers the wider contract stack that sits around the ROE.
11. Deliverables, retest, and remediation support
An engagement that ends with a PDF and no path to fixing what it found is half an engagement. The ROE and statement of work should set expectations for what you receive and what happens next.
Weak vendor ROE: A report is promised with no format, no severity model, no evidence standard, and no retest. Findings land, and the relationship ends.
What to require: A defined deliverable, an attack narrative mapped to a recognized model so findings are comparable and defensible, a severity scheme, and a retest or remediation-validation option. Coverage claims are easier to judge when they map to a framework, as covered in grading MITRE ATT&CK coverage in a red team proposal. Because pentest and red team evidence supports your SOC 2, ISO 27001, PCI DSS, DORA, and NIS2 programs, confirm the deliverable is written to stand up in front of an auditor.
12. Regulatory and threat-model alignment
Regulated sectors need the ROE to map cleanly to the framework the entity answers to, and the adversary the team emulates should reflect a real threat to the business, not a generic template.
Weak vendor ROE: No reference to the regulatory regime you fall under, and a one-size adversary profile disconnected from your industry.
What to require: Explicit alignment with your regime, whether that is DORA TLPT in the EU, OSFI I-CRT in Canada, or the UK's CBEST and STAR-FS, and a threat profile chosen for your sector. See which threat group your red team should emulate by industry, and the framework explainers for DORA threat-led penetration testing and OSFI I-CRT intelligence-led red teaming in Canada.
Regulators now mandate these controls
The clauses above are not a wish list. Supervisors have written the same controls into binding frameworks, which is the strongest possible argument for demanding them.
DORA applied across the EU from 17 January 2025, requiring in-scope financial entities to run advanced resilience testing by means of threat-led penetration testing at least once every three years, per DORA Articles 26 and 27. On 11 February 2025, the ECB updated the TIBER-EU framework to align with DORA, and the headline change for a buyer is telling: the internal coordination group formerly called the "White Team" is now the "Control Team." Regulators named the safety-and-coordination function explicitly because it is central to controlled execution. The same update made purple-teaming mandatory, so the exercise ends in structured collaboration between attackers and defenders, not just a report thrown over a wall.
On 21 November 2025, the ECB issued its SSM Implementation Guide, setting out how the Single Supervisory Mechanism operationalizes TLPT for significant institutions under DORA Articles 26, 27, and 46. Among its procedural requirements: each significant institution must appoint a single point of contact per test to preserve secrecy and coordination. That is the escalation-and-contact clause from this checklist, written by a supervisor.
Canada reached the same place earlier. OSFI's I-CRT framework has, since 2023, asked systemically important banks and internationally active insurance groups to run intelligence-led red teaming at least once per three-year supervisory cycle, structured across an initiation phase, a threat-intelligence phase, red team execution, and a closure and remediation phase, with OSFI providing oversight throughout. The UK's CBEST and CREST STAR-FS regimes, run with the Bank of England, apply the same controlled, intelligence-led model to financial services. Across all of them the pattern is identical: a named coordinating team, a defined scope, controlled execution, and a structured close. If a vendor's ROE already satisfies this checklist, it already satisfies the shape of what these supervisors expect, which is exactly the position you want to be in when an examiner asks how your last test was governed.
Reviewer's quick reference
Use this as the one-page pass before signing. Each row is a clause; mark it present, weak, or missing.
Clause | Weak ROE | What to require |
|---|---|---|
Stop conditions and safe words | "Will exercise care." No triggers. | Enumerated triggers, named safe word, committed time to stand down. |
Escalation tree | One generic email. | Named primary and backup contacts both sides, phone, response-time expectation. |
Deconfliction | Mentioned, no mechanism. | Written "is this you?" procedure; real-incident pause rule; MSSP accounted for. |
Authorization letter | Implied by the SOW. | Standalone, dated, scoped letter signed by someone with authority to accept risk. |
Evidence and data handling | "Screenshots may be taken." | Minimum-necessary rule, encryption, retention limit, destruction, no real PII exfiltration. |
Leg-up and assumed breach | Undefined. | Documented trigger, exact starting position, named approver. |
Out-of-scope and fragile assets | "Production in scope," no exclusions. | Explicit exclusions plus a fragile-asset list the vendor actively solicits. |
Testing windows and tempo | "Any time." | Agreed windows for intrusive activity, tempo or rate limits. |
Third-party and cloud duties | No mention. | Named third-party boundaries, provider-notification owner, stop-at-boundary rule. |
Liability and insurance | Unlimited on the buyer. | Proportionate liability, named indemnity and cyber insurance, safeguards as obligations. |
Deliverables and retest | Report only. | Framework-mapped narrative, severity model, retest or remediation validation. |
Regulatory alignment | Generic. | Mapped to DORA, OSFI I-CRT, or CBEST, with a sector-relevant threat profile. |
What this means for buyers
A few practical moves turn this checklist into a better engagement.
Read the ROE before the price. The commercial terms tell you what it costs. The ROE tells you what could go wrong and who is responsible when it does. If a vendor cannot produce a detailed ROE on request, that is your answer. For budgeting context, see red team engagement cost in 2026.
Bring your fragile-asset list to the first scoping call. You know your brittle systems better than any tester will on day one. A vendor who welcomes that list and writes it into the ROE is thinking about your production safety, not just their access.
Treat vague reassurance as a red flag. "We never cause issues" is marketing. "Here are our stop conditions, our deconfliction procedure, and our insurance certificate" is a safety program. Prefer the second.
Make the human safety controls explicit, and understand where automation fits. Human-operated red teaming manages production risk through the judgment and escalation this checklist describes. Automated testing manages it differently, through engineered guardrails. Stingrai's autonomous web application agent, Snipe, is purpose-built to hunt complex, high-impact vulnerabilities such as IDOR, business-logic flaws, and broken authorization, and it runs under production-safe guardrails designed for continuous, non-disruptive web application testing. Red teaming, by contrast, is a human-operated discipline where the safeguards are contractual and procedural. Both models keep production safety front and center; they just encode it in different places. Learn more about web application penetration testing and the broader red teaming service.
Stingrai's red team operations run under exactly the controls in this checklist, which is why they map cleanly onto DORA TLPT and OSFI I-CRT engagements. If you are preparing for a first red team and want a partner whose rules of engagement already meet the supervisory bar, explore our services or review current packages and pricing.
Frequently asked questions
What should red team rules of engagement include?
At minimum, red team rules of engagement should include stop conditions and a safe word, an escalation tree with named contacts, a deconfliction process with your security operations team, a written and time-bound authorization letter signed by someone with legal authority, evidence and data-handling terms, leg-up or assumed-breach rules, out-of-scope and fragile-asset lists, testing windows and tempo limits, third-party and cloud-provider notification duties, and liability and insurance terms. These are the same controls regulators require under DORA's TIBER-EU model and OSFI I-CRT.
Can a red team disrupt our production systems?
In principle, yes, because red teaming runs real techniques against real infrastructure, so the possibility of impact is never exactly zero. In practice the risk is deliberately bounded by named safeguards in the rules of engagement: stop conditions, fragile-asset carve-outs, deconfliction with your SOC, testing windows, and a named escalation path. A vendor who promises zero risk is overselling; a vendor who shows you the controls that manage the risk is doing it right.
What is a red team authorization letter and who should sign it?
The authorization letter is the legal instrument that makes the engagement lawful, naming the systems and activities authorized and setting a start and end date. It should be signed by someone with the actual authority to accept the risk, typically an executive officer or an authorized delegate, not a project manager. If subsidiaries or third-party assets are in scope, the signatory must have authority over those too. NIST SP 800-115 frames this written, time-bound authorization as the prerequisite for any test.
What is deconfliction in a red team engagement?
Deconfliction is the process of quickly confirming whether a given piece of suspicious activity is the red team or a genuine adversary. It protects you twice: it stops your blue team from wasting hours treating the exercise as a real breach, and it stops a real breach from hiding behind the exercise. A strong ROE gives your team a way to ask "is this you?" and get an authoritative answer fast, plus a rule that a confirmed real incident pauses the test.
What are stop conditions in red team rules of engagement?
Stop conditions are the predefined events that force testing to pause or halt, such as an unexpected outage, data corruption, evidence of a pre-existing compromise, or impact on a system outside the agreed scope. They work alongside a safe word, a single agreed phrase any authorized party can invoke to freeze activity immediately. Together they are the engagement's circuit breaker and are central to keeping production safe.
Does a red team test production or a staging environment?
Serious red teaming tests the real environment, because the point is to assess the systems, people, and detection you actually run. Production risk is managed, not avoided, through the safeguards in this checklist. Fragile or safety-critical systems can be carved out for intrusive techniques via a fragile-asset list, and the most disruptive activity can be confined to agreed testing windows.
How is a red team ROE different from a pentest ROE?
A penetration test ROE tends to focus on a defined scope of assets and known vulnerability classes over a fixed window. A red team ROE adds the controls needed for stealthy, objective-driven, multi-vector adversary simulation: deconfliction so the exercise is not mistaken for a real attack, leg-up and assumed-breach rules, a Control Team or single point of contact, and a threat profile chosen to emulate a realistic adversary. The red team ROE is broader because the activity is broader.
How do regulators view red team rules of engagement?
Regulators have standardized them. The ECB's February 2025 TIBER-EU update renamed the coordinating group to the "Control Team" and made purple-teaming mandatory, and the November 2025 ECB SSM Implementation Guide operationalizes threat-led penetration testing under DORA with a required single point of contact per test. OSFI I-CRT applies the same controlled model in Canada. A vendor ROE that meets this checklist meets the shape of what these supervisors expect.
Is there a template for writing a red team ROE?
Yes. The community-maintained redteam.guide ROE template is the canonical author-side resource for practitioners drafting the document. This post is the reviewer-side mirror of that template: what a buyer should demand from whatever ROE a vendor presents.
References
European Central Bank. TIBER-EU Framework updated to align with DORA. 11 February 2025. https://www.ecb.europa.eu/press/intro/news/html/ecb.mipnews250211.en.html. Announces the framework update, the renaming of the "White Team" to the "Control Team," and mandatory purple-teaming, aligning TIBER-EU with the DORA regulatory technical standards on threat-led penetration testing.
European Central Bank, Banking Supervision. Guide on the implementation of the TIBER-EU framework by the SSM. 21 November 2025 (analysis by Norton Rose Fulbright, Regulation Tomorrow). https://www.regulationtomorrow.com/2025/11/cybersecurity-ecb-issues-tiber-eu-ssm-implementation-guide/. Sets out how the ECB operationalizes threat-led penetration testing for significant institutions under DORA Articles 26, 27, and 46, including the single-point-of-contact requirement per test.
Office of the Superintendent of Financial Institutions (OSFI). Intelligence-led Cyber Resilience Testing (I-CRT) Framework. 2023. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/osfis-intelligence-led-cyber-resilience-testing-crt-framework. Canada's framework for intelligence-led red teaming of systemically important banks and internationally active insurance groups, structured across initiation, threat intelligence, red team execution, and closure phases.
National Institute of Standards and Technology (NIST). SP 800-115: Technical Guide to Information Security Testing and Assessment. September 2008. https://csrc.nist.gov/pubs/sp/800/115/final. Sets out planning and authorization as prerequisites for testing, defines rules of engagement and emergency-contact procedures, and requires halting when a path crosses into third-party infrastructure.
redteam.guide. Rules of Engagement (ROE) Template. Community resource. https://redteam.guide/docs/Templates/roe_template/. The canonical practitioner-side template for authoring a red team ROE, covering provisions, authority, ground rules, points of contact, authorization, and appendices.
Bank of England. CBEST Threat Intelligence-Led Assessments Implementation Guide. https://www.bankofengland.co.uk/financial-stability/operational-resilience-of-the-financial-sector/cbest-threat-intelligence-led-assessments-implementation-guide. The UK regulator's framework for controlled, intelligence-led testing of financial-sector firms, applying the same coordinated, scoped model as TIBER-EU and OSFI I-CRT.
