Cloud Data Localization in India: What RBI & CERT-In Require

Last year I sat across the table from the CTO of a Pune-based lending startup who had just received a rather uncomfortable email from their auditor. Their entire customer KYC database, including Aadhaar-linked records and transaction logs, was sitting in an AWS region in Singapore. The RBI examiner wanted to know exactly where that data lived, how quickly it could be produced in India on demand, and whether any copy of it existed outside the country. The team had no clean answer. That single gap threatened their NBFC partnership and put roughly ₹40 lakh of annual revenue at risk.

This is the quiet reality of cloud data localization India in 2026. It is not a theoretical compliance topic buried in a PDF. It is a business continuity issue that surfaces during audits, funding due diligence, and partnership onboarding. The RBI's payment data localization directive has been in force since October 2018, and yet I still walk into fintech and healthtech firms where nobody can produce a data flow diagram showing which systems store regulated data and where.

In this post I will break down what the RBI and CERT-In actually require, where the "Made in India" cloud push fits in, and how to architect an AWS, GCP, or Azure deployment that survives an audit. I will give you a real migration example, a vendor comparison, a step-by-step compliance walkthrough, and the mistakes I see teams make repeatedly.

Key Takeaways

• RBI's 2018 directive mandates that all payment system data be stored only in India. Foreign processing is allowed but the data must be deleted abroad and stored domestically within 24 hours.
• CERT-In's April 2022 directions require 6-month log retention (in India where possible) and reporting of specified cyber incidents within 6 hours of detection.
• All three hyperscalers (AWS Mumbai/Hyderabad, Azure Central/South India, GCP Mumbai/Delhi) have Indian regions. Localization is an architecture choice, not a vendor limitation.
• You must document data residency in a data flow diagram and be able to produce audit evidence on demand. "It's probably in Mumbai" is not compliance.
• The DPDP Act 2023 adds a separate personal data layer with a government blocklist model rather than a hard localization mandate.
• Budget for cross-region data transfer, encryption key management, and a documented incident response runbook, not just compute costs.

What does RBI actually require for data localization?

Let me clear up the biggest confusion first. The RBI's April 2018 circular on Storage of Payment System Data is narrow but strict. It applies to all system providers, payment aggregators, wallets, and banks handling payment transactions. The rule: the entire data relating to payment systems operated by them must be stored in a system only in India.

"Entire data" is the phrase that trips people up. In the FAQ clarifications, RBI defined this to include the full end-to-end transaction details, customer data (name, mobile, Aadhaar/PAN where collected), payment sensitive data (OTP, PIN), payment credentials, and transaction data (originating and destination details, amount, timestamp).

Cross-border transactions are the exception. If a transaction has a foreign leg, a copy can be processed abroad but the data must be brought back to India and any foreign copy deleted within one business day or 24 hours, whichever is earlier. This matters for anyone processing international card payments or remittances.

Who is actually covered

• Payment aggregators and payment gateways (Razorpay-style businesses)
• Prepaid instrument issuers and wallets
• NBFCs and banks handling payment data
• Fintech vendors who touch payment system data as part of a bank's ecosystem

If you are a 20-person SaaS company building a billing product that stores card transaction metadata, you are probably in scope even if you never thought of yourself as a "payment system provider." I have seen firms discover this during a bank partner's security questionnaire, far too late in the cycle.

What are CERT-In's requirements and the 6-hour rule?

CERT-In's directions of 28 April 2022 (under Section 70B of the IT Act) apply far more broadly than RBI's. They cover service providers, intermediaries, data centres, body corporates, and government organisations. If you run anything meaningful in India, this touches you.

Three obligations matter most in practice:

1. Six-hour incident reporting. Specified cyber incidents (ransomware, data breaches, unauthorised access, defacement, and a long list of others) must be reported to CERT-In within 6 hours of noticing or being made aware. This is one of the tightest reporting windows in the world.
2. Log retention. You must maintain ICT system logs for a rolling period of 180 days, and these should be maintained within India.
3. Time synchronisation. All ICT systems must sync clocks to NTP servers of NIC or NPL, or servers traceable to them. Sounds trivial until an auditor asks and your VMs are pointing at pool.ntp.org.

Common Mistake: Teams treat the 6-hour rule as an IT problem and never build a runbook. When an incident hits at 2 AM, nobody knows who authorises the CERT-In filing, who has the login, or what template to use. The clock does not care that your security lead is on holiday in Goa. Write the runbook, name the roles, and do a tabletop drill. This is exactly the kind of gap our IT consulting team flags in a compliance readiness review.

Do AWS, GCP, and Azure support Indian data localization?

Yes, all three have Indian regions, so localization is entirely achievable. The failure is almost never the cloud provider. It is the default configuration and the sneaky global services people forget about.

