NDR proposals look alike on paper because every bidder claims east-west visibility, encrypted traffic analytics and ATT&CK coverage, and the differences only show when a sensor drops packets at peak or a technique you care about produces no alert. This template gives you a ready-to-issue request for proposal for a network detection and response (NDR) platform, with numbered requirements written so each answer can be tested in a proof of concept and scored. It covers sensor placement and throughput, cloud and OT traffic, encrypted traffic and decryption, detections, retention and investigation, response integrations, platform security and pricing. It is vendor-neutral and written for SOC leads, network architects, procurement and evaluation panels. Read the NDR Buyer's Guide first for evaluation criteria and the telemetry trade-offs; 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 NDR-SEN-03) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few, or every bidder fails something.
- Bandwidths, retention periods and weights in brackets are illustrative. Measure your own peak and sustained throughput per segment for at least two weeks, including backup windows, before issue.
- Complete Appendix A (network segments) yourself. Bidders must design and price sensors against it, which makes quotes comparable.
- Issue sections 1 to 8 and Appendix A 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 an NDR platform and associated services to monitor network traffic across on-premises, cloud and [OT] environments, detect attacker activity, support investigation and trigger containment through existing controls.
- In scope: physical and virtual sensors for the segments in Appendix A; cloud traffic and flow log ingestion; detection content; metadata and packet retention; investigation workflow; integration with [SIEM], [SOAR], [EDR], [firewalls] and [NAC].
- Out of scope: [24/7 monitoring, provided by our SOC or MDR]; [TLS inspection proxies, separate procurement]; [network packet broker hardware, if procured separately].
- Contract term: [three] years, with an option to extend by [two].
- Drivers: [IDS end of support]; [lateral movement found in an incident or test]; [unmanaged devices and OT with no agent coverage]; [regulatory monitoring requirements].
2. Current state
| Item | [Organisation] value |
|---|---|
| Current network monitoring | [IDS, flow collector or none; product and contract end date] |
| Sites and data centres | [number] sites, [number] data centres, [number] cloud accounts or subscriptions |
| Tap, SPAN and packet broker estate | [available capture points per site; packet broker yes/no] |
| Peak throughput to monitor | [Gbps] aggregate, largest single link [Gbps] |
| Proportion of encrypted traffic | [estimate]; TLS inspection in place at [egress only / none] |
| Unmanaged and OT assets | [number] devices without EDR; OT protocols in use [list] |
| SOC model | [in house / co-managed / MDR], [number] analysts |
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 provide a sensor bill of materials for Appendix A.
4. Functional requirements
4.1 Sensors and coverage
| ID | Requirement | Type |
|---|---|---|
| NDR-SEN-01 | Propose a sensor design covering every segment in Appendix A, with sensor model or virtual size, capture point (tap, SPAN, packet broker, virtual switch) and any segment not covered. | M |
| NDR-SEN-02 | State tested sustained and peak throughput per sensor with all detections enabled, and how packet loss is measured and reported in the console. | M |
| NDR-SEN-03 | Alerts within [15 minutes] when a sensor stops receiving traffic, loses packets above [threshold] or falls behind on processing. | M |
| NDR-SEN-04 | Sensors are passive: no traffic injected into monitored segments, and OT sensors never poll or actively scan devices unless explicitly enabled. | M |
| NDR-SEN-05 | Parses the OT protocols listed in section 2 (for example Modbus TCP, DNP3, EtherNet/IP, S7comm, BACnet/IP) to function-code level and builds an asset inventory from traffic. | S |
| NDR-SEN-06 | Central management of sensor configuration, software updates and health, with staged rollout and rollback. | S |
See the Network Segmentation Guide and the OT Security Guide.
4.2 Cloud and container traffic
| ID | Requirement | Type |
|---|---|---|
| NDR-CLD-01 | For each cloud in Appendix A, state whether the platform uses provider traffic mirroring, flow logs, virtual sensors or agents, and what detections are lost when only flow logs are available. | M |
| NDR-CLD-02 | Estimate the provider-side cost of the proposed cloud design (mirroring sessions, data transfer, flow log storage) at Appendix A volumes. | S |
| NDR-CLD-03 | Monitors traffic between Kubernetes pods and services, and maps flows to namespaces, workloads and service accounts. | S |
| NDR-CLD-04 | Correlates cloud network activity with cloud control plane identities (roles, managed identities, service accounts) where the source data allows. | S |
See the Cloud Network Security Guide.
4.3 Encrypted traffic and decryption
| ID | Requirement | Type |
|---|---|---|
| NDR-ENC-01 | Describe detections that work without decryption: handshake and certificate analysis, client and server fingerprints, timing, size and periodicity, and which of these still work with TLS 1.3, where certificates are sent encrypted. | S |
| NDR-ENC-02 | If decryption is offered, state the method (key import, integration with a TLS inspection device, or none), supported protocol versions, and how decrypted content is protected, retained and access-controlled. | I |
| NDR-ENC-03 | Flags weak or anomalous encryption: deprecated protocol versions, self-signed or newly issued certificates on internal services, and unexpected encrypted protocols on non-standard ports. | S |
TLS 1.3 (RFC 8446) encrypts all handshake messages after ServerHello and removed static RSA key exchange, so passive decryption with an imported server key no longer works for it. See the TLS Inspection Guide.
4.4 Detection content
| ID | Requirement | Type |
|---|---|---|
| NDR-DET-01 | Provides maintained detections mapped to ATT&CK techniques, with update cadence and the traffic each detection needs (flow, metadata or packets). | M |
| NDR-DET-02 | Detects, at minimum: Network Service Discovery (T1046), lateral movement over SMB/Windows Admin Shares (T1021.002), Kerberoasting (T1558.003), command and control over web protocols (T1071.001) and DNS (T1071.004), Protocol Tunneling (T1572), Adversary-in-the-Middle (T1557) and Exfiltration Over Alternative Protocol (T1048). | S |
| NDR-DET-03 | Supports custom detections, signatures in an open rule format (for example Suricata-compatible rules), and imports threat intelligence indicators with retroactive matching against retained metadata. | S |
| NDR-DET-04 | Explains each behavioural alert with the evidence and baseline that triggered it, and states the learning period before behavioural detections are reliable. | S |
| NDR-DET-05 | Detects anomalous use of non-human identities on the wire: service accounts authenticating from new hosts, machine-to-machine API traffic to new destinations, and cleartext credentials in protocols such as LDAP, HTTP Basic or FTP. | S |
| NDR-DET-06 | Supports suppression and tuning per segment, with an audit trail of who tuned what. | S |
See the Lateral Movement Guide and the Service Account Security Guide.
4.5 Retention and investigation
| ID | Requirement | Type |
|---|---|---|
| NDR-RET-01 | Retains flow records for [180 days], enriched metadata for [90 days] and packets for [7 days] or alert-triggered capture, at Appendix A volumes, with per-segment settings. | M |
| NDR-RET-02 | Provides search across retained metadata with entity pivoting (host, user, certificate, domain), and states query time for a [30]-day search. | S |
| NDR-RET-03 | Exports packets in PCAP format and metadata in a documented schema, on request and at exit. | M |
| NDR-RET-04 | Supports masking or exclusion of defined traffic (for example health or HR systems) to meet data protection requirements. | S |
See the Zeek Network Monitoring Guide and the Arkime Full Packet Capture Guide for what metadata and packet capture look like in practice.
4.6 Response and integrations
| ID | Requirement | Type |
|---|---|---|
| NDR-RSP-01 | Sends alerts with evidence to [SIEM] and [SOAR] through a documented API or syslog in a documented schema, and accepts status updates back. | M |
| NDR-RSP-02 | Triggers containment through [firewalls], [EDR] and [NAC] (block, isolate, quarantine), with per-action approval settings, automatic expiry and an audit trail. | S |
| NDR-RSP-03 | Enriches alerts with asset and identity context from [CMDB], [identity provider] and [EDR]. | S |
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| NDR-SEC-01 | Console and API access through [Organisation] SSO with phishing-resistant MFA and role-based access, including roles that cannot view packet payloads. | M |
| NDR-SEC-02 | Credentials the platform holds for firewalls, EDR, NAC and cloud APIs are stored encrypted, scoped to the minimum actions, rotatable, and short-lived or federated where the target supports it. | M |
| NDR-SEC-03 | Logs all administrative actions, searches of packet data, exports and response actions, retained for [period] and exportable to [SIEM]. | M |
| NDR-SEC-04 | Sensor management interfaces are separated from monitoring interfaces; sensors are hardened, signed updates only, with a published vulnerability disclosure process. | M |
| NDR-SEC-05 | Current independent assurance report and completed [SIG or CAIQ]; list sub-processors, data locations and whether packet data leaves [Organisation] premises. | M |
| NDR-NF-01 | Availability commitment for cloud components of [percentage]; sensor behaviour when the cloud console is unreachable (buffer, keep detecting, drop). | S |
The platform's response credentials can change firewall rules and isolate hosts: treat them as privileged non-human identities. See the Secrets Management Guide.
6. Services and support
- Deployment: plan to install sensors for Appendix A within [months], with acceptance criteria per segment (traffic seen, packet loss below threshold, detections firing in test).
- Tuning: effort and duration of the initial tuning period and who performs it.
- Content updates: cadence, change notes and how custom detections survive updates.
- Support: tiers, hours and response targets by severity, including hardware replacement times per site.
- References: [two or three] customers of similar size, sector or OT footprint.
7. Pricing
| Cost element | What to state |
|---|---|
| Licence metric | Throughput (Gbps), monitored IP addresses or devices, sensors, or users; exactly how it is measured |
| Hardware | Sensor appliances, refresh cycle, support and replacement |
| Volume tiers | Price at [current], [current plus 50%] and [double] throughput |
| Retention | Cost of the section 4.5 retention targets and of doubling them |
| Cloud | Platform charges for cloud monitoring, plus estimated provider charges from NDR-CLD-02 |
| Add-ons | OT module, decryption, packet capture storage, response integrations, managed service |
| Renewal and exit | Cap on renewal increases; export charges |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Coverage and sensor performance (4.1, 4.2) | [25%] | Design against Appendix A, packet loss measured at peak |
| Detection quality (4.3, 4.4) | [25%] | Proof of concept emulation results |
| Investigation and retention (4.5) | [15%] | Timed investigation |
| Response and integration (4.6) | [10%] | Demonstration |
| Platform security (5) | [10%] | Assurance reports, questionnaire |
| Cost over the term (7) | [15%] | 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 covering:
- Deploy sensors on [two] on-premises segments, including one east-west data centre segment, and one cloud network; report packet loss during the busiest hour.
- Run an agreed set of [15 to 20] emulated ATT&CK techniques from NDR-DET-02 in a test environment, using an authorised emulation tool, and record which alert, how fast and with what evidence.
- Repeat three of those techniques over TLS 1.3 without decryption and record what is still detected.
- Run a timed investigation from one alert to a scoped list of affected hosts and identities, using retained metadata only.
- Trigger one containment action through a test firewall or EDR tenant with approval, then confirm expiry and the audit entry.
- Stop traffic to one sensor and measure time to the health alert.
- Export one day of metadata and one alert's packets.
Appendix A: network segments
| Segment | Type | Capture point | Peak / sustained | Retention |
|---|---|---|---|---|
| [Internet egress, site 1] | North-south | [Tap / SPAN / broker] | [Gbps / Gbps] | [flow / metadata / packets] |
| [Data centre core] | East-west | [ ] | [ ] | [ ] |
| [Cloud VPC or VNet] | Cloud | [Mirroring / flow logs / virtual sensor] | [ ] | [ ] |
| [OT cell or plant network] | OT | [Passive tap] | [ ] | [ ] |
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Map capture points first: NDR value depends on where sensors can see. If you have no tap or SPAN capacity in the data centre core, budget for it or the east-west requirement cannot be met by anyone.
- Score detections on your traffic: coverage maps show detections that exist, not ones that fire. Weight the emulation results in the proof of concept above slideware, and run emulation only with written authorisation and in agreed windows.
- Agree privacy rules before the proof of concept: packets can contain personal data and credentials. Involve your data protection officer, set retention and access roles, and use NDR-RET-04 to exclude sensitive systems.
- Protect the platform: issue bidders time-limited, least-privilege proof of concept accounts and integration credentials, revoke them afterwards, and keep response actions in approval mode until tuned.
- Plan the exit at entry: NDR-RET-03 and the hardware terms decide what replacing the platform costs. See the NDR Guide for operating the platform after award.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Sensors, cloud and OT coverage (4.1, 4.2) | SI-4, SI-4(4), AU-12 | DE.CM-01 |
| Encrypted traffic and detection (4.3, 4.4) | SI-4(2), SI-4(4) | DE.CM-01, DE.AE-02 |
| Response integrations (4.6) | IR-4, IR-4(1), SC-7 | RS.MI-01 |
| Acquisition (all) | SA-4 | GV.SC-05 |
In MITRE D3FEND, the countermeasure family this platform delivers is Network Traffic Analysis (D3-NTA).
Standards and references
- NIST: SP 800-94 Guide to Intrusion Detection and Prevention Systems
- MITRE D3FEND: Network Traffic Analysis
- MITRE ATT&CK: Network Traffic Flow (DC0078)
- CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
- IETF: RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: NDR Buyer's Guide · NDR Guide · Security Vendor Evaluation and RFP Guide · SIEM RFP Template · EDR and XDR RFP Template