DPIA Under DPDP Act: Who Must Do One and How | 2026 Guide

DPIA Under the DPDP Act: Why You Should Build the Capability Before You're Designated

By Yatin Chaudhary, SEO Specialist at ProtectComply · Last updated 5 August 2026 · 12 min read

Quick answer

A DPIA is legally required only for Significant Data Fiduciaries — and the government has not yet designated any.

That sounds like permission to wait. It isn't, for two reasons.

Designation happens by government notification, not by application. You will not get a consultation period. And the obligation that follows is a periodic assessment across your processing — which means the capability has to exist before the notification arrives, not after.

The second reason is structural. Under GDPR, a DPIA is triggered by high-risk processing. Under the DPDP Act, it is triggered by who you are. Once designated an SDF, the obligation attaches to your processing generally rather than to a handful of flagged activities.

Most organisations preparing for this have not registered that difference. It is the difference between assessing three activities and assessing three hundred.

What the Act actually says

The DPDP Act does not define "Data Protection Impact Assessment" in Section 2. The obligation sits in Section 10(2)(c), among the additional duties of a Significant Data Fiduciary, and Rule 13 of the DPDP Rules, 2025 supplies operational detail.

Alongside the DPIA, an SDF must appoint a Data Protection Officer based in India, appoint an independent data auditor, and undertake periodic audits.

A DPIA answers four questions about a processing activity: what you are doing with personal data, what harm could come to the individuals whose data it is, what you are doing to reduce that harm, and what risk remains after mitigation.

The output is a documented, living record — not a certificate you obtain once.

Nobody is an SDF yet

Section 10 empowers the Central Government to designate a Data Fiduciary, or a class of them, as Significant. The designation factors are:

• Volume and sensitivity of personal data processed
• Risk to the rights of Data Principals
• Potential impact on the sovereignty and integrity of India
• Risk to electoral democracy
• Security of the State
• Public order

No such notification has been issued. The category exists in law and is currently empty.

This produces a peculiar and widely misread situation. Read the commentary and you would think DPIAs are a live obligation for large Indian companies. Legally they are not — yet. Read it slightly differently and you might conclude the whole SDF regime is theoretical and can be deferred. That reading is worse.

Designation is a government act, not an application process. When notifications begin, affected organisations will find out by reading the gazette. The Act does not provide a preparation window between designation and obligation.

If you process personal data at scale in India — a bank, an insurer, a telco, a large platform, a hospital network, a payments company — plan on the assumption that you will be designated. The cost of being wrong in that direction is some useful documentation you did not strictly owe. The cost of being wrong in the other direction is an annual statutory obligation you cannot meet.

The scope shock nobody warns you about

This is the difference that matters most, and it is why GDPR experience will mislead your team.

Under GDPR, a DPIA is required when processing is likely to result in high risk — systematic large-scale profiling, large-scale processing of special categories, large-scale systematic monitoring. It is an activity-level trigger. Most organisations run a handful.

Under the DPDP Act, there is no specified threshold or trigger tied to a processing activity. The threshold is entity classification. An SDF must conduct periodic assessments of its processing activities.

Practical consequence: a GDPR-experienced privacy team plans for a DPIA programme covering the riskiest ten percent of processing. An Indian SDF obligation lands across the estate.

If you cannot enumerate your processing activities, you cannot scope the work — let alone do it.

DPIA depends on RoPA, and this is where programmes stall

You cannot assess the risk of an activity you have not documented.

A DPIA takes a processing activity as its unit of analysis: what data, whose, for what purpose, on what basis, shared with whom, retained how long, protected how. That is exactly the content of a RoPA row.

So the sequence is fixed by dependency, not preference:

1. Discovery — find where personal data actually lives
2. RoPA — resolve findings into processing activities that reconcile against real systems
3. Risk scoring — identify which activities cross assessment thresholds
4. DPIA — assess those activities, document mitigation, record residual risk
5. Review — periodic reassessment as processing changes

Organisations that try to start at step four end up assessing the activities they happen to remember, which is a different set from the activities they actually run.

ProtectComply is built around this pipeline. Discovery classifies personal data using an India PII pack, an activity resolver assembles processing activities, and risk scoring drives DPIA workflow wherever thresholds are crossed — with a steward review queue, because an assessment built on unreviewed classifications assesses the wrong thing.

A seven-step DPIA method

1. Define the processing activity precisely. One activity, one assessment. "Customer onboarding identity verification," not "the CRM." Scope creep here is what makes DPIAs take months.

2. Describe the data flow end to end. What is collected, from whom, through what channel, into which systems, shared with which processors, transferred where, retained how long, deleted on what trigger.

3. Establish necessity and proportionality. Is every data element needed for the stated purpose? This step routinely surfaces collection nobody can justify — which is a finding you would rather make yourself.

