India DPDPA Compliance Guide: Requirements, Rights, Consent, and Governance

Understanding the DPDPA: Scope, Timeline, and Who It Applies To

India's Digital Personal Data Protection Act (DPDPA) received Presidential assent on 11 August 2023, and the implementation rules that operationalise the Act were notified in November 2025. Together, the Act and the DPDP Rules form India's first comprehensive data protection regime — and with India being one of the world's largest digital economies, the compliance impact is global.

The DPDPA applies to the processing of digital personal data within India, whether the data was collected digitally or collected offline and later digitised. Critically, it also applies extraterritorially: any organisation outside India that processes personal data in connection with offering goods or services to individuals in India falls within scope. A US SaaS company with Indian users, a European retailer shipping to Indian customers, or a Singapore fintech serving Indian merchants all need a DPDPA compliance programme.

Two notable exclusions shape the Act's boundaries. Personal data processed by an individual for personal or domestic purposes is out of scope, as is personal data that has been made publicly available by the data principal themselves or under a legal obligation. The second exclusion is broader than anything in the GDPR and has significant implications for data scraping, enrichment, and AI training pipelines — though organisations should be cautious about relying on it without legal analysis of how the data became public.

Unlike the GDPR, the DPDPA does not create special categories of sensitive data with heightened processing conditions. All digital personal data is subject to the same baseline obligations, with additional protections applying to children's data and enhanced duties applying to organisations designated as Significant Data Fiduciaries.

Key Roles: Data Principals, Fiduciaries, and Processors

The DPDPA uses its own vocabulary, and mapping it to familiar GDPR concepts is the first step for teams building on an existing privacy programme.

The Data Principal is the individual to whom the personal data relates — the GDPR's data subject. For children, the Data Principal definition includes their parents or lawful guardians, and for persons with disabilities, their lawful guardians. This matters operationally: consent and rights requests for these groups flow through the guardian.

The Data Fiduciary is the entity that alone or with others determines the purpose and means of processing — functionally equivalent to the GDPR controller. The choice of the word 'fiduciary' is deliberate: the Act frames the relationship as one of trust, with the Fiduciary owing duties to the individual whose data it holds. The Data Fiduciary bears primary compliance responsibility, including for processing carried out on its behalf.

The Data Processor processes personal data on behalf of a Data Fiduciary, comparable to a GDPR processor. Notably, the DPDPA places almost all statutory obligations on the Fiduciary, not the Processor. Fiduciaries must therefore flow obligations down through contracts — there is no statutory safety net that binds processors directly the way GDPR Article 28 does.

Finally, the Central Government may designate any Data Fiduciary or class of Fiduciaries as a Significant Data Fiduciary (SDF) based on factors such as the volume and sensitivity of data processed, risk to data principals, potential impact on India's sovereignty and integrity, and risk to electoral democracy. SDFs carry enhanced governance obligations that we cover later in this guide.

Consent Under the DPDPA: Free, Specific, Informed, and Unconditional

Consent is the primary lawful basis for processing under the DPDPA, and its standard is demanding. Consent must be free, specific, informed, unconditional, and unambiguous, given through a clear affirmative action, and limited to personal data that is necessary for the specified purpose. Pre-ticked boxes, bundled consent, and consent walls that condition service access on unnecessary data collection all fail this standard.

The purpose limitation built into the consent requirement is strict. If a data principal consents to processing for account creation, that consent does not extend to marketing, analytics enrichment, or model training. Each distinct purpose needs its own clear disclosure, and the safest operational pattern is granular, per-purpose consent records that can be produced on demand.

Withdrawal must be as easy as giving consent. Once a data principal withdraws, the Fiduciary must stop processing within a reasonable time and instruct its processors to do the same, unless another legal ground applies. This is where many organisations discover their real gap: collecting consent is easy, but propagating a withdrawal across a CRM, data warehouse, marketing automation platform, and a dozen sub-processors requires consent state to be synchronised across systems — not stored in a standalone banner tool.

