Module 2 Β· Part 1

Grounds for Processing & Consent Framework

Master the two lawful bases for processing personal data under DPDPA 2023: the consent architecture and legitimate uses framework that form the foundation of every data processing operation.

⏱ 60-70 minutes Β§ Sections 4, 6, 7 πŸ“‹ Rules 3, 4

🎯 Introduction

Every time a Data Fiduciary processes personal data, a fundamental legal question must be answered: What authorises this processing? Unlike casual conversations where we might say "I consent to these terms" while scrolling past pages of legalese, the DPDPA 2023 demands a far more rigorous framework.

πŸ›οΈ The Fiduciary Philosophy

The term "Data Fiduciary" isn't accidental. Borrowed from trust law, a fiduciary owes duties of care, loyalty, and good faith to the beneficiary. Just as a trustee cannot misuse trust property, a Data Fiduciary cannot process personal data beyond what is authorised. As the Srikrishna Committee observed: "The relationship between the data principal and the data fiduciary must be built on the bedrock of trust."

This lesson unpacks the two β€” and only two β€” lawful grounds for processing personal data under the DPDPA:

βš–οΈ

Legitimate Uses

Section 7

Processing without consent for specified purposes deemed lawful.

  • Voluntary data provision by principal
  • State functions & subsidies
  • Medical emergencies
  • Employment purposes

⚠️ Critical Understanding

Unlike the GDPR's six lawful bases, the DPDPA recognises only two: consent (Β§6) and legitimate uses (Β§7). There is no separate "legitimate interest" balancing test as in GDPR Article 6(1)(f). This fundamental difference shapes every compliance strategy.

πŸ“œ Section 4: Grounds for Processing Personal Data

πŸ“– DPDPA 2023, Section 4 β€” Grounds for Processing Personal Data

"A person may process the personal data of a Data Principal only in accordance with the provisions of this Act and for a lawful purposeβ€”

(a) for which the Data Principal has given her consent; or

(b) for certain legitimate uses."

Section 4 is the gateway provision β€” the constitutional moment of data protection. Before any processing occurs, the Data Fiduciary must point to either consent under Section 6 or a legitimate use under Section 7.

Deconstructing Section 4

πŸ”‘ "A person may process"

The use of "person" (rather than "Data Fiduciary" alone) is deliberate. It encompasses both the Data Fiduciary who determines the purpose and Data Processors who process on their behalf. No person β€” regardless of status β€” may process without a lawful ground.

πŸ”‘ "In accordance with the provisions of this Act"

Even valid consent or legitimate use doesn't grant unlimited processing rights. Additional obligations under Section 8 (general obligations), Section 9 (children's data), and Section 10 (SDF obligations) must be satisfied cumulatively.

πŸ”‘ "For a lawful purpose"

This seemingly innocuous phrase carries constitutional weight. A purpose that violates fundamental rights, public policy, or other laws cannot be "lawful" regardless of consent obtained. Drawing from Kesavananda Bharati v. State of Kerala (1973) 4 SCC 225, the "lawful" purpose must align with the basic structure of constitutional morality.

"Data protection is not merely about protecting data. It is about protecting people and their fundamental right to privacy as illuminated in Puttaswamy."
β€” Justice B.N. Srikrishna, Data Protection Committee Report (2018)

πŸ“‹ Seven Characteristics of Valid Consent

Section 6(1) distills consent into seven mandatory characteristics. Failure on any single characteristic renders the entire consent invalid.

1

Free

Consent given without coercion, undue influence, or imbalance of power. Bundled consent (accept all or get nothing) is not "free."

Β§6(1) + Contract Act Β§14
2

Specific

Given for a particular, identified purpose β€” not blanket authorisation. Each distinct purpose requires separate consent.

Β§6(1) + Β§6(4)
3

Informed

Based on clear understanding through itemised notice under Section 5. Informed consent requires comprehensible language.

Β§6(1) + Β§5
4

Unconditional

Cannot be made a precondition for service unless processing is necessary for the service. "All or nothing" terms fail this test.

Β§6(1) + Β§6(5)
5

Unambiguous

Leaves no doubt about what is being consented to. Vague, hidden, or confusing consent mechanisms are invalid.

Β§6(1)
6

Clear Affirmative Action

Requires positive opt-in. Silence, pre-ticked boxes, or inactivity cannot constitute consent.

Β§6(1) + Rule 3
7

Limited to Necessary Data

Data minimisation principle embedded in consent β€” only data necessary for the stated purpose can be processed.

Β§6(1) + Β§8(4)

πŸ“ Practitioner's Checklist

Before advising on consent mechanisms, verify each element: Is the consent form unbundled (free)? Does it specify each purpose separately (specific)? Is the notice in accessible language (informed)? Can the service be accessed without consent where processing isn't necessary (unconditional)? Is the consent statement crystal clear (unambiguous)? Does it require an active click/check (affirmative action)? Is only necessary data requested (limited)?

