Data Residency Rules in India 2026: Where Your Cloud Data Lives

Last month a founder in Pune called me in a mild panic. His fintech startup had just closed a deal with a mid-size NBFC, and the NBFC's compliance team sent over a 40-point vendor security questionnaire. Question 12 asked, plainly: "Where is customer data physically stored, and can you produce evidence it never leaves India?" His answer, honestly, was "I think Singapore?" That "I think" nearly cost him the contract.

This is the reality of data residency India cloud decisions in 2026. The DPDP Act (Digital Personal Data Protection Act, 2023) is now backed by draft rules that spell out real obligations, and enforcement is no longer theoretical. Meanwhile, the big three cloud providers have quietly built out serious India capacity. Microsoft has expanded its India regions, AWS runs Mumbai and Hyderabad, and Google Cloud has Mumbai and Delhi NCR. The infrastructure to keep data legally inside India exists. What most SMBs lack is a clear map of what to switch on and how to prove it.

In this post I'll walk through what data residency actually means under Indian law today, where each major cloud stores your data by default (and how to lock it down), a real migration example with rupee numbers, a side-by-side comparison of the regions, and a checklist you can hand to your vendor tomorrow.

Key Takeaways

• The DPDP Act does not mandate blanket local storage for everyone, but sectoral rules (RBI, insurance, SEBI) and enterprise contracts increasingly do — so treat India residency as the safe default.
• Cloud data location is a configuration choice, not automatic. Picking the wrong default region silently sends your data offshore.
• All three majors (AWS Mumbai/Hyderabad, Azure Central/South India, GCP Mumbai/Delhi) can keep primary data in India — the gaps are usually in backups, logs, and managed services.
• RBI's payment data localisation rule is strict: payment data must be stored only in India, full stop.
• Budget for data residency as an architecture decision on day one; retrofitting it post-audit costs 3-5x more.
• You need documentation, not just correct settings — a data flow map is what auditors and enterprise clients actually ask for.

What does data residency actually mean under Indian law in 2026?

People conflate three different things, and that confusion causes bad decisions. Let me separate them.

Data residency is where your data physically sits. Data localisation is a legal requirement that certain data must stay within India's borders. Data sovereignty is the principle that data is subject to the laws of the country it lives in. You can have residency in India without any legal mandate, but the moment a sector regulator or client contract steps in, residency becomes localisation.

Here's where 2026 actually stands. The DPDP Act itself is relatively liberal on cross-border transfer. Rather than banning offshore storage outright, it allows the government to notify a list of countries where personal data cannot be transferred (a negative list model). So the Act alone doesn't force everyone to store in India.

But that's the headline that gets people in trouble. The sector-specific rules are far stricter:

• RBI payment data (2018 directive, still in force): All payment system data must be stored only in India. This is the hardest rule. If you touch card, UPI, or wallet transaction data, offshore storage is not an option.
• IRDAI (insurance): Policyholder records must be held on systems located in India.
• SEBI and depository rules: Increasingly require India-resident storage for regulated financial records.
• Government and CERT-In: The 2022 CERT-In directions require logs to be maintained within India for 180 days, which quietly forces your logging infrastructure onshore.

So my working advice to almost every SMB client: unless you have a specific reason not to, keep primary data, backups, and logs in India. It's cleaner, it satisfies the strictest questionnaire, and it removes a whole category of "we'll deal with it later" risk. If you want help reasoning through which rules apply to your specific business, this is exactly the kind of thing our IT consulting team untangles before you sign a single cloud contract.

