Consent Under DPDP: The Five Conditions That Decide Whether It Counts

Section 6 of India's DPDP Act defines consent as "free, specific, informed, unconditional and unambiguous" and requires it to be given through a "clear affirmative action." Five adjectives and one phrase, and together they decide whether your consent collection is lawful or theatre.

The Rules, notified November 13, 2025, add operational detail on top. This post breaks down each condition in plain language and translates it into product decisions. It is not legal advice; it is an engineering reading of a legal test.

The five conditions, in plain language

| Condition | Meaning | Common failure | |-----------|---------|----------------| | Free | No coercion, no take-it-or-leave-it bundling | Refusing service unless consent is given to unrelated purposes | | Specific | Consent is tied to a particular purpose, not a blanket | One "Accept" for marketing, analytics, and third-party sharing | | Informed | The user knows what they are consenting to | Vague notice: "we may use your data to improve services" | | Unconditional | No strings attached to the consent itself | "Accept to continue using the app" | | Unambiguous | A clear affirmative action, no inference | Pre-ticked boxes, silence, or implied consent |

The sixth requirement, "clear affirmative action," is the operational spine: consent must be an explicit act, not a default. That single phrase kills pre-ticked boxes, opt-out-as-consent designs, and any pattern where a user who does nothing is treated as consenting.

Free: the trickiest condition

"Free" sounds simple until you try to sell a product. The classic failure is bundling: making access to a service conditional on consent to processing that is not necessary for the service. Under DPDP, consent to marketing is not free if the only alternative is not using the product at all.

The practical reading for product teams: separate the consent that is necessary for the service from the consent that is optional. The necessary processing can often rest on legitimate uses. The optional processing, marketing, analytics for ad targeting, third-party sharing, needs its own, genuinely optional consent with a real alternative.

Specific: purpose granularity

Consent must be specific to a purpose. This is the condition that most directly shapes UI: instead of a single Accept button, you need per-purpose choices. Marketing consent, analytics consent, and personalisation consent are separate decisions, and the record has to show each one.

This is also where the DPDP Rules' separate-consent-for-separate-purposes requirement bites. A user who accepted marketing but not analytics must have both choices respected, which means your consent infrastructure has to carry purpose-level state and enforce it downstream.

Informed: notice quality and language

Consent is only informed if the user actually knows what they are agreeing to. The Act requires a notice covering the fiduciary's identity, the purposes of processing, the rights of the data principal, and how to complain. The Rules add the language requirement: notice in English and the relevant Eighth Schedule Indian languages.

For a product team, "informed" is a localisation and transparency problem. A dense legal notice in English on a Hindi-first user base is not informed consent, it is a checkbox. Notice design, language routing, and versioned publication are the work here.

Unconditional and unambiguous: the design test

"Unconditional" means consent is not tied to something else you are selling. "Unambiguous" means the action itself is clear. Together they rule out:

• Pre-ticked boxes
• "Scroll to consent" patterns
• Consent buried in terms and conditions
• Opt-out framed as consent
• Any design where the user's silence is treated as acceptance

The affirmative action requirement means your consent event is a real event: a button press, a toggle, an explicit confirmation. And it needs to be recorded as an event, because you are going to need to prove it later.

Withdrawal: the requirement everyone forgets

The Act and Rules require withdrawal to be as easy as giving consent. This is not a footnote; it is a parity requirement. If consent is two taps, withdrawal that requires an email to support is not parity.

Withdrawal also has to mean something. When a user withdraws consent for marketing, your systems must stop marketing processing. That requires enforcement plumbing: the consent state lives in one place, and downstream systems learn about changes through webhooks or polling, not through hope.

What good looks like in a product

Put the conditions together and a DPDP-era consent flow looks like:

1. A notice in the user's language, stating who, what, why, and rights
2. Per-purpose choices: service-necessary vs optional, each explicit
3. A clear affirmative action recorded as an event
4. A receipt that pins what was shown and chosen, at that moment
5. A withdrawal path with the same reachability as the consent path
6. Enforcement: consent changes propagate to backend systems
7. A record you can export when challenged

That is exactly the shape of Accord, Erasure's consent product: versioned notice, purpose-level configuration, immutable receipts, a hosted preference centre, and HMAC-signed webhooks so backend systems react to consent changes. The consent management guide covers the category, and consent receipts explains why the record matters.

The bottom line

The five conditions are not a drafting exercise; they are a design specification. Free shapes your bundling, specific shapes your purpose architecture, informed shapes your notice and localisation, unconditional and unambiguous shape your UX, and the affirmative action requirement shapes your event recording. Build to the test and the rest of compliance gets dramatically easier.

For the operational checklist this fits into, see the DPDP compliance checklist. The Rules explainer covers the regulatory detail behind Section 6.