Consent Management Under DPDP
Collection & Storage Requirements

Table of Contents

1. Section 5 — Notice Before Consent
2. Section 6 — Five Elements of Valid Consent
3. Granular Consent Architecture
4. Consent Withdrawal — Equal Ease Requirement
5. Section 9 — Children and Parental Consent
6. Consent Manager Framework
7. FAQs — DPDP Consent

The Section 5 notice is not a privacy policy buried in a website footer. It is a mandatory disclosure that must be presented to the Data Principal before or at the time of collecting consent. The notice must be in clear, plain language — legalese-heavy privacy policies do not satisfy this requirement.

The notice must contain three categories of information: first, a description of every personal data item being collected and the purpose for which each item will be processed; second, the manner in which the Data Principal can exercise their rights under Chapter III (right to access, correction, erasure, and grievance redressal); and third, the manner in which the Data Principal can file a complaint with the Data Protection Board.

For companies that currently rely on general privacy policies, the transition to Section 5 notices requires a fundamental redesign. The notice must be purpose-specific and data-item-specific. A fintech collecting name, email, phone, PAN, and bank statement data for loan underwriting must explain, in the notice, what each data item is used for — not merely state that data is collected for “providing services.” The notice must be presented in a format the Data Principal can act upon — before clicking the consent button.

Granular consent means each processing purpose is presented as an independent consent request. The Data Principal must be able to accept some purposes and reject others without losing access to the core service. For most Indian companies, this requires rebuilding consent interfaces from scratch — the common pattern of a single “I agree to the Terms and Privacy Policy” checkbox is insufficient.

The technical architecture must support: purpose-level consent storage (each purpose has a consent record with timestamp, notice version, and consent status), purpose-level withdrawal (withdrawing consent for marketing does not affect consent for service delivery), consent versioning (if the notice changes, consent must be re-obtained for the changed purpose), and consent audit trail (the system must produce a complete history of consent given, modified, and withdrawn for each Data Principal).

For banks, this means the existing consent recorded at the time of account opening — typically a bundled signature on a form covering all data processing — will need to be replaced or supplemented with purpose-specific digital consent. For e-commerce platforms, the checkout flow must separate consent for order processing from consent for personalised recommendations, marketing emails, and data sharing with payment partners.

The “equal ease” requirement in Section 6(4) is a design mandate. If consent was obtained through a single button click, withdrawal must be possible through a single button click — not through a multi-step process involving email requests, customer service calls, or account settings buried three levels deep. Companies that make consent withdrawal difficult face penalty exposure under Section 33.

Upon withdrawal, the Data Fiduciary must cease processing the affected data within a reasonable time period (to be specified in the rules). Data must be deleted unless retention is required under another law — for example, banks must retain transaction records under the Banking Regulation Act and PMLA regardless of DPDP consent withdrawal. The Data Fiduciary must communicate the consequences of withdrawal to the Data Principal — such as loss of personalised recommendations or marketing communications — but cannot use these consequences as a deterrent against withdrawal.

Section 9 creates a three-part obligation for children’s data. First, verifiable parental consent — not mere self-declaration of age, but verification that an adult guardian has consented. The verification mechanism is to be prescribed in rules, but is expected to include government ID verification (Aadhaar-based) or similar age-gating technology.

Second, a blanket prohibition on tracking and behavioural monitoring of children. This impacts education technology platforms, gaming apps, social media platforms, and any service that profiles minors for engagement optimisation. Third, a prohibition on targeted advertising directed at children — which means platforms that serve age-targeted ads must reliably identify and exclude minors from advertising targeting.

The Central Government may exempt certain categories of Data Fiduciaries from the verifiable parental consent requirement for specific, verifiably safe purposes. EdTech platforms that process only academic data may receive exemptions. However, no exemptions have been notified as of April 2025 — meaning all children’s data processing currently requires full parental consent.

Section 6(8) introduces an entirely new category of entity — the Consent Manager. Registered with the Data Protection Board, a Consent Manager acts as a single interface through which Data Principals can give, manage, review, and withdraw consent across multiple Data Fiduciaries. Instead of navigating each company’s individual consent settings, the Data Principal manages all consent through one platform.

The Consent Manager framework draws from the Account Aggregator (AA) ecosystem developed under RBI oversight. In the AA model, a licensed intermediary enables data sharing between financial institutions based on user consent — managing the consent lifecycle centrally. The DPDP Consent Manager extends this concept beyond financial data to all personal data processing.

For Data Fiduciaries, integrating with Consent Managers will require API development. The Consent Manager will need to query the Data Fiduciary’s systems for current consent status, relay new consent or withdrawal requests, and maintain synchronised consent records. Companies that invest in consent management infrastructure now — purpose-level consent records, API-accessible consent status, event-driven consent updates — will be better positioned to integrate with Consent Managers when the framework becomes operational.