Valid Consent Under DPDP: Why Your Checkbox Isn't Enough

Who this is for: Data Protection Officers, legal counsel and product leaders responsible for how consent is collected, recorded and honoured across digital channels.

Most organisations already collect something they call consent: a ticked box at sign-up, a line in the terms of service, a cookie banner with a single "Accept" button. Under the DPDP Act, most of these will not survive scrutiny. That is not because the law is unusually strict about wording. It is because the law asks a different question. It does not ask whether the customer clicked. It asks whether the business can show what the customer was told, what exactly they agreed to, and that their choice was respected afterwards.

This guide sets out the legal standard, explains each condition in practical terms, and describes what a defensible consent record contains. For the wider picture of the law, see The DPDP Act, Explained: The Complete 2026 Guide.

The legal standard: Section 6 in one sentence

Section 6(1) of the DPDP Act requires that consent be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and that it signify agreement to processing for a specified purpose, limited to the personal data necessary for that purpose.

Each of these words is a separate test. Failing any one makes the consent invalid, and processing that relies on it becomes unlawful.

1. Free

The individual must have a genuine choice. Consent obtained through pressure, or by making an unrelated service conditional on it, is not free. A lender that refuses a loan unless the applicant agrees to marketing calls is not obtaining free consent for marketing.

2. Specific

Consent must relate to a defined purpose. "To improve our services" or "for business purposes" is not specific. If you process data for account management, fraud prevention and personalised offers, those are three purposes, and each needs its own lawful basis.

3. Informed

The individual must know what they are agreeing to before they agree. In practice, this is delivered through the notice required by Section 5 and Rule 3 (see the next section). Information buried in a 40-page privacy policy, linked from a footer, does not inform anyone.

4. Unconditional

Consent cannot be bundled with conditions that the individual must accept to receive something unrelated. Section 6(2) adds a hard limit: any part of a consent that infringes the Act or any other law is invalid to that extent. The Act's own illustration is telling. If an individual consents to processing by an insurer and, in the same consent, waives their right to complain to the Data Protection Board, the waiver is void.

5. Unambiguous, with a clear affirmative action

Silence, inactivity and pre-ticked boxes are not consent. The individual must do something, such as tick an empty box, toggle a switch or tap a clearly labelled button, that can only reasonably mean agreement. "By continuing to use this site, you agree…" does not meet this test.

6. Limited to necessary data

Consent cannot legitimise collecting more than the purpose requires. The Act's illustration involves a telemedicine app that asks for access to the user's mobile contact list. If the contacts are not needed to deliver the service, consent to share them is invalid for that data, however clearly it was given.

Consent is not the only lawful basis. Section 7 lists specific legitimate uses that need no consent, and choosing the right basis for each purpose matters. The DPDP Act guide summarises them.

The notice that must come with consent

Consent cannot be informed without a notice, and the DPDP Act is precise about what that notice must contain. Section 5 requires every request for consent to be preceded or accompanied by a notice. Rule 3 sets the standard.

Format. The notice must be presented independently of any other information, such as terms of service or marketing copy. It must be understandable on its own, without reference to other documents, and written in clear and plain language.

Content. At minimum, the notice must give:

• an itemised description of the personal data to be processed
• the specified purpose of processing, with an itemised description of the goods, services or uses it enables
• a communication link (on a website or app, or another means) through which the individual can withdraw consent, exercise their rights and complain to the Data Protection Board

Language. Section 6(3) requires that individuals be able to access the request for consent in English or in any of the 22 languages listed in the Eighth Schedule to the Constitution. For consumer-facing businesses serving multiple regions, multilingual notices are a design requirement, not a translation afterthought.

Contact. The request must include the contact details of a Data Protection Officer, where applicable, or another person authorised to respond to questions about the individual's rights.

Existing users. For personal data processed on consent given before the Act commenced, Section 5(2) requires you to send the same kind of notice as soon as reasonably practicable. You may continue processing until the individual withdraws consent. Our DPDP compliance timeline shows when this obligation takes effect.

Withdrawal: as easy to leave as to join

Section 6(4) gives individuals the right to withdraw consent at any time. The ease of withdrawal must be comparable to the ease with which consent was given. If consent took one tap in an app, withdrawal cannot require an email to a support address and a 10-day wait.

Three consequences follow from Sections 6(5) and 6(6):

