DDoS as a Licence Obligation: What Changes When Your Subscribers Are the Ones Harmed

An enterprise that buys DDoS mitigation is buying protection for itself. If the design fails, the enterprise absorbs the consequence, and the calculation about how much to spend is a calculation about its own risk appetite.

A licensed operator is in a different position, and most procurement documents in the sector do not reflect it. When an internet service provider, a data centre operator or a cloud provider in the Kingdom buys mitigation, the thing being protected is a service sold to other parties under a licence — and those parties, not the operator, are the ones the availability duty exists for. That single shift changes four things about the design, none of which shows up in a throughput comparison.

A note on how this article treats regulatory text

What follows describes the shape of a licensed provider’s obligations, not their text. There are no instrument names, no article numbers, no reporting windows, no thresholds and no penalty figures anywhere below, and their absence is deliberate rather than cautious. Licence conditions are specific to your licence class and are revised; a number frozen into a guide sends a reader to a version they are not held to.

Obtain your current licence conditions and the authority’s current instruments from the Communications, Space and Technology Commission, and have your regulatory affairs function state the requirement in writing before anyone writes a technical specification. The order matters: a specification written first tends to describe the equipment someone already has in mind, and the obligation gets fitted to it afterwards.

Two regulators, two questions

Saudi organisations that think about cybersecurity governance usually think first about the National Cybersecurity Authority, and correctly. Its national baseline is the reference point for the controls an organisation applies to its own environment — and a licensed provider is an organisation like any other in that respect, so everything in our guide to the Essential Cybersecurity Controls still applies. Financially supervised institutions add a third layer, which the central bank framework guide covers.

The sector regulator asks something none of those reach. Its interest is not whether you have controls but whether the service you are licensed to sell keeps working for the people who bought it. That is a duty about harm to third parties, and it is why a provider can hold a clean internal assessment and still have a problem.

The practical consequence is that a licensed provider needs its DDoS design to answer two questions that look similar and are not:

• Did our controls work? — the question the baseline asks, answered with design documents, approvals, monitoring and test records.
• Was any subscriber’s service degraded, and by what? — the question a sector regulator asks, answered with per-subscriber facts about a specific window in time.

An architecture optimised for the first can be structurally unable to answer the second.

The unit of harm is not your uptime

Here is the scenario that separates the two worlds. An attack targets a single hosted customer. The volume is well within what your platform can carry, but the traffic aimed at that one prefix is enough to congest the path serving a whole aggregation point. Your operations team does the textbook thing: it withdraws or blackholes the targeted prefix upstream, congestion clears, and every other customer on that aggregation point is unaffected.

Measured as an enterprise incident, that is a clean result. Core protected, blast radius contained, no platform-wide outage.

Measured as a licence obligation, something else happened. One subscriber’s service was taken off the air, and it was taken off the air by you rather than by the attacker. The attacker’s objective for that subscriber was completed by the defender. That is not a scandal — it is sometimes the only available move, and every operator on earth has made it — but it is an event about a subscriber, and it belongs in the same category of record as an outage you caused for any other reason.

Once that is accepted, three design consequences follow immediately.

Aggregate metrics stop being sufficient. A platform drop counter tells you the mitigation tier is working. It does not tell you which customer bore the cost of it working.

Mitigation granularity becomes a licence issue, not a feature preference. If your only control is a threshold applied to the whole platform, then every response is necessarily coarse: you set it low and generate false positives for quiet tenants, or you set it high and your most exposed tenant is unprotected until the flood is large enough to matter to everyone. The middle ground only exists if policy can differ per customer.

The decision to shed traffic needs a procedure. Not because engineers make bad decisions under pressure, but because a decision with a third-party consequence has to be attributable afterwards, and attribution designed after the fact is never convincing.

Accountability does not travel with the traffic

The most common structure in the region is an operator that carries a commercial mitigation service from its own upstream transit provider, and treats that as its DDoS answer. The economics are attractive and the capacity is genuinely there. The problem is narrower and worth stating exactly.

Your upstream is not licensed by your regulator. It has no relationship with your subscribers, no duty toward them, and no exposure if they are harmed. Its service-level agreement runs to you, in money, and money does not discharge a licence obligation. So when a diversion is announced late, or the return path is saturated because every one of that provider’s customers diverted during the same regional event, or the provider makes a capacity decision that favours its larger customers, the party standing in front of the authority is you — holding a contract that explains why it happened and does not answer for it.

This is an argument for understanding the dependency, not for refusing it. Upstream capacity is irreplaceable above your own circuit, as the next section concedes. But it changes what you should require in writing: not just an availability percentage, but the diversion trigger, who may pull it, how long announcement and convergence take in practice rather than in the datasheet, what the return path is and what physical infrastructure it depends on, and what the provider’s behaviour is when many of its customers are under attack simultaneously. That last question is almost never asked and is the one that describes your worst day.

Blackholing is a decision, and decisions get reviewed

Because shedding a prefix has a third-party consequence, the operator needs the same thing around it that any consequential decision gets: a documented path, a named authority level, a limit, and a record.

Four elements, and none of them is expensive:

