India's DPDP Act 2023: a practical compliance guide for cloud teams

The Digital Personal Data Protection Act, 2023 applies to the processing of digital personal data inside India, including data collected on paper and digitised later, and to processing outside India when it is connected with offering goods or services to people in India (section 3). There is no headcount, revenue or "main establishment" threshold. If you offer goods or services to individuals in India, the Act reaches you.

Three groups feel it first:

• Indian product companies and their SaaS vendors. You are a Data Fiduciary for your users and employees, and a Data Processor for your customers' data. Fiduciaries stay liable for whatever their processors do (section 8(1)), so expect customer DPAs to be rewritten around the Act. See DP-001.
• Foreign SaaS selling into India. Extra-territorial reach is explicit. A US or EU company with Indian customers is a Data Fiduciary under this Act, not just under its home law.
• Indian outsourcing and processing shops. Section 17(1)(d) exempts processing of data of people outside India done under a contract with a person outside India from most of the Act, though the section 8(5) security-safeguard duty still applies. Your own Indian employee and customer data is still in scope.

Ignoring it has three costs. The Schedule to the Act sets monetary penalties of up to ₹250 crore. Section 37 lets the Central Government, on a reference from the Board, order your service blocked in India after penalties in two or more instances. And section 13(3) lets any grievance you fail to resolve go to a digital-first Board, so complaints scale with your user base, not your legal team.

As of October 2026 none of the Data Fiduciary duties are yet enforceable; they commence on 13 May 2027. That is the date to plan around.

The Act is short: 44 sections in nine chapters plus one Schedule of penalties. Chapter II (sections 4 to 10) holds every obligation on a Data Fiduciary. Chapter III (11 to 15) holds Data Principal rights and duties. Chapter IV (16 and 17) covers cross-border transfer and exemptions. Chapters V to VIII create the Data Protection Board, the appeal route to TDSAT and the penalty regime.

The vocabulary differs from GDPR. A Data Fiduciary decides purpose and means (a controller). A Data Processor acts on its behalf. A Data Principal is the individual, and for a child includes the parent. A Consent Manager is a Board-registered Indian company that lets people give, review and withdraw consent across fiduciaries. A Significant Data Fiduciary (SDF) is one the Central Government notifies on volume, sensitivity and risk grounds (section 10) and carries extra duties.

There are only two lawful bases. Either the Data Principal consented (section 6: free, specific, informed, unconditional, unambiguous, with a clear affirmative action) or one of the "certain legitimate uses" in section 7 applies: data the person volunteered for a purpose, State benefits and functions, legal disclosure obligations, court orders, medical emergencies, epidemics, disasters, and employment. There is no "legitimate interests" or "contractual necessity" basis. The lawful processing matrix is the control that makes this decision per purpose.

The DPDP Rules, 2025 (23 rules, seven schedules) supply the detail: rule 3 notice content, rule 4 Consent Manager registration, rule 6 minimum security safeguards, rule 7 breach intimation, rule 8 retention and erasure, rules 10 to 12 children and guardians, rule 13 SDF duties, rule 14 rights and the 90-day grievance ceiling, rule 15 transfers, rule 22 appeals.

What is in force today

Both the Act and the Rules commence in three tranches, set by G.S.R. 843(E) and rule 1. (Both notifications are dated 13 November 2025; the Gazette copies were uploaded and the PIB press release issued on 14 November. Plan to the earlier date.)

• Since 13 November 2025: definitions, establishment and staffing of the Board (sections 18 to 26), consistency with other laws, rule-making powers, and rules 17 to 21 on Board appointments and procedure.
• From 13 November 2026: section 6(9) and rule 4, Consent Manager registration, plus the Board's matching power over Consent Manager breaches (section 27(1)(d)).
• From 13 May 2027: everything else: sections 3 to 17 (all fiduciary duties and rights), the Board's inquiry and penalty powers, appeals, and the repeal of section 43A of the IT Act.

Everything in Chapter II is mandatory once live. Rule 13 applies only if you are notified as an SDF. Rule 8's Third Schedule erasure clocks apply only to e-commerce and social media platforms with at least two crore registered Indian users and gaming intermediaries with at least fifty lakh.

Start from data, not systems. Build a digital personal data inventory that lists each category of personal data, the people it describes (customers, end users of customers, employees, candidates, leads), where it lives, which processors touch it and whether the Data Principal is in India. Then assign a role per flow with SC-003: fiduciary, processor, or both.

Out of scope by statute: personal or domestic processing, data made public by the person or under a legal duty (section 3(c)), and data of non-Indian principals processed under contract for a foreign client (section 17(1)(d)). Employee data is in scope but usually rests on the employment use in section 7(i), which changes the paperwork (notice, not consent); see LB-005.

