Skip to content
Blog

On-premise or cloud: choosing without losing data sovereignty

Vũ Anh TuấnVũ Anh Tuấn · Content editor, Tetra··9 min read
On-premise or cloud: choosing without losing data sovereignty

Photo: Growtika / Unsplash

The shortest question we hear from customers is this: where should company data live? The short answer is that the more a dataset carries legal obligations, and the harder it is to replace once lost, the more it belongs somewhere you can independently prove you control. For most Vietnamese organizations that means a mixed architecture — core systems and personal data on-premise or in a private cloud, elastic edge workloads rented from a public cloud.

The on-premise vs cloud debate usually collapses into a monthly invoice. The axis that actually matters is data sovereignty: who decides where data sits, who touches it, and what evidence you can produce when a regulator asks. This piece compares the three models honestly, without bashing cloud, and ends with a decision framework you can use today.

Sơ đồ so sánh on-premise, private cloud và SaaS công cộng

What on-premise actually means, versus private cloud and public SaaS

The three models get used interchangeably, yet the real difference is who holds final authority over infrastructure and data.

  • On-premise. Software runs on servers the organization owns or colocates, inside its own network. You choose the hardware, the operating system, the patch schedule, the backup policy and who holds administrator rights. You also own the consequences when power fails, a disk dies, or your one sysadmin resigns.
  • Private cloud. Still dedicated infrastructure, but virtualized and automated in cloud fashion — either in your own data center or as a dedicated zone at a domestic provider. You keep control at the resource and access layer while getting provisioning speed close to public cloud.
  • Public SaaS. You rent software running on shared infrastructure. The vendor decides the architecture, the storage regions, the upgrade cadence and where data gets replicated. You have a contract and a service level commitment, but no ability to change how the system behaves.

The core distinction is not whose machine the bits sit on. It is whether you can answer three questions without asking anyone: where is the data right now, who accessed it, and how do you get all of it back if the contract ends tomorrow. On-premise and private cloud let you answer directly. SaaS makes you file a request.

What Vietnamese law forces you to weigh

No statute says "you must run on-premise." But several make the location of data a compliance question rather than a matter of taste.

  • Cybersecurity Law 2018. Clause 3, Article 26 of Law 24/2018/QH14 on Cybersecurity requires domestic and foreign enterprises providing telecom, internet and value-added services in Vietnam, where they collect, exploit, analyse or process personal information, user relationship data, or data generated by users in Vietnam, to store that data in Vietnam.
  • Decree 53/2022/ND-CP. Decree 53/2022/ND-CP, issued 15 August 2022 fills in the detail. Its Article 26 names three categories that must stay in country: personal information of service users in Vietnam; data those users generate (account name, usage time, credit card details, email address, most recent login and logout IP, the phone number tied to the account); and user relationship data. Domestic enterprises store these in Vietnam. For foreign enterprises the storage and local branch or representative office obligation is triggered by a decision of the Minister of Public Security in the circumstances the Decree spells out, with 12 months from that decision to comply. Article 27 sets a minimum storage period of 24 months, and at least 12 months for system logs used in investigations.
  • Data Law. Law 60/2024/QH15 on Data, passed 30 November 2024 took effect on 1 July 2025. Article 23 defines cross-border transfer and processing of core and important data, and explicitly counts the case where a Vietnamese organization uses a platform located outside the territory to process data. Choosing a foreign SaaS is therefore not only a procurement decision; it can itself be a cross-border transfer.
  • Personal Data Protection Law. Law 91/2025/QH15, passed by the National Assembly on 26 June 2025, effective 1 January 2026, raises personal data obligations to statute level. Organizations have a little over a year to review where their data sits.

We covered in-country storage duties in more depth in our piece on data localization and what it really demands.

Comparing on-premise and cloud on six criteria

These are the criteria we use in advisory work, ordered by how often they get overlooked.

  • Control and provability. On-premise gives you complete access logs, authority over who holds admin accounts, and physical evidence of where data lives. SaaS gives you reports the vendor issues. When an auditor asks who opened which record at what time, that difference gets very concrete.
  • Capital cost versus running cost. On-premise is front-loaded: servers, network gear, licences, rack space, power and cooling. Cloud has almost no entry cost but bills every month, growing with storage, traffic and seat count. Break-even for a steady workload typically lands somewhere in year three. Do not compare first invoices; model three to five years of total ownership, including egress charges the day you decide to leave.
  • Time to deploy. Cloud wins outright. A new environment takes minutes, while hardware procurement through a tender process can take months. If you need to test an idea within six weeks, building it in the cloud is the sane call.
  • Scalability. Cloud flexes with real load, which suits seasonal peaks such as enrolment, year-end closing or campaigns. On-premise must be bought for the peak, so it runs below capacity most of the year. Conversely, for steady and predictable load, owning is cheaper than renting.
  • Operating staff. This is where on-premise projects fail, and it is rarely a technology failure. You need people to patch, watch backups, rehearse restores and handle incidents after hours. If your organization has one part-time administrator, on-premise is a risk, not control. Either hire properly or buy managed operations alongside.
  • Vendor lock-in. The test is simple: if the contract ended tomorrow, in what format do you get your data back, how quickly, and what software can read it? If the answer is a proprietary export with no documented schema, you are locked in. On-premise is not automatically immune — closed software running on your own machine that only the vendor can configure is still lock-in.

