Data Residency and DDoS Mitigation in the GCC: Why Attack Traffic Shouldn't Leave the Country

A DDoS purchase in the Gulf usually begins as a capacity conversation. How many gigabits, how many packets per second, how quickly does mitigation engage. Somewhere between the shortlist and the signature, someone from legal or compliance asks a question that appears on no datasheet: in which country is our users’ traffic actually inspected?

The question is not rhetorical, and it does not have a comfortable answer if the mitigation tier is a foreign cloud service. It is also not a question about attacks. Under a cloud-only design, the tier inspects everything — every session from every customer, on quiet days as well as loud ones — because a filter that only inspects during an attack cannot know when an attack has begun.

That is the subject of this guide: what a scrubbing tier must process in order to work at all, why that turns an architecture decision into a cross-border transfer decision across the Gulf states, why “we do not store it” is not a defence, what an in-country tier changes, and what belongs in the contract rather than in a meeting. Where a control-framework and evidence view of the same problem is more useful to you, the companion guide on DDoS protection and the NCA Essential Cybersecurity Controls takes the Saudi case through an assessor’s checklist, and the financial-sector view covers supervised institutions.

What a scrubbing tier must process to do its job

The marketing formulation is that the provider “cleans the bad traffic”. The sentence hides the mechanism, and the mechanism is the whole of the legal problem.

To decide that one request is a customer and the next is part of a flood, a mitigation tier has to look at them. There is no filtering technology that works without looking. Inspection is processing, and the categories inspected are not a configuration option the buyer can turn off without turning off the protection.

At minimum, a scrubbing tier processes:

• Source IP addresses, for every packet. On its own an address looks like network metadata. Correlated with access logs, session records or account activity — which is exactly what both the provider’s analytics and your own logging do — it points at an identifiable individual. That correlation test is the one most modern personal data definitions apply, and the regimes in this region are drafted broadly enough that arguing an IP address out of scope is a position you would have to defend rather than assume.
• Request headers and user-agent strings. Language preference, referrer, accept headers, client hints. The combination is rich enough to act as a device fingerprint, which is precisely why bot detection is built on it.
• Session cookies and tokens, wherever application-layer protection is in play. Without them there is no way to distinguish a signed-in customer with an unusual traffic pattern from a bot emulating a browser. Layer-7 defence and session-identifier processing are the same thing described from two directions.
• Request bodies, wherever the provider terminates TLS — and terminating TLS is a precondition for meaningful HTTP flood protection. That means form submissions, API payloads and anything else inside the encrypted channel is available in the clear on the provider’s systems.

Two consequences follow, and both are worth stating plainly before any legal analysis begins.

First, “we use cloud scrubbing but no personal data is involved” is not a position anyone can hold. The only genuine variables are which categories are processed, by which legal entity, in which country, and for how long.

Second, the exposure is continuous rather than incidental. A backup replicated abroad is a defined dataset moved on a schedule. A scrubbing tier in front of your service is every user, every request, permanently. When compliance teams underestimate this decision, it is almost always because they have mentally filed it as an attack-time arrangement.

Why processing abroad becomes a transfer question

Across the Gulf, the general shape of data protection law has converged on something familiar: a broad definition of personal data, a controller-and-processor split, obligations of transparency and security, and cross-border transfer that is permitted under conditions rather than prohibited outright. The conditions typically fall into recognisable families — transfers to jurisdictions assessed as offering adequate protection, transfers made under appropriate contractual or organisational safeguards, and narrow situation-specific exceptions.

That convergence is real, and it is also the trap. The families are similar; the contents are not. Which jurisdictions are treated as adequate, what a safeguard instrument must contain, whether a notification or an approval step attaches to it, how the supervisory authority expects the underlying assessment to be documented, and how far the regime reaches processing carried out abroad — these differ by state. Some regimes attach explicit conditions to processors and sub-processors; others place more of the weight on the controller’s own accountability. A transfer position built for one Gulf state is a useful starting draft elsewhere in the bloc and nothing more.

Nor is the personal data statute the only instrument in play. Several states in the region operate government data classification schemes, national cloud policies and critical infrastructure designations that attach handling and location conditions of their own, and those instruments sit in a different place from the data protection law and are supervised by different bodies. Financially supervised institutions carry outsourcing and resilience expectations from their central bank on top of both. It is entirely possible for a foreign scrubbing arrangement to be defensible under the personal data regime and still fail a government-data classification rule, or a sector outsourcing expectation, or an internal policy an entity adopted to satisfy a tender condition three years earlier.

