DDoS Protection Recommendations: 7 Criteria a Spec Sheet Can't Compare

Establishing the scale of defense you need

Before turning to the criteria themselves, there are three facts in the data that shape every judgment that follows.

First, annual risk is dominated by a small number of extreme events.

The monthly peaks we observed in 2025 averaged 712 Gbps, while the median was only 390 Gbps — a near-twofold gap, which means the distribution is heavily skewed. In other words, it is not that every month sees a 712 Gbps attack, but that extreme values in a few months pull the average up. The gap is even wider at quarterly level: Q3 averaged 1,205 Gbps, Q4 only 204 Gbps.

The procurement implication is this: any protection specification derived from average or routine traffic levels will fail during those few events. And protection only has to fail once for the outage to have happened — customers and regulators will not offset it against the preceding 11 months of stability.

Second, high-intensity attacks are not rare events.

In 10 of the 12 months the monthly peak exceeded 150 Gbps, 4 of those months broke 1 Tbps, and the highest single event reached 2.4 Tbps.

If your internal assessment still rests on "we probably won't see anything above 10 Gbps," that assumption needs updating. Industry statistics for the same period show that more than 96% of attacks are below 10 Gbps — but that distribution describes attacks in aggregate. Once you become the target of a specific attacker, what your organization faces is the most extreme end of the distribution, not the median.

Third, the handling window is shorter than the response time of a manual process.

Industry statistics show that around 90% of attacks in 2025 lasted less than 10 minutes. The largest event we observed for the year (2.4 Tbps) occurred at 20:45 local time and was mitigated by pre-deployed automated rules, with no human intervention at any point.

That ten-minute figure is the shared premise behind several of the criteria below. If any step in the chain of detect → notify → assess → act requires a person, the total time will exceed the length of the event itself.

1. The basis used to calculate absorption capacity matters more than the maximum

The maximum absorption figure on a spec sheet has limited meaning, because it is usually the sum across the vendor's entire network and does not represent the capacity actually available to you.

The question to ask is not "what is the largest attack you have blocked," but these three:

• Is this absorption figure a network-wide total, or the capacity of a single scrubbing node?

• When an attack concentrates on a single node, how is traffic beyond that node's capacity handled?

• Is there an allocation mechanism — that is, what is the resource allocation logic when several customers are attacked at the same time?

Why press to this level of detail? Because Tbps-class attacks are short and concentrated on a single point. If the vendor's network total is 100 Tbps but the node nearest you has only 2 Tbps, then 2 Tbps is what can actually be absorbed.

A reasonable benchmark for specifications: use the capacity of the nodes available in your region, and require that it at least cover the highest monthly figure observed for comparable organizations over the past 12 months, rather than the average.

2. Always-on, or activated on demand

Of all the criteria here, this is the one most easily overlooked and the one with the most direct impact.

DDoS protection deployment models divide broadly into two types:

• Always-on: all traffic passes through the scrubbing infrastructure at all times, and when an attack occurs it is mitigated directly on the existing path.

• On-demand: traffic normally follows its original path, and is only redirected to a scrubbing center once an attack is detected.

On-demand is usually cheaper, which is why it exists. But it carries a structural time cost: detection, decision, routing change (BGP announcement or DNS switch) and route convergence together usually take from several minutes to several tens of minutes to complete.

Put that time back against the data above: 90% of attacks end within ten minutes. This means that in a substantial share of events, by the time traffic redirection is complete the attack is already over — the outage has already happened, and the scrubbing mechanism has only just come into position.

The concentrated attacks we observed (January, March, May and July) are exactly this profile. Take May: across the whole month, only one event, on 7 May, reached 1,200 Gbps, and every other event stayed below 40 Gbps. A single extreme event of this kind demands protection that is always in place; any mechanism requiring manual activation, traffic redirection or cross-system coordination may have a response time longer than the event itself.

What to establish clearly: if the model is on-demand, what is the measured time from detection to scrubbing taking effect? That figure should be written into the contract or SLA, not offered verbally as "very fast."

3. The real scope of automated mitigation and the threshold for human intervention

"We have automated protection" can mean completely different things from one vendor to another. For some it means fully automated assessment and action; for others, automated detection plus human confirmation; for others still, nothing more than automatic alerting.

