DPDP Exemptions: What Section 17 Actually Carves Out

What the DPDP Act Actually Exempts, and What It Doesn't

The Digital Personal Data Protection Act, 2023 is not a universal privacy law — it carves out specific carve-outs where the Act's obligations are relaxed, modified, or lifted entirely. Section 17 of the Act creates two tiers of exemption. Sub-section (1) is a self-executing list of six narrow situations where the Act's main provisions do not apply, and sub-section (2) empowers the Central Government to notify broader exemptions for the State and its instrumentalities, as well as for research, archiving, and statistical purposes.

The practical consequence is that most privacy teams reading the Act for the first time overestimate the exemptions. The Section 17(1) list is tightly drawn, and even where it applies, the Act's security safeguards and breach-notification duties under Section 8(5) and Section 8(6) continue to bite. There is no blanket employee-data exemption. There is no public-interest exemption. There is no small-business exemption. The exemptions that do exist are specific and tested against purpose, not sector.

This post walks through every exemption in Section 17, who can rely on it, how far it reaches, and the operating implications. We also cover the Section 17(2) notified exemptions published to date, and what to do when your use-case sits uncomfortably on the border between an exempt and a non-exempt purpose. The one-line summary: assume the Act applies, and only invoke an exemption when you can map your processing to the exact statutory language in writing.

Section 17(1)(a) — Legal Rights, Judicial Functions, and Enforcement

The first exemption covers processing necessary for enforcing any legal right or claim. In practice, this is the exemption your legal team will invoke when a Data Principal asks you to delete data that is subject to an active or threatened dispute. If a terminated employee files a wrongful-dismissal claim, the records relevant to defending that claim are exempt from erasure under this clause for as long as the proceedings remain live. The same logic applies to credit disputes, consumer complaints, and intellectual-property litigation.

The exemption also covers processing by any court or tribunal, and by any body exercising judicial, quasi-judicial, regulatory or supervisory functions in India. This is the clause that keeps courts, the Data Protection Board of India itself, and sectoral regulators (RBI, SEBI, IRDAI, TRAI, DGCA, and others) outside the normal DPDP consent machinery when they process personal data as part of their regulatory function. It does not exempt the regulated entities — only the regulator.

Two operating cautions apply. First, the exemption is purpose-based, so the processing must be necessary for the exempt purpose. Holding onto an entire HR system because one employee has a live claim does not justify blanket retention; you ring-fence the specific records tied to the dispute. Second, Section 8(5) and 8(6) continue to apply even where Section 17(1) does, so you still owe the data a reasonable security standard and must still notify the Board and affected Principals of any breach.

Section 17(1)(b) — Preventing, Detecting, Investigating and Prosecuting Offences

The second exemption shelters processing necessary for the prevention, detection, investigation or prosecution of any offence or contravention of any law in India. This is the clause that supports internal fraud investigations, anti-money-laundering screening, know-your-customer workflows, and cooperation with law enforcement. It is a workhorse exemption for financial services, insurance, and digital marketplaces.

The language is capacious — 'any offence or contravention of any law' — but the operating constraint is necessity. A fraud team may hold identity documents and transaction records for as long as they are necessary to investigate an incident; it may not retain them indefinitely under the general shield of the exemption. Internal practice typically caps investigation records at the limitation period for the underlying offence plus a defined forensic buffer, and treats continued retention beyond that as regulated processing that needs a separate lawful basis.

This exemption is one of the places where the Act's drafting puts significant weight on the Fiduciary's own documentation. A regulator asked to accept that specific records were held for offence-detection purposes will want to see the triage note, the investigator's work product, and the retention justification. In practice, the exemption is only as strong as the paper trail behind it, and we recommend treating every Section 17(1)(b) retention as a documented decision rather than a background default.

Section 17(1)(c) — Mergers, Demergers, and Corporate Restructuring

The third exemption covers processing by any legal person pursuant to any merger, demerger, amalgamation or any other arrangement or scheme of compromise or reconstruction, as sanctioned by a court or tribunal. This is the clause that permits transferring a company's customer database as part of a sale, provided the transaction is court or tribunal sanctioned. Vanilla asset sales between willing parties that do not require court sanction fall outside the exemption and need their own lawful basis for the data transfer.

The exemption is widely misread as a general M&A permission slip. It is narrower than that. First, it applies only where the restructuring is sanctioned by a court or tribunal — meaning that typical NCLT-approved schemes of arrangement qualify, but ordinary share purchase agreements and asset sales negotiated outside a court process do not. Second, it covers the processing pursuant to the restructuring itself; post-closing use of the acquired data still runs under normal DPDP rules.

For transaction teams, the practical workflow is to treat the data transfer as a tightly scoped step in the sanctioned scheme — described in the scheme filings — and to begin the acquired entity's DPDP housekeeping (updated notices, renewed consents where required, grievance officer appointment) on closing. The data-room diligence phase before signing is a separate problem and generally not covered by Section 17(1)(c): due-diligence disclosure of personal data to a prospective acquirer typically needs a legitimate-use-case basis or de-identification.

Section 17(1)(d) and (e) — Default Recovery, Credit Information, and Statutory Functions

The fourth exemption permits processing to ascertain the financial information and assets and liabilities of any person who has defaulted in payment, where the processing is in accordance with any law. This is the clause that supports debt-recovery agencies, credit information companies operating under the Credit Information Companies (Regulation) Act, 2005, and lenders tracking default portfolios for recovery and provisioning. The exemption does not create a free-for-all; it narrows to processing that is itself authorised by other law.

