What is clause 6 of the DPDP Act Rules?
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 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 of the DPDP Act 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 About Consent Management
Clause 6 shifts personal data from being a cheap growth asset to a high-liability resource.
Under DPDP, consent becomes:
- A system
- A governance model
- An artifact you must prove
- A signal you must respect and propagate
This is a compliance transformation on par with UPI in finance—fundamental, irreversible, and ecosystem-wide.
Chapter 2: The Legal Anatomy of Valid Consent
Clause 6 defines consent using five mandatory attributes. If any one is missing, the consent is invalid.
The Five Requirements of Valid Consent Management (Clause 6)
| Attribute | Meaning | Examples |
|---|---|---|
| Free | No coercion, no forced access | “Accept tracking to continue” = illegal |
| Specific | One purpose = one consent | “We use your data for marketing + analytics” (bundled) = illegal |
| Informed | User knows what and why | Notice must be shown before consent |
| Unconditional | No tying essential service to optional data | “No location = No service” unless essential |
| Unambiguous | Clear affirmative action | Pre-ticked boxes = 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 T&Cs
Examples of Valid Consent Management
- A clear consent toggle set to OFF by default
- Purpose-wise choices (“Personalization”, “Marketing”, “Analytics”)
- Notice shown in the user’s chosen language
- Consent logs stored with timestamp + notice version
Clause 6 is explicit: no affirmative action = no consent.
Chapter 3: Clause 7 and the Notice–Consent Dependency
Clause 6 consent is meaningless without Clause 7 notice.
The Act treats notice and consent as a two-step contract.
What 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/withdraw anytime |
Key Rule
Notice must be independent of Terms of Service. You cannot blend contract acceptance with data consent.
Chapter 4: The Consent Manager Model (DEPA Architecture)
India introduces a globally unique mechanism: Consent Managers (CMs).
What a Consent Manager Is
- A government-registered intermediary
- Acts as a single dashboard for user permissions
- Issues cryptographically signed Consent Artifacts
- Ensures interoperability across apps
How Consent Flows Through a Consent Manager
| Step | Actor | Action |
|---|---|---|
| 1 | Data Fiduciary | Sends consent request to CM |
| 2 | Consent Manager | Notifies user |
| 3 | Data Principal | Approves or denies |
| 4 | CM | Issues Consent Artifact |
| 5 | Fiduciary | Uses artifact as lawful basis |
Why founders must care
Consent will eventually become an API, not a UX screen.
Systems must be CM-ready from day one.
Chapter 5: When Consent Is Not Required — Clause 7 Legitimate Uses
Clause 7 defines tightly-scoped exceptions where processing is lawful without consent.
Most Relevant Exceptions
- Voluntary provision for a specific purpose
- Employment-related processing
- Government functions & compliance
- Medical emergencies
- Court orders / legal mandates
Table: Consent vs Legitimate Use
| Scenario | Consent Needed? | Why |
|---|---|---|
| User gives number for receipt | ❌ | Purpose implied, limited |
| User email used for marketing | ✅ | New purpose → not implied |
| KYC verification by fintech | ❌ | Legal mandate |
| Phone contacts used for scoring | ✅ | Optional purpose |
If purpose changes → consent becomes mandatory.
Chapter 6: Dark Patterns — UX Behaviors That Invalidate Consent
India’s DPDP Act + CCPA’s Dark Patterns Guidelines prohibit 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)
Table: Valid vs 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 |
Chapter 7: 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 localization 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 doesn’t understand = invalid consent.
Chapter 8: Children’s Consent — The “Zero-Exploitation” Rule
For minors (<18), the Act imposes:
Mandatory Requirements
- Verifiable parental consent
- No profiling
- No targeted advertising
- No behavioural monitoring
Operational Implications
| Area | Requirement |
|---|---|
| Age verification | Self-declaration insufficient for high-risk apps |
| Parental consent | Email/SMS loop or tokenized verification |
| Ad SDKs | Must be removed or neutralized in child surfaces |
Child data = high-risk = high penalties.
Chapter 9: Withdrawal of Consent — Engineering Equal Ease
Withdrawal must be as easy as giving consent.
What Equal Ease Means
- One-click withdrawal if one-click consent was taken
- No email/call requirements
- Instant acknowledgement
- Processing stops within a reasonable time
Consent Orchestration Workflow
| System | Required Action |
|---|---|
| Marketing automations | Remove user from campaigns |
| Analytics pipelines | Stop ingesting new data |
| Core product | Disable optional features |
| Vendors | Notify & enforce deletion |
The inability to orchestrate withdrawal = non-compliance.
Chapter 10: Retention & Erasure — When Consent Ends, Data Ends
DPDP introduces purpose-based storage limitation.
When Data Must Be Deleted
- User withdraws consent
- Purpose is fulfilled
- User is inactive for prolonged period
- 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 PMLA |
Consent ends → processing ends.
Chapter 11: Significant Data Fiduciaries — Consent at Scale
SDFs face enhanced duties.
Key Obligations
- Appoint a Data Protection Officer
- Conduct annual data audits
- Perform Data Protection Impact Assessments
- Maintain detailed processing records
SDF status turns consent from a UI issue into a governance discipline.
Chapter 12: Sectoral Implications — Fintech, Healthtech, SaaS
DPDP interacts differently with each sector.
Fintech
- RBI’s localization rules override DPDP flexibility
- KYC is legal processing
- Device data (SMS, contacts) needs explicit consent
Healthtech
- Follows ABDM consent artifacts
- Health data has higher harm → higher risk
SaaS
- Cross-border transfers allowed unless country blacklisted
- Indian user data must follow DPDP even if global product
Chapter 13: Engineering the Consent Artifact — Making Consent Auditable
A Consent Artifact is:
- Cryptographically signed
- Immutable
- Time-stamped
- Purpose-bound
- 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.
Chapter 14: Founder Playbook — Migrating to Consent-Centric Systems
Consent is no longer a sidebar; it is a system of record.
Founder 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
- Introduce automated deletion pipelines
Trust Becomes a Competitive Moat
Compliance is no longer about avoiding fines.
It is about signalling:
- Transparency
- Respect
- Reliability