Data residency: what choosing a cloud region does and does not settle

Backups and disaster recovery replicas, which often default elsewhere. Logs and telemetry, which frequently leave the region through monitoring tooling. Support access, where an engineer in another country can read production. Sub-processors — the email, analytics and error-tracking services your application calls. Each is a route by which data leaves the region you promised it would stay in, and each is a question a serious customer audit will ask.

The legal position is worth separating from the contractual one, because they point in opposite directions. Under the GDPR, transfers out of the EEA are prohibited unless an adequacy decision or a safeguard such as Standard Contractual Clauses applies — a permission model. Under the DPDP Act, a data fiduciary may transfer personal data outside India except where the Central Government restricts transfers to a particular country or territory — a restriction model, and no such country had been notified when this was last checked. A second and separate control sits in Rule 15: transfers are subject to whatever requirements the Central Government specifies, by general or special order, about making personal data available to a foreign State or to any person or entity under its control. Section 16 governs where data may go; Rule 15 governs who may be given it once there. Rule 15 commences on 13 May 2027 with the rest of the substantive rules.

So Indian law is currently permissive about data leaving, and the obligations that actually bind you are the ones in your customer contracts — plus, if you are designated a Significant Data Fiduciary, a localisation duty that can attach to specified categories of data. Residency commitments are usually commercial promises rather than statutory ones, which makes them no less enforceable and considerably easier to make carelessly.