Readiness assessment

DPDP Guide · Consent

How to Prove Consent Under the DPDP Act

Under the DPDP Act the burden of proving valid consent sits on you, the Data Fiduciary. This guide sets out exactly what evidence you need to keep, and how to keep it.

In short

Under Section 6(10) of the DPDP Act, if a question arises, the Data Fiduciary must prove that a valid notice was given and valid consent was obtained. To meet that burden you keep a consent record that ties each individual to the exact notice they saw, the specified purpose, the affirmative action they took, and a timestamp, plus a record of any later withdrawal. A database flag saying "consent = true" is not proof; the reconstructable record is.

Who has to prove what

Consent under the DPDP Act is not something the individual has to disprove. Section 6(10) reverses the usual intuition: where a question arises about whether consent was validly given, the Data Fiduciary carries the burden of showing that it was. That means the design goal is not just to collect consent, but to be able to reconstruct it later, on demand, for a specific person and a specific point in time.

The law

Section 6(10): the Data Fiduciary must be able to demonstrate that notice was given and consent was obtained in accordance with the Act. Section 5 governs the notice; Section 6 governs the consent itself.

What a defensible consent record contains

A record that will actually hold up ties five things together for each consent event:

  • Identity link. Which individual gave the consent, referenced in a way you can match later.
  • The exact notice shown. Not "a notice", but the specific version and wording the individual saw, including the itemised data and specified purpose.
  • The purpose. The specific purpose consented to, stored separately so you can show consent was purpose-specific and not bundled.
  • The affirmative action. What the individual actually did, the tick, toggle or tap, captured as an event rather than inferred.
  • Timestamp and context. When it happened, and enough context (interface, channel) to place it.
Practice

Version your notices. If you cannot say which wording a given user saw on a given date, you cannot prove informed consent, because the notice is what made the consent informed. A consent log that points at a versioned notice library is the cleanest way to satisfy this.

Withdrawal is part of the proof

Consent is not a one-time capture; it is a lifecycle. The same record has to show when consent was withdrawn and that processing which relied on it stopped. If you can prove consent was given but cannot show what happened after a withdrawal request, you have an evidence gap exactly where disputes tend to arise. See the consent withdrawal guide for the operational side.

What does not count as proof

  • A boolean flag. "consent = true" in a user table records a conclusion, not the evidence behind it.
  • The current privacy policy. It does not show what a specific user saw on a specific date.
  • An unversioned notice. If the wording has changed since, you cannot prove what was actually presented.
  • Bundled consent. One agreement covering many purposes cannot prove purpose-specific consent for any of them.
Risk

The failure mode is discovering, only when a question is raised, that your systems recorded the outcome of consent but not the proof of it. By then the notice wording may have changed and the trail is gone.

How to build for provability

  • Keep a versioned notice library and reference the version ID in every consent event.
  • Log consent as immutable events (given, denied, withdrawn) rather than overwriting a single field.
  • Store the purpose alongside each event so purpose-specificity is provable.
  • Make the record retrievable per individual, since that is how a question will be posed.
  • Test it: pick a random user and try to reconstruct exactly what they saw and agreed to. If you cannot, neither can you prove it.

Proving consent: frequently asked questions

Who has to prove consent under the DPDP Act?

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

Is a "consent = true" flag enough?

No. A boolean flag records a conclusion, not the evidence. To prove consent you need a record tying the individual to the exact notice they saw, the specified purpose, the affirmative action they took, and a timestamp.

Why do I need to version my notices?

Because consent must be informed, and the notice is what informs it. If your notice wording has changed, you must be able to show which version a given individual saw on a given date, or you cannot prove informed consent.

How long should I keep consent records?

Keep them for as long as you rely on that consent and for as long as you may need to demonstrate compliance, aligned with your retention policy. The practical test is whether you can still reconstruct the consent if a question arises later.

Does proof of consent include withdrawal?

Yes. A complete record shows when consent was given and, if applicable, when it was withdrawn and that the processing relying on it stopped. Withdrawal handling is part of the evidence trail.

Sources

  • Digital Personal Data Protection Act, 2023, Sections 5 and 6, including Section 6(10).
  • Digital Personal Data Protection Rules, 2025, Rule 3 (notice).

General information about the DPDP Act and Rules, not legal advice, and not affiliated with any government body.