Criteria	AWS	Microsoft Azure	Google Cloud (GCP)
Indian regions	Mumbai (ap-south-1), Hyderabad (ap-south-2)	Central India (Pune), South India (Chennai), West India (Mumbai)	Mumbai (asia-south1), Delhi (asia-south2)
Two in-country regions for DR	Yes	Yes	Yes
Data residency controls	Region lock, SCPs, AWS Config rules	Azure Policy, resource location restrictions	Org policy: resource location constraints
In-country key management (BYOK)	KMS + CloudHSM in Mumbai	Key Vault + Managed HSM in Indian regions	Cloud KMS + Cloud HSM in Indian regions
Typical SMB entry cost (small prod workload)	₹25K–₹60K/month	₹28K–₹65K/month	₹22K–₹55K/month
Watch-out	Global services (IAM, Route 53, CloudFront) are global by design	Some AI/analytics services default to other regions	Fewer managed services in asia-south2

The prices above are indicative for a modest production workload (a couple of app servers, a managed database, backups, and some object storage). Your actual bill depends heavily on data transfer and whether you commit to reserved capacity. If you are weighing one provider against several, our note on multi-cloud vs single cloud for Indian SMBs is worth a read before you lock in.

The global-service trap

Here is the detail that fails audits. AWS IAM, CloudFront, and Route 53 are global services. If your CDN caches user data at edge locations outside India, or your logs land in a global bucket by default, you have a residency violation even though your primary region is Mumbai. The same is true for certain Azure and GCP services. You have to explicitly restrict edge behaviour and audit every managed service you switch on.

How do you architect a compliant deployment? A step-by-step walkthrough

This is the practical part. Whether you brief a vendor or do it in-house, here is the sequence I follow when setting up a compliant environment on one of the hyperscalers.

1. Map your data first. Before touching the console, build a data flow diagram. List every data type (payment data, KYC, personal data, logs), where it is created, where it moves, and where it rests. This document is your single most important audit artifact.
2. Pick your primary and DR regions inside India. For example, AWS Mumbai as primary and Hyderabad for disaster recovery. Never let DR spill to Singapore for convenience.
3. Enforce region locking at the org level. On AWS use Service Control Policies to deny resource creation outside ap-south-1 and ap-south-2. On Azure use resource location policies. On GCP use the resource location org constraint. This prevents a developer accidentally spinning up a bucket in Frankfurt.
4. Lock down storage and databases. Enable encryption at rest with keys managed in an Indian KMS/HSM. Turn on encryption in transit (TLS 1.2+). Confirm backups and snapshots stay in-country.
5. Fix logging and retention. Route all logs to an in-India log store with 180-day retention. Set lifecycle rules. Point every system's NTP to NIC/NPL servers.
6. Configure CDN and edge carefully. Restrict CDN to serve only non-sensitive static assets, or configure edge behaviour so that no regulated data is cached outside India.
7. Build the incident runbook. Document detection, escalation, who files with CERT-In, the 6-hour clock, and the reporting template. Assign named owners with backups.
8. Set up continuous compliance checks. Use AWS Config, Azure Policy, or GCP Org Policy with alerts, so any drift out of the Indian region raises a flag immediately.
9. Produce audit evidence. Generate a periodic report showing region compliance, encryption status, and log retention. Keep it ready so you never scramble during an examination.

If your team does not have deep cloud engineers, this is exactly where a cloud migration and managed services partner earns their fee. We have run this playbook for regulated firms and the difference between a clean audit and a painful one is almost always documentation and enforcement, not raw technical skill.

Real example: a Gurgaon fintech that got its localization right

A 22-person lending-tech firm in Gurgaon came to us after a bank partner's security team flagged that their loan management data, including PAN and repayment records, was hosted in a US region on a legacy Heroku-style setup. They were paying roughly ₹1.6 lakh a month across scattered services, and the residency gap was blocking a partnership worth far more.

Here is what we did over about six weeks:

• Weeks 1–2: Built the data flow diagram, classified every data store, and identified three services holding regulated data outside India.
• Weeks 3–4: Set up an AWS environment with Mumbai primary and Hyderabad DR, region-locked via SCPs, KMS keys in Mumbai, and centralised logging with 180-day retention.
• Week 5: Migrated the database and application with a scheduled cutover during a low-traffic window, validated integrity, and deleted the foreign copies.
• Week 6: Wrote the CERT-In incident runbook, ran a tabletop drill, and produced the first audit-evidence report for their bank partner.

The outcome: monthly cloud spend settled at about ₹95K after right-sizing (down from ₹1.6 lakh), the residency gap closed, and the bank partnership cleared its security review. The cost saving was almost a bonus. The real win was unblocking revenue that dwarfed the infrastructure bill.

Pro Tip: When you migrate regulated data out of a foreign region, capture proof of deletion. A screenshot is weak evidence. Use the provider's audit logs to show the resource was terminated, and keep that log with your compliance file. Auditors love a paper trail and hate assurances.

