Data Residency Rules Are Rewriting Your Cloud Architecture

When India's DPDP Rules were notified in November 2025, most enterprise technology teams focused on consent management and breach notification. Reasonable priorities. But the rule that will cost the most to implement is data residency.

The requirement is straightforward in principle: certain categories of personal data must be stored and processed within India. In practice, it means that cloud architectures designed for global efficiency now need to be redesigned for jurisdictional compliance. That is an infrastructure project, not a policy project.

This piece is for CTOs, cloud architects and data protection officers dealing with the practical impact of data residency on enterprise infrastructure.

The short version

Data residency requirements under DPDP and sectoral regulations mean that storing personal data wherever the cloud provider finds it cheapest is no longer an option for many workloads. Redesigning cloud architecture for residency is expensive and takes longer than compliance timelines suggest.

• Data residency is an infrastructure problem, not just a legal one.
• Most global SaaS providers do not guarantee Indian data residency by default.
• Hybrid architectures — some workloads on Indian regions, some global — are the practical path.
• RBI's data localisation requirements for financial data are stricter than DPDP's general rules.
• Start with a data map. You cannot localise data you have not classified.

This article sits inside the technology governance cluster, where the wider argument is set out in full.

What the rules actually require

India's data residency landscape has multiple layers, and getting them confused is easy.

DPDP Act and Rules. The Digital Personal Data Protection framework requires that certain categories of personal data be processed within India. The Rules specify which categories — primarily government-issued identifiers, financial data and health records — and what "processing within India" means in practice. The exact scope is still being clarified through government notifications, but the direction is clear: sensitive personal data of Indian citizens has residency constraints.

RBI data localisation. The Reserve Bank of India requires that payment system data — transaction data, customer data used in payment processing — be stored only in India. This has been in effect since 2018 and is strictly enforced. Payment processors, banks and NBFCs have already localised this data, but the requirement extends to any system that processes or stores payment data, including analytics platforms that ingest transaction records.

SEBI, IRDAI and sectoral rules. Financial regulators have their own data handling requirements that effectively impose residency obligations for regulated entities. Insurance companies, securities firms and other regulated businesses must comply with both DPDP and their sector-specific rules.

Upcoming notifications. The government has indicated that additional categories of data and additional requirements may be notified. Cloud architectures designed today should be flexible enough to accommodate stricter requirements.

Should your organisation do this now?

• Yes, if you store personal data of Indian customers in cloud regions outside India.
• Not yet, if all your infrastructure is already in Indian data centres.
• Instead, first: verify that "in India" includes your SaaS providers' data storage locations.
• Measure it by: percentage of personal data workloads running in Indian cloud regions.

The SaaS residency gap

The hardest data residency problem is not your own infrastructure. It is your SaaS providers.

When you run your own servers or use IaaS from a hyperscaler, you choose the region. When you use SaaS, the vendor chooses the region unless you specifically negotiate otherwise.

Most global SaaS providers offer Indian data residency as an option, but:

• It may require an enterprise-tier subscription.
• It may cover primary data storage but not backups, analytics or logs.
• It may cover the core application but not ancillary services like search indexing or machine learning features.
• It may not be available at all for some products.

I recommend auditing every SaaS provider with a three-question check:

1. Where is our primary data stored? Get the specific cloud region, not just "in the cloud." 2. Where are backups, replicas and processing pipelines? Data that is backed up to a European region or processed through a US-based analytics service is not resident in India. 3. Can we get contractual commitment to Indian residency? A verbal assurance from a sales representative is not a compliance document.

The audit usually reveals surprises. A CRM that stores customer records in India but runs its email analytics through a US region. A support tool that stores tickets in India but sends them through a global routing service. An HR platform that stores employee data in India but processes payroll through a Singapore instance.

Each of these gaps needs to be evaluated: is the data covered by residency requirements, and if so, what is the remediation?

Redesigning for residency

Once you know which data must stay in India, the architecture work begins. Three approaches, in order of preference:

1. Region selection on existing platforms

If you use AWS, Azure or Google Cloud, select the Indian region (Mumbai, Hyderabad, or equivalent) for all workloads that handle personal data covered by residency requirements. This is the simplest approach if you are already on a hyperscaler.

Watch for:

• Services not available in Indian regions. Not every cloud service is available in every region. Check before assuming.
• Cross-region data movement. Load balancers, CDNs, DNS services and analytics tools may move data across regions by default. Configure them explicitly for Indian-only data paths.
• Disaster recovery. If your DR site is in another country, the replicated data leaves India. Consider a secondary Indian region for DR, or accept the compliance trade-off and document it.

2. Data classification and selective localisation

Not all data needs to stay in India. A hybrid approach classifies data by residency requirement and routes it accordingly:

