DPDPA 2023 — Section 10 · DPDP Rules 2025 — Rule 13 · Complete DPIA Guide
A Data Protection Impact Assessment is the most powerful tool your organisation has to identify, measure, and mitigate data protection risks before they become regulatory violations. Under the DPDP Act 2023 and DPDP Rules 2025, Significant Data Fiduciaries must conduct a DPIA every 12 months and submit findings to the Data Protection Board. For all other Data Fiduciaries, a DPIA is best practice that directly reduces your exposure to the Act's harshest penalties. This guide explains exactly what a DPIA is, when you need one, and how to conduct one — with a practical framework you can begin using today.
Key Facts — DPIA Under DPDPA
Rule 13
DPDP Rules 2025 — SDF DPIA obligation
Every 12 Months
Mandatory frequency for SDFs
Board Filing
Findings submitted to Data Protection Board
Rs.250 Cr
Max penalty if violations found
What This Guide Covers
- What is a Data Protection Impact Assessment?
- DPIA vs Compliance Audit — the critical difference
- Who is legally required to conduct a DPIA?
- When should non-SDF organisations conduct a DPIA?
- The high-risk processing trigger checklist
- Step-by-step DPIA process — 7 stages
- Risk scoring framework with sample register
- DPIA and board approval obligations
- Submitting findings to the Data Protection Board
- DPIA for AI and algorithmic systems
- Common DPIA mistakes to avoid
- Complete DPIA template framework
1. What is a Data Protection Impact Assessment?
A Data Protection Impact Assessment (DPIA) is a structured, documented process that helps an organisation identify and evaluate data protection risks associated with a specific processing activity — before that activity begins or as part of periodic review — and implement measures to reduce those risks to an acceptable level.
Think of it as a privacy risk audit applied to a specific processing activity. Where a general compliance audit asks "are we compliant overall?", a DPIA asks "does this specific data processing activity create unacceptable risks to the individuals whose data we process?"
What a DPIA achieves
- Identifies privacy risks before they become violations
- Documents your risk assessment as evidence of due diligence
- Satisfies the Data Protection Board that you are proactive
- Informs product and system design decisions
- Reduces penalty exposure by demonstrating accountability
- Protects individuals whose data you process
What a DPIA is NOT
- Not a general compliance checklist
- Not a one-time activity — it is periodic and iterative
- Not something you do after a problem occurs
- Not a box-ticking exercise — must be substantive
- Not the same as a security audit
- Not a substitute for fixing the risks identified
2. DPIA vs Compliance Audit — The Critical Difference
Under the DPDP Rules 2025, these are two separate, distinct obligations for Significant Data Fiduciaries — both required annually, both with different objectives.
| Aspect |
DPIA |
Compliance Audit |
| Focus | Risks to individuals from specific processing | Whether the org complies with DPDPA overall |
| Scope | Activity-specific | Organisation-wide |
| Output | Risk register + mitigation measures | Compliance report with gaps |
| Who conducts | DPO + internal team | Independent data auditor (mandatory for SDFs) |
| Timing | Before high-risk processing + annually for SDFs | Annually for SDFs |
| Board filing | Significant findings to Data Protection Board | Significant findings to Data Protection Board |
3. Who is Legally Required to Conduct a DPIA?
Rule 13 of the DPDP Rules 2025 makes annual DPIAs mandatory for all entities designated as Significant Data Fiduciaries (SDFs). The government designates SDFs based on the volume and sensitivity of data processed and potential risks to Data Principals.
MANDATORYSignificant Data Fiduciaries (SDFs)
Must conduct a DPIA every 12 months from SDF designation. The DPO oversees it, an independent auditor reviews it, and significant findings go to the Data Protection Board. No exemption once designated. Likely includes: large tech platforms, banks, payment aggregators, large e-commerce, healthcare data processors.
BEST PRACTICEStandard Data Fiduciaries (non-SDF)
Not legally mandated but strongly recommended whenever processing involves high-risk activities. A voluntary, documented DPIA creates evidence of due diligence that significantly reduces penalty exposure if the Board investigates. The Board's adjudication process considers whether the organisation took proactive steps to assess and mitigate risks.
4. The High-Risk Processing Trigger Checklist
Even without a legal mandate, conduct a DPIA whenever any of the following apply:
+Processing at large scale — millions of Data Principals
+Processing children's personal data (Section 9)
+Automated decision-making affecting individuals' rights or finances
+Financial data — credit, income, transactions
+Health, medical, or biometric data
+Continuous or systematic location tracking
+New AI, ML, or profiling systems using personal data
+Cross-border transfer of personal data
+Sharing data with third parties — vendors, partners, advertisers
+Launching a new product or feature that uses personal data
+Combining or merging datasets from different sources
+Surveillance or monitoring of employees
5. Step-by-Step DPIA Process — 7 Stages
1
Identify the Processing Activity and Determine DPIA Necessity
Define what processing activity you are assessing. Document the purpose, data types, Data Principals affected, and data flows. Then formally determine whether a DPIA is required using the high-risk checklist above. Record the decision and rationale — even if you decide a full DPIA is not required, document why.
2
Describe the Processing in Detail
Create a comprehensive description: how data is collected, where it is stored, who has access, how long it is retained, how it is deleted, all third parties who receive it, and technical/organisational security measures currently in place. Include a data flow diagram. This is your expanded Record of Processing Activity (RoPA) entry.
3
Assess Necessity and Proportionality
For each data element: Is this data actually necessary for the stated purpose? Could we achieve the same purpose with less data? Could we use anonymised data instead? Is the retention period proportionate? Is cross-border transfer necessary? Is every team member with access actually required to have it? This is DPDPA's data minimisation principle applied to specific processing.
4
Identify and Document Privacy Risks — Build the Risk Register
This is the core of the DPIA. For each processing activity and data element, identify every risk to Data Principals. Risk categories to assess: unauthorised access/breach, unauthorised disclosure to third parties, data inaccuracy leading to wrongful decisions, excessive retention, unlawful purpose change (repurposing), cross-border transfer risks, automated decision-making errors, consent withdrawal not honoured, children's data mishandling.
5
Score Each Risk — Likelihood x Impact
Score each identified risk on Likelihood (1–5) and Impact (1–5). Multiply for a Risk Score (1–25).
| Risk Level | Score | Action Required |
|---|
| Critical | 16–25 | Must not proceed without mandatory mitigation. Escalate to Board immediately. |
| High | 9–15 | Strong mitigation required before processing begins. DPO sign-off needed. |
| Medium | 4–8 | Mitigation recommended. Monitor quarterly. |
| Low | 1–3 | Document and accept. Standard controls sufficient. |
6
Identify and Implement Mitigation Measures
For every High and Critical risk, document specific mitigation measures. Re-score the residual risk after mitigation. Common measures: encryption at rest and in transit, role-based access controls, data minimisation, pseudonymisation, consent mechanism redesign, vendor DPA execution, retention period reduction, security audit of third-party systems, staff training, privacy-by-design in architecture, incident response plan update.
7
Document, Approve and Submit — The DPIA Report
Compile the DPIA into a formal report. For SDFs, the DPO reviews it, the board approves it, and significant findings go to the Data Protection Board. For all organisations, the DPIA report is your primary evidence of due diligence in any enforcement investigation. Set the next review date — 12 months for SDFs, or earlier if the processing materially changes.
6. Sample Risk Register — Lending App Credit Bureau Query
| Risk |
Likelihood |
Impact |
Score |
Mitigation |
Residual |
| Bureau data used for marketing without consent |
4 |
4 |
16 Critical |
Separate marketing consent; technical block on bureau data in CRM; staff training |
3 Low |
| Bureau API breach — data leaked in transit |
2 |
5 |
10 High |
TLS 1.3 encryption; API key rotation; pentest of bureau integration; vendor DPA |
4 Medium |
| Borrower unaware bureau was queried |
3 |
3 |
9 High |
Prominent disclosure in consent; in-app notification at bureau query |
2 Low |
| Bureau data retained after loan closure |
3 |
2 |
6 Medium |
Automated deletion schedule (10 years per RBI); quarterly deletion audit |
2 Low |
7. DPIA and Board Approval
For SDFs, the DPIA is a board governance obligation — not just an operational document. The DPO reports directly to the Board under DPDPA Section 10.
What the Board Receives
- DPIA executive summary — plain language
- Critical and High risk findings highlighted
- DPO opinion and recommendations
- Proposed mitigations with timelines
- Budget required for mitigation
- Residual risks remaining
What the Board Must Do
- Review findings at a board meeting
- Formally approve proposed mitigations
- Allocate budget for implementation
- Set timelines and accountability
- Decide whether to proceed with high-risk processing
- Record all decisions in board minutes
What the Board Cannot Do
- Simply acknowledge receipt without review
- Override DPO recommendations without documentation
- Approve Critical residual risks without resolution
- Fail to allocate budget for mandated mitigations
- Defer DPIA review indefinitely
8. DPIA for AI and Algorithmic Systems
The DPDP Rules 2025 impose a specific obligation on SDFs — algorithmic due diligence. SDFs must ensure that any algorithmic software used for handling personal data is designed and verified to safeguard against risks to Data Principals' rights. This creates a DPIA obligation for every AI/ML system processing personal data.
AIRisk: Discriminatory Algorithmic Outputs
Credit scoring, hiring, or insurance algorithms trained on historical data may produce discriminatory outputs. The DPIA must include bias testing and fairness assessment for all algorithmic outputs that affect individuals.
AutoRisk: Automated Decisions Without Human Review
Fully automated decisions — loan approval, insurance pricing, employment — must have a meaningful human review mechanism. Document how individuals can contest automated decisions in the DPIA.
DataRisk: Training Data Purpose Violation
Using personal data collected for one purpose (loan processing) to train an AI model is a separate processing purpose requiring separate consent. Confirm only anonymised/synthetic data is used for training, or document the legal basis.
9. Common DPIA Mistakes — How to Avoid Them
XConducting DPIA after processing has already started
A post-facto DPIA has reduced legal value. Its purpose is to influence decisions before they are made — not document risks after systems are live. Post-launch risks are harder and more expensive to fix.
XTreating DPIA as a form-filling exercise
A DPIA that identifies zero High or Critical risks for large-scale personal data processing is almost certainly not genuine. The Board will scrutinise DPIA quality — a superficial DPIA may be worse than none.
XNo mitigation implementation follow-through
Identifying risks and recommending mitigations without implementing them is the most common DPIA failure. Include an implementation tracker with named owners, deadlines, and sign-off in every DPIA report.
XScoping the DPIA too narrowly — ignoring vendors
A DPIA covering only your own systems and ignoring vendor processing is incomplete. If vendors process your Data Principals' data, their processing must be included in your risk assessment.
XOne DPIA for the entire organisation
A DPIA is processing-activity specific. An organisation with 15 different data processing activities needs 15 DPIAs — not one generalised document. Each activity has different risks, data types, and mitigation needs.
10. Complete DPIA Report Template Structure
DPIA Report — Section Structure
A
Cover Page and Metadata
DPIA title, organisation, processing activity name, DPO name, date, review date, version, classification (Confidential)
B
Executive Summary
One-page plain language summary of the processing, top risks found, mitigations recommended, and overall risk level. Written for board review — no technical jargon.
C
Processing Activity Description
Purpose, legal basis, data types, Data Principals affected, data flow diagram, systems, vendors, retention period, geographic scope
D
Necessity and Proportionality Assessment
For each data type: necessity test, proportionality test, data minimisation analysis
E
Risk Register — Core DPIA Document
Risk ID, description, Data Principals affected, Likelihood (1–5), Impact (1–5), Inherent score, current controls, mitigation measures, risk owner, deadline, residual score
F
DPO Opinion and Recommendation
Formal DPO opinion on whether processing should proceed, with conditions if applicable. Goes to the Board for SDFs.
G
Board Approval Record
Date of board review, resolution number, decisions made, budget allocated, processing approved/conditional/rejected, sign-off
H
Implementation Tracker and Next Review
Mitigation status table, named owners, completion dates, verification method, next DPIA review date, trigger conditions for early review
Need a DPIA Conducted for Your Organisation?
A DPIA conducted without legal and privacy expertise cannot reliably protect your organisation. Risk scoring, necessity assessment, and mitigation design require understanding of both DPDPA's legal standards and the technical realities of your systems. A DPIA that misclassifies risks does not reduce your legal exposure — it documents your failures.
Our advocates and DPDPA compliance specialists conduct end-to-end DPIAs — from mapping processing activities and scoring risks to drafting the board report and preparing the Data Protection Board submission. We also provide DPIA templates and training for in-house teams building sustainable compliance capability.
