Back to Blog
DPDP Act 7 min read

DPDP Act: Lawful Basis for Processing Personal Data

Understand the lawful bases for processing personal data under the DPDP Act 2023 — consent vs. legitimate use, what is permitted without consent, and B2B implications.

Key Takeaways
  • The DPDP Act has only two lawful bases: consent (Section 6) and legitimate use (Section 7).
  • Unlike GDPR, there is no "legitimate interests" basis — commercial processing without consent requires a specific legitimate use exemption.
  • Legitimate uses include state functions, legal obligations, medical emergencies, employment, and public interest.
  • Contract performance is not a named lawful basis — B2B companies must obtain consent or rely on a Section 7 legitimate use.
  • Each processing activity must be mapped to a specific lawful basis before the Act becomes enforceable.

The Two Lawful Bases Under the DPDP Act

Section 4 of the DPDP Act establishes the fundamental rule: a Data Fiduciary may process personal data only for a lawful purpose (a) with consent, or (b) for certain legitimate uses. Unlike GDPR's six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interests), the DPDP Act has just two primary routes.

This simplicity is by design. The Parliamentary Standing Committee that reviewed the Bill wanted a framework that was easy for Indian citizens and companies to understand. The trade-off is less nuance — situations that GDPR would handle comfortably under "contract" or "legitimate interests" require the DPDP Act to either be squeezed into consent or accommodated under Section 7.

Every processing activity your company undertakes must be mapped to either Section 6 (consent) or a specific sub-clause of Section 7 (legitimate use). Activities that cannot be mapped to either are unlawful under the Act.

Consent is the default lawful basis for commercial data processing under the DPDP Act. If your company collects personal data for marketing, analytics, product improvement, profiling, or any other commercial purpose, you need valid consent as described in Section 6.

Consent is the most flexible basis — it allows you to process data for whatever purpose you have disclosed and the Data Principal has consented to. But it is also the most administratively burdensome: you must capture, record, and honour consent decisions, and you must be able to withdraw processing when consent is withdrawn.

For pure-play consumer companies — e-commerce, consumer apps, fintech lending platforms — consent will be the primary lawful basis for almost all processing. The operational investment in consent management infrastructure is unavoidable.

Legitimate Uses: Section 7 Explained

Section 7 enumerates specific circumstances where personal data may be processed without consent. These are exhaustive — unlike GDPR's "legitimate interests," you cannot invoke Section 7 for any purpose you deem commercially reasonable. You must fall within one of the listed sub-clauses.

Section 7(a): the State or any instrumentality of the State processing for a function authorised under law. Section 7(b): compliance with a judgment, decree, or order of a court or tribunal. Section 7(c): responding to a medical emergency threatening life. Section 7(d): measures for health epidemics or safety. Section 7(e): processing by an employer for recruitment, employment, or termination (subject to Rules). Section 7(f): processing for the purpose of verification of identity or prevention of fraud (subject to Rules).

These are legitimate uses that arise in specific, bounded situations. They are not a general-purpose override of the consent requirement. A company cannot invoke Section 7 to justify marketing communications, product analytics, or commercial profiling.

Processing by the State and Public Bodies

Section 7(a) is the primary lawful basis for government and public sector processing. A government body collecting personal data to disburse a welfare scheme, process a tax return, or issue an identification document does not require consent — the processing is authorised by the enabling legislation for that function.

For private companies receiving government data or processing data under a government contract — such as Aadhaar-based authentication service providers or government project implementors — the legitimate use basis flows through the contractual relationship with the State. However, any additional processing beyond the government mandate requires a separate lawful basis.

Section 7(b) (court orders) is relevant for companies served with legal process requiring production of personal data. Compliance with a court order, summons, or regulatory direction is a legitimate use that does not require consent from the affected Data Principal.

Employment-Related Processing

Section 7(e) addresses the consent problem in employment relationships. Given the inherent power imbalance between employer and employee, consent given by an employee to their employer's processing may not be truly "free." Section 7(e) provides a legitimate use basis for processing by an employer reasonably expected of the employer-employee relationship.

