Kazakhstan's Data Localisation Requirements and On-Premise DDoS Mitigation

Most Kazakh organisations buy DDoS protection as a network engineering decision and discover, some way into the procurement, that it is also a data decision. The trigger is usually a single question from legal or from an auditor, and it is a fair one: if our users’ traffic is being inspected in a scrubbing centre outside the country, what exactly is being processed there, and how does that sit with our obligation to keep personal data about Kazakh citizens in Kazakhstan?

The honest answer is not that cloud scrubbing is forbidden. It is that the question is real, it does not have an obvious answer, and the architecture you choose determines whether you have to answer it at all. This guide works through what a scrubbing tier must process to function, why the localisation regime turns that from an implementation detail into a position you have to defend, what an on-premise tier changes, and what belongs in the contract if you keep an upstream layer.

What a scrubbing tier must process to work at all

The marketing description of cloud protection — “we clean the bad traffic” — hides the mechanism. Filtering is a classification problem. To decide that one request is a customer and the next is part of a flood, something has to look at the traffic, and looking at traffic means processing data about the people generating it. There is no technology that filters what it has not examined.

At a minimum, a scrubbing tier handles:

• Source IP addresses, for every packet. This is the primary input for rate limiting, reputation scoring and geographic policy, and there is no filtering design that does without it.
• Request headers and the user-agent string. Header ordering, TLS fingerprints and language preferences are how modern bot detection distinguishes a real browser from an imitation. In combination they are precise enough to constitute a device fingerprint.
• Session identifiers. Once you buy application-layer protection, cookies and tokens enter the picture, because the whole point is to tell a signed-in customer apart from a script replaying plausible requests.
• Request bodies, where the provider terminates TLS. Effective HTTP flood mitigation generally requires it, and it means form fields and API payloads are processed at the scrubbing tier as well.

The point worth holding on to is that none of this is a vendor’s choice or a tuning parameter. It is the mechanism. A statement of the form “we use cloud scrubbing but no personal data is processed” is not a compliance position; it is a technical impossibility.

Why localisation makes this a question rather than a detail

Kazakhstan’s personal data regime is built on a requirement that databases containing personal data about Kazakh citizens be held on infrastructure physically located in the country. That is a stronger structural constraint than the transfer-based regimes familiar from Europe or Türkiye, because it attaches to where data lives rather than only to the conditions under which it may travel. Cross-border movement is treated as its own question, permitted on defined grounds rather than freely — so an organisation with a foreign processing tier has two distinct things to explain, not one.

Applying that to a scrubbing tier produces a genuinely contested reading, and it is worth setting out both sides rather than pretending the answer is obvious.

The argument that localisation is not directly engaged. Scrubbing is largely transient. Packets are examined in flight and either forwarded or discarded; nothing is assembled into a database of Kazakh citizens in the sense the requirement was written for. On this reading the localisation duty is not triggered, and what remains is a cross-border processing question to be handled on its own terms.

The argument that it is engaged. Transience is a claim about the fast path, not about the whole service. Attack telemetry, sampled packets, event logs, dashboard data and the incident reports you are given all persist on the provider’s side, in the provider’s country, for the provider’s retention period. Once source addresses and session identifiers are retained abroad and made queryable, the distinction between “transient inspection” and “a database” gets thin. Add the fact that the accountable party is you rather than the provider, and the safe assumption is that you will be asked to justify the arrangement rather than to assert that it falls outside scope.

Neither reading is frivolous. What matters practically is that the second is the one a supervisor is more likely to start from, and that the cost of being wrong falls on the organisation, not on the vendor whose slide deck said the traffic was only passing through.

Why “we do not store anything” is not an answer

This is the sentence that surfaces in almost every procurement conversation, and it is usually offered in good faith. It still does not close the file, for two reasons.

The first is conceptual. Examining a packet and deciding whether it is hostile is an operation performed on personal data. A retention period of zero changes the consequences of a breach; it does not change the fact that the processing happened, in a particular place, under a particular legal system.

The second is empirical. Retention is almost never actually zero. If your provider gives you a post-incident report showing the top source networks, the attack vectors and the timeline, that report was generated from retained data. If the portal lets you look back at last month’s events, that is retained data. If the provider’s detection improves because it learned from your attack, something about your traffic was kept and used. None of this is sinister — it is how the service works — but it means the useful question is a four-part one: what is retained, for how long, in which country, and who else can reach it.