Section 6(4): Purpose Limitation

πŸ“– DPDPA 2023, Section 6(4)

"Where consent given by the Data Principal is the basis for processing of personal data and such processing is done in breach of the provisions of this Act, such personal data shall be processed only with the consent of the Data Principal obtained afresh, and processing of such data done prior to the withdrawal of consent shall not be affected."

This creates a significant compliance burden: if processing breaches any provision, fresh consent must be obtained before continuing. Merely "fixing" the breach isn't sufficient β€” the consent is vitiated and must be renewed.

Section 6(5): The "Bundling" Prohibition

πŸ“– DPDPA 2023, Section 6(5)

"Consent shall not be valid if it is found that performance of a contract, including provision of any goods or services or employment or legal entitlement, is made conditional on consent for processing of personal data that is not necessary for such contract, goods or services or employment or legal entitlement."

⚠️ The "Take It or Leave It" Trap

Invalid: "To use our e-commerce platform, you must consent to marketing communications."

Valid: "To process your order, we need your shipping address. Separately, would you like to receive promotional emails? [Optional checkbox]"

βš–οΈ Legitimate Uses (Section 7)

Section 7 creates a closed list of circumstances where processing is lawful without consent. Unlike the GDPR's flexible "legitimate interest" test (Article 6(1)(f)), India's legitimate uses are exhaustively enumerated.

πŸ“– DPDPA 2023, Section 7 β€” Certain Legitimate Uses

"A Data Fiduciary may process personal data of a Data Principal for any of the following uses, namely:β€”

(a) for the specified purpose for which the Data Principal has voluntarily provided her personal data to the Data Fiduciary and has not indicated to such Data Fiduciary that she does not consent to the use of her personal data;

(b) by the State or any instrumentality of the State for any function under any law for the time being in force, includingβ€”
(i) provision of any service or benefit to the Data Principal;
(ii) issuance of any certificate, licence or permit;

(c) for compliance with any judgment or decree or order issued under any law;

(d) for responding to a medical emergency involving a threat to the life or a severe threat to the health of the Data Principal or any other individual;

(e) for taking measures forβ€”
(i) provision of medical treatment or health services during an epidemic, outbreak of disease or any other threat to public health; or
(ii) ensuring safety of, or providing assistance or services to, any individual during any disaster or any breakdown of public order;

(f) for purposes related to employment...

(g) for the purpose referred to in sub-section (3) of section 17."

Detailed Analysis of Legitimate Uses

πŸ“€
Voluntary Provision
Section 7(a)

When data is voluntarily provided for a specified purpose and the principal hasn't objected. This creates an "opt-out" regime for voluntary disclosures.

Example: A user provides their email while commenting on a blog. The blog can send notifications about replies unless the user opts out.
πŸ›οΈ
State Functions
Section 7(b)

Government and instrumentalities processing data for statutory functions β€” services, benefits, certificates, licences, permits.

Example: Aadhaar-based authentication for PDS ration distribution; processing passport applications; issuing driving licences.
βš–οΈ
Court Orders
Section 7(c)

Processing to comply with judgments, decrees, or orders issued under any law by courts or tribunals.

Example: Bank disclosing account details pursuant to a High Court attachment order; producing records in compliance with CrPC summons.
πŸš‘
Medical Emergency
Section 7(d)

Life-threatening or severe health emergencies involving the Data Principal or another individual.

Example: Hospital accessing patient records during unconscious admission; sharing blood type with emergency services after an accident.
🦠
Public Health & Safety
Section 7(e)

Epidemics, disease outbreaks, public health threats, disasters, or breakdown of public order.

Example: Contact tracing during COVID-19; disaster relief databases; flood victim identification systems.
πŸ’Ό
Employment Purposes
Section 7(f)

Processing employee data for recruitment, termination, attendance, performance assessment, and related purposes.

Example: HR processing leave records; payroll data for salary disbursement; performance reviews; background verification.
πŸ›‘οΈ
Corporate Transactions
Section 7(g) β†’ Β§17(3)

Processing during mergers, demergers, acquisitions, or other corporate restructuring where reasonable security is maintained.

Example: Due diligence data sharing during M&A; customer database transfer in asset sale; employee data during merger integration.

⚠️ Closed List Warning

Unlike GDPR's "legitimate interest" which allows balancing of interests, Section 7 is a closed list. If processing doesn't fit one of these categories, consent is mandatory. There is no fallback "balancing test" β€” a significant compliance challenge for innovative data uses.

πŸ”™ Withdrawal of Consent (Section 6(6))

πŸ“– DPDPA 2023, Section 6(6)

"The Data Principal shall have the right to withdraw her consent at any time, with the ease of such withdrawal being comparable to the ease with which such consent was given, and the consequences of such withdrawal shall not affect the legality of processing of the personal data based on consent before its withdrawal."

The "Ease of Withdrawal" Principle

This provision embodies a simple but revolutionary principle: getting out must be as easy as getting in. If consent was obtained with one click, withdrawal cannot require a 20-page form, identity verification, and a phone call to customer service.

