Section 6 - Consent

Key point

Clause-by-clause commentary on valid consent, necessity, invalid terms, consent design, withdrawal, processors, Consent Managers and proof under the Digital Personal Data Protection Act, 2023

Statutory provision

6. Consent. (1) The consent given by the Data Principal shall be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and shall signify an agreement to the processing of her personal data for the specified purpose and be limited to such personal data as is necessary for such specified purpose.

Illustration

X, an individual, downloads Y, a telemedicine app. Y requests the consent of X for: (i) processing her personal data for making available telemedicine services; and (ii) accessing her mobile phone contact list. X signifies consent to both. Since the contact list is not necessary for providing telemedicine services, her consent is limited to processing her personal data for making available telemedicine services.

(2) Any part of consent referred to in sub-section (1) which constitutes an infringement of the provisions of this Act, the Rules or any other law in force shall be invalid to the extent of that infringement.

Illustration

X buys an insurance policy using Y’s app or website. She agrees to processing for issuing the policy and to waive her right to complain to the Data Protection Board. The waiver is invalid.

(3) Every request for consent shall be presented in clear and plain language, with an option to access it in English or an Eighth Schedule language, and must provide contact details of the applicable Data Protection Officer or another authorised person.

(4) Where consent is the basis of processing, the Data Principal may withdraw it at any time, with ease comparable to the ease with which it was given.

(5) The consequences of withdrawal are borne by the Data Principal. Withdrawal does not affect the legality of consent-based processing undertaken before withdrawal.

(6) Following withdrawal, the Data Fiduciary must, within a reasonable time, cease and cause its Data Processors to cease the relevant processing, unless continued processing without consent is required or authorised by the DPDPA, the Rules or another Indian law.

(7) A Data Principal may give, manage, review or withdraw consent through a Consent Manager.

(8) A Consent Manager is accountable to the Data Principal and acts on her behalf in the prescribed manner.

(9) Every Consent Manager must be registered with the Board in the prescribed manner and subject to prescribed technical, operational, financial and other conditions.

(10) Where consent is relied upon and a question arises in a proceeding, the Data Fiduciary must prove that the required notice was given and valid consent was obtained.

1. The legal function of Section 6

Section 6 does not answer the first question in a data-processing assessment. Section 3 first determines whether the Act applies. Section 4 then requires a lawful purpose and an authorised ground. Section 6 governs the quality, scope, operation and proof of consent when consent is the selected ground under Section 4(1)(a).

The structure can be stated simply:

1. Does the DPDPA apply?
2. Is the purpose lawful?
3. Is consent the correct ground?
4. Was a Section 5 and Rule 3 notice given?
5. Does the consent satisfy every element of Section 6(1)?
6. Is the processing limited to necessary data and the specified purpose?
7. Can consent be withdrawn with comparable ease?
8. Can the Data Fiduciary prove all of the above?

Consent is only one of the DPDPA’s processing grounds. It is not necessary where a particular Section 7 legitimate use properly applies. Equally, Section 7 should not be stretched merely because obtaining consent is inconvenient.

The following distinctions remain important:

The legal question is not whether consent can be collected. It is whether consent is genuine, appropriate and sufficiently limited for the processing.

2. Section 6(1): The cumulative nature of valid consent

Section 6(1) lists several requirements joined by the word “and.” These requirements are cumulative.

Consent must be:

1. free;

2. specific;

3. informed;

4. unconditional;

5. unambiguous;

6. expressed through clear affirmative action;

7. an agreement to processing for a specified purpose; and

8. limited to personal data necessary for that purpose.

Failure of any material requirement can make the consent invalid.

A consent can be informed but not free. It can be free but not specific. It can be specific but obtained through inactivity. It can be affirmative but cover unnecessary data. The presence of some elements does not repair the absence of another.

2.1 Consent validity chart

1. FREE No improper pressure or manipulation
2. SPECIFIC A defined and bounded purpose
3. INFORMED Proper notice and real understanding
4. UNCONDITIONAL No unrelated processing forced as a condition
5. UNAMBIGUOUS The choice clearly indicates agreement
6. CLEAR AFFIRMATIVE ACTION A positive act, not silence or default
7. NECESSARY DATA ONLY No excessive collection = VALID CONSENT

The EDPB’s Guidelines 05/2020 similarly analyse consent through the cumulative ideas of freely given, specific, informed and unambiguous agreement, with separate attention to imbalance, conditionality, granularity, detriment, proof and withdrawal. These principles are persuasive in understanding similar language in Section 6, but they do not replace the Indian text.

3. “The consent given by the Data Principal”

The consent must be attributable to the relevant Data Principal.

This requires the Data Fiduciary to know:

• whose data is involved;

• who gave the consent;

• whether that person was authorised to do so;

• what purpose was agreed to;

• when consent was given;

• which notice was shown;

• whether consent remains active.

4. Data about more than one person

A person may provide information about another person.

Example

For example:

• an employee provides spouse and child data for insurance;

• a guest provides a companion’s details;

• a customer supplies a nominee’s information;

• an emergency contact is recorded;

• an applicant provides a referee’s details.

The employee or customer does not automatically become the sole Data Principal for all those records. The spouse, child, nominee, companion or referee may be a separate Data Principal.

An employer may rely on Section 7(i) to process dependent information needed to provide a benefit sought by the employee. That does not mean the employer should pretend that the employee has given consent on behalf of every adult family member for unrelated processing.

5. Children and persons with lawful guardians

Where the Data Principal is a child or a person with disability who has a lawful guardian, Sections 9 and the final Rules prescribe a verifiable-consent framework.

Ordinary account creation is not enough. The Data Fiduciary must apply the prescribed verification requirements and establish the legal relationship of the parent or guardian where applicable.

6. Identity verification should remain proportionate

The Data Fiduciary must prove consent, but it should not collect excessive identity information merely to prove who clicked a button.

For low-risk marketing consent, recording the account, timestamp, notice version and affirmative action may be sufficient. Requiring Aadhaar merely to prove consent to receive a newsletter would ordinarily be excessive.

7. “Shall be free”

Free consent requires real choice and control.

