India’s Digital Personal Data Protection Act, 2023 (DPDP Act) puts consent at the center of lawful data processing. With the DPDP Rules, 2025 notified in November 2025 and a phased compliance timeline running through May 2027, organizations that handle personal data of Indian residents need to move from “collecting a checkbox tick” to running a full, auditable consent lifecycle. This guide walks through what the law requires, and how to actually build a system that records and maintains consent in a way that holds up if the Data Protection Board comes asking.

Where the DPDP Act Stands Today

Before getting into the mechanics, it helps to know the timeline, since obligations are being phased in:

• August 2023: The DPDP Act was enacted.
• November 13, 2025: The DPDP Rules, 2025 were notified, and the Data Protection Board of India was established, along with administrative provisions.
• November 13, 2026: Registration opens for Consent Managers — the licensed intermediaries who let individuals manage consent across multiple organizations from one dashboard.
• May 13, 2027: All remaining provisions — including the core consent, notice, and security requirements — become fully effective.

This phased rollout gives organizations a runway, but it’s a short one relative to how much operational change is involved. Building consent infrastructure now, rather than in 2027, is the safer bet.

What Counts as Valid Consent (Section 6)

Section 6 of the Act lays out six cumulative conditions that consent must meet. It must be:

1. Free — given without coercion or manipulation.
2. Specific — tied to a particular, clearly stated purpose.
3. Informed — given after the individual has seen a clear notice.
4. Unconditional — not bundled with unrelated services (“consent or lose access”).
5. Unambiguous — no pre-ticked boxes, no implied consent from silence or continued use.
6. Given through clear affirmative action — an active step, not a default state.

Any part of a consent request that violates the Act is void to that extent, even if the rest of the request is compliant. This is designed to kill dark patterns — pre-checked boxes, confusing toggle language, “accept all” buttons paired with a buried “reject” link, and bundled consent for unrelated processing purposes.

Notice Must Come Before or With Consent (Section 5 and Rule 3)

Consent cannot be collected in a vacuum. Section 5, read with Rule 3 of the DPDP Rules, requires every consent request to be accompanied or preceded by a notice that itemizes:

• The specific personal data being collected, described item by item rather than in vague categories.
• The specific purpose(s) for which it will be processed.
• How to withdraw consent, and how to exercise other rights (access, correction, erasure).
• How to file a complaint with the Data Protection Board.
• Contact details for the Data Fiduciary’s Data Protection Officer or authorized representative.

The notice must be available in English or any of the 22 languages listed in the Eighth Schedule of the Constitution — so a single English-only banner won’t satisfy the requirement for a diverse user base. Organizations also need to issue retrospective notices for personal data they were already processing before the Act and Rules took effect.

Recording Consent: What “Proof” Actually Looks Like

Section 6(10) puts the burden of proof on the Data Fiduciary. If a dispute arises, you — not the individual — must show that valid notice was given and valid consent was obtained. In practice, a consent record that will survive scrutiny needs to capture:

• Who consented (a stable identifier for the data principal).
• What they consented to (the exact purpose and data items, not just “terms and conditions”).
• When consent was given, with a timestamp.
• How it was given (the specific UI flow, button, or form).
• Which version of the notice was shown at that moment — notices change over time, and a consent record is meaningless if you can’t tie it to the specific language the person actually saw.
• Proof of the affirmative action — a log entry, not just a database flag that flips to “true.”

A useful way to think about this: don’t store a single “consented: yes/no” field. Store consent as an event log — every grant, every update, every withdrawal, each linked to a notice version and a purpose. That log is your evidence trail.

Consent Is a Loop, Not a One-Time Event

The biggest mental shift the DPDP Act demands is treating consent as ongoing rather than a one-time gate at signup. A practical lifecycle looks like this:

1. Notice is shown — with itemized data and purpose.
2. The individual makes a choice — accept, partially accept, or reject.
3. The choice is recorded — against the specific notice version and purpose, with a timestamp and proof of affirmative action.
4. Processing proceeds strictly within that boundary — only for the stated purpose, only using the consented data.
5. The purpose or notice changes, or the individual withdraws — the record updates, and processing must follow the new state immediately.
6. Everything is logged — so the full history can be reconstructed on demand.

If any one of these stages is missing evidence, the chain breaks, and you may end up processing data without a demonstrable lawful basis — which is treated as a violation even if the original consent was valid.

Withdrawal Must Be as Easy as Giving Consent (Section 6(4))