Alongside consent, the Act recognises 'legitimate uses' — a closed list of grounds that permit processing without consent. These include situations where the individual voluntarily provided data for a specified purpose, state functions and services, compliance with law or court orders, medical emergencies, disaster response, and employment-related purposes. The employment ground is narrower than teams often assume: it covers safeguarding the employer from loss and provision of service or benefit to employees, not any HR processing an employer finds convenient. Importantly, there is no equivalent of the GDPR's open-ended 'legitimate interests' balancing test — if your processing does not fit consent or an enumerated legitimate use, it is not lawful.

Privacy Notices: What You Must Disclose, and in Which Languages

Every request for consent must be accompanied or preceded by a notice, and the DPDP Rules specify its content in detail. The notice must describe the personal data being collected, the purpose of processing, the goods or services enabled by that processing, how the data principal can exercise their rights, how they can withdraw consent, and how to raise a grievance with the Fiduciary — and complain to the Data Protection Board of India.

Two requirements deserve special attention from global teams. First, the notice must be understandable independently: it must stand alone in clear, plain language, itemising the data and purposes rather than pointing to a lengthy general privacy policy. A single global privacy policy hyperlink is unlikely to satisfy this.

Second, the language requirement: the data principal must have the option to access the notice in English or any of the twenty-two languages listed in the Eighth Schedule of the Indian Constitution — including Hindi, Bengali, Tamil, Telugu, Marathi, Gujarati, Kannada, Malayalam, Punjabi, and Urdu. For consent banners and notice flows, this means building multilingual notice delivery as a first-class capability, not an afterthought. Machine-translated boilerplate that garbles legal meaning creates its own risk; invest in reviewed translations for your actual notice text.

Organisations that collected personal data before the Act came into force are not off the hook: they must provide notice to existing data principals as soon as reasonably practicable, informing them of the data held and their rights. Plan a notification campaign for your existing Indian user base as part of your remediation roadmap.

Consent Managers: India's Distinctive Innovation

One of the DPDPA's most distinctive features — with no direct GDPR equivalent — is the Consent Manager. A Consent Manager is an independent entity, registered with the Data Protection Board, that enables data principals to give, manage, review, and withdraw consent through an accessible, transparent, and interoperable platform.

The model draws on India's experience with the Account Aggregator framework in financial services, where licensed intermediaries let individuals control how their financial data flows between institutions. Under the DPDPA, Consent Managers act on behalf of the data principal and are accountable to them, creating a consent infrastructure layer that sits between individuals and the many Fiduciaries processing their data.

The DPDP Rules set the operating conditions: Consent Managers must be Indian-incorporated companies meeting minimum net-worth requirements, must avoid conflicts of interest with the Fiduciaries they interact with, and must not themselves be able to read the personal data flowing through their platforms in identifiable form.

For Data Fiduciaries, the practical implication is architectural: your consent infrastructure needs to be able to receive and honour consent signals — including withdrawals — that arrive through a third-party Consent Manager, not just through your own banner or preference centre. Consent state must be treated as a synchronised, auditable record that can interoperate with external platforms. Organisations whose consent lives inside a single website widget will need to re-architect. This is exactly the pattern TruePrivacy's consent management is built around: a central consent ledger that syncs preferences across your systems and can integrate with external consent channels as the ecosystem matures.

Data Principal Rights: Access, Correction, Erasure, Grievance, and Nomination

The DPDPA grants data principals five core rights, and each one needs an operational workflow behind it.

The right to access information entitles the individual to a summary of the personal data being processed, the processing activities, the identities of all other Data Fiduciaries and Processors with whom the data has been shared, and a description of what was shared. Producing the sharing inventory is the hard part — it requires an accurate, current data map of every downstream system and vendor that touches Indian personal data.

