Data Residency & Compliance in India

By the end of this lesson you will be able to explain data residency in plain words, name the main Indian laws and directions that affect cloud projects, and apply Azure controls that keep data in Indian regions and prove it to an auditor. This lesson is general education, not legal advice: always confirm requirements with your organisation's legal or compliance team.

Residency, localisation and sovereignty

These words are often mixed up:

• Data residency: where data is physically stored and processed. "Our database is in Central India (Pune)."
• Data localisation: a legal requirement that certain data must stay in a country.
• Data sovereignty: data is subject to the laws of the country where it is stored, and the owner controls who can access it.

Think of your family gold. Residency is which bank locker it sits in. Localisation is a rule that it must stay in a locker in India. Sovereignty is about which country's courts and police can ask the bank to open that locker.

The Indian rules you will hear about

Digital Personal Data Protection Act, 2023

The DPDP Act governs digital personal data of individuals in India. Key ideas for cloud builders:

• Organisations that decide why and how personal data is processed are data fiduciaries; they must collect data for a clear purpose, usually with consent, keep it secure, and delete it when no longer needed.
• People (data principals) get rights such as access, correction and erasure.
• Personal data breaches must be reported to the Data Protection Board of India and to affected people.
• Cross-border transfer is allowed in general, but the government can restrict transfers to specific countries by notification.

The DPDP Rules, 2025 were notified in November 2025 with a phased start: some parts applied at once, and most core duties, such as notices, consent and breach reporting, apply 18 months after notification (around May 2027). Check the official MeitY notification for exact dates.

RBI rules for payment data

The Reserve Bank of India's 2018 direction on storage of payment system data requires payment system operators to store the entire data relating to payment systems only in India. Banks and fintechs also follow RBI's IT outsourcing and cyber security directions. If you build for a payments company, residency in India is not optional.

CERT-In directions, 2022

CERT-In's April 2022 directions under the IT Act require covered organisations to report specified cyber incidents to CERT-In within 6 hours of noticing them, and to keep logs of their ICT systems for 180 days within Indian jurisdiction. Your logging design must support both.

Sector and government rules

Insurance, capital markets, health and government projects have their own regulators and guidelines (for example IRDAI, SEBI and MeitY's cloud empanelment for government work). They often expect data in India, audit rights and specific security controls. Read the current circulars for your sector.

What Azure promises, in general terms

For most regional services, customer data you store stays in the region or geography you choose. Some services are global by design, such as Microsoft Entra ID, Azure Front Door's edge network and some management data, and may process or store data outside your chosen region. Microsoft documents this per service on its data residency pages, which are the place to check details.

The practical lesson: choosing Central India for your web app is necessary but not sufficient. You must check every service in the design, including backups, logs, monitoring and AI.

Practical controls on Azure

Step 1: restrict regions with Azure Policy. Assign the built-in Allowed locations policy, as shown in the policy lesson, with only Indian regions plus global for global resources where needed.

Step 2: find anything that slipped outside India. JMESPath's contains checks whether a value is in a list:

az resource list \
  --query "[?!contains(['centralindia','indiasouthcentral','southindia','westindia','global'], location)].{Name:name, Location:location}" \
  --output table

Name          Location
------------  ----------
stolddemoeus  eastus
log-test-weu  westeurope

The output is illustrative; an empty table is what you want.

Step 3: check where replicas go. Geo-redundant storage copies data to the paired region. In India the pairs stay inside India: Central India pairs with South India, India South Central with Central India, and West India with South India.

az storage account show --resource-group rg-storage-demo --name stjaipurnotes01 \
  --query "{primary:primaryLocation, secondary:secondaryLocation, sku:sku.name}"

{
  "primary": "centralindia",
  "secondary": "southindia",
  "sku": "Standard_GRS"
}

This assumes the account uses GRS; with ZRS or LRS there is no secondary location.

Step 4: keep the supporting data in India too. Put Log Analytics workspaces, Application Insights, Recovery Services vaults, Key Vaults and Site Recovery targets in Indian regions. Logs and backups often contain the same personal data as the database.

Step 5: watch AI deployments. When you deploy a model in Microsoft Foundry, the deployment type decides where prompts are processed. Global deployment types may process data in any Azure region. If processing must stay in India, choose a regional deployment in an Indian region where the model is offered, and confirm in the docs.

Step 6: control encryption keys. Data at rest is encrypted by default with Microsoft-managed keys. For extra control, use customer-managed keys stored in your own Key Vault in India. Revoking the key makes the data unreadable.

Step 7: limit network paths and access. Use private endpoints, disable public network access where possible, and grant access with RBAC and PIM so you can show who touched what.

A worked example

Isha's start-up in Kochi builds a clinic appointment app. It stores names, phone numbers and visit reasons, which is sensitive personal data in practice. A residency-friendly design:

Common mistakes

• Only checking the main database. Backups, logs, analytics exports and AI prompts are data too.
• Assuming GRS might copy to Singapore. Indian pairs stay in India, but always confirm with the official regions list.
• Logging everything. Full request bodies with phone numbers and addresses in logs multiply your compliance work.
• Treating this lesson as legal advice. Laws and rules change; your compliance team decides.

Key points

• Residency is where data lives; localisation is a legal "must stay"; sovereignty is about which laws apply.
• The DPDP Act 2023 and DPDP Rules 2025 set duties for personal data, with most duties phased in by around May 2027.
• RBI requires payment system data to be stored only in India; CERT-In requires 6-hour incident reporting and 180 days of logs kept in India.
• Use Azure Policy, Indian region pairs, Indian locations for logs and backups, regional AI deployments and customer-managed keys.
• Keep a data map and evidence; confirm legal requirements with experts.

az storage account show --resource-group rg-pay --name stpayrecords01 \
  --query "{primary:primaryLocation, secondary:secondaryLocation}"