Three questions worth asking:

• Which attack types can be mitigated fully automatically, and which require human confirmation?

• Are the automated mitigation rules generic or custom? What are the trigger conditions for each?

• For cases that require human intervention, what are the actual on-duty coverage hours and the response time commitment?

The second question deserves more explanation. Our 2.4 Tbps event in July was mitigated by a trigger from a generic high-volume UDP signature rule, not by a custom rule targeting a specific source. That tells us the attack did not use obfuscation sufficient to evade generic signatures — but it also points to a limitation: if an attacker were to use vectors closer to the characteristics of normal traffic, the effectiveness of generic rules would decline.

A complete answer therefore has two parts: the scope covered by generic rules, and how long it takes to create a custom rule when generic rules are not enough. The latter is your real response capability when a targeted attack arrives.

As for on-duty hours, this needs to be checked against when attacks actually occur. Our largest event of the year happened at 20:45. The attacker's choice of a window outside business hours is not a coincidence but a common one — the hours when on-duty staffing is thinnest are exactly the hours when results come most easily. A term such as "response during business hours" in practice excludes the very period in which problems are most likely to arise.

4. Whether the network layer and application layer are provisioned separately

Volumetric attacks (L4) and application-layer attacks (L7, CC) require entirely different techniques: the former depends on absorption and scrubbing capacity, the latter on behavioral analysis and request identification. Some solutions only do the former; some treat the latter as an add-on feature.

A common but mistaken planning sequence is: handle volumetric attacks first, deal with the application layer later.

The problem with that sequence is that it assumes the attacker will arrive in that order. Our observation data does not support the assumption. Viewed as quarterly averages, the network layer surged 122% in Q3 and fell 83% in Q4, while over the same period the application layer declined steadily quarter by quarter — the two show no correspondence. No clear coordination between the two layers was found during this observation period.

More concrete is the record of concurrent activity across both layers: in four of the first half's six months, the two layers peaked on the same day. In those four months, in other words, volumetric attacks and application-layer attacks occurred on the same date.

The procurement implication: both layers need to be provisioned separately. It is not an either/or, and there is no order of precedence. If a solution covers only one layer, your real protection coverage is not the figure the vendor claims.

What to establish clearly: is application-layer protection built into the same solution, or purchased separately? Is it billed separately? When both occur at once, do the two compete for the same resources?

5. Alert aggregation and event triage matter as much as blocking capacity

This criterion appears on almost no spec sheet, yet it determines whether your team can get through a month of high-density attacks.

In October 2025 we observed the highest event density of the year: around 40 events, nearly daily, with intensity concentrated in the 150 to 380 Gbps band and no single event standing out.

The damage from this profile is operational, not technical. All 40 events had to be assessed, logged and tracked, yet none of them on its own met the threshold for escalation. The cumulative effect is alert fatigue, and the practical consequence of alert fatigue is that when a genuinely major event does occur, it gets lost in the noise.

It is worth noting that the intensity band that month was highly concentrated, which fits the random distribution of multiple independent attack sources less well than it fits a single resource conducting a long-running cost probe, possibly to determine the highest sustained intensity that does not trigger a defensive escalation. In other words, this profile may well be deliberately designed.

What to establish clearly:

• Does the platform provide alert aggregation — that is, merging multiple alerts from the same wave into a single event?

• Is there event triage, so that low-intensity events do not trigger the same notification workflow as major ones?

• Can the recipients and escalation levels for alerts be customized?

If every event is handled at the same level, operations capacity can be exhausted within a few weeks. This is not hypothetical; it is something a month with 40 events will verify directly.

6. Billing and contract terms: three things that are easily overlooked

Caps on attack counts or traffic volume:
Some plans set annual caps on scrubbing instances, scrubbing hours or attack traffic, with anything beyond that billed separately. Based on our observation data, a month with 40 events is enough to use up a fair share of many plans' annual allowance in that single month. Before signing, you should model this against the actual event density of the past 12 months rather than the vendor's suggested figure.

How overage is calculated:
If there are overage charges, are they based on attack traffic, scrubbing hours or event count? The amounts these three methods produce can differ substantially in a Tbps-class event.

