← Back to Blog

What Valid Consent Means Under DPDPA (And Why Most Companies Get It Wrong)

Under the Digital Personal Data Protection Act, 2023 (DPDPA), consent is the default legal basis for processing personal data unless a specific legitimate ground applies. For most organizations, that means daily data processing depends on whether consent under the DPDPA is valid.

This is often a challenging area for teams, because the law’s bar for valid consent is much higher than a checkbox. And once systems are live, most teams stop looking at consent entirely. This blog isn’t about UI patterns or legal theory but about what the law expects in real operations and why consent failures quietly pile up until an audit.

Legal Definition of Valid Consent Under DPDPA

Section 6(1) of the Act answers a simple question: What is meant by valid consent?

The answer comes with six non-negotiable conditions:

  • Free –  no pressure, no dark patterns, no forcing users to consent to get unrelated services.
  • Specific – consent must relate to a clearly stated purpose. “Agree to all” doesn’t qualify, no matter how common it is.
  • Informed – before consent is taken, users must see a clear notice explaining what personal data under the DPDP Act is collected, why it’s collected, how long it’s kept, and who sees it.
  • Unconditional – consent cannot be bundled with contracts or hidden inside other agreements.
  • Unambiguous – consent must be expressed through a clear affirmative action. Passive actions, such as silence, scrolling, or pre-selected checkboxes are not considered valid consent.
  • Withdrawable – users must be able to withdraw consent as easily as they gave it.

    Many teams remember this using the FISU-UW checklist – Free, Informed, Specific, Unconditional, Unambiguous, Withdrawable. Failure to meet any one requirement results in invalid consent.

Consent is limited to the stated purpose and only covers what is necessary. Collecting more than that makes the consent invalid, even if the user clicked “yes.”

Practical Requirements That Often Get Misunderstood

This is where teams most commonly face challenges.

First, consent must always follow the notice. Always. Asking for consent before showing a compliant notice invalidates any user response.

Second, affirmative action must be real. If it is buried in terms and conditions, bundled with unrelated approvals, or obtained through default settings, it will not be considered valid. During audits, this is often the point where teams realize past practices do not meet the required standard.

Third, withdrawal has to actually work. If withdrawing consent requires an email, a support ticket, or a login maze, it fails the test. If giving consent took one click, withdrawal should take one click too.

Finally, you must be able to prove it. The data fiduciary carries the burden and a timestamp alone is not enough. Records must show how consent met all six requirements — purpose, notice, method, and withdrawal path. This is why consent keeps showing up in failed DPDPA compliance checklists.

Why Most Companies Get It Wrong

Most consent failures aren’t malicious. 

Teams assume accepting terms equals consent. They treat consent as blanket permission instead of purpose-specific approval. Notices are written for lawyers, not users. Withdrawal is made inconvenient and quietly forgotten. Language accessibility is ignored, even though the rules are explicit about plain language.

None of this looks serious — until someone asks for proof.

Most consent failures are not intentional, they’re careless. Teams often assume that accepting terms counts as consent or treat it as blanket permission rather than purpose-specific approval. Notices are frequently drafted for legal compliance rather than user understanding, and withdrawal mechanisms are inconvenient or neglected. Language accessibility is often ignored, even though the rules require plain language. These problems may seem small until proof of valid consent is needed

Special Cases and Enhanced Consent

Some cases require extra discipline. For children, the Act requires verifiable parental consent, so teams must know the age of consent under the DPDPA and document how parental consent is obtained, rather than assuming it has been given. For persons with disabilities, consent may need to come from lawful guardians, with verification records in place. The Act also allows the use of a Consent Manager under the DPDP Act, but this does not shift responsibility. If consent is invalid, the fiduciary still answers for it.

What to Do Next

Valid consent under the DPDPA is not just a design choice; it is an operational requirement. Rebuild consent flows so that every requirement is met, recorded, and testable, and ensure that notices are clear and consent is given through affirmative action. Make withdrawal straightforward, and review records regularly to maintain compliance.

Download Your DPDPA Compliance Checklist today: https://lp.xyberu.com/