Section 7 — Certain Legitimate Uses

Section 4(1)(b) names "certain legitimate uses" as the second lawful basis for processing, alongside consent. Section 7 is the full, closed list of what that phrase actually means — nine named situations, lettered (a) through (i), and nothing else. This is not the open-ended "legitimate interest" test some other privacy laws use, where an organisation weighs its own interest against the individual's and decides for itself whether processing is justified. Here, if a situation doesn't match one of the nine clauses, the legitimate-use basis simply isn't available, no matter how reasonable the processing might otherwise seem. And even where a clause does apply, notice obligations and the Act's other safeguards — purpose limitation, data minimisation, security, erasure — don't disappear; Section 7 replaces the need for consent specifically, not the rest of the Act.

Voluntarily-provided data for its own stated purpose — 7(a)

Where a Data Principal has voluntarily provided her personal data for a specified purpose, and hasn't indicated she doesn't consent to that use, the Data Fiduciary may process it for that purpose. This isn't consent in the formal Section 6 sense — it's a narrower, purpose-driven basis tied to the fact that she initiated the interaction herself. Three conditions have to hold: the data was voluntarily provided, the processing stays limited to the purpose she provided it for, and she hasn't indicated refusal. The Act's illustrations are concrete: a customer who shares her number with a pharmacy so it can text a payment receipt has authorised exactly that texting, nothing more; a person who asks a real-estate broker to help find rented accommodation, then later tells the broker she no longer needs help, means the broker has to stop processing her data at that point — the basis ends when the purpose does, or when she withdraws it. Reusing the same data for marketing or analytics once the original purpose is served falls outside 7(a) entirely.

State-delivered subsidies and services — 7(b)

The State or its instrumentalities may process personal data to provide or issue a prescribed subsidy, benefit, service, certificate, licence or permit, where either the Data Principal previously consented to processing for that kind of benefit, or her data already sits in a government-maintained database, register or document notified by the Central Government — subject to standards under Central Government policy or other applicable law. The logic is administrative continuity: government programmes routinely draw on existing public records, and requiring fresh consent at every touchpoint would make routine benefit delivery impractical. The Act's illustration involves a pregnant woman enrolled in a maternity-benefits programme, whose data the government may also use to check her eligibility for other prescribed benefits — but the basis stays tied to delivering that class of public service; reusing the same data for unrelated analytics or programme expansion moves outside what 7(b) covers.

State functions, sovereignty and security — 7(c)

The State or its instrumentalities may process personal data for performing any function under Indian law, or in the interest of India's sovereignty and integrity, or the security of the State. This is a narrower clause than it might first appear — it applies to the performance of an actual statutory function or a genuine sovereignty/security interest, not to any processing a government body finds convenient. It sits alongside, and is legally distinct from, the broader exemption regime Section 17 separately carves out for specified government instrumentalities — 7(c) is a legitimate-use ground under Chapter II, while Section 17 is an exemption from provisions of the Act entirely, for a different and more limited set of purposes.

Disclosure a law already requires — 7(d)

Where any Indian law imposes an obligation on a person to disclose information to the State or its instrumentalities, that disclosure can proceed without separate consent, so long as the processing follows whatever conditions the disclosure-requiring law itself sets. The DPDP Act doesn't create these disclosure duties — it simply recognises that where one already exists elsewhere in Indian law, consent isn't a separate precondition for complying with it. Regulatory reporting, statutory financial disclosures, and law-enforcement requests made under an actual legal power fit here; an informal government request with no underlying legal disclosure obligation behind it does not.

Court orders and judgments — 7(e)

Processing needed to comply with a judgment, decree or order under Indian law, or with a judgment or order relating to contractual or civil claims made under law outside India, is a separate legitimate use in its own right. This covers the ordinary mechanics of litigation and enforcement — producing personal data in response to a valid court order doesn't require going back to the Data Principal for fresh consent, because the legal obligation to comply with the order is itself the basis. As with the other clauses, this doesn't license processing beyond what the specific judgment or order actually requires.

Medical emergencies — 7(f)

Processing needed to respond to a medical emergency involving a threat to life, or an immediate threat to health, for the Data Principal or any other individual, doesn't need to wait for a consent flow. The point is urgency: doctors, hospitals and emergency responders need to act on personal data immediately when life or health is at stake, and Section 7(f) exists precisely so that isn't blocked by process. But the basis is narrow and time-bound — it covers what's strictly necessary to respond to the emergency itself, and it stops applying once the emergency ends. Health data gathered for emergency treatment can't be repurposed afterward for unrelated analytics on this same basis.

Public health measures during an epidemic or outbreak — 7(g)

Measures to provide medical treatment or health services during an epidemic, disease outbreak, or other threat to public health fall under this clause, defined by cross-reference to how "disaster" is understood elsewhere in Indian law for the parallel clause below. Like 7(f), the justification is public-safety urgency at scale rather than an individual emergency, and it's equally purpose-bound — tied to managing the actual public health event, not to whatever downstream use the collected data might later be useful for.

Safety and assistance during disaster or breakdown of public order — 7(h)

Measures to ensure safety, or to provide assistance or services, to any individual during a disaster or a breakdown of public order are covered here, with "disaster" carrying the same meaning the Disaster Management Act, 2005 gives it. As with 7(f) and 7(g), the reasoning is that delaying action to run a consent process during an active disaster or public-order breakdown could itself cost lives or worsen harm — but the basis dissolves once the situation stabilises, and continued processing past that point needs its own separate justification.

Employment purposes — 7(i)

Processing for the purposes of employment, or to safeguard the employer from loss or liability — including preventing corporate espionage, maintaining confidentiality of trade secrets, intellectual property or classified information, or providing a service or benefit an employee has sought — is the final listed use. This recognises that an employment relationship generates processing needs (payroll, access controls, internal investigations into misconduct affecting the business) that don't naturally fit a consent model, given the power imbalance between employer and employee. The scope stays tied to employment and to protecting the employer from loss or liability specifically — employee data collected for HR administration, later repurposed for unrelated profiling or analytics with no connection to either of those two things, sits outside what 7(i) actually covers.

Why this matters in practice

The single most common misuse of Section 7 is treating it as a general escape hatch from consent — reaching for "legitimate use" because obtaining consent felt like friction, rather than because the processing genuinely matches one of the nine listed situations. Every clause in this section is purpose-bound and, in most cases, time-bound: the legitimate-use basis ends when the specific purpose, emergency, or legal obligation it was tied to ends, and any continued processing after that point needs its own separate justification, whether that's a fresh consent or a different Section 7 clause that actually fits.

Illustration: a company collects an employee's biometric attendance data under 7(i) for workplace access control. If it later wants to use that same biometric data to build a productivity-scoring analytics dashboard sold as a product feature to other companies, that use has moved well outside "employment purposes or safeguarding the employer from loss or liability" — it needs its own lawful basis, most likely consent under Section 6, and 7(i) doesn't stretch to cover it.

How Section 7 connects to the rest of the Act

Section 4(1)(b) is where "certain legitimate uses" enters as a basis, and Section 2(d) simply cross-references this section for the term's definition. Section 7 doesn't carry the same notice-before-consent sequencing Section 5 imposes on the consent route, but the Data Fiduciary's other Chapter II duties — Section 8's security, breach and erasure obligations chief among them — apply to data processed under Section 7 exactly as they do to data processed under consent. Section 17's separate exemption regime for specified government functions sits alongside 7(b) and 7(c), covering a narrower and differently-defined set of circumstances.