The Data Principal must be able to refuse or withdraw without being exposed to an improper penalty, deception or unrelated disadvantage.

The word “free” does not mean that refusal can never have any consequence. If personal data is genuinely required to provide the requested feature, refusal may make that feature technically impossible. The key distinction is between:

• a functional consequence arising because the necessary data has been withheld; and

• a punitive consequence imposed to pressure a person into agreeing to unnecessary processing.

7.1 Functional consequence versus coercive condition

8. No coercion

Consent is not free when obtained through:

• threats;

• economic pressure unrelated to the service;

• employment retaliation;

• denial of a core service because optional processing was refused;

• misleading statements about necessity;

• manipulation of vulnerable persons;

• withholding benefits to force unrelated consent.

9. Imbalance of power

Power imbalance is particularly relevant in:

• employment;

• education;

• healthcare;

• financial services;

• public services;

• landlord-tenant relationships;

• dominant online platforms.

The EDPB identifies employment as a classic setting in which consent may not be freely given because the employee may fear adverse consequences. Its guidance suggests that employee consent is credible mainly where the processing is genuinely optional and refusal creates no detriment.

The DPDPA partly reduces this problem by creating Section 7(i). Employers can use the legitimate-use ground for core employment processing rather than forcing employees to consent.

10. Dark patterns

India’s Guidelines for Prevention and Regulation of Dark Patterns, 2023 define dark patterns as deceptive UI or UX practices designed to mislead users into doing something they did not intend, by impairing autonomy, choice or decision-making. The Guidelines apply to covered platforms, advertisers and sellers and prohibit dark patterns.

A manipulative interface may therefore create both:

• a consumer-protection issue; and

• an invalid-consent issue under Section 6.

10.1 Confirm shaming

Invalid example:

• “Yes, protect my privacy.”

• “No, I like being unsafe.”

The refusal option is framed to produce guilt or fear.

Neutral version:

• “I consent.”

• “I do not consent.”

10.2 Visual asymmetry

A large, bright “Accept all” button beside a tiny grey refusal link can distort user choice. Section 6 does not expressly prescribe identical button dimensions or colours, but extreme visual suppression of refusal can show that consent was not free or unambiguous.

It is too rigid to say that accept and reject buttons must always be geometrically identical. The legal concern is whether the interface materially manipulates choice.

10.3 False urgency

A countdown stating that privacy consent will “expire in two minutes” may prevent considered and informed choice where no genuine deadline exists.

10.4 Basket sneaking

A preselected consent for partner marketing hidden inside checkout does not represent clear affirmative action.

10.5 Forced action

The CCPA’s 2026 enforcement action concerning digital platforms included findings involving preselected options and mandatory collection of personal information for content advertised as free. The authority stressed that consent cannot be assumed through preselection and should arise from clear affirmative action. Although consumer law and the DPDPA are distinct, the enforcement approach illustrates the regulatory concern surrounding manipulated consent.

11. When service conditioning is permissible

The supplied material correctly identifies necessity as central, but the proposition that a platform may condition access only where data is strictly technically necessary should be expressed with care.

Section 6 requires consent to be limited to data necessary for the specified purpose and to be unconditional. The relevant necessity may arise from:

• the inherent function of the service;

• legal requirements;

• security requirements;

• the particular optional feature requested;

• the agreed processing purpose.

It is not always limited to literal technical impossibility.

Example

For example, a bank may need identity information to comply with applicable KYC requirements even though its software could technically open an account without it. The processing can be legally necessary, not merely mechanically necessary.

11.1 Case study 1: Maps application

A user refuses current-location access.

The application may be unable to provide live turn-by-turn navigation from the user’s present location. It should still offer functions not requiring location, such as manually searching a place, if available.

11.2 Case study 2: Telemedicine

A telemedicine application requests camera and microphone access for a video consultation.

These permissions are functionally connected to the requested service. Contact-list access is not.

11.3 Case study 3: Banking application

A bank requests identity data required for account opening and separately requests consent for advertising.

The bank may refuse account opening if legally required identification is not supplied. It should not refuse solely because marketing consent was denied.

12. Consent-or-pay and differential pricing

A “consent-or-pay” model offers a choice between:

• consenting to personal-data processing, often behavioural advertising; or

• paying for a service without that processing.

Section 6 does not expressly prohibit every paid privacy alternative. Nor does it expressly authorise one.

The validity of such a model depends on context, including:

• market power;

• the amount charged;

• availability of meaningful alternatives;

• whether the paid version is equivalent;

• whether refusal causes exclusion from an important service;

• categories and intensity of tracking;

• vulnerability of users;

• whether a free, less intrusive alternative is available.

The EDPB’s Opinion 08/2024 is limited to consent-or-pay models used by large online platforms for behavioural advertising. It concludes that a binary choice between behavioural-advertising consent and a fee will, in most cases, not generate valid consent for such platforms. It recommends considering an equivalent alternative without behavioural advertising, including a free option based on less or no personal data. This is persuasive comparative guidance, not an automatic Indian prohibition.

Therefore, it would be too broad to state that every Indian platform charging non-consenting users necessarily violates Section 6. The proper conclusion is that the model presents serious risks under the requirements of free and unconditional consent, especially for dominant or essential platforms.

13. “Specific”

Consent must relate to a defined purpose.

Specificity prevents a Data Fiduciary from obtaining one broad agreement and treating it as permission for every current and future use.

14. Purpose specificity

The following expressions are ordinarily too vague:

• improve your experience;

• business purposes;

• analytics;

• research;

• service improvement;

• marketing purposes;

• security purposes;

• AI development;

• sharing with partners;

• any lawful activity.

A purpose is more specific when the person can understand:

• what will be done;

• why it will be done;

• which personal data is involved;

• what outcome or service it enables.

14.1 Purpose examples

15. Granularity

Separate purposes should permit separate choices.

A fintech application should not use one checkbox for:

• identity verification;

• fraud prevention;

• credit assessment;

• partner marketing;

• behavioural advertising;

• contact-list access.

A user may be willing to provide identity documents to open an account while refusing promotional profiling.

