SIEM RFPs that ask "do you support UEBA?" or "how many integrations do you have?" get a yes and a big number from every bidder, and the real costs appear later as ingestion overages, detection rules that never fire on your data and content you cannot take with you. This template gives you a ready-to-issue request for proposal for a security information and event management (SIEM) platform, with numbered requirements written so answers can be tested in a proof of concept and scored. It covers log ingestion and retention, normalisation, detection content, UEBA, search and investigation, SOAR integration, platform security, services and pricing by volume. It is vendor-neutral and written for SOC leads, detection engineers, procurement and evaluation panels. For how the market works, deployment models and pricing models, read the SIEM Buyer's Guide first; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [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 SIEM-ING-03) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few.
- Volumes, retention periods and weights in brackets are illustrative. Measure your own daily volumes for at least a month, including peaks, before issue, and fix weights before responses arrive.
- Complete Appendix A (log sources with daily volume and retention) yourself. Bidders must price against it, which makes quotes comparable.
- 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.
1. Purpose and scope
[Organisation] invites proposals for a SIEM platform and associated services to collect, retain and analyse security telemetry, detect threats and support investigation and response.
- In scope: collection from the sources in Appendix A; normalisation; hot and archive retention; detection content and detection-as-code workflow; UEBA; search and investigation; case management or integration with [ticketing]; SOAR integration; reporting for [regulations or audits].
- Out of scope: [SOAR platform, separate procurement]; [24/7 monitoring, provided by our MDR or SOC]; [log pipeline layer, if procured separately].
- Contract term: [three] years, with an option to extend by [two].
- Drivers: [renewal or end of support of current SIEM]; [regulatory logging requirements]; [cost growth]; [detection gaps found in incidents or tests].
2. Current state
| Item | [Organisation] value |
|---|---|
| Current SIEM and log tooling | [product, version, contract end date] |
| Measured daily ingestion | [average] GB/day, [peak] GB/day, growth [percentage] a year |
| Largest sources | [for example firewall, EDR, identity provider, cloud audit logs, DNS, proxy] |
| Retention requirement | [days] hot and searchable; [months or years] total; legal hold [yes/no] |
| Detection content in use | [number] rules, [number] saved searches and dashboards to migrate |
| SOC model and staff | [in house / co-managed / MDR], [number] analysts, [number] detection engineers |
| Hosting constraints | [SaaS in named regions acceptable / self-managed required] |
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.
4. Functional requirements
4.1 Ingestion and normalisation
| ID | Requirement | Type |
|---|---|---|
| SIEM-ING-01 | For each source in Appendix A, state the collection method (agent, API, syslog, cloud-native connector), whether the parser is maintained by the bidder, a partner or the customer, and any additional charge. | M |
| SIEM-ING-02 | Normalises events to a documented schema and states whether it maps to an open schema (for example OCSF or ECS). Custom parsers can be built and version-controlled. | S |
| SIEM-ING-03 | Filters, samples or routes data before billing, and states which of these reduce the billed volume. | S |
| SIEM-ING-04 | Detects and alerts on sources that stop sending or drop sharply in volume, within [time]. | M |
| SIEM-ING-05 | Preserves original event time and ingestion time, normalised to UTC in an ISO 8601 format, and flags clock skew. | S |
| SIEM-ING-06 | Behaviour under burst (for example an incident log storm at [5x] normal volume): buffering, dropping, throttling or overage. | S |
See the OCSF Guide and the Security Data Pipeline Guide.
4.2 Retention and search
| ID | Requirement | Type |
|---|---|---|
| SIEM-RET-01 | Retains data per Appendix A: [days] hot and fully searchable, then archive to [total period], with per-source retention settings. | M |
| SIEM-RET-02 | States search performance for a [30]-day query across [volume], and the time and cost to restore or query archived data. | S |
| SIEM-RET-03 | Supports legal hold and immutability of retained logs; describe how deletion is controlled and logged. | S |
| SIEM-RET-04 | Full export of raw and normalised data, rules and dashboards in documented formats on request and at exit, at [no charge / stated charge]. | M |
For US federal agencies, OMB M-21-31 sets minimum retention for most log categories at 12 months in active storage and 18 months in cold storage; use it as a reference point if you have no regulatory figure of your own. See the Log Management and Retention Guide.
4.3 Detection content
| ID | Requirement | Type |
|---|---|---|
| SIEM-DET-01 | Provides a maintained detection library with ATT&CK technique mapping, update cadence and the data sources each rule needs. | S |
| SIEM-DET-02 | Supports detection as code: rules stored in version control, peer review, automated testing and deployment through an API or CI pipeline. | S |
| SIEM-DET-03 | Imports or converts Sigma rules, stating which Sigma rule, correlation and filter features are supported. | S |
| SIEM-DET-04 | Supports correlation across sources and time windows, suppression, thresholds and risk-based alerting. | M |
| SIEM-DET-05 | Identity detections for workforce and non-human identities: sign-ins and token use by service principals, managed identities, service accounts and API keys, OAuth consent grants and privilege changes. | S |
| SIEM-DET-06 | Reports rule health: rules that never fired, noisy rules, and rules whose data source is missing. | S |
See the Detection Engineering Guide and the Detection Engineering for Non-Human Identities Guide.
4.4 UEBA, investigation and AI features
| ID | Requirement | Type |
|---|---|---|
| SIEM-UBA-01 | Builds behavioural baselines for users, hosts and non-human identities, and explains each anomaly with the features that drove it. | S |
| SIEM-UBA-02 | State the baseline period before UEBA produces useful output and the data sources it requires. | I |
| SIEM-INV-01 | Provides entity timelines, pivoting and case management with evidence attachment, or integrates with [ticketing] with two-way status. | S |
| SIEM-AI-01 | Describe any generative AI assistant: what customer data it uses, whether prompts or data train models, how answers cite underlying events, and how it is priced. | I |
4.5 SOAR and integrations
| ID | Requirement | Type |
|---|---|---|
| SIEM-INT-01 | Sends alerts and enriched context to [SOAR or ticketing] through a documented API or webhook, and accepts status updates back. | M |
| SIEM-INT-02 | Native or integrated automation for containment actions (disable account, revoke sessions, isolate host) with approval steps and an audit trail. | S |
| SIEM-INT-03 | Ingests threat intelligence through standard formats (for example STIX and TAXII) and matches indicators retroactively against retained data. | S |
CISA and ASD's practitioner guidance treats a properly implemented SIEM as a higher priority than SOAR; see the SOAR and Security Automation Guide.
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| SIEM-SEC-01 | Administrator and analyst access through [Organisation] SSO with phishing-resistant MFA and granular roles, including restricting access to sensitive data sets. | M |
| SIEM-SEC-02 | Logs all administrative actions, rule changes, searches of sensitive data and data deletion, retained for [period] and exportable. | M |
| SIEM-SEC-03 | Connector and API credentials stored encrypted, scoped per source, rotatable without data loss, and federated or short-lived where the source supports it. | M |
| SIEM-SEC-04 | Current independent assurance report and completed [SIG or CAIQ]; list sub-processors and data locations. | M |
| SIEM-SEC-05 | Describe how bidder staff access customer data, how that access is approved and whether [Organisation] can see those logs. | S |
| SIEM-NF-01 | Availability commitment of [percentage] with service credits; ingestion and alerting behaviour during an outage. | S |
6. Services and support
- Onboarding: plan to onboard Appendix A sources and migrate [number] priority rules within [months], with acceptance criteria.
- Staffing: skills and effort [Organisation] must provide; the joint CISA and ASD guidance stresses that these platforms need skilled, dedicated staff.
- Content updates: cadence, notice and how customised rules survive updates.
- Support: tiers, hours and response targets by severity.
- References: [two or three] customers of similar volume or sector.
7. Pricing
Price the full term against Appendix A. Joint CISA and ASD guidance notes that most SIEM pricing is based on the volume of logs ingested and advises buyers to look for hidden costs such as implementation, switching and query charges.
| Cost element | What to state |
|---|---|
| Licence metric | GB/day ingested, events per second, compute, entities or storage; exactly how it is measured |
| Volume tiers | Price at [current], [current plus 50%] and [double] volume |
| Overage and bursts | Rate, measurement period and burst allowance |
| Retention | Hot, archive and restore or query charges per Appendix A |
| Add-ons | UEBA, SOAR, AI assistant, premium connectors, threat intelligence |
| Services | Onboarding and migration price, day rates |
| Renewal and exit | Cap on renewal increases; export charges |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Detection and UEBA (4.3, 4.4) | [25%] | Proof of concept emulation results |
| Ingestion, retention and search (4.1, 4.2) | [20%] | Proof of concept, performance tests |
| Integrations and SOAR (4.5) | [10%] | Demonstration |
| Platform security (5) | [15%] | Assurance reports, questionnaire |
| Services and references (6) | [10%] | Plan, reference calls |
| Cost over the term (7) | [20%] | Priced against Appendix A 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 with [Organisation] data covering:
- Onboard [five] Appendix A sources, including identity provider, EDR and one cloud audit log, and show the per-source billed volume.
- Run an agreed set of [20] emulated ATT&CK techniques in a test environment and count which produce alerts with useful context.
- Convert [ten] existing rules and [five] Sigma rules and show them deployed from version control.
- Run a timed investigation: a scripted scenario from first alert to scoped timeline.
- Stop one source and measure time to the missing-data alert.
- Export one week of raw data, normalised data and the converted rules.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Measure before you write: a month of real volumes per source, including peaks, is the single most useful input. Without it, pricing answers cannot be compared.
- Write use cases first: list the [15 to 25] detections and investigations you need in year one; the joint guidance expects alert rules to reflect your threat model and to be tested, tuned and retired over time.
- Score on your data: coverage heatmaps show rules that exist, not rules that fire. Weight the emulation results in the proof of concept above slideware.
- Protect the platform: issue bidders time-limited, least-privilege proof of concept accounts and connector credentials, and revoke them afterwards; the winning SIEM will hold credentials for most of your estate.
- Plan the exit at entry: SIEM-RET-04 and SIEM-DET-02 decide what the next migration costs. See the SIEM Migration Guide.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Ingestion and source health (4.1) | AU-2, AU-12, SI-4 | DE.CM-01, DE.CM-03 |
| Retention and integrity (4.2) | AU-9, AU-11 | DE.CM-03 |
| Detection, correlation and UEBA (4.3, 4.4) | AU-6, AU-6(3), SI-4 | DE.AE-02, DE.AE-03 |
| Automation (4.5) | IR-4(1) | DE.AE-02 |
| Platform access (5) | AU-9(4) | DE.CM-03 |
| Acquisition (all) | SA-4 | GV.SC-05 |
CIS Controls v8.1 Control 8 Audit Log Management sets the logging baseline the SIEM should support; see the CIS Control 8 Audit Log Management Guide.
Standards and references
- CISA: Guidance for SIEM and SOAR Implementation
- ASD's ACSC: Implementing SIEM and SOAR Platforms, Practitioner Guidance
- OMB: M-21-31 Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents
- NIST: SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (initial public draft)
- SigmaHQ: Sigma Specification
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: SIEM Buyer's Guide · SIEM Guide · Security Vendor Evaluation and RFP Guide · SOAR Buyer's Guide · Incident Response Retainer RFP Template