Decide early whether you could be notified as an SDF, using SC-004. It changes the budget: a DPO based in India, an independent data auditor, annual DPIA and audit reports to the Board, and localisation of any data the Government later specifies.

The scoping mistakes that cost the most:

• Scoping only the Indian entity. If a parent abroad decides purposes, the parent is the fiduciary. Entity boundaries do not limit the Act.
• Treating B2B contact data as exempt. A buyer's name, work email and usage telemetry are personal data. Marketing and CRM systems are in.
• Forgetting processors you do not pay for. Analytics SDKs, support desks, email providers and AI assistants all need a contract under section 8(2) and a line in the processor register.
• Assuming you have no children's data. Anyone under 18 is a child. If sign-up does not establish age, you cannot show you have none.
• Relying on the start-up exemption. Section 17(3) only allows the Government to notify exempt classes. No such notification existed when this was written.

The plan below assumes a 10 to 500 person SaaS company on one or more public clouds, with some privacy groundwork (a privacy policy, a DPA template, basic access control). Work backwards from 13 May 2027 and leave the last eight weeks for the re-notification campaign.

Phase 0: weeks 0 to 3. Know what you hold

• Complete the data inventory and ROPA (SC-001, SC-003). Tag each flow with its lawful basis from the matrix.
• Run the SDF self-assessment and record the conclusion, even if it is "unlikely".
• List every processor, its region and its contract status. Flag any with no written contract.
• Name an accountable owner and publish interim contact details for data questions (section 8(9), rule 9). See GV-001.

Phase 1: weeks 3 to 10. Build the four engines

• Notice and consent. Design the standalone notice (rule 3), the consent record schema, and withdrawal that is as easy as giving consent (section 6(4)). Offer the notice in English and the Eighth Schedule languages your users read (section 5(3)); see TR-002.
• Rights handling. One intake path, identity check, and a 90-day clock: rule 14(3) caps grievance response at 90 days, and the Rules set no separate deadline for access, correction, erasure or nomination, so apply the same clock to them. Start with DS-001 and DS-007.
• Security safeguards. Map rule 6's seven minimums (encryption or masking, access control, access logging, backups, one-year log retention, processor clauses, organisational measures) to cloud settings. The hardest-controls section below is the checklist.
• Breach response. Write the runbook with the three clocks: CERT-In 6 hours, Board and Data Principals without delay, detailed Board report within 72 hours (rule 7). Pre-draft both templates.

Phase 2: weeks 10 to 18. Prove it works

• Table-top the breach runbook with engineering, support and leadership. Time it.
• Send test DSARs and erasure requests through the real path, including the processor cascade (section 8(7)(b)).
• Sign or amend processor contracts and the cross-border register (IT-001).
• Implement age assurance and the child-account feature flags if any users could be under 18.
• Plan the section 5(2) campaign: every user who consented before commencement must receive the new notice "as soon as it is reasonably practicable". Schedule it for the weeks either side of 13 May 2027.

Phase 3: ongoing from May 2027

• Monthly: grievance and request ageing against the 90-day ceiling; consent withdrawal reconciliation across processors.
• Quarterly: access reviews, log retention checks, processor register refresh.
• Annually: policy review, training (SE-005), and for SDFs the DPIA and independent audit with a report to the Board (rule 13).
• Watch MeitY and the Board's site for SDF notifications, section 16 country restrictions and rule 15 orders.

1. Provable notice and consent (sections 5, 6; rule 3)

Section 6(10) puts the burden of proof on you: in any proceeding you must show the notice was given and consent obtained. That means an append-only consent record keyed to user, purpose, notice version and language, with withdrawal events in the same store. AWS: DynamoDB with point-in-time recovery for the live record, mirrored to S3 with Object Lock in compliance mode for the immutable trail. Azure: Cosmos DB with continuous backup, mirrored to Blob Storage with a time-based immutability policy. GCP: Firestore or Spanner, mirrored to a Cloud Storage bucket with a locked retention policy. Done looks like: any user ID returns the exact notice text they saw, when, in which language, and every later withdrawal. Controls: LB-001, TR-001, DS-005.

2. Breach detection and two-track notification (section 8(6); rule 7)