Flexibility to adjust specifications during the contract term:
The importance of this comes from external trends. Within the single year of 2025, the largest publicly disclosed single attack climbed from 7.3 Tbps to 31.4 Tbps; according to Cloudflare's annual report, the scale of hyper-volumetric attacks grew by more than 700% compared with the end of 2024. This means capacity sized on historically observed values has a shrinking shelf life. A three-year contract with no mechanism for adjusting specifications mid-term may already be insufficient in its second year.

What to establish clearly:
If you need to increase specifications during the contract term, does that mean renegotiating, or are there predefined terms for adding capacity?

7. Incident reports and audit documentation

This is particularly important for government, financial, healthcare and other regulated organizations, yet it is often missed at the procurement stage — only to be discovered when the documentation is needed and cannot be obtained.

What to confirm:

• Are formal incident reports provided for attack events, covering detection time, attack type, peak, mitigation action and outcome?

• What is the turnaround time for producing reports, and how are they delivered?

• Does the platform provide raw records you can export yourself, for internal audit or regulatory review?

Concretely, a usable incident report needs to present at least this level of information: detection time (with time zone), attack type, peak rate (in both bps and pps), mitigation action, the category of rule triggered, and whether there was human intervention. The handling record for the July event described above is exactly this format. Without records at this level, both internal review and external explanation lack any basis.

In addition, if your organization falls under Taiwan's Cyber Security Management Act, or is required to report under the Administration for Cyber Security's incident response guidelines, how quickly you can obtain an incident report directly affects whether reporting can be completed on schedule.

Question checklist for before you request a quote

The seven criteria above, turned into a version you can take straight into a vendor conversation:

On capacity

• Is this absorption figure a network-wide total or single-node capacity? What is the available node capacity in my region?

• When an attack concentrates on a single node and exceeds its capacity, how is the excess traffic handled?

On deployment and response

• Is it always-on or on-demand? If on-demand, what is the measured time from detection to scrubbing taking effect?

• Which attack types can be mitigated fully automatically? Which require human confirmation?

• What are the actual on-duty coverage hours and response time commitments? Is handling outside business hours the same?

• How long does a custom rule take from request to taking effect?

On coverage

• Is application-layer protection built in or purchased separately? Is it billed separately?

• When both layers are attacked at once, do they compete for the same resources?

On operations

• Are alert aggregation and event triage provided? Can notification levels be customized?

On the contract

• Are there caps on scrubbing instances, hours or traffic? How is overage billed?

• What are the terms for increasing specifications during the contract term?

On audit

• What do incident reports contain, how quickly are they produced, and how are they delivered?

• Can raw records be exported by us?

Three common planning mistakes

1. Sizing capacity from averages:
A distribution with a mean of 712 and a median of 390 already shows that annual risk is concentrated in a handful of events. The capacity benchmark should be the monthly maximum.

2. Sizing capacity from the historical maximum alone:
This leads to a different kind of error — resources allocated to the wrong protection layer. The sensible approach is to track both the monthly maximum and the event count, and to review the relative movement of the two on a regular basis, rather than watching a single number.

3. Adjusting configuration according to current activity levels:
June and November 2025 were the only two months of the year with peaks below 150 Gbps, and both low points came immediately after periods of high intensity: June after five months of sustained pressure, November after the diversified campaigns of July through October. After November's low, December rose again to 173 Gbps.

In sequence, these two quiet periods look less like the end of a threat and more like a phase in which the attacker assesses results and regroups resources after an investment. Put another way, the moment that looks most suitable for scaling down is quite likely the moment the other side is preparing the next round.

FAQ

Summary

A spec sheet can answer "how much can this solution block at most," but actual outcomes are decided by a different set of things: whether the defense was already online before the attack began, whether mitigation needs a person to activate it, whether the application layer is provisioned separately, whether the alerting mechanism can hold up through a month with 40 events, and whether the contract leaves room for adjustment.

None of these seven criteria is abstract best practice. Each was derived backwards from 12 months of actual observation. If you are evaluating or renewing a DDoS protection solution, get in touch — we can help you review your current configuration against real attack data.