Skip to main content
DATA

Where your data lives

A clinic in Abu Dhabi and a school in Kochi are not asking the same question, and one page cannot honestly answer both with a region. So this one does something more useful: it sets out the deployment models we can discuss, the law that actually decides the answer, and the questions to put to every vendor on your list.

What you will not find here is a country name we have not confirmed. Residency is agreed with you at onboarding and written into your agreement — and if we cannot meet your requirement, we will tell you before you commit rather than after.

Trust centrePrivacy policy
Deployment models

Four ways software can sit relative to your data

These are the shapes a deployment can take, described so you can tell us which one your organisation needs. None of them is presented here as a tier you can buy today — what we can actually offer depends on the product, and you should have that answer from a person, in writing, not from a page.

Shared multi-tenant cloud

How the platforms are built to run: one deployment serving many organisations, with every record scoped to its own organisation by construction rather than by a filter bolted on at query time. Unnatio's tenancy layer is designed to fail closed, Learnatio is multi-tenant across schools with per-school branding, and Cliniva scopes a clinic by branch, department, doctor and cash counter. What this model does not tell you on its own is which country the servers sit in — that is a separate question, and the right person to put it to is us.

Confirmed per deployment

A database of your own

One customer, one database, separate at the storage layer from every other customer's. Healthcare and public-sector procurement asks for this by name, and it is a fair thing to ask for. We are not going to tick it on a web page: what we can offer depends on the product you are buying and on infrastructure decisions we will not summarise second-hand. Ask, and you will get a straight yes, a straight no, or a specific description of what we can do instead — for your product, in writing.

Confirmed per deployment

Hosting in your region, on request

Where your regulator, your board or your own policy requires the deployment to sit in a named country, that is a requirement to put on the table in the first conversation rather than the last. Residency is a deployment decision that goes into your agreement. This page will not tell you that we already host in your region, because that is not something a page can honestly tell you — we will tell you what we can host where before you commit, and we will put it in writing.

Confirmed per deployment

On infrastructure you control

The software running inside a perimeter your own team owns — your servers, or your own cloud account. It is the model that answers the strictest residency and access requirements outright, and it is also the model with the most conditions attached: which product, which modules, who operates it, how it gets updated, how it gets supported, and what happens when something breaks at 2am. Every one of those is specific to the product and to you, so it is a scoping conversation, not a checkbox.

Confirmed per deployment
What we will tell you

Residency is agreed per deployment at onboarding, and written into your agreement

We are not publishing a map of regions on this page, because the honest answer depends on the product, on the deployment and on what your regulator actually requires. One answer covering a school in Kerala and a clinic in Abu Dhabi would be wrong for at least one of them, and you would not find out which until it mattered.

So the country, the provider, where backups are held, which sub-processors are involved, how data is exported and how it is destroyed at the end are all settled with you during onboarding and go into your agreement. Raise residency in the first conversation rather than the last — it is a question we expect, and it is answerable in writing for your deployment.

And if we cannot meet your requirement, we will say so plainly and early, rather than working around the question until you have signed. A vendor who cannot host where you need is a problem you can solve in week one. A vendor who let you assume otherwise is a problem you solve in year two.

Ask every vendor

10 questions worth asking before you sign anything

None of these is specific to us, and we have not written them to flatter ourselves — a checklist you could only pass would be worth nothing to you. Put them to every vendor on your shortlist, us included, and compare who answers precisely and who answers with adjectives.

  1. Which country do the servers sit in — and are the backups in the same country?

    Backups are where residency answers usually come apart. A deployment can be hosted exactly where you were told while a nightly copy lands somewhere else entirely. Ask about both in one sentence so they cannot be answered separately.

  2. Who is the hosting provider, and is the account ours or yours?

    It decides who can pull the plug, who receives the legal request, and who still has your data on the day the relationship ends badly.

  3. Name every sub-processor that can touch our data, and what each one does.

    Payment gateways, messaging APIs, email relays, AI providers, error trackers and analytics all count. A vendor who cannot list them from memory has not thought about it, and a list that arrives without job descriptions is not a list.

  4. How is our data separated from other customers' — by row, by schema, by database, or not at all?

    These are four genuinely different levels of isolation and most marketing copy blurs them into the single word 'secure'. Ask which one, and ask what happens if the scoping logic fails: does the query return nothing, or everything?

  5. Which of your staff can read our production data, under what approval, and is that access logged?

    Support engineers usually can, and often should. The question is whether it needs an approval, whether the record of it survives, and whether you get to see that record.

  6. Is data encrypted in transit and at rest, and who holds the keys?

    Encryption at rest where the vendor holds the keys protects you against a stolen disk, not against the vendor. Both answers are legitimate — you just need to know which one you bought.

  7. When we delete something, when is it actually gone — including from backups?

    Deletion in the application and deletion from a 35-day backup rotation are not the same event. Both dates belong in the answer, and a data-deletion request you have to honour will need them.

  8. If we leave, how do we get everything out — in what format, how quickly, and at what cost?

    Ask before you sign, while the answer still costs the vendor something to get wrong. A PDF export is not your data; a documented dump of your records in an open format is.

  9. What happens in the first hour of a breach — who do you tell, and how fast?

    Under most regimes the clock is on your organisation, not just the vendor's, so their notification timeline has to fit inside yours. Ask what they will send you on day one when the picture is still incomplete.

  10. Will the residency and sub-processor answers go into the contract, and will you tell us before they change?

    An answer in an email is a statement of intent. An answer in the agreement, with a change-notification clause attached, is the thing you can actually rely on when your auditor asks.

