Data Residency Rules for Indian SMBs: Where Your Data Must Live

Last year I sat across a founder in Pune who ran a fintech aggregator with about 40 employees. His face went pale mid-meeting. His compliance officer had just flagged that their customer payment data was sitting in an AWS Singapore region, and RBI's payment data localisation mandate says that data has to stay in India. He was staring down a possible show-cause notice and a scramble to migrate live systems. The kicker? Nobody on his tech team had ever read the actual circular. They'd just picked the cheapest region during setup three years earlier.

This is more common than you'd think. RBI's payment data localisation directive has been in force since October 2018, and the Digital Personal Data Protection (DPDP) Act became law in August 2023 with rules still being finalised as of 2024. Yet a huge chunk of Indian SMBs still deploy to whatever cloud region the setup wizard defaults to. Getting data residency India wrong isn't just a paperwork problem. It can mean regulatory penalties, blocked payment licences, and expensive emergency migrations that eat your quarter.

In this post I'll break down exactly where different types of data must physically live, which regulations apply to your business, how to pick a compliant cloud region without paying a premium for it, and a real migration walkthrough. No legalese dumping, just what actually matters when you're the one signing off on the architecture.

Key Takeaways

• RBI payment data must stay in India — full stop. If you touch payments, cards, or wallets, your data has one home: an Indian data centre.
• The DPDP Act allows cross-border transfer by default, except to countries the government blacklists. This is more permissive than most people assume, but sector rules override it.
• All three major clouds have Indian regions — AWS Mumbai, Azure Central/South India (Pune/Chennai), and GCP Mumbai/Delhi — and pricing is usually within 5–15% of Singapore.
• Sector regulators matter more than the general law: RBI for finance, IRDAI for insurance, CERT-In for logging, and MeitY for government contracts.
• Egress fees, not compute, are the hidden cost when you're moving data across regions to comply. Plan your architecture to keep traffic in-region.
• Document your data residency decisions in writing. During an audit, "we chose Mumbai region and here's why" is worth more than the choice itself.

Which Indian regulations actually dictate where your data lives?

There's no single "India data localisation law." Instead you have a patchwork of sector regulators and one broad statute. Knowing which ones apply to your business saves you from over-engineering.

RBI payment data localisation (the strict one)

The Reserve Bank of India's April 2018 directive is unambiguous: all payment system data must be stored only in India. This covers full transaction details, customer data, and payment credentials. If you're a payment aggregator, a PPI (prepaid instrument) issuer, a fintech handling card data, or even a SaaS that processes UPI transactions, this applies.

You can process a transaction abroad if the foreign leg requires it, but the data must be brought back and stored in India within 24 hours, and any foreign copy deleted. Auditors check for a System Audit Report (SAR) from a CERT-In empanelled auditor. This is not optional and there's no grace for SMBs.

DPDP Act 2023 (the broad one)

The Digital Personal Data Protection Act governs personal data of Indian residents. Contrary to what a lot of fear-mongering suggests, the DPDP Act does not mandate blanket localisation. Its default position is that you can transfer personal data outside India, unless the transfer is to a country the central government specifically restricts via notification.

So for a general SMB — say a manufacturing firm storing employee and customer contact data — DPDP alone doesn't force you to keep everything in Mumbai. But it does require consent, purpose limitation, breach notification, and reasonable security safeguards. And it lets the government tighten localisation for specific categories later, so building India-first is future-proofing.

CERT-In directions (the logging one)

CERT-In's April 2022 directions require that logs of ICT systems be maintained within Indian jurisdiction for 180 days. Service providers and intermediaries also have to report certain cyber incidents within six hours. Your log storage location matters here, not just your primary data.

Sector-specific overrides

• IRDAI (insurance): Records of policyholders must be held in data centres located in India.
• MeitY / government contracts: If you sell to government or PSUs, expect data localisation and often MeitY-empanelled cloud requirements written into the tender.
• Healthcare: Clinical and patient data has its own sensitivities. If you're in this space, read our healthcare cloud compliance guide for Indian clinics.

What does "data residency India" mean for cloud region selection?

When people say data residency India, they mean the physical location where your data is stored and processed sits inside Indian territory. In cloud terms, that translates to picking the right region and being careful about which services replicate data elsewhere.

Here's the trap most SMBs fall into: they select an Indian region for their main storage but leave defaults on for backups, disaster recovery, CDN, or managed database replicas that quietly copy data to Singapore or the US. Data residency is about the whole data lifecycle, not just the primary bucket.

All three hyperscalers give you Indian options:

• AWS: Asia Pacific (Mumbai) — ap-south-1 — and Hyderabad — ap-south-2.
• Microsoft Azure: Central India (Pune), South India (Chennai), West India (Mumbai).
• Google Cloud: Mumbai — asia-south1 — and Delhi — asia-south2.

Region selection isn't a one-time checkbox. For a nuanced setup you'll often keep primary and DR both inside India (e.g. AWS Mumbai as primary, Hyderabad as DR). If you're not confident in configuring cross-region replication correctly, our cloud migration and managed services team handles exactly this kind of region-locked architecture.

