Compliance
A Lexicon of Three Words That Look Alike
Locality, residency, and sovereignty are not synonyms. A short dictionary, with usage notes, for the procurement office that has been writing the wrong clause for years.
I have read enough Bangladeshi cloud RFPs to write this short dictionary in good conscience. The procurement office did not invent the confusion; the global vendor sales pitch did. But the cost of using the wrong word in the wrong clause now sits with the customer, not the vendor. The three terms — data locality, data residency, and data sovereignty — appear in almost every cloud RFP we respond to, and they are treated as synonyms in most of those documents. They are not synonyms. The distinctions matter, both for what a provider must commit to and for what an auditor will eventually ask. They have also become specific in international privacy discourse over the last decade, and the Bangladeshi procurement profession needs to catch up before a contract goes to court.
A short dictionary
- locality noun /loʊˈkælɪti/
- Where data physically resides — at rest, in flight, in cache, in backup, in operational telemetry. A property of hardware and topology, answerable from a network diagram.
- “All customer data shall reside on infrastructure located within the territorial borders of Bangladesh.”
- residency noun /ˈrɛzɪdənsi/
- Where data is contractually or legally required to remain. A policy commitment, sitting one layer above locality. Auditable by reviewing contracts and regulatory filings.
- “The provider shall not transfer customer data outside Bangladesh without the controller's prior written authorisation.”
- sovereignty noun /ˈsɒvrɪnti/
- Whose laws govern access to the data. The deepest of the three — answerable only by examining the provider's corporate structure, the jurisdictions of incorporation, and the legal process to which the controlling entity is subject.
- “The provider shall not be subject to extraterritorial legal process that compels disclosure of customer data without Bangladesh judicial authority.”
A short etymology of the confusion
The three terms entered the cloud-procurement vocabulary at different moments and from different domains. Locality came from the storage and networking community in the 1990s, originally meaning the physical site where data resided. Residency arrived from the financial-regulation community, particularly with the European banking framework’s outsourcing notices, and meant a contractual commitment to keep certain data within defined geographic boundaries. Sovereignty arrived most recently, with the GDPR’s restrictions on cross-border transfer and the Schrems II ruling in 2020, which forced the entire European industry to recognise that residency commitments did not protect against extraterritorial process. Each word carried different baggage and different defences. Treating them as interchangeable is a category error that costs real money in procurement disputes.
Why the difference matters
A residency clause says the data shall stay. A sovereignty clause says and even if a foreign government asks for it under their law, the provider cannot lawfully hand it over. The two clauses defend against different threats. The Schrems II ruling, the EU Data Act of 2023, and the United States CLOUD Act of 2018 have all spent the last decade making this distinction explicit in international privacy discourse — most Bangladeshi RFPs have not yet caught up. India’s DPDPA of 2023 and China’s PIPL of 2021 have similarly forced the conversation in those markets. Bangladeshi procurement teams that copy boilerplate residency language from older Indian or European RFPs are, in practice, importing the older interpretation.
| Locality | Residency | Sovereignty | |
|---|---|---|---|
| Question answered | Where the bytes sit | What you must keep where | Whose laws govern access |
| Type of artefact | Topology diagram | Contract clause | Statute / incorporation |
| Stops physical exfiltration | Yes | Yes | Yes |
| Stops contract breach | Partial | Yes | Yes |
| Stops foreign legal process | Weak | Partial | Yes |
| Provider must be in-jurisdiction | No | No | Yes |
How to write the right clause
The three concepts are nested: locality ⊂ residency ⊂ sovereignty. Use the deepest term your workload actually needs. For non-personal, non-sensitive workloads, locality is enough. For personal data under the Data Privacy Act, residency is the floor. For systemically important financial infrastructure or state-level records, sovereignty is the correct word — and the clause must say the provider must be incorporated in Bangladesh, not merely the data must remain in Bangladesh. The two are not the same.
Three clauses for three threats
If your procurement template currently has a single line about “locality of data”, replace it with three. First, a locality clause that names the in-country requirement and includes operational logs and backups in scope. Second, a residency clause that requires contractual commitment from the provider, with audit rights and breach consequences. Third — only if the workload requires it — a sovereignty clause that requires the provider to be incorporated under Bangladeshi law and not subject to foreign legal process. Three sentences is usually enough; the work is in choosing them deliberately.
Where the procurement profession is going
The most sophisticated RFPs we are now seeing — typically from large banks and a handful of government tenders — explicitly stratify their data classification, asking for locality on operational data, residency on customer data, and sovereignty on systemically important records. This is the right pattern. It avoids the binary trap of all data sovereign (which excludes every hyperscaler) or all data the same (which exposes the institution to extraterritorial process). The profession is catching up; the procurement teams who lead the catch-up are the ones whose CIOs will sleep more easily over the next decade.
Read next
- Compliance
A Conversation About the Data Privacy Act
A reconstructed dialogue with a CIO who is reading the Act for the first time — what they ask, what I answer, and where the reading turns operational.
- Compliance
Three Letters to Three Regulators
How public cloud actually fits inside the Bangladeshi regulatory frame, written as three pieces of correspondence — to BTRC, to Bangladesh Bank, and to the Data Protection Authority.
- Cloud Strategy
A Letter on the Bangladesh Cloud Economy
Annual letter to the Cloud Digit board on the shape, drivers, and trajectory of the Bangladeshi cloud market. Written in the long-form-thesis style that serious investors actually read.