Scoping a Red Team: Objectives and Rules of Engagement
The objective decides whether the exercise is worth anything, and the rules decide whether it is survivable. What to write down before anyone starts.
Two documents decide whether a red team is worth buying. The objective decides whether the result means anything; the rules of engagement decide whether the exercise is survivable for everyone involved.
Writing an objective that means something
An objective is specific, singular, and unambiguous in outcome. Someone should be able to say afterwards whether it was achieved without an argument.
Good: obtain a copy of the customer database. Execute a transaction in the payment system. Reach the cardholder environment from outside it. Gain domain administrator.
Not objectives: "assess our security posture", "test our defences", "see how far you get". These are requests for a penetration test with a more expensive name, and they produce reports nobody can act on because nothing was being proven.
The test of a good objective is whether its achievement would alarm a board. If reaching it would prompt a shrug, the exercise will too.
One objective, or a short ranked list. A dozen is a wish list, and a team chasing all of them does none of them properly. Say what happens if the first falls in week two: stop, or move to the second under the same rules. Draft it with whoever would have to explain the incident in public. It is also the largest single lever on price, covered in what a red team engagement costs.
The rules of engagement
Everything the team may and may not do, written down before anyone starts.
What is in scope
Which entities, which countries, which subsidiaries. Groups with shared services get this wrong most often: a route through a subsidiary is realistic and may be outside the authorisation you actually hold.
Which techniques are permitted
Phishing, physical entry, telephone pretexting, exploitation of exposed services, supplier routes. Each is a decision. Anything affecting availability is normally excluded outright, and destructive actions always are. A team proving database access retrieves a row, not the table.
What is untouchable
Name the systems that must not be interfered with under any circumstances: safety systems, clinical systems, trading platforms during market hours, anything where a mistake is measured in something other than money.
When the team may work
Working hours, out of hours, or both. An intrusion prefers the hours when nobody is watching, so an exercise confined to weekdays from ten to six tests the shift a real attacker avoids. Then name the excluded dates: year-end close on 31 March, results season, a migration weekend, a festival week when half the floor is on leave. Blackout dates belong in the document, not in an email sent the week before.
Trusted agents
The two or three people who know. Their job is to hold the authorisation, answer the phone at any hour, and stop the exercise if it needs stopping. Choose people who will actually be reachable. A trusted agent on holiday is the same as no trusted agent.
Stop conditions
What ends the engagement early. The objective achieved. A real incident occurring in parallel. State that one explicitly: a genuine intrusion during a red team is confusing in exactly the wrong moment. Anything affecting customers. A team member detained.
Deconfliction
How the trusted agents establish, quickly, whether something odd is the red team or an actual attacker. Usually a phone number and a code word. Without it, your incident response spends a night on an exercise you paid for, or worse, dismisses a real intrusion as the exercise.
If you are regulated, that call runs against a clock. An entity under the RBI's 2026 Directions reports cyber incidents on the DAKSH platform within six hours of detection (¶182), and your own analysts, who have not been told, can reach the point of raising one over activity you commissioned. Name who decides whether an event is a real incident, and confirm that person can reach a trusted agent inside that window at any hour.
Evidence, and the data the team reaches
Proving the objective means holding something that proves it, and in a bank or a hospital that is real people's records. Agree in advance how little is taken, where it is held, who at the provider can see it, and when it is destroyed. The same clause covers what the team leaves behind: persistence comes out against a written list, item by item, and you check it off.
When the route leaves the scope
It will. A credential found in a permitted system opens a subsidiary nobody listed. The rules should say what happens at that moment: stop at the boundary, record it, ask. A scope extension is a document, and it names the new signatory where those systems belong to someone else. Widening scope on verbal approval puts both sides outside their authorisation at the point the exercise became interesting.
The authorisation itself
A signed document naming the systems, the dates, the permitted techniques and the signatory, held by both sides before work starts. Where physical entry is in scope, each tester carries a copy along with a name and number that will be answered at three in the morning.
Where any system is not yours, whether a supplier, a shared building or a hosted platform, their permission is separate and also needs to exist in writing. Being their customer does not authorise testing them.
| What you want to touch | Whose written permission | The mistake |
|---|---|---|
| A subsidiary or group company | That entity's own signatory | A holding company's letter does not cover a separate legal entity. |
| Colocated or hosted infrastructure | The provider, under your contract's testing terms | Assuming the rack is yours because the servers are. |
| A SaaS platform you run the business on | The vendor, under its testing policy | The credentials are yours. The platform is not. |
| An MSP's engineers and their access into you | The MSP | Privileged access, sitting outside your HR. |
| Shared floors, lifts and common areas | The landlord or building operator | Your lease ends at your door. See physical penetration testing. |
Control is not authorisation. The signature comes from whoever can lawfully consent for the thing being tested.
The scope is the document a third party reads
Months later an auditor, a supervisor or a customer's questionnaire asks what the exercise covered. The scope document is the answer. Assurance is given for the areas assessed and is explicit about each one (RBI ¶157), so a system dropped from scope gains nothing from the exercise however well it went.
The credentials and competency of the testing firm and its assigned personnel are established at selection, appointment, engagement and renewal (¶156), so the names doing the work are part of the record. Where a group holds a SEBI-regulated arm, CSCRF applies to the regulated activity, and Equivalence lets you avoid repeating an exercise another regulator's framework already covers, on a mapping shown control by control. Boundaries drawn along the entities make that mapping possible.
Red teaming itself is permissive under the 2026 Directions, set out in red teaming under the RBI Directions. Where the report goes to a regulator, engage a CERT-In empanelled auditor; we have held that empanelment continuously since 2008.
The scope that cannot fail, and is therefore worth nothing
The common failure is not a scope that is too aggressive. It is one negotiated down, clause by clause, until no realistic route survives. Phishing comes out because there is a separate phishing programme. The MSP comes out because the contract is awkward. The subsidiary comes out because its managing director was not in the meeting. Each exclusion is defensible alone, and together they leave a team with the public perimeter and a fortnight.
Where an exclusion is unavoidable, write down what it costs: we are not testing the route an attacker is most likely to use, and this exercise will not tell us whether it works. That sentence is more use to a board than the report.
Deciding the aftermath before the start
Who owns the fixes. A red team finding is a chain, and the links sit with identity, the platform team, the service desk, a supplier. Name an owner for the chain, or each link closes while the chain stays open.
Whether there is a retest, and of what. Re-running the whole exercise in the same quarter proves little. Re-running the chain proves the fix.
How the people who were tested are told. Agree the internal disclosure in advance, framed around the control and not the individual. See social engineering assessments and the consent they require for what naming people does to your reporting rate.
The scoping question to ask yourself
Before writing any of it: what would we do differently depending on the result?
If the honest answer is "nothing, but we need the report", buy the cheaper exercise. If it is "we would rebuild our detection", buy a purple team first and the red team afterwards, in that order.
And if you cannot name a trusted agent who will answer at three in the morning, or legal will not sign the authorisation, you are not ready to scope one at all. Fix that first.
About the author
Siddarth G
Practice Director — Cybersecurity
Leads Security Brigade's offensive security practice with deep expertise in vulnerability research, penetration testing, and red team operations. Ranked Top 80 globally on Bugcrowd.
Continue reading
All articles →Choosing a Red Team Provider
Every firm answers yes to every capability question. Six questions where the generic yes runs out, and what a real answer sounds like.
Red Teaming and SEBI CSCRF
What the Cyber Security and Cyber Resilience Framework asks of regulated entities, where adversarial testing sits within it, and how the tiering decides how much applies to you.
Social Engineering Assessments and the Consent They Require
Testing people is not testing systems. What can be assessed, what must be agreed first, and why individual results should almost never leave the room.