DPDP consent records: what an auditor will actually ask for
Five things an auditor asks for: the notice the person saw, the purpose, the timestamp, the withdrawal path — and why a checkbox is not consent.
A DPDP consent record is not a checkbox in a form. It is evidence that a specific person, at a specific time, agreed to a specific purpose under a specific version of your notice — and that they can withdraw it.
An auditor will ask for five things: the notice the person saw, the purpose it covered, the affirmative action that captured consent, the timestamp and source, and the path used to withdraw. If any one is missing, the consent is difficult to defend.
LoopNow stores the notice version, purpose, collection point, timestamp and withdrawal status per contact. The record links to the workflow run that used the data, so you can answer “why did you message this person?” without reconstructing a spreadsheet.
Start with the data map. Then make consent an event, not a field. Then test withdrawal end to end, including deletion from analytics, memory and logs. That is the work.
What this means for your team
Every action has a trace with tool, latency and cost.
Every consent has a notice version and a timestamp.
Every escalation has a named human and an audit entry.
Every number has a denominator and a window.
If a number in this article is not defensible, it does not ship. That is the editorial standard.
A consent record is evidence of a specific person agreeing to a specific purpose under a specific notice version at a specific time.
Five fields make it defensible: notice version, purpose, affirmative action, timestamp and source, and withdrawal state.
A checkbox value in a CRM is not a record. The record has to be append-only and linked to the runs that used the data.
Withdrawal is a separate event with its own timestamp, and it must propagate to email, WhatsApp, SMS, analytics and agent memory.
Consent, suppression and preference are three different things; collapsing them into one boolean creates both compliance and deliverability failures.
This is an engineering explainer, not legal advice; the exact obligations depend on the Act, the Rules and your role.
The question behind the question
When an auditor or a customer’s privacy team asks for consent records, they are rarely asking whether a checkbox exists. They are asking whether the company can reconstruct a decision: this person, this purpose, this notice, this moment, this action, and this later change of mind. A record that cannot answer those six things is a field, not evidence, and the distinction usually surfaces at the worst possible time.
The reason is structural. Consent is an event in time, but most systems store it as state: a boolean, a timestamp and maybe a source. State answers what is true now. Evidence answers what was true then. When a data principal says they never agreed to marketing, the company needs to show the notice they saw and the action they took, not a flag that currently reads true because an import defaulted every blank to yes.
Figure 1. Six parts make a record reconstructable; miss one and the remaining five describe an event you cannot date or scope.
This page is about building the evidence layer. It assumes you have already decided the purposes and written the notice, which is the subject of the companion DPDP guide. The narrow question here is how to record consent so that it survives an audit, a migration, a vendor change and the departure of the person who built the form.
Notice versions are the spine of the record
If the notice changes and the record only stores a pointer to the current notice, the record is retroactively rewritten every time marketing edits a sentence. The person agreed to what was on screen, not to what the page says today. The fix is to treat the notice as an immutable document with a version identifier and a publication date, and to store that identifier in the record.
Versioning does not require a content management system. A static notice with a version string, a publication date and a hash of the rendered text is enough, provided the archive is durable and the hash is computed over what the person actually saw. If the notice is rendered dynamically by plan, region or language, version each variant, because a Marathi notice for a Maharashtra customer is a different document from the English one.
Figure 2. Each consent points at the version that was live at the time; later edits create a new version rather than rewriting history.
The archive needs an owner and a rule. Every published version stays available for as long as any consent referencing it could be challenged, plus the retention period for the record itself. Store the rendered HTML, not just the source template, because a template change can alter the output. A hash without the document is a receipt for a package nobody kept.
Purposes need codes, not marketing prose
A purpose written as improving customer experience cannot be enforced by a system. A purpose code such as order-updates, cart-recovery, newsletter or product-analytics can be checked at the point where a message is queued. The code is the contract between the legal description and the workflow, and it is the difference between a policy and a control.
The registry should be small and stable. Each code has a human-readable description, the notice version that introduced it, the systems that consume it, and the retention for data processed under it. When a new workflow needs a purpose that does not exist, that is a decision for the privacy owner, not a string invented by an engineer at 11pm before a campaign.
Figure 3. The purpose code is checked at the send boundary; a workflow that cannot name its purpose cannot send.
Enforcement belongs at the send boundary. Before an email, WhatsApp template or voice call is dispatched, the system checks that the recipient has an active consent for the purpose the workflow declares. A missing code is a hard failure, not a warning that scrolls past in a log. The trace records the code and the decision, which is how the consent record and the run trace become one story.
What counts as an affirmative action
An affirmative action is something the person did on purpose. A click on a button that says subscribe is one. A pre-ticked box is not, because the person did nothing. A banner that treats continued scrolling as agreement is not, because the person was not asked. A single accept all button that covers four unrelated purposes is weak, because the action was not specific to each one.
The interface leaves a trail that can help. A form submission with the field values, the button identifier, the page URL, the referrer and the server timestamp is decent evidence. Client-side analytics alone is weaker, because it can be blocked, manipulated or lost. Capture the consent on the server as part of the same transaction that creates the contact, so the record and the relationship are born together.
Figure 4. The difference is agency: a person who did nothing did not agree, whatever the database says.
The action should be recorded in words a human can read. Store a short description such as ticked the newsletter toggle on the footer signup form, not only a numeric code. Six months later, the person reading the record may be an auditor, a support agent or a new engineer, and none of them will have the enum table memorised. Readability is part of defensibility.
Timestamp, source and the collection point
A timestamp is only useful if it is the server’s, in UTC, and stored with the record rather than derived later from a log. Two systems recording the same event can disagree by minutes, and a migration can shift everything by hours if a timezone is applied twice. Store UTC, display local time in the interface, and keep the original value immutable.
Source means where the consent came from: the landing page, the checkout, the WhatsApp opt-in flow, the call centre script, an import from a previous provider. The source determines the quality of the evidence. A consent captured on a form with a visible notice and an explicit toggle is stronger than a row imported with a note that says opted in. The record should not pretend those are equivalent.
Figure 5. Capture the page and the form alongside the action; a channel label is not enough to reconstruct what the person saw.
The collection point is the specific surface, not just the channel. Footer newsletter is a channel description. The footer of the pricing page, mobile view, with notice v3 is a collection point. Capture the URL and, where available, the form identifier. If a page is retired, the URL still tells the reader what the person was looking at, especially when combined with the archived notice.
Withdrawal is an event, not a delete
Withdrawal must be as easy as consent, and it must be recorded with the same care. The record gains a withdrawal state, a timestamp, the channel used and the scope. If the person withdraws marketing but keeps order updates, the record should show two purposes with different states, not a single contact marked as opted out. Blanket withdrawals are a UI convenience, not a data model.
The propagation problem is the real work. Withdrawal has to reach the ESP, the CRM, the WhatsApp business account, the SMS gateway, the ad platform audiences, the analytics warehouse and any agent memory that might otherwise use the preference to personalise a reply. Each system needs a documented path and a verification step. A withdrawal that reaches three of seven systems is not a withdrawal.
Figure 6. One withdrawal event, seven downstream consumers, each with a verification step and an audit entry.
The record itself must stay. Withdrawing consent does not erase the evidence that consent once existed, because the company needs to show that past processing was lawful. What changes is the state for future processing. Deleting the consent record on withdrawal destroys the audit trail and creates a second problem: the company can no longer prove it stopped when asked.
Consent, suppression and preference are not the same
Consent is a legal basis. Suppression is a deliverability and decency control: a hard bounce, a spam complaint, a role address that should never be mailed. Preference is a product setting: weekly instead of daily, Hindi instead of English, product category instead of everything. Teams collapse all three into a single opt-out flag because it is convenient, and then cannot answer basic questions about why someone is not receiving mail.
The collapse causes two failures. A suppressed address that is not legally withdrawn gets resurrected by an import that only checks the consent flag, and the next campaign mails someone who reported spam. A preference change gets treated as a withdrawal, so a customer who asked for fewer emails stops receiving order updates. Both are avoidable with three separate fields and a clear precedence rule.
Figure 7. Suppression first, then withdrawal by purpose, then preference; reversing the order is how people get mailed after complaining.
The precedence rule should be explicit and written down: suppression blocks all mail regardless of consent, withdrawal blocks the withdrawn purpose but not others, preference adjusts frequency or content within an active consent. Any system that sends must apply the rule in that order. Put it in the send boundary, not in a document that campaign managers are expected to remember.
How long to keep the record, and what to keep
The consent record has a longer life than the marketing list. A contact who unsubscribed five years ago may still be the subject of a complaint about a message sent three years ago, and the company needs the record of what was agreed at that time. Retention for the evidence should be set by the limitation period for claims in your jurisdiction and by your contracts, not by the campaign calendar.
Minimisation still applies. Keep the fields needed to prove the decision: identifier, purpose, notice version, action, timestamp, source, withdrawal state and the system of record. Do not keep the full form payload if it contains unrelated data, and do not keep the raw request body for years because it was convenient. The record should be a compact evidence object, not an archive of everything the person ever typed.
Figure 8. Illustrative sample of a retention ladder; the consent record outlives the campaign data it authorised.
Anonymising the record is usually the wrong move, because a consent record that cannot be linked to a person cannot prove anything about that person. The compromise is to keep the identifier and the evidence, restrict access to a small group, encrypt at rest, and delete the surrounding payload. If the identifier must be removed after a period, record that the anonymisation happened and keep the aggregate, but understand that the evidentiary value drops sharply.
Voice, WhatsApp and the consent that is easy to miss
A voice agent needs a notice at the start of the call, before it records or transcribes anything. The record should show that the notice played, at what point, and what the caller did next. If the caller objected and the call continued without recording, that is a different record from one where the caller agreed. The audio, the transcript and the consent event are three separate artefacts with three retention rules.
WhatsApp opt-in is its own regime on top of DPDP. Meta’s policies require an opt-in before a business initiates a marketing template, and the opt-in has to be recorded in a way the business can produce. A phone number imported from a website form is not automatically a WhatsApp opt-in unless the form said so and the person agreed to receive messages on WhatsApp. The channel matters, and the record should name it.
Figure 9. Four channels, three overlapping regimes; one boolean cannot represent all of them.
SMS adds a third layer through the DLT framework administered by TRAI, where sender IDs, headers and templates are registered and consent is recorded against a template. DLT consent is not a substitute for DPDP consent, and DPDP consent does not satisfy DLT registration. A team running all three channels needs a consent model that records the channel, the regime and the template or purpose, rather than a single boolean that means different things in different systems.
Testing the record before someone else does
A record model is a hypothesis until it is tested. The useful test is small and repeatable: sample fifty recent contacts across at least three sources, and try to reconstruct each consent without looking at the live page. For each one, answer five questions: what notice did they see, what purpose did they agree to, what action did they take, when and where, and has anything changed since. A failure rate above a handful is a design problem, not a training problem.
Then test withdrawal five times, through five different paths: the preference centre, the unsubscribe link, a support request, an API call and a WhatsApp stop keyword. Time each one and check propagation to every downstream system within the documented window. The interesting result is rarely the headline path; it is the support request that lands in a shared inbox and never reaches the consent store.
Figure 10. Fifty records, five withdrawal paths, one restore drill; each finds a different class of failure.
Finally, test a restore. Take a backup from before a withdrawal, restore it into a staging environment, and confirm that the deletion and withdrawal states are reapplied rather than lost. This is the test most teams fail, because the backup predates the event by design. If a restore silently reactivates withdrawn contacts, the backup is a compliance incident waiting for a disaster.
Failure modes that keep coming back
The first is the default that means yes. An import maps a blank column to subscribed, a CSV from a previous provider has no consent column, and the migration fills the gap with the most commercially useful value. The second is the single timestamp, overwritten on every update, so the record shows when the contact was last touched rather than when consent was given. The third is the notice link that points at the current page, which means the record now cites a document the person never saw.
The fourth is withdrawal that only stops email. The contact keeps receiving WhatsApp templates because the preference centre does not know about the messaging system, and the support agent who took the request had no way to propagate it. The fifth is the agency or reseller that collects consent under its own notice and transfers a list without the notice version, leaving the brand unable to show what the person agreed to.
Figure 11. Purpose-level state with a notice version and a withdrawal history; the record is only as good as the fields it keeps.
The sixth is agent memory. A workflow stores a preference in a vector index, the person withdraws, the source record updates, and the index keeps returning the old preference for months. The fix is to treat the index as a downstream consumer with a deletion job and a rebuild rule, not as a cache that will catch up on its own. Every one of these failures is boring, and every one of them is visible in a test that takes a day.
Frequently asked questions
Is a checkbox value in our CRM enough?
No. A checkbox tells you the current state, not the event. You need the notice version the person saw, the purpose, the action, the server timestamp, the collection point and the withdrawal history. The checkbox can be one field in that record, but on its own it cannot answer the question an auditor will actually ask.
Should we delete consent records when someone withdraws?
No. Withdrawal changes the state for future processing; it does not erase the fact that consent existed when the data was used. Deleting the record destroys your ability to show that past processing was lawful and that you honoured the withdrawal from that point. Keep the record, mark the state, and delete the underlying marketing data as required.
How do we prove what notice someone saw?
Publish the notice as an immutable, versioned document, compute a hash of the rendered text, and store the version identifier and hash in the consent record. Keep an archive of rendered versions, not just templates, because a template change can alter what the person saw. If the notice varies by language or plan, version each variant separately.
What is the difference between consent and suppression?
Consent is the legal basis for processing. Suppression is an operational block, usually triggered by a hard bounce or a spam complaint, that stops mail regardless of consent. Preference is a product setting for frequency or content. Keep them as three separate fields with a clear precedence rule, or imports and support requests will keep resurrecting the wrong people.
Do we need a separate opt-in for WhatsApp?
Yes, in practice. Meta’s policies require an opt-in before a business initiates a marketing template, and the business has to be able to produce it. A phone number collected for email is not a WhatsApp opt-in. Record the channel, the wording the person agreed to and the time, and keep that record available for as long as you send on the channel.
Does DLT consent satisfy DPDP?
No. DLT is TRAI’s framework for registered senders, headers and templates on SMS, and its consent records serve that regime. DPDP consent is a separate obligation with its own notice and purpose requirements. Running SMS means satisfying both, and your consent model should record the regime as well as the channel.
How long should a consent record be kept?
Longer than the campaign data it authorised. Set the period with the people who own legal and contracts, based on the limitation period for claims and your sector obligations. Keep a compact evidence object rather than the full form payload, restrict access, and document the retention rule so that a reviewer can see it was a decision rather than an accident.
What should we test first?
Withdrawal propagation. Pick five contacts, withdraw through five different paths, and check every system that could send or personalise a message. Most teams find at least one path that never reaches the consent store, usually a support request or an agency-managed channel. Fixing that is more valuable than another policy document.
Can an agency collect consent on our behalf?
Yes, but the brand remains responsible for the basis. The agency should use your notice or a notice you have approved, record the version and the collection point, and transfer the evidence with the list. A list handed over with a note that says opted in is not a consent record, and the brand will be the one asked to defend it.
