DPIA in India: When You Need One and How to Run It
TL;DR
Under the DPDP Act, DPIAs are mandatory only for Significant Data Fiduciaries, which must run one every 12 months and report significant observations to the Data Protection Board (Section 10, Rule 13). Every other organisation should still assess high-risk processing before launch: children's data, large-scale profiling, new technologies and sensitive data. A good DPIA describes the processing, tests necessity, identifies risks to individuals and records the measures taken.
Who this is for: DPOs, privacy leads and product teams deciding whether, when and how to assess privacy risk.
A Data Protection Impact Assessment (DPIA) is a structured look at a processing activity before it goes live: what data it uses, why, what could go wrong for the people involved, and what you will do about it. Under the DPDP Act, it is a legal requirement for some organisations and good judgement for the rest.
When a DPIA is mandatory
Section 10(2)(c) requires Significant Data Fiduciaries to carry out periodic DPIAs. Rule 13 sets the frequency and content:
- a DPIA every 12 months
- containing a description of the rights of Data Principals and the purpose of processing
- with an assessment and management of the risk to those rights
- with significant observations from the DPIA and the annual audit reported to the Data Protection Board
See Significant Data Fiduciary for who may be designated.
When to run one anyway
For everyone else, a DPIA is not required by law, but it is the clearest evidence that you considered and managed risk, a factor the Board must weigh when setting a penalty under Section 33(2). Run one before:
- processing children's data at scale
- large-scale profiling, scoring or automated decisions
- new technologies such as biometrics, face recognition or AI models trained on personal data
- combining data sets from different sources
- systematic monitoring of employees or the public
- large-scale processing of financial, health or location data
- new cross-border transfers of large data sets
A practical DPIA method
1. Describe the processing
Purpose, data items, Data Principals, volumes, sources, systems, vendors, transfers and retention. Pull this from your ROPA.
2. Confirm the lawful basis
Consent or a specific legitimate use, and why it fits.
3. Test necessity and proportionality
Is each data item needed? Could the purpose be met with less data, less intrusive methods or shorter retention?
4. Identify risks to individuals
Think from the Data Principal's side, not the company's:
| Risk | Example |
| Loss of confidentiality | Breach exposes health or financial data |
| Loss of control | Data used for purposes people didn't expect |
| Discrimination or unfair decisions | Biased scoring model denies loans or jobs |
| Harm to children | Engagement design affects well-being |
| Inaccuracy | Wrong data drives a decision about someone |
| Inability to exercise rights | Data spread across systems can't be found or erased |
5. Rate and treat each risk
Rate likelihood and severity, then record measures: minimisation, encryption, access control, human review, notices, consent design, retention limits, vendor terms.
6. Decide and sign off
Record the residual risk, who accepted it, and any conditions for launch. Unacceptable residual risk means redesign.
7. Review
Revisit when the processing changes, and at least annually for SDFs.
Common mistakes
- Running the DPIA after launch. It becomes documentation, not design.
- Assessing risk to the company, not to people.
- A template filled in once and filed. DPIAs should change decisions.
- No owner for actions. Measures that nobody implements reduce no risk.
How ConsentifyAI helps
ConsentifyAI starts each DPIA from the processing activity already recorded in your ROPA, guides teams through necessity and risk questions, tracks mitigation actions to completion, and keeps a versioned history of each assessment for annual reviews and audits.
Sources & references
- DPDP Act, 2023 — Section 10(2)(c)
- DPDP Act, 2023 — Section 33(2)
- DPDP Rules, 2025 — Rule 13
Frequently asked questions
Is a DPIA mandatory under the DPDP Act?
Only for Significant Data Fiduciaries, under Section 10(2)(c) and Rule 13, which require a DPIA every 12 months.
What must an SDF's DPIA contain?
A description of the rights of Data Principals and the purpose of processing, and an assessment and management of the risk to their rights. Significant observations must be reported to the Board.
Should non-SDFs run DPIAs?
For high-risk processing, yes. It is the most practical way to show that risks were considered and managed, which the Board can weigh in any penalty.
When should a DPIA be done?
Before high-risk processing starts, and again when it changes significantly. SDFs must also complete an annual DPIA.
Who should run the DPIA?
The DPO or privacy lead, with the business owner, engineering, security and legal.
Related reading
Significant Data Fiduciary: Are You on the Government's Radar?
The government can designate any Data Fiduciary, or class of fiduciaries, as a Significant Data Fiduciary (SDF) based on data volume and sensitivity and risks to individuals, the state and public order (Section 10). SDFs must appoint a DPO based in India, an independent data auditor, and run an annual DPIA and audit (Rule 13), plus due diligence on algorithms and any localisation the government specifies. Criteria have not yet been notified, but likely candidates should prepare now.
ReadROPA Under DPDP: Map Every Data Flow Before Someone Else Does
Unlike the GDPR, the DPDP Act does not explicitly require a Record of Processing Activities. But without one, you cannot write itemised notices, tell individuals who received their data, erase it on time, scope a breach within 72 hours, or prove compliance. A DPDP ROPA records each processing activity's purpose, data, individuals, lawful basis, systems, recipients, transfers, retention and safeguards. It is the foundation every other DPDP control is built on.
ReadThe Consent Lifecycle: How to Build Consent You Can Prove
Under the DPDP Act, consent has to be valid when given, honoured while it lasts, withdrawable at any time and provable afterwards. That makes it a lifecycle, not a checkbox. Design it as states and events: notice, capture, record, propagate, use, modify, renew and withdraw. A central registry of purposes, a consent ledger as the single source of truth, event-driven integrations and an audit layer turn that lifecycle into something your teams can operate.
Read