Data localization: why keeping data in-country is becoming the norm

Data has no technical borders, but it increasingly has legal ones. That is why "data localization" — storing and processing data in-country — is shifting from a technical option to a legal expectation in Vietnam. For decision-makers the question is no longer "where is it convenient to keep data" but "where can I prove I control it when asked".

This piece explains what data localization actually is, why it is becoming the norm, what it demands of your architecture, when a business is obliged to localize, and a checklist to get started.

What data localization is, and is not

Data localization is the requirement to keep certain data inside the territory where it originates, rather than letting it flow freely to a data center in another country. At its most basic it poses two concrete questions: where does the data physically sit, and who has the right to touch it.

A few concepts often get lumped together and are worth separating:

• Data residency. The primary copy of the data lives on servers in-country. This is a requirement about where data "is".
• Data sovereignty. The data falls under Vietnamese law and the organization can prove who accessed it and when. This is a requirement about rights, not just location.
• Cross-border transfer limits. Some categories of data may only move abroad when specific conditions are met, rather than being banned outright.

Data localization does not mean "no cloud" or "everything on-premise". It means you must know which data has to stay close, and have a way to prove it.

Why in-country storage is becoming the norm

International analysts note Vietnam, like many countries, gradually tightening requirements on in-country data storage and control. The trend comes from three drivers stacked on top of each other.

• The legal driver. Domestically, several major texts reinforce this direction. The Law on Cybersecurity 2018 and Decree 53/2022/ND-CP impose an in-country storage duty for certain categories of data generated by users in Vietnam. The Data Law (60/2024/QH15, effective 1 July 2025) treats using an offshore platform to process data as a form of cross-border data transfer and processing. The Law on Personal Data Protection (91/2025/QH15, effective 1 January 2026) and Decree 356/2025 detailing it raise obligations over personal data to statute level. When the law asks you to prove where data is and who controls it, "anywhere is fine" is no longer a safe answer.
• The sovereignty driver. The state, and businesses too, increasingly treat citizen data and core operational data as strategic assets. Keeping data within domestic jurisdiction reduces dependence on a single vendor's decision or a policy set abroad.
• The risk driver. When data sits on someone else's infrastructure in another region, their incident becomes your incident, yet you can only wait for a notification. Your legal obligations to data subjects remain yours, even when someone else runs the system.

These drivers do not exclude each other. They push toward the same conclusion: where data sits is a decision to weigh up front, not a vendor default.

What "in-country / on-premise" means in practice

In practice, "keeping data in-country" comes in several degrees, not just one.

• On-premise. Data lives on servers the organization owns or colocates, inside its own network. This is the highest level of control and also the highest level of operational responsibility.
• Domestic private cloud. Dedicated infrastructure, placed in a domestic data center or a dedicated zone at a Vietnamese provider. You keep control at the resource and access layer while getting provisioning speed close to public cloud.
• Public cloud with a Vietnam region selected. Still a shared service, but data is pinned to an in-country region and this is written into the contract, rather than defaulting to the nearest region.

The surest way to keep data in-country and under control is to put it on your own infrastructure. On-premise is not nostalgia — it is a pragmatic answer to a tightening legal environment. But on-premise is not automatically safe: a server left unpatched with no off-site backup is riskier than a well-run managed service. Control comes with responsibility.

Implications for architecture

Once localization becomes a requirement, it touches how systems are designed, not just where machines sit.

• Data partitioning. You need a clear boundary between data that must stay in-country and data that can be flexible, rather than mixing them and having to localize everything because one part is sensitive.
• Access logging. To prove who touched what, the system must record access logs fully and keep them long enough. On-premise and private cloud give you this capability directly; SaaS leaves you dependent on vendor reports.
• In-country backup and recovery. Backups are data too. If the primary copy is in Vietnam but automated backups push to a foreign region, the in-country storage duty can be breached in exactly the place few people check.
• Exit capability. The simple test: if the contract ends tomorrow, in what format do you get all the data back, how long does it take, and what software can read it? Open standards and documented schemas are what stop localization from turning into a new kind of vendor lock-in.

We discussed the trade-offs between models in more depth in on-premise or cloud.

When a business must localize data

Not all data must stay in-country, but some cases lean firmly toward keeping it close.

• Data containing personal information of users in Vietnam, especially sensitive data.
• Enterprises providing telecom, internet or value-added services that process user data in Vietnam, falling under the in-country storage rules.
• Systems holding state secrets, trade secrets, HR records or sensitive customer data.
• Core systems where losing the data, or access to it, halts the organization for a long time.

For data outside these groups — public websites, test environments, workloads that only live through a short campaign — cloud remains a sensible choice. On penalties, be careful: sanctions attach to specific conduct under current regulations, and cross-border transfer violations have their own treatment; this should not be read as a single blanket fine applied to every violation. Details should be checked against the texts and against legal advice for each situation.

A checklist to start

• Inventory your data. List the systems and classify data by sensitivity and legal obligation before discussing where it goes.
• Identify what must stay in-country. Clearly mark personal data, sensitive data and core systems.
• Check current locations. For each system in use, confirm where the data and its backups actually sit, including any vendor replication regions.
• Review logs and evidence. Can you answer who accessed which data and when.
• Prepare an exit path. Ask about export format and timing in the first negotiation round, not when you want to leave.
• Draw a roadmap. Decide what moves to on-premise or domestic private cloud, what stays flexible, ordered by risk.

Tetra eOffice, Manta Security and Molly Reader all run on your infrastructure, keeping data and logs in a database your own engineers can access. If your organization is reviewing its data strategy, book a consultation to help identify what must stay close, what can be flexible, and a sensible transition path.