Is it legal to run a DDoS test against my own servers?

Owning the servers is necessary but not sufficient. Traffic reaches them through infrastructure you usually do not own — a hosting provider, a transit provider, a cloud platform — and saturating a shared path affects other customers. In most jurisdictions the offence turns on unauthorised impairment rather than on ownership of the endpoint, so the authorisation you need is from everyone whose infrastructure carries the test, not only from yourself.

Can we use a booter or stresser service to test our defences?

Treat that as a hazard rather than a shortcut. Services of that kind generally operate without any consent framework, frequently generate traffic from compromised third parties, and give you no control over volume, source or stopping. Using one exposes the buyer to criminal liability in many jurisdictions and gives you no defensible evidence afterwards, because you cannot describe what was sent. A controlled generator in a defined scope is both lawful and more useful, since it produces a repeatable measurement.

Does a regulator require us to test?

Several regimes require you to assess the effectiveness of your measures, which in practice means exercising them rather than documenting an intention. The financial sector carries the most specific obligations, including an advanced testing regime. What no regime does is tell you to generate attack traffic against production without controls — the duty is to demonstrate effectiveness, and a tabletop exercise or a controlled test both satisfy it in different ways.

Should we tell our upstream provider before testing?

Always, and early enough that they can say no. A provider that discovers your test by detecting it may mitigate it — which invalidates the test — or may treat it as an incident on their side, which is worse. Their acknowledgement also protects you: it converts an apparent attack into a scheduled activity in their records.

What should we do if the test causes a real outage?

Abort using the agreed condition and channel, then treat it as an incident rather than as an embarrassment: the runbook applies, the evidence is captured, and the review happens. A test that caused an outage has produced the most valuable result available, provided the organisation is willing to write it down.

Operations

Authorised DDoS Testing, Legally and Safely

Last updated: August 2026 · What has to be true before the first packet · Reading time ~12 min

A heavy pale gate held open by three visibly different props — a straight rod, an A-brace and a coiled spring column — with one bounded teal-green beam passing beneath it while amber piles up against an unbroken wall to the right.

A DDoS test is lawful when the person who owns the target has authorised it in writing, the scope names exactly what is in it, every provider whose shared infrastructure is in the path has acknowledged it, and an abort condition and its owner are agreed in advance. Testing infrastructure you do not own or have authorisation for is a criminal matter in most jurisdictions, whatever the intent.

Testing a DDoS defence means generating traffic that is, by construction, indistinguishable from an attack. Everything on this page exists because that fact has legal and operational consequences that do not go away when the intent is good.

This is technical implementation guidance, not legal advice. Verify your obligations with competent counsel and, where a regulator is involved, with the regulator.

What has to be true before the first packet

Appliance	Requirement	What satisfies it
Authorisation	Signed instruction from the legal owner of the target asset	A verbal go-ahead, or an email from someone without authority
Scope	Named addresses, services and time windows	Our production environment
Provider consent	Written acknowledgement from hosting, transit and cloud providers in the path	Assuming the contract permits it
Abort	A named person, a stated condition and a tested channel to reach them	An intention to stop if something looks wrong
Evidence	Retained logs and a written test record	The generator's own summary screen

The second column is what an incident review, an insurer or a regulator will ask to see. The third is what most teams actually have.

Written authorisation from the asset owner

Signed, by someone with the authority to sign, naming the systems in scope and the window. An engineer’s confidence that the organisation would approve is not authorisation, and the distinction matters most in exactly the situation where you would want it to have been done properly.

An exact scope

Addresses, hostnames, services and time windows, written down. “Production” is not a scope. The reason to be exact is not bureaucratic: the scope is what an abort decision is measured against, and what tells an investigator later that what happened was the test rather than something else.

Provider acknowledgement

Hosting providers, transit providers and cloud platforms all carry your test traffic across infrastructure shared with other customers. Their acknowledgement is required for two separate reasons — it makes the activity contractually permitted, and it stops their own defences from mitigating your test and invalidating the result.

Ask early enough that a refusal is still useful information rather than a problem.

An abort condition and a named owner

A stated condition, a named person and a channel that has been tested. Under load, the channel you were going to use may be the thing that is degraded, which is a discovery best made beforehand.

Where to test

A lab that mirrors production is the safest place and the least informative one, because the property you are usually measuring — how the defence behaves against your real traffic mix — is exactly what a lab does not have.

Production, in a defined window, below saturation is where the useful measurements are. The discipline that makes it acceptable is testing the device rather than the circuit: deliberately staying below the level at which the uplink saturates, because a saturated uplink measures the uplink and affects everyone else on it.

