The 7 Requirements of Valid Consent Under the DPDP Act

Consent is the engine of the DPDP Act — and the place where most Indian organisations are non-compliant today without realising it. The Act doesn't just require consent; it defines precisely what consent must look like. Miss one element and the consent is void, making the processing itself unlawful. Here are the seven requirements, with real-world pass/fail examples.

1. Free

Consent must be given without coercion, pressure or imbalance being exploited. Fails: "Accept all data uses or you cannot enter the premises." Passes: a genuine choice where refusing non-essential processing doesn't block the core service.

2. Specific

Consent attaches to a specified purpose. One blanket consent covering "services, marketing, analytics, partners and improvements" is not specific — each materially different purpose needs its own consent. Fails: a single checkbox for delivery and marketing and data sharing. Passes: separate, per-purpose choices.

3. Informed

Consent must follow a notice that tells the principal, in clear and plain language: what personal data is collected, the purpose of processing, how to exercise rights, and how to complain to the Board. The notice must be understandable on its own — not buried in a 40-page terms document — and available in English or any of the 22 Eighth Schedule languages.

4. Unconditional

Access to goods or services cannot be conditioned on consent to processing that isn't necessary for that service. Fails: a food delivery app refusing to work unless you consent to sharing data with "marketing partners". Passes: delivery requires your address (necessary); promotional profiling is a separate, refusable ask.

5. Unambiguous, with clear affirmative action

Silence, inactivity, pre-ticked boxes and "by continuing you agree" banners are all invalid. The principal must do something — tick, click, sign, state — that unambiguously signals agreement. Audit your forms today: every pre-ticked box on a lead form, admission form or app signup is a live violation.

6. Limited to necessary data

Consent covers only personal data necessary for the specified purpose. Collecting extra fields "while we're at it" — date of birth for a newsletter, Aadhaar for a gym membership — exceeds the consent even if the form was otherwise compliant. Data minimisation is baked into consent validity.

7. Withdrawable — as easily as it was given

The principal may withdraw consent at any time, and the ease of withdrawal must match the ease of giving. If signup was one click, withdrawal cannot be a phone call, an email to legal and a 30-day wait. On withdrawal, you (and your processors) must stop processing and erase within a reasonable time, unless retention is legally required — withdrawal must propagate to every downstream system.

The evidence requirement behind all seven

When a complaint reaches the Data Protection Board, the burden is effectively yours: prove this person consented, to this purpose, after this notice, on this date. That demands consent records — who, when, which notice version, which purposes, and every subsequent change or withdrawal — retained in tamper-evident form. A consent your systems cannot evidence is, for regulatory purposes, a consent that doesn't exist.

Fixing consent in practice

  1. Inventory every point where you collect personal data — web forms, apps, paper-to-digital, call centres, walk-ins.
  2. Rewrite notices: plain language, itemised purposes, rights information, language options.
  3. Unbundle: one purpose, one consent; remove every pre-ticked box.
  4. Build the consent register: evidence for every grant, change and withdrawal.
  5. Wire withdrawal to actually stop processing — including at your vendors.

This is precisely what a consent management platform automates. Privonta Shield's consent module generates compliant notices, captures per-purpose consent with evidence, and propagates withdrawal — so validity is engineered in, not audited after.

What a compliant notice actually contains

Consent is only as valid as the notice that precedes it. Under the Act and Rules, the notice must be a standalone document, understandable on its own, in clear and plain language, and must set out:

  • the personal data to be collected, itemised — not "information about you";
  • the purpose of processing, described specifically enough that the principal knows what will happen;
  • how the principal may exercise their rights, including withdrawal of consent;
  • how to make a complaint to the Data Protection Board;
  • the contact details of the DPO or other person able to answer questions about the processing;
  • a link or means to access the notice in English or any of the 22 Eighth Schedule languages.

A notice buried inside 40 pages of terms and conditions does not satisfy this, even if every element is technically present somewhere in the document.

Consent already collected: does it still work?

This is the question that decides how much work you face. Consent obtained before the Act's obligations bite does not automatically become valid — where you relied on consent that would not meet the Act's standard, the Act contemplates giving data principals a fresh, compliant notice so they can make an informed choice about continued processing.

Practically, that means auditing your existing consent base and sorting it into three buckets: consent that already meets the standard and can be evidenced (keep, with records intact); consent that is defective but where processing can continue under a legitimate use such as employment purposes or legal compliance (re-map the basis, stop calling it consent); and consent that is defective with no alternative basis (serve a fresh notice and re-obtain, or stop the processing). Most organisations discover their marketing database sits squarely in the third bucket.

A consent audit you can run this month

  1. List every collection point. Website forms, mobile app screens, admission and onboarding forms, call-centre scripts, walk-in registers later digitised, QR-code campaigns, event sign-ups, chatbots.
  2. For each, capture three things: what fields are collected, what purposes the data is actually used for, and what the person was told.
  3. Flag the gaps. Any purpose in column two that is missing from column three is processing without informed consent. Any field collected that no purpose needs is a minimisation failure.
  4. Check the mechanics. Pre-ticked boxes, bundled checkboxes, implied consent from continued use, and consent as a condition of unrelated service — each is an invalidity.
  5. Test withdrawal. Try to withdraw consent as an ordinary user. If it takes more effort than signing up did, or if processing continues afterwards, you have found a live violation.

Step 5 is where most audits produce their sharpest findings, because withdrawal is the requirement organisations design last and test never.

Frequently asked questions

What are the requirements for valid consent under the DPDP Act?
Consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, limited to data necessary for the specified purpose — and as easy to withdraw as it was to give.
Are pre-ticked boxes valid consent under the DPDP Act?
No. Consent requires a clear affirmative action by the data principal. Pre-ticked boxes, silence, inactivity and 'by continuing you agree' mechanisms do not constitute valid consent.
What happens when a user withdraws consent?
The fiduciary and its processors must stop processing the personal data and erase it within a reasonable time, unless retention is required by law. Withdrawal must be as easy as giving consent and must propagate to downstream systems and vendors.
Privonta Shield helps Companies, Government, SMEs and Education Institutes meet every DPDP obligation — data discovery, consent management, rights workflows and audit trails, deployed inside your own boundary. Book a free DPDP assessment →

Ready to become DPDP compliant?

Get a personalised compliance assessment — free, no obligation.

Book a Free Assessment →