AWS vs Azure vs GCP: which is best for Indian data residency and cost?

The honest answer is that all three are compliant if configured right, so the decision usually comes down to your existing stack, pricing, and support. Here's how they stack up for an India-first SMB deployment.

Criteria	AWS (Mumbai/Hyderabad)	Azure (Pune/Chennai/Mumbai)	GCP (Mumbai/Delhi)
Indian regions	2 regions, multiple AZs	3 regions	2 regions
In-country DR possible	Yes (Mumbai + Hyderabad)	Yes (Central + South)	Yes (Mumbai + Delhi)
Rupee billing	Available via AWS India	Available (often best for MS shops)	Available via GCP India
Typical premium vs Singapore	~5–12%	~8–15%	~5–10%
Best fit	Startups, fintech, broad service catalogue	Firms already on Microsoft 365 / Windows	Data/AI-heavy workloads, Kubernetes
GST invoicing	Proper Indian GST invoice	Proper Indian GST invoice	Proper Indian GST invoice

A practical note on billing: getting a proper GST invoice with your GSTIN matters for input tax credit. All three now bill through Indian entities, but you have to configure your tax registration in the console correctly. If you're a Microsoft-centric shop already paying for Microsoft 365 licensing, Azure often wins on integrated billing and identity. If you live in Google Workspace, GCP feels natural. We break the productivity side of this down in our comparison of Zoho vs Google Workspace vs Microsoft 365 for Indian SMBs.

Common Mistake: Teams obsess over per-hour compute pricing between clouds and ignore egress fees — the charge for data leaving a region. If your compliance fix involves copying data from Singapore back to Mumbai, you'll pay egress on every gigabyte moved, and ongoing egress if apps in one region keep pulling from another. We've seen a ₹18K/month bill balloon by ₹40K just from cross-region chatter. Read our deep dive on cloud egress fees blowing up SMB budgets before you architect.

Case study: how a Gurgaon logistics SMB fixed its data residency and cut costs

Let me walk through a real engagement (details lightly anonymised). A 22-person logistics company in Gurgaon ran a fleet-tracking and billing platform. Their data — including driver KYC, customer invoices, and payment records from a wallet feature — was split across an on-prem server in their office and an AWS Singapore account a former contractor had set up.

Two problems. First, the wallet payments sitting in Singapore violated RBI localisation. Second, they were paying roughly ₹52,000/month: ₹22K on the on-prem box (AMC, power, a backup drive that had failed twice), and ₹30K on Singapore cloud plus egress from constant cross-region syncs.

What we did

1. Data classification (week 1): We mapped every data store to a category — payment data (RBI-bound), personal data (DPDP), and operational logs (CERT-In, 180-day retention).
2. Region decision: Primary moved to AWS Mumbai (ap-south-1), DR to Hyderabad (ap-south-2). Payment data locked to Mumbai only, no foreign replication.
3. Migration (weeks 2–4): Lift-and-shift the app servers, then re-point the managed database to an RDS instance in Mumbai. On-prem server decommissioned after a 2-week parallel run.
4. Egress cleanup: The old cross-region sync was killed. All app-to-DB traffic now stays inside Mumbai, so egress dropped to near zero.
5. Logging: CloudTrail and app logs configured to an S3 bucket in Mumbai with a 180-day lifecycle policy to satisfy CERT-In.
6. Documentation: A one-page data residency map and a rationale memo, kept ready for their auditor.

The result

New monthly cloud spend settled at about ₹19,500 — right-sized instances, no duplicate infrastructure, and negligible egress. That's a ~62% cut from ₹52K, and more importantly they were RBI-compliant before their SAR audit deadline. The migration itself took four weeks with roughly two hours of planned downtime on a Sunday night.

The lesson isn't "cloud is always cheaper." It's that a residency-driven cleanup often surfaces waste — orphaned servers, cross-region syncs, oversized instances — that you fix along the way. If you want this kind of audit for your setup, our IT consulting team runs data residency assessments as a fixed-scope engagement.

How do I actually pick a compliant cloud region? A step-by-step method

Here's the process I use with clients. You can brief your own vendor with these steps or run it internally.

1. Inventory your data. List every place data lives: databases, object storage, backups, log stores, third-party SaaS, email, CRM. You cannot secure what you haven't mapped.
2. Classify each store. Tag it as payment data (RBI), personal data (DPDP), sensitive sector data (IRDAI/health), or general operational data. This tells you the strictness level.
3. Match rules to stores. Payment and insurance data must stay in India. Personal data can stay abroad under DPDP but keeping it in India is safer and simpler. Logs must be India-retained for 180 days.
4. Choose primary and DR regions. For anything India-bound, pick two Indian regions from the same provider for high availability without leaving the country.
5. Audit your defaults. Check backup destinations, CDN edge behaviour, database read-replicas, and managed service defaults. This is where data leaks the country silently.
6. Lock it down with policy. Use service control policies (AWS SCPs), Azure Policy, or GCP Organization Policy to deny resource creation outside Indian regions. Prevention beats detection.
7. Configure GST/tax and rupee billing. Add your GSTIN so invoices carry it. This protects your input tax credit.
8. Document the decision. Write a short residency memo: which data, which region, why. Auditors love this and it takes an hour.