βš–οΈ Comparative: GDPR Article 7(3)

The EU's Article 7(3) similarly provides: "It shall be as easy to withdraw as to give consent." The CJEU in Planet49 (C-673/17) and the UK ICO's guidance have elaborated that this requires symmetry in the consent journey β€” a principle directly adopted by DPDPA.

Effects of Withdrawal

1

No Retrospective Effect

Processing based on consent before withdrawal remains lawful. The withdrawal is prospective only.

2

Cessation of Processing

The Data Fiduciary must cease processing for the withdrawn purpose as soon as reasonably practicable.

3

Trigger for Erasure

Withdrawal may trigger the right to erasure under Section 12(3), unless retention is required by law or other legitimate use applies.

⚠️ Common Compliance Failures

β€’ Requiring account deletion to withdraw consent
β€’ Hiding withdrawal options in obscure settings
β€’ Imposing waiting periods ("withdrawal effective in 30 days")
β€’ Demanding reasons for withdrawal
β€’ Requiring in-person verification for online consent withdrawal

🌐 GDPR Comparison: Six Bases vs. Two Grounds

Understanding the structural difference between GDPR and DPDPA is crucial for multinational compliance strategies.

GDPR Article 6(1) Basis DPDPA Equivalent Key Difference
(a) Consent Section 6 DPDPA adds "unconditional" requirement
(b) Contract Performance Section 7(a) (voluntary provision) DPDPA requires "specified purpose" at provision
(c) Legal Obligation Section 7(c) (court orders) DPDPA limited to judicial orders, not all legal obligations
(d) Vital Interests Section 7(d)-(e) (emergencies) Substantially similar
(e) Public Interest/Official Authority Section 7(b) (State functions) DPDPA requires statutory basis
(f) Legitimate Interest ❌ No equivalent Major gap β€” no balancing test in DPDPA

πŸ›οΈ Philosophical Divergence

The absence of a "legitimate interest" ground reflects India's more paternalistic approach to data protection. The GDPR trusts Data Controllers to balance interests; the DPDPA trusts only the enumerated situations. This reflects the Srikrishna Committee's concern: "In a country where power asymmetries are pronounced, leaving balancing to the controller may not serve the data principal's interests."

πŸ“‹ Practical Scenarios

πŸ“ Scenario 1: E-commerce Marketing

Situation: An e-commerce platform wants to send promotional emails to customers who made purchases.

Analysis: Section 7(a) (voluntary provision) covers transactional emails about orders. But marketing requires separate consent under Section 6 since it's not the "specified purpose" for which data was provided.

Solution: Obtain separate, unbundled consent for marketing at checkout with a clear opt-in checkbox (not pre-ticked).

πŸ“ Scenario 2: HR Analytics

Situation: A company wants to use employee data for AI-powered attrition prediction.

Analysis: Section 7(f) covers "employment purposes" but this may not extend to predictive analytics about employee behaviour. The purpose must be directly related to the employment relationship.

Solution: Conservative approach β€” obtain employee consent for analytics use, clearly explaining the AI processing. Alternatively, argue that retention management is an employment purpose (document this reasoning).

πŸ“ Scenario 3: Fintech KYC Sharing

Situation: A fintech wants to share KYC data collected for loan applications with partner insurance companies.

Analysis: Original consent was for loan processing. Sharing with insurance partners is a different purpose requiring fresh consent. Section 6(4) requires new consent when processing changes.

Solution: Either obtain specific consent for insurance partner sharing at origination, or seek fresh consent before sharing. Implement Consent Manager integration for easy management.

πŸ“ Scenario 4: Government Portal Data

Situation: A state government digitises land records and wants to make them searchable online.

Analysis: Section 7(b) permits State processing for statutory functions. Land record maintenance is a government function. However, making records publicly searchable may exceed the original function.

Solution: Ensure statutory backing for public disclosure. If the Land Revenue Code doesn't authorise public online access, either amend the law or provide opt-out mechanisms for landowners.

🎯 Key Takeaways

βš–οΈ

Two Grounds Only

DPDPA recognises only consent (Β§6) and legitimate uses (Β§7) β€” no "legitimate interest" balancing test exists.

βœ…

Seven Consent Characteristics

Valid consent must be free, specific, informed, unconditional, unambiguous, clear affirmative action, and limited to necessary data.

🀝

Consent Manager Innovation

India uniquely enables registered Consent Managers to help Data Principals manage consent across multiple fiduciaries.

πŸ“‹

Closed List of Legitimate Uses

Section 7 exhaustively enumerates legitimate uses β€” processing must fit one of these categories or require consent.

πŸ”™

Easy Withdrawal

Withdrawal must be as easy as giving consent β€” symmetry in the consent journey is legally mandated.

πŸ“œ

Document Everything

Burden of proving valid consent or legitimate use lies with the Data Fiduciary β€” maintain comprehensive records.