Never a third party. Not a competitor, not a provider’s shared infrastructure as a target, not “a public service that will not notice”. There is no version of this that is defensible.

Traffic generation

Use a generator you control, with a stated rate, a stated source set and a stop that works. The categories that qualify are commercial test platforms, open-source generators run on infrastructure you own, and a manufacturer’s own test rig operated under your scope agreement.

The category that does not qualify is a booter or stresser service. Those operate without a consent framework, frequently source traffic from compromised third parties, and give you no control over what is sent or when it stops. The exposure is criminal in many jurisdictions, and the result is unusable as evidence because you cannot describe what happened.

This page does not provide attack tooling, configurations or techniques for generating traffic against a target. The controls to test and the way to measure them are the subject; how to mount an attack is not.

Regulatory context

Several regimes require an entity to assess the effectiveness of its security measures rather than merely to have them, and availability is squarely within that duty NIS2 Directive. In the financial sector the obligations are more specific, including a structured advanced testing regime and explicit expectations about scope, scenarios and remediation DORA Regulation.

Two things follow. The first is that a test which produces a written record is worth substantially more than one that produces a feeling, because the record is the evidence the duty asks for. The second is that a tabletop exercise satisfies part of the duty at a fraction of the risk — and for the decision-making half of your response, it satisfies it better than a traffic test does.

Evidence and rollback

Retain the test record the way you would retain incident evidence: the authorisation, the scope, the configuration under test, the generator settings, timestamps for each run, the measurements, any abort events, and what changed as a result.

Plan the rollback before the test. Any configuration changed for the test gets reverted in a stated order, verified afterwards, and recorded. Test-day changes that quietly survive into production are a recurring source of later incidents.

Prohibited and unsafe patterns

Testing anything you do not own or have written authorisation for.
Using booter or stresser services.
Testing at a volume that saturates shared infrastructure.
Testing without an abort owner reachable on a channel that has been checked.
Testing during a business peak without an explicit decision that it is the point of the test.
Leaving test configuration in production.
Reporting a result without stating what could not be tested.

What to do with the result

A test result is an input to the proof-of-concept methodology if you are evaluating a product, and to the incident response runbook if you are exercising a process. Neither is useful without the other: a defence that performs well and a team that cannot operate it produce the same outage as a defence that performs badly.

Sources

Frequently asked questions

Is it legal to run a DDoS test against my own servers?: Owning the servers is necessary but not sufficient. Traffic reaches them through infrastructure you usually do not own — a hosting provider, a transit provider, a cloud platform — and saturating a shared path affects other customers. In most jurisdictions the offence turns on unauthorised impairment rather than on ownership of the endpoint, so the authorisation you need is from everyone whose infrastructure carries the test, not only from yourself.
Can we use a booter or stresser service to test our defences?: Treat that as a hazard rather than a shortcut. Services of that kind generally operate without any consent framework, frequently generate traffic from compromised third parties, and give you no control over volume, source or stopping. Using one exposes the buyer to criminal liability in many jurisdictions and gives you no defensible evidence afterwards, because you cannot describe what was sent. A controlled generator in a defined scope is both lawful and more useful, since it produces a repeatable measurement.
Does a regulator require us to test?: Several regimes require you to assess the effectiveness of your measures, which in practice means exercising them rather than documenting an intention. The financial sector carries the most specific obligations, including an advanced testing regime. What no regime does is tell you to generate attack traffic against production without controls — the duty is to demonstrate effectiveness, and a tabletop exercise or a controlled test both satisfy it in different ways.
Should we tell our upstream provider before testing?: Always, and early enough that they can say no. A provider that discovers your test by detecting it may mitigate it — which invalidates the test — or may treat it as an incident on their side, which is worse. Their acknowledgement also protects you: it converts an apparent attack into a scheduled activity in their records.
What should we do if the test causes a real outage?: Abort using the agreed condition and channel, then treat it as an incident rather than as an embarrassment: the runbook applies, the evidence is captured, and the review happens. A test that caused an outage has produced the most valuable result available, provided the organisation is willing to write it down.

Sources

Directive (EU) 2022/2555 (NIS2)
EUR-Lex, Publications Office of the European Union · 2022-12-14 · regulator · accessed 2026-08-15
Referenced for the testing and assessment duty; the binding text for you is your member state's transposition.
Regulation (EU) 2022/2554 (DORA)
EUR-Lex, Publications Office of the European Union · 2022-12-14 · regulator · accessed 2026-08-15
Financial-sector testing obligations, including the advanced testing regime, sit here rather than in NIS2.

Published: August 2026 · Last reviewed: August 2026

Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.

This guide is updated as vendors release new models and pricing. How we compare vendors