Data residency questions for education buyers in the Middle East

Ask an education software vendor where your data is stored and you will usually get a region name back. That answers about a fifth of the question. Data at rest sits in one place; processing sits somewhere else; backups sit somewhere else again; and the sub-processors behind the vendor's own features — the AI model, the email sender, the error tracker, the support desk — each sit in a country of their own. A residency commitment that covers only the first of those is not a residency commitment. It is a hosting preference.

This matters more in the Gulf than it did five years ago, because the rules became specific. Saudi Arabia's Personal Data Protection Law, enforced by SDAIA, sets conditions on moving personal data out of the Kingdom. The UAE has a federal law running alongside separate regimes inside the DIFC and ADGM. Qatar, Bahrain, Oman and Egypt each have their own statute, and sector regulators layer classification rules on top. Procurement teams are asking questions they did not ask in 2019.

Residency, sovereignty and jurisdiction are three different promises

They are separate, and a vendor can meet one while failing the other two.

Data sovereignty is the stronger claim: that the data is governed by the law of the country it sits in, and only that law. It is a legal position rather than a technical one, and it depends on who operates the infrastructure, who holds the encryption keys, and where the operating entity is incorporated.

Jurisdiction follows the corporate entity, not the disk. A US-incorporated vendor storing your records in a Riyadh data centre is still a US company, still reachable by a US court, and still within scope of the US CLOUD Act of 2018, which allows US authorities to compel a US-based provider to produce data it controls wherever that data is stored. Moving the disk did not move the company.

Why "the cloud" is not an answer

"The cloud" is not a place. It is a purchasing model laid over a global fleet of data centres, and the fleet is the point of it. When a vendor says "we run on AWS", every question that matters is still open.

• Which region? One account can hold resources in twenty regions at once, and the answer is per-service, not per-account.
• Is every service in that region? Some replicate across regions by default; some have a control plane that permanently lives elsewhere.
• Where do the application servers run, as opposed to the database?
• Where do logs, error traces and product analytics go? These carry names, email addresses and sometimes free-text learner answers.
• Where does the support team sit, and what can they see from there?
• Where do backups land, and how long do they persist after deletion?

Each of those is an ordinary engineering decision, made early, for latency or cost rather than for law, by someone who was not in the procurement meeting. That is why the answers are so often vague: nobody wrote them down.

The seven questions

Send these in writing and attach the answers to the contract. A vendor who will not answer in writing cannot be held to the answer.

1. Where is data at rest, and in which named region?

Ask per data class, not per platform. Learner records, assessment attempts, uploaded files, video, certificates and audit logs often live in different systems, and the vendor may only have thought about the first. Ask for a table: for each class of data, the country, the provider and the region code.

2. Where is it processed?

Storage is the easy half; processing is where data moves. Search indexing, report generation, PDF rendering, video transcoding and anything AI-assisted all read the data and run somewhere. AI is the sharpest case in education software right now: a tutor, an authoring assistant or a grading draft sends learner text to a model provider, and that provider's inference region is a separate fact from the vendor's hosting region. Ask which provider, in which region, whether content is used for training, and get retention in days.

3. Which sub-processors touch it, and in which country?

Ask for it as a list, with three columns: name, function, country of processing. A platform in 2026 typically has eight to fifteen — a cloud host, a database provider, an object store, an email sender, an AI model provider, an error tracker, an analytics tool, a support desk, and a payment processor if it takes money.

Two follow-ups separate a serious vendor from a hopeful one. How are you notified when a sub-processor changes, and can you object? And which of them receive personal data rather than metadata? A vendor who has never written this down takes a week to produce it, and the delay is itself information.

4. Where do backups and disaster-recovery copies go?

Backups are the most common way a residency commitment quietly fails. Cross-region replication is the default recommendation in every cloud architecture guide, for reasons unrelated to your regulator. Ask where backups are written, whether any replica leaves the region, and how long a deleted record survives inside them. If your erasure obligation is 30 days and backup retention is 90, that gap belongs in a policy rather than an audit finding.

5. Who can access it, and from where?

Residency is undone by remote access. Ask where the support and engineering teams sit, whether production access is possible from outside the region, whether it needs approval, and whether you can see the log. "Our engineers can read customer data from anywhere, unlogged" is a real answer some vendors give if you ask plainly.

6. What is the transfer mechanism?

If any data leaves the country, and for most vendors some of it will, there has to be a named lawful basis for the transfer rather than a shrug. Ask which provision of which local law it relies on.

A common tell: the vendor sends you the EU standard contractual clauses. Those are an EU instrument, built for transfers out of the European Economic Area. They are a reasonable contractual base and they are not, on their own, a Saudi or a UAE transfer mechanism. A vendor treating a GDPR agreement as universal compliance has not read the local statute.

7. What happens if the law changes?

This is the question almost nobody asks and the one with the most money attached. Data protection law in the region is young and moving: a regulator can issue a new classification, and a position that was compliant at signature stops being compliant in year two of a five-year contract. Put four things in the contract:

1. If the law changes so that our arrangement is no longer lawful, what must you do, and within what period?
2. Who pays for the migration — you, us, or split by cause?
3. Can we terminate without penalty if you cannot comply in that period?
4. On exit, in what format do we get the data, how long does the export take, and when is it deleted from your systems and your backups?

Where Lurno sits, plainly

Here is our own answer to our own questionnaire, in the form we would want it from anyone else.

Augmental Learning Inc. is a United States company, and our default infrastructure and sub-processors are US-based. Two things follow, and a buyer in the Gulf should hear both directly. By default, your records sit in the United States. And the company is US-incorporated, so US jurisdiction reaches it wherever any individual byte lives. No configuration setting changes the second one — not for us, and not for any other US vendor.

What is genuinely configurable today is media storage. It is set per organisation across Supabase, Amazon S3, Azure and Google Cloud Storage — your own bucket, in your own region — and inherits down the organisation tree, so a publisher can keep one country's files in that country without splitting it into a separate tenant. That covers the largest part of the payload: uploaded documents, recordings, learner submissions and evidence files. How it is configured is on the authoring page.

What we do not claim: an in-region deployment of the primary database and the application tier is not something you can tick on an order form today. If your requirement covers those, it is a scoped conversation with a timeline attached, not a checkbox — and you should press every vendor for that specificity, including the ones whose deck says "sovereign".

We are not SOC 2 certified and we are not ISO 27001 certified, and we would rather write that down than let a badge on a slide imply it. What exists is a data processing agreement, a FERPA addendum, a hash-chained audit log, GDPR consent and erasure flows with a two-person rule, and separation between organisations enforced underneath the platform rather than only by the screens on top. Isolation is a different guarantee from residency: it means another customer cannot reach your rows. A vendor who answers a residency question with an isolation answer has changed the subject — including us.

Writing the requirement so you get a real answer

Vendors return vague answers because the question permitted one. "Do you support data residency?" invites a yes, and nobody has ever said no to it. Replace it with questions that have a wrong answer.

1. Ask for a table, not a paragraph: data class, storage country, processing country, provider, region code.
2. Ask for the sub-processor list as an attachment, with countries and a change-notification term.
3. Ask for backup locations, retention in days, and how long deleted records survive in them.
4. Ask which provision of which local law each cross-border transfer relies on.
5. Ask what happens contractually if the law changes, including who pays to move.

Then score the answers on specificity rather than enthusiasm. While the rules in the region are still settling, a vendor who tells you precisely where your data is — including the parts you did not want to hear — is easier to stay compliant with than one who agrees to everything. Our own version is on the security page. Hold it to the same standard as everyone else's.