DPDP Notices and Consent: What a Valid Request Looks Like

Introduction

Most consent screens in India were built to protect the business: one checkbox and a button marked "Continue". The Digital Personal Data Protection Act, 2023 (the DPDP Act) turns that around. It tests a consent request part by part, invalidates what goes too far and, if consent is disputed, makes the business prove notice and valid consent.

A data fiduciary decides why and how personal data is processed; a data principal is the individual the data relates to; a data processor acts on a fiduciary's behalf. Sections 5, 6(1) to 6(8) and 6(10) of the Act, and Rule 3 of the DPDP Rules, 2025, commence on 13 May 2027, a date unchanged as of October 2026. Screen design is covered in Trayambic's blog on dark patterns and consent design, and consent managers in its insight on Rule 4.

The legal position

The notice (s.5(1)). "Every request made to a Data Principal under section 6 for consent" must be accompanied or preceded by a notice telling her (i) the personal data and the purpose for which it is proposed to be processed; (ii) how to exercise her rights under s.6(4), withdrawal, and s.13, grievance redressal; and (iii) how to complain to the Data Protection Board of India (the Board).

The standard (Rule 3). The notice must be "understandable independently of any other information" the fiduciary has given. In clear and plain language it must give "an itemised description of such personal data", the specified purposes and the goods, services or uses they enable, and a link through which she can withdraw consent as easily as she gave it, exercise her rights and complain to the Board.

Earlier consents (s.5(2)). Where consent was given before commencement, the fiduciary must give a similar notice "as soon as it is reasonably practicable", and "may continue to process the personal data until and unless the Data Principal withdraws her consent".

Language and contact (ss.5(3), 6(3)). The notice and the request must be available, at the person's option, in English or any of the 22 languages in the Eighth Schedule to the Constitution. The request must be in clear and plain language and name a Data Protection Officer, where there is one, or another person authorised to respond.

Consent (s.6(1)). Consent must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action", and is limited to personal data necessary for the specified purpose. In the illustration, a telemedicine app also asks for the phone's contact list; because the list "is not necessary for making available telemedicine services", the consent covers telemedicine only.

Partial invalidity (s.6(2)). Any part of a consent that infringes the Act, the Rules or "any other law for the time being in force" is "invalid to the extent of such infringement". The illustration: an insurance buyer's consent to waive her right to complain to the Board.

Withdrawal (ss.6(4) to 6(6)). She may withdraw at any time, as easily as she consented. She bears the consequences, and earlier processing stays lawful (s.6(5)). The fiduciary must, "within a reasonable time", stop processing and make its processors stop, unless the Act or another law requires or authorises continued processing (s.6(6)).

Proof (s.6(10)). Where consent is the basis of processing and "a question arises in this regard in a proceeding", the fiduciary must prove notice and consent.

Analysis

Notice attaches to consent

Section 5(1) speaks only of requests for consent, so processing on a legitimate use in s.7, such as employment under s.7(i), carries no statutory notice duty.

Section 7(a), however, covers data voluntarily provided "for the specified purpose", and s.2(za) defines that as "the purpose mentioned in the notice given by the Data Fiduciary". In our view a one-line purpose statement where s.7(a) data is collected, not a full Rule 3 notice, answers that; Trayambic's article on the s.7 legitimate uses develops the point.

One notice or several

Rule 3's independence test rules out a notice that merely points to the privacy policy, but it does not demand a document per screen. In our view the workable model is one short, itemised notice per consent journey, shown where the request is made, with the privacy policy behind it as background.

Different people need different notices. Employees processed under s.7(i) need none by statute, but consent-based extras such as background verification do; Trayambic's article on background checks covers these. Vendors' and clients' staff are usually processed on business contact details, which s.7(a) can cover; using them for event marketing, say, needs a notice. Customers need one for each consent journey. Tag every notice with a version and language.

Bundling, necessity and conditions of service

"Unconditional" does not oblige a business to serve someone who withholds the data the service needs: s.6(1) limits consent to necessary data, and s.6(5) accepts that withdrawal has consequences, including losing the service. In our view consent can be a condition of a service only for the data it needs, and where the person hands that data over for the service, s.7(a) is usually the cleaner ground.

