The DPDP Rules are notified and the compliance deadline sits at May 2027 — here's a practical framework for evaluating a consent platform against what the Act actually requires, not what a demo makes easy to show.
June 2026 · 9 min read
Most organisations shopping for a consent management platform today have a realistic window of twelve to eighteen months to select one, implement it, and prove it works before enforcement begins. That's tighter than it sounds once you factor in evaluation, integration, data mapping and staff training — so it's worth getting the selection criteria right the first time rather than discovering the gaps after signing.
The complication most buyers run into: the consent management category, as it exists globally, grew up around GDPR. That shapes how most platforms are designed, and a fair amount of it doesn't map cleanly onto the DPDPA. This isn't a vendor comparison — it's a framework for evaluating any platform you're looking at, including whichever one you might already be using.
GDPR gives controllers six lawful bases for processing, and "legitimate interest" alone lets a business run a good deal of analytics, fraud checks and marketing without asking first. The DPDPA doesn't offer a general-purpose equivalent — for most Indian businesses, consent is the primary legal basis, full stop. A platform designed around "consent is one option among several" starts from the wrong assumption for Indian law.
The vocabulary is different too, and it isn't cosmetic. GDPR speaks of Controllers, Data Subjects and Processors. The DPDPA speaks of Data Fiduciaries, Data Principals and Data Processors, and the obligations attached to each come from the Act itself. If your consent logs and audit reports still carry GDPR terminology, they don't map cleanly onto what you'd present to the Data Protection Board of India.
DPDPA also requires notices in a language the Data Principal understands, and India has 22 official scheduled languages — an English-only consent banner doesn't meet that bar for a large share of the population. And from 13 November 2026, the Act introduces a registered Consent Manager framework: entities registered with the Board that let Data Principals manage consent across multiple Data Fiduciaries centrally. This is uniquely Indian, with nothing comparable under GDPR — a platform built natively for Indian law should already have it on its architecture roadmap.
Section 6 requires consent that's free, specific, informed, unconditional and unambiguous. That rules out pre-ticked boxes, bundled consent across multiple purposes, and any implied consent from continued use. The platform needs to support separate consent per processing purpose, recorded independently.
This is where most implementations quietly fail. Section 6(4) requires that withdrawing consent be no harder than giving it, and withdrawal isn't a messaging exercise — it's a systems-control problem. When a Data Principal withdraws, processing has to actually stop across every connected system and processor. Ask directly: what happens downstream when a withdrawal is recorded? "We log it, you handle the rest" isn't a compliant withdrawal mechanism.
DPDPA gives users rights beyond consent itself — access, correction, erasure, grievance redressal and nomination. The platform needs a structured workflow for each: intake, verification, SLA tracking, fulfilment and an audit trail that would survive a Board inquiry.
You need to demonstrate that consent was obtained, what it covered, when, and under which notice version. That means a tamper-evident log: timestamp, purposes consented to, the exact notice shown, withdrawal events, and records of downstream propagation.
Section 8 places obligations on Data Fiduciaries to ensure their processors also comply. For most mid-size and large organisations, that means dozens of SaaS tools, analytics vendors and integration partners who touch personal data on the business's behalf. Many CMPs stop at the Data Principal-facing layer and leave this entirely up to you.
Significant Data Fiduciaries and higher-risk processing activities require Data Protection Impact Assessments. A DPIA isn't a one-off exercise — it needs to be repeatable, documented, and linked back to the specific processing activity it assessed.
Ask specifically which of the 22 scheduled languages the platform supports natively, and whether translations were done by human translators or generated automatically. Machine-translated legal notices don't reliably meet DPDPA's standard.
DPDPA isn't just a consent law — it's a full-lifecycle data protection framework: notice and consent, rights fulfilment, breach notification (a 72-hour clock to the Board), DPIA for high-risk activity, processor oversight and security safeguards, all at once. A platform that only handles consent capture leaves you managing rights, breach, DPIA and processor oversight in separate tools, each with its own audit trail and its own gaps — fragmentation that's itself a source of risk, independent of how good any one tool is on its own.
The question that actually separates platforms, after the demo is done: if a Data Principal withdraws consent today, and six months from now the Board asks you to prove processing stopped across every one of your systems and vendors — can this platform actually produce that evidence? If you're not confident in the answer, that's the gap to close before you commit, not after. Our CMP evaluation service runs this exact framework against your shortlist, and if building rather than buying makes more sense, we also do the full build and deployment, source-owned, on your own infrastructure.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation