Vision 2030 and the DDoS Layer: Why Traffic That Leaves Also Takes the Learning With It

Saudi Arabia’s development programme is explicit about a small number of things: diversifying the economy away from a single revenue source, growing a digital economy, and building local content and local capability rather than importing finished capability indefinitely. Those are declared goals, restated consistently, and nothing in this guide requires reading anything more specific than that into them.

Applied to cybersecurity procurement, they produce a question that a compliance assessment never asks. Not is this control adequate — that is settled elsewhere, and our guide to the national controls covers it — but does the way we deliver this control build the thing the country said it wanted to build, or substitute for it?

For DDoS mitigation the answer turns out to be unusually clear, and it hinges on something that does not appear in any data-flow diagram.

Availability became a public asset

The first move is to notice what a digital-economy goal does to the status of uptime.

When commerce, government service delivery, banking and logistics all migrate to public-facing digital channels, the availability of those channels stops being an operational metric belonging to individual organisations. It becomes a property of the national economy — the same way port throughput or grid reliability is. An extended outage in a payment network or a citizen services portal is not a bad quarter for one operator; it is a period during which a part of the economy that was deliberately digitised does not function.

That reframing is why DDoS deserves attention in a development-policy conversation at all. It is one of the few threat classes whose entire purpose is to remove availability, it requires no compromise of anything, and it is cheap to launch against a target that has become economically important.

The part of localisation that gets discussed

Most localisation discussion concerns data. Where is it stored, where is it processed, under whose jurisdiction, on what legal basis. Applied to DDoS the analysis is well trodden: a scrubbing tier cannot classify traffic without processing source addresses, headers, session identifiers and, for application-layer protection, request bodies — so a tier operating abroad is processing that material abroad, whatever it stores. The GCC residency guide sets that out in full and this guide does not repeat it.

That analysis is correct and incomplete. It measures what crosses the border. It does not measure what fails to accumulate on this side of it.

The part that does not

Consider what actually happens during a mitigated attack, from the point of view of institutional learning rather than traffic.

Someone watches the traffic arrive. Someone recognises which signature this is, notices which of the protected services started to wobble first, decides whether the threshold that fired was correct, adjusts it, watches the effect, and afterwards writes down what to do differently. That sequence is where operational competence is manufactured. It cannot be acquired from a report, a course, or a certification, because the useful part of it is specific to the estate being defended — your normal, your services, your false positives, your change process.

Now ask where that sequence takes place under each architecture.

If everyday inspection happens in a provider’s scrubbing centres, it takes place in that provider’s operations room, staffed by that provider’s engineers, in another country. Your team receives a notification, a graph and, later, a summary. They have not watched anything. Over five years and several dozen events, the provider’s organisation becomes measurably better at defending traffic like yours, and yours becomes measurably better at reading reports.

If everyday inspection happens on equipment in your own facility, the same sequence takes place in your operations room. The engineer who tuned the threshold is on your payroll, in the country, and remains employable in the country afterwards. The knowledge does not leave when a contract expires, because it was never held by the counterparty.

That is the claim, and it is narrower than the sovereignty rhetoric usually attached to this subject. It is not that foreign providers are untrustworthy. It is that skill accrues to whoever performs the work, and a development goal about building national capability is a statement about where work should be performed.

Local content is not only where the money goes

Procurement frameworks that weight local content usually count spend: what proportion of contract value is delivered by domestic entities. That is a reasonable proxy and it understates this case.

A recurring offshore scrubbing subscription is, in local-content terms, close to a pure import. It is a service fee, delivered by people and facilities elsewhere, renewed annually, with almost no domestic work attached beyond the account relationship.

An appliance deployed in country is not fully domestic either — the hardware and the software are imported, and this guide is not going to pretend otherwise. But look at what surrounds it: physical installation, network integration, policy design, baselining against local traffic, tuning, monitoring, incident response, capacity planning, testing, and the training of people to do all of it. That work is performed locally by definition, because the equipment is local, and it is the kind of work that produces engineers who are still valuable when the equipment is replaced.

Over a five-year horizon the difference is not the invoice. It is whether the country has more people who know how to defend a national-scale service at the end of the period than at the start.

Where the equipment choice actually matters

Two properties distribute the learning differently, and they are worth putting in a tender.

The first is whether the detection logic is trained and executed on the customer’s own infrastructure. Where it is, tuning is your team’s work and the resulting knowledge is a local asset, which is the property that connects an equipment decision to a capability outcome rather than only to a data-residency one. Where classification depends on a manufacturer-operated intelligence service, the most valuable tuning happens inside that service, and the local role narrows toward operating what is supplied. Both are legitimate designs and the second is often more capable out of the box; they simply put the compounding in different places.

The second is whether operations are transferable. A model in which the manufacturer or a partner operates the platform indefinitely produces the same outcome as offshore scrubbing with extra steps — the equipment is in the country and the competence is not. Ask, in writing, on what timescale the customer’s own team can take over operations, what training is included, and who certifies it. Answers vary widely across the market and rarely appear in a datasheet.

Appliance	Everyday inspection offshore	Everyday inspection in country
Who observes the attack in detail	The provider's operations centre	Your own operations team
What an incident produces internally	A summary report and an invoice line	A tuned policy, a rehearsed runbook and a trained engineer
Where the skill accumulates over five years	In the provider's organisation	In the national labour market
Local content in the purchase	Recurring service fee, largely offshore	Hardware, integration, operations, training
Position if the relationship ends	Capability leaves with the contract	Capability stays; hardware and people remain
What the data-flow diagram shows	A cross-border processing hop to justify	No hop for everyday traffic
What the diagram does not show	That the learning also crossed the border	That it did not

The last two rows are the argument. Every localisation discussion covers the data; almost none covers the experience, and the experience is the part that compounds.

The limit of the argument

Three honest qualifications.

Capacity is not a policy question. No amount of local capability changes the fact that an attack larger than your circuit has already won before your equipment sees it. Upstream capacity remains necessary, and an organisation with a genuine terabit-scale exposure that refuses cloud capacity on capability grounds has confused a preference with a design.

Speed sometimes beats strategy. An organisation currently defenceless and under attack should buy the fastest adequate answer available, which is frequently an upstream service that can be turned on this week. Capability is built over years and outages happen this afternoon.

Local operation is a commitment, not a purchase. An appliance operated by nobody is worse than a service operated by someone competent. The capability argument only pays if the organisation actually staffs, trains and rehearses — and an organisation unwilling to do that should buy the service and be honest about why.

What to put in the tender

1. State the proportion of delivered work performed in country, by role.
2. State the timescale on which the customer’s own team can assume full operation, and what training and certification is included.
3. State what the customer retains — equipment, configuration, knowledge, records — if the commercial relationship ends.
4. State whether detection is trained and executed on customer infrastructure or depends on an external service, and how it degrades if that service is unreachable.
5. Require that the diversion runbook is exercised by the customer’s own staff, not demonstrated by the vendor.

Item five is the cheapest and the most revealing. A capability that only the supplier can exercise is a capability the country does not have.

Sources and further reading

The development programme’s stated objectives are published by the Kingdom and are the right primary source for any policy framing; nothing in this guide depends on a specific target, timeline or figure, and none is asserted here. For the regulatory analysis that sits alongside this policy one, see the national controls guide, the central bank framework guide and the GCC residency guide. For the licence-holder’s version of the same question, see DDoS as a licence obligation.