Uzbekistan Law No. 213:
What It Means for Your Cloud Infrastructure
Uzbekistan's Law No. 213-II "On Personal Data," adopted in 2019 and amended several times since, is not theoretical compliance risk. Companies that collect personal data of Uzbek citizens — regardless of where the company is incorporated — are required to process and store that data in databases physically located within Uzbekistan. That means your database server, not your application logic, determines compliance status.
What the Law Actually Covers
Law No. 213-II defines "personal data" broadly: name, passport number, phone number, email address, biometric data, geolocation data, and any information that allows identification of a specific individual. If your application captures any of these from Uzbek users — which includes virtually every consumer application and most B2B SaaS tools — you are subject to the law.
The enforcing body is the Agency for Personal Data Protection (Shaxsiy ma'lumotlar bo'yicha agentlik). Penalties for non-compliance include regulatory audits, mandatory suspension of data processing activities, and potential restrictions on operating in the Uzbek market. For a company that depends on Uzbek users or customers, suspension of data processing is effectively suspension of the product.
The Most Common Non-Compliant Pattern
-
AWS Frankfurt as primary database — Many Uzbek companies run PostgreSQL or MySQL on AWS eu-central-1 and believe that because their users and application servers are in Uzbekistan, they are compliant. They are not. The storage location is the point of compliance — and Frankfurt is in Germany.
-
"We just read from it from Uzbekistan" — The direction of data access is irrelevant to the law. The law concerns where data is stored and processed, not where queries originate. Querying a Frankfurt database from a Tashkent application server does not satisfy the localisation requirement.
-
Managed SaaS tools with foreign data storage — CRM systems, analytics platforms, and marketing tools that store personal data in foreign jurisdictions by default. If you're feeding Uzbek user data into Salesforce on US servers without a compliant data handling arrangement, this is also a Law 213 issue.
What a Compliant Architecture Looks Like
The rule is straightforward: the primary database containing personal data of Uzbek citizens must reside on servers physically in Uzbekistan. The good news is that this does not prevent you from using foreign infrastructure for everything else. CDN edge nodes, analytics pipelines (processing anonymised or aggregated data), machine learning training on anonymised datasets, and application servers can legally operate outside Uzbekistan, as long as the canonical store of personal data is inside the country.
Compliant Architecture Pattern
-
Primary database in Uzbekistan — PostgreSQL or MySQL running on servers physically located in-country (e.g., Hyper App Tashkent region). This is where personal data is written and stored.
-
Analytics on anonymised data — Aggregated, de-identified analytics can flow to foreign analytics platforms. The key is that no individual-identifiable data leaves the country.
-
CDN for static assets — Images, scripts, and static files can be served from global CDN edge nodes. These do not contain personal data.
-
Audit logging in-country — Access logs containing user identifiers should also remain in Uzbekistan to support potential regulatory audits.
GDPR Analogy — and Where It Differs
If you are familiar with GDPR's data residency requirements for EU citizens, Law No. 213 follows a similar conceptual model: personal data of citizens of a given jurisdiction must be processed under that jurisdiction's rules, with the baseline being storage within the country. The key difference is scope. GDPR governs the entire EU and includes an extensive framework for cross-border data transfers with adequate protection. Law No. 213 is narrower — it currently focuses primarily on the localisation requirement, without the same depth of transfer mechanism framework. This makes localisation the practical compliance strategy for most companies.
The simplest path to compliance is also the best performing one for your Uzbek users: move your primary database to a server physically in Uzbekistan. On Hyper App infrastructure, that means TTFB from Tashkent drops from 150-250ms (Frankfurt) to 8-25ms — a performance improvement that has measurable impact on user engagement and conversion rates, independent of any compliance benefit.
"We didn't realize we were out of compliance until a legal review flagged our AWS Frankfurt database. Moving to a Tashkent-based database was faster than the legal paperwork we'd have needed to stay on AWS."
— CTO, Uzbek FinTech Platform