Granularity does not necessarily require one checkbox for every database field. It requires meaningful control over materially distinct purposes.

16. Functionally inseparable processing

Some operations may be described together where they form a single coherent purpose.

Example

For example, an order-fulfilment process may reasonably involve:

• confirming the order;

• processing payment;

• preparing the goods;

• arranging delivery;

• communicating delivery status.

However, promotional profiling should not be bundled into “fulfilling your order.”

17. Applicants, interns and employees under the specificity requirement

18. Applicants

An applicant’s consent should distinguish:

• assessment for the current vacancy;

• background verification;

• psychometric testing;

• retention for future vacancies;

• sharing with group companies;

• use in recruitment-model training;

• marketing of courses or services.

Consent to apply for one vacancy is not consent to indefinite retention or commercial AI training.

19. Interns and trainees

A non-employee intern’s consent should distinguish:

• programme administration;

• attendance;

• stipend payment;

• access control;

• assessment;

• certificate issuance;

• promotional photography;

• future programme invitations.

20. Employees

Core employment processing should ordinarily rely on Section 7(i), not consent.

Where consent is used, purposes should remain genuinely optional, such as:

• publication of a testimonial;

• voluntary wellness research;

• optional alumni marketing;

• promotional photography;

• disclosure to a commercial benefits partner beyond core administration.

An employer cannot solve the power imbalance by writing “specific” purposes while continuing to make them mandatory.

21. “Informed”

Consent is informed only if the Data Principal receives sufficient information before deciding.

Section 5 and Rule 3 form the principal notice framework. The notice must identify:

• the personal data;

• the specified purpose;

• the goods or services enabled by the processing;

• withdrawal mechanism;

• rights mechanism;

• grievance and Board complaint route.

Rule 3 requires the notice to be independently understandable, written in clear and plain language and to contain an itemised description of the data and purpose.

22. Notice must correspond with reality

Consent is not informed where the notice says data is used for account administration but the system also:

• creates advertising profiles;

• shares data with brokers;

• trains a model;

• tracks precise location;

• accesses the contact list;

• performs facial recognition.

23. Hidden information

Material information should not be hidden:

• at the end of a lengthy terms document;

• behind several links;

• beneath the consent button;

• in an unrelated policy;

• in language the user did not select;

• in technical terminology.

Layered notices are permissible in principle where the core information is prominent and further detail is easily accessible. The EDPB’s transparency guidance supports concise, intelligible and layered communication, provided the approach does not conceal material information.

24. Consent cannot be informed through fiction

A Data Fiduciary should not say:

“By clicking agree, you confirm that you have read and understood every policy.”

A declaration does not prove actual intelligibility where the interface or content is deliberately confusing.

24.1 Case study 1: Hospital model training

A hospital tells patients that information is collected for “care and quality improvement” but transfers identifiable records to a technology company to build a commercial model.

The model-training purpose was not clearly disclosed. Consent to treatment does not automatically cover commercial product development.

24.2 Case study 2: Social-media advertising

A retailer asks users to consent to “better services” and uploads identifiers to a platform for matched audiences.

The consent is not informed because the matching and advertising purpose is concealed.

24.3 Case study 3: Workplace photograph

An employer asks an employee to submit a photograph “for HR purposes” and later publishes it in advertising.

The original information did not explain publication. A separate informed consent is required.

25. “Unconditional”

The word “unconditional” is an express feature of the DPDPA.

It means that consent should not be tied to acceptance of personal-data processing that is unnecessary for the specified purpose.

A consent can be specific and informed but still conditional. For example:

“We clearly tell you that we will sell your purchase history to advertisers, and you cannot buy from us unless you agree.”

The disclosure may be specific and informed, but the consent remains conditional on unrelated processing.

26. Necessary conditions versus unrelated conditions

Consent does not become conditional merely because supplying necessary data is required for a requested feature.

Example

Examples:

• a delivery address for home delivery;

• location for live navigation;

• a camera feed for a video consultation;

• email address for an email newsletter;

• photograph for a requested digital identity card.

The problem arises where an unrelated use is made a condition of the core service.

27. Optional programmes

An employer may say:

“To participate in the voluntary wellness programme, you must consent to processing the health information necessary to deliver that programme.”

That is not necessarily improper. The employee can refuse the programme without employment detriment.

The employer should not say:

“All employees must join the voluntary programme or lose appraisal points.”

28. “Unambiguous with a clear affirmative action”

These words require an observable positive act that clearly shows agreement.

Valid mechanisms may include:

• an unchecked box actively selected;

• an off-state toggle actively switched on;

• a signed statement;

• a spoken affirmative response recorded through an appropriate process;

• an electronic signature;

• selecting “I consent” after the notice;

• choosing specific purposes in a consent dashboard.

Invalid or high-risk mechanisms include:

• silence;

• inactivity;

• pre-ticked boxes;

• pre-enabled toggles;

• continued browsing;

• scrolling;

• failure to opt out;

• “we will assume consent unless you object”;

• bundled acceptance of all terms without a distinct choice.

The EDPB states that consent requires an active indication and that silence, inactivity, pre-ticked boxes and general scrolling do not ordinarily establish valid consent. This is strongly persuasive under the DPDPA’s even more explicit reference to “clear affirmative action.”,

29. Consent through conduct

Not every physical act should be treated as consent.

Entering premises after seeing a CCTV sign may be relevant to Section 7(a), but it does not necessarily satisfy the formal Section 6 requirement for clear affirmative action.

Handing over a phone number in response to a clear request may be voluntary provision under Section 7(a). It may also represent affirmative consent in context if proper notice and choice are established. The grounds should not be conflated.

30. Recorded oral consent

Oral consent can potentially be affirmative if:

• the notice is communicated clearly;

• the person expressly agrees;

• the purpose is specific;

• the Data Fiduciary preserves reliable proof;

• withdrawal remains accessible.

A generic call-centre note stating “customer agreed” may be insufficient under Section 6(10).

31. “Shall signify an agreement”

Consent reflects agreement, not mere awareness.

