
DPDPA Section 17: The Exemptions Are Not a Free Pass
DPDPA Section 17 offers strict India data privacy exemptions, not a free pass. Master these critical compliance exceptions to protect your organization.
Written by
Himanshu Jotwani
Date
Read time
7 min

Everyone reading the Digital Personal Data Protection Act looks for the exit door. They usually find it in DPDPA Section 17.
But Section 17 is not a free pass. It is a highly conditional, heavily monitored set of narrow carve-outs. Each of these India data privacy exemptions is tied to a specific purpose, and often chained to other laws or government notifications. Used correctly, these carve-outs enable essential business activity. Treat them like a blanket loophole, and they become a trap.
What DPDPA Section 17 Actually Covers
Section 17 contains five distinct buckets of relief. You must read each clause exactly as written. The relief is purpose-bound and strictly non-transferable to your other operations.

- Section 17(1): Switches off most obligations in Chapter II, all of Chapter III, and section 16 for specific fact patterns. Crucially, two sub-sections of section 8 still apply in these cases: section 8(1) and section 8(5).
- Section 17(2): Completely excludes the Act for two categories. One is for certain State instrumentalities notified by the Central Government. The other is for research, archiving, or statistical purposes that meet strict conditions.
- Section 17(3): Allows the Central Government to waive specified sections for certain Data Fiduciaries or classes, including startups, based on the volume and nature of data processed.
- Section 17(4): Provides targeted relief to the State or its instrumentalities for certain processing scenarios.
- Section 17(5): Permits time-bound exemptions for specified Data Fiduciaries or classes, by notification, within five years from commencement.
Section 17(1): Case-Specific Carve-Outs
In the following situations, the provisions of Chapter II (except section 8(1) and 8(5)), Chapter III, and section 16 do not apply.
a. Enforcing a legal right or claim
What it says: Processing that is necessary for enforcing any legal right or claim.
What it means: Parties can process the personal data they need to assert or defend a claim.
In practice: Litigation support, pre-litigation steps, and enforcement actions can proceed without standard Chapter II and III requirements. But you must still meet section 8(1) and 8(5).
b. Courts, tribunals, and bodies with judicial, quasi-judicial, regulatory, or supervisory functions
What it says: Processing by a court, tribunal, or any other body in India entrusted by law with such functions, where necessary for that function.
What it means: When these bodies act within their mandate, they are not bound by the usual obligations for that processing.
In practice: Regulators and supervisory authorities can handle the personal data needed to carry out their statutory roles.
c. Crime prevention and enforcement
What it says: Processing in the interest of prevention, detection, investigation, or prosecution of any offence or contravention of any law in force in India.
What it means: Law enforcement and similar functions can process personal data necessary for their work.
In practice: Maintain a clear necessity trail. Scope your processing strictly to the offence or contravention at hand.
d. Foreign data subjects under foreign contracts
What it says: Processing personal data of Data Principals not within India, pursued under a contract with any person outside India, by any person based in India.
What it means: If you are in India and process data of people outside India for a contract with an entity outside India, the listed DPDPA provisions do not apply to that processing.
In practice: This is common in IT services, BPO, and global support operations. Document that the Data Principals are outside India and that the contract counterparty is outside India.
e. Court or authority approved corporate restructurings
What it says: Processing necessary for a scheme of compromise or arrangement, merger, amalgamation, reconstruction by demerger or otherwise, transfer of undertaking, or division of companies, approved by a court, tribunal, or competent authority.
What it means: Transactional due diligence and integration activities necessary to implement an approved scheme qualify.
In practice: Keep processing tied to the approved scheme. Maintain records of approvals and the necessity link.
f. Loan default asset and liability ascertainment
What it says: Processing to ascertain financial information and assets and liabilities of a person who has defaulted on a loan or advance from a financial institution, subject to other applicable disclosure laws.
What it means: Lenders and aligned entities can process for recovery-related assessments, consistent with other law.
In practice: Align with disclosure rules in force. Keep evidence of default, scope limitation, and legal basis. The Act provides an example involving a bank processing a borrower’s data after missed repayment.
Important: In all 17(1) scenarios, section 8(1) and section 8(5) continue to apply. Ensure your engineering and compliance teams know exactly which obligations still stand.
Section 17(2): Complete Exclusions From the Act
a. Notified State instrumentalities for specified interests
What it says: Processing by such instrumentality of the State as the Central Government may notify, in the interests of sovereignty and integrity of India, security of the State, friendly relations with foreign States, maintenance of public order, or preventing incitement to any cognizable offence relating to any of these. The exemption also covers processing by the Central Government of personal data furnished by such instrumentality.
What it means: Only notified entities, and only for the listed interests, fall outside the Act.
In practice: Check notification status before relying on this clause. Tie processing directly to the listed grounds.
b. Research, archiving, or statistical purposes with prescribed safeguards
What it says: Processing necessary for research, archiving, or statistical purposes if the personal data is not used to take any decision specific to a Data Principal and the processing follows prescribed standards.
What it means: You can process personal data for these purposes outside the Act if you do not use it to make individual decisions and you meet the standards set by rules.
In practice: Build technical controls that prevent individual-level decisioning. Apply the standards prescribed. The applicable DPDP Rule 2025 identified for this is Rule 15 (research, archiving, or statistical purpose).
Sections 17(3) to 17(5): Targeted and Transitional Relief
- Section 17(3): The Central Government may notify certain Data Fiduciaries or classes of them, including startups, to whom section 5, sub-sections (3) and (7) of section 8, and sections 10 and 11 shall not apply. This is based on the volume and nature of personal data processed.
- Section 17(4): For processing by the State or its instrumentalities, section 8(7) and section 12(3) do not apply. If the purpose does not include making a decision that affects the Data Principal, section 12(2) does not apply.
Practical point: Map your public function processing to see where these subsections are in scope. Avoid creeping into decision-making about individuals if you intend to rely on the second limb.
- Section 17(5): Before five years from commencement, the Central Government may declare by notification that any provision of the Act shall not apply to specified Data Fiduciaries or classes for a set period.
- Necessity is a hard gate. For 17(1) and 17(2)(b), document why the processing is strictly necessary, not merely helpful.
- Purpose linkage is non-negotiable. Keep processing aligned to the legal right, statutory function, offence, approved restructuring, foreign-contract processing, or recovery use case as applicable.
- Respect other laws. 17(1)(f) expressly requires consistency with applicable disclosure provisions. 17(1)(e) requires an approval by a competent authority.
- Government notification matters. Relief under 17(2)(a) and 17(3) depends entirely on formal notification. No notification, no exemption.
- Individual decisioning is out for research. Under 17(2)(b), do not use the data to make any decision specific to a Data Principal. Build technical and procedural blocks to enforce this.
- Surviving obligations still apply. In 17(1) cases, section 8(1) and 8(5) continue to apply. Ensure your compliance inventory reflects this reality.
What Changes Operationally
- Build an exemptions register. Record the clause relied on, the necessity rationale, scope of data, time period, approvals, and the surviving obligations.
- Tighten access and retention. Even where obligations drop away, do not expand scope beyond what is required for the exempt purpose.
- Coordinate with legal for 17(1)(e) and 17(1)(f). Keep copies of court or authority approvals and confirm alignment with sectoral disclosure rules.
- For foreign data under 17(1)(d), validate the geo-status of Data Principals and the contracting party’s location, and segregate that processing stream.
- For research under 17(2)(b), implement standards prescribed by Rule 15 of the DPDP Rules 2025. Ensure your methods physically prevent decisions about individuals.
- Track notifications. If you rely on 17(2)(a), 17(3), or 17(5), maintain a single source of truth for applicable government notifications and their expiry.
DPDP Act exemptions exist to keep critical activity moving. Use them with precision. Over-claiming an exemption will not survive scrutiny, and it will compound your exposure when the Board or courts review your files.
Compliance execution is where the theory breaks. Teams need evidence logs, purpose maps, and role-based controls that switch obligations on and off correctly. At Regodit, we give you a structured way to operationalize these exemptions, track notifications, and prove necessity without slowing down your core work.
Because an exemption you cannot prove is just a breach waiting to happen.
Disclaimer: The views and explanations shared in this blog are based on our team's understanding of the relevant compliance frameworks. While every effort has been made to ensure accuracy, readers are encouraged to refer to the original legal provisions and official notifications for authoritative guidance. Please reach out to us at connect@solsphere.ai.
Keep reading
All blogs →DPDPA Rule 23: Government Requests for Information from Data Fiduciaries and Intermediaries
Handling a notice under DPDP Act Rule 23 requires strict confidentiality. Discover how to respond to government data requests and ensure full compliance.
DPDPA Rule 22: Appeals to the Appellate Tribunal
Lost at the Data Protection Board? DPDPA Rule 22 governs the digital-first appeals process. Read our complete guide to filing an appeal with the Tribunal.
DPDPA Rule 21: The Machinery Behind the Data Protection Board of India
Ensure your business meets DPDP Act compliance requirements. Discover key obligations for data fiduciaries, penalty risks, and steps to protect user privacy.
