Organisations buy a red team engagement expecting to learn whether their detection and response would stop a real attacker, then receive what is really a broad penetration test with a dramatic narrative and no measurable change to their defences. A red team engagement is objective led: testers emulate a named threat, using intelligence about how that threat operates, to reach agreed objectives while the defending team works as normal. Buying one well means defining objectives, the threat intelligence behind them, the rules of engagement and the outputs before you compare providers. This vendor-neutral guide covers scoping, threat intelligence led testing, rules of engagement, purple team outputs, regulatory schemes such as TIBER-EU, CBEST and DORA threat-led penetration testing (TLPT), pricing and contract terms. It is for CISOs, security operations leads and procurement teams. Vulnerability focused testing is covered in the Penetration Testing Provider Buyer's Guide, and the discipline itself in the Red Teaming Guide.
Key takeaways
- Buy against objectives, not targets. A red team scope names what an attacker would want (payment release, customer data, domain control of a critical service) and lets the team find its own path, within agreed limits.
- Threat intelligence should drive the scenarios. Regulated schemes separate the threat intelligence provider from the testers; even outside them, ask how each scenario is grounded in threats relevant to you.
- The control team is your job. A small group that knows about the test manages risk, approves escalations and keeps the secret. The provider cannot do this for you.
- Value comes after the attack. Replay, purple teaming and a remediation plan with owners are where detection improves. Price and plan them from the start.
- Regulatory schemes set the bar. Where TIBER-EU, CBEST or DORA TLPT applies, provider accreditation, phases and reports are prescribed, so check the scheme rules before any commercial discussion.
Define requirements
- Why now: regulatory requirement, a board question about resilience, a new security operations capability to validate, or follow-up after an incident. The answer decides whether you need a scheme compliant test or a bespoke one.
- Regulatory scheme: DORA Article 26 requires TLPT at least every three years for financial entities identified by their authority, with the method in Delegated Regulation (EU) 2025/1190. TIBER-EU was updated in 2024 to align with the DORA TLPT standards. CBEST is run jointly by the Bank of England, the Prudential Regulation Authority and the FCA. See the Threat-Led Penetration Testing Guide for the scheme detail.
- Objectives and critical functions: the business services and systems that support them, and the outcome the red team should try to achieve against each.
- Attack paths in scope: external compromise, phishing and social engineering, physical access, supply chain or trusted third party, insider assumption (an assumed breach starting point), cloud and identity provider attacks.
- Constraints: production systems that must not be touched, safety critical or fragile systems, legal limits on social engineering of staff, data that must not be exfiltrated even as proof, and testing windows.
- Your defensive set-up: in-house security operations, a managed detection provider, or both. Third parties who monitor you must be considered in the rules of engagement and, for some, in the control team.
Capability areas
| Capability | What it involves | Why it matters |
|---|---|---|
| Threat intelligence | Targeted threat landscape, reconnaissance of your external footprint, scenarios tied to relevant threat actors and their techniques | Without it the test reflects the testers' favourite techniques, not your threats. TIBER-EU and CBEST both use a separate threat intelligence provider |
| Scenario design and test plan | Scenarios, flags or objectives, assumed breach starting points, leg-ups agreed in advance | Keeps the test realistic and measurable within time and budget |
| Operational tradecraft | Initial access, persistence, lateral movement and objective actions conducted safely and with full logging | Tests detection at each stage, not only the perimeter |
| Risk management | Stop conditions, escalation to the control team, deconfliction if the blue team responds, safe handling of any data accessed | Prevents an exercise turning into an incident |
| Reporting and replay | Timeline of actions with timestamps, mapped to MITRE ATT&CK, compared against what the defenders saw | Lets defenders find each gap in their logs and detections |
| Purple teaming | Joint sessions where testers repeat techniques while defenders tune detections | Turns findings into tested detection rules. See the Purple Teaming Guide |
A bespoke engagement often runs a few months from scoping to closure. CBEST guidance cites an average project duration of around 9 to 12 months, with indicative phases of about 6 weeks initiation, 10 weeks threat intelligence, 14 weeks penetration testing and 4 weeks closure, and the DORA standards require at least 12 weeks of active red team testing.
Evaluation criteria
An illustrative weighting: 25% team and tradecraft, 20% threat intelligence approach, 20% risk management and rules of engagement, 15% reporting, replay and purple team outputs, 10% scheme accreditation and provider security, 10% commercials.
| Criterion | Strong answer | Weak answer |
|---|---|---|
| Team | Named red team lead and operators with relevant certifications and comparable engagements; continuity across the test | Penetration testers relabelled as a red team; names withheld |
| Accreditation | Where a scheme applies, accreditation that scheme requires: CBEST providers must be accredited and CREST members employing certified red team managers and threat intelligence managers | Claims of scheme experience with no verifiable accreditation |
| Threat intelligence | Scenarios traced to named threat actors or campaigns and to your footprint; intelligence refreshed during the test | Generic "nation state" scenario applied to every client |
| Rules of engagement | Written, signed, with stop conditions, prohibited actions, escalation contacts and data handling. See the Red Team Rules of Engagement Template | Verbal agreement; "we'll know when to stop" |
| Reporting | Attack timeline, detection opportunities missed and caught, root causes, ATT&CK mapping, prioritised recommendations | List of vulnerabilities with CVSS scores and no narrative |
| Provider security | Hardened, segregated infrastructure; logging of every operator action; evidence encrypted and deleted on schedule | Shared tooling infrastructure across clients; evidence kept indefinitely |
| Commercials | Phased pricing (intelligence, testing, reporting, replay, purple team) with day estimates and change control | Single lump sum with replay and purple teaming as unpriced extras |
Contract terms that matter
- Authorisation: written authorisation from someone with authority over every asset and attack path, including consent from cloud and outsourcing providers where their terms require it.
- Insurance: professional indemnity cover appropriate to the risk; under DORA Article 27 external testers must carry it.
- Social engineering limits: who may be targeted, what pretexts are off limits, how staff welfare is protected and how HR is involved.
- Evidence and credentials: encrypted storage, named access, destruction certificate, and rotation of any credential the team obtained.
- Personnel: named operators, no subcontracting without approval, vetting where required.
Where identity fits
Most red team paths run through identity: phished or reused credentials, tokens stolen from developer machines, over-privileged service accounts, and federation or identity provider abuse. Ask providers how they test machine identities and cloud roles, and require a closure step that revokes and rotates every credential, token and key used or captured during the test. See the Red Teaming AI Agents for Identity Abuse guide where AI agents are in scope.
Questions to ask vendors
- Who will run our engagement, what red team engagements of comparable scope have they run, and will the same people stay throughout?
- For which schemes (TIBER-EU, CBEST, DORA TLPT, others) are you accredited or have you delivered tests, and how can we verify that?
- How do you build scenarios from threat intelligence, and who provides that intelligence if you do not?
- What stop conditions and escalation steps do you propose, and how do you deconflict if our defenders respond?
- How do you log operator actions so that we can replay every step against our own telemetry?
- What does replay and purple teaming include, how many days, and what do our defenders receive at the end?
- How is your attack infrastructure secured and separated from other clients, and how is our data destroyed afterwards?
- Do you use AI tools during testing, which data do they see, and who approves their actions?
Red flags
- A proposal that lists IP ranges and applications but no objectives.
- No mention of a control team, stop conditions or deconfliction.
- Scenarios that are identical across clients and sectors.
- Reluctance to share a timestamped activity log after the test.
- Replay and purple teaming offered only as optional extras.
- Willingness to start before written authorisation and third-party consents are in place.
- Pressure to target personal accounts or devices of staff.
Proof of concept
For a service this is a structured selection, ideally with a small paid exercise.
- Shortlist on evidence: verify scheme accreditation where needed, collect named CVs and a redacted report with an attack timeline.
- Run a scoping workshop: give finalists the same objectives and constraints, and compare the scenarios, assumptions and risks each identifies.
- Commission a short assumed breach exercise: a few days from a defined foothold towards one objective, with your control team in place.
- Replay it: compare the provider's log with what your security operations saw, and judge how useful the walkthrough was to defenders.
- Close cleanly: confirm removal of implants and accounts, rotation of captured credentials and destruction of evidence.
After the main engagement, track: time to detect and contain at each attack stage, share of techniques detected, new detections deployed from purple team sessions, remediation actions closed on time, and repeat paths in the next test.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for offensive security services, including how identity and machine credentials are tested and cleaned up. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Red Teaming Guide · Threat-Led Penetration Testing Guide · Red Team Services RFP Template · Purple Team Exercise Plan Template