"Voluntary Sharing" Under Section 7(a) of the DPDP Act: When Can You Skip Consent?

Section 7 of the DPDP Act lists situations where a Data Fiduciary can process personal data without obtaining consent. These are called "certain legitimate uses."

Section 7(a) is the first on that list - and, on a plain reading, looks like an extremely wide exemption.

It says a Data Fiduciary can process personal data if the Data Principal has "voluntarily provided" it for a specified purpose:

But this gets quite confusing when you try and apply it to practical scenarios.

Doesn't most data collection feel "voluntary"? A customer fills in a form to obtain a SIM card. A patient gives their details at a hospital reception. A borrower provides data for completing KYC.

None of these involve coercion. So are they exempt from consent under 7(a)?

The short answer is - No. In this article, we'll explain why.

What Section 7(a) actually says

Here is the relevant text of Section 7(a) with the key parts highlighted:

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 in respect of which she has not indicated to the Data Fiduciary that she does not consent to the use of her personal data.

This provision only applies if 2 key conditions are met:

1. The Data Principal must have voluntarily provided the data for a specified purpose.
2. The Data Principal must not have indicated that they don't consent to its use.

The second condition is relatively simple. If the Data Principal has actively signalled that they don't want their data used, 7(a) doesn't apply, regardless of how the data was provided.

The first condition is where it gets confusing. What counts as "voluntarily provided"?

The limiting principle: who initiates matters

The DPDP Act's consent framework under Sections 5 and 6 covers situations where a Data Fiduciary asks for personal data, explains what it will be used for, and obtains the Data Principal's consent.

If "voluntarily provided" in Section 7(a) simply meant "the Data Principal gave the data without being physically coerced," then almost every consent-based interaction would also qualify under 7(a)

Under this reading, the entire consent framework under the DPDP Act would basically become redundant.

So "voluntarily provided" must mean something narrower than "not coerced."

After closely reading the DPDP Act - and assessing various real-life scenarios - we've arrived at - what we believe - is the cleanest definition of “voluntarily provided”

Personal data is “voluntarily provided” if the Data Principal initiates the data transfer, unprompted by the Data Fiduciary.

The moment the Data Fiduciary does anything to initiate or prompt the data transfer — like asking a question, providing a form, creating an input field – the data is no longer “provided voluntarily” and its collection would require proper consent.

So, in order to determine whether data is voluntarily provided or not, you need to apply an “initiation test”:

Data is “voluntarily provided” when the Data Principal initiates the data transfer without being asked to or prompted by the Data Fiduciary. It does not apply when the Data Fiduciary initiates the data transfer.

Applying the principle: clear-cut scenarios

Let’s apply the initiation test to some common scenarios.

A customer emails a support team to complain about a defective refrigerator they bought.

Under the initiation test - it is clear that the customer initiated the transfer. And therefore, data provided in the support email has been “voluntarily provided” by the customer.

A customer sends a WhatsApp message to a business number asking about product availability, sharing their name and location.

The business listed its WhatsApp number on its website or storefront. The customer found it and messaged on their own. They shared their name, location, and what they were looking for — because they wanted a response. The business did not ask for this data. This is "voluntarily provided" under 7(a).

A hospital hands a patient a form to fill in their personal details during admission.

The hospital designed the form. The hospital decided what fields to include. The hospital handed it to the patient and asked them to complete it. The patient is responding to a request for data — not initiating a data transfer.

This is not “voluntarily provided” data under 7(a). The hospital needs consent.

A retail store asks "Can I have your phone number for the invoice?"

The store clerk asked for the data - as part of the store's billing process. This is clearly Data Fiduciary-initiated. This is not "voluntarily provided" under 7(a). Consent is required.

A bank collects personal data as part of KYC.

KYC is a regulatory obligation of the bank. The bank designs the KYC process, determines what data is needed, and requires the customer to provide it as a condition of opening an account.

The entire data collection flow is initiated, structured, and controlled by the Data Fiduciary.

This is not "voluntarily provided" under 7(a). Banks need consent for KYC data.

The common thread across the "does not apply" scenarios: whenever the Data Fiduciary has built a process that collects data — whether that's a form, a verbal ask, a mandatory field, or a regulatory workflow — the data transfer is Data Fiduciary-initiated. 7(a) doesn't cover it.

What happens when you can't tell who initiated the request?

The scenarios above are clear-cut. Many real-world interactions are not.

The DPDP Act's own illustration for Section 7(a) makes this visible. It describes a scenario where a person makes a purchase at a pharmacy, "voluntarily provides" their personal data, and requests the pharmacist to send a payment receipt to their mobile phone. The Act says the pharmacist can process this data for the purpose of sending the receipt — under 7(a), without separate consent.

This is a very shaky scenario.

What if the pharmacist had asked: "Would you like the receipt on your phone? What's your number?" In that version of the same interaction, the pharmacist prompted the data transfer.

Following the initiation test, this would no longer fall under 7(a). Consent would be required.

So the same interaction — pharmacy purchase, phone number shared, receipt sent — lands on different sides of the line depending on whether the customer volunteered the number or the pharmacist asked for it.

In a real pharmacy, both versions happen naturally.

This is the grey zone.

The initiation test is hard to apply here because the question of “who initiated the transfer” blurs in the course of natural human communication.

Any in-person or real-time interaction where data gets exchanged conversationally — a service desk, a consultation, a walk-in enquiry — can fall into this grey zone.

When you're in the grey zone - just collect consent.

When you face such “grey zone” scenarios, you should err on the side of consent collection - for 3 primary reasons:

• The cost of mislabelling as voluntary can be hefty: If you collect consent when you didn't strictly need it, you've added a small step to your process. If you skip consent by relying on 7(a) and that reliance is later found to be incorrect - you are liable to be penalized under the DPDP Act - with fines of upto INR 250 Cr. per violation.
• Collecting more consent than necessary is not a big deal: The “grey zone” applies mostly in in-person, physical scenarios. So there is very minimal risk of customer drop off even if you add an extra consent step in the middle of the journey.

A note on other exemptions under Section 7

The analysis in this piece applies specifically to Section 7(a).

The rest of Section 7 — clauses (b) through (i) — contain separate exemptions that operate on different logic entirely.

Each has its own conditions and boundaries, and none of them turn on the "voluntary sharing" question discussed here. These include:

• State functions and sovereign interests — 7(b), 7(c)
• Legal disclosure obligations — 7(d)
• Court orders and decrees — 7(e)
• Medical emergencies — 7(f)
• Epidemics and public health threats — 7(g)
• Disaster response and public order — 7(h)
• Employment-related processing — 7(i)

Disclaimer

This piece represents our interpretation of the DPDP Act based on the statutory text and its illustrations. It is not legal advice. Consult qualified legal counsel before making compliance decisions based on this analysis.