# DPDP consent and the nine legitimate uses

Source: https://dpdp.d2c.in/guides/dpdp-consent/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs

**Short answer:** Under the DPDP Act you may process personal data only for a lawful purpose, with consent (section 6) or for one of the nine legitimate uses in section 7. Consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and as easy to withdraw as to give. These provisions apply from 13 May 2027, and the burden of proving consent is on you (s.6(10)).

## Key takeaways

- Every processing activity needs a lawful purpose plus consent or one of the nine section 7 legitimate uses.
- There is no legitimate interests ground, so anything outside section 7 needs consent.
- Withdrawal must be as easy as giving consent; stop processing within a reasonable time and make processors stop.
- Section 6(10) puts the burden of proving notice and consent on the fiduciary: keep a consent ledger.
- Bundled consent, pre-ticked boxes and “by continuing you agree” are unlikely to pass the section 6(1) tests.

Consent is where DPDP compliance becomes visible to your users. It is also where much current practice falls short: a single checkbox that accepts the terms, the privacy policy and marketing messages at once will not survive the section 6(1) tests. The good news is that the Act gives you a closed list of situations where you do not need consent at all, and a clear standard for when you do.

This guide covers both grounds, how withdrawal works, what you must be able to prove, and how to build a consent record that will stand up if the Data Protection Board asks. Sections 6(1) to 6(8), 6(10) and 7 apply from 13 May 2027.

## Consent or legitimate use: which ground applies?

Section 4 allows processing only for a lawful purpose, and only on one of two grounds: the person's consent, or a legitimate use under section 7. Start every processing activity in your data map with one question: does this fit one of the nine legitimate uses? If it does, record which one and why. If it does not, you need consent, with a notice that meets [section 5 and Rule 3](https://dpdp.d2c.in/guides/dpdp-privacy-notice/).

## What makes consent valid under the DPDP Act?

Section 6(1) sets the standard. Consent must be free, specific, informed, unconditional and unambiguous, signify agreement through a clear affirmative action, and be limited to the personal data necessary for the specified purpose. Each word maps to a design test you can run on your own screens.

 ✓**Free**The person can say no without a penalty or pressure. Refusing marketing should not degrade the core service.

s.6(1)
 ✓**Specific**One consent per purpose. “To improve our services” covers nothing specific.

s.6(1)
 ✓**Informed**Given after an itemised notice, in English or an Eighth Schedule language the person reads.

s.5, s.6(3)
 ✓**Unconditional**Access to the service is not tied to agreeing to processing it does not need.

s.6(1)
 ✓**Unambiguous, by clear affirmative action**A tap, a tick or a typed reply. Silence, scrolling and pre-ticked boxes are not actions.

s.6(1)
 ✓**Limited to necessary data**Ask only for the data items the purpose needs. Extra fields mean the consent covers more than it should.

s.6(1)

