Data Localisation vs Cloud Architecture: An Inevitable Conflicts

Introduction

Cloud computing revolutionised enterprise IT by decoupling data from hardware. Its core promise: data location shouldn't matter, letting applications and data flow across global data centres, automatically adjusting resources, backing up, and boosting performance by smartly routing requests. NIST defines the cloud by on-demand service, resource pooling, rapid elasticity, and broad access, all at odds with fixed geographic rules. 

But the rules haven't kept up. In India, the Digital Personal Data Protection (DPDP) Act, 2023, along with sector rules from the RBI, IRDAI, and TRAI, now say exactly where your data can be stored, processed, and transferred. For example, Section 16 of the DPDP Act lets the government restrict which countries data can be sent to, and some industries have even stricter requirements. As a result, if you're building cloud systems for global businesses, there's a real clash: cloud is designed to move, law wants data to stay put. 

Cloud Architecture: Built for Geographic Fluidity 

Modern cloud architecture is built to be everywhere at once. The European Commission points out that when it comes to the cloud, users don't need to know where their data is at any given moment and that's intentional. Big providers like AWS, Microsoft Azure, and Google Cloud run huge networks of data centres around the world, ensuring data is replicated for safety, delivered quickly via local caches, and that computing power is deployed where it's needed most and at lower cost. 

Resource pooling enables users to share infrastructure and cut costs, while rapid elasticity lets workloads quickly span regions. Services track geographic usage, but workloads cross borders: data might be read from a CDN in Singapore, written to storage in Mumbai, and replicated to Frankfurt. 

This flexibility helps: 62% of UK firms use several cloud providers for reliability, flexibility, and to pick the best tool. Cloud-native setups also keep data close to users, like Europeans using Frankfurt and Indians using Mumbai. 

For security, spreading data is safer. The Diplo Foundation says strong encryption and controls, not physical location, matter most. Cloud security goes with your data. 

This technical advantage directly collides with legal rules that treat data location as the foundation of jurisdiction, turning geographic flexibility a cloud strength into a legal point of contention. 

Unresolved Definitional Questions 

The DPDP Act's cross-border transfer provisions assume a clear distinction between domestic and foreign data processing. However, cloud architecture's technical realities expose definitional ambiguities that regulations have not yet resolved. 

What counts as a "transfer" in ephemeral processing? When serverless functions (AWS Lambda, Azure Functions) route requests through foreign regions for milliseconds without persisting data to disk, does Section 16's "transfer" prohibition apply? If an Indian user's authentication token passes through a Singapore-based API gateway en route to an India-based database, has a cross-border transfer occurred? The Draft DPDP Rules, 2025, do not clarify this. Organisations adopting cautious interpretations route all traffic, including DNS queries, authentication tokens, and CDN requests, through India-domiciled infrastructure, sacrificing latency optimisation. 

If an Indian user's authentication token passes through a Singapore-based API gateway en route to an India-based database, has a cross-border transfer occurred? The DPDP Rules, 2025, do not clarify this. 

Organisations adopting cautious interpretations route all traffic, including DNS queries, authentication tokens, and CDN requests, through India-domiciled infrastructure, sacrificing latency optimisation. 

How would regulators interpret "access" vs "storage"? If personal data remains stored in India whilst foreign personnel access it remotely, such as a US-based data scientist querying an India-hosted database via VPN, has cross-border transfer occurred? 

The Diplo Foundation's hybrid framework treats data processing as value-adding activity, suggesting that where processing occurs matters more than physical storage. 

Until the Data Protection Board clarifies, organisations must anticipate that any foreign interaction with India-resident personal data carries compliance risk. 

The DPDP Act does not distinguish between these technical implementations, creating uncertainty about whether disaster recovery to foreign regions constitutes prohibited transfer or mandated security infrastructure. 

Data Localisation Under the DPDP Act: Legal Constraints on Geographic Mobility 

India's DPDP Act adopts a "blacklist" or "negative list" approach to cross-border data transfers under Section 16. The default position is that personal data may be transferred to any country or territory unless explicitly prohibited by a Central Government notification. This contrasts with the GDPR's "whitelist" model, which restricts transfers except to jurisdictions with adequacy decisions. 