The right to correction and erasure lets data principals demand correction of inaccurate data, completion of incomplete data, updating, and erasure of data no longer necessary for the purpose it was collected for, unless retention is required by law. Erasure must propagate to processors — a deletion that clears your production database but survives in your data warehouse, backups beyond policy, and sub-processor systems is not compliance.

The right of grievance redressal requires every Fiduciary to provide a readily available means for data principals to raise grievances, and to respond within the timelines set in the Rules. Data principals must exhaust this channel before escalating to the Data Protection Board — which makes your grievance workflow both a compliance obligation and your first line of defence against regulatory complaints.

The right to nominate is unique among major privacy laws: a data principal may nominate another individual to exercise their rights in the event of death or incapacity. Your DSR intake needs to handle nominee-submitted requests, including verifying the nominee's authority.

Data principals also carry duties — including not impersonating others, not suppressing material information, and not filing false or frivolous complaints — with modest penalties for violations. This duty-bearing design is another departure from the GDPR's one-directional model.

Significant Data Fiduciaries: DPOs, Audits, and Impact Assessments

Organisations designated as Significant Data Fiduciaries face a materially heavier governance load, and any organisation processing Indian personal data at scale should plan for the possibility of designation.

An SDF must appoint a Data Protection Officer who is based in India, represents the Fiduciary under the Act, serves as the point of contact for grievance redressal, and is responsible to the board of directors or equivalent governing body. For multinationals, the India-residency requirement means the global DPO cannot simply absorb the role — you need an accountable individual in India.

SDFs must also appoint an independent data auditor to evaluate compliance, and conduct periodic Data Protection Impact Assessments and audits, with significant observations reported to the Data Protection Board. Under the DPDP Rules, these are annual exercises — which means DPIA capability cannot be an occasional, consultant-driven event. It needs to be a repeatable internal process with templates, ownership, and evidence trails.

The Rules additionally empower the government to require SDFs to ensure that certain categories of personal data, to be specified by notification, are not transferred outside India — a targeted localisation lever aimed at the largest processors. SDFs must also verify that the algorithmic software they deploy does not pose a risk to the rights of data principals, an obligation whose contours will be shaped by future guidance but which clearly signals scrutiny of automated systems.

Even if you are not designated an SDF today, the designation criteria — volume and sensitivity of data, risk to data principals — mean that successful, fast-growing consumer platforms are natural candidates. Building DPO, audit, and DPIA muscle before designation is far cheaper than retrofitting it under regulatory attention.

Children's Data: Verifiable Consent and the Tracking Ban

The DPDPA defines a child as anyone under eighteen — one of the highest age thresholds in any major privacy law — and imposes strict conditions on processing children's data.

Before processing a child's personal data, a Data Fiduciary must obtain verifiable consent from the parent or lawful guardian. The DPDP Rules describe acceptable verification approaches, including reliance on identity and age details already available to the Fiduciary, voluntarily provided identity documents, or virtual tokens issued by authorised entities such as Digital Locker service providers. 'Verifiable' is the operative word: a self-declared checkbox asserting parental status will not withstand scrutiny.

Beyond consent, the Act prohibits processing that is likely to cause detrimental effects on a child's well-being, and bans tracking, behavioural monitoring, and targeted advertising directed at children outright. For consumer platforms with mixed-age audiences, this effectively requires age assurance at onboarding and segmented processing logic downstream — advertising identifiers, analytics profiling, and recommendation personalisation must all be capable of switching off for under-eighteen users.

The Rules provide limited exemptions for certain classes of Fiduciaries — such as healthcare providers, educational institutions, and childcare providers — and for narrow purposes, but these are purpose-bound and do not license general profiling. If your product serves or is likely to attract users under eighteen in India, children's data handling should be one of the first workstreams in your compliance programme, not the last.

Cross-Border Transfers: The Blacklist Model

