How to Run a Recurring DDoS Testing Program

A practical guide to setting the cadence, onboarding the SOC, closing findings, and working with your testing vendor between engagements

Running DDoS testing as a recurring program means linking every planned simulation to remediation, retesting, SOC training, and the next material change in the environment. Unlike a one-off project, it does not end when the report is delivered. Each result becomes the baseline for the next cycle, so the organization can verify that fixes work and that new endpoints, routes, WAF rules, or providers have not reopened previously closed gaps.

Annual testing still gives a valuable point-in-time assessment, and for many organizations it is the regulatory baseline. The limitation is that environments rarely stay unchanged for a year. A recurring program adds event-driven validation after significant deployments, architectural changes, incidents, or completed remediation: a continuous validation cycle, not continuous attack traffic. For SOC managers, the point is not a permanent testing workload but a predictable one – which assets are tested, who monitors each control, who can stop the simulation, who owns each finding, and when the fixes will be retested.

Key Takeaways

• Treat recurring testing as a closed loop.
  Each simulation should lead to owned remediation, verification of the fixes, and an updated baseline for the next cycle.
• Regulation already assumes a program.
  DORA requires a testing programme, not a test, and PCI DSS pairs an annual baseline with an after-any-significant-change trigger.
• Set the cadence around change and risk.
  Major infrastructure changes, incidents, and completed remediation may justify testing before the next calendar date.
• Prepare the SOC for specific decisions.
  Monitoring responsibilities, escalation paths, and stop authority should be clear before test traffic begins.
• Run a delta checklist, not the full plan.
  Establish the baseline once, then reconfirm before each cycle only what can have changed since the last test.

A Recurring DDoS Program Is a Closed Loop, Not a Repeated Booking

Scheduling a test every year makes the activity repeatable; it does not create a recurring validation program. The distinction is what happens between the test dates, and what can trigger a test before the next one arrives.

A one-off test begins with a defined question, produces findings, and ends with a report. An annual test repeats that assessment and can show how the environment changed over time. A recurring program connects the assessments through a shared operating process: findings are assigned, controls hardened, fixes retested, and material infrastructure changes reviewed for whether further validation is required.

Testing model	How it works	What happens after the test
One-off test	A simulation is commissioned for a specific decision, change, or assurance requirement	Findings are reported, but remediation and retesting may require a separate project
Annual test	A broader assessment is repeated on a fixed yearly schedule	Results can be compared over time, although relevant changes may occur between test dates
Recurring program	Scheduled and event-driven tests operate within the same validation cycle	Findings, remediation, retesting, training and future scope remain connected

Some arrangements reserve several controlled test windows in advance, using some for broader simulations and holding others for targeted retesting. Reserving the days is not running a program; they become one only when they share the same scope, governance, findings, and improvement process. Reserved windows should not be confused with DDoS Day, Red Button’s conference series, which is an industry event rather than a testing model.

The calendar provides structure but does not control the program. A new public API, a CDN or WAF change, a cloud migration, a material incident, or completed remediation can all create a reason to test sooner. Red Button’s analysis of annual versus continuous DDoS simulation explains how configuration drift makes an earlier result less representative of the environment running today.

Regulation Already Assumes a Program, Not a Test

For a SOC manager or procurement lead justifying a recurring line item, the strongest argument is not that continuous validation is better practice. It is that the applicable regulation already describes the obligation as a program, and pairs a fixed interval with a change-based trigger.

Under the EU’s Digital Operational Resilience Act, Article 24(1) requires financial entities to “establish, maintain and review a sound and comprehensive digital operational resilience testing programme.” The regulation’s own noun is programme, not test. Article 24(6) sets a baseline of appropriate tests on all ICT systems supporting critical or important functions at least yearly; Article 24(4) requires independent testers, and Article 25(1) names the testing types in scope, including scenario-based tests, performance testing and end-to-end testing.

Article 26 adds a different obligation for entities identified by their competent authority: threat-led penetration testing at least every three years, on live production systems. Two cadences covering two scopes cannot sensibly run as a single annual project, which is itself an argument for an operating program.

The pattern is not unique to DORA. PCI DSS v4.0.1 requires penetration testing at least once every 12 months and after any significant infrastructure or application change, and NIS2 Article 21 requires policies to assess the effectiveness of risk-management measures. That “after any significant change” trigger is the compliance-language version of configuration drift. None of these instruments mandates DDoS simulation by name, and a page claiming otherwise overstates the position – but a single dated test is not what a regulator means by a testing program.