A person may know that cameras operate in a building but not agree to facial recognition. A patient may know that a hospital stores records but not agree to commercial model training. An employee may acknowledge receiving a privacy notice without consenting to optional publicity.

The legal act should therefore be labelled correctly:

32. “For the specified purpose”

The definition of specified purpose connects Section 6 with the notice under Section 5.

Consent is bounded by the purpose communicated to the Data Principal. Once the processing moves beyond that purpose, the original consent no longer supplies the required ground.

32.1 Purpose creep

The DPDPA does not establish a broad compatibility test equivalent to the GDPR’s further-processing framework. A Data Fiduciary should not assume that a new use is lawful merely because it is related or commercially useful.

33. “Limited to such personal data as is necessary”

This is one of the strongest parts of Section 6(1).

Consent cannot authorise collection of data unnecessary for the specified purpose.

The Act therefore rejects the argument:

“The user agreed, so we may collect it.”

Even genuine agreement is legally limited by necessity.

34. The telemedicine illustration

A contact list is not necessary to provide a telemedicine consultation. Consequently, even where the user selects both permissions, consent is effective only for the data necessary to provide the telemedicine service.

The statutory illustration produces an important rule:

34.1 Consent is not a cure for excessive collection.

35. Assessing necessity

The Data Fiduciary should ask:

1. What exactly is the specified purpose?

2. Can the purpose reasonably be achieved without this data?

3. Is less data sufficient?

4. Can precision be reduced?

5. Can data remain on the device?

6. Can anonymous or aggregated information be used?

7. Is continuous collection required, or only event-based collection?

8. How long is the data needed?

35.1 Necessity examples

36. Precision and duration

Necessity concerns not only categories but also:

• granularity;

• frequency;

• duration;

• retention;

• recipients.

A weather application may need approximate city-level location, not continuous precise GPS tracking. A fraud investigation may require records for a defined period, not the employee’s complete historical communications.

37. Section 6(2): Invalidity to the extent of infringement

Section 6(2) invalidates any part of consent that infringes:

• the DPDPA;

• the Rules;

• another Indian law in force.

The phrase “to the extent of such infringement” introduces statutory severability.

A consent may contain lawful and unlawful parts. The unlawful part is invalid. The remaining part may survive if it is legally and functionally independent.

38. Rights cannot be waived contrary to the Act

The statutory illustration confirms that a Data Principal cannot validly waive the right to complain to the Board.

Other problematic terms may include purported waivers of:

• consent withdrawal;

• grievance redressal;

• applicable correction or erasure rights;

• breach-related entitlements;

• rights arising under consumer, employment or sectoral law.

39. Consent cannot excuse non-compliance

Invalid clauses include:

• “You consent to us storing your data without security.”

• “You consent to us ignoring any withdrawal.”

• “You consent to collection of any data we may choose.”

• “You consent to processing for unlawful discrimination.”

• “You waive all remedies under the DPDPA.”

• “You agree that processors need not stop after withdrawal.”

40. Severability has limits

Suppose an insurance consent contains:

1. consent to process identity and health information to issue a policy;

2. a waiver of the right to complain to the Board.

Part 2 is invalid. Part 1 may survive.

But where an invalid term is inseparable from the central bargain, the entire consent may be compromised. For example, if the consent request conceals its real prohibited purpose, deleting one sentence may not cure the lack of informed agreement.

40.1 Case study 1: Employment waiver

An employment form states that the employee permanently waives the right to withdraw consent for use of her photograph.

The waiver is invalid. The employer cannot contract out of Section 6(4).

40.2 Case study 2: Consumer complaint waiver

An application says that consent to personalised advertising includes agreement never to approach the Board.

The complaint waiver is invalid.

40.3 Case study 3: Unlawful third-party disclosure

A professional obtains client consent to disclose information where another law absolutely prohibits disclosure.

The consent is invalid to the extent of the prohibited disclosure.

41. Section 6(3): Clear and plain language

Every consent request must be presented in clear and plain language.

This requirement concerns the request, not merely the underlying privacy notice.

The consent control should tell the Data Principal what decision is being made.

41.1 Inadequate

“I agree to data processing in accordance with all applicable policies and business requirements.”

41.2 Better

“I consent to The Imperial using my photograph and job title on its public website and official social-media pages to promote its employer brand.”

42. Audience-specific communication

Clear language depends on the audience.

A notice designed for:

• consumers;

• hotel guests;

• employees;

• teenagers;

• rural users;

• medical patients;

• persons with disabilities;

may require different language, examples and presentation.

43. Technical processing

Technical concepts should be explained through effects.

Instead of:

“We perform embedding-based vector similarity analysis.”

Say:

“We convert your photograph into a numerical facial template and compare it with enrolled templates to verify your identity.”

Instead of:

“We use automated inference architecture.”

Say:

“An automated tool will use your application information to generate a suitability score for the vacancy.”

44. Language choice

Section 6(3) requires an option to access the consent request in:

• English; or

• any language specified in the Eighth Schedule.

The language choice should be available before consent is given.

It should cover:

• the request;

• the purpose;

• the data categories;

• consent buttons;

• refusal controls;

• withdrawal mechanism;

• contact details.

A Hindi notice followed by English-only consent buttons and withdrawal settings does not provide a coherent language experience.

Translation should preserve legal meaning without becoming unreadable. Machine translation should be reviewed, particularly for terms such as:

• consent;

• withdrawal;

• grievance;

• biometric information;

• automated processing;

• sharing;

• profiling;

• retention.

45. Contact details

The consent request must provide contact details of:

• the Data Protection Officer, where applicable; or

• another person authorised to respond to communications concerning the Data Principal’s rights.

The contact must be functional.

A placeholder such as privacy@________ does not comply in an operational consent mechanism.

The contact channel should:

• accept relevant communications;

• provide acknowledgement;

• route requests appropriately;

• support language and accessibility needs;

• remain available after account closure or employment exit;

• not require engagement through an inaccessible portal.

The contact person is not necessarily a registered Consent Manager. An internal privacy contact, DPO and Consent Manager are distinct roles.

46. Section 6(4): Withdrawal at any time

Where consent is the ground, withdrawal is a continuing right.

