Red Team Services RFP Template

A red team engagement is the most realistic test an organisation can buy and the easiest to buy badly: without precise requirements it drifts into an expensive penetration test, or into an uncontrolled exercise that risks live services and sensitive data. This template is a ready-to-issue request for proposal for red team services, whether a single objective-based engagement, a threat-led test under a regulatory scheme, or a programme of exercises over several years. Its numbered requirements cover provider accreditation, threat intelligence, the named team, rules of engagement and safety controls, operational security, detection and response evaluation, reporting and replay, data handling, insurance and commercials, with mandatory and scored criteria, a weighted scoring matrix, a pilot plan and a pricing schedule. It is vendor-neutral and written for CISOs, security operations leads, procurement and evaluation panels. For what the market offers and how providers differ in approach, read the Red Team Services buyer's guide; this page is the procurement document.

How to use this template

Replace text in square brackets, such as [Organisation], [objectives] and [number], with your own details. Delete requirements that do not apply.
Each requirement has an ID (for example RT-OPS-04) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
Weights, durations and amounts in brackets are illustrative, not benchmarks. Fix them before issue and do not change them after responses arrive.
Keep the circle of knowledge small. The RFP itself reveals that a test is coming: issue it through the control team, not general procurement channels, and limit who sees responses.
Issue sections 1 to 9 to bidders. The Implementation guidance section is for your panel only.
Attach the Red Team Rules of Engagement Template as a schedule. For regulated threat-led schemes, the scheme's own procurement guidance takes precedence over this template: see the Threat-Led Penetration Testing Guide.

1. Purpose and scope

[Organisation] invites proposals for red team services. The aim is to test, under controlled conditions, whether a realistic adversary could achieve [objectives] and whether [Organisation]'s people, processes and technology would prevent, detect and respond to them. The outcome is learning and improvement, not a pass or fail.

Engagement model: [single engagement of approximately [number] weeks active testing] or [programme of [number] exercises over [number] years, including purple team sessions].
Objectives (flags): [for example: obtain access to the payments approval workflow; read a named crown jewel data set; obtain administrative control of the cloud tenancy; obtain a production signing key]. Objectives describe outcomes, never methods.
Threat basis: [threat intelligence led by a separate provider], [threat intelligence by the bidder] or [scenarios supplied by [Organisation]].
Attack surfaces in scope: [external perimeter]; [phishing and social engineering of staff]; [telephone social engineering of the service desk]; [physical access to named sites]; [assumed-breach start from a standard workstation]; [cloud and SaaS]; [supplier connections with written permission].
Out of scope: [denial of service]; [named fragile systems]; [personal devices and personal accounts of staff]; [customers]; [third parties without written permission].
Regulatory context: [none] or [scheme name, for example a TIBER-based programme or DORA threat-led penetration testing], with [authority] oversight.

2. Organisation background and constraints

Item	[Organisation] value
Size and footprint	[number] staff; [number] sites; [countries]
Technology	[directory and identity provider]; [cloud providers]; [key SaaS]; [OT or specialist systems]
Security operations	[in-house SOC, MDR or hybrid]; hours of cover; [EDR, SIEM in place]
Previous testing	[penetration tests, red team or purple team exercises in the last three years]
Testing windows	[dates]; [change freezes]; [periods to avoid, such as year end]
Legal constraints	[employment, works council and monitoring rules]; [jurisdictions with specific requirements]

3. Instructions to bidders

Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; presentations and team interviews [dates]; decision [date]; planning starts [date].
Confidentiality: the existence of this RFP is confidential. Bidders must not contact [Organisation] staff other than the named contact.
Single point of contact: [name, email], a member of the control team.
Named team: name the engagement lead, operators and threat intelligence analysts proposed, with qualifications and comparable experience. Substitution after award requires [Organisation]'s written approval and an equivalent replacement.
Sample deliverables: submit one redacted red team report and, if threat intelligence is in scope, one redacted targeted threat intelligence report. Both are scored.
Response scale: for each requirement state met, partly met (explain) or not met, with evidence.

4. Provider requirements

4.1 Accreditation, independence and assurance