4. Identify risks to Data Principals. Not risks to the business. Harm to individuals: financial loss, discrimination, reputational damage, loss of control, identity theft, physical safety. Indian identifiers raise the stakes — Aadhaar and PAN exposure carries downstream harm most datasets do not.

5. Assess severity and likelihood. Score both. Consistency across assessments matters more than precision within one, because the Board will look at your methodology as much as your conclusions.

6. Document mitigation and residual risk. What you are changing, and what risk remains after you change it. Residual risk is the section people leave blank, and it is the section that demonstrates you actually did the analysis.

7. DPO review and sign-off. The DPO supervises the assessment. Record who reviewed it and when. Then set the reassessment date — this is a periodic obligation, and an assessment from three product releases ago describes a system that no longer exists.

What makes a DPIA hold up

Three things separate an assessment that demonstrates good faith from one that demonstrates paperwork.

Reasoning preserved, not just conclusions. A DPIA recording "risk: medium, mitigated" evidences nothing. The reasoning — why medium, what alternatives were considered, why this mitigation — is the part with evidential value.

Linkage to the underlying record. The assessment should point at the RoPA activity, its consent basis, its processor contracts, its retention rule. An assessment floating free of the processing record cannot be verified against reality.

A tamper-evident trail. When the Board asks when an assessment was conducted and by whom, that should be provable. Hash-chained or append-only logging answers the question; a document management system's version history mostly does not.

Under the Act, a documented DPIA is among the strongest available demonstrations of good-faith compliance — which matters not only for avoiding findings but for how penalties are assessed when something does go wrong.

Penalties

Failures on Significant Data Fiduciary obligations carry penalties up to ₹150 crore under the Act's penalty schedule. Failure to maintain reasonable security safeguards runs to ₹250 crore.

Penalties are assessed per contravention rather than per organisation, so a single incident can attract findings under several heads at once.

When this becomes enforceable

The DPDP Rules timeline puts the substantive obligations, including Rule 13, at 13 May 2027. Enforcement and penalty provisions become operative 13 November 2026.

SDF designations could be notified at any point. There is no requirement that they wait for the compliance deadline.

Frequently asked questions

Is a DPIA mandatory under the DPDP Act?

Only for Significant Data Fiduciaries, under Section 10(2)(c) with operational detail in Rule 13. For all other Data Fiduciaries it is not required by name — though the general obligation to implement appropriate technical and organisational measures makes structured risk assessment difficult to evidence without something DPIA-shaped.

Who is a Significant Data Fiduciary?

Any Data Fiduciary, or class of them, that the Central Government designates under Section 10, based on volume and sensitivity of data, risk to Data Principals, and impacts on sovereignty, electoral democracy, security of the State and public order. No designations have been notified yet.

How often must a DPIA be conducted?

Periodically, understood as annually. It is a recurring obligation, not a one-off.

How does a DPDP DPIA differ from a GDPR DPIA?

GDPR triggers on high-risk processing activities. DPDP triggers on entity classification. Under GDPR you assess selected activities; as an Indian SDF the obligation attaches to your processing generally. The scope is materially larger.

Do we submit DPIAs to the Data Protection Board?

Not routinely. They are internal records produced on request — which is why they must be current and defensible rather than assembled under pressure.

What is the difference between a DPIA and a gap assessment?

A gap assessment is organisation-wide and asks which obligations you meet. A DPIA is activity-specific and forward-looking, asking what harm a particular processing activity could cause and how you will prevent it.

Should non-SDFs conduct DPIAs?

For high-risk activities, yes — new products handling sensitive data, large-scale profiling, children's data, automated decisions with significant effects. It is the cheapest way to evidence privacy-by-design, and it means the capability exists if you are later designated.

Who signs off a DPIA?

For SDFs, the DPO supervises the assessment. Organisations without a statutory DPO should still name an accountable reviewer — an unsigned assessment is a draft.

Where to start

If you might be designated, the honest first question is not "how do we run a DPIA" but "can we enumerate our processing activities at all." Most organisations cannot, and that is the real blocker.

Start with a gap analysis, then discovery, then your processing register. DPIA capability follows from having something to assess.

See how risk scoring drives DPIA workflow from your RoPA

About the author

Yatin Chaudhary is an SEO Specialist at ProtectComply, where he writes about India's data protection framework and how organisations operationalise it.

How this article was researched

Written against Section 10 of the DPDP Act, 2023 and Rule 13 of the DPDP Rules, 2025. The absence of SDF designations is stated as of August 2026 and should be re-checked against the gazette — this article will be updated when notifications issue.

Corrections: write to [corrections email] and we will review and update.

Sources

• The Digital Personal Data Protection Act, 2023 — Section 10, Section 10(2)(c), and the penalty schedule
• Digital Personal Data Protection Rules, 2025 — Rule 13; gazette notification G.S.R. 846(E), 13 November 2025

General information, not legal advice. Consult qualified counsel before finalising your compliance position.