Consent records under the DPDP Act
A practical guide to building consent records under the DPDP Act for product, legal, marketing and compliance teams in India.
Data>Nuance
A consent record with no evidence is merely optimism in formal shoes.
Consent records under the DPDP Act should show what the individual was told, what they agreed to, when they agreed, and how the business used that signal. A screenshot alone is usually not enough. A useful record connects the notice, purpose, data category, channel, language, version, withdrawal status and system activity.
The DPDP Act deals with consent, notice and the rights of Data Principals. The DPDP Rules, 2025 add implementation detail that should be checked against official sources before final publication or audit use. For a growing company, the practical goal is simple: if a complaint, audit or internal review asks why processing happened, the team can answer from records instead of memory.
What to review
Review every consent collection point. This includes app onboarding, website forms, checkout flows, demos, events, newsletter sign-ups, employment portals, support scripts and partner journeys. For each point, identify the purpose, data fields, notice version and system where the signal is stored.
Review whether consent records are versioned. If a notice changes, the business needs to know which users saw which version. If a feature changes purpose, old consent may not safely cover the new activity.
Review withdrawal and preference records alongside consent collection. A consent record that does not show later withdrawal, suppression or preference changes may mislead operational teams.
Review evidence quality across systems. A marketing platform may store a timestamp, the website may store the notice version, and the CRM may store the customer profile. Unless these are linked, the organisation may struggle to reconstruct the full consent story.
Review access control. Consent records are evidence, but they may also contain personal data or identifiers. Restrict editing, log changes and make sure support teams can view what they need without accidentally changing the record.
Implementation steps
Define a standard consent-record schema. Useful fields include Data Principal identifier, consent purpose, data category, timestamp, channel, notice version, language, source page or screen, device or session reference where appropriate, withdrawal status, and system owner.
Connect the schema to actual systems. Marketing automation, CRM, product databases, consent managers and customer support tools should not each maintain conflicting truth. Decide which system is authoritative and which systems receive updates.
Create a monthly exception report. Look for missing timestamps, unclear purposes, duplicate records, failed syncs, stale notice versions and vendor tools that collect data without a mapped consent record. Exceptions should be assigned to owners, not left as dashboard noise.
Test the record before relying on it. Pick five users or accounts, trace the notice they saw, the consent they gave, the system that stored it, and the downstream tools that acted on it. This sample often reveals broken integrations faster than policy review.
Add retention and deletion rules. Consent evidence may need to be retained long enough to explain a processing decision, but it should not become a forgotten archive. Link retention to the purpose, dispute risk, audit need and deletion workflows.
For audit readiness, maintain a short data dictionary for consent fields. It should explain what each field means, who can edit it, which system creates it, and how exceptions are corrected. This keeps evidence understandable when team members change.
Common mistakes
- Keeping consent evidence only as a design screenshot, without user-level timestamps, purpose mapping or notice-version history.
- Allowing marketing, product and support systems to hold conflicting consent states for the same individual.
- Forgetting to record withdrawal, preference changes and suppression actions against the original consent purpose.
How DataNuance can help
DataNuance can help design consent-record fields, map system ownership, review notice-version controls and create an evidence checklist for product and compliance teams. The work is especially useful before funding diligence, product launches, vendor reviews or board reporting. To review your consent evidence model, contact DataNuance through our contact page.
FAQs
What should a consent record prove?
It should prove the purpose, notice version, channel, timestamp, individual or account reference, and current consent or withdrawal state.
Do we need separate records for each purpose?
Usually yes. Purpose-level records reduce confusion when one consent is withdrawn but another processing activity continues on a different basis.
Can a CRM be the consent source of truth?
It can be, if it reliably receives updates from product, marketing and support systems. If not, choose a more accurate authoritative system.
How long should consent records be retained?
Retention should match the business need to evidence the processing decision, subject to legal, operational and deletion considerations. Record the rationale.
Sources
This publication is general information and is not legal advice for a specific organisation or matter.