Paste-ready BAS requirements (safe attack simulation, MITRE ATT&CK mapping, prevention and detection validation, scheduling, automated pen testing), vendor questions and a weighted rubric.
See the structure before you download. The Word file has every section listed below, ready to fill in.
The sections in the document, in order.
Use this breach and attack simulation RFP template when you need to prove, on a schedule rather than once a year, that your security controls block, detect and alert on the attacker techniques that matter to you, across endpoints, network, email, web and cloud. Many BAS products are now sold as exposure validation platforms that also include automated penetration testing, so this template covers that as an option you can keep or delete.
It's written for the security operations, detection engineering and procurement team running the evaluation, and it covers the whole process: when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.
Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.
A breach and attack simulation evaluation involves the security operations center, detection engineering, the owners of every control being tested and IT operations, which has to accept attacker techniques running on production systems. The example schedule in this template runs about 11 weeks from kickoff to contract award; allow more if your proof of concept spans several network zones or cloud accounts.
Breach and attack simulation runs safe versions of attacker techniques, usually from agents you place on endpoints, servers and network segments, and records whether each security control prevented, detected or missed them. It answers a control question: if an attacker does this, do our tools stop it or tell us? Results are mapped to MITRE ATT&CK, and tests run on a schedule, so you find out when a control that used to work stops working.
Automated penetration testing answers a different question: what can an attacker actually reach from here? It probes your environment, often without agents, and chains real weaknesses such as weak or reused credentials, misconfigurations and unpatched systems to show attack paths to critical assets. Many vendors now sell both in one platform, often described as exposure validation or adversarial exposure validation. Neither replaces skilled human testers for business-logic flaws, creative attack chains or a penetration test your auditors or regulators require, so check whether automated testing will satisfy them before you count on it.
Continuous threat exposure management (CTEM) is a program, not a product. It is usually described in five stages: scoping, discovery, prioritization, validation and mobilization. BAS and automated penetration testing support the validation stage, by showing which exposures can actually be exploited given your controls. If a vendor positions its product as a complete CTEM solution, ask which stages it covers and which still depend on your own processes and other tools.
Signs you should keep the automated penetration testing requirement (F16) in this template:
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
| ID | Requirement | Priority |
|---|---|---|
| F1 | A library of attack scenarios that run safe versions of real attacker techniques, each mapped to MITRE ATT&CK tactics, techniques and sub-techniques, covering at least endpoint, network, email, web and data exfiltration. State how many techniques you cover for each and how you define a technique as covered. | Must-have |
| F2 | A result for every simulated action that distinguishes prevented, detected (an alert was raised), logged only (telemetry arrived but no alert fired) and missed, with the evidence behind each result, such as the matching EDR alert or SIEM event. | Must-have |
| F3 | Endpoint scenarios on Windows, macOS and Linux covering techniques such as credential access (including against Active Directory), privilege escalation, persistence, defense evasion, misuse of built-in system tools and ransomware behavior. Ransomware scenarios must act only on test files the product creates, never on our data. | Must-have |
| F4 | Network scenarios run between agents in different network zones, to validate segmentation, firewall rules and intrusion prevention, including lateral movement and command-and-control traffic over common protocols such as HTTPS and DNS. | Must-have |
| F5 | Data exfiltration scenarios that send synthetic sensitive data (such as test card numbers and fictitious personal records) over web, DNS, email and cloud storage channels, to validate our data loss prevention controls. | Must-have |
| F6 | Email scenarios that send simulated malicious attachments, links and spoofed messages to designated test mailboxes, and report whether our email security controls blocked, quarantined or delivered each one. This tests our email controls, not our staff; phishing simulation for employee awareness is a separate product category. | Must-have |
| F7 | Web gateway scenarios that attempt to download simulated malicious files and connect to malicious or uncategorized destinations, from devices on our network and from remote users' devices. | Must-have |
| F8 | Web application firewall (WAF) scenarios that send simulated attacks, such as those in the OWASP Top 10 categories, to applications or test endpoints we designate. | Nice-to-have |
| F9 | Cloud scenarios in our accounts with [list cloud providers], such as permission misuse, access to storage and changes to logging settings, run with permissions we approve, to validate cloud-native detections and our cloud security tools. | Nice-to-have |
| F10 | Threat-informed scenarios that chain techniques in the order a named threat group or malware family uses them, plus new scenarios for significant emerging threats and government security advisories. State the usual time from a public advisory to an available scenario. | Must-have |
| F11 | Custom scenarios built from library actions in any order, with our own parameters, run against the agents or network zones we choose. | Must-have |
| F12 | Import of our own scripts, commands or test files into custom scenarios, with a review and approval step before they can run. | Nice-to-have |
| F13 | Scheduling of one-off and recurring assessments, an alert when a control that previously prevented or detected a technique stops doing so, and a one-step retest of failed actions after a fix. | Must-have |
| F14 | Remediation guidance for each failed action, specific to the product and control involved, such as prevention settings, signatures or detection-rule logic (for example, in our SIEM's query language or a vendor-neutral format such as Sigma). | Must-have |
| F15 | Dashboards and reports for different audiences: a MITRE ATT&CK heatmap of prevention and detection results, trends by control and by technique over time, and an executive summary showing which controls improved or got worse. | Must-have |
| F16 | Automated penetration testing that, within a scope and time window we approve, discovers assets, finds weak credentials, misconfigurations and exploitable vulnerabilities, and shows attack paths from a starting point to critical assets such as domain administrator accounts. State whether it needs agents and what it changes on target systems. | Nice-to-have |
| F17 | A purple-team mode in which a tester runs scenario steps one at a time while defenders watch their tools, with notes and outcomes recorded against each step. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | A statement of the deployment models offered (vendor-hosted SaaS, customer-hosted or air-gapped) and which features differ between them. Make a customer-hosted or air-gapped option Must-have if your environment can't connect to a cloud service. | Must-have |
| T2 | Lightweight agents for Windows, macOS and Linux endpoints and servers, installable through our software distribution tools, with published CPU, memory, disk and network use. State whether installation or upgrades need a reboot. | Must-have |
| T3 | Documentation of everything agents and tests need from our environment: privileges, outbound connections, firewall rules and any exclusions in our security tools. State exactly which exclusions are needed and why; they must not exempt the simulated attack activity from our controls. | Must-have |
| T4 | Agentless options for tests that don't need an agent, such as email, WAF and internet-facing tests. State which scenarios require agents and what is lost without them. | Must-have |
| T5 | Vendor-hosted attacker infrastructure on the internet for command-and-control, infiltration and exfiltration tests, plus the option to keep tests inside our network using attacker or target nodes we host. | Must-have |
| T6 | Safety controls on every scenario: benign payloads, no destructive or irreversible changes, automatic clean-up of files, processes and settings after each test, rate limits, and exclusions for systems and time windows we specify. | Must-have |
| T7 | A stop control that immediately halts all running tests across all agents, available to authorized administrators at any time, with confirmation that each agent has stopped. | Must-have |
| T8 | Support for [number] agents across [number] network zones and sites, with concurrent assessments. State the largest deployment you support today. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| I1 | Integration with our SIEM and EDR/XDR to confirm automatically, for each simulated action, whether the expected telemetry arrived, whether an alert fired and how long the alert took. List pre-built integrations. | Must-have |
| I2 | Single sign-on via SAML 2.0 or OIDC. State whether user and group provisioning via SCIM is supported. | Must-have |
| I3 | Creation of tickets in our ITSM platform for failed actions, with the remediation guidance attached and the ticket status visible in the product. | Must-have |
| I4 | SOAR integration that lets our playbooks start assessments, for example after a firewall or EDR policy change, and that tests whether our response playbooks run on simulated activity. | Nice-to-have |
| I5 | A documented REST API for agents, scenarios, assessments, results and reports, plus webhooks or event export when an assessment completes. | Must-have |
| I6 | Import of threat intelligence, such as STIX 2.1 reports or lists of ATT&CK techniques, to find matching scenarios and coverage gaps, and export of results as MITRE ATT&CK Navigator layers. | Nice-to-have |
| I7 | Import of findings from our vulnerability scanners, and export of validated results to our vulnerability or exposure management platform, so evidence of exploitability informs remediation priority. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| S1 | Role-based access that separates who can build, approve and run scenarios, limits which agents, zones and scenario types each role can use, and requires approval before high-impact scenarios run. | Must-have |
| S2 | Administrator access through SSO with MFA, and an audit log of every scenario created, approved, run or stopped and every configuration change, exportable to our SIEM. | Must-have |
| S3 | Protection against misuse of the platform itself: encrypted, outbound-only communication from agents, mutual authentication between agents and the console, signed agent updates and scenario content, and agents that run only content issued from our tenant. | Must-have |
| S4 | A statement of what data each test collects from our systems. BAS scenarios must not collect or send real credentials, password hashes or business data; if an automated penetration testing module uses real credentials it finds, describe how they are protected, how long they are kept and how they are deleted. | Must-have |
| S5 | A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed service, available under NDA. | Must-have |
| S6 | FedRAMP authorization at the required impact level, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. | Nice-to-have |
| S7 | Choice of the region where our results and logs are stored, configurable retention, and export of all results at any time in a usable format. | Must-have |
| S8 | A published vulnerability disclosure process and committed timelines for fixing security flaws in agents and customer-hosted components, with direct notice when a fix needs action from us. | Must-have |
| S9 | A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | A deployment plan covering agent placement (which endpoints, servers, network zones and cloud accounts), integrations, the initial scenario set and a baseline assessment, with the effort expected from both sides. | Must-have |
| M2 | A safe rollout that starts with low-impact scenarios on pilot systems, and a written procedure for telling our SOC, any MDR or MSSP provider and change management what will run and when, so simulated activity isn't handled as a real incident. | Must-have |
| M3 | Identification of who delivers the implementation (vendor, partner or both) and the relevant experience of the named team. | Must-have |
| M4 | A service-level agreement for availability of the management console and scheduled assessments, with service credits. State how availability is measured. | Must-have |
| M5 | 24×7 support with response-time targets by severity, including an urgent path when a test has unexpected impact on a production system. State the targets. | Must-have |
| M6 | Scenario library updates on a stated schedule, with release notes listing new and changed scenarios and their ATT&CK mapping. | Must-have |
| M7 | Access to the vendor's specialists for interpreting results and tuning detections, such as periodic reviews or detection engineering workshops. State what is included and what is charged. | Nice-to-have |
| M8 | Training and documentation for administrators, SOC analysts and control owners, with certification options for our staff. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by module (for example endpoint, network, email, web gateway, WAF, cloud and automated penetration testing), metric (per agent, per asset or platform fee) and term, showing list price, discount and net price. | Must-have |
| C2 | A statement of any limits on assessments, scenario runs, agents or concurrent tests, and the charge for exceeding them. | Must-have |
| C3 | Prices for adding agents or modules mid-term, co-terminated with the main agreement. | Must-have |
| C4 | A cap on price increases at renewal. State the cap. | Must-have |
| C5 | A proof of concept at no charge, with the vendor's engineering support. | Nice-to-have |
| C6 | Exit terms covering export of results history, custom scenarios and reports, removal of all agents, and deletion of our data with written confirmation. | Must-have |
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Scenario coverage and threat currency | 20% | Generally available scenarios for every attack vector in scope, mapped to MITRE ATT&CK at procedure level, with new threats added quickly and release notes to prove it. |
| Result accuracy and detection validation | 20% | Prevention and detection results that match what your controls actually recorded in the proof of concept, with evidence attached to each result. |
| Safety and control of testing | 15% | Benign payloads, reliable clean-up, a stop control that works, approval workflows, and no exclusions that weaken your real protection. |
| Remediation and continuous validation | 10% | Fix guidance specific to your products, ticketing, quick retests, and alerts when a control that used to work stops working. |
| Integration and operations | 10% | Works with your SIEM, EDR, ITSM and SOAR; a usable API; agents that are easy to deploy and maintain. |
| Implementation and support | 10% | A credible rollout plan that includes SOC and MDR notification, an experienced named team, clear SLAs and committed content updates. |
| Commercials and total cost | 15% | Transparent pricing by module and agent, no surprise limits on test runs, a renewal cap and fair exit terms over a three-year view. |
| Total | 100% |
Scoring scale
Your scope (the controls to validate, the endpoints, network zones, email domains and cloud accounts in scope, and the threats that matter most); requirements for attack scenarios, MITRE ATT&CK mapping, prevention and detection results, safety controls, scheduling, remediation and reporting, each marked Must-have or Nice-to-have; integration, security and support terms; a pricing table; and the rubric you'll score with. This template includes all of them, plus optional requirements for automated penetration testing.
Breach and attack simulation runs a library of safe, repeatable attack techniques on a schedule and reports whether each control prevented, detected or missed them. Penetration testing, whether by people or by automated tools, looks for real weaknesses and chains them to reach a goal, such as administrator access to a critical system. BAS tells you whether your defenses work against known techniques; penetration testing tells you what an attacker could actually reach. They don't replace each other, and human testers remain necessary for business-logic flaws and for tests your auditors or regulators require.
CTEM is a program for finding, prioritizing and fixing exposures on a continuous cycle, usually described in five stages: scoping, discovery, prioritization, validation and mobilization. BAS and automated penetration testing support the validation stage, by showing which exposures can actually be exploited given your controls. A BAS product on its own doesn't make a CTEM program, so ask vendors which stages they support and which depend on your own processes and other tools.
It is designed to be: BAS products use benign payloads, avoid destructive changes and clean up after each test, which is what allows scheduled testing on production systems. Safety still depends on how you set it up, so start with low-impact scenarios on pilot systems, tell your SOC and any MDR provider before tests run, try the stop control during the proof of concept, and require approval for high-impact scenarios. Automated penetration testing goes further than BAS, so check exactly what it does on target systems before you enable it.
The example schedule in this template runs about 11 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of concept. Allow longer if agents must pass through your change process for production systems, or if the proof of concept spans several network zones and cloud accounts. Agent rollout and a baseline assessment follow the award.
Paste-ready requirements for finding and securing service accounts, API keys, tokens, workload identities and AI agents, with vendor questions, a scoring rubric…
Paste-ready ZTNA requirements (per-app policy, device posture, agent and agentless access, connectors, VPN migration), vendor questions that separate products, and a weighted…
Paste-ready requirements for immutable backup storage and cyber recovery vaults (object lock, isolation, multi-person approval, clean-room recovery), vendor questions and a weighted…
Please provide your feedback below.
"*" indicates required fields