AMLEGALSDPDPA
Sections 5–9 · Architecture

Consent Management Framework

The first compliance control regulators examine.

Consent is not a checkbox. Under DPDPA 2023, it is a multi-layered architecture — Notice, Affirmative Consent, Withdrawal, Children’s Consent, Deemed Consent, and Consent Manager integration. Get any layer wrong and downstream compliance unravels regardless of how robust your other safeguards are.

§ 4

Lawful purpose with consent or deemed consent

Legal foundation
§ 6

Free, specific, informed, unconditional, unambiguous

Five conditions for valid consent
Up to ₹50 Cr

Catch-all exposure for consent contraventions

Para 6, Schedule
Why Consent Architecture Matters

Consent is the load-bearing wall of every compliance programme.

When the Data Protection Board examines a contravention, the first artefact it reviews is the consent record. Was consent obtained? Was it specific? Was it informed? Was withdrawal possible? The answers determine whether downstream processing was lawful.

Most organisations carry forward consent practices designed for IT Act 2000 — single checkbox, bundled purposes, no withdrawal mechanism. These are categorically inadequate under DPDPA. The Act requires a multi-layered architecture that distinguishes between six distinct consent contexts.

The shift is not just legal — it is operational. Consent management ceases to be a legal compliance task and becomes an engineering discipline. CRM systems, marketing automation, analytics pipelines, and product flows all need to be re-architected.

The 6-Layer Architecture

Each layer maps to a discrete statutory obligation

These six layers are not optional features — they are statutory requirements distributed across Sections 5 through 9 and the DPDP Rules 2025. Implementing any layer incompletely creates a discrete compliance gap.

01

Layer 1 — Notice (Section 5)

Inform Data Principal of processing details before collection

Required Elements
  • Identity of Data Fiduciary
  • Specific purposes of processing
  • Categories of personal data
  • Rights of Data Principal
  • Grievance officer contact
  • Mechanism to withdraw consent
02

Layer 2 — Affirmative Consent (Section 6)

Capture free, specific, informed, unconditional and unambiguous consent

Required Elements
  • Clear affirmative action — no pre-ticked boxes
  • Purpose-specific — not bundled
  • Plain language
  • Granular toggles per purpose
  • Timestamped record
  • Audit trail with version history
03

Layer 3 — Withdrawal Mechanism (Section 6(4))

Allow Data Principal to withdraw consent as easily as it was given

Required Elements
  • Single-click withdrawal interface
  • No friction barriers
  • Confirmation of withdrawal
  • Cessation of processing
  • Erasure on request
  • Notification to processors
04

Layer 4 — Children's Consent (Section 9)

Verifiable parental or guardian consent for Data Principals below 18

Required Elements
  • Age verification at point of collection
  • Verifiable parental consent mechanism
  • No tracking of children
  • No behavioural monitoring
  • No targeted advertising
  • Documentation of verification method
05

Layer 5 — Deemed Consent (Section 7)

Document scenarios where consent is deemed given by operation of law

Required Elements
  • Voluntary provision identified
  • Employment processing scoped
  • Statutory obligations mapped
  • Medical emergency provisions
  • Public interest research
  • Public order disclosures
06

Layer 6 — Consent Manager Integration

Plug into Consent Manager ecosystem under DPDP Rules 2025

Required Elements
  • Registered Consent Manager onboarded
  • Interoperable consent receipts
  • Audit log to Manager
  • Cross-Fiduciary withdrawal sync
  • Standardised consent format
  • Verification mechanism
From the Counsel’s Notebook

The seven failure patterns we see in 80% of initial reviews

These patterns are not hypothetical. They appear repeatedly across client engagements, regardless of sector or scale. Each is a discrete remediation priority.

Failure 01

Single checkbox covering 8–15 purposes

Bundled consent fails Section 6’s specificity requirement. Each purpose needs its own toggle.

Failure 02

Pre-ticked consent boxes

Pre-ticking is not affirmative action. The Data Principal must take a positive step to consent.

Failure 03

No withdrawal mechanism in product UI

Withdrawal hidden in support contact flows fails Section 6(4). Must be as easy as giving consent.

Failure 04

No timestamped consent record

Cannot prove consent was given for a specific purpose at a specific time. Audit failure.

Failure 05

Children’s product without age verification

Section 9 absolute prohibition. Must verify age at collection point with verifiable parental consent.

Failure 06

No vendor consent flow-through

Withdrawal does not propagate to downstream processors and third-party recipients of personal data.

Failure 07

Implied or coerced consent for service access

Conditioning service access on consent for unrelated purposes violates Section 6’s unconditional requirement.

Failure 08

Generic “we collect data to improve services” notice

Section 5 requires specific purposes. Vague language is not informed consent.

Privileged Engagement

Request a Consent Architecture Review

Our practitioners will review your existing consent flows, map gaps against the six-layer architecture, and identify the highest-priority remediations across product, marketing, and platform engineering.

Request a Confidential Architecture Review

A senior practitioner will reach out within one working day.

Your information is handled in accordance with our privacy obligations. No spam, ever.