• Residency-required data (personal data of Indian citizens under DPDP, payment data under RBI rules) stays in Indian regions exclusively.
• Non-personal operational data (aggregated analytics, system logs without personal identifiers, configuration data) can reside globally.
• De-identified or anonymised data may be exempt from residency requirements depending on the degree of anonymisation and the legal interpretation.

This approach requires investment in data classification, but it avoids the cost of localising everything.

3. Sovereign or on-premise for the most sensitive workloads

Some organisations, particularly in financial services and government, choose to keep the most sensitive data on infrastructure they fully control — either on-premise or in a sovereign cloud operated under Indian jurisdiction.

This is the most expensive approach, but it provides the highest degree of control and the clearest compliance story. It also limits access to cloud-native capabilities and increases operational burden.

Should your organisation do this now?

• Yes, if you are a regulated entity with personal data in non-Indian cloud regions.
• Not yet, if you have not completed a data classification exercise.
• Instead, first: classify your data by residency requirement before making infrastructure changes.
• Measure it by: percentage of residency-required data hosted in compliant locations.

The cost reality

Data residency redesign is not free. The costs include:

Migration costs. Moving data and workloads between cloud regions requires planning, downtime windows and testing. For large datasets, migration can take weeks.

Operational overhead. Running workloads in a specific region rather than wherever the cloud provider optimises cost typically increases infrastructure spend by ten to twenty per cent.

SaaS tier upgrades. Getting Indian data residency from SaaS providers often means upgrading to enterprise-tier subscriptions with higher per-user costs.

Ongoing compliance monitoring. Data residency is not a one-time configuration. It requires continuous monitoring to ensure that new services, new features and new integrations do not inadvertently move data outside India.

These costs should be part of the compliance budget, not treated as an infrastructure surprise. If your DPDP compliance programme does not include an infrastructure line item, it is incomplete.

Before you start

Checklist:

• Data map covering all systems that store or process personal data of Indian citizens.
• SaaS provider audit with data residency status for each vendor.
• Data classification framework: residency-required, operational, anonymised.
• Cloud region strategy for IaaS workloads with Indian-region-first policy.
• Disaster recovery architecture reviewed for residency compliance.
• Budget allocated for migration, SaaS upgrades and ongoing monitoring.

Questions to ask:

• Your cloud architect: which of our workloads currently run outside India, and which handle personal data?
• Your procurement team: which SaaS providers have confirmed Indian data residency in writing?
• Your legal team: which data categories are covered by residency requirements today, and which might be added?
• Your DR planning team: does our disaster recovery architecture keep residency-required data in India?
• Your finance team: what is the cost difference between Indian-region and global-optimised cloud hosting?

How to measure it

• Residency compliance rate. Percentage of residency-required data stored exclusively in Indian regions. Baseline: first data map. Owner: cloud architecture. Review: quarterly. Leading.
• SaaS residency coverage. Percentage of SaaS providers with contractual Indian data residency. Baseline: first audit. Owner: procurement. Review: semi-annual. Leading.
• Cross-region data transfers. Volume of personal data transferred outside India per month. Baseline: first monitoring month. Owner: network operations. Review: monthly. Leading.
• Compliance cost per workload. Additional cost of Indian-region hosting versus global. Baseline: first quarter of localised hosting. Owner: cloud operations. Review: quarterly. Lagging.
• Residency incidents. Instances of personal data found outside compliant regions. Baseline: first audit. Owner: data protection officer. Review: quarterly. Lagging.

Mistakes that cost the most

Assuming SaaS means compliant

You assume your SaaS providers store data in India because they serve Indian customers.

• Why it happens: nobody checked, and the provider did not volunteer the information.
• Prevention: require written confirmation of data storage location from every SaaS provider.
• Early warning: a provider cannot name the specific cloud region where your data resides.

Localising everything

You move all data to Indian regions regardless of whether it is covered by residency rules.

• Why it happens: it feels safer to localise everything.
• Prevention: classify first. Only residency-required data needs localisation.
• Early warning: cloud costs increase significantly with no incremental compliance benefit.

Forgetting backups and DR

Primary data is in India, but backups replicate to a foreign region.

• Why it happens: DR architecture was designed before residency rules existed.
• Prevention: review the full data lifecycle, including backups, replicas and archives.
• Early warning: DR test restores pull data from a non-Indian region.

What to do next

Start with the data map. List every system that stores personal data, where that data physically resides, and whether the storage location meets residency requirements. The map will show you the gaps. Then read the related piece on DPDP compliance for malls and retail and the technology governance topic page.

Last reviewed: 14 October 2026.

Views are my own and do not represent my employer.

This article is general information, not legal advice.