Where does the DPDP Act and "Made in India" cloud fit in?

The Digital Personal Data Protection Act, 2023 is a separate layer from RBI and CERT-In. Importantly, DPDP does not impose blanket hard localization on all personal data. Instead it allows cross-border transfers except to countries the government specifically blocks. So your compliance stack now has three distinct concerns: RBI (payment data, hard localization), CERT-In (logs and incident reporting), and DPDP (personal data handling and consent).

The "Made in India" cloud and sovereign cloud conversation is gaining ground, especially for government and highly regulated workloads. If that is on your radar, our deeper explainer on sovereign cloud in India for SMBs covers when it genuinely matters versus when a well-configured hyperscaler region is enough. For most SMBs, a properly locked-down Indian region on AWS, Azure, or GCP satisfies the current requirements without the premium of a dedicated sovereign offering.

If your business is going through broader modernisation alongside this, the digital transformation playbook for Indian manufacturers and our custom software development team can help you build systems that are compliant by design rather than retrofitted later.

Practical compliance checklist before your next audit

• Data flow diagram documenting all regulated data and its location
• Region locking enforced at the org level (SCP / Azure Policy / GCP Org Policy)
• Encryption at rest and in transit, with keys managed in India
• Backups, snapshots, and DR all inside India
• Centralised logs with 180-day retention, stored in India
• NTP synced to NIC/NPL servers
• CERT-In incident runbook with named owners and a tested 6-hour process
• Proof-of-deletion evidence for any migrated foreign data
• Periodic audit-evidence report ready on demand
• Consent and personal data handling aligned to DPDP obligations

Print this. If you cannot tick every box today, you have your project plan. Communication tooling matters here too. If you use messaging channels for customer OTPs or notifications, make sure your WhatsApp Business API and bulk SMS provider handle sensitive data in line with these rules, since payment credentials must never leak into non-compliant systems.

Frequently Asked Questions

Does all data need to be stored in India as per RBI?

No. RBI's mandate applies specifically to payment system data, which must be stored only in India. Non-payment data is not covered by that circular, though it may fall under CERT-In and DPDP obligations. Always classify your data first so you apply the right rule to the right dataset.

What is the CERT-In 6-hour reporting rule?

Under CERT-In's April 2022 directions, organisations must report specified cyber incidents such as data breaches and ransomware within 6 hours of noticing them. You report to CERT-In using their prescribed channels and template. Having a pre-built runbook with named responders is the only realistic way to hit that window.

Can I use AWS or Azure and still be compliant with Indian data localization?

Yes. AWS Mumbai/Hyderabad, Azure Central/South India, and GCP Mumbai/Delhi all keep data in-country. Compliance depends on your configuration: region locking, in-India key management, log retention, and controlling global edge services. The vendor gives you the tools; you must enforce the policy.

Is cross-border payment processing allowed under RBI rules?

Yes, with a condition. For transactions with a foreign leg, a copy may be processed abroad, but the data must be stored in India and any foreign copy deleted within one business day or 24 hours, whichever is earlier. Keep deletion evidence in your compliance file.

Does the DPDP Act require data localization in India?

Not as a blanket rule. The DPDP Act, 2023 permits cross-border transfer of personal data except to countries the government specifically restricts through a blocklist. This is different from RBI's hard localization for payment data, so treat the two obligations separately.

How long does a compliant cloud migration usually take for an SMB?

For a small-to-mid regulated firm, expect four to eight weeks depending on data volume and application complexity. The engineering is rarely the bottleneck; data mapping, testing, and documentation take the most time. Rushing the cutover without validating data integrity is where projects go wrong.

What logs does CERT-In require me to keep and for how long?

CERT-In requires ICT system logs to be maintained for a rolling period of 180 days, and these should be maintained within India. This includes system, application, and access logs relevant to security. Set lifecycle policies so retention is automatic rather than manual.

Getting this right without derailing your roadmap

Cloud data localization India compliance is not a one-time project you finish and forget. It is a posture you maintain through region enforcement, disciplined logging, and a rehearsed incident process. The firms that treat it as ongoing hygiene sail through audits and partner security reviews. The ones that treat it as paperwork get the uncomfortable email from their auditor, usually at the worst possible time.

If you are staring at a legacy setup, an upcoming RBI examination, or a bank partner's security questionnaire, the smart move is to map your data and lock down your architecture before you are forced to. Our team has done this for lending, healthtech, and logistics firms across India, and we can run a readiness review that tells you exactly where the gaps are.

Explore our cloud migration and managed services, browse the full eDarpan services overview, or talk to us about a compliance readiness assessment. If licensing and collaboration tooling are also on your plate, our guides to Google Workspace and Microsoft 365 licensing, plus our comparison of Zoho vs Google Workspace vs Microsoft 365, will help you round out a compliant, India-ready stack.

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