Where does your cloud data live by default (and why that's a trap)?

The dangerous myth is that signing up with an Indian entity of a cloud provider means your data lives in India. It does not. The location is determined by the region you select when you create resources, and defaults are frequently non-Indian.

A classic example: someone spins up a new Microsoft 365 tenant, doesn't specify the data location, and gets provisioned in a default region based on the billing address logic — which historically defaulted many customers to non-India regions. Same with a hastily created AWS S3 bucket that defaults to us-east-1 if the person clicking around isn't paying attention.

The three big providers each run genuine India infrastructure:

• AWS: Asia Pacific (Mumbai) region ap-south-1 and Asia Pacific (Hyderabad) ap-south-2.
• Microsoft Azure: Central India (Pune), South India (Chennai), West India (Mumbai), plus Microsoft 365 and Dynamics data residency commitments for India.
• Google Cloud: Mumbai asia-south1 and Delhi NCR asia-south2.

The catch is in the layers people forget. Your primary database might be in Mumbai, but check these:

1. Backups and snapshots — are they replicated cross-region to Singapore for "durability"?
2. Logs and monitoring — many SaaS observability tools ship logs to US-based ingestion by default.
3. Managed AI/ML services — some inference endpoints don't have an India region yet, so calling them sends data out.
4. Email and collaboration — Microsoft 365 and Google Workspace store mail, files, and calendar data based on tenant data location, which must be set correctly.
5. CDN and edge caching — content can be cached globally; usually fine for public assets, a problem for anything sensitive.

Common Mistake: Teams lock down their production database region, then forget that their disaster-recovery backups auto-replicate to a foreign region. During an audit, that single backup setting is enough to fail the "data never leaves India" claim. Always map the backup and log destinations, not just the primary store.

How to keep your data residency in India cloud setups compliant, step by step

Here's the practical walkthrough I use with clients. You can hand this to your cloud team or vendor directly.

1. Draw a data flow map first. List every place personal or regulated data is created, stored, processed, backed up, and logged. Include third-party SaaS. This single document is what enterprise clients and auditors actually want to see.
2. Set the region explicitly at account setup. For AWS, default to ap-south-1 (Mumbai). For Azure, pick Central India or South India. For GCP, use asia-south1. Never leave it to defaults.
3. Pin backup and DR regions to India. Configure cross-region replication only between Mumbai and Hyderabad (AWS) or Central and South India (Azure). Two Indian regions give you disaster recovery without leaving the country.
4. Fix your email/collaboration data location. For Microsoft 365, confirm the tenant's data residency is set to India. For Google Workspace, apply data region policies to keep covered data in India. We handle these settings routinely as part of Microsoft 365 licensing and Google Workspace licensing engagements.
5. Route logs to an India region. Configure CloudWatch/Log Analytics/Cloud Logging to store in your Indian region and set retention to at least 180 days to satisfy CERT-In.
6. Audit third-party SaaS. Your CRM, helpdesk, analytics, and payment tools all store data somewhere. Ask each vendor for a written data residency statement. If they can't produce one, that's a red flag.
7. Encrypt with India-hosted keys. Use KMS/Key Vault in the Indian region so encryption keys don't leave the country either.
8. Document everything. Screenshots of region settings, vendor statements, and your data flow map go into a compliance folder. When the questionnaire arrives, you answer in an hour instead of a week.

If this feels like a lot to coordinate, it is — but it's a one-time setup that pays off every audit cycle. Our cloud migration and managed services team does this end to end, and we also help pick the right region in the first place, which we dug into in our guide on choosing a cloud region in India for 2026.

AWS vs Azure vs GCP for India data residency: which region setup wins?

There's no universal winner. It depends on your existing stack, your compliance load, and honestly what your team already knows. Here's how the three compare on the factors that matter for keeping data in India.

Criteria	AWS	Microsoft Azure	Google Cloud
India regions	Mumbai, Hyderabad (2)	Central, South, West India (3)	Mumbai, Delhi NCR (2)
In-country DR pairing	Mumbai ↔ Hyderabad	Central ↔ South India	Mumbai ↔ Delhi
Office/email residency	Via WorkMail (limited adoption)	Strong — M365 India data residency	Strong — Workspace data regions
Breadth of India services	Widest coverage	Broad, strong enterprise fit	Good, some newer services US-first
Best fit for	Startups, broad workloads	Microsoft-centric enterprises, M365 shops	Data/analytics-heavy teams
Rough entry cost (small prod workload)	₹15K–₹30K/month	₹18K–₹35K/month	₹15K–₹28K/month

If you're comparing the free tiers to get started, we broke those down in AWS vs GCP vs Azure free tier 2026. For a Microsoft-heavy business that already runs on Outlook and Teams, Azure plus a correctly configured M365 tenant is usually the path of least friction. For a lean product startup, AWS Mumbai remains the default I reach for.

Real example: how a Gurgaon logistics SaaS fixed its residency problem

A 22-person logistics SaaS company in Gurgaon came to us after losing a pilot with a large FMCG distributor. The reason was blunt: the distributor's IT team ran a security review and found that the SaaS company's PostgreSQL database was in AWS ap-south-1 (correct), but their nightly backups were replicating to Singapore, their application logs were streaming to a US-based logging SaaS, and their support tool stored customer contact data on US servers.

They were spending around ₹38,000/month on cloud and roughly ₹12,000/month on the offshore logging tool. Here's what we changed over a three-week engagement:

• Week 1: Built the data flow map, identified the three leak points, and got written residency statements from every SaaS vendor. Two couldn't provide India residency and were flagged for replacement.
• Week 2: Reconfigured backup replication to stay between Mumbai and Hyderabad. Migrated logging to a self-hosted stack in the Mumbai region with 180-day retention. Moved encryption keys into AWS KMS Mumbai.
• Week 3: Replaced the US-based support tool with an India-resident alternative, migrated contact data, and documented every setting with screenshots.

The net cost actually dropped slightly — the offshore logging bill of ₹12,000/month was replaced by an in-India logging setup costing about ₹7,000/month, and the backup change added negligible cost since intra-India transfer is cheap. Total cloud spend settled around ₹36,000/month. More importantly, they now had a one-page residency attestation. They won the FMCG contract on the second attempt and have since used the same document to close two more enterprise deals.

The lesson: data residency isn't just a compliance chore. For a B2B SaaS selling to Indian enterprises, being able to prove India residency is a sales asset. We see the same pattern in our custom software development projects — building residency in from the start makes the eventual enterprise sale far smoother.

What about SaaS tools, messaging, and voice data?

Cloud servers are only half the story. Most SMBs leak data through the tools bolted onto their core systems, and this is where SaaS sprawl bites. If you haven't audited your subscriptions recently, our post on cutting wasteful SaaS spend pairs well with a residency audit — you often find both a cost problem and a residency problem in the same tool.

Two categories deserve specific attention:

Messaging and SMS data

If you send OTPs, transactional alerts, or marketing messages, that traffic carries phone numbers and often personal context. Using an India-based provider keeps this data onshore and aligns with TRAI's DLT framework. Our bulk SMS services and WhatsApp Business API setups are built around Indian infrastructure and DLT compliance, so the message metadata stays where it should.

Voice and AI interaction data

Voicebots and AI assistants can be a hidden residency gap because many speech and language models are hosted abroad. If you deploy an AI voicebot that records and transcribes customer calls, you need to know where that audio and transcript live. We architect these with India-resident processing where the workload and regulations demand it.

Pro Tip: When evaluating any SaaS vendor, ask one specific question: "Can you contractually commit to storing our data in India, and will you name the region in the agreement?" Vague "we use secure global infrastructure" answers mean the data is going offshore. A vendor that has India residency will say so in writing without hesitation.

Frequently asked questions

Does the DPDP Act require all data to be stored in India?

No. The DPDP Act uses a negative-list model, meaning the government may restrict transfers only to specifically notified countries rather than banning offshore storage entirely. However, sector regulators like RBI, IRDAI, and SEBI impose their own stricter localisation rules, and many enterprise contracts demand India residency regardless.

Is my data in India if I use the Indian branch of AWS or Azure?

Not automatically. Data location depends on the specific region you select for each resource, not on which entity you're billed by. You must explicitly choose an Indian region such as AWS Mumbai or Azure Central India, and verify that backups, logs, and managed services also stay in India.

What is RBI's rule on payment data storage?

RBI's 2018 directive requires that all payment system data be stored only in India. There is no exception for backups or copies abroad; even a mirrored copy offshore violates the rule. If your business handles card, UPI, or wallet transaction data, offshore storage is not permitted.

Can I use Microsoft 365 or Google Workspace and stay India-resident?

Yes. Both offer India data residency, but it must be configured at the tenant level and confirmed for each covered data type like mail and files. Setting up the tenant with the correct data location from the start is far easier than migrating it later, which is why we handle this during the licensing setup itself.

How much extra does keeping data in India cost?

Usually very little. Intra-India data transfer between regions like Mumbai and Hyderabad is inexpensive, and compute pricing in Indian regions is comparable to other Asia-Pacific regions. The real cost is one-time architecture and configuration effort, not ongoing spend.

What do enterprise clients actually ask for as proof of residency?

They typically want a data flow map, written residency statements from your sub-processors, and evidence of region configuration such as screenshots. A concise one-page attestation covering primary storage, backups, logs, and third-party tools answers most vendor security questionnaires.

Do I need a physical office in India for compliance too?

Data residency and business registration are separate, but many SMBs need a registered address for GST and company compliance while keeping overheads low. A virtual office address for GST and company registration covers that need without a long-term lease.

Getting your data residency right without the guesswork

The gap between "I think our data is in India" and a documented, defensible answer is where deals are won or lost in 2026. Getting your data residency India cloud setup right isn't about buying more expensive infrastructure — it's about choosing the right regions, closing the quiet leaks in backups and logs, and having the paperwork ready before anyone asks. The cost is mostly upfront thinking, and the payoff is faster enterprise sales and zero audit panic.

If you're staring at a compliance questionnaire, planning a migration, or just want a straight answer on whether your current setup would survive scrutiny, that's exactly what we do. Explore our full range of services, learn more about eDarpan, or get in touch for a review of your cloud residency posture. And if your growth plans include physical space too, our property services for buying, renting, and investing in Indian real estate can help there as well.

Image credit: Innovate Maryland Emerging Technology Center by MDGovpics via flickr (BY 2.0), sourced through Openverse.