The DDoS Buyer's Checklist, and the Claims That Need a Proof of Concept

Procurement disputes in this category are rarely about whether a claim is true. They are about what kind of claim it is — and once that is settled, most of them resolve themselves.

So the checklist below is sorted by how a thing can be established rather than by subject. Three piles: documents, tests, contracts. Anything that fits none of the three is a statement of intent, which is a legitimate thing for a supplier to make and an illegitimate thing for a buyer to score.

At a glance

Appliance	Claim	Why it cannot stand alone	The measurement that replaces it
Zero false positives	Unfalsifiable without a denominator	Transaction completion against a baseline, with sample size
Automatic mitigation	Every product automates something	Operator interventions counted during a live scenario
AI-powered detection	Describes an implementation, not a result	Detection time on a vector the product has not seen
Unlimited protection	No device exceeds the circuit in front of it	Sustained packet rate at 64-byte frames, model-specific
Line-rate performance	Line rate at which frame size, in which direction	The RFC 2544 frame-size matrix
Multi-layer coverage	Coverage is not efficacy under load	Concurrent capacity with two countermeasures active

None of these claims is dishonest. Each is unfalsifiable as stated, and each has a straightforward measurable form that a confident supplier will accept.

Pile one — settled by a document

These need no test. They need a current document, with a date, naming the model quoted.

1. Capacity of the specific model, in packets per second at 64-byte frames, mitigation active, direction stated.
2. New sessions per second, separate from concurrent sessions.
3. The RFC 2544 frame-size matrix, or an explicit statement that it was not measured.
4. Which ceilings are licensed rather than physical, with the cost and lead time of each step.
5. Deployment modes supported, and which are in scope for this quotation.
6. Bypass mechanism: hardware or software, trigger conditions, stated failover time.
7. Which functions require reachability to a supplier-operated service, answered per function.
8. Export formats for telemetry and incident records.
9. Platform generation the figures describe, and the document’s revision date.
10. Licence expiry behaviour and grace period, as a number of days.

Item 9 catches the trap described in reading a datasheet: a public specification page can describe a superseded platform for years, and two suppliers compared across different generations are not being compared at all.

Pile two — settled only by a test

No document can establish these, because they are properties of the product and your traffic together.

11. Legitimate transaction completion under attack, against a measured baseline.
12. False-positive behaviour against the awkward sources: shared addresses, unusual clients, genuine peaks.
13. Sustained packet rate at 64-byte frames with mitigation active, on the quoted model.
14. Concurrent capacity with two countermeasures running, which is always lower than either alone.
15. Behaviour when the supplier path is blocked for the full evaluation window rather than an hour.
16. Time to mitigate, measured from the first attack packet rather than from the alert.
17. Operator interventions required, counted.
18. Recovery behaviour after the attack stops, including late-clearing state.
19. Evidence export performed by your staff, in your format, without supplier assistance.
20. Failover triggered deliberately, with the time measured.

Item 15 has a specific failure mode worth naming: grace periods run on timers, so a short disconnection test passes regardless of the period’s length. The duration is the test.

The full method is in the proof-of-concept methodology and the environment in the test lab guide.

Pile three — settled only in the contract

Things no document proves and no test reveals, because they are about the future.

21. Support renewal percentage, its basis, and a cap for the expected life.
22. Behaviour at end of support term, and at licence expiry, with a grace period in days.
23. Capacity step pricing, fixed in advance.
24. Emergency capacity uplift: whether it exists, who authorises it out of hours, how long it takes.
25. Response commitments by severity, in your time zone and language, with the escalation named.
26. Exit terms: what you keep, what stops, what is returned, over what period.
27. Acceptance criteria from pile two, with the thresholds you set, as a condition of acceptance.
28. Notification obligations if a component’s dependency model changes during the term.

Item 27 is what connects the three piles. A test result that is not a contractual condition is information; the same result written into acceptance is leverage.

The claims that need converting

Six recurring phrases, each unfalsifiable as stated and each with an obvious measurable form. The conversion is not adversarial — a supplier confident in the product will usually propose the measurement themselves.

“Zero false positives.” Over what sample, against what baseline? Replace with transaction completion under attack, with a denominator.

“Automatic mitigation.” Every product automates something. Replace with a count of operator interventions during a live scenario, and the escalation point where automation stops.

“AI-powered.” Describes how something was built, not what it achieves. Replace with detection time against a vector the product has not previously seen, and the false-positive rate that accompanies it.

“Unlimited protection.” No device exceeds the circuit in front of it. Replace with sustained packet rate for the quoted model, and a written division of responsibility with the upstream tier.

“Line-rate performance.” At which frame size, in which direction, with mitigation active? Replace with the frame-size matrix.

“Multi-layer coverage.” Coverage is a feature list. Replace with concurrent capacity — the figure with two countermeasures active, which is the one multi-vector campaigns attack and which appears on no datasheet.

Before signing

Four questions that a good evaluation still frequently misses:

• Which capabilities demonstrated in the evaluation are separately licensed? Ask before the demonstration, not after.
• What happens on the day support lapses? The answers vary across the category by more than most technical differentiators.
• Who answers at 03:00, from where, in which language? With the escalation named rather than described.
• What would make you tell us this product is the wrong fit? A supplier with an honest answer is describing a boundary; one with none is describing a sales position.

The last one is not a trick. Every product in this category is wrong for some estates, and a supplier who can say which ones has told you something no datasheet contains.

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.