How to Prepare Your Organization for a Red Team Exercise

A red team exercise is not a pentest with a different label. It’s a fundamentally different engagement with different objectives, different rules, and different stakeholders — and the organisations that treat it like a scaled-up pentest end up with a disappointing readout and a SOC that feels blindsided. If your board has asked for a red team, this is what you should be preparing for.

We run these ops most often for Indian banks, large enterprises, and critical-infrastructure clients. The prep work below is what separates a red team that actually teaches you something from one that’s just an expensive theatre piece.

Red team vs. pentest vs. purple team

A pentest finds bugs. Scope is a set of IPs, URLs, or apps; the deliverable is a list of findings with severity and remediation. The blue team knows it’s happening. The tester is trying to be comprehensive, not stealthy.

A red team tests your ability to detect and respond. Scope is an objective — “read the CEO’s inbox”, “exfiltrate the customer database”, “reach the core banking system” — not a list of hosts. Stealth is part of the engagement. The blue team usually doesn’t know. The deliverable is a narrative of what the red team did, which controls caught them, which didn’t, and how you’d harden against the same adversary next time.

A purple team is cooperative. Red and blue work together in real time, detonating specific TTPs and watching the telemetry to see what fires and what doesn’t. Purple teams are the best way to measure detection coverage quickly; they don’t measure end-to-end adversary simulation.

Rough rule of thumb: if you’ve never had a proper pentest, don’t jump to a red team. You’ll spend money learning lessons a pentest would have taught you at half the cost. Red team is for organisations that already have a functional security programme and want to know how it performs under real pressure.

The scoping workshop

Scoping a red team is about agreeing on objectives, not targets. The conversation should revolve around “what would hurt us most” and “what do we want to know”.

Typical objectives we’ve scoped: access to the SWIFT terminal, read access to a specific executive’s mailbox, ability to initiate a funds transfer above a threshold, exfiltration of source code for a flagship product, domain admin on the production AD forest, access to the HSM that signs OTA firmware updates. Notice these are business outcomes, not technical checkpoints.

Once you have objectives, define the “win condition” for each. What proof does the red team need to produce? A screenshot? A file hash? A timestamped export? Be specific — “we exfiltrated customer data” is meaningless; “we copied 1000 rows from the customers table to our C2″ is measurable.

Agree on starting assumptions too. Assumed-breach (“we’ll give you a standard corporate laptop and let you start from inside”) versus full external (“you start with our public domain and nothing else”) changes the engagement dramatically. For a four-week op, we usually recommend assumed-breach for Week 2 onwards — most organisations’ external perimeter is hard enough that a pure external op can burn three of your four weeks before the interesting work begins.

Rules of engagement

The RoE document is what keeps everyone out of trouble. It’s also what determines how realistic the exercise can be. A useful RoE covers:

RULES OF ENGAGEMENT — CONFIDENTIAL

1. PARTIES
   Client:       [legal entity, address, signatory]
   Red team:     ZynoSec Offensive Security, Pune
   Effective:    [start date] to [end date]

2. OBJECTIVES
   - Primary:   [business outcome 1]
   - Secondary: [business outcome 2]

3. SCOPE
   In-scope:    All assets owned by [entity], including subsidiaries
                listed in Annex A. Cloud tenants under account IDs
                listed in Annex B.
   Out-of-scope: Third-party SaaS providers except as listed in
                Annex C. Production payment rails. DR site.

4. PERMITTED TECHNIQUES
   - Phishing (with pre-approved pretexts from Annex D)
   - Physical access attempts to HQ (weekdays only, business hours)
   - Exploitation of vulnerabilities discovered during engagement
   - Lateral movement within client-owned infrastructure
   - Data staging (no exfiltration outside client network)

5. PROHIBITED
   - Destructive actions (data deletion, DoS, ransomware-like)
   - Access to regulated data beyond proof-of-reach
   - Techniques that bypass safety on production OT/ICS
   - Social engineering of employees outside the approved list

