What valid consent requires, what is effective when, what your organisation must build, and exactly where to go next.
DPDP consent management is how a Data Fiduciary that relies on consent meets India’s Digital Personal Data Protection Act: define a specified purpose, give the required notice, obtain valid affirmative consent, let people withdraw as easily as they agreed, stop consent-based processing (and make its processors stop) within a reasonable time of withdrawal, and keep evidence able to prove all of it. DPDP consent management is an operating model, not a checkbox, cookie banner or CRM field.
Pick a path and jump straight to the sections that matter for your problem.
When a Data Fiduciary relies on consent, it must be able to collect, use, change, withdraw, stop and prove consent-based processing. That is not a single feature. It is a connected operating model across purpose, notice, capture, identity, enforcement, withdrawal, processors and evidence.
Under the DPDP Act, a Data Fiduciary decides the purpose and means of processing; a Data Principal is the individual the data is about. Relying on consent means you can later demonstrate that the person received the required notice and gave valid consent for a specified purpose. Most organisations discover the hard part is not capturing consent, it is stopping and proving it downstream.
The Act does not name a “consent ledger,” CMP, cookie banner or dashboard. It creates a proof burden when you rely on consent. A controlled consent record is one implementation approach that supports that burden; it is a recommendation, not a statutory product.
What is at stake: the Act sets maximum penalties of up to ₹250 crore for a failure of reasonable security safeguards and up to ₹200 crore for breaches of children’s-data obligations, imposed by the Data Protection Board after inquiry. Provable consent and its evidence trail are part of how a Data Fiduciary limits that exposure.
Valid DPDP consent is a free, specific, informed, unconditional and unambiguous agreement, given by a clear affirmative action, to process only the personal data necessary for a stated purpose. Implied permission, pre-ticked boxes and bundled acceptance do not meet that standard.
A SaaS form offering a technical guide should separate three purposes: (1) deliver the requested guide, (2) send product and event marketing, (3) share with named partners. Delivering the guide must not be made artificially conditional on accepting optional marketing.
Consent is not the only lawful route. Section 7 “certain legitimate uses” can cover processing such as a voluntarily provided purpose, legal obligations, or specified employment uses. Asking for consent where a legitimate use genuinely applies, or calling optional marketing a “legitimate use,” both create risk.
Maintain a processing-purpose register: each purpose gets one primary legal basis, data categories, system owners, recipient categories, a retention rule and a withdrawal/rights impact.
A DPDP notice explains the proposed processing; consent is the Data Principal’s affirmative agreement to it. Section 5 requires notice before or with a consent request. A privacy policy supports transparency but is not automatically the Section 5 notice or a valid consent record.
| Item | Main function | Expressly required? | Typical format |
|---|---|---|---|
| DPDP notice | Explain the data and specified purpose before/with the request | Yes, under Section 5 | Just-in-time product/form/account notice |
| Privacy policy | Broad transparency document | Not named as the Section 5 notice format | Website / app policy |
| Consent request | Ask for affirmative agreement | Yes, where relying on consent | Checkbox, toggle, button, signed/verbal record |
| Consent record | Preserve proof of notice and action | Proof burden under Section 6(10) | Ledger, event log, auditable record |
A lone privacy-policy link beside a checkbox is weak if the person cannot tell what data is collected, why, whether a purpose is optional, how to withdraw, and what action counts as agreement. Design the notice and affirmative event around the actual context.
Rule 3 (effective 13 May 2027) will require the notice to be independently understandable, in clear and plain language, itemising the data, purpose, withdrawal route, rights and a link to the Data Protection Board.
DPDP consent aligns with the GDPR on free, specific, informed and unambiguous consent and easy withdrawal, but do not port a GDPR programme wholesale: there is no cookie-banner mandate, no standalone right to explanation, and notices must be available in English and the Eighth Schedule languages.
You do not need to erase pre-DPDP customer data on 13 May 2027. Under Section 5(2), consent obtained before commencement can support continued processing until withdrawal, but as soon as reasonably practicable you must give notice of the data, purpose, withdrawal route, rights and how to complain to the Board. This is one of the largest practical problems for Indian businesses.
Purchased or scraped lead lists are high risk: a seller’s assurance is not proof that you have valid consent for your intended purpose. Old marketing leads with no purpose-specific consent should be quarantined, re-permissioned or suppressed.
Section 6(10) puts the proof burden on the Data Fiduciary: where a question arises in a proceeding, you must be able to show notice was given and valid consent obtained. That makes consent evidence an operational control, not a UX afterthought. The Act does not fix a record format, but a controlled record helps you answer the questions that matter.
“Marketing opt-in = yes” in a CRM is rarely enough. It usually cannot show which purpose, which channel, which notice version, whether a separate third-party choice existed, or whether a later withdrawal reached email, SMS, WhatsApp, ad audiences and external processors.
Treat consent records as integrity-sensitive evidence: access controls, tamper-evident logging where proportionate, change histories and backup/recovery, especially for financial, lending, health, insurance and children’s services.
A Data Principal may withdraw consent at any time, and withdrawal must be as easy as giving it. After withdrawal the Data Fiduciary must stop consent-based processing within a reasonable time and cause its processors to stop, unless another law authorises or requires continued processing. This is where many otherwise-good programmes fail: they capture consent in one place but cannot stop it everywhere.
Support granular withdrawal. Someone may stop marketing while keeping the service. Do not read a marketing withdrawal as a delete-everything request, and do not use active account status as an excuse to continue unrelated marketing or profiling.
Run the free readiness assessment to score notice, consent, evidence, withdrawal and processor controls, and get a prioritised gap list.
Withdrawal stops consent-based processing. Erasure deletes stored data. Retention keeps limited data where a law or specified purpose still requires it. Do not promise total deletion when tax, fraud, security, claims or regulatory duties require records to remain, and do not keep data for unrelated reuse just because you are allowed to retain some of it.
| Concept | Main question | Typical outcome |
|---|---|---|
| Consent withdrawal | Can we continue consent-based processing? | Stop the affected processing within a reasonable time |
| Cessation | Which systems and processors must stop? | Disable marketing, profiling or sharing for that purpose |
| Erasure | Must stored data be deleted? | Delete unless retention is necessary for a purpose or law |
| Retention restriction | Can data stay but be blocked from ordinary use? | Keep only necessary records with restricted access |
| Suppression | How do we prevent future marketing? | Keep a minimal “do not contact” record where justified |
Section 8(7) requires erasure when consent is withdrawn or the purpose is no longer served, whichever is earlier, unless retention is needed to comply with law, and requires you to cause processors to erase data made available to them. Section 12 gives the Data Principal a right to seek erasure, subject to the same retention limits.
DPDP does not prescribe an architecture, but a Data Fiduciary relying on consent should build systems that can prove what was agreed, enforce purpose limits, handle withdrawal, and push stop-processing instructions to processors. The pattern below is an implementation reference, not a statutory design.
Identity resolution is the hidden dependency. A consent status only works if it maps to the right person across email, mobile, customer ID, device and cookie identifiers. Weak matching can suppress, delete or disclose the wrong person’s data. Then make consent a system input: an API blocks a marketing export when consent is withdrawn, a CDP drops the person from ad audiences.
A Data Fiduciary stays accountable for consent-dependent processing done by its processors. Withdrawal is incomplete if internal systems stop but vendors, SaaS tools, ad platforms or outsourced teams keep using the data. Changing one CRM field is not enough.
Keep a purpose-to-processor map and use a vendor test: “If we send a withdrawal for Data Principal 12345, which datasets, caches, tickets, backups, tables, profiles and subprocessors are affected, and what evidence will you return?” If a vendor cannot answer, you likely cannot meet your Section 6 and 8 duties through them.
A DPDP Consent Manager is a specific, Board-registered role, not a generic software product. It is a single point of contact through an accessible, transparent and interoperable platform that lets a Data Principal give, manage, review and withdraw consent. It is not a synonym for a CMP, cookie tool or CRM preference field. The statutory role echoes India’s Account Aggregator and DEPA consent-sharing lineage: an interoperable, registered intermediary, not a compliance plugin.
As of August 2026 the concept and Rules are notified, but the Section 6(9) registration regime and Rule 4 commence on 13 November 2026. Do not describe any product as a Board-registered Consent Manager before then, and ordinary consent software is not automatically one.
| Capability | DPDP Consent Manager | CMP | CRM field |
|---|---|---|---|
| Defined by the DPDP Act | Yes | No | No |
| Board registration required | Yes (once s6(9) is effective) | No | No |
| Single point of contact for Data Principals | Statutory purpose | Maybe | No |
| Must be interoperable | Yes | Not automatically | No |
| Must avoid conflict of interest | Yes | No such rule | No |
You do not have to wait for the Consent Manager market to form. During 2026, decide whether you need an internal consent service or a CMP, keep consent data exportable and interoperable, and avoid lock-in to any vendor that cannot support withdrawal, audit evidence or downstream propagation.
Some processing carries sharply higher penalties and scrutiny. Before processing a child’s data (anyone under 18), you must obtain verifiable parental consent and must not track, behaviourally monitor or run targeted advertising at children, except under a narrow Fourth Schedule exemption. Marketing carries a different trap: do not import GDPR cookie-banner assumptions.
The consent framework is uniform, but the operational tension changes by sector. These are summaries, not complete sectoral advice; each links to a deeper vertical guide as we publish more guides.
Consent management is cross-functional. Legal defines the framework, but product captures consent, engineering enforces it, security protects the evidence, marketing uses preferences, procurement governs vendors and support receives withdrawals. The Act prescribes no RACI; this is a recommended ownership model.
| Function | Primary responsibility |
|---|---|
| Board / executive | Risk oversight, resourcing, escalation |
| DPO / privacy | Legal interpretation, policy, notices, rights governance |
| Legal | Contracts, disputes, retention, sectoral-law analysis |
| Product | Consent journeys, purpose presentation, user controls |
| Engineering | System of record, APIs, events, withdrawal propagation |
| Security (CISO) | Access control, log integrity, monitoring, breach readiness |
| Marketing / CRM | Preference use, suppression, campaign governance |
| Procurement | Processor diligence, contract controls, deletion support |
| Support | Intake, identity verification, grievance escalation |
| Internal audit | Control testing, end-to-end withdrawal and retention validation |
The Act does not require you to buy consent software. A spreadsheet may suffice for a small organisation with few purposes, low volume and few processors, if it still preserves access controls, change history and evidence. It becomes risky once you have multiple channels, large marketing stacks, ad audiences, many processors, children’s data or AI reuse.
The most effective approach is to build the operating model before core consent provisions commence on 13 May 2027. Start with data and purpose discovery, then move through decisions, design, build, testing and governance. This is product, data, security and vendor work, not only legal preparation.
| Period | Priority action |
|---|---|
| Q3–Q4 2026 | Purpose and data-flow discovery; legacy-data triage; monitor Consent Manager registration (opens 13 Nov 2026) |
| Q1 2027 | Notice and consent redesign; processor contract updates; architecture decisions |
| Q2 2027 | System integrations; withdrawal propagation; test programmes; staff training |
| Before 13 May 2027 | Final readiness assessment; remediate critical gaps; executive sign-off |
A DPDP consent audit tests whether you can demonstrate valid notice and consent, enforce purpose limits, complete withdrawals across processors, and explain any retained data. You do not need a formal annual audit for every organisation, but auditability is how you meet the Section 6 proof burden.
Your path from here:
Turn this checklist into a scored result with a prioritised gap list for your organisation.
Consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, limited to the personal data necessary for a specified purpose and confined to that purpose (Section 6).
No. Consent is one basis. Section 7 “certain legitimate uses” can cover some processing, such as a voluntarily provided purpose, legal obligations or specified employment uses. Map each purpose to one primary basis.
Usually not. A privacy policy supports transparency but is not automatically the Section 5 notice or a valid consent record. Design a context-specific notice and a clear affirmative consent event.
No. There is no cookie-specific rule or mandated “accept all / reject all” control. But where an online identifier is personal data and you rely on consent, the Section 5 and 6 requirements apply.
Yes, at any time, and withdrawal must be as easy as giving consent. You must stop consent-based processing within a reasonable time and cause processors to stop, subject to other authorised or required processing.
Not necessarily. Withdrawal, cessation and erasure are distinct. Data may be retained where necessary for a specified purpose or to comply with law, but it should not be reused for unrelated purposes such as marketing.
The Act requires you to prove notice was given and valid consent obtained when a question arises in a proceeding. A controlled record of identifier, purpose, timestamp, notice version, affirmative action and withdrawal history is a practical way to support that proof.
Yes, where processing depends on withdrawn consent. Section 6 requires the Data Fiduciary to cause its processors to cease within a reasonable time, unless another legal basis authorises or requires it.
No. A Consent Manager is a distinct Board-registered role for enabling Data Principals to manage consent through an interoperable platform. You do not become or use one merely because you process personal data.
Not always. Section 7 includes certain employment-related legitimate uses, such as preventing loss or liability, protecting confidentiality and providing employee benefits. Still map each purpose rather than treating employment as a blanket exemption.
No. There is no standalone GDPR-style right to explanation of automated decisions. Section 11 provides a right to access information about personal data and processing activities in specified circumstances.
The specialist guides below go deeper on each part of this guide. They publish in priority order; the readiness assessment is live now.
This guide is general information about the DPDP framework, not legal advice. Confirm application to your organisation with a qualified Indian privacy-law adviser.