Skip to content
Blog

The National Data Center arrives: "data in-country" and the on-prem question

Vũ Anh TuấnVũ Anh Tuấn · Content editor, Tetra··6 min read
The National Data Center arrives: "data in-country" and the on-prem question

Photo: imgix / Unsplash

When a country invests in building a data center at national scale, it is not just a building full of servers — it is a statement of direction. The National Data Center going live in mid-2025 reinforces a message already emerging through the Data Law and the country's personal-data rules: data should stay in-country and under control. For enterprise decision-makers this is not industry news to skim; it is a signal to factor into infrastructure strategy now.

This piece looks at five things: what the National Data Center is and why it matters, how it shifts the "data in-country" expectation, what that says for an organization's architecture choices, on-premise versus domestic cloud, and a short checklist to get started.

What the National Data Center is and why it matters

The National Data Center is shared data infrastructure at national scale, led by the Ministry of Public Security, and part of Vietnam's broader push on data infrastructure and governance. It is tied to the Data Law (60/2024/QH15, effective 1 July 2025), the text that lays the groundwork for building, connecting and exploiting databases at national scale. In plain terms, it is where many data flows that used to sit scattered across ministries, sectors and localities converge and are coordinated.

What matters here is not the hardware but the policy signal. A state that commits resources to centralizing data nationally is sending a clear message: data is a strategic asset, and where it sits is a deliberate decision, not a default set by whichever vendor is most convenient. When the public sector holds itself to that standard, the standard gradually spreads to how regulators, partners and the wider market view where any organization keeps its own data.

How it shifts the "data in-country" expectation

Until recently, "where should data live" was mostly a technical decision: pick whatever is cheap, fast and easy to integrate. National-scale centralized infrastructure, arriving alongside a legal frame that keeps tightening on transfers abroad, moves that question onto a different plane. It is no longer just "where is it convenient" but "where can I prove I control it when asked".

From exception to default. A few years ago, keeping data in-country or choosing on-premise was often seen as a special requirement of defense, security or finance. The new context makes it a broader expectation: an ordinary business processing the personal data of users in Vietnam now also needs to answer where that data sits and who can touch it.

Data sovereignty is no longer only the public sector's concern. When the state treats citizen data as an asset to keep within domestic jurisdiction, that logic carries naturally to business. Legal obligations to data subjects remain with the organization that collects the data, no matter where the system sits or who runs it.

Expectations move faster than regulation. Even before a specific rule reaches a given sector, the expectations of partners, major customers and regulators have already shifted. An organization that prepares early for the question "where does your data live" avoids scrambling to fix it later.

What it means for enterprise architecture

Once the "data in-country" expectation becomes real, it touches how systems are designed, not just where machines sit. Four points are worth thinking about early.

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. Classify the data first, choose the location second.

Access logging. To prove who touched what and when, the system must record 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. 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 fewest people check.

Exit capability. The simple test: if the contract ends tomorrow, in what format do you get all your 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.

There is a notable paradox here. The state centralizes data nationally, but for each business the lesson is to keep data under its own control. A large central store is also a large target, and the safe path for an individual organization is still to bring data onto infrastructure its own technical team can access and control.

On-premise or domestic cloud

"Keeping data in-country" comes in several degrees in practice, not just one, and it does not mean "no cloud".

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: patching, backup monitoring and recovery drills are all your job.

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.

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 always comes with responsibility. For most organizations the sensible answer is a mixed architecture: core systems and personal data on-premise or in a domestic private cloud, elastic edge workloads rented from a public cloud. We covered the trade-offs between models in more depth in on-premise or cloud, and the in-country storage duty itself in data localization.

A checklist to get started

You do not need to wait for a specific rule to reach your sector before acting. These five steps can be done now:

Inventory your data. List your systems and classify data by sensitivity and legal obligation, before discussing where it sits.

Mark what must stay in-country. Clearly identify personal data, sensitive data and core systems.

Check where things currently sit. For each system in use, confirm where the data and its backups actually live, including the provider's replication regions.

Review logs and evidence. Can you answer who accessed which data, and when.

Draw a roadmap. Decide what moves to on-premise or a domestic private cloud, what stays flexible, in order of risk.

Tetra eOffice and Manta Security both run on your infrastructure, keeping data and logs in a database your own technical team can access — squarely in the spirit of "data in-country, and in your systems". If your organization is reviewing its data strategy in light of this new context, book a consultation to identify which data must stay close, which parts can stay flexible, and a sensible migration path.

Related articles

Free resource

Personal Data Protection checklist

Review your business before the law takes effect on 01/01/2026.

Get the checklist