SOAR RFPs that ask "how many integrations do you have?" and "do you support low-code playbooks?" get the same answer from every bidder, and the real differences surface after award: connectors that break when an API changes, containment actions with no approval gate and execution-based bills that grow with every loop. This template gives you a ready-to-issue request for proposal for a security orchestration, automation and response (SOAR) platform or security automation capability, with numbered requirements written so each answer can be tested and scored. It covers integrations, playbook authoring and testing, case management, response safety, AI-assisted automation, credential handling, platform security and workload-based pricing, and ends with a playbook test plan. It is vendor-neutral and written for SOC leads, automation engineers, procurement and evaluation panels. Read the SOAR Buyer's Guide first to decide between SIEM-native, XDR-native and standalone automation; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [SIEM], [EDR], [ITSM] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example SOAR-PB-03) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few.
- Alert volumes, execution counts and weights in brackets are illustrative. Export a month of real alerts by type before issue; pricing answers are meaningless without it.
- Complete Appendix A (tools to integrate) and Appendix B (priority use cases) yourself. Bidders price and demonstrate against them.
- Issue sections 1 to 8 and both appendices to bidders. Implementation guidance is for the panel only. Ask for responses in a spreadsheet with one row per requirement ID.
1. Purpose and scope
[Organisation] invites proposals for a security automation platform and associated services to orchestrate enrichment, triage, case handling and response actions across the tools in Appendix A, for the use cases in Appendix B.
- In scope: integrations with Appendix A tools; playbook authoring, testing and version control; case management or two-way integration with [ITSM]; approval and response controls; reporting; any AI-assisted triage features offered.
- Out of scope: [SIEM, separate procurement]; [24/7 monitoring, provided by our SOC or MDR]; [general IT workflow automation outside security].
- Contract term: [three] years, with an option to extend by [two].
- Drivers: [analyst time spent on repetitive triage]; [slow containment of compromised accounts]; [current SOAR end of support or cost growth]; [consolidation onto SIEM-native automation].
2. Current state
| Item | [Organisation] value |
|---|
| Current automation | [product, scripts or none; contract end date; number of playbooks in production] |
| Alert volume to automate | [number] alerts a month, of which [number] phishing reports, [number] endpoint, [number] identity |
| SIEM and XDR | [products]; whether either includes automation already licensed |
| Playbook builders | [number] analysts using visual editors, [number] engineers writing code |
| Change and approval rules | [which containment actions need human approval today, and from whom] |
| Hosting constraints | [SaaS acceptable / on-premises execution required for internal tools] |
3. Instructions to bidders
- Timeline: RFP issued [date]; questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Contact: [name, email]; other contact about this RFP may lead to disqualification.
- Response scale: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless contractually committed.
- Evidence: link the product documentation page supporting each "available now" answer, and for each Appendix A tool state who maintains the connector.
4. Functional requirements
4.1 Integrations
| ID | Requirement | Type |
|---|
| SOAR-INT-01 | For each Appendix A tool, state the connector's actions (read, enrich, contain, remediate), maintainer (bidder, partner, community or customer), supported API version and any extra charge. | M |
| SOAR-INT-02 | State the committed time to fix a bidder-maintained connector after a third-party API change, and how customers are notified of breaking changes. | S |
| SOAR-INT-03 | Custom integrations can be built against REST APIs and webhooks with documented SDKs, stored in version control and deployed like other playbook content. | S |
| SOAR-INT-04 | Runs actions against internal tools through an on-premises execution component, with outbound-only connectivity and its own documented hardening. | S |
| SOAR-INT-05 | Ingests alerts from [SIEM], [EDR] and email reporting mailboxes with deduplication and grouping into cases, and writes status back to the source. | M |
4.2 Playbook authoring, testing and change control
| ID | Requirement | Type |
|---|
| SOAR-PB-01 | Provides a visual editor and code steps (state languages), with reusable sub-playbooks, error handling, retries and timeouts. | M |
| SOAR-PB-02 | Playbooks are versioned, exportable as files, can be stored in [Git], peer reviewed and promoted from test to production with an approval record. | S |
| SOAR-PB-03 | Supports testing playbooks with replayed or synthetic alerts in a non-production mode where response actions are simulated, not executed. | S |
| SOAR-PB-04 | Imports or exports playbooks in the OASIS CACAO Security Playbooks v2.0 format, or states the format used and how playbooks can be migrated out. | S |
| SOAR-PB-05 | Restricts who can create, edit, publish and run playbooks by role, and logs every change with before and after content. | M |
| SOAR-PB-06 | Reports playbook health: failed runs, failing connectors, average run time and actions taken per playbook. | S |
See the OASIS CACAO Security Playbooks Standard Guide and the SOAR and Security Automation Guide.
4.3 Case management and analyst workflow
| ID | Requirement | Type |
|---|
| SOAR-CASE-01 | Provides case management with timelines, evidence attachment, tasks, SLAs and role-based visibility, or integrates two ways with [ITSM]. | M |
| SOAR-CASE-02 | Records every automated and manual action on a case with actor (human, playbook or AI feature), input, output and time, exportable for incident reports. | M |
| SOAR-CASE-03 | Reports mean time to triage, contain and close by use case, and analyst time saved per playbook using a documented method. | S |
4.4 Response safety
| ID | Requirement | Type |
|---|
| SOAR-RSP-01 | Approval steps per action type (for example disable account, isolate host, block domain, delete email) with named approvers, timeout behaviour and an approval channel such as [chat tool] or email. | M |
| SOAR-RSP-02 | Protected-asset and protected-identity lists (for example domain controllers, executives, break-glass accounts, production service accounts) that playbooks cannot act on without escalation. | M |
| SOAR-RSP-03 | Rate limits and blast-radius caps per playbook (for example no more than [10] accounts disabled per hour), with automatic halt and alert when exceeded. | S |
| SOAR-RSP-04 | Reversal actions for each containment step (re-enable, release, unblock) available from the case in one step. | S |
| SOAR-RSP-05 | Manual override: analysts can stop a running playbook and take the remaining steps by hand. | M |
4.5 AI-assisted automation
| ID | Requirement | Type |
|---|
| SOAR-AI-01 | Describe any AI triage, summarisation or agent features: models used, what customer data they process, whether data trains models, and where processing happens. | I |
| SOAR-AI-02 | AI features cannot take response actions outside the approval and protected-asset controls in 4.4, and every AI-proposed or AI-taken action is logged with its reasoning and inputs. | M |
| SOAR-AI-03 | Describe controls against prompt injection from alert content, email bodies and attachments processed by AI features. | S |
OWASP lists Excessive Agency as LLM06:2025 in its Top 10 for LLM Applications; AI agents in a SOAR platform hold the same credentials as playbooks. See the Prompt Injection Guide and the Agentic AI in the SOC Guide.
| ID | Requirement | Type |
|---|
| SOAR-SEC-01 | Console and API access through [Organisation] SSO with phishing-resistant MFA and granular roles separating playbook authors, approvers and analysts. | M |
| SOAR-SEC-02 | Each integration uses its own identity and credential, scoped to the actions its playbooks need; no shared administrator accounts across tools. | M |
| SOAR-SEC-03 | Credentials are stored encrypted or retrieved at run time from [secrets manager], never shown to playbook authors, rotatable without editing playbooks, and federated or short-lived where the target supports it. | M |
| SOAR-SEC-04 | Logs all administrative actions, credential changes, playbook runs and response actions, retained for [period] and exportable to [SIEM]. | M |
| SOAR-SEC-05 | Current independent assurance report and completed [SIG or CAIQ]; list sub-processors and data locations; describe how bidder staff access tenants and credentials. | M |
| SOAR-NF-01 | Availability commitment of [percentage]; behaviour of queued alerts and in-flight playbooks during an outage. | S |
A SOAR platform that can disable accounts and change firewall rules is a tier-zero non-human identity: theft of its stored tokens maps to Steal Application Access Token (T1528). See the Secrets Management Guide and the Service Account Security Guide.
6. Services and support
- Onboarding: plan to integrate Appendix A tools and put the Appendix B use cases into production within [months], with acceptance criteria per playbook.
- Content: playbook templates provided, how they are updated and how customised copies survive updates.
- Enablement: training for analysts and automation engineers; skills and effort [Organisation] must provide.
- Support: tiers, hours and response targets by severity, including connector failures.
- References: [two or three] customers with similar tools and alert volume.
7. Pricing
Price the full term against Appendix B volumes. Execution-based models charge for loops, retries and polling, so state how these are counted.
| Cost element | What to state |
|---|
| Licence metric | Users, analysts, playbook runs, actions, connectors or ingested alerts; exactly how each is counted |
| Volume tiers | Price at [current], [current plus 50%] and [double] alert volume |
| Overage | Rate, measurement period, and whether test runs and failed runs count |
| Execution components | On-premises runners, extra environments (test, production) |
| Add-ons | AI features, premium connectors, threat intelligence, case management |
| Services | Onboarding, playbook build, day rates |
| Renewal and exit | Cap on renewal increases; playbook and case data export |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Integrations (4.1) | [20%] | Connector actions demonstrated against Appendix A test tenants |
| Playbook authoring and testing (4.2) | [20%] | Build exercise in the proof of concept |
| Response safety and AI controls (4.4, 4.5) | [20%] | Negative tests in the proof of concept |
| Case management (4.3) | [10%] | Analyst walkthrough |
| Platform and credential security (5) | [15%] | Assurance reports, questionnaire, demonstration |
| Cost over the term (7) | [15%] | Priced against Appendix B at three volumes |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders will run a [three]-week proof of concept in test tenants of Appendix A tools:
- Build the phishing triage use case from Appendix B with [Organisation] engineers watching: ingest a reported email, extract and enrich indicators, search for other recipients, and quarantine with approval. Record build time.
- Run the compromised account use case: revoke sessions, reset credentials and disable the account in [identity provider], with approval, then reverse each step from the case.
- Negative tests: a playbook targets a protected identity, exceeds its blast-radius cap, and receives an alert containing instructions aimed at the AI feature. All must stop, escalate or be ignored, and be logged.
- Change test: edit a production playbook through version control with peer review, test it in simulated mode and promote it.
- Credential test: rotate one integration credential in [secrets manager] and confirm playbooks keep working without edits.
- Run a week of replayed alerts and compare the bidder's counted billable units with your own count.
- Export all playbooks and one month of case data in documented formats.
| Appendix | Bidders receive |
|---|
| A. Tools to integrate | [Tool, product, version, actions needed (read, enrich, contain), hosting (SaaS or internal)] for SIEM, EDR, email, identity provider, firewalls, cloud, ITSM, threat intelligence |
| B. Priority use cases | [Use case, monthly volume, current handling time, actions that need approval] for [five to eight] use cases, for example phishing triage, endpoint malware, compromised account, leaked secret, vulnerability ticketing |
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Get detection right first: the joint CISA and ASD's ACSC guidance on implementing SIEM and SOAR treats SOAR as building on a working SIEM; automating noisy alerts automates noise. Check whether automation already licensed in your SIEM or XDR covers Appendix B before buying standalone.
- Write use cases before features: Appendix B with real volumes and handling times is the most useful input to scoring and pricing.
- Score safety as highly as speed: weight the negative tests in step 3 at least as much as build time. A platform you cannot trust to stop will be left in notify-only mode.
- Protect the platform: give bidders test tenants and time-limited, least-privilege credentials, and revoke them afterwards. After award, run the platform's integration identities through the same review as other privileged service accounts.
- Plan the exit at entry: SOAR-PB-02 and SOAR-PB-04 decide whether your playbooks can move to the next platform.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Integrations and enrichment (4.1) | IR-4(1), AU-6 | DE.AE-02 |
| Playbook change control (4.2) | CM-3 | RS.MA-01 |
| Case management (4.3) | IR-4 | RS.AN-03 |
| Response safety (4.4, 4.5) | IR-4(1), AC-6 | RS.MI-01 |
| Credentials and access (5) | IA-5, AC-6 | PR.AA-05 |
| Acquisition (all) | SA-4 | GV.SC-05 |
NIST SP 800-61 Rev. 3 expects containment to be automatic for some incidents with manual action still available, which is what SOAR-RSP-01 and SOAR-RSP-05 test. See the Incident Response Plan Template.
Standards and references
Related NHI Mgmt Group resources: SOAR Buyer's Guide · SOAR and Security Automation Guide · SIEM RFP Template · AI SOC Platform RFP Template · Security Vendor Evaluation and RFP Guide