Data residency is not the same as data sovereignty
Moving data inside the country satisfies the letter of a residency rule and often changes very little about who can actually reach it. What the harder questions are, and what to ask a cloud provider before signing.
Azhar Ghafoor18 September 20266 min read
Pakistan has moved towards keeping certain categories of data inside the country, with accreditation requirements attached to the providers who hold it. Several other jurisdictions have made similar moves, and organisations operating across the Gulf will recognise the pattern from the Qatari and Emirati equivalents.
The instinctive response is to find a compliant region, migrate, and consider the matter handled. That satisfies the rule as written. It frequently changes far less than people assume about who can actually reach the data, and the gap between those two things is where the interesting risk lives.
Three different questions wearing one name
Residency, sovereignty, operational control and key custody are four separate answers.
Residency asks where the bytes physically sit. It is the easiest to satisfy and the easiest to verify, which is why policies tend to lead with it.
Sovereignty asks whose law applies and who can compel disclosure. This is a question about the provider's corporate structure and its parent jurisdiction, not about the location of the building. A datacentre in Islamabad operated by a subsidiary of a foreign parent may be reachable through a legal order served on the parent, and the data never moves an inch during that process.
Operational control asks who can technically access the system. Administrative access, support engineers, the key material. A provider with excellent residency and foreign support staff holding production access has data that is resident, and reachable, by people outside the jurisdiction on an ordinary Tuesday.
Most organisations solve the first and assume they have solved all three. They are separable, and a serious assessment treats them separately.
Residency tells you where the data sleeps. Sovereignty tells you who can wake it up.
Where the keys are is the question that matters
If you take one thing from this, take this.
Encryption at rest is close to universal now and is quoted in every proposal. The security property it delivers depends almost entirely on who holds the keys, and that detail is usually three layers down in the documentation.
Provider managed keys mean the provider can decrypt your data. Everything else about the arrangement is a policy commitment rather than a technical limit, and policy commitments are exactly what a legal order overrides.
Customer managed keys held in the provider's own key service are better, and the provider still operates the service.
Keys held outside the provider entirely, in hardware you control, is the arrangement where the residency claim becomes structurally true rather than contractual. It is also operationally harder, and the failure mode is losing access to your own data, which is a real risk that deserves a real plan rather than optimism.
There is no universally right answer. There is only a decision that should be made deliberately, by somebody who understood the trade, and written down.
What to ask a provider before signing
Ask these in writing and keep the answers, because they become your evidence later.
Which legal entity operates this service, where is it incorporated, and who is its ultimate parent. Which jurisdictions can compel disclosure from that entity. Who holds the encryption keys and can the provider technically decrypt without your involvement. Which staff have administrative access to production, and where do those staff sit. Where does support and monitoring happen, including the overnight window. Does any telemetry, log data, metadata or backup leave the country, and metadata matters here because it is frequently exempted in the answer and revealing in practice. Where are backups and disaster recovery copies, which is the most common place residency quietly breaks. What happens when you leave, in what format, and how long does it take.
The last one is not a security question and it belongs in the same conversation, because an arrangement you cannot exit is not really a choice you keep making.
Any of these met with vagueness should be read as a no. Providers who have solved these answer them quickly, in writing, because they are asked constantly.
The thing organisations get wrong
Backups, overnight support and exported telemetry are where residency quietly breaks.
They treat this as a procurement exercise and finish it once.
Your data location is not a static property. A new feature lights up in a different region. A support model changes. A subcontractor is added to a chain. A backup policy gets revised. A managed service you enabled quietly processes somewhere else. Two years after a clean assessment, organisations regularly find that a component of their stack no longer matches the commitment they made to a regulator, and nobody did anything wrong at any single step.
This is the same structural problem as the one in infrastructure fails in chains. A property that depends on a chain cannot be assured by assessing one link once.
Which means residency needs to be a monitored control with an owner and a review, not a signed document in a folder. That is a dull conclusion and it is the one that holds.
What the accreditation schemes change
Where a country stands up accreditation for providers and datacentres, something useful happens for buyers. Instead of every organisation running its own assessment of a provider's claims, a common bar exists and can be pointed at.
Two cautions. Accreditation covers the provider, not your configuration, and the majority of cloud incidents come from customer side configuration rather than provider failure. And accreditation is a point in time statement about a moving target, which is the same limitation as any certificate.
Use it as a floor and a shortlist, not as an answer.
Where we fit
Our GRC practice runs residency and sovereignty assessments that separate the three questions instead of collapsing them, and our VAPT team tests the configuration side, which is where the exposure usually turns out to be. For organisations working to the Qatari framework alongside a domestic one, ComplianceVault carries a National Information Assurance programme from impact analysis through to audit day.
Because this is a control that decays rather than a document that expires, CyberNexus holds the review and the named acceptance behind it, and ControlGraph answers the question that gets asked after something changes, which is what else this reaches and who needs to hear about it.
We work from Islamabad and across the Gulf, so this is a question we answer about ourselves as well as for clients.
Start here
Pick your most sensitive dataset and answer two questions about it today.
Where are its backups. Who can decrypt it without asking you.
If the answer to either is uncertain, you have found the gap, and you have found it before a regulator did.
Common questions
What is the difference between data residency and data sovereignty
Residency is where data is physically stored. Sovereignty is about which legal system governs it and who can compel access. Data can be fully resident in a country and still be reachable through a legal order served on a foreign parent company.
Does storing data in country make it sovereign
No. Location is one factor. The operating entity's jurisdiction, who holds encryption keys, and which staff hold administrative access all determine whether in country storage means in country control.
What questions should we ask a cloud provider about residency
Which entity operates the service and where it is incorporated, who holds the keys, which staff have production access and where they sit, whether logs, metadata or backups leave the country, and what exit looks like. Get the answers in writing.
Where does data residency usually break
Backups and disaster recovery copies, support and overnight monitoring carried out from another region, and telemetry or metadata exported to a central service. These are rarely covered in the original assessment and change without anyone announcing it.
Is provider accreditation enough
It is a useful floor. It does not cover your own configuration, which is where most cloud incidents originate, and it describes a point in time. Treat it as a shortlist rather than as assurance.