Bundled Consent Under the DPDP Act: Why One Checkbox Fails Section 6

A Single Checkbox Is Not Consent. It Is a Liability.

Bundled consent is the practice of grouping several data-processing purposes under one consent action. The user ticks one box, or clicks one button, and the organisation treats that single act as agreement to everything: account creation, marketing, profiling, analytics, and data sharing with third parties.

Under the DPDP Act 2023, this is non-compliant. Section 6 sets the standard for valid consent, and a single accept-all action fails it on two counts. This article explains why, what regulators are now treating as a violation, and how to redesign the flow.

What Section 6 Requires

Section 6(1) of the DPDP Act states that consent must be “free, specific, informed, unconditional and unambiguous with a clear affirmative action, and shall signify an agreement to the processing of her personal data for the specified purpose.”

Two of those words decide the question of bundled consent.

• Free. Consent is not free when refusing one purpose costs the individual access to a service that does not depend on that purpose. Pairing marketing consent with account registration, where declining marketing blocks the account, is coercion by design.
• Specific. Consent is specific when it attaches to a defined purpose. A single action that covers analytics, profiling, and third-party sharing at once is not specific to any one of them. The individual cannot agree to the processing they want and refuse the processing they do not.

Section 6(1) also requires “a clear affirmative action.” A pre-ticked box is not affirmative. Silence is not affirmative. Inactivity is not affirmative. The default state of any consent control must be off.

Defective consent is treated the same as absent consent. The Data Protection Board of India does not distinguish between an organisation that collected no consent and one that collected consent that fails Section 6.

Why Bundled Consent Fails Both Tests at Once

Consider a sign-up flow with one checkbox: “I agree to the Terms of Service and Privacy Policy, and to receive marketing communications and personalised offers.”

That single control bundles at least three distinct purposes:

1. Processing necessary to provide the service.
2. Marketing communication.
3. Profiling for personalised offers.

The first may be supportable. The second and third are optional and must be separable. By forcing all three into one action, the flow makes consent neither free nor specific. The user who wants the service but not the marketing has no path to that outcome. The consent record the organisation holds is defective for every purpose it claims to cover.

This is not a technicality. It is the difference between a consent artefact that survives scrutiny and one that does not.

Bundled Consent Is a Dark Pattern

The DPDP framework treats consent interface design as part of the obligation, not a presentation choice. Bundled consent sits inside a wider category the Act and its associated guidance treat as non-compliant: dark patterns. These are interface choices that steer an individual toward consent they would not give if the choice were presented plainly.

Common dark patterns regulators are scrutinising:

• Pre-ticked boxes. The control defaults to consent. Section 6 requires the opposite.
• Bundled consent. Multiple purposes under one action, as described above.
• Asymmetric choices. A prominent “Accept all” against a buried or multi-step “Reject.”
• Forced action. Service denied for refusing processing the service does not require.
• Confirmshaming. Language that frames refusal as a loss or a mistake.

For regulated financial entities, this is now explicit. The RBI Responsible Business Conduct Amendment Directions, notified as final in May 2026 and effective July 1, 2026, require per-product explicit consent and ban bundled and pre-ticked consent and dark patterns in digital interfaces. The detail of what banks and NBFCs must have in place is covered in the RBI consent rules guide. The direction of travel is the same across every sector: one consent action per purpose, no defaults, no coercion.

How to Redesign a Bundled Flow

Moving from bundled to compliant consent is a structured exercise. The work is the same whether you run an e-commerce checkout, a lending app, or a hospital intake form.

1. Map every purpose

List each distinct purpose for which you process personal data at the point of collection. Service delivery, payment processing, marketing, profiling, analytics, third-party sharing. Each is a separate purpose with its own consent question.

2. Separate necessary from optional

Identify which purposes are necessary to deliver the service the individual asked for and which are optional. Processing that is genuinely necessary for the requested service may rest on the contract, but you cannot relabel marketing or profiling as necessary to avoid asking. The classification has to be honest, because an inspection will test it.

3. Present one consent action per optional purpose

Give each optional purpose its own control, defaulted to off, requiring an affirmative action. The individual must be able to consent to one and refuse another, and still receive the core service. This is the operational meaning of free and specific.

4. Remove the defaults and the asymmetry

No pre-ticked boxes. No accept button without an equally reachable refuse path. The interface must not weight the decision.

5. Record consent against the purpose

Every consent action must be logged against the specific purpose it relates to, with a timestamp, the version of the notice shown, and the affirmative action taken. Store these in a signed, tamper-evident ledger. When a Data Principal withdraws consent for one purpose, the record must show that the other consents remain intact and that processing for the withdrawn purpose stopped.

What an Auditable Consent Record Must Show

Redesigning the interface is half the obligation. The other half is the record. For each consent the system must hold:

• The specific purpose consented to, mapped to a lawful basis.
• The exact notice text and version presented at the time.
• The timestamp and the affirmative action captured.
• The state of every other purpose, consented or refused, at that moment.
• A withdrawal trail, if the individual later changed any of those states.

This is what separates a defensible consent posture from a checkbox. When a Data Principal exercises their rights, or the Board asks for evidence, the record either reconstructs the exact consent state or it does not.

The Operational Position

Bundled consent persists because it is the path of least resistance at the design stage. One control is faster to build and converts at a higher rate than purpose-separated consent. That short-term gain is the exposure. Every individual who passed through a bundled flow holds a defective consent record, and the defect is systemic rather than isolated. Remediation means rebuilding the flow and, in most cases, re-collecting consent from the existing base.

Purpose-separated consent, recorded against each purpose in an auditable ledger, is the standard the DPDP Act sets and the standard sector regulators are now enforcing ahead of it. The DPDP compliance checklist sets out where consent design sits among the other obligations, and the consent management guide covers the full set of conditions valid consent must meet.

Assess Your Consent Posture

The free Compliance Gap Assessment scores your organisation against the DPDP Act’s obligations in under 10 minutes, including how your consent collection measures against Section 6, and returns a prioritised report. View ConsentOS pricing tiers for the consent infrastructure that captures purpose-specific consent and maintains the audit trail the Act requires.