The blacklist isn't published yet, but countries with tensions like China and Pakistan will likely be included. Routing Indian data through such regions can breach the Act, with penalties up to ₹150 crore. 

Sector-specific mandates impose stricter requirements, that are stated as the following  

1. Banking and financial services: All payment data must remain in India, regardless of the DPDP Act's general provisions. 

   
   

2. Insurance: Core policyholder data must be stored in India. 

   
   

3. Telecom: Subscriber databases and Call Detail Records must be hosted domestically. 

For these sectors, data localisation is mandatory, regardless of the DPDP Act's general transfer provisions. 

The DPDP Rules, 2025, further expand localisation. Significant Data Fiduciaries (SDFs) must comply with additional data localisation requirements for specific categories of personal data, as determined by a government-appointed committee. The Rules also permit the government to impose conditions on foreign states' access to transferred data, complicating compliance for multinational operations. 

Critically, the DPDP Act applies beyond India. EU or US companies serving Indian users must follow the Act and may be penalised by the Data Protection Board, even if their servers are in Frankfurt or Virginia. This forces global cloud architectures to fit Indian legal requirements. 

The Structural Conflict: Technical Efficiency vs Legal Sovereignty 

The conflict between cloud architecture and data localisation is structural, not just operational. Cloud computing is driven by efficiency, resilience, and cost; data localisation is grounded in sovereignty, control, and jurisdiction. These priorities are fundamentally at odds. 

1. Technical Inefficiency: Data localisation limits how cloud providers manage resources and ensure resilience. If Indian data must remain within national borders, providers cannot use alternate capacity in Singapore or Frankfurt during high demand, making disaster recovery far more complex. Geo-redundancy, the practice of storing data across distant locations to survive regional failures, often conflicts with strict localisation rules. Backup strategies like cold, warm, and hot backups each balance recovery speed (RTO) and data loss tolerance (RPO), but localisation restricts organisations from placing backups abroad, where such diversity boosts reliability. For sectors needing rapid recovery, like finance or healthcare, compliance can mean slower failover and higher risk. Ultimately, data localisation doesn’t just raise costs—it can weaken system resilience by keeping both primary and backup infrastructure within one vulnerable jurisdiction. 

The Diplo Foundation says, "data cannot just be stored like oil." Cloud computing involves fast processing and delivery in many places, with many complexities. Localisation forces cloud designs to treat data as static, which goes against what makes the cloud useful. 

2. Region pinning enforces geographic boundaries primarily on the data plane. AWS Control Tower, Azure Policy, and GCP Resource Location Restrictions block data plane deployments outside approved regions and alert on cross-region replication. 

However, control plane localisation remains challenging. When an administrator provisions an Indian database via AWS Console, API requests travel to AWS's control plane (often US-domiciled). Request metadata—including resource tags that may contain customer names—transits through foreign infrastructure. 

Does this constitute cross-border transfer under Section 16?, AWS increasingly supports regional control plane isolation for services like S3 and EC2. Azure offers sovereign clouds with fully in-country control planes. However, global services—such as AWS IAM and Route 53—operate control planes in centralised US regions, creating unavoidable cross-border metadata flows. 

3. Compliance Complexity: Multi-cloud (using multiple cloud service providers) and hybrid-cloud (combining cloud and on-premises infrastructure) strategies increase compliance burdens. An organisation using AWS for computing tasks, Azure for data storage, and GCP for data analysis must configure region pinning associating data with specific geographic locations across all three, ensuring that data, backups, logs, and system records remain within approved regions. Mistakes like unintentionally enabling replication across regions or sending API (software interface) traffic via overseas servers can result in compliance violations. 

Vendor due diligence (evaluating and monitoring third-party providers) must be ongoing. Organisations need to track subcontractors, monitor changes to their infrastructure, and obtain contracts that specify the exact locations of their data centres. If a vendor moves data processing or storage to a newly blacklisted country, the organisation risks immediate violation of legal requirements. 

