DPDP Act 2023: A Cloud Compliance Checklist for Indian Enterprises on Azure, AWS and Google Cloud

The Digital Personal Data Protection Act 2023 (DPDP Act) does not mention Azure, AWS or Google Cloud. It does not say where a server must be, which encryption to use or how long to keep a log. It describes duties: process personal data lawfully, protect it with reasonable safeguards, tell people and the regulator when it leaks, erase it when its purpose is served, and answer to the Data Principal whose data it is. Every one of those duties lands somewhere in your cloud estate as a setting, a policy or a contract. This checklist maps each duty to the control that meets it and to the place in Azure, AWS and Google Cloud where that control is set.

Reviewed October 2026, against the Act and the DPDP Rules, 2025, notified on 13 November 2025. The Act comes into force in phases: the Data Protection Board from 13 November 2025, the Consent Manager provisions from 13 November 2026, and most of the Data Fiduciary duties in this checklist, including security safeguards, breach notification, erasure, Data Principal rights, cross-border transfer and penalties, from 13 May 2027. Until then this checklist is preparation rather than a current legal duty, and the Board's practice is still forming. This article is an engineering checklist, not legal advice: confirm scope, dates and interpretation with counsel before you rely on it.

• ₹250 crore: the maximum penalty for a significant breach of the duty to take reasonable security safeguards, from 13 May 2027
• 72 hours: to give the Data Protection Board the detailed report of a personal data breach, from 13 May 2027
• 1 year: the minimum period the Rules require you to keep logs and processing records, from 13 May 2027

Who is who, and why the cloud does not change it

The Act has three roles. The Data Principal is the person the data is about. The Data Fiduciary decides why and how personal data is processed; that is you, if you run the application or the business. The Data Processor processes data on the Fiduciary's behalf under a contract.

For the personal data you host on it or ask it to work on, a cloud provider normally acts as your Data Processor, and so does a managed service provider that operates your estate. For its own customer-account data, each is a Data Fiduciary in its own right. Neither changes your position: the Act makes the Fiduciary responsible for compliance regardless of any contract with a processor. You can delegate the work of encryption, logging and backup. You cannot delegate the duty.

That is the lens for everything below. Each check asks not "does the platform offer this?" but "have we configured it, can we prove it, and does the contract say who does what?"

What the Act covers, and when each duty starts

The Act applies to digital personal data processed in India, including data collected on paper and digitised later, and to processing outside India connected with offering goods or services to people in India. It does not apply to personal data processed for purely personal or domestic purposes, or to personal data that the person, or someone under a legal duty, has made publicly available.

• 13 November 2025. What takes effect: Definitions, the Data Protection Board and its procedures
• 13 November 2026. What takes effect: Registration and duties of Consent Managers
• 13 May 2027. What takes effect: Data Fiduciary duties (notice, consent, security safeguards, breach notification, erasure, grievance redress), Data Principal rights, Significant Data Fiduciary duties, cross-border transfer and penalties

Most of this checklist therefore prepares for duties that apply from 13 May 2027. Sector rules, such as RBI's payment data localisation, and the CERT-In Directions already apply.

The checklist: duty by duty

1. Keep personal data where you can lawfully keep it

The Act permits transfer of personal data outside India except to countries the Central Government restricts by notification; no country had been notified at the time of writing, and section 16 applies from 13 May 2027. The Rules let the Central Government set requirements for making transferred data available to a foreign State, and require Significant Data Fiduciaries to keep personal data the Government specifies, on a committee's recommendation, in India. Sector rules can be stricter and already apply: RBI requires payment system data to be stored in India, SEBI's cyber framework includes a data-localisation standard that is currently in abeyance, and insurers should check IRDAI's current information and cyber security guidelines. The practical control is the same on every platform: decide which regions are permitted, enforce the list with policy so nobody can deploy elsewhere by accident, and check that replication and backup targets obey it too.

• Azure. Indian regions: Central India (Pune), India South Central (Hyderabad), South India (Chennai), West India (Mumbai); Where to enforce: Azure Policy, "Allowed locations", assigned at management group; check the paired region used by geo-redundant storage
• AWS. Indian regions: ap-south-1 (Mumbai), ap-south-2 (Hyderabad); Where to enforce: Service control policy in Organizations denying actions outside the permitted regions; check S3 replication rules and backup copy destinations
• Google Cloud. Indian regions: asia-south1 (Mumbai), asia-south2 (Delhi); Where to enforce: Organization Policy, "Resource location restriction"; choose India regions or a custom dual-region for storage

2. Reasonable security safeguards

Section 8(5) requires every Data Fiduciary to protect personal data with reasonable security safeguards, and the Rules name the minimum: encryption, obfuscation, masking or tokenisation; control of access to the systems; monitoring and logging that can detect, investigate and remediate a breach; backup and continuity; and contractual terms that bind processors to the same standard. The highest penalty in the Act attaches to this clause.