Marketing, profiling, partner sharing and device access a feature does not need must be requested separately, off by default and refusable without losing the core service. The Act's response to over-reach is severance: the telemedicine illustration keeps the service consent and drops the contact list. It is not a safety net: a flow that forces acceptance of extras invites the argument that none of the consent was free.

Click-wrap, browse-wrap and why a contract is not consent

Online terms are contracts. Section 10 of the Indian Contract Act, 1872 enforces agreements "made by the free consent of parties competent to contract", if its other conditions are met, and s.10A of the Information Technology Act, 2000 says an electronically formed contract is not unenforceable "solely on the ground that such electronic form or means was used". A click-wrap, where the user clicks "I agree", fits. A browse-wrap, where use of the site counts as acceptance of terms behind a footer link, is in our view a weak contract, because nothing shows the user agreed.

DPDP consent is a different instrument:

Sign-up therefore needs two actions: accepting the terms, and consenting purpose by purpose.

Proving it

Section 6(10) has four parts, and each needs its own evidence:

• "a notice was given by her": the notice version, its archived text and the language shown.
• "consent was given by such Data Principal": the account or verified identifier, and the method, whether tick, toggle or one-time password.
• "to the Data Fiduciary": the entity named in the notice. Consent collected by a partner, or bought with a list, is not consent to you.
• "in accordance with" the Act and Rules: purposes accepted and declined, timestamp, channel, and each withdrawal with the date it reached every processor.

Under s.63 of the Bharatiya Sakshya Adhiniyam, 2023, an electronic record offered in evidence needs a certificate from the person in charge of the system and an expert, so build logs that can be exported with one. In our view s.6(10) itself justifies keeping a minimal record of a consent and its withdrawal after the underlying data is erased.

Practical implications

Worked example (figures illustrative). A diagnostics chain runs a home-collection app with about six lakh registered users. Sign-up is one screen: "By continuing you agree to our Terms and Privacy Policy." The app requests contacts at launch for "invite friends", pre-ticks a box for WhatsApp offers and shares selected report values with an insurer offering wellness discounts, which its policy calls sharing with "partners".

The redesign:

1. 1.Core service on s.7(a). Booking details are collected for the test under a one-line purpose statement. Reports are kept as long as other law requires, whatever is withdrawn (s.6(6)).
2. 2.Three separate consents, each with its own Rule 3 notice and off by default: sharing named report values with the insurer, trend insights across past reports, and WhatsApp offers.
3. 3.Contacts permission removed. Referral moves to a share link, the fix the telemedicine illustration points to.
4. 4.Terms accepted separately, by a checkbox that grants no data consent.
5. 5.Languages. Notices launch in the app's four interface languages, with a working route to any other scheduled language, since in our view s.5(3) gives the choice to the person.
6. 6.Child profiles. A laboratory is a clinical establishment under the definition the Fourth Schedule to the Rules uses, so the parental-consent duty in s.9(1) does not apply to a child's test, to the extent necessary to protect her health. Insurer sharing and insights are disabled on child profiles.
7. 7.Existing users. A s.5(2) notice goes out in-app and by email soon after 13 May 2027. In our view pre-ticked WhatsApp opt-ins are not consent the app can prove, so it asks again.
8. 8.Withdrawal. Each consent is a two-tap toggle under Privacy, as it was given. Switching off insurer sharing stops transfers and sends the insurer, a separate fiduciary, a contractual notice.

Key takeaways

A valid request is a short, standalone, itemised notice in a language the person can choose, then a separate affirmative act for each purpose beyond the service itself, with withdrawal one step away and a record that can be produced in evidence. Designing to that standard now leaves little to change once the Board starts hearing complaints.

• Every consent request must come with a notice stating the data and purpose, how to withdraw and seek redress, and how to complain to the Board (s.5(1)); Rule 3 adds that it must stand alone and itemise.
• Consent can be a condition of a service only for the data that service needs; the Act severs over-reaching parts (s.6(2)), but a forced flow risks the whole consent.
• Clicking 'I agree' to terms forms a contract (IT Act s.10A) but is not DPDP consent; browse-wrap is at best a weak contract and never consent.
• People who consented before 13 May 2027 must be sent a notice as soon as reasonably practicable (s.5(2)).
• The fiduciary must prove notice and consent (s.6(10)), so versioned notices and an exportable consent log are core evidence.