Sources: DORA (Regulation (EU) 2022/2554) Articles 24, 25 and 26; PCI DSS v4.0.1 Requirement 11.4; NIS2 Directive Article 21. These requirements are revised periodically, so confirm the current text before relying on it in a scoping document.

Build the Cadence Around Change, Risk and Remediation

A recurring cadence combines planned test dates with event-driven validation: fixed dates prevent long gaps in assurance, and event-driven tests respond to changes that make the last result less reliable. The right frequency depends on service criticality, rate of change, unresolved findings, and external assurance requirements, so most programs settle on a scheduled baseline test supported by shorter targeted validations. Red Button’s own DDoS 360 program illustrates the range: a typical mid-range package includes about four test cycles a year, though the exact number – like the timing – is set per customer, laid out in the annual roadmap, reviewed every quarter, and reopened whenever something changes. Agree on the cadence at the start and review it at the end of each cycle.

A practical validation cycle has five stages.

• Establish the baseline and scope.
  Map the internet-facing services, traffic paths, protection layers, and normal operating metrics the program will validate.
• Schedule and authorize the test.
  Define targets, exclusions, scenarios, traffic limits, monitoring responsibilities, and stop conditions, and confirm the test complies with the current requirements of the relevant providers, including the AWS DDoS Simulation Testing Policy or Azure DDoS Protection simulation-testing guidance where applicable. Coordinate with any ISP, CDN, or scrubbing provider in the traffic path too, so the test is not blocked before it reaches the control it is meant to validate – and settle responsibility for the findings in the same conversation: who receives the report, who prioritizes remediation, who implements each change, and how a retest is requested.
• Simulate and observe.
  Run the agreed scenarios under live oversight, measuring whether each control detects and mitigates the traffic, what reaches the protected service, and how legitimate users are affected.
• Prioritize and remediate.
  Assign each finding to an owner, agree on the required change, and set a target date.
• Retest and update the response process.
  Re-run the relevant scenarios to verify the fix works, then update the baseline and the SOC playbook so the next cycle starts with the evidence already gathered.

These five stages are the availability-scoped version of what the industry now calls Continuous Threat Exposure Management: scoping, discovery, prioritization, validation, and mobilization. Naming it that way helps when the cycle has to be explained to a board that already recognizes the framework, because it positions DDoS testing as part of an exposure-management practice rather than a standalone purchase. It is also the principle behind Red Button’s DDoS 360 continuous resilience cycle, where testing is followed by hardening and retesting rather than treated as a completed annual task.

Scheduled and Event-Driven Testing Work Together

A scheduled test provides governance and protects the program from indefinite postponement. It should not stop the organization testing sooner when the environment changes, and not every trigger needs a full simulation – a targeted retest is often enough when the question concerns one remediated control or one change in the traffic path.

Trigger	Appropriate response
Planned baseline date	Run the broader set of scenarios agreed for the recurring cycle
New CDN, WAF, cloud route or mitigation provider	Validate the changed protection path and any affected dependencies
New public API, application or service	Add the asset to scope and test the relevant network- or application-layer scenarios
Important finding remediated	Re-run the scenario that exposed the weakness
Material DDoS incident	Recreate the relevant conditions after containment to verify the improved defenses

The governing question is not “When did we last test?” but “What has changed since the evidence we currently rely on was produced?” If the answer includes a new exposure, an altered control or a significant remediation, waiting for the next annual date preserves the schedule while letting the assurance go stale.

Onboard the SOC for the Decisions It Will Actually Make

SOC onboarding should prepare the team to monitor the exercise, tell expected test activity from unintended impact, follow the escalation path, and make or support a stop decision. It should not begin with a platform demonstration; a testing interface is useful only once responsibilities, telemetry and decision authority are clear.

The UK NCSC’s guidance on DoS testing and monitoring puts it in one line: “Thinking you are well prepared to defend against denial of service attacks is not the same as knowing.” It recommends testing the ability to defend against both network-layer and application-layer attacks, and maintaining the monitoring needed to spot an attack as it begins and analyze it while it is underway.

Different functions need different preparation, and treating the SOC as one audience is the common mistake. Red Button’s breakdown of whether your teams are trained to stop a DDoS attack splits it four ways: NOC and SOC need fast identification and escalation, security needs depth on which control answers which vector, network needs equipment-level procedures, and management needs enough to coordinate a crisis.

