DPDP for Government Bodies and PSUs: What the Act Exempts, What It Still Demands, and Where Implementation Really Breaks
The most expensive sentence in the public sector right now is "the Act exempts us."
It rarely arrives that bluntly. It turns up at the end of a review meeting, delivered with a shrug: surely government departments sit outside the DPDP Act, and surely a PSU can lean on the same carve-outs. Everyone nods, because nodding is easier than reading Section 17.
Here is what the text says. The Digital Personal Data Protection Act, 2023 gives the State real room to manoeuvre. It does not give the State a pass. Most of that room is conditional, some of it depends on a notification that must be issued first, and the duties that survive every exemption (security, accuracy, accountability) are exactly where public bodies tend to be weakest.
This article is for the CIO of a ministry's e-governance cell, the CISO of a PSU, the company secretary who has just inherited "DPDP" as an additional charge, and anyone drafting a tender for a system that will touch citizens' data. It covers what the law grants, what it still demands, where implementation breaks in practice, and what to do about it.
The State is a Data Fiduciary first and an exception second
The Act applies to digital personal data processed within India, and it applies to the State the way it applies to everyone else unless a specific provision says otherwise. Whoever decides the purpose and means of processing is a Data Fiduciary. A ministry running a beneficiary portal is one. So is a state transport corporation, a municipal body, a public sector bank or a power distribution utility.
The four roles map across cleanly, even where the org charts do not.
Two points trip people up.
First, "State" is not a closed list. Practitioners read it through Article 12 of the Constitution and the instrumentality doctrine the Supreme Court developed in the 1970s: if the State acts through a corporation, that corporation can be treated as its instrumentality. Whether a particular PSU qualifies turns on control, funding and function, and it matters. A listed PSU selling to retail customers is the State for some purposes and an ordinary commercial fiduciary for others.
Second, the Act covers personal data collected digitally, and non-digital data that is later digitised. The paper visitor register at a district office sits outside the Act until somebody scans it. Every e-Office rollout and records-digitisation drive pulls more of your archive inside it.
What the Act gives the State, and where it stops
Government functions run on personal data that citizens cannot meaningfully "consent" away. The Act recognises this through Section 7, which lists certain legitimate uses where processing is allowed without consent. These are the ones public bodies lean on most.
| Section | Legitimate use | What it looks like in government |
|---|---|---|
| 7(a) | Data Principal voluntarily provides data for a specified purpose and has not indicated non-consent | A citizen shares a mobile number to receive application status updates |
| 7(b) | State or its instrumentality provides a subsidy, benefit, service, certificate, licence or permit, where the person earlier consented or the data sits in a notified government database | DBT payouts, ration cards, driving licences, scholarships |
| 7(c) | State performs a function under law, or acts in the interest of sovereignty, integrity or security of India | Tax administration, licensing enforcement, statutory returns |
| 7(d), 7(e) | Fulfilling a legal obligation to disclose information to the State, or complying with a judgment, decree or order | Responding to court orders, statutory disclosures by a PSU |
| 7(f) to 7(h) | Medical emergencies, epidemics and public health threats, disasters and breakdown of public order | Public health response, disaster relief |
| 7(i) | Employment, or safeguarding the employer from loss or liability | Payroll, service records, vigilance cases |
Read the right-hand column carefully. Section 7 does not say the processing is free of rules. It says consent is not the lawful basis. Section 8 still follows you: you remain responsible for your processors, must keep data accurate where it drives decisions, must take reasonable security safeguards, must report breaches and must run a grievance mechanism. For subsidy-and-benefit processing under Section 7(b), Rule 5 and the Second Schedule to the Rules add standards for lawful, purpose-limited and secure State processing.
Section 17 is the second layer, and it is graduated rather than blanket.
Section 17(1) disapplies most of Chapters II and III for specific purposes, such as enforcing legal claims, court and regulatory functions, and preventing or investigating offences. But Section 8(1) and 8(5) are expressly kept. Security safeguards are never exempted here.
Section 17(2)(a) lets the Central Government notify particular State instrumentalities, in the interests of sovereignty, security, friendly relations with foreign States or public order, after which the Act does not apply to their processing for those purposes. The operative word is notify. Until your body is named, you are not exempt, however sovereign your mandate feels. Commentators also note that the Rules tie such exemptions to necessity and reasonable safeguards.
Section 17(4) is the quiet one. For any processing by the State or its instrumentalities, the erasure duty in Section 8(7) and the erasure right in Section 12(3) do not apply, and the correction right in Section 12(2) falls away where the processing does not feed a decision about the person. That is genuine relief for record-keeping bodies. It does not make retention unlimited, because the Second Schedule standards still expect data held only as long as the purpose needs it.
The pattern is consistent: the State gets a different lawful basis, not a different standard of care.
The calendar, and the pressure that runs ahead of it
The DPDP Rules, 2025 were notified on 13 November 2025, and the Data Protection Board was constituted the same day. The Consent Manager framework follows on 13 November 2026. The operational core (notice, State processing standards, security safeguards, breach reporting, retention and the rest) takes effect on 13 May 2027.
Treat that last date as a ceiling, not a runway. Public procurement is slow by design: scoping, budget, tender, evaluation, award, onboarding. A system specified in 2027 will not go live in 2027. A contract signed today for five years will bind you through the first years of enforcement. The best time to put DPDP clauses into your RFP templates was last year. The next best is this quarter.
Seven challenges that decide whether a programme works
Across ministries, state departments and PSUs, the same seven problems surface. Few are purely legal. Most are organisational, which is why they are hard.
1. You cannot protect what you cannot find
Beneficiary data does not live in one system. It lives in the flagship portal, in three state-level copies, in district spreadsheets emailed between officers, in scanned PDFs on shared drives and in the notebooks of the person who "handles the list". Aadhaar numbers, bank details and addresses repeat across all of them. Before anything else, a body needs one honest register of where personal data sits and who answers for each location.
2. PSUs wear two hats
A power utility or public sector bank processes data as a service provider to the State in one breath and as a commercial business selling to retail customers in the next. The lawful basis differs by activity. Billing might rest on a legal obligation, a loyalty campaign on consent, payroll on Section 7(i). Bodies that apply one blanket assumption to everything end up either over-collecting consent they do not need or relying on exemptions they do not have.
3. The vendor chain is longer than the org chart
System integrators, cloud hosts, call centres, SMS gateways, outsourced payroll, third-party app developers and the subcontractors behind each of them all touch personal data. The Act makes the fiduciary answerable for its processors, and Rule 6 expects processor contracts to carry security safeguards. Tender templates written before the Act rarely do. And the lowest-bid rule rarely rewards the vendor who prices in privacy engineering.
4. Legacy systems cannot produce the evidence
Applications built a decade ago, with maintenance contracts that have lapsed, do not log in ways an investigator can use. Rule 6 expects access controls, monitoring and logs retained for at least one year. Rule 7 expects a detailed breach report within 72 hours. You cannot meet a 72-hour clock with a system that cannot tell you who opened which record last Tuesday.
5. Transparency law and privacy law now pull against each other
Section 44(3) of the DPDP Act amended Section 8(1)(j) of the RTI Act. The clause now exempts information that "relates to personal information", without the public-interest balancing the earlier text contained inside it. Petitions challenging this are pending, and the Supreme Court has issued notice. Public Information Officers are left to decide, case by case, what counts as personal. Over-withhold and you invite appeals. Over-disclose and you create a breach. Write down classification guidance now and plan for the position to move.
6. Ownership walks out on transfer
Officers rotate every two or three years. A programme that depends on one enthusiastic Joint Secretary or General Manager resets the day that person is posted elsewhere. The owner has to be a post with a written mandate, a documented handover and records that live in a system, not in a mailbox.
7. Several authorities, several clocks
A single incident can start four timers at once. Reconcile them before the incident, not during it.
| Obligation | What it asks | How to reconcile |
|---|---|---|
| DPDP Rule 6 | Retain logs and processing records for at least one year | Treat one year as the floor for systems holding personal data |
| CERT-In Directions (April 2022) | Report specified incidents within six hours; keep logs for a rolling 180 days within India | Follow the stricter clock for each; keep logs longest where the two overlap |
| DPDP Rule 7 | Inform affected Data Principals without delay; detailed report to the Board within 72 hours | One incident playbook, different recipients |
| RTI Act, Section 8(1)(j) as amended | Personal information exempt from disclosure; challenge pending | Written classification guidance and an escalation route for PIOs |
| Records and archival rules | Retain files for prescribed periods | A retention schedule citing the governing rule for each record class |
| Sectoral regulators (RBI, IRDAI for PSU banks and insurers) | Their own cyber, outsourcing and incident directions | Map once; reuse the same evidence across regimes |
What non-compliance actually costs
Penalties come from the Schedule to the Act and are imposed by the Data Protection Board after an inquiry. These are ceilings, and the Board must weigh the nature, gravity and duration of the breach and what the fiduciary did to mitigate it.
| Breach | Section | Maximum penalty |
|---|---|---|
| Failure to take reasonable security safeguards to prevent a personal data breach | 8(5) | Rs 250 crore |
| Failure to notify the Board and affected Data Principals of a breach | 8(6) | Rs 200 crore |
| Breach of additional obligations relating to children | 9 | Rs 200 crore |
| Breach of additional obligations of a Significant Data Fiduciary | 10 | Rs 150 crore |
| Any other provision of the Act or Rules | Residual | Rs 50 crore |
| Data Principal's breach of their own duties | 15 | Rs 10,000 |
Look at the shape rather than the size. The largest figure attaches to security safeguards, which is also the most fixable item on the list. For a public body, the fine is rarely the whole bill. An inquiry draws in audit observations, questions in Parliament or the Assembly, and a loss of public trust that no budget head can restore.
A 90-day plan for a public body
You will not finish in a quarter. You can become defensible.
Days 1 to 30: establish ownership and visibility. Name the accountable post, publish a grievance contact and build the register of personal data holdings. For each processing activity, record the basis: a Section 7 use, consent, or an exemption you can show is notified.
Days 31 to 60: close the contractual and technical gaps. Rank vendors by the personal data they touch and renegotiate the top ten. Add DPDP clauses to RFP templates. Check which critical systems cannot log or cannot restore from backup.
Days 61 to 90: rehearse and document. Run a breach tabletop that exercises the CERT-In, DPDP and sectoral clocks together. Issue RTI classification guidance. Start the evidence file you will hand to an auditor, a CAG team or a Board inquiry.
How VaultDef helps
Most of the seven challenges come down to one demand: prove it. Prove where the data is, prove on what basis you hold it, prove who has seen it and prove what you did when something went wrong. VaultDef is built around producing that proof as a by-product of the work.
| Challenge | What VaultDef brings |
|---|---|
| Cannot find the data | Automated data discovery and classification, feeding a data map with a named owner against every system |
| Two hats, many lawful bases | RoPA and data mapping that records the basis for each activity, whether a Section 7 use or consent |
| Long vendor chain | Vendor and cross-border tracking, so processor obligations and data locations stay visible |
| Evidence from legacy estates | A tamper-evident evidence trail, so audit-ready records exist without weeks of reconstruction |
| Breach clocks | Breach workflow and DPIA tooling built around the 72-hour report |
| Citizen requests and consent | Consent and notice management, plus a data principal rights workflow with tracked response times |
| Ownership lost on transfer | The register, decisions and evidence live in the platform, so a change of posting does not reset the programme |
The team behind VaultDef comes from hands-on offensive security, defensive security and compliance work, including RBI and CERT-In regimes for banks, NBFCs, insurers and fintechs. That background is relevant for PSU banks and insurers, where the DPDP programme has to coexist with sectoral directions.
An honest boundary: a platform is not a policy. It will not decide whether your body should seek notification under Section 17(2), draft your RTI guidance or fix a tender. Those decisions stay with you. Before selecting any tool, including ours, ask four questions. Where will data and logs physically sit? Who administers the platform? How does it connect to your legacy systems? What evidence can be exported for an auditor?
If you want the step-by-step version of the groundwork, start with our DPDP audit readiness checklist. When you are ready to see it working, book a working demo and bring a real system with you.
Frequently asked questions
Is a government department automatically exempt from the DPDP Act?
No. Section 17(2)(a) exempts only instrumentalities the Central Government notifies, and only for specified interests such as sovereignty, security and public order. Everything else is governed by Section 7 and the standard obligations.
Are PSUs treated as "the State" under the Act?
It depends on whether the body is an instrumentality of the State, usually tested through Article 12 principles. Even then, a PSU's commercial activities with customers generally need the same lawful basis as any private fiduciary.
Does Section 7 mean we can skip security and breach reporting?
No. Section 7 removes the need for consent. Security safeguards under Section 8(5), breach intimation under Section 8(6) and the Rules' safeguards continue to apply.
