Short answer: From 13 May 2027, an app may process personal data only for a lawful purpose and either with the user's consent or for a listed legitimate use (s.4). Consent must be free, specific, informed, unconditional and unambiguous, limited to the data needed for the purpose, and as easy to withdraw as to give (s.6).
What counts as valid consent under the DPDP Act?
Valid consent under the DPDP Act is a clear affirmative action by the user that agrees to processing of only the personal data necessary for a specified purpose, given freely and on an informed basis after a notice (s.6(1), s.5).
The Act's own words are short enough to quote: consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action" (s.6(1)).
- Consent: the user's agreement to processing of her personal data for the specified purpose, meeting the s.6(1) standard.
- Lawful purpose: any purpose not expressly forbidden by law (s.4).
- Legitimate use: one of the closed list of situations in s.7 where consent is not needed. See legitimate uses.
Is consent the only lawful basis for an app?
No. The Act allows processing either with consent or for a legitimate use under s.7 (s.4). But the s.7 list is closed and contains no general legitimate interests or contractual necessity ground.
- Interpretation: commentators read this as making consent the default basis for most commercial app processing, such as analytics, personalisation and marketing. This is a reading of the Act's structure, not an express statement in it.
The seven rules of DPDP consent
| Requirement | Source | Practical meaning |
|---|---|---|
| Free, specific, informed, unconditional, unambiguous | s.6(1) | No pre-ticked boxes, no bundling of unrelated purposes |
| Limited to necessary data | s.6(1) | Ask only for what the stated purpose needs |
| Infringing terms are invalid | s.6(2) | A clause waiving the right to complain to the Board does not bind |
| Plain language, language choice, contact details | s.6(3) | English or an Eighth Schedule language; DPO or authorised contact named |
| Withdrawal as easy as giving | s.6(4) | Same number of steps, same place in the app |
| Stop processing on withdrawal | s.6(6) | Including by your processors, within a reasonable time |
| Burden of proof on the app | s.6(10) | Keep records of notice and consent |
What does necessary data mean for app permissions?
Consent covers only personal data necessary for the specified purpose (s.6(1)). The Act's illustration is direct: a telemedicine app that asks for consent to access the user's contact list does not get valid consent for that access, because the contact list is not necessary to provide the service.
- Expect each runtime permission (contacts, location, camera, microphone) to be tested against its stated purpose.
- A single "I agree" covering every purpose risks failing the specific and unconditional tests.
What happens when a user withdraws consent?
The user can withdraw at any time, and the ease of withdrawing must be comparable to the ease of giving consent (s.6(4)). Within a reasonable time the app must stop processing, and cause its Data Processors to stop, unless the law requires or authorises continued processing (s.6(6)).
- The consequences of withdrawal, such as losing access to a feature that depends on the data, are borne by the user (s.6(5)).
- Withdrawal does not make earlier lawful processing unlawful (s.6(5)).
- Withdrawal also triggers the erasure duty in s.8(7). See retention and erasure.
Can users manage consent through a third party?
Yes. A user may give, manage, review or withdraw consent through a Consent Manager registered with the Board (s.6(7)). The wording is permissive, so using one is optional for the user. Consent Manager registration rules start earlier, on 13 November 2026. See consent managers.
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider separating consent by purpose (for example core service, product analytics, marketing, attribution) instead of one blanket toggle.
- A common approach is to show the Rule 3 notice and the consent choice on the same screen, with an affirmative tap and no pre-selected options.
- Consider auditing each device permission and SDK against a written purpose, and removing those you cannot justify as necessary.
- Put a withdrawal control where users gave consent, such as a privacy settings screen reachable in the same number of taps.
- Consider how a withdrawal signal reaches your analytics, attribution and marketing vendors. The attribution page covers this.
- Keep a timestamped consent log per user and per purpose, including the notice version shown, because the burden of proof sits with the app (s.6(10)).
- Plan the s.5(2) notice for users who consented before 13 May 2027.