Before the first scheduled test, assign named roles for monitoring security alerts, service health, and legitimate-user impact, and identify who is authorized to stop the test, who coordinates with the vendors, and who documents what happened. Then rehearse the workflow before live traffic is generated: a short walkthrough confirms the SOC knows which dashboards to watch, how to reach the NOC and application owners, when to escalate, and whether an out-of-band channel exists if the environment becomes unreliable.

Put the SOC in the Room

The most useful operational decision in a recurring program costs nothing: have the SOC watching its own consoles while the simulation runs, rather than reading a report two weeks later. This is the purple-team principle applied to availability – the defenders see how the attack appears in their own telemetry at the moment the tester knows exactly what was sent, so a detection gap is identified and explained in the same conversation. Participation can then grow across cycles, from observing the telemetry to running detection, escalation, and documentation through the organization’s real procedures.

Announced or Unannounced?

Programs differ on whether the SOC is told a test is coming, and the choice should be deliberate. An announced test validates infrastructure and process together under controlled conditions, and it is the sensible option whenever production is in scope, and a stop decision may be needed within seconds. An unannounced exercise measures something narrower but harder to rehearse: how the team performs when it does not know the traffic is a simulation. Agree which model applies before the program begins, and if both are used, who is told in advance.

Red Button runs both. It has offered unannounced simulations since 2020, under a written methodology, and the choice is less about customer readiness than about what is practical: someone on the client side always has to be informed and authorized to stop the test, and cloud and CDN providers require notification above certain traffic volumes, so the simulation still has to be designed inside limits the provider has already authorized. The surprise, in other words, is for the defending team – not for the providers in the traffic path.

Why a Playbook Matters More Than Any Platform Guide

The artifact that makes a team independent is a playbook: a document describing the scenarios the organization can realistically face and the specific actions to take in each case. Who identifies. Who escalates. Who is authorized to call the scrubbing provider, and at what hour. What is said to customers. What “over” looks like, and who declares it.

A playbook is also what a recurring program keeps updating. Each cycle should end with at least one change to it – a detection that was too slow, an escalation path with a gap, a contact who has left. That is the difference between a team trained once and a team currently ready. Red Button’s resource library includes a white paper on DDoS education, playbooks and wargames, and the knowledge base carries the task-level material a SOC needs between tests.

How Much Training Does the SOC Need?

There is no useful universal number of training hours. It depends on whether the team will operate a self-service platform, participate in an expert-led test, or take responsibility only for detection and response. A self-service platform puts more planning, execution, and interpretation on the internal team; in a managed engagement, the provider handles the attack while the SOC observes the defenses and exercises its response.

Training is sufficient when the assigned members can safely perform the tasks in their scope: recognize the simulation in telemetry, follow the communication plan, assess operational impact, use the stop procedure, and say when expert help is required. Red Button’s DDoS education and training combines hands-on exercises with product-specific knowledge, because a team needs to understand not only DDoS attacks in general but how its own controls should behave.

Red Button’s own training component runs in three parts: eLearning for NOC and SOC staff, tailored to the customer’s own architecture on the higher-tier packages; war games, either a live-fire surprise attack run after a few normal simulations or a tabletop exercise for management; and a two-level course – a Basics 101 delivered online and an Advanced 102 delivered on-site and customized to the organization’s network and products – combining theory with hands-on labs. The audience spans SOC and NOC analysts and their team leads, security and network engineers, and management for the tabletop sessions. There is no fixed duration or cadence: most programs run one to two training activities per service year, planned into the annual roadmap and adjusted to the package, the team’s starting point, and what the tests have exposed.

The Delta Checklist: What to Confirm Before Every Scheduled Test

A first DDoS test needs a full plan. A recurring test needs a delta. Establish a stable baseline once – architecture, roles, authorization, reporting, and risk tolerances – then, before each cycle, reconfirm only what can have changed since the last one. That second list is the delta checklist, and it is the artifact most recurring testing arrangements are missing.

Established once, at program onboarding	Reconfirmed before every scheduled test (the delta checklist)
Architecture and protection-stack map	New or changed FQDNs, public APIs, origins and traffic routes since the last test
Protection vendors and product set	Any change of CDN, WAF, scrubbing or cloud provider, or of the plan or tier within one
Core roles, escalation path and stop authority	Named participants, live contacts, on-call roster and current availability
Provider authorization and coordination requirements	Approvals or notifications required for this test, and whether any provider policy has changed
Reporting and remediation workflow	Findings from the last cycle marked fixed but not yet retested
General risk and impact tolerances	Current targets, exclusions, scenarios, stop thresholds and acceptable degradation
Typical attack profile	Botnet size, geography and maximum volume per vector against current provider caps for this cycle
Test scheduling defaults	Test date and window, and whether this cycle runs in production or non-production

