AMLEGALSDPDPAVibe Data Privacy
Back to Documents
Framework

Consent Architecture and Forms

Designing consent mechanisms that meet DPDPA requirements for free, specific, informed, and unambiguous consent

Section 6Section 7Rule 4

Consent under DPDPA is not a checkbox. It is an architecture. The law requires consent that is free, specific, informed, unconditional, and unambiguous. Each word carries legal weight. Your consent mechanism must satisfy all five requirements simultaneously.

The Five Requirements

Free means the Data Principal has genuine choice without coercion or undue influence. Specific means consent is sought for defined purposes, not blanket authorization. Informed means the Data Principal understands what they are consenting to. Unconditional means consent cannot be tied to unrelated conditions or bundled with service acceptance. Unambiguous means there is a clear affirmative act, not silence or pre-ticked boxes.

Granular Consent Design

DPDPA expects granularity. If you process data for multiple purposes, you need separate consent for each purpose. A single consent covering marketing, analytics, and personalization is problematic. The Data Principal must be able to consent to some purposes while declining others.

Key Points
  • Separate consent toggle for each processing purpose
  • Clear explanation accompanying each consent request
  • No bundling of essential and non-essential processing
  • Equal prominence for accept and decline options

Consent Managers

Rule 4 introduces Consent Managers as registered intermediaries. These are entities that help Data Principals manage their consents across multiple Data Fiduciaries through a single interface. Only Indian-incorporated companies with minimum net worth of two crore rupees can register as Consent Managers. This is unique to India and has no GDPR equivalent.

Withdrawal Must Be Easy

Section 6(4) requires that withdrawing consent be as easy as giving it. If consent is given through a single click, withdrawal must be achievable through a single click. Requiring phone calls, written letters, or multi-step processes to withdraw consent violates this principle.

Record Keeping

You must maintain records of consent. When was consent given. What was consented to. Through what mechanism. These records become evidence of your compliance. In case of dispute or regulatory inquiry, the burden falls on you to demonstrate valid consent was obtained.

Essential Clauses

Purpose-Specific Consent Language

Section 6(1)

Each consent request must clearly state the specific purpose

Affirmative Action Requirement

Section 6(1)

Pre-ticked boxes or implied consent mechanisms are invalid

Withdrawal Mechanism Description

Section 6(4)

The consent form must explain how to withdraw

Consequences of Withdrawal

Section 6(5)

Data Principal must understand what happens if they withdraw consent

No Bundling Declaration

Section 6(1)

Consent for data processing should not be bundled with service terms

Timestamp and Version Tracking

Rule 4

Records must show when consent was given and which notice version was presented

Implementation Steps

1

Map all processing activities to identify distinct consent requirements

2

Design consent UI with separate toggles for each purpose

3

Ensure visual parity between accept and decline options

4

Build consent withdrawal mechanism with equal or lesser friction than grant

5

Implement consent logging with timestamps and notice version references

6

Create audit trail for consent state changes

7

Test consent flows across all user touchpoints

8

Prepare for Consent Manager integration when the framework becomes operational

Frequently Asked Questions

Need This Document Drafted?

Understanding the requirement is the first step. Having it implemented correctly is what protects your organization. Our team drafts DPDPA-compliant documents tailored to your specific operations.

Get in Touch