Appliance	Foreign cloud scrubbing	On-premise appliance	On-premise-first hybrid
Where everyday traffic is inspected	Provider points of presence abroad	Your facility, on hardware you own	Your facility by default; abroad only during diversion
Localisation position to document	Continuous, for every user, every day	None arises for inspection	Defined, time-bounded diversion windows
Who holds the retained telemetry	The provider, under its own retention policy	You, under yours	Split — yours by default, provider's for the window
Sub-processor chain to assure	Provider plus leased PoP operators	Hardware supply chain only	Scoped to the diversion service
Original source address in your logs	Reaches you through the provider path	Preserved locally and timestamped by you	Preserved except during diversion
Capacity ceiling	Provider backbone	Your access circuit	Circuit locally, backbone above it
Test you can schedule without asking	Only what the provider agrees to run	Any, at any time	Local freely; diversion drill jointly

Rows describe architecture classes rather than named products. For a regulated buyer in Kazakhstan the second row usually decides the purchase, because it is the only row that changes from a paperwork exercise into a structural fact.

What an on-premise tier changes

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

• No cross-border processing arises for everyday traffic. Inspection happens on your equipment, in your facility. There is nothing to justify because nothing crossed a border.
• No processor relationship is created. The controller and the entity doing the inspecting are the same legal person. There is no processing agreement to negotiate, no sub-processor chain to enumerate, and no assurance programme to run over a third party.
• No additional recipient category exists. Your privacy notice and internal records do not have to describe a foreign recipient of user traffic, because there is not one.
• You hold the evidence. After an incident you have your own full-fidelity capture, under your own retention policy, rather than a summary produced within somebody else’s.

That last point is underrated. Localisation arguments tend to be conducted in the abstract, but the practical daily benefit of local inspection is evidentiary: you can pull a packet capture without raising a support ticket, you set the retention window rather than inheriting it, your access logs keep the original client address and a locally generated timestamp with no provider hop in the chain, and you can schedule a test at a time that suits your audit calendar rather than someone else’s change window.

Where sectoral expectations raise the bar

The general data protection regime is the floor, not the ceiling. Two categories of buyer in Kazakhstan work to more than that.

Licensed communications operators and operators of significant information infrastructure are expected to keep their security architecture, monitoring and incident handling under a degree of national oversight that a foreign, contractually mediated service sits awkwardly against. The issue is less prohibition than visibility and control: a supervisor asking how an incident was detected and mitigated is asking about a capability you are supposed to be operating, and “our provider handled it and sent us a report afterwards” is a weaker answer than one supported by your own telemetry.

Financial institutions work to sectoral information security expectations layered on top of the general regime, and outsourcing a control does not transfer responsibility for it. In practice, banks in Kazakhstan face the same pattern as banks in other tightly supervised markets: outsourced arrangements are permitted, but the assurance burden — provider selection, contractual controls, ongoing oversight, exit planning — is heavier than the burden of running the control yourself. That calculus is often what decides an on-premise tier, quite independently of the localisation argument.

The honest limit of an on-premise tier

An article that stopped here would be selling something. The limit is structural and it matters: an on-premise appliance cannot stop an attack that saturates your access circuit. If you have a 10 Gbps uplink and 40 Gbps arrives, the circuit fills before the appliance gets a chance to act. Whether the box is rated at 20 Gbps or 200 Gbps is irrelevant above that threshold, because the bottleneck is the link in front of it.

So the conclusion “we will buy an appliance for localisation reasons and skip the upstream layer” is only correct for organisations that are not realistic volumetric targets — a category that keeps shrinking for anything public-facing. The workable design is the inverse of the usual cloud-first pitch: all everyday traffic inspected in country on the local tier, with the upstream layer engaged only above circuit capacity and under conditions agreed in advance. Cross-border processing then stops being a permanent condition and becomes an exceptional, documented, time-bounded event, which is a far easier thing to describe honestly in a privacy notice and to defend in a supervisory conversation. An appliance that performs its full L3-to-L7 classification on your own hardware, with no vendor-operated intelligence cloud in the decision path, fits that pattern directly, and the same test is worth applying to every candidate on the shortlist.

One trap deserves naming. In a hybrid design, writing “no data is transferred abroad” in a privacy notice is a false statement. The correct formulation defines the circumstances, purpose and duration of the exceptional transfer.

The vendor question arrives at the same time

Kazakh buyers rarely get to consider localisation on its own, because the shortlist raises a second issue simultaneously. The incumbent options in the region have for years been Russian platforms alongside Chinese equipment, and both now carry continuity problems that have nothing to do with product quality: payment and renewal friction on one side, downstream interconnection and counterparty restriction risk on the other.

These are different questions and they should not be conflated. Localisation is about where processing happens. Vendor jurisdiction is about which government holds a lever over the company that built, licenses and supports your equipment — and that lever reaches an appliance sitting in a rack in Almaty just as surely as it reaches a cloud service. A product can satisfy the localisation requirement perfectly while concentrating your entire defence under a single foreign export-control regime.