We are happy to be asked every one of them. Where the answer is “that depends on the deployment”, that is what you will get — along with what it depends on and who decides.

Regulatory context

What the law in your market actually says

Sourced and date-stamped, because a compliance claim without a citation is just a sentence. Each card links to where we read it and the day we last checked — go and read it yourself.

United Arab Emirates — Federal Decree-Law No. 45 of 2021 (PDPL)

The UAE's federal personal data protection law, in force since January 2022.

Checked 31 August 2026
  • The law covers the processing of personal data, in whole or in part through electronic systems, inside or outside the country, and sets out the requirements for cross-border transfer and sharing of personal data for processing purposes.
  • Information revealing a person's health status — physical, psychological, mental, genetic or sexual condition, including information about the health care services they received — is treated as sensitive personal data, with tighter handling than ordinary personal data.
  • Several PDPL mechanisms depend on the Executive Regulations and on the UAE Data Office, including the designation of jurisdictions considered adequate for cross-border transfer. Published summaries have disagreed about the current status of both, so we are not going to state one here. Check it with your own counsel rather than with any vendor's web page — this one included.
Sources

India — Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025

India's data protection statute, with its operational rules notified in November 2025 and commencing in stages.

Checked 31 August 2026
  • The Act takes a negative-list approach to cross-border transfer: personal data may be transferred out of India for processing to any country except one the Central Government specifically restricts by notification. As of DLA Piper's 13 February 2026 update, no country had been notified onto that list.
  • Section 16(2) preserves any higher degree of restriction on transferring personal data outside India that is already imposed by another Indian law — so a sectoral rule, or your own contracts, can be stricter than the Act.
  • The Digital Personal Data Protection Rules, 2025 were notified in November 2025 with a staggered commencement: a handful of provisions took effect on publication, and the bulk of the operational obligations — notice, security safeguards, breach reporting, Significant Data Fiduciary duties and data principal rights — follow later rather than on day one.
Sources

Health data carries its own rules, on top of privacy law

For a clinic or hospital, the binding constraint is usually not the general privacy statute.

Checked 31 August 2026
  • In the UAE, health information and data related to health services provided in the country may not be stored, processed, generated or transferred outside the UAE, except in the cases permitted by the relevant health authorities. The rule comes from Federal Law No. 2 of 2019 on the use of information and communication technology in health fields; Federal Ministerial Decision No. 51 of 2021 sets out the permitted exceptions. For a UAE clinic, this — not the PDPL — is normally the constraint that decides where a system can run.
  • India took the opposite structural route: the DPDP Act does not create a separate statutory category for sensitive personal data or for health data, and applies one standard to all digital personal data. Health-specific obligations in India therefore come from sectoral rules and from what the healthcare organisation is itself bound by, rather than from the Act's definitions.
  • Both of these land on the customer before they land on us. The clinic, hospital or school is the controller and answers to its own regulator. Our job is to give you a deployment you can defend to that regulator — and to say so plainly, early, when we cannot.
Sources

This is orientation for a buyer, not legal advice, and we are a software company rather than your counsel. Regulations move, and the summaries above are our reading of the sources cited on the dates shown. Take the decision that binds your organisation with someone qualified to give you that advice.

Answered per deployment, in writing

Tell us what your regulator requires, and we will tell you what we can do

Which country, which provider, where the backups sit, who can read the data. Bring the requirement and we will come back with a specific answer for the product you are buying — including a plain no, if that is the honest answer.

Ask us directlyTalk to the team
Or ask on WhatsApp

More on how we build: the trust centre. What this website itself collects: the privacy policy.