The fifth exemption is for processing by the State, or any of its instrumentalities, in the interest of sovereignty and integrity of India, security of the State, friendly relations with foreign States, maintenance of public order, or preventing incitement to any cognisable offence. This is the national-security clause, and it is paired with Section 17(2)(a) under which the government may further exempt its own instrumentalities by notification. Private entities cannot invoke this clause themselves.

Section 17(1)(d) in particular is a reminder that the DPDP exemption framework is interlocked with sector-specific laws. The CICRA regime, the RBI Master Directions on recovery, and the IBC's resolution framework all describe processing that proceeds inside the Section 17(1)(d) and (e) envelope. Operating privacy teams in financial services should map each sectoral permission to the DPDP exemption it relies on, and avoid asserting that a sector law permits something without checking that the processing fits the DPDP exemption's own text.

Section 17(1)(f) — Research, Archiving, and Statistical Purposes

The sixth exemption covers processing for research, archiving, or statistical purposes, where the processing is not used to take any decision specific to a Data Principal, and where the processing is carried out in accordance with such standards as may be prescribed. Two conditions make this exemption usable only after some engineering work.

First, the no-decision-specific-to-a-Principal constraint means that the processed outputs cannot feed back into decisions about the individuals in the dataset. A dataset used to train a credit model that then scores applicants does not qualify; a dataset used to publish aggregate research on default patterns across a lender's book, with no re-identification pipeline, does. The practical test is whether the Principal can be adversely affected by the processing, and if yes the exemption fails.

Second, the exemption is conditioned on compliance with prescribed standards. Those standards are expected to require, at minimum, pseudonymisation and strict access controls, and will likely borrow from the GDPR's Article 89 framework in substance. Until the standards are formally notified, the operating approach is to apply recognised best practice — de-identification before use, access on a research-committee basis, destruction schedules — and document the compliance posture so a later notification can be adopted without rework.

Section 17(2) — Government Notifications and Startup Exemption

Section 17(2) gives the Central Government a notification power to carve further exemptions, with two main uses to date. Sub-section (2)(a) empowers the government to notify specific instrumentalities of the State as exempt from the Act's provisions, in the interests listed in Section 17(1)(e). Sub-section (2)(b) empowers notification of exemptions for research, archiving, or statistical purposes consistent with (1)(f).

The DPDP Rules add a notable sub-category under 17(3) — the exemption for notified startups. The Act contemplates that the government may, by notification, exempt certain classes of Data Fiduciaries, including startups, from the application of provisions such as the duties under Section 5 (notice), parts of Section 8 (data accuracy and completeness in certain contexts), and parts of the children's-data regime. In practice, the eligibility criteria will mirror the DPIIT startup definition and the sub-category of exemptions available is narrower than many startups expect — notice duties and children's-data obligations remain substantially in place.

Two cautions for teams relying on the startup exemption. First, it is not self-executing; it requires government notification and typically ongoing compliance with the startup definition. Second, the exemption is partial — it cuts the compliance surface, it does not remove it. Startups still owe security safeguards, breach notification, Grievance Officer appointment, and most of the Section 8 duties. We expect the government to tighten the eligibility test over time as the regime matures.

Operating Rules When You're on the Exemption Border

Many real-world situations sit between an exempt and a non-exempt purpose. A fraud investigation that evolves into a disciplinary action, a research project that spawns a model affecting individuals, a merger-related integration that drifts into post-closing marketing — each of these starts inside an exemption and ends outside it. The compliance task is to recognise the crossover and switch regimes promptly.

Three operating rules keep this manageable. First, document the exemption claim at inception. The record should state which clause of Section 17(1) or (2) applies, the specific purpose, the dataset and retention period, and the controls in place. If you cannot describe the claim in one page, you probably do not have the exemption. Second, treat Section 8(5) and (6) as always-on. The exemption framework releases consent and some substantive duties; it does not release security standards or breach notification. Build your security and incident playbooks on the assumption that every exempt dataset is still DPDP-notifiable if breached.

Third, run periodic exemption reviews. Any dataset held under Section 17(1) should carry an owner, a review date, and a decision at review on whether the exemption still applies. When a merger closes, when a research project publishes, when an investigation concludes, the exemption terminates and the Act's full obligations resume. A dataset in that state without a transition plan is a compliance liability, and a steady source of audit findings when the Data Auditor visits.

What TruePrivacy Does With Exemptions

A capable privacy platform encodes the exemption framework rather than hiding it behind free-text notes. TruePrivacy treats every processing activity in the RoPA as either (a) consent-based, (b) legitimate-use-case under Section 7, or (c) exempt under Section 17 — with the specific clause recorded, the justification attached, and the review date set. DSR workflows understand exemptions: when a Principal requests erasure of records that fall under Section 17(1)(a) because they are tied to an active dispute, the workflow surfaces the exemption, prompts the DPO to confirm, and holds the record with a retention lock and auditable justification.

The breach workflow treats Section 17 exempt datasets no differently for notification purposes — a security incident involving records held under an exemption still fires the Board intimation and Data Principal notice. The audit trail captures the exemption invocation, the review history, and the trigger for retiring the exemption when the underlying purpose ends. This is the operating posture the Data Protection Board of India is likely to expect from a mature Fiduciary: exemptions used precisely, reviewed regularly, and never used as a general compliance shortcut.