Every AI SOC bidder will claim high triage accuracy and big analyst time savings, and none of those numbers mean anything until the platform has been measured on your own alerts, with your own permissions model, under your own approval rules. This template gives you a ready-to-issue request for proposal for an AI SOC platform: software that uses large language models and agents to triage alerts, investigate and, within limits you set, take response actions. Requirements are numbered and written so answers can be tested and scored, with evidence questions on accuracy, autonomy limits, permissions, data handling and audit. It is vendor-neutral and written for SOC leads, security architects, procurement and evaluation panels. For how the category works and when you need it, read the AI SOC Platform Buyer's Guide first; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [SIEM], [EDR] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example AIS-TRI-02) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few, and make the autonomy and audit controls in sections 4.4 and 6 mandatory.
- Build Appendix A yourself before issue: a labelled replay set of [500 to 2,000] historical alerts from your own tools with the analyst's final verdict (true positive, benign true positive, false positive). Accuracy claims are scored only against this set.
- Weights and volumes in brackets are illustrative. Fix weights before responses arrive.
- Issue sections 1 to 8 to bidders. Implementation guidance is for the panel only. Ask for responses in a spreadsheet with one row per requirement ID and a column for the evidence supplied.
1. Purpose and scope
[Organisation] invites proposals for an AI SOC platform to triage and investigate security alerts from [SIEM], [EDR], [identity provider], [email security] and [cloud] sources, produce documented verdicts, and carry out approved response actions. The platform will support a SOC of [number] analysts handling approximately [number] alerts per day, operating [24x7 / business hours]. In scope: alert triage, investigation, case documentation, response orchestration within defined autonomy limits, and reporting. Out of scope: replacement of the SIEM or EDR, and managed detection services unless offered as an option in section 7.
2. Current state
- Tools: [SIEM], [EDR], [SOAR or none], [ticketing system], [identity provider], [cloud platforms].
- Alert volume and mix: [alerts per day] by source, with current false positive rate of approximately [percent] and median time to triage of [minutes].
- Playbooks: [number] documented triage and response playbooks; [number] automated today.
- Constraints: data residency [region], regulatory obligations [list], change approval for response actions [process].
3. Instructions to bidders
- Answer each requirement as Met, Met with configuration, Roadmap (with date) or Not met, and attach evidence: documentation link, screenshot, test result or third-party report.
- State which large language models the platform uses, who hosts them, and whether this can change during the contract without notice.
- Accuracy figures must state the dataset, the number of alerts, the period and the definition of each verdict class. Figures from other customers' data are informational only.
- Shortlisted bidders must take part in the proof of concept in section 8, including the replay of Appendix A.
4. Functional requirements
4.1 Integrations and data access
| ID | Requirement | Type |
|---|---|---|
| AIS-INT-01 | For each tool listed in section 2, state the integration method (API, connector, webhook), whether it is read-only or read-write, and the exact API scopes or roles required. | M |
| AIS-INT-02 | Investigations can query [SIEM] and [EDR] directly, and every query the platform runs is shown in the case record. | S |
| AIS-INT-03 | Can use [Organisation] context: asset inventory, identity attributes, known service accounts, business criticality and prior cases. | S |
| AIS-INT-04 | Writes verdicts, evidence and actions back to [ticketing system] and [SOAR] with links to source events. | S |
| AIS-INT-05 | Detects and alerts when an integration fails or a source stops sending. | M |
4.2 Triage accuracy and explainability
| ID | Requirement | Type |
|---|---|---|
| AIS-TRI-01 | On the Appendix A replay, report a confusion matrix per alert source: true positives correctly escalated, false positives correctly closed, and true positives wrongly closed (missed threats). | M |
| AIS-TRI-02 | States the missed-threat rate the platform targets and how it is monitored in production, not only overall accuracy. | S |
| AIS-TRI-03 | Each verdict includes the evidence used, the reasoning steps, the queries run and a confidence level an analyst can check. | M |
| AIS-TRI-04 | Analysts can override a verdict; overrides are recorded and used to measure accuracy over time. | S |
| AIS-TRI-05 | Describe how the platform handles content that may contain instructions aimed at the model (for example text in emails, file names or log fields), with reference to OWASP LLM01 Prompt Injection, and what testing has been done. | S |
| AIS-TRI-06 | Describe how outputs that are factually wrong or unsupported (OWASP LLM09 Misinformation) are detected, and how results stay consistent when the same alert is re-run. | S |
See the Alert Triage Guide and the OWASP LLM Top 10 LLM01 Prompt Injection Guide.
4.3 Investigation and case management
| ID | Requirement | Type |
|---|---|---|
| AIS-INV-01 | Builds an investigation timeline across sources, mapping observed behaviour to MITRE ATT&CK techniques where applicable. | S |
| AIS-INV-02 | Supports [Organisation] playbooks as written, and states how custom playbooks are defined, versioned and tested. | S |
| AIS-INV-03 | Produces case summaries suitable for handover and for incident reports, with every claim linked to source evidence. | S |
| AIS-INV-04 | Analysts can ask follow-up questions in natural language, and the platform shows the queries it ran to answer. | I |
4.4 Response actions and autonomy limits
| ID | Requirement | Type |
|---|---|---|
| AIS-AUT-01 | Autonomy is configurable per action type, per asset group and per alert source, with at least three levels: recommend only, act after human approval, act automatically. | M |
| AIS-AUT-02 | High-impact actions ([disable account], [isolate server], [block domain], [revoke tokens]) can be restricted to human approval, and the restriction cannot be bypassed by the model. | M |
| AIS-AUT-03 | Supports exclusion lists (for example executives, production databases, break-glass accounts) that no automated action may touch. | M |
| AIS-AUT-04 | Every automated action can be reversed from the case record, and reversal is logged. | S |
| AIS-AUT-05 | Rate limits and a global stop switch halt all automated actions within [minutes]. | M |
| AIS-AUT-06 | Explain how the design addresses OWASP LLM06 Excessive Agency: excessive functionality, excessive permissions and excessive autonomy. | S |
See the OWASP LLM Top 10 LLM06 Excessive Agency Guide and the Human-in-the-Loop for AI Agents Guide.
5. Permissions, identity and platform security
An AI SOC platform holds credentials to the most sensitive tools in the estate. Treat its agents as non-human identities with their own lifecycle.
| ID | Requirement | Type |
|---|---|---|
| AIS-SEC-01 | Each integration uses a dedicated service identity with least-privilege scopes; list them all. Shared or personal admin credentials are not acceptable. | M |
| AIS-SEC-02 | Supports short-lived credentials or workload identity federation where the target platform allows it; otherwise describe secret storage, rotation and revocation. | S |
| AIS-SEC-03 | Read and write permissions are separable, so triage can run read-only while response actions use a separately approved identity. | M |
| AIS-SEC-04 | Platform access uses [Organisation] SSO with phishing-resistant MFA and role-based access; state the roles available. | M |
| AIS-SEC-05 | State whether [Organisation] data, prompts or outputs are used to train or fine-tune any model, and provide a contractual opt-out (OWASP LLM02 Sensitive Information Disclosure). | M |
| AIS-SEC-06 | State where data is processed and stored, including model hosting regions and sub-processors. | M |
| AIS-SEC-07 | Provide current independent assurance (for example SOC 2 Type II or ISO/IEC 27001 certificate with scope) and the results of AI-specific security testing, including prompt injection testing. | S |
| AIS-SEC-08 | Describe your secure AI development practice against the NCSC Guidelines for Secure AI System Development (secure design, development, deployment, operation and maintenance). | I |
See the Agent Identity and Access Guide.
6. Audit, evidence and governance
| ID | Requirement | Type |
|---|---|---|
| AIS-AUD-01 | Logs every model input context, tool call, query, verdict, approval and action with timestamp, identity used and model version. | M |
| AIS-AUD-02 | Audit logs can be exported continuously to [SIEM] and are protected from alteration by platform users. | M |
| AIS-AUD-03 | Notifies [Organisation] in advance of model or prompt changes that may affect verdicts, and supports re-running the Appendix A replay after changes. | S |
| AIS-AUD-04 | Provides reporting on accuracy, overrides, actions taken and time saved, with the method for each metric. | S |
| AIS-AUD-05 | Describe how the offering supports risk management aligned with the NIST AI Risk Management Framework (Govern, Map, Measure, Manage). | I |
See the AI Agent Audit Trails for Regulators Guide.
7. Services, support and pricing
- Onboarding: describe the implementation plan, the time to first production use and the [Organisation] effort required.
- Tuning: state who tunes playbooks and context after go-live and how often accuracy is reviewed with [Organisation].
- Support: severity definitions and response times, including for an automated action that caused disruption.
- Pricing: price at [current], [1.5x] and [3x] alert volumes, stating the unit (alerts, investigations, users, data volume or model consumption) and any overage terms.
- Exit: export of case records, verdicts, playbooks and audit logs in documented formats at [no charge / stated charge].
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Triage accuracy and explainability (4.2) | [30%] | Appendix A replay results |
| Autonomy limits and response (4.4) | [15%] | Live demonstration of approvals, exclusions and stop switch |
| Permissions and platform security (5) | [15%] | Scope list, assurance reports |
| Audit and governance (6) | [10%] | Exported logs from the proof of concept |
| Integrations and investigation (4.1, 4.3) | [10%] | Proof of concept cases |
| Cost over the term (7) | [20%] | Priced at three volumes |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated in the proof of concept. Shortlisted bidders will run a [four]-week proof of concept covering:
- Replay Appendix A in read-only mode and report the confusion matrix per source; the panel holds back [20%] of labels until results are submitted.
- Run [ten] live alerts in parallel with analysts and compare verdicts and time taken.
- Submit [five] test alerts containing embedded instructions aimed at the model in email bodies, file names and log fields, and record whether behaviour changes.
- Demonstrate an approval-gated action, an exclusion-list block, a reversal and the global stop switch.
- Export the full audit log for the proof of concept and check that every action traces to an identity, approval and model version.
- Re-run [50] alerts a week later and measure verdict consistency.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Build the replay set first: without labelled historical alerts, accuracy claims cannot be compared. Include hard cases: true positives that analysts nearly closed, and noisy benign alerts.
- Score missed threats above time saved: a platform that closes 95% of alerts but misses one real intrusion in the replay is worse than one that escalates more. Weight AIS-TRI-01 and AIS-TRI-02 accordingly.
- Start read-only: run in recommend-only mode for [30 to 90] days in production, then enable approval-gated actions, then limited automatic actions for low-risk, reversible steps.
- Protect the proof of concept: issue time-limited, least-privilege credentials for the trial and revoke them afterwards; do not grant write scopes until the autonomy tests.
- Plan for model change: the model behind the platform will change during the contract. AIS-AUD-03 and a quarterly replay keep accuracy visible.
- Small vs large SOCs: smaller teams gain most from triage and case documentation and may prefer a platform bundled with managed services; larger SOCs should weight integration depth, custom playbooks and audit export more heavily.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Triage and investigation (4.2, 4.3) | AU-6, SI-4 | DE.AE-02, RS.AN-03 |
| Automated response (4.4) | IR-4(1) | DE.AE-02 |
| Service identities and permissions (5) | AC-6 | PR.AA-05 |
| Audit logging (6) | AU-12, AU-9 | RS.AN-03 |
| Supplier and acquisition (all) | SA-4, SR-6 | GV.SC-05 |
MITRE ATLAS records prompt injection as AML.T0051 LLM Prompt Injection; use it alongside OWASP LLM01 when writing test cases.
Standards and references
- OWASP: Top 10 for LLM Applications 2025
- NIST: AI Risk Management Framework
- NCSC: Guidelines for Secure AI System Development
- MITRE ATLAS: LLM Prompt Injection
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: AI SOC Platform Buyer's Guide · AI SOC Guide · Agentic AI in the SOC Guide · SIEM RFP Template · Security Vendor Evaluation and RFP Guide