Turning DDoS Protection Into a Service Customers Pay For

A carrier or hosting provider considering DDoS protection as a product already owns the two things that make it possible, and neither can be bought by the customer directly: capacity above the customer’s own circuit, and a view of the attack while it is still upstream.

What usually goes wrong is not capability. It is packaging that promises something the operator cannot measure and the customer cannot evaluate.

At a glance

Appliance	Tier	What the customer actually gets	What it costs you to deliver
Included baseline	Protection of the shared platform, not of them specifically	Nothing extra; it exists for your own stability
Detection and notification	You tell them, with evidence, and act on request	Monitoring per customer, and a support path
Automatic mitigation	Action without a phone call, within a stated time	Per-customer policy, calibration, and out-of-hours staffing
Managed with reporting	Tuned policy, incident reports, a named contact	Real analyst time, which is the actual cost of this tier

The middle column is what a customer will compare against a competitor. The right column is where the margin lives, and the third row is where most providers underprice by ignoring staffing.

The baseline is not a product

Every provider does something for its own stability: filtering obvious abuse, null-routing addresses under attacks that threaten shared infrastructure, ordinary hygiene.

Describing that as a customer protection tier causes a dispute at the first incident, because it protects the platform rather than any individual customer — and the cheapest platform-protecting action, discarding traffic to the target, is precisely the outcome the customer thinks they paid to avoid.

Say what it is. “We protect the shared network. This does not guarantee your service remains available, and under a sufficiently large attack against your address we may discard traffic to it.” That sentence costs a small amount of sales comfort and removes an entire class of argument.

Tier two: you notice, and you tell them

The first genuinely saleable thing is visibility, and it is saleable because the customer cannot produce it themselves. You see the attack in flow records before it fills their circuit; they see a slow service.

What the tier contains: per-customer monitoring, an alert to a named contact, an evidence record, and mitigation applied on request within a stated time.

What it costs you: monitoring configured per customer, and a support path that can be reached and knows what to do. Modest, and mostly work you have already done for your own operations.

This tier sells well to organisations that have an operations team and want the upstream view they cannot get. It is also the natural place for a standard signalling interface such as DOTS, so the request can be automated rather than telephoned.

Tier three: you act without being asked

The step to automatic mitigation is where the platform requirement appears, and it is the reason this tier cannot simply be priced above the last one.

Per-customer policy becomes mandatory. A shared policy across customers with different normal traffic will refuse someone’s ordinary business or be too loose to protect anybody. This is the same isolation requirement that governs hosting platforms, and the property to verify is enforcement independence rather than reporting separation.

Calibration becomes an ongoing cost. Every customer’s thresholds have to come from that customer’s measured traffic and be revisited as it grows. This is real recurring work and it is where providers most often underestimate.

Out-of-hours staffing becomes real. Automatic action still produces judgement calls, and the automation boundary applies to you as the operator: whatever is expensive to reverse still needs a person who is authorised.

Tier four: managed, which means people

The top tier is analyst time wearing a product name. Tuned policies, incident reports written for the customer’s own regulator or board, a named contact who knows their estate, and proactive review.

This is worth more than the tiers below it and costs more to deliver than most price lists assume, because the cost is hours rather than capacity. Before setting the price, count the operator interventions your platform actually requires per incident — the KPI list argues for collecting that figure anyway, and here it converts directly into margin.

Writing an SLA somebody can measure

The commonest SLA in this field is a time-to-mitigate commitment, and on its own it is a promise that can be kept while the customer’s service is unusable. Mitigation engaged in ninety seconds that refuses a quarter of real traffic has satisfied the clause and failed the customer.

A defensible commitment has three parts:

1. Time to mitigate, from attack start, with the measurement method stated.
2. Traffic survival against an agreed baseline, measured at a point both parties accept.
3. Notification and evidence, within a stated period, in a stated format.

The second is the hard one, and it is what the customer is actually buying. It requires a baseline agreed in advance and a measurement point neither side controls unilaterally. Providers who offer it differentiate themselves immediately, because most competitors will not.

Regulated customers under NIS2 or DORA will additionally need the evidence in part three to arrive within their own reporting deadline, which is shorter than most support processes assume.

The margin question

Three costs decide whether the service is profitable, and only the first is usually modelled.

Capacity. Sized to your aggregate edge rather than to any customer, and largely already purchased.

Platform. Per-customer policy, reporting and provisioning. A one-off with a maintenance tail, and the licensing structure matters here in a way it does not for a single-tenant buyer: if the platform meters per protected object, your margin is a function of the licence model rather than of the hardware.

People. The dominant recurring cost above tier two, and the one that scales with customers rather than with capacity.

A price list built from the first two alone will look excellent and lose money on the managed tier, which is the tier customers most want to buy.

Before designing the price list

• Confirm enforcement independence between tenants by testing it, not by reading about it.
• Measure your current interventions per incident; that number sets tier-four pricing.
• Decide and document the null-routing policy, because it is the boundary of what any tier can promise.
• Establish whether the platform’s licensing meters protected objects, and model margin accordingly.
• Write the traffic-survival clause before sales starts describing the tiers, so the product matches the commitment.

The buyer-side view of the same platform — what a customer evaluating you will ask — is in the ISP buyer’s guide, and reading it before writing the price list is the cheapest competitive research available.