Pro Tip: Step 6 is the one most SMBs skip and later regret. A single junior developer spinning up a test bucket in us-east-1 can put personal data outside India by accident. An organisation-level policy that flatly blocks non-Indian regions means the mistake can't happen in the first place. Set it once and stop worrying.

Do SaaS tools like WhatsApp, email, and SMS count for data residency?

Yes, and this is the blind spot. Your carefully region-locked cloud means little if your CRM, email, or messaging tools park customer data abroad without you realising.

A few practical points:

• Messaging: If you send customer OTPs or notifications, check where your provider stores message logs and phone numbers. Our WhatsApp Business API and bulk SMS setups are configured with Indian data handling in mind.
• Email and productivity: Both Google Workspace and Microsoft 365 let you influence data location and offer data-region controls on higher tiers. Configure these deliberately. While you're at it, tighten security — see our guide on email security for Indian SMBs.
• Voice and AI: If you deploy an AI voicebot that records calls, those recordings are personal data. Know where they're stored.
• Custom apps: When we build custom software or mobile apps for clients, region-locking and consent capture are baked in from day one, not bolted on later.

The rule of thumb: every vendor that touches Indian customer data is part of your compliance surface. Ask them, in writing, where the data lives.

How much does data residency compliance actually cost an SMB?

Less than most people fear if you plan it, and a lot more if you react to an audit notice. The premium for an Indian cloud region over Singapore is typically 5–15%, which for a small workload might be a few thousand rupees a month. Compare that to the cost of an emergency migration, legal fees, or a stalled payment aggregator licence.

Rough numbers for a typical 20–50 person SMB:

• Data residency assessment: a one-time consulting engagement, usually a few days of work.
• Cloud spend: often flat or lower after cleanup, as our Gurgaon example showed.
• CERT-In empanelled audit (if RBI applies): priced by the auditor, an annual cost for regulated entities.
• Ongoing: mostly the small region premium plus your normal managed services.

The mistake is treating this as pure cost. A residency review usually pays for itself by eliminating orphaned infrastructure and cross-region egress. For manufacturers modernising their whole stack, this fits neatly into a broader plan — see our digital transformation playbook for Indian manufacturers.

Frequently asked questions

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

No. The DPDP Act 2023 permits cross-border transfer of personal data by default, and only restricts transfers to specific countries the central government notifies. Sector regulators like RBI impose stricter localisation, but the general law itself does not mandate blanket data localisation.

Where must RBI payment data be stored?

RBI's 2018 directive requires all payment system data to be stored only in India. Processing can happen abroad if necessary, but the data must be returned to Indian storage within 24 hours and any foreign copy deleted. Compliance is verified through a System Audit Report by a CERT-In empanelled auditor.

Is AWS Mumbai region compliant for Indian businesses?

Yes, AWS Mumbai (ap-south-1) is a physically Indian region and is suitable for data residency requirements, provided you also lock backups, DR, and logging to Indian regions. Pair it with AWS Hyderabad (ap-south-2) for in-country disaster recovery.

How long must I retain logs under CERT-In rules?

CERT-In's April 2022 directions require ICT system logs to be maintained for 180 days within Indian jurisdiction. Certain cyber incidents must also be reported to CERT-In within six hours of detection.

Do I need to keep employee data in India?

Under the DPDP Act, employee personal data can generally be stored abroad unless restricted by government notification. However, keeping it in an Indian region simplifies compliance and future-proofs you against tighter rules, so many SMBs choose India-first storage regardless.

Will an Indian cloud region cost more than Singapore or the US?

Usually only 5–15% more on compute and storage. In practice, moving to a properly configured single Indian region often reduces total cost by eliminating cross-region egress fees and duplicate infrastructure, as we've seen repeatedly in real migrations.

Does using WhatsApp Business API affect my data residency compliance?

It can, because message content, phone numbers, and delivery logs are personal data. You should confirm where your provider stores this data and ensure consent is captured. Our WhatsApp Business API setups are configured with Indian data handling practices in mind.

Getting your data residency right, without overspending

Data residency India compliance isn't the bureaucratic nightmare people imagine. For most SMBs it comes down to three moves: know which regulator applies to you, put your regulated data in an Indian region locked down by policy, and document why. Do that, and you turn a lurking audit risk into a non-event, often while trimming your cloud bill in the process.

The businesses that struggle are the ones that ignore it until a compliance officer or an auditor forces the issue, then pay a premium to migrate under pressure. The businesses that thrive treat it as a one-time architecture decision made early and cleanly.

If you'd like a straight answer on where your data currently lives and what it would take to get compliant, that's exactly what we do. Explore our cloud migration and managed services, browse the full eDarpan services overview, or get in touch for a data residency assessment scoped to your business. And if you're also sorting out a registered address for GST or company registration, our virtual office service can handle that piece too.

Image credit: File:Aadhaar - Biometric Data Collection - Chirantani Vidyapith - Howrah 2012-08-10 01540.jpg by Biswarup Ganguly via wikimedia (BY 3.0), sourced through Openverse.