When cloud is the right answer

Defaulting to on-premise for everything is just a different kind of lazy thinking. Cloud is the correct choice in plenty of situations.

  • The organization has no infrastructure operations team and is not ready to build one.
  • The workload swings wildly, or exists only for a short campaign.
  • Public websites, marketing channels, test systems, development environments — non-sensitive data that can simply be rebuilt.
  • Disaster recovery at a second location when you do not have a second data center.
  • Compute you need for a few weeks a year, where buying outright is waste.

In these cases, if the data still falls into the in-country categories, pick the provider's Vietnam region explicitly and write it into the contract rather than accepting the nearest default.

The risks of foreign SaaS

The risk is not technical quality. Many international SaaS platforms run better than the average internal data center. The risk sits elsewhere.

  • Data may be replicated across regions by design, and you cannot forbid it.
  • Terms of service change unilaterally, and so do prices and usage limits.
  • Vendors sunset products, get acquired, or withdraw from the Vietnamese market.
  • Their incident becomes your incident, but you do not participate in the response — you wait for the status page.
  • Legal obligations to data subjects remain yours, even when someone else runs the system.

None of this disqualifies SaaS. It is simply the reason to classify data before signing.

A decision framework by data type

Rather than picking a model and stuffing data into it, work the other way. For each system, answer five questions and let the answers decide placement.

  • Does this data include personal information of users in Vietnam? If so, the in-country storage duty comes first.
  • If this data disappeared, how long would the organization stop? The longer, the closer it should stay.
  • Does it hold state secrets, trade secrets, HR files or sensitive customer records?
  • Is the load steady? Steady load favours owning over renting in the long run.
  • Do you actually have operators, or only an org chart?

Sector patterns are fairly consistent. Public sector bodies and financial institutions lean on-premise or domestic private cloud for core systems. Manufacturers keep production systems on site for latency and continuity, while pushing reporting to cloud. Retail and e-commerce put customer-facing layers in the cloud for elasticity and keep customer and transaction data in a domestic region. Smaller service businesses can run almost entirely in the cloud, provided they know which datasets must remain in country.

Common mistakes

  • Treating hybrid as "half here, half there." Real hybrid means classifying data first, then placing each class deliberately, with a clear boundary between zones.
  • Assuming on-premise is secure by default. An unpatched server with no off-site backup is far more dangerous than a well-managed cloud service.
  • Comparing costs by first invoice rather than multi-year total ownership.
  • Ignoring exit cost and exit time. Ask about data export in the first negotiation round, not when you want to leave.
  • Never rehearsing recovery. A backup that has never been restored is a belief, not a plan.
  • Forgetting that signatures and workflow are data too. Standardizing internal digital signing along the lines described in our note on digital signatures under Decree 23/2025 keeps electronic records legally sound wherever the system runs.
  • Ignoring organizational change. Mergers, splits and handovers all mean data handovers, as we analysed in our piece on handing over digital records during administrative mergers.

Tetra's view

We build on-premise-first, not because cloud is bad, but because our customers — large enterprises and public bodies — have a core where control matters more than provisioning speed. Tetra eOffice is designed to run inside the customer's own infrastructure, on open standards, with data in a database the customer's own engineers can reach and no mechanism designed to keep you from leaving. For the non-sensitive parts, we still recommend cloud when it saves time and money. Preparing early for new obligations, including those arising from the Digital Technology Industry Law 71/2025, is always cheaper than a rushed retrofit.

Conclusion

On-premise vs cloud is not a contest with a winner. It is the problem of putting each class of data in the right place, at a cost and an operational capability the organization genuinely has. Start from a data inventory, not a product catalogue.

If your organization faces this choice, book a consultation and we will review together what data must stay close, what can be flexible, and what a sensible migration path looks like.

Related articles

Free resource

Personal Data Protection checklist

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

Get the checklist