1. Past processing stays lawful. Withdrawal does not invalidate processing that took place before it.
2. Processing must stop within a reasonable time, unless another lawful basis applies. This includes processing by your processors. You must cause them to stop as well.
3. The individual bears the consequences. If withdrawal means a service can no longer be provided, the individual accepts that outcome. You may tell them about it, but you cannot use it to pressure them.

The operational challenge is the second point. Withdrawal is a state change that must reach every system and vendor relying on that consent: CRM, marketing automation, analytics, call centres and data partners. An organisation that updates a preference centre but keeps sending campaigns from its email platform has not complied.

Children and persons with disabilities

For a child (anyone under 18), consent must come from a parent or lawful guardian, and it must be verifiable (Section 9(1)). Rule 10 requires the fiduciary to adopt appropriate technical and organisational measures to confirm that the person giving consent is an identifiable adult. It allows this to be done through reliable details already held or through a virtual token, such as one issued through DigiLocker. The same principle applies to a person with a disability who has a lawful guardian.

Even with valid parental consent, Section 9(3) prohibits tracking, behavioural monitoring and targeted advertising directed at children.

Consent Managers: a new channel

Section 6(7) allows individuals to give, manage, review and withdraw consent through a Consent Manager: a platform registered with the Data Protection Board that works across many businesses. Registration opens on 13 November 2026 under Rule 4. See the DPDP compliance timeline for every phase.

For most businesses, the practical implication is interoperability. Your systems should be able to receive and act on a consent or withdrawal that arrives through a Consent Manager, just as they would one collected on your own website.

The burden of proof is on you

Section 6(10) is the provision that changes how consent must be engineered. Where consent is the basis of processing and a question arises in any proceeding, the Data Fiduciary must prove that a notice was given and that consent was given in accordance with the Act.

The customer does not have to show they never agreed. You have to show they did, on what terms, after seeing which notice. A boolean field reading consent = true will not discharge that burden.

What a defensible consent record contains

To meet the Section 6(10) burden, each consent event should be stored with enough context to reconstruct it months or years later. A well-designed record answers six questions: who consented, to what purpose, covering which data, after seeing which notice, how and when, and what has happened since.

{
  "consent_id": "cns_8f2a91",
  "data_principal_ref": "cust_104552",
  "purpose_id": "marketing_whatsapp_offers",
  "data_items": ["mobile_number", "first_name"],
  "notice_id": "ntc_marketing_v3",
  "notice_language": "hi",
  "action": "granted",
  "method": "unticked_checkbox_selected",
  "channel": "android_app",
  "captured_at": "2027-05-20T10:42:18+05:30",
  "source": "direct",
  "status": "active",
  "history": [],
  "record_hash": "sha256:4be1...c907",
  "previous_hash": "sha256:91ad...02fe"
}

Three design choices make the difference:

• Version the notice. Store a reference to the exact notice version shown, not just "privacy notice". When the notice changes, old consents still point to the text the individual actually saw.
• One record per purpose. A single consent covering several purposes cannot show which ones the individual chose. Separate records allow partial withdrawal.
• Make the history tamper-evident. Chaining each record to the previous one with a hash means any later alteration is detectable. That is powerful evidence when consent is disputed.

Valid consent checklist

Use this to audit each consent flow in your products.

Common consent mistakes

• One checkbox for everything. Bundling terms of service, privacy policy and marketing into one tick fails the tests for being specific, unconditional and free.
• Relying on consent where a legitimate use fits better. Processing needed to comply with a law does not need consent. Asking for it creates a withdrawal right you cannot actually honour.
• Dark patterns. A bright "Accept all" next to a grey "Manage settings" link, or repeated prompts after a refusal, undermine the claim that consent was free.
• Static consent in a changing product. New features often reuse old consent for new purposes. A new purpose needs new consent.
• Recording the click but not the context. Without the notice version and the purpose, a consent record cannot carry the burden of proof.

How ConsentifyAI helps

ConsentifyAI turns the Section 6 standard into product infrastructure. Purposes and data items are defined once in a central registry and linked to versioned, multilingual notices. Consent is captured per purpose through SDKs and APIs. Withdrawals are pushed to connected systems as events, and every action is written to a hash-chained audit trail. When you need to prove a consent, you retrieve the record, the notice the individual saw, and its full history in one place.