Rule 7 is not a 72-hour rule. Affected Data Principals and the Board must be told without delay; the 72 hours (extendable on written request) is for the detailed Board report. Separately, the CERT-In directions of 28 April 2022 require reporting listed incidents, including data breaches and leaks, within 6 hours of noticing them. Detection has to be automated. AWS: GuardDuty, Security Hub and CloudTrail data events on personal-data buckets and tables, routed through EventBridge to the incident queue. Azure: Microsoft Defender for Cloud with Sentinel analytics rules on the personal-data workspaces. GCP: Security Command Center Premium with Event Threat Detection. Done looks like: a drill from alert to CERT-In email, Board intimation and user notice completed inside the clocks, with timestamps in the ticket. Controls: IR-001, IR-002.

3. Visibility of access to personal data, kept for one year (rule 6(1)(c) and (e))

Rule 6 requires logs, monitoring and review that let you detect and investigate unauthorised access, and retention of those logs and the personal data for one year. CERT-In separately requires 180 days of ICT logs held within India. AWS: enable CloudTrail data events for S3 and DynamoDB (off by default), set CloudWatch Logs retention to at least 365 days, write the trail to an Object-Locked bucket in ap-south-1 or ap-south-2. Azure: diagnostic settings on every data store to a Log Analytics workspace in Central India with retention of at least 365 days. GCP: turn on Data Access audit logs (disabled by default except BigQuery), route to a log bucket in asia-south1 with a 365-day locked retention. Control: SE-003.

4. Erasure with processor cascade, against a one-year floor (section 8(7); rule 8)

On withdrawal or when the purpose ends you must erase and cause processors to erase, unless law requires retention. Rule 8(3) then requires personal data, traffic data and processing logs to be kept for at least one year from processing for the Seventh Schedule purposes. The resolution is a retention schedule per data class: delete from live systems on request, keep the minimal processing record for a year, then purge. AWS: DynamoDB TTL, S3 lifecycle expiration, AWS Backup vault retention aligned to the schedule. Azure: Blob lifecycle management, Azure Backup retention, Purview to find stragglers. GCP: Cloud Storage lifecycle rules, BigQuery partition expiration, Sensitive Data Protection discovery scans. Done looks like: an erasure job that emits a certificate and collects processor confirmations within the SLA. Controls: DS-004, SC-005.

5. Encryption, masking and tokenisation (rule 6(1)(a))

Rule 6 names encryption, obfuscation, masking or virtual tokens as the minimum. AWS: KMS customer-managed keys, SSE-KMS as the bucket default, RDS and EBS encryption checked by AWS Config rules, tokenise identifiers at write time. Azure: Key Vault customer-managed keys, Always Encrypted or Dynamic Data Masking on Azure SQL. GCP: CMEK on Cloud Storage, BigQuery and Cloud SQL, policy tags with dynamic data masking in BigQuery. Control: SE-001.

6. Children's data and verifiable parental consent (section 9; rules 10 to 12)

Under-18s are children. You need verifiable parental consent before processing, and no tracking, behavioural monitoring or targeted advertising directed at children. Rule 10 accepts identity and age details you already hold, details the parent volunteers, or a virtual token from an authorised entity such as a Digital Locker provider. Engineering work: an age step at sign-up, a parent verification flow, and feature flags that disable analytics and ad SDKs for child accounts. Done looks like: a child account cannot emit a behavioural event. Controls: SC-008, SC-002.

7. Cross-border transfers and region strategy (section 16; rules 13(4) and 15)

The Act takes a blacklist approach: transfers are allowed except to countries the Central Government notifies, and rule 15 adds conditions the Government may set by order on making data available to a foreign State. No country had been restricted when this was written. SDFs may be told to keep specified data and its traffic data in India. Keep a transfer register and the ability to pin workloads to India regions: AWS ap-south-1 (Mumbai) and ap-south-2 (Hyderabad); Azure Central India, South India and West India; GCP asia-south1 (Mumbai) and asia-south2 (Delhi). Enforce with an SCP on aws:RequestedRegion, Azure Policy "Allowed locations", and the GCP org policy constraints/gcp.resourceLocations. Controls: IT-001, IT-002.

There is no auditor's checklist for ordinary fiduciaries, so the evidence is what the Board would ask for in an inquiry (section 28 gives it civil-court powers to call for documents) and what an SDF's independent auditor needs. Keep it in four groups.

• Policies and notices: the standalone notice in each language with version history; consent and withdrawal policy; retention schedule; breach response plan; children's data policy; processor and transfer policies; grievance SOP. Each with an owner and a review date.
• Records: the data inventory and ROPA; the legal-obligation register; processor register with signed contracts; consent and withdrawal log; request and grievance register with received and closed dates; breach register with copies of Board and user intimations; nomination records; DPIA reports (PD-001).
• Technical exports: key management and default-encryption settings; audit-log configuration and retention values; lifecycle and TTL rules; region-restriction policies; backup vault settings (SE-004); quarterly access-review output (SE-002).
• Tickets: every DSAR, erasure job, processor confirmation, breach drill and real incident, with timestamps.

