Manu Shukla

Posted on Aug 1 • Originally published at ecorpit.com

DPDP data residency in 2026: the compliant multi-region cloud architecture for India

#dpdp #dataresidency #datalocalization #cloudarchitecture

DPDP data residency in 2026: the compliant multi-region cloud architecture for India

Summary. India notified the Digital Personal Data Protection Rules in November 2025, and the core business obligations land 18 months later, in 2027. Penalties reach ₹250 crore, about $28 million, per breach. The Rules do not force everything onshore, but they let the government name categories of personal data that must stay in India, they require security controls including one-year log retention and breach notice to the Data Protection Board within 72 hours, and they sit on top of stricter sector rules from the RBI, SEBI and IRDAI. For an Indian SaaS or regulated team, the practical answer is a data-residency architecture that keeps regulated data in one of the in-country cloud regions, AWS Mumbai and Hyderabad, Azure Central and South India, or Google Cloud Mumbai and Delhi, with cross-border transfer controls you can prove. This guide sets out that architecture, and where eCorpIT builds it.

Most teams read "data residency" as one switch: pick an Indian region and you are done. That is not how the DPDP Rules work, and it is not how your auditors will read it. Residency is a property of specific data flows, not of your whole account. Some personal data can leave India today, some categories will be blocked once the government notifies them, and payment and insurance data already cannot leave under sector rules that predate DPDP. An architecture that treats every table the same either over-restricts and costs you money, or under-restricts and fails an audit.

This is the design we build for Indian product and platform teams: classify the data, place each class in the right region, control the crossings, and prove all of it with logs. It is engineering work with a compliance deadline attached, and the deadline is close enough that starting now is the cheap option.

What the DPDP Rules actually require on residency

The DPDP Rules 2025 were notified in November 2025 and operationalise the Digital Personal Data Protection Act 2023, as India Briefing detailed. Three parts of them drive architecture directly.

First, localization is conditional, not blanket. Personal data may still be transferred outside India, subject to conditions the central government prescribes, which K&S Partners describes as a blacklist model: transfers are allowed except to countries the government specifically notifies as restricted, and no restricted list has been published yet. But the Rules also let the government name categories of personal data, and related traffic data, that Significant Data Fiduciaries must not transfer outside India at all. You cannot know today exactly which categories those will be, so the safe design keeps sensitive personal data in-country and treats cross-border flow as the exception you can switch off.

Second, the security controls are specific. Fiduciaries must apply encryption, masking or tokenization, strict access controls, and continuous logging and monitoring, with one-year log retention and verified backups. On a breach, affected users must be told promptly and the Data Protection Board notified, with a detailed report within 72 hours. Union Minister for Electronics and IT Ashwini Vaishnaw has called the framework a possible "global template" for data regulation, according to Storyboard18, and the security floor reads like one.

Third, retention is bounded. Personal data cannot be kept beyond one year of user inactivity unless another law requires it, and users get 48 hours' notice before inactivity-based erasure. That turns residency into a lifecycle problem: the data has to live in the right place and be deleted on schedule, which is an architecture and automation task, not a policy PDF. Our DPDP legacy data remediation guide covers the cleanup that most existing systems need to meet that erasure rule.

Sector rules stack on top, and they are stricter

DPDP is the floor. For regulated industries, sector rules already mandate hard localization and they are not relaxed by DPDP, as K&S Partners sets out. The Reserve Bank of India requires that all payment system data, including full end-to-end transaction details, be stored only in India. Insurance regulator IRDAI requires policyholder, claims and underwriting data to sit in data centres located in India. Market regulator SEBI expects regulated entities to keep critical systems and regulatory data within Indian jurisdiction, with cloud usage confined to data centres prescribed by the Ministry of Electronics and IT, as Securiti summarises.

The practical consequence is that a fintech, an insurer or a broker cannot lean on DPDP's liberal cross-border default. If your product touches payments, insurance or securities, the strictest applicable rule wins, and for those flows the strictest rule is onshore-only. The architecture has to encode that per data class, which is why a single "India region" flag is not enough.

The in-country regions you can build on

All three hyperscalers run in-country regions in India, and all are empanelled by the Ministry of Electronics and IT, as data-residency guidance for India notes. The differences that matter for a residency design are region count, availability-zone depth for high availability, and how cleanly you can pin storage and processing to India.

