DPDP Act · Section 6
The DPDP Act Consent Management Clause 6 Explained: The Complete Guide to Manage Consent Under India’s New Data Protection Law
In short: Clause 6 (Section 6) of the DPDP Act makes consent the primary lawful basis for processing personal data in India. To be valid, consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, paired with a Clause 7 notice, logged as an auditable record, and as easy to withdraw as it was to give.
The DPDP Act does not simply update India’s privacy laws; it changes the foundational relationship between users and digital businesses. Clause 6 marks the transition from passive, implied consent to affirmative, accountable consent.
What is Clause 6 of the DPDP Act?
What India is moving away from
- Long, unreadable terms-of-service bundles
- “By using this app, you agree…” patterns
- Pre-ticked boxes and default opt-ins
- Consent assumed through silence or continued usage
What Clause 6 introduces
- Consent must be active, not passive
- Consent must be specific, not bundled
- Consent must be informed, not buried
- Consent must be revocable, not permanent
Why founders need to care
Clause 6 shifts personal data from being a cheap growth asset to a high-liability resource. Under the DPDP Act, consent becomes a system, a governance model, an artifact you must prove, and a signal you must respect and propagate. This is a compliance transformation on par with UPI in finance: fundamental, irreversible and ecosystem-wide. If you have not yet mapped where you stand, a free DPDP readiness assessment is the fastest way to get a board-level baseline.
The legal anatomy of valid consent
Clause 6 defines consent using five mandatory attributes. If any one is missing, the consent is invalid.
| Attribute | Meaning | Example of a breach |
|---|---|---|
| Free | No coercion, no forced access | “Accept tracking to continue” is unlawful |
| Specific | One purpose equals one consent | “We use your data for marketing and analytics” (bundled) is unlawful |
| Informed | The user knows what and why | Notice must be shown before consent |
| Unconditional | No tying an essential service to optional data | “No location, no service” unless location is essential |
| Unambiguous | A clear affirmative action | Pre-ticked boxes are invalid |
Examples of invalid consent
- “By continuing, you accept our policy”
- “Allow all” with no breakdown of purposes
- “Decline” hidden behind multiple taps
- Consent embedded inside terms and conditions
Examples of valid consent
- A clear consent toggle set to OFF by default
- Purpose-wise choices (“Personalisation”, “Marketing”, “Analytics”)
- Notice shown in the user’s chosen language
- Consent logs stored with timestamp and notice version
Clause 6 is explicit: no affirmative action means no consent.
Clause 7 and the notice–consent dependency
Clause 6 consent is meaningless without a Clause 7 notice. The Act treats notice and consent as a two-step contract. Getting the notice right is also where a clean record of processing (RoPA) and data map pays off, because every stated purpose has to trace back to real processing.
What the notice must include
- What data is being collected
- For what specific purposes
- How long it will be retained
- Whether it will be shared
- How to withdraw consent
- Contact details of a grievance officer
Layered notice structure (recommended)
| Layer | Purpose | Example |
|---|---|---|
| Layer 1 | Quick contextual summary | “We collect your email to create your account.” |
| Layer 2 | Detailed policy | Full privacy policy linked |
| Layer 3 | Consent dashboard | User can view or withdraw anytime |
Key rule: notice must be independent of the terms of service. You cannot blend contract acceptance with data consent.
The Consent Manager model (DEPA architecture)
India introduces a globally unique mechanism: Consent Managers (CMs).
What a Consent Manager is
- A government-registered intermediary
- A single dashboard for user permissions
- An issuer of cryptographically signed consent artifacts
- An interoperability layer across apps
How consent flows through a Consent Manager
| Step | Actor | Action |
|---|---|---|
| 1 | Data Fiduciary | Sends a consent request to the CM |
| 2 | Consent Manager | Notifies the user |
| 3 | Data Principal | Approves or denies |
| 4 | Consent Manager | Issues a consent artifact |
| 5 | Fiduciary | Uses the artifact as its lawful basis |
Why founders must care: consent will eventually become an API, not a UX screen. Systems should be CM-ready from day one.
When consent is not required: Clause 7 legitimate uses
Clause 7 defines tightly scoped exceptions where processing is lawful without consent. These are narrow, and building your programme around them without a proper DPDP Act compliance review is risky.
Most relevant exceptions
- Voluntary provision for a specific purpose
- Employment-related processing
- Government functions and compliance
- Medical emergencies
- Court orders and legal mandates
Consent versus legitimate use
| Scenario | Consent needed? | Why |
|---|---|---|
| User gives a number for a receipt | No | Purpose implied and limited |
| User email used for marketing | Yes | New purpose, not implied |
| KYC verification by a fintech | No | Legal mandate |
| Phone contacts used for scoring | Yes | Optional purpose |
If the purpose changes, consent becomes mandatory.
Dark patterns: UX behaviours that invalidate consent
The DPDP Act, alongside India’s dark-pattern guidelines, prohibits deceptive UX.
Dark patterns that invalidate consent
- Forcing users into choices
- Hiding “decline” behind multiple taps
- Urgency timers that push acceptance
- Sneaking consent into unrelated workflows
- Asymmetric UI design (“Accept” big, “Decline” tiny)
Valid versus invalid consent UX
| UX pattern | Status | Reason |
|---|---|---|
| Pre-ticked boxes | Invalid | Not affirmative |
| “Continue to agree” | Invalid | Ambiguous |
| Toggle default OFF | Valid | Requires user action |
| Dedicated consent modal | Valid | Unambiguous |
Multilingual consent: the 22-language mandate
India’s linguistic requirement is one of the Act’s most operationally demanding components.
Challenges
- Accurate legal translation
- Complex Indian scripts
- RTL support (Urdu, Kashmiri, Sindhi)
- UI expansion for long words
Technical requirements
| Requirement | Why it matters |
|---|---|
| Dynamic localisation engine | Hard-coded text breaks compliance |
| Script-specific fonts | Prevents display errors |
| Version-controlled notices | Required for audits |
| On-device caching | Ensures fast load times |
Consent in a language the user does not understand is invalid consent.
Children’s consent: the “zero-exploitation” rule
For minors (under 18), the Act imposes strict duties. Because child data is high-risk, a Data Protection Impact Assessment (DPIA) is the sensible starting point for any child-facing surface.
Mandatory requirements
- Verifiable parental consent
- No profiling
- No targeted advertising
- No behavioural monitoring
Operational implications
| Area | Requirement |
|---|---|
| Age verification | Self-declaration is insufficient for high-risk apps |
| Parental consent | Email/SMS loop or tokenised verification |
| Ad SDKs | Must be removed or neutralised on child surfaces |
Withdrawal of consent: engineering equal ease
Withdrawal must be as easy as giving consent. In practice this is a consent and rights (DSAR) workflow problem: the request has to propagate everywhere the data went.
What equal ease means
- One-click withdrawal if one-click consent was taken
- No email or call requirements
- Instant acknowledgement
- Processing stops within a reasonable time
Consent orchestration workflow
| System | Required action |
|---|---|
| Marketing automations | Remove the user from campaigns |
| Analytics pipelines | Stop ingesting new data |
| Core product | Disable optional features |
| Vendors | Notify and enforce deletion |
The inability to orchestrate withdrawal is non-compliance.
Retention and erasure: when consent ends, data ends
The DPDP Act introduces purpose-based storage limitation.
When data must be deleted
- The user withdraws consent
- The purpose is fulfilled
- The user is inactive for a prolonged period
- There is no legal mandate to retain
Two categories of data after withdrawal
| Category | Must be deleted? | Example |
|---|---|---|
| Optional data | Yes | Marketing preferences |
| Legally mandated data | No | KYC documents under the PMLA |
Significant Data Fiduciaries: consent at scale
Significant Data Fiduciaries (SDFs) face enhanced duties. Key obligations include appointing a Data Protection Officer, conducting annual data audits, performing Data Protection Impact Assessments, and maintaining detailed processing records. SDF status turns consent from a UI issue into a governance discipline. If you are unsure whether these duties apply to you, our Do I need a DPO? decision tool and the guide to a DPO under the DPDP Act walk through the test; the glossary entry on the DPO role covers the fundamentals.
Sectoral implications: fintech, healthtech, SaaS
The DPDP Act interacts differently with each sector.
Fintech
- RBI localisation rules override DPDP flexibility
- KYC is legal processing
- Device data (SMS, contacts) needs explicit consent
Healthtech
- Follows ABDM consent artifacts
- Health data carries higher harm and higher risk
SaaS
- Cross-border transfers are allowed unless the country is blacklisted
- Indian user data must follow the DPDP Act even for a global product
Engineering the consent artifact: making consent auditable
A consent artifact is cryptographically signed, immutable, time-stamped, purpose-bound and linked to a specific notice version.
Core elements of a consent artifact
| Element | Purpose |
|---|---|
| Consent ID | Unique tracking |
| User identifier | Data Principal identity |
| Purpose code | Defines scope |
| Data fields | What is being processed |
| Notice version | Ensures transparency |
| Signature | Enables verification |
This artifact is your regulatory defence.
Founder playbook: migrating to consent-centric systems
Consent is no longer a sidebar; it is a system of record. Priorities: map all data to its purpose, delete unneeded or unlawful data, issue fresh notices for legacy data, build consent logs, create a privacy dashboard, and introduce automated deletion pipelines. Deciding who runs this, and how, is its own question – our comparison of operating models (in-house, fractional, consultant, software-led) helps you choose. Trust then becomes a competitive moat: compliance stops being about avoiding fines and starts signalling transparency, respect and reliability.
DPDP Act consent management FAQs
What is consent management under the DPDP Act?
Consent management under the DPDP Act is how organisations collect, record, verify, update and withdraw valid consent from Data Principals, based on Clause 6 requirements. It includes notices, consent artifacts, dashboards and withdrawal workflows.
What makes consent valid under Clause 6 of the DPDP Act?
Consent must be free, specific, informed, unambiguous and given through a clear affirmative action. If any element is missing, consent is invalid.
What is a Consent Manager under the DPDP Act?
A Consent Manager is a registered entity that lets users manage consent across apps through interoperable, standardised platforms using consent artifacts.
How should startups manage consent withdrawal under the DPDP Act?
Withdrawal must be as easy as giving consent. Systems must propagate revocation across all databases, vendors, marketing tools, analytics pipelines and processors within a reasonable time.
Does the DPDP Act apply to legacy data?
Yes. Organisations must send fresh notices and collect new consent for previously collected data if the old consents were not DPDP-compliant.
Not sure whether your consent flows would pass?
Get a board-ready DPDP readiness score in about six minutes, or talk to an independent advisor about your consent, notice and withdrawal design.