• Encryption at rest, with keys you control. Azure: Platform encryption on by default; customer-managed keys in Key Vault for storage, disks and databases; AWS: Default encryption on S3, EBS and RDS; customer-managed keys in KMS; Google Cloud: Default encryption everywhere; customer-managed keys in Cloud KMS
• Encryption in transit. Azure: Enforce TLS 1.2+ on storage accounts, App Service and SQL ("secure transfer required"); AWS: Bucket and API policies that deny non-TLS requests; TLS on load balancers; Google Cloud: HTTPS load balancing; organisation policy to require TLS on services that support it
• Identity and least privilege. Azure: Entra ID with MFA for all, Conditional Access, Privileged Identity Management for admin roles, RBAC scoped to resource groups; AWS: IAM Identity Center, MFA enforced, permission sets instead of long-lived keys, no root use; Google Cloud: Cloud Identity with 2-step verification, IAM roles at the narrowest scope, no owner role on projects holding personal data
• Masking and tokenisation. Azure: Dynamic data masking and Always Encrypted in Azure SQL; Microsoft Purview for classification; AWS: Macie to find personal data in S3; column-level encryption in RDS or application-side tokenisation; Google Cloud: Sensitive Data Protection to discover and de-identify; column-level security in BigQuery

3. Detect, investigate and remediate a breach

The Rules expect logging that is good enough to work out what happened, and retained long enough to be useful: one year, the Rules' minimum from 13 May 2027, is the figure to design to. The practical test is simple: for any system holding personal data, can you say who accessed what, from where, and when, for any day in the last twelve months?

• Azure. Audit and activity logs: Activity Log and resource diagnostic settings into Log Analytics; Entra sign-in and audit logs; Threat detection: Microsoft Defender for Cloud; Microsoft Sentinel for correlation and cases; Retention setting: Log Analytics workspace retention set to 365 days or more, or archive tier for the older part
• AWS. Audit and activity logs: CloudTrail organisation trail to S3 and CloudWatch Logs; VPC flow logs; Threat detection: GuardDuty; Security Hub to aggregate; Retention setting: CloudWatch log group retention of 365 days or more; S3 lifecycle on the trail bucket, with object lock if you need immutability
• Google Cloud. Audit and activity logs: Cloud Audit Logs (admin, data access, system) routed to a log bucket; Threat detection: Security Command Center; Retention setting: Log bucket retention of 365 days or more, with a retention lock for the evidence bucket

Data access logs are off by default on more than one platform for cost reasons. For systems with personal data they need to be on, which is a cost line the budget should know about.

4. Tell the Board and the people affected

From 13 May 2027, a personal data breach must be reported to the Data Protection Board and to every affected Data Principal. The Rules set the shape: an initial intimation without delay, a detailed report to the Board within 72 hours, and a plain-language notice to each affected person describing what happened, the likely consequences, what you are doing about it, the safety measures they can take and whom to contact. Indian enterprises also carry the CERT-In Directions, which separately require reporting of specified incidents within six hours.

None of this is a cloud setting. It is a runbook, with named owners, pre-drafted notice templates and a contact list for the Board, CERT-In and your sector regulator, rehearsed at least once. The cloud's part is to make the facts available fast: the logs above, an alert that pages someone, and an incident record. Microsoft, AWS and Google each publish their own commitment to notify customers of incidents on their side of the shared-responsibility line; that notice starts your clock, it does not satisfy it.

The 72-hour report needs the one-year log. A breach discovered on a Tuesday has to be described to the Board by Friday: scope, cause, affected principals, remediation. Without the logs in section 3 the report is guesswork.

5. Erase it when you are done with it

Personal data must be erased when the purpose is served or consent is withdrawn, unless a law requires retention. The Rules also set a floor: every Data Fiduciary must keep personal data, the associated traffic data and processing logs for at least one year from the date of processing before erasing them, so a lifecycle rule must not delete inside that year. Large e-commerce, online-gaming and social-media platforms also have a three-year inactivity period, with a 48-hour warning to the Data Principal before erasure. In cloud terms that means three things: know where every copy is, including backups and logs; have a lifecycle rule that deletes on schedule rather than a ticket that someone may raise; and make sure deletion reaches the backup within its retention window. Our backup and disaster recovery guide covers where those copies sit on each platform.

• Azure. Object and file data: Blob lifecycle management rules by container or tag; Databases: Azure SQL retention jobs or purge procedures; TTL in Cosmos DB; Backups: Azure Backup retention policy aligned to the erasure period, so a deleted record is not restorable years later
• AWS. Object and file data: S3 lifecycle rules with expiration; Databases: DynamoDB TTL; scheduled purge on RDS; Backups: AWS Backup lifecycle and vault retention
• Google Cloud. Object and file data: Cloud Storage Object Lifecycle Management; Databases: Firestore TTL policies; scheduled purge on Cloud SQL; Backups: Backup and DR retention rules

Tag data at creation with its purpose and the retention it carries. A lifecycle rule can act on a tag; nobody can act on a column nobody labelled.

6. Answer the Data Principal

Principals have the right to know what you hold about them, to have it corrected or erased, to nominate someone to act for them, and to be heard through a grievance mechanism. For the cloud estate this is the discovery problem in reverse: can you find every record about one person across every system within the response period you publish, which the Rules cap at 90 days? Classification tools, Microsoft Purview, Amazon Macie and Google's Sensitive Data Protection, exist to make that answer "yes" before anyone asks. The Rules also require you to publish the contact details of the person who answers data-protection questions, which belongs on the website, not in a ticketing queue.