The scope of this legitimate use is subject to Rules. The Draft Rules have indicated it will cover processing for: onboarding, payroll, benefits administration, performance management, attendance tracking, and regulatory compliance (e.g., PF, ESI, TDS filings). Processing beyond these core HR functions — such as health monitoring beyond what is required for safety, or communications surveillance — will likely still require consent.

Until the Rules finalise the scope of Section 7(e), err on the side of obtaining consent from employees for processing beyond administrative HR functions. Update employment contracts and onboarding documentation to include data processing disclosures and, where appropriate, consent requests.

What GDPR Has That DPDP Act Doesn't

GDPR's Article 6(1)(b) allows processing "necessary for the performance of a contract" — covering a vast amount of commercial data processing including service delivery, billing, and customer support without requiring explicit consent. The DPDP Act has no equivalent. Contract performance is not a named lawful basis.

GDPR's Article 6(1)(f) "legitimate interests" allows controllers to process data for their own or a third party's legitimate interests, subject to a balancing test against the Data Principal's interests. This covers fraud prevention, network security, direct marketing (with soft opt-in), analytics, and countless other routine commercial uses. The DPDP Act has no equivalent.

The absence of these two GDPR bases significantly increases the consent burden for Indian companies. Activities that GDPR-compliant companies in Europe handle without seeking consent — operational analytics, fraud screening, routine B2B outreach — will require consent under the DPDP Act unless they fit a Section 7 legitimate use. Indian companies building compliance programmes must not assume GDPR practices transfer directly.

Mapping Your Processing Activities to a Lawful Basis

Conduct a processing activity mapping exercise as part of your DPDP compliance programme. For each processing activity, document: the activity description, the categories of personal data involved, the purpose, and the lawful basis. For Section 7 activities, identify the specific sub-clause. For Section 6 activities, document your consent mechanism and retention of consent evidence.

Common processing activities and their likely lawful basis under the DPDP Act: account creation (Section 6 consent or Section 7(f) identity verification); marketing communications (Section 6 consent — mandatory); analytics and product improvement (Section 6 consent); payroll and HR administration (Section 7(e) employment); legal hold (Section 7(b) legal obligation); fraud prevention (Section 7(f) — subject to Rules).

This mapping exercise is not a one-time activity — it must be updated whenever you launch a new product feature, enter a new market, or change a significant data processing practice. Embed lawful basis review into your product development lifecycle, analogous to how SOC 2-compliant companies embed security review into their SDLC.

Frequently Asked Questions

Can a B2B SaaS company rely on "contract performance" to process customer data without consent?
No. The DPDP Act does not have a contract performance lawful basis. B2B SaaS companies must either obtain consent from the individuals whose data they process, or rely on a Section 7 legitimate use. For customer employee data uploaded to the SaaS platform, the SaaS company is typically a Data Processor — the customer (Data Fiduciary) bears the consent obligation.
If we already have GDPR-compliant "legitimate interests" assessments, can we use them for DPDP Act compliance?
No. Legitimate interests is not a lawful basis under the DPDP Act. For activities currently relying on legitimate interests, you need either to obtain consent or identify a matching Section 7 legitimate use. Activities that do not fit either must cease.
Is there any equivalent to GDPR's soft opt-in for B2B marketing under the DPDP Act?
No explicit equivalent exists. GDPR's soft opt-in (Recital 47) allows direct marketing to existing customers on a legitimate interests basis. The DPDP Act requires consent for marketing communications. However, the Rules may create a B2B soft opt-in equivalent — watch this space.
How does the DPDP Act handle processing required by other Indian laws (SEBI, RBI, IRDAI regulations)?
Section 7(b) covers compliance with court orders and judgments. For regulatory obligations imposed by sectoral regulators (SEBI, RBI, IRDAI, MCA), the enabling legislation for those requirements constitutes a lawful basis under Section 7(a) (State function authorised by law). Maintain documentation of the specific regulatory requirements as evidence of your lawful basis.
Do we need separate consent for each third-party tool we use — analytics, marketing automation, CRM?
Yes, where those tools process personal data for distinct purposes. If your analytics tool processes user data for product analytics, your marketing automation tool processes it for marketing, and your CRM processes it for sales — each is a distinct processing purpose requiring separate consent under the "specific" requirement of Section 6.

Automate your compliance today

AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.

Start for free