ID	Requirement	Type
RT-ACC-01	Holds current company accreditation for intelligence-led or simulated attack testing from [a recognised accreditation body, for example CREST STAR disciplines] or [scheme-specific accreditation]; provide the certificate and date of last reassessment.	[M or S]
RT-ACC-02	Where a regulatory scheme applies, meets every provider requirement in [the scheme's service provider procurement guidance] and supplies the evidence it asks for.	[M where applicable]
RT-ACC-03	Discloses conflicts of interest, including whether the bidder provides [Organisation]'s managed detection, SOC, incident response or security products, and how independence would be maintained.	M
RT-ACC-04	Holds [ISO/IEC 27001 certification] covering the service, or an equivalent independent assurance report.	S

4.2 Team and threat intelligence

ID	Requirement	Type
RT-TEAM-01	The engagement lead has led at least [number] red team engagements of similar scale in the last [three] years; provide anonymised summaries.	M
RT-TEAM-02	Operators hold recognised practical qualifications in [simulated attack or red team operations] [list acceptable qualifications] and experience in each attack surface in scope.	S
RT-TEAM-03	All personnel are directly employed or named subcontractors who pass [Organisation]'s background checks and hold [vetting level] where required.	M
RT-TEAM-04	Threat intelligence (if in scope) is delivered by a team separate from the operators, produces a targeted threat intelligence report with realistic threat actor profiles and scenarios mapped to MITRE ATT&CK, and is reviewed with [Organisation] before scenarios are fixed.	S
RT-TEAM-05	Describe how scenarios cover identity attack paths relevant to [Organisation]: phishing-resistant MFA bypass attempts through social engineering, service desk impersonation, token and session theft, misuse of service accounts, API keys and cloud roles, and supplier access.	S

See the Practical Red Team Certifications Guide and the Red Teaming Guide.

4.3 Rules of engagement and safety

ID	Requirement	Type
RT-OPS-01	No activity starts until signed rules of engagement and a written authorisation (letter of authority) cover objectives, targets, dates, source infrastructure, permitted and prohibited techniques and contacts.	M
RT-OPS-02	A named control team contact is reachable 24 hours a day during active testing; the bidder pauses on request at any time.	M
RT-OPS-03	Stop and escalate immediately on: impact on service, access to data outside agreed limits, discovery of a real prior compromise, or risk of harm to a person.	M
RT-OPS-04	Describe controls to avoid harm: no destructive actions, approval required before any action that changes production configuration, and a log of every change made so it can be reversed.	M
RT-OPS-05	Deconfliction process so that the control team can confirm within [minutes] whether an alert is the red team, and so that real incidents are never ignored.	M
RT-OPS-06	Social engineering and physical activity follow [Organisation]'s legal and HR constraints; individuals are never named or blamed in reports; carry an authorisation letter on site.	M
RT-OPS-07	Malware, implants and tools used are under the bidder's control, removable, and fully removed at the end, with a written confirmation and list of artefacts.	M

4.4 Infrastructure, operational security and data handling

ID	Requirement	Type
RT-DAT-01	Attack infrastructure is owned and controlled by the bidder, hardened, used only for [Organisation], and torn down after the engagement.	M
RT-DAT-02	Data obtained, including credentials, screenshots and files, is minimised, stored encrypted in [region], accessible only to the named team and securely deleted within [days] of report acceptance, with confirmation.	M
RT-DAT-03	Credentials, tokens and keys obtained are used only within scope, recorded in a register shared with the control team, and listed for rotation at the end.	M
RT-DAT-04	Reports and logs are exchanged only through [secure portal or encrypted transfer].	M

4.5 Detection, response and purple teaming

ID	Requirement	Type
RT-DET-01	Maintains a timestamped activity log of every action with source, target and technique (ATT&CK ID) so the blue team can match it to telemetry.	M
RT-DET-02	After the active phase, runs a replay workshop with the blue team comparing red team actions with what was detected, alerted and responded to, and when.	S
RT-DET-03	Offers optional purple team sessions to test specific detections collaboratively; describe format and cost.	S
RT-DET-04	Supports leg-ups (control team assisted steps) when a phase stalls, records each one in the report, and explains what a real attacker would have needed instead.	S

See the Purple Teaming Guide and the Purple Team Exercise Plan Template.

4.6 Reporting

ID	Requirement	Type
RT-RPT-01	Report includes an executive narrative, the attack path for each objective, detection and response observations, root causes, and prioritised recommendations across people, process and technology.	M
RT-RPT-02	Each finding has evidence, affected assets, risk rating in [Organisation]'s scheme and specific remediation; findings delivered in machine-readable form as well.	M
RT-RPT-03	Critical issues (such as a real compromise discovered, or a severe exposure) are reported to the control team within [hours], not held for the report.	M
RT-RPT-04	Draft report within [10] working days of the active phase ending; board-level debrief included; deliverables meet [scheme reporting guidance] where applicable.	S
RT-RPT-05	Supports [Organisation]'s remediation plan and an optional retest of key detection and prevention fixes within [months].	S

5. Vendor security questions

Bidders answer each question in full. Answers are scored under RT-ACC and RT-DAT.

How do you protect client data and findings from your own compromise? Describe segregation between clients, and access controls on engagement data.
Which security incidents affecting client data have you had in the last three years, and how did you notify clients?
How are your operators' own accounts protected (phishing-resistant MFA, privileged access, device controls)?
How do you manage and dispose of credentials and keys captured during engagements?
How do you vet, supervise and bind subcontractors to the same obligations?
How do you source, review and control the tools and implants you use, including open source tools?
What happens to your infrastructure, logs and data if the contract ends early?

6. Contractual, legal and insurance requirements

ID	Requirement	Type
RT-LEG-01	Professional indemnity insurance of at least [amount], public liability of at least [amount] and cyber insurance of at least [amount]; certificates provided.	M
RT-LEG-02	Accepts [Organisation]'s confidentiality terms, a data processing agreement and limits on publication of any engagement detail.	M
RT-LEG-03	Will not test systems owned or hosted by third parties without written permission obtained by [Organisation], and follows cloud providers' published testing policies.	M
RT-LEG-04	Confirms compliance with computer misuse, privacy, employment and physical trespass laws in each jurisdiction in scope.	M

7. Service management

Governance: weekly control team updates during active testing; escalation path to the bidder's senior management.
Quality assurance: describe the technical and editorial review each report receives before release.
Programme continuity: for multi-year programmes, how lessons and threat intelligence carry forward between exercises while avoiding repeating the same paths.
References: [two or three] clients of similar size and sector, including one that ran a regulatory threat-led test if applicable.

8. Pricing schedule

Cost element	What to state
Threat intelligence phase	Fixed price and days
Planning and rules of engagement	Fixed price and days
Active testing phase	Fixed price for [number] weeks; day rate by grade for extensions
Physical and social engineering	Price per site and per campaign, if separate
Reporting, replay and debrief	Fixed price
Purple team sessions and retest	Price per session
Expenses and infrastructure	Capped amount
Cancellation, pause and rescheduling	Notice periods and charges, including a pause requested under RT-OPS-02

9. Evaluation method and pilot

Criterion	Weight	Evidence
Team experience and threat intelligence (4.2)	[25%]	CVs, interviews with proposed lead and operators
Rules of engagement, safety and data handling (4.3, 4.4, 5)	[20%]	Response, sample rules of engagement, security answers
Detection and response evaluation (4.5)	[15%]	Response, example replay output
Report quality (4.6)	[15%]	Sample report scored against RT-RPT-01 and RT-RPT-02
Accreditation, independence and legal (4.1, 6)	[5%]	Certificates, declarations
Price (8)	[20%]	Pricing schedule for the defined scope

Scored requirements use 0 to 5: 0 not met; 3 met with gaps; 5 fully met with evidence. A mandatory requirement not met excludes the bid. A full red team cannot be piloted without spoiling it, so in place of a proof of concept [Organisation] runs this evaluation script with the top [two] bidders:

Scenario workshop (half day): give each bidder a short threat brief and one objective; score the attack scenarios and detection opportunities they propose, and how they apply the rules of engagement.
Operator interviews: the proposed lead and two operators walk through a past engagement, including a moment they stopped or escalated.
Report review: a system owner and a SOC analyst score the sample report for clarity and actionability.
Optional paid purple team session: a one-day collaborative test of [three] specific detections, scoring technique coverage, communication and evidence quality.

Implementation guidance

This section is for the evaluation panel, not for bidders.

Keep the control team small: red team value depends on the blue team not knowing. Limit evaluation panel membership and do not include SOC staff who will be tested.
Buy people and judgement: the interviews matter more than the brochure. Hold the bidder to the named team.
Separate intelligence from testing where you can: TIBER-EU, for example, treats threat intelligence and red team testing as distinct roles, and DORA recital 61 notes that the threat intelligence provider should always be external to the financial entity and refers to alternating internal and external testers every three tests.
Regulated tests have their own rules: TIBER-EU was updated in 2024 to align with the DORA regulatory technical standards on threat-led penetration testing, and its Guidance for Service Provider Procurement sets requirements entities must check. Use this template for scope and scoring, and the scheme documents for eligibility.
Plan for the credentials: red teams routinely capture passwords, tokens, service account secrets and keys. RT-DAT-03 gives you the register; budget time to rotate everything on it. See the Service Account Security Guide.
Measure the blue team, not just the red: time to detect, time to escalate and time to contain from the replay are the most useful outputs. Feed them into detection engineering and track improvement across exercises.

Requirement group	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Red team exercises (4.2, 4.3)	CA-8(2)	ID.IM-02
Assessment and reporting (4.6)	CA-2, CA-8	ID.RA-01, ID.IM-02
Provider due diligence and contract (4.1, 5, 6)	SA-9, SR-6	GV.SC-06

Red Team Services RFP Template: Requirements, Scoring and Vendor Questions