Section 6 — Consent

Section 4(1)(a) names consent as a lawful basis for processing. Section 6 is where the Act decides what's actually allowed to count as consent — and it sets a five-part test, not a checkbox. A click that technically happened isn't automatically valid consent under this Act; it has to be free, specific, informed, unconditional and unambiguous, all five at once, with a clear affirmative action behind it. Fail any one element and the consent is invalid to that extent, whether or not the user technically clicked "agree."

The five-part test — 6(1)

Consent must be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and it must signify agreement to processing for the specified purpose, limited to the personal data actually necessary for that purpose. Each word is a separate, independently-failable condition:

Free means a real choice — without pressure, coercion, or artificial dependency. A screen offering only "Agree & Continue" or "Decline & Exit," where declining means losing access to a service that didn't actually need the data being requested, isn't free consent — it's forced continuation dressed up as a choice. If refusing consent disproportionately penalises the user, the consent was never voluntary to begin with.

Specific means tied to one defined purpose, one defined data set, one decision — not bundled. A single checkbox covering account creation, analytics, marketing messages and partner data-sharing in one action isn't specific consent for any of those purposes individually; it's blanket permission wearing a consent label. If a given consent can't be mapped back to exactly one purpose, it fails this test regardless of how clearly it was worded.

Informed means the Data Principal actually knows, at the point of consenting, what data is being collected, why, and how it will be processed — not via a link to a privacy policy she'd have to go find and read separately. "Details available in our Privacy Policy" doesn't satisfy this element on its own; understanding can't be outsourced to a document the notice merely points at instead of restating.

Unconditional means consent can't be used to justify collecting more than the service actually needs. Making location access, contact-list permissions, or behavioural profiling mandatory to use an app that doesn't functionally require them turns consent into a toll rather than a choice — consent doesn't manufacture necessity, and data that isn't required for the service can't be made mandatory by wrapping it in a consent request.

Unambiguous, with clear affirmative action means an explicit, deliberate, provable act — clicking "I agree," toggling a switch on, an explicit confirmation. Silence isn't consent. Inaction isn't consent. A pre-ticked box a user never touched isn't consent. And data collected before this section applied to a given relationship can't be treated as consented-to under this standard without a fresh affirmative act once the section does apply.

The Act's own illustration ties several of these together: a telemedicine app asking for consent to process health data for consultations, bundled with a request to access the user's phone contact list, has bundled two purposes into one consent event. Because the contact list isn't necessary for telemedicine services, the user's consent is limited to the telemedicine processing only — the contact-list part of that bundled consent simply doesn't count, regardless of what box got checked.

Invalid parts don't taint the rest, but they still fall away — 6(2)

Any part of a consent that infringes the Act, its rules, or any other law is invalid to that extent — not the whole consent, just the offending part. The Act's illustration: an insurer asks a customer to consent both to processing her data for issuing a policy, and to waiving her right to complain to the Board. The policy-issuance consent stands; the complaint-waiver part is invalid on its own, because no consent can lawfully sign away a statutory right to complain.

Clear language, and a real point of contact — 6(3)

Every consent request has to be presented in clear and plain language, with the option to view it in English or any Eighth Schedule language, and it must give the contact details of a Data Protection Officer (where applicable) or another person authorised to respond to the Data Principal's rights-related communications. A consent screen with no route back to a real contact point fails this sub-section even if the request itself reads clearly.

Withdrawal as easy as giving it — 6(4) and 6(5)

Where consent is the basis for processing, the Data Principal can withdraw it at any time, and the ease of withdrawing has to be comparable to the ease with which consent was originally given. If consent took one click, withdrawal buried behind several screens or requiring a call to support doesn't meet this test — comparable ease is the actual statutory bar, not merely "withdrawal exists somewhere in settings." Withdrawal doesn't need justification, isn't time-bound, and isn't subject to discretionary approval. The consequences of withdrawing sit with the Data Principal, and withdrawal doesn't retroactively make prior processing unlawful — processing that already happened under a valid consent stays lawful even after that consent is later withdrawn. The Act's illustration: a shopper who withdraws consent from an e-commerce platform can be stopped from placing new orders, but the platform doesn't have to stop processing an order she already placed and paid for before withdrawing.

Cascading withdrawal to processors — 6(6)

Once consent is withdrawn, the Data Fiduciary has to cease processing within a reasonable time, and cause its Data Processors to cease as well — unless continued processing without consent is separately required or authorised under this Act, its rules, or other law. The Act's illustration shows the mechanics: a telecom operator's billing vendor stops emailing a customer's bills once she switches to in-app billing and withdraws that specific consent — the operator has to stop itself and make sure its vendor stops too, not just update its own systems and leave the vendor unaware.

Consent Managers — 6(7), 6(8), 6(9)

A Data Principal may give, manage, review or withdraw consent through a Consent Manager rather than dealing with each Data Fiduciary directly. A Consent Manager is accountable to the Data Principal and acts on her behalf under prescribed conditions, and every Consent Manager has to be registered with the Board under prescribed technical, operational and financial conditions. That registration requirement isn't a formality that already exists in practice — Rule 4 of the DPDP Rules, 2025 (the rule that governs Consent Manager registration) only comes into force twelve months after the Rules' notification date, around 13 November 2026. Until a platform actually clears that registration with the Data Protection Board, calling it a "registered Consent Manager" under Section 6(9) is inaccurate regardless of how the platform markets itself — incorporation under the Companies Act is a different thing entirely from Board registration under this Act, and choosing an unregistered platform doesn't remove the Data Fiduciary's own accountability if that choice is later scrutinised.

Burden of proof sits with the Fiduciary — 6(10)

If a question about consent arises in a Board proceeding, the Data Fiduciary — not the Data Principal — has to prove that notice was given and valid consent was obtained. Silence in a Fiduciary's own records isn't neutral; it's treated as a failure to discharge that burden.

Why this matters in practice

Section 6 is where consent screens get tested against a legal standard most weren't originally designed around — "did the user click something" and "was this free, specific, informed, unconditional and unambiguous consent" are different questions, and a lot of existing UX answers the first without answering the second. The most common failure isn't outright fraud; it's bundling (one checkbox, several purposes), soft coercion (declining costs more than it should), and notice-by-reference (pointing at a policy instead of stating the purpose directly) — all three patterns are common precisely because they were built for conversion, not for this test.

Illustration: a ride-hailing app requests consent to process location data for booking rides, bundled in the same screen with consent for sending promotional offers via SMS, presented as a single "Allow" button. A user who wants rides but not promotional SMS has no way to give one without the other — this fails the specific test in 6(1) regardless of how clearly each purpose was described in the accompanying text.

How Section 6 connects to the rest of the Act

Section 5's notice obligation feeds directly into Section 6(1)'s "informed" requirement — a notice that doesn't meet Section 5 tends to produce consent that fails Section 6 too. Section 7 is the alternative basis for processing when consent isn't sought or available — the two sections don't overlap, they're separate doors under Section 4. Section 13's rights chapter is where the withdrawal mechanics in 6(4) connect to the Data Principal's broader right of access and correction, and Rule 4 through Rule 16 of the DPDP Rules, 2025 fill in the "manner as may be prescribed" details this section defers to repeatedly.