A full-scope red team engagement at a mid-size organization typically runs four to eight weeks end to end, across five phases: scoping and rules of engagement, reconnaissance, initial access, internal operations toward an objective, and reporting with a debrief. It is priced either as a fixed bid against a defined objective or as a weekly rate.
A penetration test asks what can be exploited. A red team asks whether your people, process and technology detect and stop an adversary working toward a specific goal. That difference changes how you plan the engagement, how long it runs and how you should pay for it. This guide covers all three, with a timeline table, a rules of engagement checklist and a comparison of pricing models.
How long does a full-scope red team take, and what are the typical phases?
Most full-scope red team engagements for a mid-size organization take four to eight weeks. Planning and reporting each take about as long as the attack itself, so budget calendar time for both. After scoping, the red team works without contact with your organization until the debrief, apart from an emergency stop.
| Phase | Typical duration | What happens | Your team’s involvement |
| 1. Scoping and rules of engagement | 1–2 weeks | Objective and scenarios agreed, rules of engagement signed, trusted agents and emergency contacts named, safety controls set | Executive sponsor, legal, trusted agent |
| 2. Reconnaissance and preparation | ½–1 week | Open-source intelligence, attack surface mapping, pretext design, attack infrastructure stood up | None (emergency contact only) |
| 3. Initial access | ½–1½ weeks | Phishing, credential attacks or external exposure used to gain a foothold | None (emergency contact only) |
| 4. Internal operations | 1–2 weeks | Privilege escalation, lateral movement, persistence, objective pursuit, simulated exfiltration | None (emergency contact only) |
| 5. Reporting, debrief and replay | 1–1½ weeks | Attack narrative, timeline, detection gaps, executive debrief, optional purple team replay | Security team, leadership |
| Total | 4–8 weeks |
How does the timeline change by engagement type?
Scope moves the timeline more than anything else. Other providers publish similar bands, which helps when you compare proposals.
| Engagement type | Typical duration |
| Focused or assumed-breach (one business unit, limited objectives) | 2–4 weeks |
| Full-scope, mid-size organization | 4–8 weeks |
| Multi-site, OT or complex hybrid estates | 6–12+ weeks |
| Regulated threat-led testing (DORA TLPT under TIBER-EU) | 9–14 months including procurement and attestation |
The other factors that stretch a timeline: social engineering in scope, more than one objective, a stealthier tempo, a mature blue team that forces the red team to slow down, and slow internal approvals during scoping.
Phase 1: Scoping and rules of engagement
This is where most engagements succeed or fail. You agree one primary objective, the scenarios that will pursue it, what is off-limits, who knows the test is running and how to stop it. This is the last planned interaction with the red team until the debrief, so settle every question here. Exit criterion: a signed rules of engagement document and an authorization letter from someone with authority over in-scope systems.
Phase 2: Reconnaissance and preparation
The red team studies your organization the way an attacker would: public employee data, exposed services, cloud footprint, email security posture and third-party relationships. It also builds the infrastructure it needs, such as domains and command-and-control servers. Exit criterion: an internal attack plan mapped to the approved scenarios. From here until the debrief, the red team operates without contact with your organization unless an emergency stop is called.
Phase 3: Initial access
Operators attempt a foothold through the routes the rules of engagement allow, such as targeted phishing, credential attacks or an exploitable external service. Real attackers do not always get in on day one, and a realistic test should not assume they will. Exit criterion: a foothold, or a documented set of blocked attempts that becomes a finding in its own right.
Phase 4: Internal operations and objective pursuit
From the foothold, the team escalates privileges, moves laterally and works toward the objective while trying to stay undetected. Proof of access uses screenshots, metadata or pre-seeded canary data, never real customer records. Every action is logged with a timestamp so detections can be matched to activity later. Exit criterion: objective reached, objective blocked, or time box expired.
Phase 5: Reporting, debrief and replay
The report tells the story of the attack: what was attempted, what was detected, what was missed and how long your team took to respond. Findings are mapped to MITRE ATT&CK techniques so detection engineers can act on them. Many organizations follow with a Purple Team Exercise that replays the attack path alongside defenders. Exit criterion: remediation owners assigned. Red team engagements do not include a retest; a follow-up purple team exercise or your next engagement is where improvements get validated.
How do you plan a red team engagement for a mid-size company without derailing operations?
Plan around one objective, a small white cell and written production guardrails. Disruption usually traces back to vague scope or a missing stop procedure, not to the testing itself.
- Write the objective in one sentence. For example: “Can an external attacker reach the finance file share without the SOC escalating?” If you cannot write it in one sentence, scoping will sprawl.
- Confirm you are ready to be measured. A red team measures detection and response. If you do not have a mature SOC, MDR provider or alert triage process yet, start with an internal network penetration test or a purple team exercise instead.
- Keep the white cell small. Name an executive sponsor, one or two trusted agents and a legal contact. Trusted agents should be senior enough to make fast calls but outside the SOC being tested.
- Put production guardrails in writing. Ban denial-of-service and destructive actions, list fragile systems as off-limits, and use canary data for any exfiltration proof.
- Schedule around the business calendar. Avoid quarter-close, major releases, audits and change freezes. The trusted agent can check the change calendar without tipping off the wider team.
- Agree deconfliction before day one. Decide how the SOC escalates suspicious activity, who answers, and whether the trusted agent lets incident response run as a live exercise. The emergency contact channel is the only line open during testing, so agree up front when it may be used.
- Protect employees. Agree with HR that social engineering results are reported in aggregate, not by name, and that no one is disciplined for being phished during the test. Exclude anyone who should not be targeted.
- Book the debrief and name remediation owners up front. Value comes from what changes afterward. Put the readout on calendars before testing starts, because you will not hear from the red team between scoping and the debrief.
What should a red team rules of engagement checklist include?
Rules of engagement turn a simulated attack into an authorized, controlled exercise. Use this checklist when you review a provider’s draft.
Authorization
- Authorization letter signed by an officer with authority over every in-scope system and legal entity
- Named testing firm and operators, engagement dates and authorized activity categories
- Cloud and SaaS provider testing policies reviewed; third-party systems excluded or separately authorized
Objective and scope
- Primary objective and success criteria (objective reached, detected, or both)
- In-scope networks, domains, cloud accounts, applications and employee groups
- Explicit out-of-scope list: fragile production systems, safety-critical systems, third parties, named individuals
Techniques
- Authorized techniques by category: phishing, vishing, wireless, external exploitation, cloud and identity attacks
- Prohibited techniques: denial of service, destructive actions, real data exfiltration, actions that could harm reputation
- Actions needing separate approval before use, such as creating accounts or touching production databases
Communication and deconfliction
- Trusted agents and emergency contacts named, reachable during active operations
- Confirmation that the red team will not contact your organization between scoping and the debrief, except for an emergency stop
- Deconfliction protocol for SOC escalations, including how to handle a real incident during the test
- Emergency stop: who can call it, how, and what operators do immediately
- Timestamped operator activity log
Data handling and close-out
- Storage and encryption rules for any sensitive data encountered
- Destruction of engagement data within an agreed number of days after report delivery, with written confirmation
- Removal of implants, accounts and infrastructure after testing
- Report format, distribution list, classification and debrief date
Red team pricing: should you pay per week or fixed bid?
For a mid-size organization with a clear objective, a fixed bid usually gives better budget certainty and ties the provider to an outcome. A weekly rate fits open-ended work, such as continuous or exploratory engagements where scope is expected to shift.
| Pricing model | How it works | Best when | Risk to the buyer | ROI watch-out |
| Fixed bid | One price for an agreed objective, scope and time box | Objective and scope are clear | Scope changes need a change order | Check what happens if the objective is reached early or not at all |
| Per week (time and materials) | Weekly rate multiplied by weeks used | Scope is exploratory or expected to change | Cost grows if the engagement drifts | Insist on a cap tied to the objective |
| Retainer or continuous | Recurring fee for periodic campaigns | Mature SOC wanting repeated testing over a year | Paying for capacity you may not use | Tie each campaign to a measurable detection goal |
| Hybrid | Fixed core engagement plus optional weekly extensions | You want certainty but expect follow-on testing | Extensions creep without approval gates | Pre-agree extension triggers and rates |
What drives red team cost?
Red team work is priced on senior tester time, so anything that adds days adds cost.
- Scope breadth: more environments, business units and attack paths
- Duration: a slower, stealthier tempo means more billed days
- Scenario count: each scenario needs its own planning and execution
- Threat-intelligence depth: bespoke adversary research adds a phase
- Objective depth: a single flag costs less than a full attack-path rehearsal with replay
- Social engineering: phishing and vishing campaigns need their own pretexts, planning and legal guardrails
How does Canary Trap scope red team pricing?
We scope every Red Team Exercise against the objective you need to prove on a short scoping call, then quote against that scope. We do not compete on the lowest day rate. We price against the evidence you need: detection and response performance your board, customers, insurers or auditors can rely on.
How do you measure whether a red team engagement was worth it?
Measure detection and response, not just whether the red team got in. Useful measures include:
- Whether the objective was reached, and how far along the attack path the team got
- Time from first malicious action to first alert, and from alert to escalation
- Share of ATT&CK techniques used that were prevented, alerted on or missed
- Which detections fired as designed and which stayed silent
- Remediation progress your team tracks after the debrief, validated later through a purple team exercise or the next engagement
These results also support compliance conversations. A red team does not replace the penetration testing that PCI DSS Requirement 11.4 calls for. Its evidence of detection and response does support SOC 2 monitoring criteria (CC7) and ISO 27001 incident management and monitoring controls.
Frequently asked questions
What does a red team exercise look like week by week at a mid-size company?
In a six-week engagement, week 1 is scoping and rules of engagement, week 2 is reconnaissance and preparation, weeks 3 and 4 cover initial access and internal operations, and weeks 5 and 6 cover reporting, the debrief and an optional replay. Between week 1 and the debrief, you will not hear from the red team unless an emergency stop is called. Shorter engagements compress reconnaissance and internal operations.
Should our SOC know a red team is running?
Usually not. Only the white cell knows, so you measure how the SOC detects and responds under normal conditions. A trusted agent handles escalations through the agreed deconfliction protocol.
What should a red team engagement include?
At minimum: an agreed objective, initial access, privilege escalation, lateral movement, simulated exfiltration using canary data, defensive measurement and a debrief. Social engineering and a purple team replay are common additions.
Do red team engagements include retesting?
No. A red team measures detection and response at a point in time, so there is no retest phase. Validate your fixes with a follow-up purple team exercise or your next engagement.
Is physical security testing part of a red team engagement?
No. Physical security testing is scoped and run as a separate engagement, a physical security assessment, with its own rules of engagement.
How long does it take to agree on rules of engagement?
Typically one week, inside the scoping phase. Lead time grows when several legal entities or cloud providers need separate authorization.
Red team retainer or annual one-off: which makes more sense?
A one-off engagement suits organizations testing detection for the first time or validating a major change. A retainer suits mature SOCs that want repeated campaigns and measurable improvement between them.
Red team, penetration test or purple team: which should we buy first?
Buy a penetration test first if you have not fixed known exploitable weaknesses. Choose a purple team exercise if you want to build detections collaboratively. Choose a red team when you have mature monitoring and response in place and want to know whether they work under realistic pressure.
How often should we run a red team?
A common cadence for mature programs is once a year, with penetration tests in between. Regulated EU financial entities subject to DORA threat-led testing must run it at least every three years.
Plan your Red Team Exercise
Tell us what you need to prove, and we will scope a Red Team Exercise around that objective, with rules of engagement your operations team can live with. Book a scoping call.