The practical consequence for an architecture decision is not that cloud scrubbing is prohibited. It is that cloud scrubbing converts a network decision into a standing legal obligation — one that has to be assessed, documented, disclosed, kept current as the provider’s footprint changes, and defended to more than one authority. That obligation is perfectly manageable. It simply has a cost, and the cost is usually invisible at the point where the architecture is chosen.

Where you are licensed can matter more than where you sit

There is a structural feature of the region that catches groups out with some regularity: the major financial free zones operate their own legal systems, including their own data protection regimes with their own regulators. The Dubai International Financial Centre, Abu Dhabi Global Market and the Qatar Financial Centre each have data protection rules distinct from the surrounding national framework, and for groups that straddle that line in the UAE the entity-by-entity mapping this forces is the first piece of work in the project.

For a DDoS decision this has three concrete effects.

The applicable regime follows the contracting entity, not the building. Two subsidiaries of the same group, in the same city, on the same corporate network, may answer to different instruments and different regulators. The entity that signs the scrubbing agreement therefore determines which transfer rules govern it.

A group-wide position may not be portable. Security architecture is usually standardised across a regional group — the same provider, the same configuration, the same contract template. The compliance analysis behind it is not automatically transferable in the same way, and a shared service that inspects traffic for entities across several regimes needs a position per regime.

Intra-group traffic is still traffic. Where a shared scrubbing arrangement inspects traffic destined for affiliates in different jurisdictions, the analysis has to be done for each destination, not for the entity that happens to hold the contract.

None of this is an argument against operating regionally. It is an argument for knowing, before the architecture is fixed, how many distinct positions a given design commits you to maintaining. An in-country inspection tier reduces that number to the states you physically operate in. A shared foreign tier multiplies it.

“We do not store it” is not “we do not process it”

The most common reassurance offered in a procurement meeting is some version of: we do not store your traffic, we just pass it through. The answer is usually offered in good faith. It does not close the question, for two separate reasons.

The first is definitional. Processing, in every regime shaped like the ones in this region, is much broader than storage. Collecting, recording, organising, consulting, using, transmitting and erasing are all processing. Taking a packet, examining its header, comparing it against a behavioural baseline and deciding to drop it is processing in the fullest sense — and it occurs at the location of the scrubbing centre, whatever happens to the packet afterwards. Zero retention changes what a breach at the provider would expose. It does not change where the processing happened, and the transfer question is about location, not persistence.

The second is factual. Retention is almost never actually zero. Attack telemetry, flow records, sampled packets, event logs, classification decisions and reporting data all persist somewhere for some period, because they are the raw material of every incident report, dashboard and monthly summary the provider supplies. A provider that genuinely retained nothing could not tell you what it had blocked.

So the useful question is never “do you store it”. The useful questions are what, for how long, in which country, and held by which legal entity — asked separately for each category, because the answers usually differ. It is common for sampled packets to have a short life, event records a medium one and aggregate reporting data a long one, in facilities operated by different companies.

A related evasion worth naming: “the data stays in the region”. The region is not a jurisdiction. A facility in a neighbouring Gulf state is a cross-border transfer from where you sit, subject to whatever conditions your own regime imposes, and it may or may not be a jurisdiction your regime treats favourably. Ask for countries, not regions.

What an in-country tier actually changes

An on-premise mitigation tier does not answer the questions above more convincingly. It removes most of them.

No cross-border transfer arises for everyday traffic. Inspection happens on your own hardware, in your own facility, in the state whose law you are already subject to. There is no transfer to assess, no basis to select, no safeguard instrument to negotiate and no country list to keep under review.

No processor relationship arises for inspection. Controller and processor are the same entity. There is no processing agreement to maintain over this activity, no sub-processor chain to assure, and no notification mechanism to monitor when the provider changes a leased facility operator you never knew about.

Your disclosure to individuals gets shorter, not longer. There is no additional recipient category to describe, and no foreign country to name.

Your logs keep their integrity. This one is underrated and it matters wherever a logging or record-keeping obligation applies. When traffic is diverted through a scrubbing tier, what reaches your servers has traversed the provider’s network. Depending on how client addresses are conveyed, your access logs may record the mitigation path rather than the original source, or may depend on a forwarded-header convention that itself has to be trusted, configured and documented. Any obligation that assumes an unbroken, locally timestamped record of who connected to your service is easier to satisfy when nothing sits in front of you.

You control retention and evidence. After an incident, the reconstruction is built from equipment you own, at the fidelity you chose, over the retention window you set, on your timetable rather than a support queue’s.

Look at the first row of that diagram carefully. In a cloud-only design it is not attack traffic that is inspected abroad — it is all traffic. That is not a defect of cloud scrubbing; it is a structural property of it, and it is the property that turns an engineering choice into a legal one.