Cloud region option	India regions	Availability zones	Data residency for DPDP
AWS	Mumbai (ap-south-1), Hyderabad (ap-south-2)	3 per region	In-country storage and processing; MeitY-empanelled
Microsoft Azure	Central India (Pune), South India (Chennai), West India (Mumbai)	Zones in Central India	In-country storage and processing; MeitY-empanelled
Google Cloud	Mumbai (asia-south1), Delhi (asia-south2)	3 per region	In-country storage and processing; MeitY-empanelled
Two-region in-country	Any two India regions above	Cross-region for DR	Onshore disaster recovery without leaving India
Single region only	One India region	Zonal HA only	Meets residency, weaker regional resilience

The design point most teams miss is disaster recovery. Keeping regulated data in India and keeping it resilient are both required, and the clean way to do both is a two-region-in-country footprint: primary in one Indian region, recovery in another, so failover never sends data offshore. AWS Mumbai plus Hyderabad, or Google Cloud Mumbai plus Delhi, give you that without a cross-border hop. We build this pattern as a multi-region resilience and disaster recovery service, because residency and resilience are the same conversation in India.

The reference architecture we build

The architecture has four moving parts, and the order matters.

Start with data classification. Every table, bucket and queue gets a class: general personal data, sensitive or government-specified personal data, and sector-regulated data such as payment or insurance records. Classification is the load-bearing step, because everything downstream keys off it. Without it, teams apply the strictest rule everywhere and pay for it, or the loosest rule everywhere and fail.

Place each class by rule. General personal data can use an India region by default and remain eligible for controlled cross-border processing later. Government-specified and sensitive personal data stays in India with no egress. Payment, insurance and securities data stays in India under the relevant sector rule, in the region and configuration that rule allows. The placement lives in infrastructure-as-code, not in a wiki, so it is enforced and auditable.

Control the crossings. Any flow that leaves India, an analytics pipeline, a third-party API, a support tool, becomes an explicit, logged, switch-off-able boundary. You want a single choke point where cross-border transfer is allowed or denied per data class, so that when the government notifies a restricted category or country you flip one control rather than re-architecting. This is also where processor contracts and the DPDP security clauses attach.

Prove it with logs and lifecycle. The Rules require one-year log retention and 72-hour breach reporting, so the same logging that satisfies your SRE needs also satisfies the auditor, if it captures access to personal data and cross-border events. Retention automation enforces the one-year inactivity deletion with the 48-hour user notice. Building consent capture and withdrawal into this layer connects the architecture to the DPDP consent manager framework that the Rules also introduce.

Data class	Where it lives	Cross-border allowed?	Primary driver
General personal data	India region, default	Conditionally, once government conditions are met	DPDP Rules 2025
Government-specified personal data	India only, no egress	No, once notified	DPDP significant-fiduciary localization
Payment and transaction data	India only	No	RBI payment data storage rule
Insurance policy and claims data	India data centres	No	IRDAI cyber security guidelines
Securities and market data	India, MeitY-prescribed centres	No	SEBI cloud framework
Non-personal operational logs	India region, one-year retention	Case by case	DPDP security safeguards

What this costs, and why starting now is cheaper

Two-region-in-country resilience costs more than a single region, and pinning workloads to India can cost more than using the cheapest global region. That is real, and it is smaller than the alternative. Penalties under the DPDP Act reach ₹250 crore, about $28 million at ₹88.58 to the dollar, per breach, and the harder cost is retrofitting residency into a system that mixed data classes freely for years. Reclassifying and moving live data under a deadline is far more expensive than designing the boundaries in from the start. Our DPDP compliance cost analysis breaks down where the spend actually goes for Indian startups facing the 2027 timeline.

The teams that will spend the least are the ones that classify and place their data now, while the restricted-category list is still unpublished and they can design the choke points calmly. The teams that will spend the most are the ones that wait for the government to notify a category and then discover their data is spread across regions with no boundary to switch.

Common residency mistakes we see

Four patterns show up repeatedly when we review Indian systems for residency.

The first is the single-flag assumption: a team sets a default region to India and believes the job is done, while an analytics export, a customer-support tool, or a logging pipeline quietly ships personal data to a foreign region. Residency fails at the flows you forgot, not the database you remembered.

The second is treating backups and disaster recovery as out of scope. A backup in a foreign region is still a transfer, and a failover that promotes an offshore replica moves regulated data across a border at the worst possible moment. Residency has to cover the recovery path, which is why the two-region-in-country pattern matters.

The third is mixing data classes in one store. When payment data, general personal data, and non-personal telemetry share a table, the strictest rule contaminates everything, and you either over-restrict the whole store or cannot prove the regulated subset stayed onshore. Separating classes early is cheaper than untangling them later.