4. Jurisdictional Fragmentation: Data localisation creates legal complexity. The Diplo Foundation warns that full localisation is restrictive, while allowing IT companies to set the rules is risky. Serving users in multiple countries means separate data stores under different laws. 

India’s data localisation mandates, though driven by legitimate national security and economic concerns, risk undermining the Internet’s universality and creating digital borders that resemble physical ones. As data becomes “the world’s most valuable resource,” fragmentation deepens due to ambiguity over what constitutes “access” vs “storage.” If personal data is stored on Indian servers but remotely accessed by foreign personnel or systems, such as a US-based data scientist connecting via VPN, the question arises whether this qualifies as cross-border transfer—under a location-based view it does not, but under a control-based view it does, since foreign entities gain temporary custody of the data. 

Industry Approaches: Hybrid Models, Region Pinning, and Compliance Automation 

Faced with this conflict, enterprises are adopting strategies that balance regulatory compliance with operational efficiency. 

1. Multi-Tier Data Residency Models: Organisations classify data by sensitivity and apply differentiated residency rules. Low-sensitivity data such as anonymised analytics or public content may flow globally, whilst personally identifiable information (PII) and regulated financial data remain within specified jurisdictions. The Diplo Foundation suggests treating data "as a raw material, intermediate good or final product. The data source would be where the most value is added (e.g., processing, analysis, transformation)". 

   
   

   This approach mirrors trade policy frameworks: just as WTO rules distinguish between goods and services with varying transfer modes, cloud architectures can identify different data flows storage, processing, analytics and apply jurisdictional rules accordingly. 

2. Compliance-as-Code: Embedding regulatory requirements into Infrastructure-as-Code (IaC) automates enforcement. Tools such as Terraform, AWS CloudFormation, and Azure Resource Manager define data residency policies as code, preventing human error and ensuring consistency across multi-cloud deployments. Compliance automation platforms continuously scan configurations, flagging violations before they reach production. 

API routing introduces further uncertainty. When Mumbai-based applications route requests through AWS Singapore edge locations before reaching India-based backends, do the request packets, containing personal data in headers or payloads, trigger Section 16 transfer obligations? The answer hinges on whether the Act regulates data location or data access. The Diplo Foundation argues that "data location does not matter for technical security purposes", suggesting encrypted routing through foreign nodes should be permissible. However, absent explicit regulatory guidance, organisations face legal exposure every time they configure cross-region load balancers or global API gateways. 

3. Contractual and Technical Mitigations: Standard Contractual Clauses (SCCs) and Data Processing Agreements (DPAs) specify vendor obligations. Data Processing Agreements (DPAs) specifying that control plane metadata is either not "personal data" under DPDP Act definitions or is subject to separate contractual safeguards. Contracts must detail the exact geographic locations of data centres, prohibit transfers to blacklisted nations, require immediate notification of infrastructure changes, and mandate the return or deletion of data upon termination. Whilst the DPDP Act does not mandate SCCs (unlike the GDPR), implementing robust DPAs is practically mandatory to fulfil Rule 6 security safeguard obligations. 

GoTrust's Role: Automating Data Residency and Cross-Border Compliance 

GoTrust's data governance platform addresses the operational complexity of managing data localisation across distributed cloud architectures. Whilst GoTrust is not a cloud provider, its capabilities enable organisations to map, monitor, and enforce residency requirements in real time. 

1. Automated data discovery identifies where personal data resides across databases, cloud storage, SaaS platforms, and on-premises systems. GoTrust's data discovery tool continuously scans environments, classifying data by sensitivity and tagging geographic locations. The PII map visualises data residency, showing which personal data categories reside in India, the EU, or other jurisdictions. This visibility is foundational: organisations cannot enforce localisation rules if they do not know where data is stored. 

   
   

2. Data flow mapping traces how personal data moves between systems, regions, and vendors. GoTrust tracks cross-border transfers, identifying which datasets are sent to third-party processors, where those processors are located, and whether transfers comply with Section 16 blacklist restrictions. When new data stores are introduced such as spinning up a test environment in a foreign region GoTrust alerts compliance teams to potential violations before production use begins. 

   
   

