DDoS Protection Renewal: Match Every Protected Circuit to a Response Owner

A DDoS protection proposal can look complete and still leave the important question unanswered: who can get each affected service into mitigation when the attack starts?

The agreement lists bandwidth. The portal shows protected objects. Security has an incident plan. Network operations has the circuit inventory.

Okay, but do those records describe the same circuits, IP prefixes, routing paths, services, contacts, and activation process?

Before you renew, match every protected asset to the business service it supports, the mitigation method, the people authorized to act, the provider response, and current test evidence. Then decide what to keep, correct, remove, redesign, or compare.

Start with the service, not the security product

DDoS protection does not protect “the company” as one object. It protects specific paths, addresses, applications, DNS services, cloud endpoints, or other exposed resources through a defined technical and operating model.

Start with the business services whose loss of availability would matter: customer portals, ecommerce, remote access, public APIs, voice services, authoritative DNS, or internet-facing infrastructure at a data center.

For each service, trace the complete delivery path:

Field	What to capture
Business service	Name, owner, users, critical periods, and tolerable degradation
Public exposure	Domains, hostnames, public IPs, prefixes, ports, protocols, and origin systems
Network path	ISP, circuit ID, autonomous system details where applicable, cloud edge, CDN, WAF, DNS, firewall, and load balancer
Protection	Provider, service tier, mitigation mode, detection source, threshold, and activation method
Response	Internal incident owner, network owner, provider contact, authorization path, and escalation contact
Evidence	Portal export, routing record, configuration, alert sample, incident record, and test result
Decision	Keep, correct, remove, redesign, compare, or investigate

Do not group several circuits or prefixes into one line because the provider markets them as one service. One site may have provider-managed mitigation. Another may rely on a cloud edge. A third may have a service on the invoice but no current routing path into it.

NIST Cybersecurity Framework 2.0 treats assets, suppliers, technology resilience, incident response, and recovery as connected outcomes. That is the right lens for renewal. The product matters, but so do the assets in scope, the supplier’s role, your team’s authority, and the process for restoring normal service.

The ISP renewal inventory guide can help reconcile service IDs, addresses, invoices, and circuit records first. DDoS review starts where that inventory ends by asking what traffic is protected and what happens during an attack.

Separate three different protection problems

A supplier saying it “handles DDoS” is not specific enough.

The UK’s National Cyber Security Centre separates attacks by what they exhaust. A volumetric attack consumes network capacity. A protocol attack consumes network-device resources by abusing normal protocol behavior. An application attack sends legitimate-looking requests that consume server or database resources.

Those attacks do not necessarily use the same controls or owners.

An ISP or network scrubbing service may filter large traffic volumes before they reach your circuit. A CDN or cloud edge may absorb web traffic. A WAF, rate limit, or temporary feature restriction may help when requests are reaching an expensive application function. More capacity may help with one bottleneck while doing little for another.

Ask the provider to map its service to the attacks and resources it can address:

Which network layers and protocols are in scope?
Does the service cover volumetric, protocol, and application-layer attacks?
Where does mitigation happen relative to the constrained circuit or service?
Which traffic stays encrypted, and which provider can inspect enough context to filter it?
What is automatic, what needs customer approval, and what remains the customer’s job?
What happens to legitimate traffic when the provider applies an aggressive control?

Do not accept a capacity number as the full answer. Capacity matters. So do routing, detection, activation time, false positives, application context, and the limits written into the service.

Reconcile every circuit, prefix, and origin

The renewal proposal is a commercial record. It is not proof of current coverage.

Pull the provider’s protected-object export, agreement, order forms, invoices, portal configuration, circuit inventory, IP address management data, DNS records, routing design, cloud inventory, CDN configuration, firewall objects, and application-owner list. Match them.

Look for the gaps that accumulate quietly:

A circuit was replaced, but the old service ID remains in the DDoS schedule.
A public prefix moved to another carrier or data center.
An application migrated behind a CDN, but the origin is still directly reachable.
A new cloud endpoint never entered the protection inventory.
A backup circuit uses a different range that nobody added.
An acquired business has public services under a separate account.
The provider portal lists a technical contact who left the company.
A protected object exists, but nobody can explain the business service behind it.

NCSC guidance recommends understanding what mitigation an ISP already provides, what additional controls are available, and when the provider may limit access to protect other customers. It also warns buyers to check for shared resources when using multiple providers.

