DPIA template for DPDP and GDPR
that survives a second reading.
A nine-section Data Protection Impact Assessment template that works for DPDP Section 10 and GDPR Article 35, with notes on what makes each section pass or fail review. Free to copy.
Last updated Published by TryTrustableNot legal advice
What is a DPIA?
A Data Protection Impact Assessment (DPIA) is a documented assessment of one processing activity that describes the data involved, tests whether the processing is necessary and proportionate, scores the risks it creates for the people whose data it is, and records the measures that bring those risks down. It is done before the processing starts and repeated when the processing changes.
The point is a decision, not a document. A DPIA ends with someone accountable choosing to proceed, proceed with conditions, or stop, and with a record of why. That record is what a regulator, an auditor or a customer's privacy team asks to see.
When is a DPIA mandatory?
Under the GDPR a DPIA is mandatory whenever processing is likely to result in a high risk to individuals; under India's DPDP Act it is mandatory for Significant Data Fiduciaries, once every twelve months. Everyone else is not required to run one under DPDP, but a buyer's security review or a GDPR obligation often makes it necessary anyway.
GDPR, Article 35. Three cases always need one: systematic and extensive evaluation of people, including profiling, that produces legal or similarly significant effects; large-scale processing of special category or criminal offence data; and large-scale systematic monitoring of a publicly accessible area. The European Data Protection Board's guidance (WP248) lists nine criteria, such as evaluation or scoring, sensitive data, vulnerable people, new technology and data matching, and treats processing that meets two or more as likely to need a DPIA.
DPDP Act, section 10 and Rule 13. A Data Fiduciary notified as a Significant Data Fiduciary must carry out a DPIA and an independent data audit once in every twelve months and report significant observations to the Data Protection Board. Whether you are likely to be designated is a question for the Significant Data Fiduciary checker; when the duties commence is covered in the DPDP Act and Rules guide.
How does a DPDP DPIA differ from a GDPR one?
The structure is the same and one document can serve both, but the trigger, the timing and what follows differ. The table sets out where.
| GDPR (Article 35) | DPDP Act (s.10, Rule 13) | |
|---|---|---|
| Who must do one | Any controller whose processing is likely to be high risk | Significant Data Fiduciaries |
| Trigger | The nature of the processing | Designation by the government |
| When | Before the processing starts, and on change | Once every twelve months, with an independent audit |
| Advice | DPO's advice must be sought (Art. 35(2)) | Through the SDF's Data Protection Officer, based in India |
| If risk stays high | Prior consultation with the supervisory authority (Art. 36) | Significant observations reported to the Data Protection Board |
| Children | Vulnerable data subjects are a high-risk criterion | Under 18 is a child; tracking and targeted ads directed at children are prohibited (s.9) |
Read with the Act, the DPDP Rules 2025 and EDPB guidance WP248 rev.01. Not legal advice.
The nine sections
Copy this structure. The section titles matter less than the discipline of answering each one about a single processing activity rather than about the company in general.
| Section | What it has to establish |
|---|---|
| 1. What is being assessed | The processing activity, the system it runs in, and who owns it. One activity per assessment; a DPIA covering 'the product' is not an assessment. |
| 2. Data inventory | Every category of personal data involved, whether any of it is sensitive, the volume, and the source. If you cannot fill this in confidently, run discovery before you continue. |
| 3. Purpose and lawful basis | The purpose in plain language, the basis relied on, and for consent, the notice version that asked for it. |
| 4. Necessity and proportionality | Why this data and not less. The honest answer to 'what would break if we collected half of this' belongs here. |
| 5. Flows and recipients | Where the data goes, including processors, sub-processors and any transfer outside India, with the contract that binds each one. |
| 6. Retention and deletion | How long, on what trigger it is deleted, and whether deletion has actually been tested. |
| 7. Risks to Data Principals | Scored on likelihood and impact. Risks to people, not risks to the company: those are different registers and conflating them is the most common error. |
| 8. Controls and residual risk | The controls that treat each risk, and what the risk score is after they are applied. This is where the assessment stops being a document and becomes a decision. |
| 9. Sign-off | Owner, date, review date. Unsigned and undated assessments are the ones that fail review. |
The two failure modes
It describes intentions. An assessment that says data is encrypted at rest, when the assessment was written before the migration and the migration slipped, is worse than no assessment: it is a documented claim you cannot support. Write what is true today and date it.
It goes stale silently. A DPIA is a snapshot, and snapshots age. If the controls named in section 8 start failing, nothing in the document changes, which is exactly the gap between a document and a control. Tying the assessment to live control state is the fix, and it is why our risk register recalculates residual risk from control results rather than storing the number somebody typed.
Scoring risks to people
Use a 5×5 on likelihood and impact, and be explicit that impact means impact on the Data Principal. A breach that is embarrassing for you and harmless to users is a low-impact risk in a DPIA and a high-impact one in your corporate register. Keeping the two apart is what makes the assessment credible to a regulator.
Impact on a person, in ascending order: inconvenience, financial loss, discrimination, identity theft, physical safety. If sensitive data or children's data is involved, the impact floor rises regardless of likelihood.
Copy the template
A plain-text version of the nine sections with the prompts each one needs. Paste it into your document tool, keep one copy per processing activity, and keep every version.
DATA PROTECTION IMPACT ASSESSMENT
Processing activity: [one activity, e.g. "Credit scoring of loan applicants"]
Owner: [name, role] DPO / privacy lead: [name]
Version: [1.0] Date: [YYYY-MM-DD] Next review: [date, or on material change]
1. WHAT IS BEING ASSESSED
- Description of the processing and the system it runs in
- Why a DPIA is being done (mandatory trigger, SDF duty, or voluntary)
2. DATA INVENTORY
- Categories of personal data | sensitive? | volume | source
- Data about children? (DPDP: under 18)
3. PURPOSE AND LAWFUL BASIS
- Purpose in plain language
- Basis: consent (notice version ___) / legitimate use under DPDP s.7 / GDPR Art. 6 basis
4. NECESSITY AND PROPORTIONALITY
- Why each data item is needed; what would break with less
- Less intrusive alternatives considered and why rejected
5. FLOWS AND RECIPIENTS
- Processors and sub-processors, with contract reference
- Transfers outside India / outside the EEA, and the mechanism
6. RETENTION AND DELETION
- Retention period per category, deletion trigger, last deletion test
7. RISKS TO DATA PRINCIPALS
- Risk | likelihood (1-5) | impact on the person (1-5) | score
8. CONTROLS AND RESIDUAL RISK
- Control treating each risk | status today | residual score
- Residual high risk? (GDPR Art. 36 prior consultation)
9. SIGN-OFF
- Owner decision: proceed / proceed with conditions / do not proceed
- DPO advice recorded; signatures and datesA worked example: credit scoring in a lending app
A digital lender scores loan applicants using bank statements, device data and repayment history. It is the textbook case for a DPIA: scoring with significant effects on the person, financial data at volume, and a decision people cannot easily challenge.
- Data inventory. Identity and KYC data, bank statements, device identifiers, repayment history. Contacts and photo-library access are not needed for scoring and are removed in section 4
- Purpose and basis. Assessing creditworthiness for the loan the person asked for, on consent with an itemised notice that names each data category
- Risks to the person. Wrongful rejection from a model error (likelihood 3, impact 4); exposure of bank statements in a breach (2, 5); scoring that disadvantages a group (2, 4)
- Controls. Human review of every rejection on request; encryption and access logging on statement storage; a quarterly bias test of the model's approval rates; deletion of statements 90 days after the decision
- Decision. Proceed with conditions: the bias test and the rejection review must be live before launch, and the DPIA is reviewed when the model is retrained
How is a DPIA different from a risk assessment?
A DPIA assesses risk to the people whose data is processed; an information security risk assessment assesses risk to the organisation. The same breach can be low impact for the company and high impact for the people in it, which is why the two registers are kept apart and linked rather than merged. A legitimate interests assessment (LIA) is different again: it tests whether a GDPR Article 6(1)(f) basis holds, and is often an input to the DPIA rather than a substitute for it.
Findings from a DPIA should flow into the risk register where they create risk for the organisation, and the controls named in section 8 should be the same controls your security programme already tests.
Want it prefilled?
If your systems are connected, most of sections 2, 5, 6 and 8 can be generated rather than written: discovery knows what data you hold, the flow map knows where it goes, and the control graph knows which controls are passing today. What remains is the judgement in sections 4 and 7, which is the part worth your time. We will walk one through with you.
Section 2 is where most assessments stall, because nobody has a current inventory. Automated data discovery fills it from the systems themselves. For whether you need a DPIA at all under DPDP, and when Significant Data Fiduciary duties commence, see the DPDP Act and Rules 2025 guide; for what an SDF failure can cost, the DPDP penalty schedule.
The things people ask us
Who has to do a DPIA under DPDP?
Significant Data Fiduciaries must carry out periodic Data Protection Impact Assessments under Section 10. Everyone else is not required to, but the assessment is the cheapest way to find out what you actually process, and it is the document a buyer's security review asks for.
Is a DPDP DPIA the same as a GDPR one?
The structure is similar and one document can serve both if you are careful. The differences are that DPDP ties the assessment to SDF designation rather than to a risk threshold, and that the consent and notice sections need to reflect DPDP's specific requirements including the language obligation.
How often is 'periodic'?
The Act says periodic without fixing an interval. Annually, and on any material change to processing, is the defensible reading and the one most auditors will expect. A DPIA tied to live control state rather than a document also shows when it has gone stale, which is the point of repeating it.
What makes a DPIA fail a review?
Two things, consistently. It describes intentions rather than the system as built, and it has no date or owner, so nobody can tell whether it is current. Both are fixable by generating the assessment from live control state instead of writing it from memory.
When is a DPIA mandatory under GDPR?
When processing is likely to result in a high risk to people's rights and freedoms (Article 35(1)). Article 35(3) names three cases that always need one: systematic and extensive evaluation including profiling with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area. Supervisory authorities also publish their own lists of processing that needs one.
What happens if the DPIA shows high residual risk?
Under GDPR Article 36 you must consult the supervisory authority before the processing starts, if the risk stays high after the measures you plan. DPDP has no equivalent prior consultation; a Significant Data Fiduciary reports significant observations from its DPIA and audit to the Data Protection Board.
Who should write the DPIA?
The team that owns the processing, with the DPO or privacy lead advising and signing off. GDPR Article 35(2) requires the controller to seek the DPO's advice where one is designated. An assessment written only by the privacy team, without the engineers who built the system, tends to describe intentions.
Can one DPIA cover several processing activities?
Only similar ones that present similar risks, such as the same technology used across several branches. GDPR Article 35(1) allows a single assessment for a set of similar operations. A DPIA for 'the whole product' is almost always too broad to assess anything.
How long does a DPIA take?
For one well-understood activity with a current data inventory, a few days of elapsed time. Most of the delay is in section 2: finding out what data the system really holds. Without an inventory, start with discovery.
Stop writing assessments from memory.
Bring one processing activity to a 30 minute call. We will fill the template from your live systems and you will see which sections you could not have answered by hand.