This is one of the Act’s most operationally demanding requirements. Section 6(4) states that a data principal can withdraw consent at any time, and the withdrawal process must be comparable in ease to the process of giving it. If someone can opt in with a single tap, they must be able to opt out with a similarly simple action — not a support ticket, not a multi-step form, not an email to a compliance inbox that nobody monitors.

Practical implications:

• Build a visible, self-service withdrawal or “revoke consent” control wherever consent was originally captured.
• Withdrawal should propagate automatically to every downstream system — CRM tools, marketing platforms, third-party processors — not just the primary database.
• Processing must stop within a reasonable time of withdrawal, and any data processors you’ve shared data with must also be instructed to stop.

Two important carve-outs soften this obligation:

• Section 6(5): Withdrawal doesn’t undo the legality of processing that already happened before the withdrawal — you’re not required to retroactively treat past processing as unlawful.
• Section 6(6) and Section 8(7): If you’re legally required to retain the data for another purpose (say, KYC records under RBI rules, or tax records), you can continue to retain and process it for that specific legal purpose even after consent is withdrawn — but only for that purpose, not for the original one consent covered.

If withdrawing consent for a specific type of data means you genuinely can’t continue providing a service (for example, withdrawing KYC consent on an active bank account), the Act allows you to discontinue that service, but you should inform the individual of that consequence before the withdrawal takes effect.

Special Rules for Children and Persons with Disabilities

The Act requires verifiable parental or lawful guardian consent before processing the personal data of a child (defined as under 18) or a person with a disability who has a lawful guardian. It also:

• Prohibits any processing likely to cause harm to a child.
• Bans behavioral monitoring and targeted advertising directed at children.

The DPDP Rules add the operational detail: how verification of the parent or guardian’s identity and relationship must actually be carried out, and the limited situations (like certain educational or healthcare contexts) where some of these obligations are relaxed.

If your product could plausibly have underage users, you need age-gating logic and a verifiable parental-consent flow built in well before the 2027 deadline — this is one of the more technically demanding parts of compliance.

Consent Managers: A New Layer in the Ecosystem

The Act introduces a novel intermediary — the Consent Manager — a registered platform through which individuals can give, review, manage, and withdraw consent across multiple organizations from a single interface, similar in spirit to the RBI’s Account Aggregator framework for financial data.

Key points for organizations to know:

• Consent Managers must register with the Data Protection Board and meet conditions under the First Schedule of the DPDP Rules, including a minimum net worth requirement.
• Registration for Consent Managers opens in November 2026.
• If a data principal chooses to route consent through a Consent Manager, your systems need to be able to recognize and honor consent signals coming from that channel, not just your own native consent UI.

Even if you’re not building a Consent Manager yourself, your consent architecture should be designed with interoperability in mind, since individuals may increasingly manage their permissions through third-party platforms rather than your app directly.

A Practical Checklist for Building Compliant Consent Infrastructure

• Redesign notices first. Make them itemized, purpose-specific, multilingual, and short enough that people actually read them.
• Version every notice. Each time wording or purpose changes, create a new version and tie future consent records to it.
• Log consent as an event, not a flag. Capture the who, what, when, how, and which notice version, for every grant, change, and withdrawal.
• Build a real withdrawal mechanism. Self-service, one step or close to it, and wired to propagate to every system and processor that touched the data.
• Automate purpose enforcement. If consent was given for one purpose, the system should technically prevent use of that data for another.
• Map your data processors. You need to know every third party the data flows to, so a withdrawal or erasure request can actually be executed everywhere.
• Build age-verification and parental consent flows if there’s any chance of underage users.
• Keep an audit trail that’s exportable on demand — if the Data Protection Board asks, you should be able to produce the full consent history for any individual within hours, not weeks.
• Reassess data already being processed. Issue retrospective notices for data collected before your compliant flow went live.
• Track the phased deadlines — November 2026 for Consent Manager registration, May 2027 for full effect — and treat them as hard internal milestones, not soft targets.

The Bottom Line

The DPDP Act doesn’t just ask for a consent banner — it asks organizations to be able to prove, item by item, what an individual agreed to, when, under what notice, and to unwind that agreement just as easily as it was given. The organizations that will find this manageable in 2027 are the ones treating consent now as a data architecture problem — an auditable event log connected to real enforcement in their systems — rather than a legal disclaimer bolted onto a signup form.

This article is for general informational purposes and does not constitute legal advice. Organizations should confirm their specific obligations under the DPDP Act and DPDP Rules, 2025 with qualified legal counsel, since interpretation and enforcement guidance continue to evolve.