Proving Consent Under the DPDP Act: What Your Consent Records Must Show

Most teams think of consent as a moment: the person ticks a box and the job is done. The DPDP Act treats it as evidence. Under Section 6(10), if a Data Principal disputes their consent, the Data Fiduciary has to prove that a notice was given and that consent was obtained. If you cannot prove it, you are, in practice, processing personal data without a valid basis.

This guide covers what that burden of proof means for your systems, what a defensible consent record contains, why refusals and withdrawals must be recorded as carefully as agreements, and a checklist to work through before the notice and consent obligations begin on 13 May 2027. It is the companion to our guide on DPDP granular consent: once consent is purpose by purpose, the proof has to be purpose by purpose too.

What Section 6(10) actually says

Section 6(10) of the DPDP Act applies where consent is the basis for processing. If a question arises in any proceeding about that consent, the Data Fiduciary is obliged to prove that a notice was given to the Data Principal and that consent was given in accordance with the Act and the Rules.

Two things follow. First, the proof covers both the notice and the consent. Showing that someone clicked "I agree" is not enough if you cannot show what they were told when they clicked. Second, the consent has to be shown to meet the Act's standard: free, specific, informed, unconditional and unambiguous, given by a clear affirmative action (Section 6(1)). Your record has to carry enough context to show that, not just that a click happened.

Why a checkbox value is not proof

Here is how consent usually lives in a product database:

What most systems store	What a dispute will ask
marketing_opt_in = true	Which purposes, exactly? Was marketing email bundled with WhatsApp and partner sharing?
updated_at on the user row	When was consent given, and has it changed since? updated_at moves every time anything on the row changes.
Nothing	Which notice, in which version and language, was shown at that moment?
Nothing	Where was consent collected: which form, page, app screen or offline channel?
Nothing	Was the box pre-ticked, or did the person tick it?
The current value only	Did the person withdraw and later opt in again? What happened in between?

A single mutable field answers none of these. It records the current state. What Section 6(10) asks for is the history of events that produced that state.

What a defensible consent record contains

Think of each consent as an event written to a log, not a value overwritten in a table. At minimum, each event should capture:

1. Who. An identifier for the Data Principal. Store the minimum you need: a hashed email or phone number, or an internal ID, rather than a copy of their profile.
2. Which notice. The version of the notice shown, and the language it was shown in. Rule 3 of the DPDP Rules, 2025 requires an itemised notice, so you need to be able to reproduce what that notice said on that day.
3. Which purposes, and the answer for each. Every purpose presented, marked accepted or declined. Not only the ones that were accepted.
4. When. A server-side timestamp in a known timezone. Do not rely on the client's clock.
5. Where. The collection point: the URL or form, the app screen, or the offline channel such as a branch or a call centre.
6. How. The affirmative action: an unticked box that was ticked, a button pressed, an OTP confirmed. If you verified the identifier, record that too.
7. What happened next. Later events for the same person and purpose: modification, renewal, withdrawal, expiry.

If you already publish an itemised notice under Rule 3 (see our Rule 3 notice guide), the hard part is usually the second item. Notices get edited in a CMS, and nobody keeps the old text. Version your notices, never overwrite a published version, and stamp the version on every consent event.

Record the "no" as carefully as the "yes"

Granular consent means some people will accept order updates and decline promotional email. Many systems only write a record when something is accepted. That leaves a gap: if a declined purpose is processed later by mistake, you have nothing that shows the person was asked and said no, and nothing that tells downstream systems to stay away.

Record every purpose that was presented, with its outcome. A refusal is evidence that your form offered a real choice, which is part of showing that consent was free and specific. It is also the signal your marketing and analytics tools need to respect.

Withdrawal is an event, not a delete

Section 6(4) gives the Data Principal the right to withdraw consent at any time, with the ease of doing so comparable to the ease with which consent was given. Section 6(6) then requires the Data Fiduciary to stop processing that personal data within a reasonable time, and to cause its Data Processors to stop as well, unless processing without consent is required or authorised under the Act, the Rules or any other law in force in India.

Two design consequences follow:

• Withdrawal must reach every system that acted on the consent. If consent fed your email platform, CRM and ad audiences, the withdrawal has to reach all three. Record when each was told.
• Do not delete the consent history when consent is withdrawn. If you erase the record, you also erase your proof that you asked properly in the first place and that you stopped when told to. Section 8(7) requires you to erase the personal data, and have your Data Processors erase it, once consent is withdrawn or the purpose is no longer served, unless retention is necessary for compliance with law. Keeping a minimal, pseudonymised record of the consent events for the purpose of demonstrating compliance is a different question from keeping the underlying data. Settle the exact retention period for these records with counsel.

Make records append-only

Evidence that can be silently edited is weak evidence. Design the consent log so that events are only ever added:

• A change of mind is a new event, not an update to the old one.
• Application code should not have update or delete rights on the consent log. Enforce this in the database, not only in code review.
• Corrections, for example after a data-entry error in an offline channel, are new events that reference the original and say why.
• Administrative actions on consent data (exports, imports, manual entries) go in an audit log with the actor and time.

What about consent collected before the Act?

Section 5(2) requires a Data Fiduciary that processes personal data on the basis of consent given before the Act commenced to give those Data Principals a notice as soon as reasonably practicable. Most legacy consents also fail the evidence test: there is no notice version, no purpose breakdown, and often only a boolean.

Treat re-notice as the moment to collect consent the right way, purpose by purpose, with a proper record. Do not backfill old rows with invented notice versions or purposes to make them look complete. A record that claims more than you actually know is worse than an honest gap.

Checklist: consent evidence before 13 May 2027

1. List every place consent is collected: web forms, apps, checkout, in-store, call centre, partner channels.
2. For each one, check you can answer who, which notice, which purposes, when, where and how, for a consent given yesterday.
3. Version every notice and keep every published version, in every language you show it in.
4. Record declined purposes, not only accepted ones.
5. Move consent from a mutable field to an append-only event log. Remove update and delete rights on it.
6. Make withdrawal as easy as consent, and record when each downstream system was told to stop.
7. Decide, with counsel, how long consent evidence is kept after withdrawal or account deletion.
8. Run a drill: pick a real customer and produce their full consent history, with the exact notice text they saw, in under an hour.

For the dates behind this checklist, see why 13 November 2026 is not your deadline and our month-by-month DPDP deadline calendar.

How Consently records consent

Consently is a DPDP-native consent management platform. Each consent is recorded per processing activity and per purpose, including purposes the person declined. When you publish versioned notices, each consent is stamped with the notice version and language that applied. The Data Principal's email identifier is stored hashed, and each person gets a Consent ID that carries no personal data.

Records are append-only: modifications, renewals and withdrawals are added as new events rather than overwriting old ones. Data Principals can review, update or withdraw consent from a preference centre after verifying with an OTP, and administrative actions are written to an audit log you can export. Consently is a platform that Data Fiduciaries use to manage consent. It is not a registered Consent Manager under Section 6(9). To see what your consent evidence would look like, book a demo.

Frequently asked questions

Who has to prove consent under the DPDP Act?

The Data Fiduciary. Section 6(10) says that where a question arises in a proceeding about consent, the Data Fiduciary must prove that a notice was given and that consent was given in accordance with the Act and the Rules.

Is a timestamp and a checkbox value enough to prove consent?

Usually not. You also need to show which notice the person saw, which purposes they were asked about and how they answered each, where consent was collected, and that it was given by a clear affirmative action rather than a pre-ticked box.

Should I delete consent records when someone withdraws consent?

You must stop processing and, under Section 8(7), erase the personal data unless the law requires you to keep it. The record of the consent events is what shows you asked properly and stopped when told, so many organisations keep a minimal, pseudonymised version of it. Agree the retention period with counsel.

Do I need to record when someone declines a purpose?

Yes. A recorded refusal shows your form offered a genuine choice and tells downstream systems not to process data for that purpose. Without it, an accidental use of a declined purpose leaves you with no evidence either way.

When does the burden of proof start to apply?

Section 6 and the Rule 3 notice requirements apply from 13 May 2027 under the phased commencement of the DPDP Rules, 2025. Consents you collect before then will still need to be defensible afterwards, so it is worth recording them properly now.

This article is for general information and is not legal advice. Please consult a qualified lawyer for advice on your specific situation.