Readiness is a visibility problem, and it’s one many organizations don’t know they have.

Most security controls tell you when they’re broken. A bad firewall rule lets traffic through that shouldn’t be there. An expired certificate generates alerts. A misconfigured WAF starts blocking legitimate users and someone notices pretty quickly.

DDoS protection is different. A service can be configured, licensed, and technically available, yet not actually be protecting your traffic. Worse, it often looks exactly the same as a fully functioning service until the moment an attack arrives.

That’s the challenge with DDoS readiness: confirming, continuously, that your traffic is actually flowing through your DDoS protection rather than assuming it is.

Attacks are loud. Protection gaps are silent.

DDoS readiness: why “protected” isn’t the same as “ready”

Ask an organization whether it’s protected from DDoS attacks and the answer is often based on two things:

  • We have a DDoS protection service.
  • It’s been configured.

Both may be true. Neither proves your traffic is actually protected. Readiness isn’t a checkbox. It’s an operational state that needs continuous validation. At Imperva, we view DDoS readiness through three simple questions:

  1. Is traffic being advertised the way you expect?
  2. Are the connections carrying protected traffic healthy?
  3. Is traffic actually arriving where it should?

If you can’t answer all three, you’re making assumptions about your protection posture. That gap is behind many of the reasons DDoS protection fails just when it matters most.

This is different from DDoS testing. An attack simulation shows whether mitigation holds under load on the day you run it. Readiness monitoring answers a different question: whether the path to that mitigation is still intact today, and every day between tests. You need both.

1. Is your traffic being advertised correctly?

Whether you use always-on or on-demand protection, traffic has to be routed through the protection service, usually by advertising your network prefixes to it over BGP. Problems often emerge through gradual drift rather than obvious failures.

A prefix that should be advertised is no longer being announced. A routing change made during another project alters the traffic path. An on-demand configuration hasn’t been tested since the day it was set up. Nothing appears broken, no alarms sound, but traffic may no longer be following the path you think it is. And if an attack happens tomorrow, that’s the worst possible moment to discover it.

How to check: in Imperva DDoS Protection for Networks, the Connectivity dashboard shows the advertisement status of every protected prefix. Received means it reaches Imperva on at least two connections at two different PoPs. Received with issues flags problems such as a prefix advertised to a single PoP, or an on-demand prefix missing its no-export community. Not received means Imperva isn’t getting the advertisement at all. Status changes can be sent to you by email or to your SIEM.

2. Are your connections healthy?

Protecting traffic is only half the equation. Once traffic has been inspected and scrubbed, it still needs to reach your environment. The health of tunnels and connections plays a critical role in that process. A tunnel that’s technically up but suffering from packet loss, latency, or instability isn’t delivering the same outcome as a healthy connection.

Many organizations don’t discover these issues until traffic volumes increase or operational pressure rises. In other words, exactly when they need those connections most.

How to check: with performance monitoring enabled on a GRE tunnel connection, Imperva tracks latency, jitter and packet loss between its PoP and your network. You set the thresholds. When one is crossed, Imperva logs a “connection performance degraded” event and notifies you, with automated ping and traceroute results attached to the event.

3. Is traffic actually arriving?

This is often the most overlooked readiness check; many organizations monitor overall traffic levels and see healthy numbers across the environment. The dashboard looks green, total volume looks normal, but aggregate metrics can hide local problems.

A single point of presence (PoP) may receive significantly less traffic than expected because of routing changes, connection issues, or path degradation. In a global environment, that reduction might represent only a small percentage of total traffic and easily disappear into normal variation.

The dashboard stays green, while users in that region experience a very different reality. Monitoring expected traffic levels at the PoP level helps uncover these issues before they impact users or complicate response during an attack.

How to check: Imperva PoP Traffic Monitoring does exactly this. You set a minimum level of legitimate traffic for each protected network or IP (0–100 Mbps) and a minimum share of traffic for each PoP or group of PoPs. When traffic stays below a threshold for five minutes (the default), Imperva logs a “traffic dropped below threshold” event and notifies you.

Watch for too little, not just too much

Most DDoS detection systems are designed to identify excess: more traffic, more requests, more connections and more anomalies. The assumption is simple: when something goes wrong, volume increases, but readiness issues often present in the opposite way. Traffic stops arriving where expected, advertisements change, routes shift and connections degrade. But nothing spikes, nothing triggers traditional attack alerts.

The only signal is an absence. That’s why DDoS readiness requires a different mindset. Instead of asking:

“Is too much traffic arriving?”

you also need to ask:

“Is the expected traffic still arriving everywhere it should?”

That question can reveal problems long before an attacker does.

What changes when readiness becomes visible?

When readiness becomes visible, three things change. First, readiness becomes an operational consideration rather than an emergency discovery. Teams can identify issues during routine monitoring instead of during an active incident.

Second, on-demand protection becomes easier to validate. If attack-path activation is something you’ll depend on during a crisis, you need confidence that it will work before the crisis arrives. For on-demand ranges, Imperva also raises an event if flow monitoring data stops arriving, because DDoS detection for that range is inactive until it resumes.

Third, incident response improves. When an attack begins, teams aren’t wasting precious time figuring out whether protection was actually in place. They can focus immediately on responding to the threat.

The bottom line

Protection you can’t verify is protection you’re assuming.

That assumption can survive for months or even years because most days are quiet. Every uneventful day reinforces the belief that everything is working as expected. Then an attack arrives and turns that assumption into a test.

At Thales, we believe DDoS readiness is fundamentally a visibility problem. By continuously monitoring advertisement state, connection health, and traffic flow across locations, organizations can answer the critical question before an attacker forces it: is our DDoS protection actually on, everywhere it should be?

Discover how Thales Imperva DDoS Protection helps defend your applications and networks against increasingly sophisticated DDoS attacks while keeping critical services available.

DDoS readiness FAQ

What is DDoS readiness?

DDoS readiness is the verified, ongoing state in which your traffic is actually routed through, delivered by and arriving at your DDoS protection service, as opposed to a service that is only licensed and configured. It rests on three checks: route advertisement, connection health and traffic arrival at each PoP.

How can I tell if my DDoS protection is actually working?

Check three things continuously: that your prefixes are advertised to and received by the provider, that the tunnels or connections back to your network are healthy (latency, jitter, packet loss), and that expected traffic keeps reaching each PoP. Alert on drops, not just spikes.

How is DDoS readiness different from DDoS testing?

DDoS testing simulates an attack to check whether mitigation holds at one point in time. Readiness monitoring checks, every day, that the routing and connections mitigation depends on are still intact. One complements the other.

Does on-demand DDoS protection need readiness checks?

Yes, even more than always-on. On-demand protection only matters if activation works during an attack, so verify that your advertisements are correct (with Imperva, including the no-export community) and that flow monitoring data is still arriving. If it stops, attack detection for that range is inactive.

The post Is Your DDoS Protection Actually On? appeared first on Blog.