What Is Consent?
LawUnder DPDP, consent is the primary lawful ground for processing personal data — the default assumption is that you need it, unless the processing falls within one of the closed list of "certain legitimate uses" the Act carves out separately (Section 7), which covers scenarios like a Data Principal voluntarily providing their data for a specified purpose, or processing required for compliance with a court order. Outside those specific carve-outs, if you're processing personal data, you need consent, and it needs to meet the Act's standard for what "consent" means — not just a checkbox somewhere on the page.
What Makes Consent Valid
LawSection 6 sets out the standard directly: consent must be free, specific, informed, unconditional, and unambiguous, given through clear affirmative action, and limited to the personal data necessary for the stated purpose. A few practical consequences follow from that wording:
- "Free" rules out making an unrelated service conditional on consent to something else entirely (bundling access to a free ebook with consent to marketing calls, for instance).
- "Specific" means one consent per purpose, not one consent covering "marketing, analytics, and anything else we might think of later."
- "Affirmative action" rules out pre-ticked checkboxes and any consent that's assumed by default — the Data Principal has to actively do something to indicate agreement.
A signup form with a single, pre-ticked "I agree to receive updates and share my data with partners" checkbox fails on at least three counts: it's pre-ticked (no affirmative action), it bundles two different purposes (updates vs. third-party sharing) into one consent, and it isn't itemised. Two separate, unticked checkboxes — one for product updates, one for third-party sharing, each with its own short explanation — is the version that holds up.
Notice
LawSection 5 requires that a request for consent be accompanied by, or given alongside, a notice describing the personal data being collected and the purpose of processing, in clear and plain language — in English or any language listed in the Eighth Schedule to the Constitution. The notice and the consent request are meant to travel together; a vague privacy policy linked from the footer, disconnected from the actual point of data collection, doesn't substitute for this.
| Concept | Where it lives in this guide |
|---|---|
| Designing the actual collection flow (UX, checkbox patterns, pairing notice with consent) | Consent Collection → |
| Making withdrawal work in practice | Consent Withdrawal → |
Consent Records
PracticeA consent record is the stored evidence of what was agreed to, by whom, when, and for what purpose — the thing you'd actually produce if a Data Principal or the Data Protection Board asked "what did this person consent to, and when." At minimum, a usable record needs: the specific purpose consented to, a timestamp, the notice text shown at the time (notices change over time, so linking a static snapshot matters), and the current status (granted, withdrawn, or expired). Storing this only as a database flag ("marketing_consent: true") with no history is a common gap — it tells you the current state but not what was actually shown or agreed to at the time.
Consent Withdrawal
LawSection 6 requires that withdrawing consent be as easy as it was to give. This is covered in full in its own chapter, since it's substantial enough to warrant one: Consent Withdrawal →
Consent Preferences
TechnologyA preference centre is where a Data Principal manages standing choices across multiple purposes at once — rather than making them re-consent or re-withdraw one purpose at a time by contacting support. It's not a distinct legal requirement so much as the practical interface layer that makes "specific consent" and "easy withdrawal" workable at scale once you have more than one or two consent purposes running.
Consent Lifecycle
PracticePutting the pieces above in sequence: Notice shown → Consent captured (specific, itemised, affirmative) → Record stored (purpose, timestamp, notice version) → Consent acted on (only the consented processing actually happens) → Preferences managed (Data Principal can review/change standing choices) → Withdrawal, if it happens (as easy as consent was to give) → Record updated, not deleted (the history of what was agreed to and when it changed is itself part of your audit trail).
Website Consent, Marketing Consent, and Third-Party Consent
PracticeThree contexts where the same standard gets applied slightly differently in practice:
- Website consent — cookies, analytics, and tracking scripts need their own purpose-specific consent, separate from any account-creation or checkout consent, and should be blocked until consent is given, not fired first and reconciled later.
- Marketing consent — should never be bundled with consent for a transactional or service purpose (an order confirmation email list is a different purpose from a promotional newsletter, even if both go out over email).
- Third-party consent — if data is shared with a partner or vendor for a purpose the Data Principal wasn't specifically told about, that's a new purpose requiring its own notice and consent, not something covered by the original collection consent.
Treating "we have a privacy policy that mentions third-party sharing" as equivalent to consent for that sharing. A mention buried in a general policy document doesn't meet the "specific" and "informed" bar Section 6 sets for an actual consent request.
Consent Management Technology
TechnologyEverything above is achievable manually at very small scale, but becomes hard to sustain once you have more than a handful of purposes, multiple touchpoints (website, app, in-store, call centre), and a growing volume of rights requests referencing historical consent. A consent management platform operationalises the lifecycle above: capturing purpose-specific consent, storing it as a queryable, exportable ledger, and giving Data Principals a working preference centre and withdrawal path — without making the underlying legal judgment calls for you (what counts as a "purpose," whether a given processing activity needs consent at all) which stay with your own team and counsel.
Digital Anumati's own Consent Management Platform is built around exactly this lifecycle, for readers who want to see the product version of what's described conceptually in this chapter.