The words “at any time” mean that a Data Fiduciary cannot:

• create a non-withdrawable consent;

• impose a fixed lock-in period;

• permit withdrawal only once a year;

• require completion of the original purpose before withdrawal;

• deny withdrawal because processing has already begun.

The consequences of withdrawal may vary, but the request must be accepted.

47. Withdrawal does not require justification

The Data Principal should not be required to explain why consent is withdrawn.

An optional feedback field may be offered, but it should not block the withdrawal.

48. Granular withdrawal

Where consent was purpose-specific, withdrawal should be purpose-specific.

A customer should be able to stop marketing without closing the shopping account. An employee should be able to withdraw publicity consent without affecting payroll. An applicant should be able to leave a future talent pool without withdrawing an active application.

49. Comparable ease and the symmetry principle

Section 6(4) requires comparable ease, not necessarily an identical interface.

If consent was given in one or two simple actions, withdrawal should not require:

• a telephone call during office hours;

• a notarised letter;

• physical attendance;

• multiple hidden menu layers;

• several confirmation screens;

• lengthy manual verification;

• thirty working days without justification.

50. Comparability is contextual

An additional authentication step may be legitimate where needed to prevent malicious withdrawal from another person’s account.

Example

For example, entering a password before changing an account-wide privacy preference may be reasonable if the same or equivalent authentication protected the original consent.

It is too broad to say that any password confirmation automatically violates Section 6(4). The question is whether the additional friction is reasonably connected with security or is designed to obstruct withdrawal.

51. Problematic withdrawal patterns

51.1 Customer-service detour

Consent is given through one click, but withdrawal requires a telephone call.

51.2 Multi-layer maze

The control is buried under numerous unrelated settings.

51.3 Mandatory explanation

The user cannot proceed without selecting a reason.

51.4 Confirmation loop

Repeated warnings pressure the user to abandon withdrawal.

51.5 Email black hole

The user must email a generic address with no acknowledgement or timeline, although consent was captured instantly in-app.

52. Section 6(5): Consequences of withdrawal

The consequences of withdrawing consent are borne by the Data Principal.

This provision should not be read as permission to punish withdrawal.

It recognises that a service or feature dependent upon the consent may no longer be available.

53. Functional consequences

Example

Examples include:

• a customer withdraws delivery-address consent, so future home delivery cannot be provided;

• a user withdraws location consent, so location-based recommendations stop;

• an employee withdraws consent for an optional wellness programme, so participation ends;

• an applicant withdraws future-talent-pool consent, so later vacancies will not be offered through that pool.

54. Punitive consequences

Example

Examples include:

• lowering an employee’s appraisal because she withdrew publicity consent;

• delaying customer support because marketing consent was withdrawn;

• imposing an arbitrary fee solely as retaliation;

• denying an unrelated purchased service;

• publicly identifying persons who refused.

The word “consequences” should be linked to the actual dependence of the service on the withdrawn consent.

55. Prior processing remains lawful

Withdrawal does not affect the legality of consent-based processing undertaken before withdrawal.

This assumes that the original consent was valid.

If the original consent was coerced, vague or uninformed, Section 6(5) does not retrospectively cure the invalidity. The clause protects prior processing only where it was lawfully based on consent at the time.

55.1 E-commerce illustration

The statutory illustration distinguishes:

• future use of the shopping service; and

• completion of an order already placed and paid for.

After withdrawal, the platform may stop enabling future orders, but it may still process the data necessary to supply the already purchased goods.

This does not mean that every operation connected with the account may continue. Marketing and unrelated profiling should stop.

56. Section 6(6): Cessation within a reasonable time

After withdrawal, the Data Fiduciary must:

1. cease the relevant processing within a reasonable time; and

2. cause its Data Processors to cease that processing.

The statute does not require universal instantaneous cessation. The relevant standard is reasonable time.

What is reasonable depends on:

• type of processing;

• level of automation;

• risk to the individual;

• number of processors;

• active campaigns;

• system architecture;

• legal-retention requirements;

• safety and fraud concerns.

High-speed digital processing should normally be capable of rapid cessation. A business should not design its systems so poorly that withdrawal takes months.

57. The telecom illustration

Where a customer chooses app-only billing, the telecom provider must stop emailing bills and require the email processor to stop.

The illustration demonstrates purpose-level withdrawal. The provider may continue processing account information needed to provide telecom services and issue the bill through the selected app.

58. Processor cascade

The duty expressly extends to processors acting for the Data Fiduciary.

Relevant processors may include:

• email providers;

• SMS gateways;

• payroll vendors;

• advertising agencies;

• cloud providers;

• background-verification vendors;

• AI service providers;

• recruitment platforms.

Contracts should require processors to implement cessation instructions promptly.

59. Independent recipients

The statutory wording expressly says “Data Processors.” It does not state in Section 6(6) that every independent third-party Data Fiduciary or recipient must automatically erase data merely because the original Data Principal withdrew consent from the first Data Fiduciary.

If an independent recipient relies on its own consent or another ground, its position requires separate analysis. If the first Data Fiduciary had no authority to transfer the data, withdrawal is not the only issue.

Accordingly, the statement that Section 6 creates a universal deletion cascade across every third-party recipient is too broad.

60. Withdrawal and erasure

Cessation and erasure are related but distinct.

• Cessation means stopping the relevant processing.

• Erasure means deleting the relevant personal data.

• Retention restriction may mean holding data only for a continuing legal purpose.

Section 8(7) addresses erasure when the Data Principal withdraws consent or when the specified purpose is no longer served, unless retention is necessary for compliance with law.

The Data Fiduciary should determine:

• whether the data is used only for the withdrawn purpose;

• whether the same data is needed for another authorised purpose;

• whether a legal retention rule applies;

• whether processor copies must be erased;

• whether backup deletion follows a controlled cycle;

• whether a suppression record is needed to honour the withdrawal.

60.1 Example: Marketing suppression

A customer withdraws marketing consent.

The business may delete the customer’s information from active marketing systems while retaining a minimal suppression record to prevent accidental re-enrolment, if that limited processing has a valid basis.

