Security data pipeline RFPs that ask "can you reduce SIEM costs?" get the same answer from every bidder, and the real questions surface after signature: which events were dropped, whether delivery was acknowledged, and who can change the routing rules that decide what the SOC ever sees. This template gives you a ready-to-issue request for proposal for a security data pipeline (also sold as a telemetry pipeline or security data fabric), with numbered requirements written so answers can be tested and scored. It covers collection, parsing and OCSF normalisation, reduction, routing, delivery guarantees, pipeline security, pricing by volume and a proof of concept plan. It is vendor-neutral and written for SOC leads, detection engineers, platform teams and procurement. For how the category works and where it fits, read the Security Data Pipeline Buyer's Guide and the Security Data Pipeline Guide first; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [SIEM], [data lake] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example SDP-RED-02) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few.
- Volumes, weights and percentages in brackets are illustrative. Measure at least a month of daily volume per source, including peaks, before issue.
- Complete Appendix A (sources, daily volume, destinations and which event classes detection rules depend on) yourself. Bidders price and design against it, which makes answers 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 security data pipeline platform to collect, parse, normalise, reduce, enrich and route security telemetry from the sources in Appendix A to [SIEM], [data lake or object storage], [archive] and [other tools].
- In scope: collectors and API pollers; parsing and normalisation to a documented schema; volume reduction; enrichment; routing to multiple destinations and tiers; buffering and replay; pipeline monitoring; management plane and change control.
- Out of scope: [SIEM licence, separate procurement]; [detection content]; [24/7 monitoring by our MDR or SOC].
- Contract term: [three] years, with an option to extend by [two].
- Drivers: [SIEM ingestion cost growth]; [planned SIEM migration]; [new data lake]; [sources not collected today]; [data residency requirements].
2. Current state
| Item | [Organisation] value |
|---|---|
| Current collection tooling | [agents, syslog relays, forwarders, open-source collectors], [versions] |
| Measured daily volume | [average] GB/day, [peak] GB/day, growth [percentage] a year |
| Destinations today and planned | [SIEM], [data lake], [archive], [observability platform] |
| Largest sources | [for example firewall, DNS, proxy, EDR, cloud audit logs, identity provider] |
| Target schema | [OCSF version / ECS / SIEM native schema] |
| Hosting constraints | [SaaS control plane acceptable / data plane must stay in named regions / fully self-managed] |
| Team | [number] platform engineers able to operate the pipeline as a product |
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.
- Architecture: state which components run in [Organisation] environments (data plane) and which in the bidder's (control plane), and whether event data ever leaves [Organisation] environments.
4. Functional requirements
4.1 Collection and transport
| ID | Requirement | Type |
|---|---|---|
| SDP-COL-01 | For each source in Appendix A, state the collection method (agent, syslog, OTLP, API pull, cloud storage or queue subscription), who maintains the connector and any extra charge. | M |
| SDP-COL-02 | Receives syslog over TLS (RFC 5425, TCP 6514) with mutual authentication, and OTLP with TLS and an authenticator; listeners bind to specific interfaces rather than all interfaces by default. | M |
| SDP-COL-03 | Reports API polling lag and quota or throttling errors per SaaS and cloud source, so a throttled poller is not mistaken for a quiet period. | S |
| SDP-COL-04 | Detects sources that stop sending or drop below a per-source baseline and alerts within [time]. | M |
| SDP-COL-05 | Preserves original event time and ingestion time, normalised to UTC, and flags clock skew above [threshold]. | S |
4.2 Parsing and normalisation
| ID | Requirement | Type |
|---|---|---|
| SDP-NOR-01 | Maps events to OCSF and states the OCSF schema version supported, which event classes and profiles are covered per source, and how extensions are handled. State support for [ECS / SIEM native schema] as additional outputs. | S |
| SDP-NOR-02 | Keeps the raw event, or a retrievable pointer to it, alongside normalised output; unmapped fields are retained rather than discarded. | M |
| SDP-NOR-03 | Routes parse failures with the raw event to a dead-letter destination and reports the failure rate per source. | M |
| SDP-NOR-04 | Parsers and mappings are stored as code, version-controlled, testable against sample events in CI and exportable in a documented format. | S |
| SDP-NOR-05 | States how parser updates for vendor format changes are delivered, tested and announced, and how customer modifications survive them. | S |
OCSF is an Apache 2.0 licensed open schema that became a Linux Foundation project in November 2024. See the OCSF Guide.
4.3 Reduction, enrichment and routing
| ID | Requirement | Type |
|---|---|---|
| SDP-RED-01 | Supports field removal, deduplication, aggregation of high-volume flow data and truncation, with every rule showing the volume it removes per source. | S |
| SDP-RED-02 | Reduction rules can be scoped so that authentication, audit, privilege change and other detection-relevant event classes are never sampled or dropped; the platform warns when a rule affects a protected class. | M |
| SDP-RED-03 | Before deployment, shows the effect of a rule change on sample traffic and on fields referenced by [Organisation] detection rules. | S |
| SDP-RED-04 | Sends full-fidelity copies of reduced data to [low-cost storage] so removed events can be replayed into [SIEM] during an investigation; state replay speed and cost. | S |
| SDP-ENR-01 | Enriches events with asset, identity, geolocation and threat intelligence context; state how lookup tables are refreshed and how stale lookups are detected. | S |
| SDP-RTE-01 | Routes each event class to one or more destinations and tiers by rule, including data residency rules by region. | M |
| SDP-RTE-02 | Lists native destinations (SIEM, data lake, object storage, queue, SOAR) and the formats written to each, including open table or columnar formats where relevant. | I |
4.4 Delivery guarantees and resilience
| ID | Requirement | Type |
|---|---|---|
| SDP-DEL-01 | State the delivery semantics per source and destination type (at most once, at least once, effectively once) and how duplicates are handled. | M |
| SDP-DEL-02 | Supports end-to-end acknowledgement, so a source or upstream queue learns whether events reached every configured destination. | S |
| SDP-DEL-03 | Provides durable disk or queue buffering sized per source, and states exactly what happens when buffers fill: back-pressure, blocking or discarding (and which events are discarded). | M |
| SDP-DEL-04 | Exposes discard, retry and buffer-utilisation counters per source and destination, with alerting; a non-zero discard count on a protected class raises an alert. | M |
| SDP-DEL-05 | Behaviour when [SIEM] is unavailable for [hours], and during a burst of [5x] normal volume; time to drain the backlog afterwards. | S |
| SDP-DEL-06 | High availability for collectors and processing nodes; data plane keeps processing if the control plane is unreachable. | S |
5. Pipeline security and non-functional requirements
A pipeline that can drop or reroute events can blind the SOC. MITRE ATT&CK T1685 Disable or Modify Tools covers interference with logging pipelines and forwarding, so treat this layer as part of your detection logic.
| ID | Requirement | Type |
|---|---|---|
| SDP-SEC-01 | Management plane access through [Organisation] SSO with phishing-resistant MFA and granular roles separating viewing, rule authoring and rule deployment. | M |
| SDP-SEC-02 | Every routing, reduction and parser change is versioned, attributed to a named identity, optionally subject to approval and exportable to [SIEM] as an audit event. | M |
| SDP-SEC-03 | Source and destination credentials (API keys, ingest tokens, cloud roles) are stored encrypted or in [secrets manager], scoped per connector, rotatable without data loss and federated or short-lived where the source supports it. | M |
| SDP-SEC-04 | Encrypts data in transit between all components and at rest in buffers; state key management options. | M |
| SDP-SEC-05 | Supports masking or tokenisation of personal data fields by rule, logged and reversible only by authorised roles. | S |
| SDP-SEC-06 | Current independent assurance report and completed [SIG or CAIQ]; list sub-processors, data locations and how bidder staff access customer pipelines. | M |
| SDP-NF-01 | Throughput per node or per unit of compute for [event size and mix], with the benchmark method. | I |
The collector service accounts and ingest tokens here are privileged non-human identities. See the NHI Security Platform RFP Template for requirements on governing them.
6. Services and support
- Onboarding: plan to onboard Appendix A sources and route them to [destinations] within [months], with acceptance criteria per source.
- Migration: how existing collectors, forwarders and parsing rules are migrated, and whether the pipeline can run in parallel with current collection.
- Content: who maintains parsers and OCSF mappings, update cadence and notice.
- Support: tiers, hours and response targets by severity, including a severity for data loss.
- References: [two or three] customers of similar volume, with at least one that changed SIEM while using the pipeline.
7. Pricing
Price the full term against Appendix A. Pipeline savings claims depend entirely on what is dropped, so ask bidders to show the reduction assumed for each source.
| Cost element | What to state |
|---|---|
| Licence metric | Ingested GB/day, processed GB/day, delivered GB/day, nodes or compute; exactly where volume is measured |
| Volume tiers | Price at [current], [current plus 50%] and [double] volume |
| Destinations | Whether each additional destination or replay is charged |
| Infrastructure | Compute and storage [Organisation] must run for the data plane, with sizing |
| Claimed reduction | Per-source reduction percentage assumed, and the resulting [SIEM] volume |
| Services | Onboarding, parser development, day rates |
| Renewal and exit | Cap on renewal increases; export of pipelines, parsers and mappings |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Delivery guarantees and resilience (4.4) | [20%] | Failure tests in the proof of concept |
| Normalisation quality (4.2) | [15%] | Mapping review against sample events |
| Reduction and routing (4.3) | [20%] | Measured reduction with protected classes intact |
| Collection coverage (4.1) | [10%] | Sources onboarded |
| Pipeline security (5) | [15%] | Assurance reports, change audit demo |
| 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 [three]-week proof of concept covering:
- Onboard [five] Appendix A sources, including the identity provider, one cloud audit log and the highest-volume network source, and route them to [SIEM] and [low-cost storage].
- Apply reduction rules and measure delivered volume per source; confirm that every protected event class arrives complete by comparing counts with the source.
- Run [20] existing detection rules on reduced and unreduced data and compare results.
- Stop the [SIEM] destination for [two] hours, then restore it; measure events lost, duplicated and time to drain.
- Inject malformed events and a vendor format change; confirm dead-lettering and alerting.
- Make an unapproved routing change with a test account and confirm it is blocked or logged and alerted.
- Export the pipeline configuration, parsers and mappings in a documented format.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Agree protected classes first: list the event classes that detection, investigation and regulatory retention depend on before any reduction discussion. SDP-RED-02 is the requirement that stops cost savings from becoming blind spots.
- Measure loss, not only savings: the failure tests in step 4 tell you more than any reduction percentage. Pipelines lose data in documented ways when buffers fill.
- Involve detection engineers: they own the field-usage inventory that SDP-RED-03 checks against. See the Detection Engineering Guide.
- Protect the proof of concept: issue time-limited, read-only source credentials and revoke them afterwards.
- Plan the exit: SDP-NOR-04 and the export test decide whether the pipeline makes your next SIEM change easier or locks you in. See the SIEM Migration Guide.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Collection and source health (4.1) | AU-2, AU-12, SI-4 | DE.CM-01, DE.CM-03 |
| Delivery and integrity (4.4, 5) | AU-9 | PR.DS-01 |
| Change control (5) | CM-7 | PR.PS-01 |
| Acquisition (all) | SA-4 | GV.SC-05 |
For the SIEM that sits downstream, use the SIEM RFP Template; if you are buying both, align Appendix A across the two documents.
Standards and references
- OCSF: Open Cybersecurity Schema Framework
- OCSF: Understanding OCSF
- IETF: RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog
- OpenTelemetry: Collector Configuration Best Practices
- NIST: SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (initial public draft)
- MITRE ATT&CK: T1685 Disable or Modify Tools
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Security Data Pipeline Buyer's Guide · Security Data Pipeline Guide · SIEM RFP Template · Log Management and Retention Guide · Security Vendor Evaluation and RFP Guide