7. Processor contracts that say who does what

A Fiduciary may use a processor only under a valid contract. For the hyperscalers that is the data processing agreement in their standard terms; read it once for the clauses on sub-processors, breach notification timing and data location, and keep it with the compliance evidence. For a managed service provider, the contract should name the personal data they can touch, the controls they operate, the logs they keep, the breach-notification timing they owe you, and what happens to data and access at exit. If your MSP cannot show you the control they run against each line of this checklist, the gap is yours to carry.

8. Significant Data Fiduciaries carry more

The Central Government may notify a Fiduciary as "significant" based on factors including the volume and sensitivity of the data, the risk to Data Principals, and the impact on sovereignty, electoral democracy, security of the State and public order. It is expected to reach large banks, insurers, hospitals, telecoms and consumer platforms first; no Significant Data Fiduciary had been notified at the time of writing. Significant Data Fiduciaries must appoint a Data Protection Officer based in India, commission an independent data audit and carry out a Data Protection Impact Assessment once every twelve months, and may face further restrictions on moving specified data outside India. The cloud evidence for all of this already exists if sections 1 to 5 are done: policy compliance reports, access reviews, log retention and lifecycle configurations are what the auditor will ask for.

Where the sectors sit on top of this

The Act is the floor. Three sectors have a ceiling above it.

• Banking and financial services: RBI's Managing Risks in Outsourcing Directions (2025) and its Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions (2026), payment data localisation, and the expectation of audit trails for privileged access. Landing zones for banks are built with region restriction and immutable logging from day one.
• Healthcare: health data is among the most sensitive personal data any Fiduciary holds (the Act does not define special categories, but the harm from a breach is greater), breach consequences are personal, and the erasure duty collides with clinical record-retention law. Retention rules need the clinician's input, not just the engineer's.
• Insurance: IRDAI's information and cyber security guidelines, policyholder data across underwriting, claims and distribution partners, and processor contracts with a long chain of intermediaries.

A 30-day plan

1. Week 1: inventory. List every system that holds personal data, the region it runs in, the backups it has and the processor contract that covers it. The platform tagging and classification tools above can do most of the finding.
2. Week 2: region and identity. Enforce the permitted-region policy at the top of the hierarchy; turn on MFA for everyone and privileged access management for administrators; remove standing admin rights.
3. Week 3: logs and encryption. Route audit and data-access logs for personal-data systems to a retained store of one year or more; confirm encryption at rest and in transit on every store, with customer-managed keys where the risk warrants.
4. Week 4: lifecycle and runbook. Write lifecycle rules for the retention each dataset carries, aligned with backup retention; draft and rehearse the breach runbook with the 72-hour Board report and the CERT-In timeline side by side, using the CERT-In six-hour checklist for the second.
5. Day 30: evidence. Export the policy compliance report, the access review, the log retention settings and the lifecycle rules into one folder. That folder is the audit, the DPIA input and the answer to the board's question.

Where CloudSwift fits

Our compliance services run this checklist as a managed control set rather than a one-time project: the region policy, identity baseline, logging and retention are built into the landing zone, monitored by managed security, and reported on so the evidence folder above refreshes itself. For enterprises that already know they are in scope as a Significant Data Fiduciary, our regulatory compliance services cover the audit preparation and the DPIA.

If you would like the inventory in week 1 done with you rather than by you, book a consultation. The first conversation is the list of systems and where they run.

Frequently asked questions

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

Not in general. From 13 May 2027 the Act allows transfer outside India except to countries the Central Government restricts by notification, and only Significant Data Fiduciaries can be required to keep specified personal data in India. Sector rules can be stricter: RBI requires payment system data to be stored in India. The safe engineering default for most Indian enterprises is to keep personal data in Indian regions and enforce it with policy.

Is a cloud provider a Data Fiduciary or a Data Processor?

Normally a processor for the personal data you host, acting under your contract; for its own customer-account data it is a Fiduciary. You remain the Fiduciary for your data and responsible for compliance. The same applies to a managed service provider operating your estate.

How quickly must a breach be reported?

From 13 May 2027: to the affected Data Principals and the Data Protection Board without delay, with a detailed report to the Board within 72 hours of becoming aware, or a longer period the Board allows on request. The CERT-In Directions separately require specified incidents to be reported to CERT-In within six hours. Both clocks run at once.

What are the penalties under the DPDP Act?

The Act's schedule sets maximum penalties, the highest being ₹250 crore for failing to take reasonable security safeguards and ₹200 crore for failing to notify a breach. The Board imposes them after an inquiry, for breaches it finds significant, taking into account factors such as the nature, gravity and duration of the breach. They apply from 13 May 2027.

Does being ISO 27001 certified make us DPDP compliant?

No. ISO 27001 is strong evidence for the security safeguards duty and will help with an audit, but the Act also requires lawful purpose and consent, breach notification, erasure, Data Principal rights and processor contracts, none of which a security certificate covers.