The two analyses interact in one specific way that is easy to miss. If your local appliance depends on a vendor-operated threat feed to classify traffic effectively, then you have reintroduced a continuous outbound channel and a foreign dependency into an architecture you bought precisely to avoid them. Ask what the product does when that channel is unavailable for ninety days, and test the answer during acceptance rather than during an incident. The full analysis is in our vendor jurisdiction risk guide, and it is worth running both frameworks over the same shortlist before deciding.

What to specify in the contract

If any upstream tier remains in the design — and for most organisations it should — these are the clauses that convert a verbal assurance into something you can show an auditor. Ask for them as contractual annexes; a slide is not evidence.

1. The countries of the scrubbing centres that will actually handle your prefixes. Not the provider’s global PoP map. Name the specific facilities, and require notice before they change.
2. TLS termination. Whether it happens, where, by which legal entity, and who holds the keys. If it happens, request bodies are being processed, and that changes what your privacy notice has to say.
3. Data categories and retention, itemised. Attack telemetry, sampled packets, event records and reporting data listed separately, each with its retention period and the country in which it is held.
4. The sub-processor list. Most global providers lease regional points of presence from third-party data centre operators. You need the list and a change-notification duty, because those operators are part of your chain whether or not you were told about them.
5. The lawful basis for the cross-border element, in writing, with the signed instrument attached rather than described.
6. Diversion conditions in a hybrid design. The threshold that triggers upstream engagement, the maximum duration, the criteria for returning traffic to local handling, and who is authorised to make each decision. This is the technical counterpart of the exceptional-transfer language in your privacy notice.
7. Deletion and exit. What happens to retained telemetry at termination, on what timescale, and how deletion is evidenced.
8. Standards-based signalling to the upstream tier. BGP FlowSpec and DOTS rather than a proprietary integration, so that changing provider is a configuration change rather than a redesign.

A decision frame

Two axes, weighed together rather than separately.

The regulatory axis. If you are a state body, an operator of significant information infrastructure, a financial institution, or an organisation processing sensitive categories of personal data, having all everyday user traffic inspected abroad is a difficult position to hold. In that segment a local inspection tier is effectively mandatory and the real discussion is only about how the upstream layer is arranged.

The threat axis. If your volumetric exposure is genuine, a local tier alone is not sufficient, for the circuit reason above. Put the two axes together and most regulated Kazakh buyers land on an on-premise-first hybrid: local by default, upstream by exception.

For small organisations outside regulated sectors, with no in-house network team, a cloud-first architecture remains a reasonable engineering choice. The obligation in that case is not to conceal the cross-border element but to establish its basis and describe it accurately — which is exactly the work that an on-premise-first design lets you skip.

Sources and further reading

We do not paraphrase paywalled analyst research or attribute figures to it, and we do not reproduce legal provisions from memory. The list below is what to read, and what to request from a provider.

Kazakh legal instruments. Read the current consolidated text of Kazakhstan’s law on personal data and its protection, together with the implementing acts on the localisation of databases, from the official legal information system at adilet.zan.kz rather than from a secondary summary — the localisation provisions have been amended more than once and law firm commentary ages quickly. Communications operators and operators of significant information infrastructure should read their sectoral obligations alongside it; financial institutions should read the information-security and outsourcing requirements applicable to their licence. Where a specific position matters commercially, obtain local counsel’s written view rather than relying on any vendor’s characterisation, including ours.

Comparative context. Our companion analyses of vendor jurisdiction risk and of cloud, on-premise and hybrid architectures cover, respectively, the supply-chain and the capacity dimensions of the same decision.

Analyst coverage of the category. Gartner’s Market Guide for DDoS Mitigation Solutions, Forrester’s The Forrester Wave: DDoS Mitigation Solutions and the IDC MarketScape series describe the vendor landscape but not, as a rule, data residency or jurisdictional exposure. Ask for the current edition rather than a screenshot, and expect to do the residency analysis yourself. Where a vendor quotes Gartner publicly, reprint rights are required and it is reasonable to ask to see them.

Technical standards worth naming in the tender. RFC 8955 and RFC 8956 for BGP FlowSpec; RFC 9132 and RFC 8811 for DOTS, the standard signalling protocol for requesting mitigation between organisations; NIST SP 800-161 for supply chain risk management; NIST SP 800-189 for routing resilience.

Public attack data. The quarterly DDoS reports published by Cloudflare and Akamai are the most commonly cited open sources for volume and vector distribution. Both are compiled from their own customer bases and carry the sampling bias that implies.