60.2 Example: Bank records

A bank customer withdraws marketing consent.

The bank must stop marketing use but may retain KYC and transaction information required under applicable financial laws. The retained information cannot continue to be used for marketing.

60.3 Example: Applicant

A rejected applicant withdraws future-talent-pool consent.

The employer should erase the talent-pool copy unless retention is needed for a particular legal claim or other authorised purpose. It should not continue general recruitment profiling.

61. Switching grounds after withdrawal

A Data Fiduciary should not obtain consent and, after withdrawal, suddenly claim that the same processing was always a Section 7 legitimate use.

Grounds are not interchangeable escape routes.

However, the same personal data may lawfully be processed for separate purposes on separate grounds.

Example

For example:

• employee bank details for payroll under Section 7(i);

• employee bank details supplied to a commercial lender under consent.

If the employee withdraws lender-sharing consent, payroll processing may continue.

The Data Fiduciary should document the purposes and data flows separately rather than “switching” the original marketing activity to employment use.

The EDPB similarly discourages controllers from retrospectively moving to another lawful basis after consent fails. This comparative approach is useful because it protects predictability and accountability.

62. Section 6(7): Consent Manager

A Data Principal may use a Consent Manager to:

• give consent;

• manage consent;

• review consent;

• withdraw consent.

Use of a Consent Manager is optional. A Data Fiduciary may continue to obtain and manage consent directly.

The statutory Consent Manager is not merely:

• a cookie banner;

• an internal preference centre;

• a generic consent-management software product;

• the Data Fiduciary’s DPO;

• a processor that stores consent records.

It is a person registered with the Board to provide a single, accessible, transparent and interoperable platform through which Data Principals can manage consent across participating Data Fiduciaries.

63. Giving consent

The platform may communicate a consent decision to a Data Fiduciary.

64. Managing consent

The Data Principal should be able to view active consent relationships and alter them where permitted.

65. Reviewing consent

The Data Principal should be able to see:

• Data Fiduciary;

• purpose;

• data concerned;

• date;

• status;

• withdrawal route.

66. Withdrawing consent

The Consent Manager should communicate withdrawal reliably to the relevant Data Fiduciary. The Data Fiduciary then remains responsible for implementing cessation and processor instructions.

67. Section 6(8): Accountability to the Data Principal

The Consent Manager acts on behalf of and is accountable to the Data Principal.

This distinguishes it from a processor acting on behalf of a Data Fiduciary.

DATA PROCESSOR

Acts on instructions of the Data Fiduciary

CONSENT MANAGER

Acts on behalf of the Data Principal and is accountable to the Data Principal

The Consent Manager should not manipulate users into consenting because a Data Fiduciary pays it more. Its design should remain neutral and transparent.

Potential conflicts include:

• preferential presentation of certain Data Fiduciaries;

• financial rewards based on consent volume;

• hiding withdrawal;

• using consent records for advertising;

• linking consent signals with unrelated commercial profiles;

• selling insights about Data Principals.

The final Rules therefore impose governance, independence, security, record and audit requirements.

68. Section 6(9) and Rule 4: Registration

Every statutory Consent Manager must be registered with the Board.

Rule 4 and the First Schedule establish the registration and continuing-obligation framework. Public summaries of the final Rules identify requirements including Indian incorporation, a minimum net worth of ₹2 crore, technical and operational capacity, governance standards, conflict management, audit and record obligations. Rule 4 is scheduled to commence on 13 November 2026.

As of 11 August 2026, the statutory registration framework has not yet commenced. Organisations should therefore avoid presenting an ordinary consent-software vendor as a registered DPDPA Consent Manager before that status has actually been granted.

68.1 Consent Manager versus software platform

69. Rule 4 and the First Schedule

The final framework requires the Consent Manager to operate as more than a storage vault for “yes” and “no” signals.

Its obligations are understood to include:

• enabling consent lifecycle management;

• maintaining consent records;

• providing access to records;

• implementing security measures;

• avoiding conflicts of interest;

• operating an accessible and interoperable platform;

• undergoing audit;

• maintaining governance and financial capability;

• complying with Board directions.

The final statutory and Rule text should remain the controlling source. Secondary descriptions that refer to “real-time cascading,” universal portability or specific technical standards should not be treated as enacted requirements unless the final Rules expressly contain them.

A Consent Manager may transmit withdrawal rapidly, but Section 6(6) still gives the Data Fiduciary a reasonable time to cease processing.

70. Section 6(10): Burden of proof

Where consent is relied upon and the issue arises in a proceeding, the Data Fiduciary must prove:

1. the required notice was given;

2. the Data Principal gave consent;

3. notice and consent complied with the Act and Rules.

The burden does not rest on the Data Principal to prove that consent was absent.

A database entry saying consent = yes may be insufficient because it does not show:

• what notice was displayed;

• which purpose was presented;

• which data was identified;

• what language was used;

• whether the box was preselected;

• what the user did;

• whether consent was later withdrawn.

71. Minimum evidentiary record

A sensible record may include:

• Data Principal or account identifier;

• Data Fiduciary identity;

• timestamp;

• notice version;

• language;

• specified purpose;

• data categories;

• affirmative action;

• channel;

• consent status;

• withdrawal timestamp;

• processor instruction status.

72. IP address and device identifiers

Recording IP address and device identifiers may sometimes help prove the interaction, but Section 6(10) does not mandate that these fields always be collected.

Collecting them by default for every consent could itself become excessive. Evidence should be proportionate to the risk and context.

73. Immutable or cryptographic logs

The Act does not expressly require every Data Fiduciary to maintain blockchain-based, cryptographically immutable consent logs.

Tamper-evident audit systems may be excellent practice for high-volume or high-risk processing, but they should not be described as an explicit statutory requirement unless prescribed.

The legal requirement is proof. The technical method may vary.

74. Screenshots alone

Screenshots show the interface but not necessarily the individual’s action. A complete evidentiary package should connect:

• the version of the notice;

• the user session;

• the action;

• the purpose-level record;

• subsequent changes.

75. Employees

Core employment processing should not be built around forced consent.