Retention: the Act sets no limitation period, and section 6(10) means consent evidence must outlive the processing it justifies. A defensible floor is: consent and notice records for the life of the relationship and at least one year after the last processing, including the erasure itself (rule 8(3)); access logs for at least one year (rule 6), which already exceeds CERT-In's 180 days; breach and grievance files for the same period as your contractual limitation clauses. Consent Managers must keep their records for seven years (First Schedule), a useful benchmark if you integrate with one.

There is no DPDP certificate to earn. Three processes matter.

Board inquiry

A proceeding starts with a breach intimation under section 8(6), a Data Principal complaint (after exhausting your grievance process, section 13(3)), a Government reference, or a court direction. The Board first decides whether there are sufficient grounds (section 28(3)). If so it inquires with civil-court powers, must give you a hearing, and under rule 19(9) must finish within six months, extendable three months at a time. Outcomes: closure, directions, a voluntary undertaking (section 32, which bars further proceedings on the same matter if honoured), or a penalty under section 33 sized on gravity, duration, data type, repetition, gain, and mitigation. Appeals go to TDSAT within 60 days (section 29), filed digitally with a fee as under the TRAI Act (rule 22); TDSAT aims to decide within six months.

SDF annual cycle

Once notified, an SDF must every 12 months complete a DPIA and an audit and have the assessor send a report of significant observations to the Board (rule 13). Expect a 6 to 10 week engagement: scoping, evidence pull, interviews, testing of consent and rights flows, and a report. Cost drivers are the number of processing purposes, processors and jurisdictions, and whether algorithmic systems need the rule 13(3) due-diligence review.

Readiness review

For everyone else, assessment is self-driven or customer-driven. Indian enterprise customers increasingly ask for a gap assessment against the Act and Rules in procurement. A useful internal cadence is a full readiness review before May 2027, then an annual review aligned with your ISO 27001 or SOC 2 cycle, reusing their evidence. The complaint pathway control describes the grievance-to-Board route in detail.

• Copying the GDPR basis table. "Legitimate interests" and "contractual necessity" do not exist here. Fix: re-run every purpose through the matrix; most B2C purposes land on consent or section 7(a) voluntary provision.
• Burying the notice in the privacy policy. Rule 3(a) requires a notice understandable on its own. Fix: a short, itemised notice at the point of collection with a link to the full policy, per language.
• Forgetting existing users. Section 5(2) requires a fresh notice to everyone who consented before commencement. Fix: a scheduled campaign with delivery logs, not a banner.
• Withdrawal harder than consent. Section 6(4) makes the ease comparable. Fix: a one-click withdrawal in the same surface as the consent toggle, and a job that propagates it to processors.
• Planning the breach process around 72 hours. The first intimations are "without delay", and CERT-In wants 6 hours. Fix: pre-approved templates and an on-call rota with authority to send.
• Deleting logs at 180 days. CERT-In's 180 days is a floor, not the DPDP target; rule 6 wants one year. Fix: set retention to 365 days on the audit trail and document why.
• No age signal at sign-up. Without it you cannot show you have no children's data. Fix: a date-of-birth or age-band step, and child-account flags that disable tracking SDKs.
• Reading "no localisation" as "no constraint". Section 16(2) keeps sector rules alive, CERT-In logs must stay in India, and SDFs can be ordered to localise. Fix: maintain the region map and the ability to move a workload to an India region on notice.
• Treating the DPO as optional for everyone. Only SDFs must appoint one, but every fiduciary must publish a contact who can answer processing questions (section 8(9), rule 9) and respond within 90 days. Fix: name the person now.

iCompaas maps the Act and the 2025 Rules to the 36 controls in the library below, grouped the way the work is actually done: scope and classification, lawful basis, transparency, Data Principal rights, data processing, privacy by design and DPIA, security, incident response, international transfer and governance. Each control article states what the law requires, what to implement and what evidence to keep.

On the platform, continuous checks run across connected AWS, Azure, GCP and other cloud accounts for the technical safeguards in rule 6: encryption defaults, audit-log coverage and retention, backup configuration, access-control posture and region placement. Policy templates mapped to the DPDP controls come with named owners and review cadences, including notice templates per language, consent and withdrawal handling, retention schedules and a breach notification playbook laid out for the Board's reporting content. A grievance redressal workflow tracks each request against its SLA. Evidence is collected from the connected accounts and policy workflows and can be exported when a customer, an SDF auditor or the Board asks for it.