The DPDPA takes a fundamentally different approach to international data transfers than the GDPR. Rather than requiring adequacy decisions or contractual safeguards before data can leave the country, the Act permits transfers to any jurisdiction by default, except to countries the Central Government specifically restricts by notification — a blacklist model, in contrast to the GDPR's whitelist-plus-safeguards architecture.

This makes day-one compliance simpler: there are no transfer impact assessments, no standard contractual clauses, and no derogations to manage. But it concentrates regulatory risk in a different place — a single government notification can render an established data flow unlawful, and organisations must be able to respond quickly.

Two caveats complicate the picture. First, the DPDP Rules require that where a foreign state or its agencies seek access to personal data processed by a Fiduciary, transfers meet conditions the government may specify — a provision aimed at foreign governmental access that DPAs and legal teams should watch as guidance develops. Second, sectoral laws with stricter localisation requirements — such as the RBI's payment data localisation mandate — continue to apply on top of the DPDPA. The Act sets a floor, not a ceiling.

The practical programme is straightforward: maintain a live inventory of every cross-border flow of Indian personal data, including sub-processor and support access; build contractual provisions into vendor agreements that address future restrictions; and ensure your architecture supports data residency options so that a localisation notification is a configuration change rather than a re-platforming project. For a deeper treatment, see our dedicated guide to cross-border transfers under the DPDP Act.

Security, Breach Notification, and Penalties Up to ₹250 Crore

Every Data Fiduciary must implement reasonable security safeguards to prevent personal data breaches, and the DPDP Rules give that phrase teeth by specifying minimum measures: encryption, obfuscation, masking or virtual tokens, access controls, logging and monitoring to detect and investigate unauthorised access, and retention of logs and personal data breach-related records for at least one year. The Fiduciary remains responsible for safeguards even when processing happens at a processor.

The breach notification obligation is one of the most demanding in the world because it has no risk threshold. Where the GDPR only requires notifying individuals when a breach poses a high risk to their rights, the DPDPA requires notifying every affected data principal and the Data Protection Board for every personal data breach. The Rules structure this as a two-stage process: prompt initial notification to affected individuals in clear and plain language — describing the breach, its likely consequences, mitigation measures, and safety steps the individual can take — and a detailed report to the Board, with initial intimation without delay and fuller particulars within seventy-two hours of becoming aware, extendable on request.

Penalties are severe and itemised in the Act's Schedule. Failure to implement reasonable security safeguards carries the maximum: up to ₹250 crore — roughly USD 30 million — per instance. Failure to notify a breach can draw up to ₹200 crore, violations of children's data obligations up to ₹200 crore, and SDF obligation failures up to ₹150 crore. Unlike the GDPR, penalties are fixed maximums rather than revenue percentages, and the Act provides no private right of action or statutory compensation for individuals — enforcement runs through the Data Protection Board, which functions primarily as an adjudicatory body with the power to investigate complaints and impose monetary penalties.

The compliance takeaway: breach readiness is not a policy document. You need detection and logging that actually surfaces incidents, a rehearsed response playbook with pre-approved notification templates in the required languages, and a system of record that can identify affected Indian data principals quickly enough to hit the timelines.

DPDPA vs GDPR: Where the Two Regimes Diverge

Teams with a mature GDPR programme have a head start, but treating the DPDPA as 'GDPR for India' will create gaps. The divergences matter operationally.

Lawful bases: GDPR offers six, including the flexible legitimate interests ground. The DPDPA offers consent plus a closed list of legitimate uses — no balancing test, no contractual-necessity ground for most commercial processing. Processing you justify under legitimate interests in Europe likely needs consent in India.

Consent infrastructure: the DPDPA's Consent Manager framework has no GDPR equivalent and anticipates interoperable, third-party consent platforms. Your consent architecture needs to be integration-ready.

Transfers: GDPR is whitelist-plus-safeguards; DPDPA is blacklist-by-notification. Simpler today, but volatile — and organisations subject to both must apply the stricter standard to each flow.