Section 6(3) adds that every consent request must be in clear and plain language, offered in English or any Eighth Schedule language, and carry the contact details of your DPO or the person who answers questions. If you process children's data, consent comes from a parent or lawful guardian and must be verifiable; see our [children's data guide](https://dpdp.d2c.in/guides/dpdp-children-data/).

## What are the legitimate uses under section 7?

Section 7 is a complete list. If a use is not on it, it is not a legitimate use. Most private companies will rely mainly on clause (a), clause (i) for staff data, and the clauses on legal obligations and court orders.

| Clause | Legitimate use | Practical example | Watch-out |
|---|---|---|---|
| 7(a) | A specified purpose for which the person voluntarily provided the data, where she has not indicated she does not consent | A customer gives her mobile number at a store counter to receive the bill by SMS; you send the bill | Only that purpose. Sending her offers later needs consent. |
| 7(b) | The State providing subsidies, benefits, services, certificates, licences or permits | A government department using data it holds to issue a licence or a benefit | Relevant to private firms mainly when acting for the State. |
| 7(c) | The State performing functions under law, or in the interest of sovereignty and security | A State agency processing data for a function a statute gives it | Not a ground a private business can rely on for its own purposes. |
| 7(d) | Fulfilling a legal obligation to disclose information to the State | Responding to a statutory requisition from a government authority | Disclose what the law requires, no more. Log the request. |
| 7(e) | Complying with a judgment, decree or order | Producing customer records in response to a court order | Keep a copy of the order with the disclosure record. |
| 7(f) | Responding to a medical emergency involving a threat to life or immediate threat to health | A hospital treating an unconscious patient; an employer sharing a staff member's details with paramedics | Limited to the emergency. Ordinary follow-up care is a separate question. |
| 7(g) | Medical treatment or health services during an epidemic or other threat to public health | A clinic contacting patients for treatment during an outbreak | Tied to the public health threat, and ends with it. |
| 7(h) | Safety of, or assistance to, any individual during a disaster or breakdown of public order | Locating employees during a flood and arranging evacuation | Use the data for safety, then stop. |
| 7(i) | Employment purposes, or protecting the employer from loss or liability (such as espionage, trade secrets, IP, classified information) or providing a service or benefit the employee asks for | Payroll, attendance, access control, data loss prevention on work devices, enrolling an employee in a health plan she asked for | Employment purposes only. Marketing to staff or sharing for unrelated uses needs consent. |

Write your chosen clause into the record of processing for each activity, with a one-line reason. Clause (a) in particular depends on facts you need to show later: that the person provided the data voluntarily, for a purpose she understood, and has not objected.

### Is there a legitimate interests ground in the DPDP Act?

No. Teams with GDPR programmes often expect to carry over legitimate interests assessments for analytics, fraud scoring or direct marketing. The DPDP Act has no equivalent. If an activity does not fit one of the nine clauses above, it needs consent. This is one of the biggest practical differences covered in our [DPDP vs GDPR comparison](https://dpdp.d2c.in/guides/dpdp-vs-gdpr/), and it usually means more consent prompts, not fewer, for consumer businesses.

Common gapProduct analytics and personalised recommendations are often treated as “necessary to run the service”. Test that claim honestly. If the service works without them, put them behind their own consent toggle.

## How does withdrawal of consent work?

Section 6(4) lets a person withdraw consent at any time, and the ease of withdrawal must be comparable to the ease of giving it. If consent took one tap in the app, withdrawal cannot require an email to a support address and a ten-day wait.

What follows a withdrawal:

- **Past processing stays lawful.** Section 6(5) says withdrawal does not affect processing based on consent before it.

- **Stop within a reasonable time.** Under section 6(6) you, and every processor working for you, must cease processing for that purpose within a reasonable time.

- **Erase unless the law says keep.** Section 8(7) requires erasure once consent is withdrawn, and you must make your processors erase too, unless retention is required by law.

- **Logs follow their own rule.** Rule 8(3) requires every fiduciary to keep personal data, associated traffic data and processing logs for at least one year from processing. Our [data retention guide](https://dpdp.d2c.in/guides/dpdp-data-retention/) covers how to reconcile that with erasure.

- **Consequences are the person's to bear.** If withdrawing consent means a feature stops working, say so in plain terms, but do not use that as pressure.

Engineering the “stop” is the hard part. Withdrawal has to propagate to every system that uses the data for that purpose: the CRM, the marketing platform, the analytics warehouse and each vendor. Build it as an event that each system subscribes to, with a confirmation back to the ledger.

## Who has to prove consent, and what should a consent record hold?

Section 6(10) places the burden of proof on you. In any proceeding, you must show that notice was given and consent was obtained in line with the Act. A row in a database saying marketing_opt_in = true will not do that. You need a record of what the person saw, what she did, and when.

| Field | Why you need it |
|---|---|
| Data Principal reference (internal ID, not raw email or phone) | Links the record to the person without spreading identifiers |
| Purpose ID and data items covered | Shows consent was specific and limited to necessary data |
| Notice version and language shown | Proves the person was informed (s.5, s.6(10)) |
| Action: given, denied or withdrawn | Records the clear affirmative action, and refusals too |
| Timestamp and time zone | Orders events; shows what was valid on a given date |
| Channel and surface (web, app screen, call centre, paper form) | Lets you reproduce exactly what the person saw |
| App or site build version | Ties the event to the UI as it was then |
| Consent manager reference, if any | Needed where consent arrives through a registered consent manager |
| Propagation status to processors | Shows that withdrawal reached every processor (s.6(6)) |

Design the ledger as append-only. Never overwrite a consent with a withdrawal; add a new event. Hash-chaining entries, or writing them to storage that cannot be edited, makes the record much harder to challenge. Keep the published notice texts alongside it, in every language version.

## What are the bundled consent pitfalls?

Most failures we see during assessments come from a few patterns:

- **Terms acceptance as consent.** One box for “I agree to the Terms, Privacy Policy and to receive offers”. That bundles a contract with several consents and fails the specific test.

- **Service held hostage.** Sign-up blocked unless the user agrees to share data with partners. Consent must be unconditional.

- **Pre-ticked boxes and default-on toggles.** Not a clear affirmative action.

- **“By continuing, you agree.”** Browsing is not consent.

- **Purpose creep.** Data collected for delivery reused for profiling without a fresh request.

- **Hard exits.** Opt-in in one tap, opt-out by emailing a grievance address. Fails section 6(4).

## Where do consent managers fit?

Sections 6(7) to 6(9) let a person give, manage, review and withdraw consent through a consent manager registered with the Board. Rule 4, on registering consent managers, applies from 13 November 2026, but no consent manager has been registered yet. Plan your ledger so it can accept consents arriving through one later, and read our [consent manager guide](https://dpdp.d2c.in/guides/dpdp-consent-manager/) for the model.

## How to implement this

- **Classify every activity.** In your data map, mark each processing activity as consent or a named section 7 clause, with a reason.

- **Unbundle.** Split terms acceptance from consent, and split consent by purpose.

- **Rebuild consent screens** with itemised notices, purpose toggles and equal accept and reject options.

- **Build the ledger** with the fields above, append-only, linked to stored notice versions.

- **Wire withdrawal** as an event that reaches every internal system and processor, with confirmations.

- **Re-paper existing consents** with the section 5(2) notice for users who consented before commencement.

- **Test it.** Run a mock Board query: pick ten users and produce the full consent history for each within a day.

Consent sits early in the [implementation roadmap](https://dpdp.d2c.in/guides/dpdp-implementation-roadmap/) because so much depends on it. If you want an engineering team to design the ledger and rebuild the flows with your counsel, [get in touch](https://dpdp.d2c.in/#contact).

## Frequently asked questions

### Is consent mandatory under the DPDP Act?

Not for everything. You need either consent or one of the legitimate uses listed in section 7, along with a lawful purpose. If your processing does not fit a section 7 use, you need consent that meets section 6(1).

### Does the DPDP Act have a legitimate interests basis like GDPR?

No. Section 7 lists nine specific legitimate uses and nothing like GDPR's open-ended legitimate interests ground. Analytics, marketing and product improvement that do not fit section 7 need consent.

### What happens when a user withdraws consent?

Processing done before the withdrawal stays lawful (s.6(5)). You must stop processing for that purpose within a reasonable time and make your processors stop (s.6(6)), then erase the data unless a law requires you to keep it (s.8(7)). Withdrawal has to be as easy as giving consent (s.6(4)).

### Can I make consent a condition of using my service?

Only for data genuinely necessary for that service. Consent must be unconditional and limited to the data necessary for the specified purpose, so you cannot make access to the core service depend on agreeing to unrelated purposes such as marketing.

### Can employers process employee data without consent under DPDP?

Section 7(i) allows processing for employment purposes, or to protect the employer from loss or liability, for example against corporate espionage or to protect trade secrets and intellectual property, or to provide a service or benefit the employee asks for. Uses outside that, such as marketing to employees, need consent.

### How long should consent records be kept?

The Act puts the burden of proving consent on you, so keep the record for as long as you rely on that consent and for as long as you may need to prove it afterwards. Agree the exact period with your counsel and document it in your retention schedule.