The first question before a recurring test is therefore: what is different from the environment we validated last time? A new endpoint, a changed WAF rule, or a temporary routing exception may require a change of scope or scenario. If nothing material has changed, the test can focus instead on confirming that previously validated protections still hold and that the team can repeat the response process under pressure.

It should also confirm the purpose of the exercise, because a broad scheduled simulation, a targeted remediation retest, and a SOC readiness exercise need different scenarios and different success criteria. Red Button’s full DDoS testing checklist covers the first-engagement version in more detail; the delta checklist above is its recurring-cycle counterpart.

The client time commitment follows the same logic. Red Button’s DDoS testing FAQ breaks a first managed test down to roughly five hours in total – a one-hour pre-test interview, a three-hour live session, and a one-hour readout. A recurring cycle takes less, because the baseline is set once and only the delta above is reconfirmed.

The Work Between Tests Determines Whether the Program Improves

The period between tests is not downtime. It is when findings become changes and the next test is prepared. If the vendor delivers a report and disappears until the following date, the organization has recurring engagements but not a continuous validation cycle.

Each finding should be assigned to an owner and connected to a specific action – adjusting a WAF threshold, closing direct-to-origin exposure, changing a routing policy, extending protection to an overlooked API, correcting an escalation procedure. Evidence of implementation is not evidence that the control now works: a screenshot or a closed ticket confirms somebody made a change, while a targeted retest confirms the change produces the expected result under the scenario that exposed the weakness. Important findings should stay open at program level until their remediation has been tested.

That distinction showed up clearly for a healthcare-communications provider that scored 2.0 on its first test. Of eleven scenarios, five were not mitigated at all, the scrubbing centre forwarded only a fraction of the traffic its links could carry, and not one rate-limit rule fired during the whole test. The organization replaced its scrubbing provider and web application firewall, wrote and tuned rate-limit rules, and applied best-practice configuration. The retest scored 5.5, with nine of ten scenarios mitigated – including the application-layer flood, stopped by the very rules that had failed to fire the first time. The second cycle also caught two problems the first could not have: a firewall feature whose false positives diverted traffic to the wrong data centre, and which generated enough log volume to take down the customer’s own monitoring server.

The next cycle should also absorb what the team learned. A delayed alert means the monitoring logic needs to change; a SOC that did not know who could call the scrubbing provider means the playbook needs updating; a supposedly protected service that followed a different traffic path means the architecture baseline and future scope need to reflect it.

What Ongoing Support Should a DDoS Testing Vendor Provide?

Support between engagements varies by service model. A report-only engagement may include a results readout and clarification of the findings. A broader engagement may add remediation guidance, technical discussions with the client’s teams, and a targeted retest. A managed resilience program may also include architecture hardening, recurring training, updated scenarios and pre-aligned incident-response support.

Before entering or renewing a recurring arrangement, confirm:

• whether the vendor will work directly with the teams implementing the fixes;
• whether targeted retesting is included or separately scoped;
• who answers technical questions between test windows, and how quickly;
• whether the SOC playbook and training are updated as the environment changes;
• what support is available if a real DDoS attack occurs between scheduled tests.

The answers determine whether the vendor is providing repeated simulations or helping to operate an improvement program. Red Button’s own DDoS 360 program illustrates what a fuller answer looks like: it combines a bucket of hours – covering assessment, gap analysis, design, vendor proof-of-concepts, playbook work, training, configuration recommendations and hardening – with fixed commitments, including a named technical account manager as the single point of contact, a set number of tests, a recurring status and audit report showing the current DRS and forward roadmap, a quarterly roadmap review and an annual audit. Configuration review after a protection-vendor change and advisory input when a new attack vector is disclosed are both handled as normal work inside the program rather than as separate triggers, and incident response runs through a written procedure with two named engineers available 24/7 and published response times, covering a live attack, mitigation that is not working, false positives blocking real users, and forensics afterward.

Measure Increasing Assurance, Not Increasing Traffic

Success is not whether the next test generates more gigabits or covers more vectors. Volume matters only when it helps answer a relevant question about the environment. Three kinds of progress are worth tracking separately.

