How to build a consent management system for DPDP
DPDP consent is not a checkbox — it requires a system that captures, stores, and propagates consent signals across your entire data infrastructure.
What must a DPDP consent record capture?
Every DPDP consent record must capture: the identity of the data principal (or a pseudonymous identifier); the date and time of consent; the specific purposes for which consent was given (not a generic 'I agree to the privacy policy'); the channel through which consent was given (web, app, paper, phone); the version of the privacy notice that was active at the time; and any subsequent withdrawal or modification. This record is your proof of consent if the Data Protection Board investigates. Store it in an immutable audit log.
How should consent be presented to users?
Consent requests must be: specific (separate checkboxes for each purpose, not one master consent); informed (a plain-language description of what the data will be used for, not legalese); freely given (not bundled with service access unless the data is strictly necessary for the service); and easily revocable (a visible withdrawal mechanism as easy as giving consent). Present consent purposes in plain, non-technical language at the first point of interaction where personal data is collected — registration form, checkout, app onboarding.
How do you propagate consent signals across your tech stack?
Consent given at the user interface must be communicated to every downstream system that uses that data. This requires a consent propagation architecture: the consent management layer (CMP or consent database) should emit events (webhooks, API calls, Kafka topics) that downstream systems subscribe to. Your CRM, email marketing tool, analytics platform, and ad tech should all receive consent status updates and enforce them. When a user withdraws consent, the withdrawal event must cascade through all systems within a defined SLA — ideally real-time or within minutes.
What technology stack can you use for DPDP consent management?
Options range from purpose-built CMPs (OneTrust, Cookiebot, Usercentrics — though these are primarily GDPR-focused and need DPDP customisation) to custom-built consent databases. For most Indian mid-market companies, a practical starting point is a structured consent table in your existing database (user_id, purpose, granted, timestamp, withdrawal_timestamp), a consent collection UI in your registration and settings flows, and propagation logic that reads consent status before processing in each downstream system. Scale to a purpose-built CMP as complexity grows.
How do you handle consent for existing users before DPDP enforcement?
For existing user bases that predate DPDP enforcement (May 2027), you need to establish a lawful basis for continuing to process their data. Where the existing consent is not DPDP-compliant (too broad, bundled, or obtained without proper notice), you have options: run a re-consent campaign; migrate processing to a legitimate use basis where applicable; or stop processing users who do not re-consent. Re-consent campaigns work best when positioned as a benefit — 'update your preferences for a better experience' — rather than a compliance exercise.
How do you audit your consent management system?
Periodically audit your consent system: check that consent records are being captured for every data collection touchpoint; verify that withdrawal events are propagating correctly to all downstream systems; test that the withdrawal mechanism works as intended; review the privacy notice version linked to each consent record to ensure it is current; and check that no personal data is being processed for users who have not consented or have withdrawn. Run these checks quarterly and document the results as evidence of ongoing compliance.
Frequently asked questions
Is a privacy policy checkbox at registration enough for DPDP consent?
No. A checkbox saying 'I agree to the Privacy Policy' is not specific consent under DPDP. Consent must be specific to each processing purpose. If you use data for multiple purposes (order fulfilment, marketing, analytics, personalisation), you need separate consent for each purpose — or at minimum, granular disclosure with opt-in for non-essential purposes. The privacy policy itself is a notice document, not a consent mechanism.
Can we use legitimate interest instead of consent for some processing under DPDP?
The DPDP Act provides for 'legitimate uses' as an alternative lawful basis to consent for specific situations: statutory obligations, state functions, and other purposes the government may prescribe. Unlike GDPR's broader legitimate interests test, DPDP's legitimate use basis is expected to be narrower. For most commercial data processing — analytics, marketing, personalisation — consent is the appropriate basis. Monitor government notifications for any expansion of the legitimate use provisions.
How should we store consent records securely?
Consent records should be stored in a tamper-evident, auditable system — a database with append-only logging where records cannot be modified or deleted. Use a separate consent database (or consent schema) rather than embedding consent flags in your main application database, which reduces the risk of accidental overwrites during migrations or data cleaning. Back up the consent database regularly and retain records for at least as long as you retain the personal data they cover.
Audit your consent architecture
Niti Bharat's DPDP Consent Audit examines your existing consent collection, records, propagation architecture, and withdrawal mechanisms — with a gap report and technical remediation plan.
Start Consent Architecture Audit