Choose a red team for the quality of the question it helps you answer. A credible engagement begins with a business objective, threat model, rules of engagement and safety design; it ends with a defensible attack narrative, detection evidence and a prioritized improvement plan. If the proposal is only a larger penetration test with stealth language, it will not tell leadership whether people, process and technology can detect and stop a determined attacker.
When to buy a red team — and when not to
A red team is appropriate when
- You have a functioning security baseline and want to test an end-to-end objective
- The SOC and incident responders need a realistic detection-and-response exercise
- Leadership needs evidence of resilience against a defined threat scenario
- The organisation can support a white cell, safety decisions and controlled uncertainty
Start elsewhere when
- Known critical vulnerabilities remain unaddressed across the target estate
- Basic logging, endpoint telemetry or escalation coverage is not operating
- The real need is a compliance VAPT or a focused application penetration test
- The organisation cannot authorize realistic techniques or respond safely to them
A penetration test asks whether a defined system can be compromised. A red team operation asks whether an adversary can achieve a business objective across people, process and technology without being stopped. A purple-team engagement makes the collaboration explicit so each technique becomes a detection improvement. Choose the format before comparing providers.
Red team provider scorecard
| Criterion | Weight | Evidence to request |
|---|---|---|
| Objective and threat design | 20% | A sample objective tree and threat-informed campaign plan |
| Operator depth | 20% | Assigned roles and relevant experience across identity, endpoint, cloud and social paths |
| Safety and governance | 20% | Rules of engagement, white-cell model, deconfliction and stop procedures |
| Adversary realism | 15% | Technique selection linked to a threat model, not a generic attack checklist |
| Detection evidence | 10% | Method for reconciling operator actions with SOC telemetry and response |
| Reporting and transfer | 10% | Attack narrative, control gaps, ATT&CK mapping and purple-team backlog |
| Operational security | 5% | Infrastructure isolation, evidence protection and teardown process |
What a strong engagement design contains
- One to three measurable objectives tied to business assets, such as accessing a defined data set or obtaining a named control-plane role.
- A threat model identifying relevant adversary behaviours, likely initial-access paths and techniques that are out of scope.
- A white cell with authority to approve exceptions, distinguish the exercise from a real incident and stop unsafe activity.
- Rules for social engineering, persistence, credential access, payloads, cloud actions, data simulation and third-party systems.
- A deconfliction channel that preserves realism without allowing the exercise to collide with a genuine incident.
- A plan to reconcile operator timestamps and actions against what endpoint, identity, network, cloud and SOC controls observed.
Questions for the proposed operators
- How would you translate our threat model and crown jewels into objectives and decision points?
- Which parts of the campaign require specialist operators, and who fills those roles on our engagement?
- How do you prevent a payload, persistence mechanism or cloud action from causing uncontrolled impact?
- How do you adapt when an initial-access route is blocked without turning the exercise into a checklist?
- How are real credentials, collected data, operator infrastructure and test artifacts protected and destroyed?
- How do you distinguish a control that prevented an action from one that merely failed to log it?
- What does the blue team receive after the campaign to build and validate detections?
The evidence package leadership and defenders need
| Deliverable | Decision it supports |
|---|---|
| Executive objective assessment | Were crown jewels reached, which barriers worked and what risk remains? |
| Attack narrative | How did initial access, execution, privilege, movement and objective achievement connect? |
| Operator timeline | What happened when, and which evidence supports each material action? |
| Detection reconciliation | Which behaviours were prevented, detected, investigated, missed or misclassified? |
| ATT&CK coverage map | Which techniques matter to the scenario and where are the visibility or control gaps? |
| Purple-team backlog | Which detections, controls, playbooks and retests should be prioritized? |
| Artifact teardown record | Were accounts, infrastructure, payloads, persistence and evidence removed? |
Red flags in red team proposals
- No business objective beyond finding vulnerabilities or achieving domain administrator access.
- A fixed technique list copied into every proposal without a threat model or control assumptions.
- Sales credentials presented instead of the assigned operator roles and availability.
- No white-cell design, stop condition, deconfliction method or protection for collected data.
- A promise to bypass every security product or remain completely undetected.
- A final deliverable that ends with vulnerabilities and does not reconcile detection and response performance.
How to run a fair technical evaluation
- Give each provider the same business objectives, threat context, environment boundaries and non-negotiable safety constraints.
- Ask for a short campaign design rather than a generic capabilities deck, then score it before the presentation.
- Interview at least one proposed operator and the engagement lead who will own safety and reporting.
- Review an anonymised attack narrative and detection-reconciliation example from a comparable type of engagement.
- Contract the objective, safety model, evidence package, purple-team transfer and teardown obligations explicitly.
Define the objective before the techniques
Review how a goal-based red team is scoped, governed, executed and converted into a detection-improvement backlog.