• Technical progress includes faster detection and mitigation, lower impact on legitimate users, fewer scenarios reaching the origin, and improved protection of critical assets.
• Operational progress includes clearer escalation, correct use of the response playbook, faster engagement of mitigation providers, and better decisions about when to continue or stop a scenario.
• Program progress includes findings closed and verified, shorter remediation times, fewer repeated weaknesses, and measurable improvement across successive cycles.

Tracking the DDoS Resiliency Score Across Cycles

A recurring program needs one figure that is genuinely comparable between cycles, and traffic volume is not it. The DDoS Resiliency Score, developed by Red Button, grades resilience on a scale of 1.0 to 7.0. The scale is exponential rather than linear, so each step represents a substantially larger attack the organization can withstand, and a move from 3.0 to 4.0 is a larger change than it appears. The average first-test score across industries is 3.0, and Red Button recommends a baseline of 4.5 to 5.0 for financial services and gaming. Red Button does not publish a single expected movement figure – it depends too much on what the first test found – but the two-cycle example earlier in this guide, where one organization moved from 2.0 to 5.5 after a single remediation cycle, is a more honest picture than an average would be.

Across cycles, the score does two things a report cannot: it shows the SOC whether remediation is producing cumulative improvement or the same weaknesses keep recurring, and it gives a CISO a figure a board can compare year on year. Red Button’s guide to reading a DDoS test report beyond pass/fail sets out how it is derived and tracked. A program is working when previously successful attack paths no longer succeed, and the SOC responds with less uncertainty than in the previous cycle.

Make the Last Test the Starting Point for the Next One

A DDoS test produces evidence about a defined environment at a defined moment. A recurring program preserves the value of that evidence by connecting it to remediation, retesting, SOC readiness, and the changes that follow. If the next test starts without the findings, decisions, and lessons of the previous one, the organization is repeating an exercise rather than operating a resilience program.

Most of what a recurring program produces lives with your team rather than in a report: the playbook, the delta checklist, the remediation records and the training material. Red Button’s knowledge base and resource library hold the reference material a SOC uses between cycles, and DDoS testing explains how an individual test is run.

Frequently Asked Questions

What is a DDoS days program, and is it the same as recurring DDoS testing?

Two different things are often merged under this phrase. DDoS Day is Red Button’s conference series, held in Israel, Austria, the UK, and Singapore – an industry event, not a testing model. Separately, some buyers and vendors use “testing days” for an arrangement in which several controlled test windows are reserved in advance. Reserving several dates becomes a program only when the tests share scope, governance, findings, and a defined remediation process.

Can DDoS testing be scheduled as a recurring service?

Yes. An organization can schedule recurring DDoS tests rather than commission each simulation as a separate project. The arrangement should define the planned test windows, the preparation required before each one, how scope changes are handled, and whether additional event-driven or remediation tests are available. Scheduling provides continuity, but the program should stay flexible enough to respond to material changes.

Does recurring DDoS testing mean generating attack traffic continuously?

No. Recurring testing maintains a continuous validation process, not continuous attack traffic. Simulations still take place during authorized and controlled test windows. The continuity comes from tracking findings, implementing remediation, retesting fixes, updating the SOC playbook, and deciding whether infrastructure changes require validation before the next scheduled exercise.

Does DORA or PCI DSS require recurring DDoS testing?

Neither names DDoS simulation as a specific obligation. DORA Article 24 requires financial entities to maintain a digital operational resilience testing programme, with appropriate tests on critical systems at least yearly, and Article 26 adds threat-led penetration testing at least every three years for entities identified by their competent authority. PCI DSS v4.0.1 requires penetration testing at least once every 12 months and after any significant change. That common structure – a fixed interval plus a change-based trigger, described as a programme – is the one a recurring DDoS testing cycle follows.

How much training does a SOC team need for recurring DDoS testing?

It depends on the SOC’s role. A team operating a self-service platform needs more knowledge of scope, scenarios, safety controls, and result interpretation than a team participating in an expert-led managed test. Training is sufficient when team members can monitor the exercise, follow the escalation path, assess unintended impact, use the stop procedure, and recognize when expert assistance is required.

What support should a DDoS testing vendor provide between engagements?

Depending on the agreement, ongoing support may include explaining findings, working with technical teams on remediation, reviewing evidence of implementation, running targeted retests, updating scenarios, and helping maintain the response playbook. Some managed programs also provide pre-aligned incident-response support. Confirm which services, retests, and response commitments are included before the program begins.