The honest limit of an on-premise tier

An article that stopped there would be selling something. The constraint has to be stated without softening: an on-premise appliance cannot filter traffic that has already saturated the circuit delivering it.

If your access circuit is 10 Gbps and 40 Gbps arrives, the circuit is full before the appliance is consulted. Whether that appliance is rated for 20 Gbps or 200 Gbps is irrelevant above the line, because the bottleneck sits upstream of it. Any vendor conversation that does not raise this point unprompted should be treated as a warning sign.

So “we will keep everything in country and skip the upstream tier” is only correct for organisations whose exposure genuinely is not volumetric: internal services, segments behind an already protected perimeter, environments where the threat model is application abuse rather than bandwidth exhaustion. Any prominent public-facing service will eventually meet an attack larger than its circuit, and rented flood capacity is neither scarce nor expensive.

The design that satisfies both constraints is on-premise-first hybrid. All everyday traffic is inspected in country, on equipment you control, whether or not an attack is under way. An upstream tier engages only above the circuit line, under thresholds and conditions written into the contract and the runbook. Cross-border processing then stops being a permanent state of affairs and becomes an exceptional, bounded, documentable event — which is a far easier thing to describe in a transfer assessment and in a privacy notice than a continuous arrangement. Appliances designed to cover layers 3 through 7 in a single in-line device fit this shape directly, because keeping the everyday inspection local is exactly what removes the standing transfer position.

Two traps to avoid in the hybrid case. The first is the privacy notice that says no data leaves the country: in a hybrid design that is inaccurate, and it is contradicted by your own runbook. Describe the conditions instead. The second is the hybrid that has never been exercised — a diversion arrangement that has not been tested is a contractual assertion, not a capability, and the fail-back is the half that is skipped most often.

Appliance	Foreign cloud scrubbing	In-country on-premise tier	On-premise-first hybrid
Where everyday traffic is inspected	Provider points of presence, wherever they sit	Your facility, on hardware you own	Your facility by default; abroad only during diversion
Cross-border transfer position to maintain	Continuous, for every user, every day	None arises for inspection	Defined, time-bounded diversion windows
Number of regimes the position must satisfy	Every state and free zone you operate in	The one you sit in	As many, but only for the diversion window
Who holds retained telemetry	The provider, under its retention policy	You, under yours	Split by period
Sub-processor chain to assure	Provider plus leased facility operators	Hardware supply chain only	Scoped to the diversion service
Original source address in your own logs	Reaches you through the provider path	Preserved locally, timestamped by you	Preserved except during diversion
Capacity ceiling	Provider backbone	Your access circuit	Circuit locally, backbone above it
Test you can schedule without permission	Only what the provider agrees to run	Any, at your own convenience	Local tests yours; diversion drill joint

Rows describe architecture classes, not products. Row two is the one that changes the legal workload, and row three is the one most groups underestimate: a regional business does not have one transfer position to defend, it has one per regime it touches.

What to specify contractually

If any tier is bought as a service, the following belong in the requirements document and then in the signed agreement. A slide in a sales presentation is not an artefact, and a footnote on a status page is not a commitment.

The countries of the facilities that will handle your prefixes. Not the provider’s global footprint — the specific centres your traffic will be steered to, named in the contract, with a notification obligation before the list changes. Ask specifically whether traffic can be re-routed to a different facility during a large event or a maintenance window, because that is exactly when the country list quietly changes.

Whether TLS is terminated, where, by which legal entity, and who holds the keys. If it is terminated, request bodies are processed, and your transfer position and privacy notice both have to say so. If it is not, be equally clear about what application-layer protection you are therefore not receiving.

Data categories and retention, itemised. Attack telemetry, flow records, sampled packets, event logs and reporting data listed separately, each with a period, a country and a holder. One blanket retention figure covering everything usually means nobody has checked.

The sub-processor list and the change mechanism. Global providers frequently lease points of presence from third-party facility operators and use third-party services in the delivery path. The entities that touch your traffic are often more numerous than the entities named in your contract.

The contracting entity and its group structure. Which legal person are you contracting with, in which jurisdiction, and which affiliates perform the processing? This determines both your transfer analysis and who you would actually be litigating against.

Evidence rights after an incident. What logs, captures, timelines and reports you may obtain, in what format, within what time, and at what cost. Silence here is the single most common reason an organisation cannot reconstruct its own incident for a regulator.

