Data residency and local deployment, explained plainly

"Your data is safe" is not an answer. Neither is "we are cloud-based". Data residency is a specific question with a specific answer: which country is the data in, who can reach it, and what happens if you want it somewhere else.

This is what the terms mean in practice, and what to ask before you commit.

Residency is about location, sovereignty is about control

Data residency means the data is stored in a particular country or region. Data sovereignty means the legal jurisdiction that governs it — which is not always the same thing, because a server in one country can be operated by a company incorporated in another.

For most businesses the practical concern is simpler than the legal theory: can you state, in writing, which country a customer record sits in, and can you prove it if a regulator or an enterprise customer asks?

What region routing by IP means

On a cloud deployment, the system looks at the IP address a request comes from, determines the country, and keeps that data in the matching region. A customer in Thailand is served from the Thailand region; a customer in Malaysia from the Malaysia region.

Two things this does not mean, and both get misread:

• It is not a security control. It is a placement rule. Access control is a separate mechanism.
• It is not a substitute for a decision. If your compliance requirement says "all data in one country", IP-based routing across six markets is the wrong shape — you want a single region, or on-premise.

What the six markets look like in practice

Our cloud deployments place data in the region each market belongs to, with the core data centre for that market:

Market	Core data centre
Singapore	Singapore
Malaysia	Kuala Lumpur
Laos	Vientiane
Indonesia	Jakarta
Cambodia	Phnom Penh
Thailand	Bangkok

If you need a different arrangement — one shared region, or a specific country for all traffic — it belongs in the written scope, not in a footnote.

Local deployment: what it really involves

Running the system on your own servers or private cloud is a legitimate option, not a downgrade. It is usually the right choice when a regulator, a parent company or an enterprise customer requires that data never leaves your network.

What it involves, honestly:

• You take on operations. Backups, updates and uptime become your responsibility, or a support arrangement we run with you.
• You need somewhere to put it. A virtual machine in your own rack or a private cloud tenancy, with the specification agreed before installation.
• Migration is a project. Moving from a cloud region to your own hardware is planned work with a cutover, not a configuration switch.
• Documentation stops being optional. Installation, backup and restore procedures have to be written down, because we will not be the only people operating it.

Questions worth asking any vendor

• In which country is the data stored, exactly, and where is the backup?
• Is the location fixed, or does it follow the traffic? What determines it?
• Who can access the data, and is that access logged?
• What happens to the data if the relationship ends — export format, timeline, deletion proof?
• Can it be deployed on our own infrastructure, and what changes in the contract if it is?

If a vendor answers "yes, we are compliant" without naming a country, you do not have an answer yet.

Why this comes up earlier than people expect

Residency questions rarely arrive from the operations team. They arrive from a procurement review, a parent company's IT policy, or a tender requirement — usually a few weeks before a contract is signed, and often after the architecture has been set.

Deciding region, backup location and local-deployment options before the build starts costs a meeting. Deciding them afterwards costs a migration.