Section 7(i) supports genuine employment processing and protection of the employer, including:

• payroll;

• attendance;

• performance administration;

• workplace access;

• investigations;

• protection of trade secrets;

• prevention of corporate espionage;

• provision of employee-requested benefits.

Consent remains relevant for genuinely optional activity.

75.1 Employee consent case study 1: Public testimonial

An employee is asked to appear in a public recruitment video.

Valid consent requires:

• a specific description of channels;

• no effect on employment if refused;

• a defined purpose;

• ability to withdraw future use;

• clear treatment of already distributed material.

75.2 Employee consent case study 2: Optional wellness programme

An employer offers a health-assessment programme.

Consent is not free if managers receive non-participant lists or refusal affects appraisal. The Data Fiduciary should isolate participation from employment decisions.

75.3 Employee consent case study 3: Financial offers

An employer offers to share salary and contact information with a lender.

This is not core employment processing merely because employees may benefit. Separate consent should identify the lender, data, purpose and consequences.

76. Applicants and candidates

Applicants are not ordinarily employees. Their data may be processed under Section 7(a) for the specified purpose for which they voluntarily applied. Consent remains appropriate for additional activities.

76.1 Applicant consent should be separated for:

• background checks;

• psychometric testing;

• future retention;

• group-company sharing;

• recruitment AI training;

• publicity;

• unrelated marketing.

76.2 Case study 1: Future talent pool

An applicant is unsuccessful for Vacancy A. The employer wishes to retain the CV for twelve months.

The employer should seek specific consent. Refusal should not affect the completed assessment.

76.3 Case study 2: AI model training

The employer wants to use historical CVs and interview scores to train a general screening model.

This is different from assessing the applicant’s own application. Fresh consent should ordinarily be obtained unless another exact ground applies.

76.4 Case study 3: Reference checks

The applicant supplies referees and consents to contact for defined verification.

The employer should not use that consent to investigate unrelated personal relationships or collect irrelevant information.

77. Interns and trainees

Where an intern or trainee is not an employee, consent should ordinarily support programme processing unless Section 7(a) or another precise ground applies.

Consent should identify:

• identity information;

• academic records;

• attendance;

• stipend data;

• evaluation;

• access control;

• certificate issuance;

• optional publicity.

The organisation should not use one compulsory checkbox for programme administration, social-media publicity and future marketing.

If the actual relationship is legally employment, Section 7(i) may apply despite the “trainee” label.

78. Marketing

Marketing is a principal consent use case.

79. Transactional and promotional communication

A phone number provided to receive an invoice may be used for that specified purpose under Section 7(a). Promotional use is separate.

80. Channel-specific control

A customer may consent to email but not:

• SMS;

• WhatsApp;

• telephone calls;

• personalised advertising;

• partner marketing.

Consent should be granular where channels or purposes differ materially.

81. Matched audiences

Where identifiers are uploaded to an advertising platform, consent should explain:

• data shared;

• platform or recipient category;

• account matching;

• advertising purpose;

• profiling or lookalike creation;

• withdrawal.

82. Marketing withdrawal

Withdrawal should promptly suppress future campaigns. A campaign irreversibly dispatched before withdrawal may not be retrievable, but no new processing should be initiated solely on withdrawn consent.

83. AI training

AI training is a purpose, not a legal ground.

If consent supports training, it should specify:

• data sources;

• training purpose;

• model function;

• whether individual scores are generated;

• vendor use;

• whether the vendor improves a general model;

• material retention implications;

• withdrawal mechanism.

84. General model improvement

“Improve our services” is ordinarily inadequate to describe contribution to a general commercial AI model.

85. Withdrawal after training

Withdrawal creates difficult technical questions where data has affected model parameters.

The Data Fiduciary should not promise instantaneous “unlearning” unless technically capable. It should explain what withdrawal can practically stop while complying with erasure duties relating to identifiable source records, retraining datasets and future use.

The DPDPA does not expressly define when a trained model itself constitutes personal data or prescribe machine unlearning. These remain significant grey areas.

86. Derived outputs

A model-generated score or prediction may itself be personal data and require a ground, even if source data was lawfully processed.

87. CCTV and facial recognition

Ordinary CCTV should not be forced into a consent framework where consent is unrealistic.

Potential grounds include:

• Section 3(c)(i) for domestic activity;

• Section 7(a) for voluntary entry after clear notice, though legally unsettled;

• Section 7(i) for employer protection;

• Section 7(d) for legally mandated surveillance and disclosure.

Where consent is actually used, such as optional facial-recognition access, Section 6 applies fully.

A generic sign saying “CCTV in operation” does not obtain informed consent to:

• biometric template generation;

• watchlist comparison;

• emotion analysis;

• advertising profiles;

• movement tracking across locations.

Facial recognition does not automatically require explicit consent under a separately stated DPDPA biometric category, because the Act has no GDPR-style special-category regime. The lawful ground must still be identified, and consent, where used, must meet Section 6.

88. Scraping and public data

If personal data was genuinely made publicly available by the Data Principal, Section 3(c)(ii) may exclude it from the DPDPA.

Consent is therefore not automatically required for every public field. However:

• leaked data is not voluntarily public;

• restricted profiles are not necessarily public;

• hidden information is not public;

• generated inferences may be new personal data;

• biometric templates are not necessarily the same as public photographs;

• combined profiles require separate analysis.

If the resulting processing remains within the Act and no Section 7 ground applies, consent may be required. In mass scraping, obtaining meaningful consent may be operationally impossible. Impossibility does not create a new lawful ground.

89. Vendors

A Data Fiduciary cannot outsource consent responsibility.

A processor may operate the interface or maintain records, but the Data Fiduciary must prove validity.

Vendor contracts should address:

• processing instructions;

• consent signals;

• withdrawal implementation;

• deletion;

• evidence;

• security;

• subprocessors;

• prohibition on independent model training;

• breach response;

• audit support.

A processor that begins using data for its own advertising or model-training purpose may become a Data Fiduciary for that operation and require its own ground.

90. Consent design across channels

90.1 Mobile application

• off-state toggles;

• purpose-level choices;