3. Compliance dashboards aggregate data residency status, access logs, and configuration alerts into unified views. Privacy and security teams monitor whether cloud configurations enforce region pinning, whether backups and disaster recovery destinations comply with localisation mandates, and whether vendor infrastructure changes introduce new cross-border risks. GoTrust's Data Security Posture Management (DSPM) continuously scans cloud, SaaS, and on-premise environments, detecting misconfigurations and unauthorised data movements. 

   
   

4. Vendor risk management extends oversight to third-party processors. GoTrust's platform tracks Data Processing Agreements, monitors vendor compliance questionnaires, and validates that subprocessors adhere to residency commitments. If a vendor proposes routing data through a newly blacklisted country, GoTrust flags the change and triggers remediation workflows. 

   
   

5. Audit-ready evidence supports regulatory reviews. GoTrust maintains immutable logs of data transfers, access patterns, and enforcement of residency policies. When auditors or the Data Protection Board request evidence of Section 16 compliance, organisations can produce timestamped records showing where data was stored, which transfers occurred, and what safeguards were applied. 

By embedding residency monitoring into governance frameworks, GoTrust enables organisations to satisfy DPDP obligations whilst maintaining operational flexibility. Localisation becomes a managed compliance parameter rather than a technical constraint. 

Reconciling Cloud and Sovereignty: A Hybrid Path Forward 

The conflict between data localisation and cloud architecture is not insurmountable, but neither is it resolvable solely through technology. The Diplo Foundation proposes a hybrid system: "data localisation is generally prohibited, except for data directly affecting national security (with the burden of proving necessity on the claiming government), contributing to economic development, or identifying citizens (including biometric data)". 

This mirrors WTO trade policy, which permits the free flow of goods and services with exceptions for security imperatives, public order, and special treatment for developing countries. Applied to data, the framework would allow global cloud architectures by default, with narrow, well-defined exceptions for genuinely sovereignty-sensitive categories. 

Until multilateral harmonisation emerges, organisations must navigate a patchwork of domestic laws. The DPDP Act's blacklist model is more permissive than outright localisation mandates, but sector-specific rules and the pending notification of prohibited countries inject uncertainty. Enterprises must prepare for multiple scenarios: mapping cross-border data flows, configuring multi-region architectures, negotiating vendor contracts with transition clauses, and implementing monitoring tools that detect violations in real time. 

The Diplo Foundation concludes that "governments should look beyond the static physical location of data, and the legal, political and economic comfort that localisation brings. They must see cloud computing as a dynamic activity involving value-adding storage, processing and movement of data by people and computers worldwide". The challenge for Data Fiduciaries is to operationalise this vision within existing legal constraints. 

Conclusion 

Data localisation and cloud architecture are not fundamentally compatible. Cloud computing is designed for geographic abstraction, dynamic resource allocation, and global resilience. Data localisation mandates static residency, jurisdictional control, and restricted mobility. The DPDP Act's Section 16 blacklist approach mitigates some conflicts by permitting transfers to most countries, but sector-specific mandates, pending blacklist notifications, and evolving Draft Rules introduce complexity that multinational organisations cannot ignore. 

The conflict will persist because it reflects competing priorities: national sovereignty and data protection versus operational efficiency and economic integration. Resolution requires multilateral frameworks that harmonise residency rules across jurisdictions a goal that remains distant given current geopolitical realities. 

In the interim, organisations must treat data localisation as a managed compliance parameter. Region pinning, multi-tier residency models, encryption with local key management, contractual safeguards, and continuous monitoring enable compliance without abandoning cloud benefits entirely. GoTrust's compliance automation platform provides the governance infrastructure to operationalise these strategies, transforming residency enforcement from a reactive IT task into a proactive compliance discipline. 

The inevitable conflict between data localisation and cloud architecture demands not resolution, but intelligent management. Organisations that build residency compliance into their architecture, continuously monitor data flows, and maintain visibility across multi-cloud environments will navigate this tension more successfully than those that treat localisation as an afterthought. In a world where data is both a technical artefact and a jurisdictional asset, governance is the bridge between technical capability and legal obligation.