6. COMMUNICATIONS
   Trusted Agent Group (TAG): [3-5 named individuals]
   Emergency contact (24x7): [phone, signal, backup]
   Check-in cadence: daily, encrypted channel

7. EMERGENCY STOP
   Any TAG member may halt the operation by uttering the safeword:
   "[agreed phrase]" via the emergency channel. Red team ceases
   all activity within 30 minutes and preserves evidence.

8. DELIVERABLES
   - Weekly status brief to TAG
   - Final report within 10 business days of conclusion
   - Readout presentation to executive team and blue team

9. LEGAL
   - Authorisation to test executed per signed MSA dated [...]
   - Get Out Of Jail Free letter provided to red team lead
   - All artefacts destroyed 90 days post-engagement

The “Get Out Of Jail Free” letter is a signed authorisation the red team carries. If they’re caught in your office at 2am, it’s what keeps them out of a police station.

Who knows, who doesn’t

This is the part every first-time red team client gets wrong. The entire point of the exercise is measuring detection and response, which means your SOC and IT helpdesk cannot know. If they know, they’ll behave differently, and you’ll learn nothing about your real posture.

Our standard recommendation for who’s in the Trusted Agent Group:

• CEO or equivalent (they authorise the exercise and accept the risk)
• CISO (operational lead)
• Head of Legal or General Counsel (signs RoE, handles anything that escalates)
• One trusted senior in IT infrastructure (so if the red team accidentally knocks over a DC, someone with keys can recover quietly)
• One board-level contact, optional, for very high-stakes ops

Who does not know: the SOC, the CSIRT, the broader IT team, HR, the helpdesk, and every employee you’re planning to phish. Telling them ruins the test.

Plan communications carefully. If the SOC detects the red team and escalates to a crisis bridge, a TAG member needs to quietly deflect — usually with a phrase like “this is under investigation, hold the escalation pending my direct update”. Don’t lie to responders; redirect them. Brief your TAG on exactly how to handle the call before Week 1 starts.

Week-by-week: a typical 4-week op

Week 1 — Reconnaissance. Passive and active info gathering. Domain mapping, employee enumeration via LinkedIn, subdomain discovery, initial attack-surface scoping. Light phishing pretext development. No detection-worthy actions on your infra yet. Trusted Agent gets a daily summary. Your SOC sees nothing unusual.

Week 2 — Initial access. The phishing goes out. Maybe a physical drop, if in scope. The goal is one foothold — typically a user-level compromise on a corporate laptop. Tradecraft matters here because this is usually where the blue team has the best chance of catching the op. If your SOC catches and contains every initial-access attempt, that’s a win you get to celebrate; if not, the op proceeds.

Week 3 — Lateral movement and objective. From the foothold, the red team pivots. Internal recon, credential harvesting, privilege escalation, lateral movement. Heavy use of LotL techniques to stay under the EDR radar. The goal this week is to reach the win condition defined in scoping. Expect a lot of “how did nobody see this?” moments when you read the report.

Week 4 — Objective confirmation and reporting. The red team captures proof of reach, backs out cleanly, and starts writing. Evidence packages, detection opportunities per phase, and specific recommendations. The report includes both what happened and what would have stopped them.

Your readout day is the payoff. The red team walks the executive team, the blue team, and your TAG through a chronological narrative of the op. For the blue team this is often the first time they see what they missed; the mood shifts from defensive to constructive once people move past the initial surprise. Leave two hours. Don’t cut it short.

After the readout

The report isn’t the end; it’s the start. Every detection gap identified should become a specific blue-team improvement — a new Sigma rule, a new alerting threshold, a hardening change. Track them. Red team again in 12–18 months with a different objective and measure improvement.

Red teams are expensive because they’re slow, bespoke, and done by senior people. If your programme is mature enough to benefit from one, the investment returns clearly. If it isn’t, start with a proper pentest and get there. Either way, prepare properly — most of the value in a red team comes from how seriously you take the prep work above.