• visible refusal;

• privacy dashboard;

• one-step or similarly easy withdrawal.

90.2 Website

• consent separate from terms;

• no pre-ticked boxes;

• clear data-purpose mapping;

• persistent preference control.

90.3 Call centre

• clear oral script;

• active “yes” response;

• reliable record;

• follow-up notice where appropriate;

• easy telephone or digital withdrawal.

90.4 Physical form

• consent separate from mandatory declarations;

• readable font;

• language choice;

• signed purpose-level choices;

• version control.

90.5 WhatsApp

• notice before document submission;

• clear response procedure;

• no assumption from message receipt;

• available withdrawal route outside the chat if needed.

91. DPDP Rules mapping

Rule 3 does not itself create consent. Rule 4 does not transfer accountability for the Data Fiduciary’s processing to the Consent Manager.

92. GDPR comparison

The EDPB guidance should be used to illuminate free choice, power imbalance, granularity, detriment, affirmative action and withdrawal. It must not be used to import GDPR lawful bases or Article 9 into the DPDPA.

93. Corrections to propositions in the supplied material

Several propositions require qualification.

93.1 “Every purpose requires a separate checkbox”

Not necessarily every minor or technically connected operation. Materially distinct purposes require granular choice. Functionally integrated operations supporting one coherent purpose may be grouped.

93.2 “Any difference in service is unlawful differential treatment”

Too broad. A feature may stop where the withheld data is necessary for that feature. Punitive degradation unrelated to necessity is the real concern.

93.3 “Pay or okay is automatically unlawful in India”

Not established. It creates serious risks under free and unconditional consent. The EDPB opinion concerns large online platforms under GDPR and is persuasive, not binding Indian law.

93.4 “Withdrawal takes effect instantaneously for all processing”

The right may be exercised immediately, but Section 6(6) allows a reasonable time for the Data Fiduciary and processors to cease processing.

93.5 “A campaign already in dispatch may always continue”

Not automatically. It depends on whether the processing is technically irreversible and what constitutes reasonable cessation. The Data Fiduciary should not initiate new activity after withdrawal.

93.6 “Section 8(7) requires every independent third party to erase”

Too broad. The Act expressly requires the Data Fiduciary to cause its processors to erase. Independent recipients require separate role and ground analysis.

93.7 “Withdrawal audit logs must contain IP address and device ID”

Not expressly required. These may be useful evidence but should be collected only where proportionate.

93.8 “Audit records must be cryptographically immutable”

Good practice in some systems, but not an express universal statutory requirement.

93.9 “All biometric processing requires explicit consent”

Incorrect under the DPDPA. No separate special category exists. The exact Section 4 ground must be identified.

93.10 “All core employee processing requires consent”

Incorrect. Section 7(i) supports genuine employment and employer-protection processing.

94. Consent lifecycle model

1. DEFINE PURPOSE

State the real and bounded objective.

2. IDENTIFY NECESSARY DATA

Exclude fields not required for that objective.

3. SELECT THE CORRECT GROUND

Use consent only where consent is appropriate.

4. PROVIDE NOTICE

Explain data, purpose, service, rights and withdrawal.

5. PRESENT A NEUTRAL CHOICE

No preselection, concealment or manipulation.

6. RECORD AFFIRMATIVE ACTION

Maintain purpose-level evidence.

7. LIMIT PROCESSING

Do not exceed data, purpose, recipients or duration.

8. ENABLE REVIEW

Allow the Data Principal to see active consents.

9. ENABLE COMPARABLY EASY WITHDRAWAL

Avoid obstructive processes.

10. CEASE AND INSTRUCT PROCESSORS

Act within a reasonable time.

11. ERASE OR RESTRICT

Unless another law authorises continued processing.

12. PRESERVE PROPORTIONATE EVIDENCE

Demonstrate notice, consent and withdrawal.

95. Final interpretation

Section 6 treats consent as a continuing and controlled permission, not as a one-time transfer of personal data.

A valid consent must satisfy every statutory element. The Data Principal must have a real choice. The purpose must be concrete. The notice must enable understanding. Agreement must not be tied to unnecessary processing. The action must clearly indicate consent. The data must remain limited to what the purpose needs.

The telemedicine illustration makes the most important point in the section: even a person’s affirmative agreement cannot authorise unnecessary collection. Consent does not override necessity.

Section 6(2) further confirms that consent cannot contract out of the DPDPA or another law. Invalid terms are severed to the extent of their infringement, although serious defects may undermine the whole consent.

Section 6(3) makes accessibility part of validity. Clear language, constitutional-language options and a functional privacy contact are not decorative requirements.

Sections 6(4) to 6(6) make consent reversible. Withdrawal must be comparably easy, prior lawful processing remains valid, and consent-dependent processing must cease within a reasonable time. The Data Fiduciary must also ensure cessation by its processors. Continued processing is permissible only where another provision of the DPDPA, the Rules or another Indian law independently supports it.

Sections 6(7) to 6(9) create a distinct Indian institution, the registered Consent Manager. The Consent Manager acts for the Data Principal, not for the Data Fiduciary, and provides a platform for giving, reviewing, managing and withdrawing consent.

Section 6(10) completes the framework by placing proof on the Data Fiduciary. Consent cannot exist merely as an assertion in pleadings or a boolean field in a database. The organisation must be able to show what notice was presented, what purpose was stated, what choice was made and whether that consent remained active.

For applicants, consent is particularly relevant to background checks, future retention and AI training. For non-employee interns and trainees, it should support programme processing not otherwise covered by Section 7(a). For employees, it should be reserved for optional activities outside Section 7(i). For marketing, it should be channel- and purpose-specific. For AI, it must identify model training as a real purpose rather than hiding it under service improvement. For CCTV, consent should not be presumed where another statutory route is the true basis. For scraped data, inability to contact individuals does not create a lawful ground. For vendors, outsourcing does not outsource accountability.

The controlling principle is:

Key point

Consent is valid only when the Data Principal receives a meaningful choice over a clearly explained, necessary and limited use of personal data, can reverse that choice without obstruction, and the Data Fiduciary can prove the entire process.