DDoS Mitigation RFP Template: Questions to Ask Every Vendor

Most DDoS tenders fail in the drafting rather than the evaluation. A questionnaire is written by copying feature lists out of the datasheets of products already known to the team; the responses come back with every box ticked; and the decision falls back to price, or to whichever vendor the evaluators already liked.

The way out is a single drafting rule.

Ask nothing that two competent products would answer the same way. A question every respondent passes has scored nothing and has cost a page of everyone’s time. This document is a set of questions built to fail some good products and pass others, which is the only useful behaviour a tender question has.

At a glance

Appliance	Weak question	Why every vendor passes it	Sharper version
Do you protect against DDoS attacks?	It is the category definition	At what packet rate does each countermeasure still function, at 64-byte frames?
Do you support L3–L7?	Everyone claims the range	Which application protocols are inspected beyond port and rate, and how?
Is detection automatic?	Automation is universal and unqualified	What decides without an operator, and what needs one? Show the escalation path.
Do you have high availability?	Every product has some HA story	Measured failover time, and behaviour on power loss versus software fault.
Can you report on attacks?	All of them produce reports	Export a specific incident in our format, on our schedule, without your staff.

The test for any tender question is whether two competent products could answer it differently. If they could not, the question is scoring nothing and consuming a page.

Section 1 — Detection architecture

The point of this section is to establish where the decision to drop a packet is made, which is the property that most changes behaviour under adverse conditions and is least visible on a datasheet.

1. Where does classification run: on the appliance, on a management server, or on a service the manufacturer operates?
2. Which detection functions, if any, require reachability to a manufacturer-operated service? Name them individually rather than answering for the product as a whole.
3. How are baselines established, how long does baselining take, and what is the behaviour before a baseline exists?
4. Which countermeasures are signature-based, which are threshold-based, and which are behavioural? For each, what happens against a vector not seen before?
5. Are threshold values set by the operator, derived automatically, or both? If both, which wins when they conflict?

A strong answer distinguishes functions rather than answering for the product, and states what degrades rather than claiming nothing does. A weak answer describes the detection as intelligent and moves on.

Section 2 — Dependency and failure behaviour

Everything here is a variation on one question that a demonstration will never surface: what is still true when something the product relies on is not there?

6. If the appliance loses reachability to every manufacturer-operated service, which functions continue, which degrade, and which stop? Answer per function.
7. Is there a licence check that can fail closed? What is the behaviour if a licence cannot be validated during an attack?
8. What is the bypass mechanism — hardware relay, software path, or none — and what is the measured failover time?
9. What is the behaviour on power loss, and is it different from the behaviour on software fault?
10. Where are configuration and telemetry held, and can the appliance be operated with the management plane unreachable?

Question 7 is the one most often left out of tenders and most often regretted. A ceiling reached during an incident is not a support case; it is an outage with a purchase order attached.

Section 3 — Layer coverage and traffic scope

11. For each of L3, L4 and L7, describe the inspection performed. “Supported” is not an answer; describe what is parsed.
12. Which application protocols are inspected beyond port number and rate — and by what mechanism?
13. How is encrypted traffic handled? If inspection requires termination, state where keys live and what that does to the failure domain.
14. Is IPv6 coverage equivalent to IPv4 for every countermeasure? List any that differ.
15. How are fragmented packets, malformed headers and protocol-anomaly traffic handled?

The firewall, IPS, WAF or DDoS appliance distinction matters when reading these answers: a product that answers question 12 by describing a web application firewall is describing a different control with a different failure mode, not a deeper version of this one.

Section 4 — Capacity, and what the figures mean

16. State the capacity of the specific model proposed in packets per second at 64-byte frames, with mitigation active, and say whether the figure is unidirectional or bidirectional.
17. Provide the RFC 2544 frame-size matrix, or state that it was not measured.
18. State new sessions per second, separately from concurrent sessions.
19. Which ceilings are licence-limited rather than hardware-limited? For each, the cost to raise it and the time to apply the change.
20. What is the added latency while mitigating at half the rated capacity?

These five convert a datasheet into a commitment. The reasoning behind each is set out in how to read a datasheet; the questions are reproduced here so the tender does not depend on the reader having followed the argument.

Section 5 — Tenancy, delegation and reporting

Skip this section entirely unless you protect other people’s traffic. It is the section most often included out of completeness and least often relevant.

21. Can protection policies differ per protected customer or business unit on the same hardware, and is the boundary enforced for configuration, statistics and alarms alike?
22. Can an end customer be given visibility of their own traffic without visibility of anyone else’s?
23. What is the reporting output per tenant, and can it be produced without manufacturer involvement?
24. How are policies for a new tenant provisioned, and how long does it take?

Section 6 — Operations and the human path

25. What is the day-to-day operator workload in a quiet month? Describe the tasks, not the hours.
26. What must an operator do during an attack that the product does not do alone?
27. What is the escalation path to the manufacturer, in which languages, under what response commitment, and staffed from where?
28. What training is required before an operator can safely change a policy during an incident?
29. Describe the change-control behaviour: can a policy change be reverted atomically if it makes things worse?

Question 26 separates products more reliably than any capacity question. Every manufacturer claims automation; few will describe in writing the moment when a human has to intervene, and the description is where operational cost lives.

Section 7 — Evidence and integration

30. Which export formats are supported for telemetry and incident records, and are they documented?
31. Can an incident record be exported in a form suitable for a regulator or an insurer, including timestamps whose integrity can be demonstrated?
32. What retention is available on the device itself, independent of any external system?
33. Is packet-level evidence retrievable for a specific incident after the fact?

Under NIS2 and DORA these stop being convenience features. A reporting deadline is met with evidence that already exists, and a product that can only show a live dashboard has not helped with the obligation.

Section 8 — Commercial structure

34. Set out the licensing model: what is perpetual, what is subscription, what is capacity- metered, and what renews.
35. Provide year-one through year-five cost including support renewal, assuming no capacity growth, and again assuming stated growth.
36. What is the price of the next capacity step, and is it a licence change or a hardware change?
37. Is any part of the commercial relationship tied to a transit or upstream service, and can either be renegotiated without the other?
38. What happens to the appliance’s function at the end of a support term?

Question 38 is asked rarely and answered inconsistently across the category. The answers range from “nothing changes except updates stop” to “protection ceases”, and the difference is worth more than several of the technical questions above.

Section 9 — The evidence rule

One instruction, placed at the front of the questionnaire rather than the back:

For each answer, state whether it is (a) documented in current product documentation, (b) demonstrable in a proof of concept, or (c) a statement of intent or roadmap. Answers marked (a) must cite the document and its date.

This single instruction does more work than any individual question. It costs a respondent nothing to comply with, it is unarguable, and it converts a tender response from a set of assertions into a set of assertions with provenance — which is the difference between a document you can evaluate and a document you can only read.

What an RFP cannot settle

A tender establishes what a product claims and what a manufacturer will commit to in writing. It cannot establish false-positive behaviour on your traffic, the packet rate at which a specific countermeasure stops working, or how the thing behaves at 4am with one person awake.

Those are measured, not asked. The proof-of-concept methodology covers the measurement, and the two documents are designed to be used in sequence: the tender narrows the field to two, and the test decides between them.

Technical specification checklist

A clause-by-clause checklist for a DDoS tender. It covers what to require on hardware bypass, packet-rate capacity, application-layer coverage, logging and support, and each line is written so it can be pasted into a specification and answered yes or no.

Company

Work emailSend

Sent by hand, usually within a working day. The address is used for that and for nothing else.

Received. Your request has been passed on.

That did not go through. Check the address and try again.