Breach notification: GDPR notifies the regulator within 72 hours and individuals only on high risk; DPDPA notifies all affected individuals and the Board for every breach, with detailed Board reporting within 72 hours.

Rights: DPDPA omits data portability and has no direct objection right to automated decision-making, but adds the nomination right and imposes duties on data principals. DSR workflows built for GDPR need reconfiguration, not just relabelling.

Enforcement: GDPR fines scale to 4% of global turnover and coexist with private claims; DPDPA penalties are capped in absolute terms (up to ₹250 crore) with no individual compensation route. The structural lesson is that DPDPA compliance is a distinct workstream that reuses GDPR assets — data maps, DSR tooling, DPIA templates — but applies different rules to each of them.

AI and the DPDPA: What the Act Does and Does Not Regulate

The DPDPA is frequently misread on AI. It does not prohibit automated decision-making, does not establish an AI-specific governance regime, and contains nothing comparable to GDPR Article 22 or the EU AI Act's risk classification system. The Act regulates the processing of personal data — and AI systems are simply one more context in which that processing happens.

That framing still generates real obligations for AI pipelines. Training or fine-tuning models on personal data of Indian data principals requires a lawful basis, and with no legitimate-interests ground available, that usually means specific, informed consent for the training purpose — bundling 'model improvement' into general terms will not meet the consent standard. The publicly-available-data exclusion offers a potential pathway for some datasets, but only where the data principal themselves made the data public, a condition much of the scraped web does not satisfy.

Accuracy, security, and erasure obligations follow the data into the pipeline: feature stores, training corpora, and evaluation sets containing personal data are all in scope, and a consent withdrawal or erasure request raises hard engineering questions about retraining and data lineage that are far cheaper to answer at design time.

Two forward-looking signals deserve attention. Significant Data Fiduciaries must verify that algorithmic software they deploy does not pose risks to data principals' rights — the Act's clearest hook for future AI scrutiny. And India's broader AI governance conversation is active, so the sensible posture is to run privacy and AI governance as connected programmes: a unified inventory of AI systems, the personal data they touch, their lawful bases, and their assessed risks positions you for both the DPDPA today and whatever India's AI framework becomes.

Your DPDPA Compliance Roadmap: Five Priorities

The DPDPA rewards organisations that treat compliance as an operational capability rather than a legal memo. Five workstreams cover most of the distance.

First, establish data visibility. You cannot honour access requests, propagate erasures, or notify breach victims without knowing what personal data of Indian data principals you hold, where it lives, and where it flows. Automated data discovery and a continuously maintained data map are the foundation everything else builds on — point-in-time spreadsheet inventories go stale before the ink dries.

Second, rebuild consent for the DPDPA standard. Audit every processing purpose against consent or an enumerated legitimate use, implement granular per-purpose consent with itemised, multilingual notices, and make withdrawal propagate across every downstream system and processor. Design for Consent Manager interoperability now.

Third, operationalise data principal rights. Stand up intake, identity verification (including nominees), fulfilment, and grievance redressal workflows with tracked timelines. Grievance redressal is your buffer before Board complaints — treat its SLAs as seriously as DSR deadlines.

Fourth, prepare for breaches and transfers. Implement the Rules' minimum security safeguards, retain the required logs, rehearse the dual-notification playbook with pre-drafted templates, and keep a live cross-border flow inventory you can re-assess the day a restriction notification lands.

Fifth, build governance that scales. Assign accountable ownership, prepare for possible SDF designation with India-based DPO plans, annual DPIA and audit capability, and board-level reporting — and monitor rulemaking, because the DPDPA regime is still being built out through notifications and Board practice.

TruePrivacy was built for exactly this: automated data discovery and mapping, DPDPA-grade consent management with multilingual notices, end-to-end DSR and grievance automation, breach response workflows, and assessment tooling — in one platform, so your DPDPA programme runs alongside GDPR and CCPA rather than as a parallel universe. Book a demo to see a DPDPA readiness walkthrough tailored to your stack.