Most Indian companies implementing DPDP consent are building the wrong thing. They are adding a cookie banner, updating their signup checkbox text, and calling it done.
That is only one part of a much larger operational problem.
The harder part is infrastructure: a consent event ledger that records every decision with a timestamp and purpose, a propagation layer that pushes consent changes to every downstream processor in real time, a withdrawal mechanism that is as easy as the original grant, notice delivery with the language-access options required by the Act, and an audit trail that can prove to the Data Protection Board exactly what was consented to, when, by whom, and in what language.
This guide walks through how to build a consent management system that actually satisfies the DPDP Act. Not the marketing version. The engineering version. For the broader stack this sits in, see DPDP compliance for engineering teams and why a privacy policy is not compliance.
What DPDP actually requires for consent
Six provisions define the consent regime. Each creates a specific engineering obligation.
Section 6(1): The consent standard
Consent must be free, specific, informed, unconditional, and unambiguous with a clear affirmative action.
Free: The user cannot be coerced. Denying consent for marketing cannot block access to the product.
Specific: Consent must be tied to a defined purpose. "We use your data to improve our services" is not specific. "We use your email address to send transactional order confirmations" is.
Informed: The user must understand what they are consenting to before consenting.
Unconditional: Consent cannot be bundled with contract acceptance unless the data is strictly necessary for the service.
Unambiguous with clear affirmative action: Pre-ticked checkboxes, implied consent (continuing to browse), and dark patterns (reject button hidden behind "manage preferences") are all non-compliant. The user must take a deliberate, positive action.
Engineering implication: every consent capture point in your product must present unbundled, purpose-specific consent options with equal visual weight for accept and reject, and record the user's explicit action.
Section 5: Notice before or at the time of consent
Before requesting consent, you must provide a notice describing every personal data item being collected, the purpose of processing each item, and how the Data Principal can exercise their rights.
Engineering implication: the notice must be versioned. When you update your notice (adding a new purpose, changing a data category), existing consents were given under the old version. You need to track which version each user consented to.
Section 6(3): Language requirements
The Data Fiduciary must give the Data Principal the option to access the notice in English or any language specified in the Eighth Schedule. The Eighth Schedule contains 22 languages; English is separate from that list.
Engineering implication: build a translation and content-versioning workflow that can serve the required language options for your user base. Machine translation can assist with drafting, but legal accuracy matters. Human review should be part of the publishing workflow.
Section 6(4): Withdrawal parity
Consent withdrawal must be as easy as giving consent. If consent was one click, withdrawal must be one click. Not a support ticket. Not an email to the DPO. Not buried in account settings.
Engineering implication: build a "Manage my data" page accessible from the same location as the signup flow. Equal prominence, equal ease.
Section 6(5): Consequences of withdrawal
Upon withdrawal, the Data Fiduciary must stop processing the data for that purpose. Prior processing based on valid consent remains lawful, but future processing must cease.
Engineering implication: consent withdrawal is not retroactive, but it is immediate. Every system processing data for the withdrawn purpose must stop. This is the consent propagation problem.
Section 6(8): Consent Manager framework
Data Principals can manage consent through registered Consent Managers. The final Rules establish a registration framework for Consent Managers, including Indian incorporation and a minimum net worth requirement of Rs. 2 crore. Rule 4, which establishes the Consent Manager registration framework, comes into force one year after the Rules were notified, on November 13, 2026.
Engineering implication: if you plan to support Consent Manager-mediated consent, design your consent architecture so external consent signals can be incorporated into your internal consent ledger. Do not assume that every Data Fiduciary must integrate with a Consent Manager.
The consent data model
Every consent event must be stored as a structured record. Here is the minimum viable schema:
| Field | Type | Description |
|---|---|---|
| consent_id | UUID | Unique identifier for this consent event |
| data_principal_id | UUID | The user who gave or withdrew consent |
| purpose | ENUM | The specific processing purpose (e.g., marketing_email, product_analytics, payment_processing) |
| action | ENUM | GRANTED, WITHDRAWN, MODIFIED |
| notice_version | VARCHAR | The version of the consent notice shown |
| language | VARCHAR | The language the notice was displayed in |
| timestamp | TIMESTAMP | When the action was taken (server-side, not client-side) |
| collection_method | ENUM | WEB_FORM, MOBILE_APP, API, CONSENT_MANAGER |
| consent_manager_id | VARCHAR | If collected via Consent Manager, their registered ID |
| ip_address | VARCHAR | For audit purposes (hashed if preferred) |
| user_agent | VARCHAR | Browser or device information at time of consent |
This table is append-only. Never update or delete rows. Every consent change is a new row. This immutability is what makes it an audit trail.
Why append-only matters: When the Data Protection Board asks "did User X consent to marketing on June 12?", you need to produce the exact record. If you've been overwriting consent states in a boolean column, you cannot prove what was consented to, when, or under what notice version.
Purpose taxonomy
Before building anything, define your purpose taxonomy. This is the enumerated list of processing purposes your product uses. Every consent capture and every downstream processing activity must map to one of these purposes. Those purposes should also appear in your data map.
Example taxonomy for a B2B SaaS product:
| Purpose ID | Purpose | Description | Requires consent? |
|---|---|---|---|
| account_essential | Account operation | Core product functionality, authentication, session management | Section 7 legitimate use (voluntary provision for specified purpose) |
| transactional_email | Transactional communication | Order confirmations, password resets, security alerts | Section 7 legitimate use |
| marketing_email | Marketing communication | Newsletters, product updates, promotional content | Consent required (Section 6) |
| product_analytics | Product analytics | Usage tracking, feature adoption, funnel analysis | Consent required (Section 6) |
| behavioral_tracking | Behavioral tracking and personalization | Recommendation engines, personalized UI, A/B testing | Consent required (Section 6) |
| third_party_ads | Third-party advertising | Retargeting pixels, ad network SDKs | Consent required (Section 6) |
| support | Customer support | Ticket management, chat history | Section 7 legitimate use |
| billing | Billing and payments | Invoice generation, payment processing | Section 7 legitimate use |
Not every purpose requires consent. Section 7 defines "legitimate uses" that allow processing without consent. But each must be explicitly classified and documented.
Building the consent capture layer
Signup flow
The signup form is the primary consent capture point. Implement it as unbundled, purpose-specific consent:
Do:
- Present each non-essential purpose as a separate, clearly labeled toggle or checkbox
- Default all non-essential toggles to OFF (opt-in, not opt-out)
- Give equal visual weight to accept and decline
- Show a link to the full consent notice before the user takes action
- Record the exact state of every toggle at time of submission
Don't:
- Bundle marketing consent with account creation ("by signing up, you agree to receive marketing emails")
- Use pre-ticked checkboxes for any non-essential purpose
- Hide the reject option behind a "manage preferences" click
- Use dark patterns (larger accept button, grayed-out reject)
Cookie consent
Cookie consent under DPDP requires affirmative opt-in. The old IT Rules allowed implied consent (continue browsing). DPDP does not.
Where cookies or similar tracking technologies involve processing personal data on a consent basis, build a consent flow that:
- Blocks the relevant non-essential tracking until the required consent is given
- Presents categories (essential, analytics, marketing) with individual toggles
- Defaults non-essential categories to OFF
- Records the consent event in your consent ledger
- Respects withdrawal immediately (drops cookies and stops tracking)
In-product consent capture
Some consent needs to be captured during the product experience, not at signup. Examples:
- User enables a new integration that sends data to a third party
- User opts into a beta feature that collects additional data
- User enables push notifications
Each needs its own consent capture moment tied to the relevant purpose in your taxonomy.
Building the consent propagation layer
This is the hardest engineering problem in DPDP consent management. It is also the one most companies skip entirely.
The problem
A user withdraws marketing consent. The consent ledger records the withdrawal. But your marketing email platform (Sendgrid, Klaviyo) doesn't know. Your analytics pipeline (Mixpanel, PostHog) doesn't know. Your CDP (Segment) doesn't know. Your retargeting pixel (Meta, Google) doesn't know.
The user continues receiving marketing emails. Their behavior continues being tracked. Every processing event after the withdrawal is unauthorized under Section 6(5). Mapping those downstream systems is the same work as mapping third-party processors.
The architecture
Event-driven propagation. When consent state changes, emit an event to a message bus (Kafka, AWS SNS/SQS, EventBridge). Every system that processes data for that purpose subscribes to consent events and acts on changes.
The event payload:
{
"event_type": "consent_change",
"data_principal_id": "user_12345",
"purpose": "marketing_email",
"action": "WITHDRAWN",
"timestamp": "2026-08-25T10:30:00Z",
"effective_immediately": true
}
Subscriber actions by processor:
| Processor | Action on withdrawal |
|---|---|
| Sendgrid | Call Suppression API to suppress the user's email |
| Segment | Call DELETE regulation endpoint to suppress the user for the purpose |
| Mixpanel | Call opt-out API or delete user profile |
| PostHog | Disable tracking for the user via feature flag or API |
| Meta Pixel | Remove user from custom audience via Conversions API |
| Google Ads | Remove user from remarketing list via Customer Match API |
| Razorpay | No action needed (payment is essential purpose, not marketing) |
For processors without an API: Some tools don't have programmatic opt-out. For these, you need a manual suppression workflow with SLA tracking. Flag any processor that requires manual action as a compliance risk and prioritize migrating to an API-capable alternative.
Consent state cache
For high-throughput applications, checking the consent ledger on every request is expensive. Implement a consent state cache:
- On consent change, update a fast-access cache (Redis, in-memory) with the current consent state per user per purpose
- Services check the cache before processing
- Cache TTL should be short (5 minutes max) to limit the window of unauthorized processing after a withdrawal
- Cache miss falls through to the consent ledger
Testing consent propagation
The propagation pipeline must be tested end-to-end. Quarterly at minimum:
- Grant consent for all purposes for a test user
- Verify the test user's data flows to all processors
- Withdraw consent for one purpose
- Verify the withdrawal propagates to every processor for that purpose within the expected time window
- Verify the test user's data stops being processed for that purpose in every processor
- Document the test with timestamps and evidence
This test is the evidence the Data Protection Board will ask for.
Building the withdrawal mechanism
Section 6(4) requires withdrawal to be as easy as granting consent. Build a dedicated page:
"Manage my data" page. Accessible from:
- User account settings (primary)
- The footer of every marketing email (for marketing consent)
- The privacy policy page
The page should show:
- Current consent status for every purpose (granted/withdrawn, with date)
- One-click toggle to withdraw any specific purpose
- Confirmation of what withdrawal means (processing for that purpose stops, prior processing remains lawful)
- Timestamp of last change
When the user toggles a purpose off:
- Record the withdrawal event in the consent ledger
- Emit the consent change event to the propagation layer
- Confirm to the user that withdrawal has been processed
- Begin erasure workflow for that purpose's data if applicable under Section 8(7)
Preparing for Consent Manager integration
The Consent Manager registration framework under Rule 4 becomes operational on November 13, 2026. Consent Managers are registered intermediaries that can manage consent on behalf of Data Principals across multiple Data Fiduciaries.
What you need to build:
Consent ingestion API. If you choose to support Consent Manager-mediated consent, expose an integration layer that can accept consent events from registered Consent Managers. The event model should be designed to capture the Data Principal identifier, purpose, action (grant/withdraw), Consent Manager identifier where applicable, timestamp, and relevant notice/version metadata.
Verification. Verify that the Consent Manager is registered and that incoming consent signals can be reliably associated with the relevant Data Principal and purpose.
Parity. Consent received through a Consent Manager should feed the same internal consent ledger, propagation controls, and withdrawal workflow as directly captured consent, subject to the applicable Consent Manager framework.
The detailed technical integration standard may evolve. Keep the consent architecture decoupled from vendor-specific APIs so you can connect to registered Consent Managers as the ecosystem develops.
Evidence generation for audit
Your consent management system must produce audit-ready evidence on demand:
Per-user consent history. For any Data Principal, produce the complete consent timeline: every grant, every withdrawal, every notice version shown, every language used.
Per-purpose consent coverage. For any processing purpose, produce the percentage of users with valid, current consent. Flag users being processed without consent.
Consent notice version history. Every version of every notice, with effective dates and the number of users who consented under each version.
Propagation evidence. For any withdrawal event, produce evidence that every processor was notified and acted on the withdrawal, with timestamps.
This evidence is what transforms consent from a UX feature into a legal defense. For the broader evidence pack, see what a DPDP audit actually looks at.
The five consent implementation mistakes
Mistake 1: Boolean consent column.
A single has_consented: true/false column in the users table. No timestamp, no purpose, no version tracking, no audit trail. This is the most common pattern and the most dangerous. Replace with the append-only consent ledger.
Mistake 2: Consent without propagation.
You capture consent beautifully. You record it in the ledger. When it changes, nothing downstream knows. The marketing emails keep going. The analytics keep tracking. This is consent theater.
Mistake 3: Opt-out defaults.
Pre-ticking marketing consent, analytics consent, or any non-essential purpose. Under DPDP, consent must be affirmative. Opt-out defaults (consent assumed unless the user actively rejects) are invalid.
Mistake 4: English-only notice.
Your consent notice is available only in English, while your user base spans multiple Indian states and languages. Section 6(3) gives Data Principals the option to access the notice in English or any language specified in the Eighth Schedule. Design the notice system to support that access requirement rather than assuming an English-only flow is sufficient.
Mistake 5: No withdrawal mechanism.
The user can grant consent at signup. There is no way to withdraw it short of emailing the support team. Section 6(4) requires parity: if consent was one click, withdrawal must be one click.
The self-test
- Can you produce the exact consent notice version shown to a specific user on a specific date?
- If a user withdraws marketing consent right now, how long before your email platform actually stops sending?
- Is your consent capture opt-in (default off) or opt-out (default on)?
- How many languages is your consent notice available in?
- Can a user withdraw consent for a specific purpose without contacting support?
If any answer is uncertain, that is your starting point.
Where Privra fits
Privra builds and operates consent architecture for Indian companies. Our system handles purpose-based consent capture, multilingual notice delivery, real-time propagation to downstream processors, withdrawal parity, and continuous audit-trail generation. Your engineering team integrates once. We handle the ongoing consent compliance.
Talk to us about consent architecture.
This article has been reviewed against the notified Digital Personal Data Protection Rules, 2025 and the Digital Personal Data Protection Act, 2023. Legal requirements and Privra's recommended engineering practices are intentionally distinguished.