1. A trigger stated in advance. What condition permits it — not “when the NOC judges it necessary”, which is a description of the absence of a policy.
2. An authority level. Who may make the call at three in the morning, and who has to be informed within what period. A shift engineer with no written authority will either hesitate when speed matters or act without cover; both are the policy’s fault.
3. A time limit and a review point. A withdrawal that persists because nobody revisited it is the most common way a five-minute decision becomes a multi-hour subscriber outage.
4. A reconstructable record. What was withdrawn, when, on whose authority, on what evidence, and when it was restored.

The fourth is where architecture and procedure meet, because a record you cannot produce is a procedure you did not follow. Which brings the argument to its practical end.

Reconstruction: who, when, and what

Some weeks after a significant event, the questions arrive. They are always about specifics: was this customer affected, between which times, by the attack or by your response, and what did you observe. A bandwidth graph does not answer any of them.

Producing that answer is cheap under one condition — that the inspection point is equipment you operate, whose records you keep on a retention policy you set. Then a packet capture is a query, not a support ticket. Source addresses arrive with original values and local timestamps rather than through a provider’s forwarding path. The retention window is a decision your compliance function made rather than a term in someone’s standard contract. And you can produce the record while the subscriber is still waiting, which is usually the difference between an explanation and a complaint.

Where everyday inspection happens in another provider’s facilities, every one of those becomes a request to a third party, answered within their retention window and their support model, about an incident for which you are the accountable party. That is the operational case for keeping the everyday inspection point local, and it stands entirely apart from the data-residency argument that the GCC residency guide makes on separate grounds.

The honest limit

None of the above changes physics. An appliance sitting behind your access circuit cannot mitigate an attack that has already filled that circuit, and a national-scale volumetric event will exceed any single operator’s edge capacity. For a provider, upstream capacity is not optional — it is the only tier that exists above your own uplink.

So the design that fits a licensed provider is on-premise-first rather than on-premise-only: inspection local by default, upstream engaged as a deliberate, rehearsed, time-bounded action above a threshold you have measured on your own circuit rather than adopted from a template. The hybrid architecture comparison sets out the general trade; what a licence adds is that the diversion itself becomes an event you have to be able to describe afterwards.

What this means for the shortlist

Read the vendor market with the two acceptance criteria above rather than with a throughput column, and the field sorts differently.

Per-customer policy on shared hardware moves from a nice-to-have to a threshold requirement, and it is not universal — plenty of capable appliances are designed around a single protected estate, because that is what most of their buyers are. HARPP DDoS Mitigator is built the other way round, with protection profiles defined per customer on shared hardware, which is the shape this problem has; whether its capacity envelope fits your aggregation points is a separate question and the one to test first. Radware DefensePro and NetScout Arbor are both used in carrier deployments at scales that make the point moot, though Arbor’s network-wide picture normally arrives through Sightline alongside the edge device, so a provider shortlisting on “one design document, one test plan” should price the ecosystem rather than the box. A10 Thunder TPS has a long service-provider history and its strength sits at L3/4, which matters if your subscriber base is being hit at the application layer.

The second criterion — whether detection runs on your own infrastructure — reads differently for a provider than for an enterprise. An enterprise asking it is usually asking a data-protection question. A provider asking it is asking an availability question: if your mitigation degrades when a vendor-operated intelligence service is unreachable, then a dependency outside your licence has been placed inside a duty that sits squarely within it.

Appliance	Enterprise buying for itself	Licensed provider buying for subscribers
What counts as harm	Your own services degraded	Any subscriber's service degraded, including by your own mitigation
Who the duty is owed to	Your board and your customers, contractually	Your subscribers and your sector regulator, by licence
Effect of a successful blackhole	Incident contained	Core protected, and one subscriber taken off the air by you
Whose evidence answers the question	Yours, or your provider's, at your discretion	Yours, on a timeline the authority may ask you to reconstruct
What outsourcing transfers	Operational work and some risk	Operational work only — the licence obligation does not move
Granularity the design must support	Whole-estate policy is usually enough	Per-subscriber policy, per-subscriber reporting
Cost of an upstream provider's decision	An outage you explain internally	An outage you explain to the party that licensed you

The two columns are not different products — most of the appliance market serves both. They are different acceptance criteria, and the rows that separate them are the last three.

Clauses to put in the tender

Six, each of which produces a testable answer rather than a marketing response:

1. Describe how protection policy is defined per customer on shared hardware, and demonstrate two customers on one platform with materially different thresholds during a proof of concept.
2. Produce, for a single named customer and a single named hour, a record of what was detected, what action was taken and what was forwarded. Show the query, not a screenshot.
3. State what telemetry leaves our network in the course of everyday protection, to which party, and in which country it is processed.
4. State how mitigation behaves if that external dependency is unreachable for twenty-four hours.
5. For the upstream tier: state the diversion trigger, the authority required, the measured time from decision to full mitigation, the return path, and the physical infrastructure the return path depends on.
6. For the upstream tier: state the behaviour when a large proportion of your customers divert during the same event.

The last two belong in the transit tender rather than the appliance tender, which is itself part of the point — a provider that sources both tiers from one commercial relationship has one conversation where it needs two.

Sources and further reading

Licence conditions, the applicable instruments and any sector-specific reporting expectations should be obtained directly from the Communications, Space and Technology Commission, and read alongside the national cybersecurity baseline published by the National Cybersecurity Authority. Neither this guide nor any other is a substitute for the current text as it applies to your licence class; the value of the framing above is in the questions it makes you ask your own regulatory affairs function, not in any statement of what the rules say.