That matters commercially. Two providers on a slide may still share a backbone, facility, access path, or cloud dependency. The internet circuit diversity guide can help you test whether a second path changes the failure domain or only changes the logo on the invoice.

Make the activation path executable

A mitigation service that requires manual activation is only as fast as the people and permissions around it.

Write down the real sequence. Who detects the event? Who decides it is an attack instead of a legitimate traffic surge or a broken application? Who opens the provider case? Who is allowed to request routing or filtering changes? Which phone number works after hours? Who approves controls that may block real users? Who tells the business that service is degraded?

NCSC’s response guidance starts by clarifying what is happening. It recommends gathering traffic, bandwidth, processor, database, alert, and help-desk evidence because a slowdown can have malicious or non-malicious causes. Turning on the wrong response can make the outage worse.

Create a one-page activation record for each protection model:

Detection signal and alert destination
Initial technical checks and decision owner
Provider name, service identifier, portal, phone, and case path
Authorized callers and backup callers
Information the provider requires
Controls the provider may apply without approval
Controls that require customer approval
Business communication owner
Recovery and mitigation-removal steps
Evidence to retain after the event

Keep the record somewhere responders can reach if the normal network, identity provider, collaboration tool, or corporate phone service is affected. A beautifully written runbook inside an unavailable system is not much of a runbook.

Read the contract for provider self-protection

Providers have to protect their own infrastructure and other customers. Your agreement should tell you how they may do that.

NCSC’s upstream-defence guidance gives buyers a useful set of contract questions. Will the provider apply mitigation automatically? Will it notify you? How long does extra mitigation take to activate? Can the provider throttle bandwidth, sinkhole traffic, or terminate service? When do extra usage or mitigation charges begin? How quickly can service be restored after a shutdown?

Turn those questions into marked contract language and an operating checklist.

Review:

Protected circuits, prefixes, domains, applications, and accounts
Included mitigation mode and any paid activation option
Detection and notification obligations
Response targets and the events that start the clock
Customer information and approval requirements
Traffic-routing, filtering, throttling, and sinkhole rights
Overage, burst, incident, professional-service, and log-access charges
Reporting, evidence, and post-incident review
Maintenance, exclusions, and dependencies
Removal, migration, and transition support at termination

A generic uptime SLA does not answer these questions. Service credits after an outage do not prove the provider can coordinate the response you need.

Test the operating model before renewal

Do not launch an unapproved DDoS test against production. Use the provider’s approved test process, a legitimate testing service, controlled simulation, or a tabletop exercise that stays inside legal and technical boundaries.

Start with a portal and contact validation. Confirm named users can sign in, see the right account, locate protected objects, open a priority case, and reach the after-hours path. Then walk a realistic alert through the internal decision and provider escalation process.

Where an approved technical test is possible, define what you want to prove:

Detection produces an alert in the expected place.
The correct circuit, prefix, application, or origin is identified.
The provider can activate or confirm the contracted mitigation mode.
Routing and service behavior match the design.
Monitoring shows network, compute, storage, and application effects.
Legitimate users can still complete the most important workflow.
Responders know when and how to remove temporary controls.
The provider delivers the promised incident evidence.

NCSC recommends testing both network-layer and application-layer defenses and monitoring the parts of the service that can reveal how the attack is causing exhaustion. A dashboard screenshot is not enough if nobody tests the handoff between your monitoring, your responders, and the upstream provider.

Make an asset-level renewal decision

Keep protection where the business service, public exposure, protected object, mitigation model, contacts, contract, and test evidence agree.

Correct records, routing, contacts, alerts, or response steps when the service still fits but the operating model has drifted.

Remove obsolete circuits, prefixes, accounts, or paid features only after proving they no longer protect a current service or dependency.

Redesign when the protected path still exposes an origin, the control sits behind the bottleneck, the response requires unavailable systems, or multiple providers share a failure point you meant to diversify.

Compare alternatives when the supplier cannot define coverage, activation, authority, evidence, pricing, or recovery well enough to support the business requirement.

Investigate every mismatch before signing. A protected object with no owner is not automatically waste. It may be the only protection in front of a service your records missed.

Renewal is the moment to turn DDoS protection from a line item into an operating capability. Match the asset, name the owner, test the call, and fix the gaps while you still have commercial leverage.

If your DDoS, internet, cloud edge, CDN, or managed security agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, proposal, invoices, circuit and prefix inventory, routing design, protected-object export, contact list, incident history, and latest test result. Catch Advisors will help you decide what to keep, correct, remove, redesign, compare, or investigate before you sign.