The fourth is logging that cannot answer the audit question. Plenty of teams retain logs for a year but cannot show who accessed a given user's records or when data crossed a border, because the logs were built for uptime, not for DPDP. The fix is to decide, at design time, that access to personal data and every cross-border event are first-class logged events.

A phased path to a compliant footprint

You do not have to rebuild everything at once, and you should not. The sequence that works starts with a data-flow map: every store, every export, every third-party processor, tagged with a data class and a current location. That map is usually the first time a team sees exactly how much personal data leaves India today.

From there, fix the flows that already break sector rules, the payment, insurance and securities data that sits or transits offshore, because those are non-negotiable under the RBI, IRDAI and SEBI today, not in 2027. Next, stand up the two-region-in-country footprint and move sensitive and government-specified personal data onto it with no egress. Then build the single cross-border choke point and route the remaining permitted transfers through it, so a future restricted-category notification becomes a configuration change rather than a rebuild. Finally, wire retention and one-year deletion automation with the 48-hour user notice, and confirm the logging captures access and transfer events.

Each phase is shippable on its own and cuts risk immediately, which is what makes this affordable. A team that maps flows and fixes the sector-rule breaches this quarter is in a very different position from one that waits for the restricted-category list and then scrambles. Our cloud migration and modernization work usually carries this sequence, because residency is rarely a greenfield build.

How eCorpIT builds it

eCorpIT is a Gurugram-based, senior-led engineering organisation, founded in 2021 and certified for CMMI Level 5, MSME and ISO 27001:2022, and an AWS, Microsoft and Google partner. We design and build DPDP-aligned data-residency architecture for Indian SaaS and regulated teams: data classification, region placement across AWS, Azure or Google Cloud India regions, two-region-in-country disaster recovery, cross-border transfer controls, and the logging and retention automation the Rules require. We design applications aligned with DPDP Act requirements and the relevant RBI, SEBI and IRDAI localization rules, rather than claiming a certification on your behalf. If you are building for the 2027 deadline, start with our DPDP engineering playbook and our DPDP-ready app development practice, then contact us to scope the architecture for your data.

FAQ

What does data residency mean under India's DPDP Rules?

Data residency means keeping specified personal data physically stored and processed in India. The DPDP Rules 2025 allow most cross-border transfers by default but let the government name categories of personal data that Significant Data Fiduciaries must not transfer outside India. Sector rules from the RBI, IRDAI and SEBI already mandate onshore storage for regulated data.

When do the DPDP obligations take effect?

The DPDP Rules were notified in November 2025. Some provisions, such as the Data Protection Board, took effect immediately, Consent Manager rules follow at 12 months, and core business obligations including security safeguards and retention rules apply 18 months after notification, landing in 2027. Teams should design residency architecture well before that deadline.

Which cloud regions support DPDP data residency in India?

AWS runs Mumbai and Hyderabad regions, Azure runs Central India, South India and West India, and Google Cloud runs Mumbai and Delhi. All are empanelled by the Ministry of Electronics and IT. For onshore disaster recovery, a two-region-in-country footprint keeps failover inside India rather than sending data to a foreign region.

Do RBI and IRDAI rules override DPDP on residency?

They stack on top and are stricter. The RBI requires payment system data, including full transaction details, to be stored only in India. IRDAI requires insurance data in Indian data centres, and SEBI confines regulated data to MeitY-prescribed centres. For payment, insurance and securities data, the onshore-only sector rule applies regardless of DPDP's more liberal cross-border default.

What are the penalties for getting DPDP residency wrong?

Penalties under the DPDP Act reach ₹250 crore, about $28 million, per breach, graded by severity and with protections for MSMEs. Beyond fines, the larger practical cost is retrofitting residency into systems that mixed data classes for years, which is far more expensive than designing data classification and region placement in from the start.

How should we classify data for a residency architecture?

Classify every store as general personal data, government-specified or sensitive personal data, or sector-regulated data such as payment or insurance records. Placement, cross-border rules and retention all key off that class. Classification belongs in infrastructure-as-code so it is enforced and auditable, not in a policy document that engineering cannot act on.

Can we still use global cloud services under DPDP?

Yes, for data that is not restricted, subject to the government's cross-border conditions and any processor contract terms. The safe pattern is a single, logged choke point where cross-border transfer is allowed or denied per data class, so that when the government notifies a restricted category or country you change one control rather than re-architecting the system.

Does DPDP require log retention?

Yes. The Rules require continuous logging and monitoring with one-year log retention, plus breach notification to the Data Protection Board with a detailed report within 72 hours. The same logs that record access to personal data and cross-border transfer events serve both operational monitoring and audit, provided they are designed to capture those events from the start.