Diversion and fail-back terms, for hybrid designs. The trigger thresholds, who may invoke them, the out-of-band channel for invoking them when your circuit is saturated, the maximum duration and the conditions for returning to normal. This clause is simultaneously an operational requirement and the technical definition of your exceptional-transfer window, which means legal and network engineering have to draft it together.

Testing rights. Your entitlement to schedule a diversion exercise, the notice period and the permitted frequency. Without it, you cannot evidence that the arrangement works, and the first live test will be a real attack.

Assistance and notification obligations. What the provider will do if a supervisory authority asks you where your traffic is inspected, if a data subject exercises a right, or if the provider itself receives a request from an authority in its own jurisdiction.

A decision framework

Two axes, taken together rather than separately.

The regulatory axis. If you are a government body, a critical infrastructure operator, a supervised financial institution, a healthcare provider or anyone processing data in a category your regime treats as sensitive, having all everyday traffic inspected outside the country is a defensible position that you will spend real and recurring effort defending — to more than one authority, at every review cycle, and again each time the provider’s footprint changes. For this segment an in-country inspection tier is effectively settled, and the only live question is how the tier above it is arranged and bounded.

The threat axis. If a plausible attack against you exceeds your access circuit — and for any prominent public service it does — an in-country tier alone is insufficient, however well it documents.

For most regulated buyers in the Gulf both axes point at the same design: everything in country by default, upstream engagement exceptional, contractually bounded and rehearsed. The inverse arrangement — cloud-first with an appliance behind it — costs more, because you pay for continuous clean bandwidth and hardware, and it concedes the residency argument anyway.

Cloud-first remains a reasonable answer for smaller organisations outside any mandatory scope, with no regulated data and no team to operate an appliance. The correct response there is not to obscure the transfer but to document it properly, name the countries, and tell users the truth.

Sources and further reading

We do not reproduce regulatory text from memory and we do not paraphrase paywalled analyst research. The list below is what to obtain, and from whom.

Primary law, per state. Obtain the personal data protection instrument for each state you operate in, in its current version, from the issuing authority or official gazette — together with any implementing regulations, since the cross-border transfer conditions are usually elaborated there rather than in the primary text. For Saudi Arabia, that means the Personal Data Protection Law and the implementing instruments issued by the Saudi Data and Artificial Intelligence Authority, including those dealing specifically with transferring personal data outside the Kingdom. Do not work from a law-firm summary at the architecture stage; summaries are written for orientation and are frequently a version behind.

Free-zone regimes. Where a group entity is licensed in the Dubai International Financial Centre, Abu Dhabi Global Market or the Qatar Financial Centre, obtain that zone’s data protection instrument and guidance from its own regulator. These are separate regimes, not local implementations of the surrounding national law.

Government data and critical infrastructure instruments. Where you handle government data or operate designated infrastructure, obtain the applicable classification scheme, cloud policy and sector cybersecurity framework from the relevant national authority. These commonly impose location and handling conditions that are independent of the personal data regime and are assessed by a different body.

Sector supervisors. Financially supervised entities should read their central bank’s cybersecurity and outsourcing expectations alongside the national baseline; our SAMA framework guide works through the Saudi case, and the NCA ECC guide covers the evidence an assessor expects. For the vendor-side question of which legal systems reach the manufacturer of your equipment, see the vendor jurisdiction risk guide; for the underlying architecture trade-offs, the comparison of cloud, on-premise and hybrid designs.

Technical standards. If you want the interface between your own tier and an upstream tier to be standards-based rather than proprietary — which matters for exit planning and for multi-vendor designs — the relevant documents are RFC 8955 and RFC 8956 for BGP FlowSpec, and RFC 9132 and RFC 8811 for DOTS, the standardised signalling protocol for cross-organisation mitigation requests. NIST SP 800-189 covers resilient interdomain routing, and NIST SP 800-61 remains the most widely used reference for structuring incident handling so that it produces records an assessor can read.

Analyst coverage. The category is covered in Gartner’s Market Guide for DDoS Mitigation Solutions, Forrester’s The Forrester Wave: DDoS Mitigation Solutions and IDC’s IDC MarketScape for the segment. Where a vendor claims analyst recognition, ask for the current edition rather than a screenshot; positions move between editions, and Gartner restricts public quotation of its research, so a vendor quoting it publicly should be able to show reprint rights.

Public attack data. The quarterly DDoS reports published by Cloudflare and Akamai are the most widely cited open sources for attack volumes and vector mix, and both are compiled from their own customer bases, which is worth holding in mind when reading their regional breakdowns. CVE-2023-44487, the HTTP/2 Rapid Reset flaw, remains the clearest public example of a protocol-level weakness that no choice of topology could have isolated — a useful corrective to any assumption that architecture alone closes this risk.