DPDP Consent Management Guide — Technical Implementation (2026)

Consent Is Infrastructure, Not a Checkbox

The biggest mistake companies make with DPDP consent is treating it as a UI problem — add a cookie banner, check a box, done.

Collect granular, purpose-specific consent before any processing begins
Record every consent event with a cryptographic audit trail
Allow one-click withdrawal that propagates to all downstream systems
Re-obtain consent when purposes change
Integrate with your data processing pipelines to enforce consent decisions in real-time

This guide covers the technical architecture for DPDP-compliant consent management.

What the DPDP Act Requires

Section 6 of the DPDP Act prescribes specific consent requirements:

1. Free consent — Cannot be conditional on service access for non-essential processing. You can require consent for core service delivery but not for marketing or analytics.

2. Specific consent — Each processing purpose needs its own consent. "I agree to all" is non-compliant. If you collect data for (a) service delivery, (b) marketing emails, and (c) analytics, that's three separate consent requests.

3. Informed consent — Must be accompanied by a privacy notice that explains what data, for what purpose, shared with whom, and how to withdraw.

4. Unconditional consent — Cannot use dark patterns, misleading language, or manipulative design to obtain consent.

5. Unambiguous consent — Requires clear affirmative action. Pre-ticked checkboxes, silence, or inactivity do not constitute consent.

6. Withdrawal = as easy as giving — If consent is collected with one click, withdrawal must be one click. If via a form, withdrawal via a form. The friction must be equal.

Consent Data Architecture

A compliant consent system needs these core entities:

Core Data Model

Consent Purposes ``` Purpose { id: UUID name: string // "Marketing Emails" description: string // Shown to user legalBasis: enum // CONSENT | LEGITIMATE_USE dataTypes: string[] // ["email", "name"] isEssential: boolean // Can't withdraw without leaving retentionPeriod: string // "3 years from last activity" thirdParties: string[] // ["SendGrid", "Mixpanel"] } ```

Consent Records ``` ConsentRecord { id: UUID principalId: string // User identifier purposeId: UUID status: enum // GRANTED | WITHDRAWN collectedAt: timestamp withdrawnAt: timestamp? collectionMethod: string // "widget_v2", "api", "form" ipAddress: string userAgent: string noticeVersion: string // Which privacy notice was shown } ```

Every consent event creates a new immutable record. Never update consent records — append new ones. This gives you a complete, tamper-evident audit trail.

Consent Verification Flow

Before any data processing, your systems should verify consent:

1. User action triggers data processing
2. System queries: "Does user X have active consent for purpose Y?"
3. If yes → proceed with processing
4. If no → block processing, show consent collection UI
5. If withdrawn → stop processing, queue data for deletion

This is the critical integration point. Your consent system isn't useful if it's disconnected from your actual data processing pipelines.

Consent Widget Implementation

The consent widget is the user-facing component. Here's what makes it DPDP-compliant:

Design Requirements

No dark patterns — "Accept all" and "Reject all" buttons must be equally prominent. No colour tricks (bright green for accept, grey for reject).
Purpose-level granularity — Each purpose is a separate toggle, not a single "I agree" checkbox.
Privacy notice link — Clearly visible before the user makes any choice.
No pre-selected options — All toggles start in the "off" position except essential purposes.
Language support — Widget text available in the user's preferred language.
Dismissible without consequence — User can close the widget without consenting (they just can't access non-essential features).

Implementation Pattern

Option A: Embeddable JavaScript Widget

Deploy via a script tag on your website: ```html ```

The widget loads asynchronously, shows the consent UI, and sends consent decisions to the DPDP Comply API. Your application can then check consent status via API before processing data.

Option B: API-First

Build your own UI, use the DPDP Comply API for consent storage and verification: ``` POST /api/v1/consent/collect { "principalId": "user@example.com", "purposeId": "mktg_emails", "status": "granted", "noticeVersion": "2.1" }

GET /api/v1/consent/status?principalId=user@example.com&purposeId=mktg_emails → { "status": "granted", "grantedAt": "2026-03-12T..." } ```

Consent Withdrawal Architecture

Withdrawal is where most implementations fail. The DPDP Act requires withdrawal to be "as easy as giving consent."

This means:

1. Preference Centre — A branded page where users can view and modify their consent choices at any time. Accessible from your app settings, email footers, and privacy notice.

2. One-Click Withdrawal — If consent was given with one click, withdrawal must be one click. No "are you sure?" confirmations, no "tell us why" surveys before processing the withdrawal.

Stop all processing for that purpose immediately
Remove user from marketing lists
Queue data for deletion (if no other legal basis)
Notify third-party processors to stop processing
Log the withdrawal in the audit trail

4. Confirmation — Send the user confirmation that their withdrawal has been processed.

The propagation step is the hardest. If a user withdraws marketing consent, can your system automatically unsubscribe them from SendGrid, remove them from your Mixpanel cohort, and update your CRM — all without manual intervention?

This is why consent needs to be infrastructure, not a checkbox.

Building a Tamper-Evident Audit Trail

The audit trail is your evidence in case of a regulatory inquiry. It needs to prove:

What consent was given — exact purposes and data types
When it was given — precise timestamp
How it was given — which UI, which version of the notice
What the user was told — the notice version shown at the time
When/if it was withdrawn — and that you stopped processing

Append-only storage (never modify or delete consent records)
Include a hash of the previous record for chain integrity
Store the full privacy notice text (or version hash) shown at consent time
Log IP address and user agent for non-repudiation
Retain consent records for the processing lifetime + 3 years
Regular integrity checks on the audit log

If the Data Protection Board asks "did user X consent to marketing emails on March 1, 2026?" — you need to answer with cryptographic certainty.

Common Consent Implementation Mistakes

1. Cookie consent ≠ DPDP consent — The DPDP Act is about personal data processing, not cookies. Your cookie banner doesn't satisfy DPDP requirements.

2. One-time collection — Consent is ongoing. If you add a new processing purpose, you need new consent. If your notice changes materially, you may need to re-consent existing users.

3. No enforcement — Collecting consent but not actually checking it before processing is worse than not collecting at all (it shows you knew about the requirement and ignored it).

4. Email opt-in as consent — "Subscribe to our newsletter" is not DPDP consent. DPDP consent must reference the specific data types, purposes, and rights.

5. Ignoring third-party consent — If you share data with vendors (analytics, marketing, payments), you need consent for that sharing. Most privacy notices don't mention specific third parties.

---

Ready to implement compliant consent? Start your free trial or take the readiness assessment to see where you stand.

DPDP Consent Management: The Complete Technical Guide