DPDP Act30 May 2026 9 min read

DPDP Act Cloud Storage: AWS, Azure, GCP Compliance

How the DPDP Act 2023 applies to cloud storage on AWS, Azure, and GCP — data residency, cross-border transfer rules, DPA requirements, and configuration best practices.

Key Takeaways

Cloud providers (AWS, Azure, GCP) are Data Processors under the DPDP Act — a DPDP-compliant DPA must be executed with each cloud provider used.
The DPDP Act will specify cross-border transfer rules through a Central Government whitelist of permitted countries — cloud regions outside India may require this clearance.
Data residency controls (restricting data to Indian cloud regions like Mumbai, Pune) reduce cross-border transfer risk but do not eliminate all DPDP obligations.
Encryption, access logging, and identity management configurations on cloud platforms contribute directly to Section 8(5) reasonable safeguards compliance.
Indian cloud regions are available on all three major providers — AWS ap-south-1 (Mumbai), Azure India Central, and GCP asia-south1 (Mumbai).

In this guide

Cloud Infrastructure and the DPDP Act
DPAs With Cloud Providers
Cross-Border Transfer Rules and Cloud Regions
Implementing Data Residency Controls
Cloud Security Controls for DPDP Compliance
The Shared Responsibility Model and DPDP
Compliance in Multi-Cloud Environments

Cloud Infrastructure and the DPDP Act

The majority of Indian SaaS companies host their infrastructure on one or more of the major hyperscale cloud platforms: Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). Personal data stored and processed on these platforms is subject to the DPDP Act — the fact that data sits in a cloud environment does not exempt it from the Act's requirements.

Cloud providers are Data Processors under the DPDP Act. They process personal data on your behalf (hosting, compute, storage, managed databases) under your instructions. The relationship between a SaaS company and its cloud provider is a Data Fiduciary-Data Processor relationship, requiring a compliant DPA as specified in Section 8(2). The cloud provider does not determine the purpose of your data processing — you do.

Cloud compliance is not just a contractual matter — it has significant technical dimensions. Where you store data (which cloud region), how you configure access controls, what encryption settings you use, and how you log and monitor access all have DPDP Act relevance. Understanding the intersection of cloud architecture and DPDP compliance is essential for every SaaS engineering and infrastructure team.

DPAs With Cloud Providers

All three major cloud providers have DPDP Act-aligned Data Processing Addenda (DPAs) available. AWS offers a Data Processing Addendum that can be accepted online through the AWS console or by contacting your account manager. Microsoft Azure's Data Processing Agreement is part of the Microsoft Online Services Data Protection Addendum. GCP offers a Data Processing and Security Terms agreement.

Review each provider's DPA against the DPDP Act requirements: processing scope (does it cover the services you use?), security obligations (does it commit to maintaining appropriate technical and organisational security measures?), sub-processor transparency (does it list sub-processors and provide notification of changes?), deletion on termination (does it commit to deleting your data within a specified period after contract termination?), and breach notification (does it commit to notifying you of security incidents affecting your data within a defined timeframe?).

For enterprise cloud customers, negotiate custom DPA terms if the standard addendum is insufficient for your risk profile. Large enterprise deals on AWS, Azure, and GCP are often supported by custom data protection terms — particularly around breach notification timelines, audit rights, and specific security requirements. Use your DPDP Act obligations as leverage to negotiate stronger protections.

Cross-Border Transfer Rules and Cloud Regions

Section 16 of the DPDP Act gives the Central Government the power to restrict cross-border transfers of personal data by prohibiting transfer to specific countries or territories. Rather than a blanket prohibition with an adequacy or safeguards exception mechanism (as in GDPR), the DPDP Act takes an allowlist approach: transfers are permissible to countries on the Government-notified whitelist. The whitelist has not yet been published as of early 2026.

In the current pre-Rules environment, cross-border data transfers are not yet subject to formal restriction. However, companies should build their cloud architecture with DPDP cross-border transfer compliance in mind. If you currently store personal data only in Indian cloud regions (AWS ap-south-1 Mumbai, Azure India Central or India South, GCP asia-south1 Mumbai), you have no cross-border transfer issue. If data is stored in US, EU, or APAC regions, you will need to assess compliance when the whitelist is published.

Some cloud services — particularly global services like CloudFront CDN, Azure Active Directory, and GCP's global database features — may process or replicate data across multiple regions, including outside India, as part of their service architecture. Review the data residency documentation for each cloud service you use and understand whether any data leaves Indian regions. Services that process data globally may require additional contractual safeguards once the whitelist regime is in force.

Implementing Data Residency Controls

Data residency means restricting the storage and processing of personal data to specific geographic regions — in this case, Indian cloud regions. Implementing data residency controls is the most direct way to manage DPDP Act cross-border transfer risk: if personal data never leaves India, there is no cross-border transfer to assess.

To implement data residency on AWS: create your resources in the ap-south-1 (Mumbai) region; use Service Control Policies (SCPs) in AWS Organizations to deny creation of resources in non-Indian regions; ensure RDS, S3, and other storage services are explicitly deployed in Mumbai; be aware that some global services (IAM, CloudFront, Route 53) are inherently global and may process data outside India — review AWS documentation for each service.

On Azure, use Azure Policy to enforce data residency: create a policy that restricts resource creation to India Central or India South locations. For GCP, use Organization Policy constraints to restrict allowed resource locations to asia-south1 (Mumbai) or asia-south2 (Delhi). Test your residency policies by attempting to create resources in non-permitted regions — residency controls should be enforced, not just documented.

Cloud Security Controls for DPDP Compliance

Section 8(5)'s reasonable security safeguards requirement is supported by a set of cloud-native controls that every Indian SaaS company should implement. For AWS: enable CloudTrail in all regions with log file validation and S3 object lock (to prevent tampering); configure GuardDuty for threat detection; use AWS KMS for encryption key management; enforce MFA on all IAM users; implement least-privilege IAM policies; enable VPC Flow Logs for network monitoring.

For Azure: enable Azure Monitor and Microsoft Defender for Cloud; use Azure Key Vault for encryption key management; enforce MFA via Azure Active Directory Conditional Access; implement Azure Policy for compliance; enable diagnostic settings for all resources; configure Just-in-Time VM access to reduce attack surface. For GCP: enable Cloud Audit Logs; use Cloud KMS for encryption keys; enforce organisation-wide MFA; configure VPC Service Controls; implement least-privilege IAM bindings.

Encryption is a fundamental DPDP security safeguard. All three cloud providers offer default encryption at rest using provider-managed keys. For higher-risk data (financial, health, children's data), use customer-managed keys (CMK) via KMS/Key Vault/Cloud KMS — this gives you control over key lifecycle and enables cryptographic erasure (deleting the CMK effectively destroys the encrypted data). Document your encryption configuration as evidence of reasonable safeguards.

The Shared Responsibility Model and DPDP

Cloud providers operate on a shared responsibility model: the provider is responsible for security "of" the cloud (physical infrastructure, hypervisor, network), while the customer is responsible for security "in" the cloud (operating system configuration, application security, data encryption, access management). This model is directly relevant to the DPDP Act's Section 8(5) obligation: the provider fulfils their security responsibilities through the infrastructure; you fulfil yours through correct configuration.

Misconfigurations are the leading cause of cloud data breaches globally — publicly exposed S3 buckets, misconfigured database security groups, and overly permissive IAM policies have exposed billions of records. In the DPDP Act context, a breach caused by your misconfiguration of a cloud service is not a vendor security failure — it is your failure to implement reasonable safeguards. The Board will hold you responsible for the configuration decisions you made.

Use cloud security posture management (CSPM) tools — AWS Security Hub, Azure Security Center, GCP Security Command Centre — to continuously scan your cloud environment for misconfigurations. These tools check your configuration against security benchmarks (CIS Benchmarks, AWS Well-Architected Framework) and highlight deviations. Regularly remediate findings and maintain the scan reports as compliance evidence.

Compliance in Multi-Cloud Environments

Many Indian SaaS companies use multiple cloud providers — AWS for primary infrastructure, GCP for ML workloads, Azure for Microsoft integration, and various SaaS services that run on their own cloud infrastructure. Multi-cloud environments amplify compliance complexity: each provider needs a DPA, each environment needs data residency controls, and data flows between environments need to be mapped and governed.

Create a cloud provider inventory that lists every cloud service in use, the personal data categories stored or processed in each, the DPA status, the regional configuration (Indian vs. international regions), and the relevant security controls. This inventory is part of your data purpose register and serves as input to your annual DPDP compliance review.

Consider adopting a cloud-agnostic security controls framework — Terraform or Pulumi for infrastructure as code, a common logging and monitoring stack, and a consistent encryption key management approach — that can be applied uniformly across providers. Centralising your security controls management reduces the risk of inconsistent configuration and simplifies compliance evidence collection.

Frequently Asked Questions

Does storing data in AWS Mumbai (ap-south-1) guarantee DPDP cross-border transfer compliance?

Storing primary data in ap-south-1 significantly reduces cross-border transfer risk. However, some AWS global services may process metadata or control-plane data outside India. Review the AWS documentation for each service you use, particularly global services like IAM, CloudFront, and Route 53. For the majority of application data (databases, S3 objects, EBS volumes) in ap-south-1, you are within India.

Do we need separate DPAs with each cloud region, or one per provider?

One DPA per cloud provider covers all regions within that provider's global infrastructure. AWS's DPA covers all AWS services worldwide, including ap-south-1. You do not need separate DPAs for each region. However, if you use multiple cloud providers (AWS and GCP), you need a DPA with each provider separately.

Our disaster recovery environment is in Singapore. Does this create a DPDP cross-border transfer issue?

Yes, potentially. If personal data is replicated to a Singapore DR environment, this is a cross-border transfer. Until the Government publishes the whitelist of permitted countries, the transfer rules are not yet fully enforceable. When the whitelist is published, assess whether Singapore is included. In the meantime, consider whether your DR requirements can be met using a second Indian region (AWS has Mumbai and Hyderabad, Azure has India Central, India South, and India West).

Is a cloud provider's SOC 2 or ISO 27001 report sufficient evidence of their security for DPDP purposes?

Yes, a current SOC 2 Type II or ISO 27001 certificate from your cloud provider is strong evidence that they have implemented appropriate security controls as your Data Processor. Review the report's scope to confirm it covers the services and regions you use. AWS, Azure, and GCP all publish extensive compliance documentation and maintain multiple security certifications for their Indian region infrastructure.

Can we use CloudFront (AWS's global CDN) to serve Indian users if it routes traffic through non-Indian edge nodes?

CloudFront's edge network is global by nature. If your application serves personalised or authenticated content through CloudFront that includes personal data, edge processing may occur outside India. For static or non-personal content, CloudFront's global routing is generally fine. For personalised content, consider using CloudFront Origin Shield in the Mumbai region and restricting edge caching of personal data to minimise cross-border processing.