A DDoS resilience test deliberately generates traffic intended to stress your defences. Without proper authorisation, the same activity can look exactly like an attack, and in many jurisdictions sending disruptive traffic to systems without permission can be a criminal offence. Authorisation is therefore not a formality. It is the foundation that makes a test lawful, safe, and useful. This guide sets out what authorisation for DDoS testing usually involves and which parties need to agree before any traffic is sent. It is general information and not legal advice.
What It Is
Authorisation for a DDoS test means that everyone with a legitimate interest in the target systems has agreed, in writing, to a defined test. That normally includes the business owner of the service, the technical owner, and any provider that operates part of the path: hosting companies, cloud platforms, CDNs, DDoS mitigation services, ISPs, and sometimes upstream carriers. Owning a domain or paying for hosting does not by itself give you the right to direct attack-like traffic at a provider's shared infrastructure. Many cloud and CDN providers publish testing policies; some require advance notice, use of approved vendors, or specific limits, and some prohibit certain test types. Beyond permission, authorisation documents the scope: target addresses and hostnames, traffic types, maximum rates, time windows, monitoring arrangements, named contacts on each side, and conditions under which the test stops immediately.
Who It Is For
This guide is relevant for:
- Security and infrastructure leads planning a first DDoS resilience test
- Businesses relying on a CDN or mitigation service and wanting to verify it works as expected
- Procurement teams evaluating DDoS testing proposals
- Managers who need to confirm the legal and contractual basis before approving a test
What It Helps Clarify
Working through authorisation helps clarify:
- Which systems you own and which are operated by providers whose permission is needed
- Whether provider testing policies restrict traffic types, rates, or timing
- Who can stop the test at any moment and how they will be reached
- What business impact is acceptable and what would trigger an immediate halt
What's Included
- Written authorisation signed by someone with authority over the target service
- Inventory of in-scope IP addresses, hostnames, and the providers in the traffic path
- Review of each provider's testing policy and, where required, their written approval or notification reference
- Defined traffic scenarios, maximum rates, and duration for each
- Test window agreed with business teams, avoiding peak periods and critical events
- Named contacts on both sides, with a tested communication channel
- Clear stop conditions and a confirmed method to halt traffic immediately
- Agreement on monitoring, evidence collection, and how results will be reported
What's Not Included
- Testing against systems where authorisation from the owner or provider is missing
- Legal advice on criminal, contractual, or regulatory questions
- Instructions for generating attack traffic
- A claim that a test proves immunity from real attacks
When to Choose It
Begin authorisation work several weeks before the intended test date, because provider approvals can take time. Revisit it whenever the target, provider, or window changes; a change in any of these is a change in scope, not an informal adjustment. If a provider declines to approve a test, respect that decision and discuss alternatives, such as testing a non-production replica or reviewing configuration instead. This article is general information and not legal advice.
Our Approach
We treat authorisation as part of the engagement, not paperwork beforehand. Scope is confirmed in writing, provider requirements are identified early, and the customer obtains any third-party approvals that are needed. Our DDoS Resilience Testing service evaluates agreed disruption scenarios within written limits, with controlled observation, a resilience-gap summary, and prioritised recommendations. During testing, named contacts can pause or stop the work at any time. The engagement delivers evidence about the agreed environment during the test window, and remediation or incident response is scoped separately if needed. Keep the authorisation pack with the final report; it records the conditions under which results were obtained, which matters when results are discussed later.
Frequently Asked Questions
Related Articles
Get Started
Planning a DDoS test and unsure about approvals?
Share the services, providers, and timing you have in mind. We will help define the scope and the approvals required.
Request a written scope