Most organisations adopt a DPIA template for good reasons: consistency, coverage and a record for later review. The problem begins when the form becomes the process. Teams complete it after the design is fixed, reuse language from the last project and select familiar risks without testing the actual processing.
If the DPIA never changed a design decision, it was probably paperwork rather than assessment.
The template problem
Interviews and forms capture what a project team remembers to describe. A real assessment needs evidence: data flows, system architecture, intended users, access paths, recipients, retention logic, model behavior where AI is involved, and foreseeable misuse.
- The DPIA is requested as a release-gate document after implementation.
- Purpose, lawful basis and necessity are treated as the same question.
- Risks are written as organisational losses rather than harm to people.
- Mitigations repeat existing policy without an owner, date or test.
- Residual risk is marked “accepted” without naming who had authority.
When an assessment is required
Under GDPR Article 35, a DPIA is required where processing is likely to result in a high risk to individuals. The text specifically highlights systematic and extensive evaluation with significant effects, large-scale processing of special-category or criminal-offence data, and large-scale systematic monitoring of publicly accessible areas. Supervisory-authority lists and sector guidance add context.
Under India’s DPDP Act, section 10 requires a Significant Data Fiduciary to undertake periodic DPIAs and audits. The applicable rules, commencement position and any regulator directions should be checked at the time of assessment.
A good organisation also uses risk-based internal triggers. New technology, vulnerable people, location tracking, biometric processing, large-scale monitoring, data matching, consequential profiling or a material change to existing processing should trigger screening even before the legal threshold is concluded.
What a real DPIA does
| Stage | Question | Evidence | Decision |
|---|---|---|---|
| 1. Screen | Could this processing create high risk? | Trigger checklist, project brief, prior assessments | Full DPIA, documented no-DPIA decision, or escalation |
| 2. Describe | What exactly happens to whose data? | Data flow, systems, recipients, transfers, retention | Agreed processing description and boundaries |
| 3. Test necessity | Can the purpose be met with less data, access or retention? | Alternatives considered and rejected | Design reduced, justified or stopped |
| 4. Assess harm | What could happen to people? | Likelihood, severity, affected groups, existing controls | Prioritised inherent risks |
| 5. Treat risk | Which measures reduce each material risk? | Control owner, due date, test and closure evidence | Approved treatment plan |
| 6. Decide | Is residual risk acceptable and by whom? | DPO advice, approvals and consultation record | Proceed, redesign, consult or stop |
| 7. Review | Has the processing or risk changed? | Change records, incidents, complaints, audit results | Reassessment date or reopened DPIA |
Describe the processing precisely
Document data sources, categories, people affected, purposes, systems, recipients, transfers, access and retention. Vague processing descriptions produce vague risks and generic controls.
Test necessity and proportionality
Ask whether the purpose can be achieved with less data, shorter retention, fewer recipients, lower precision, local rather than central processing, or a less intrusive design. Record alternatives and why they were accepted or rejected.
Assess risk from the individual’s perspective
Consider discrimination, financial loss, identity misuse, exposure, physical or emotional harm, chilling effects and loss of control. Evaluate likelihood and severity for affected people—not only regulatory, reputational or commercial risk to the organisation.
Change the design and own the treatment
Every material risk needs a proportionate measure, named owner, due date and evidence of completion. Residual risk needs an accountable decision-maker; high residual risk may require regulator consultation under the applicable regime.
What the file should prove
- A dated processing description aligned to the RoPA or data inventory.
- The screening decision and trigger evidence.
- Alternatives considered and necessity reasoning.
- Risk statements describing cause, event and harm to people.
- Likelihood and severity criteria applied consistently.
- Measures with owners, dates, tests and closure evidence.
- DPO or privacy advice, stakeholder consultation and dissent recorded.
- Residual-risk approval and the authority of the approver.
- Review triggers and a next-review date.
Signs a DPIA is paperwork
- It was completed after the system went live.
- The risk section is identical to several earlier DPIAs.
- No alternative designs or data-minimisation decisions are recorded.
- Measures have no owner, date, test or closure evidence.
- Engineering, product, security or the operational owner did not contribute.
- Residual risk is accepted by the author rather than an accountable owner.
- The DPIA has not been reviewed since the processing changed.
Make the DPIA part of change
Trigger screening through procurement, product intake, architecture review and change management. Require the product owner and a technical contributor as co-authors. Link the assessment to the RoPA entry, vendor record, retention rule and control actions so changes in one record can prompt review of the others.
The DPIA should remain open until agreed measures have evidence of completion. Treat overdue actions and unreviewed material changes as control exceptions, not administrative reminders.
References and scope
- Regulation (EU) 2016/679 (GDPR), Articles 35 and 36.
- Article 29 Working Party Guidelines on DPIAs (WP248 rev.01), endorsed by the European Data Protection Board.
- Digital Personal Data Protection Act, 2023 (India), section 10, together with applicable rules and commencement notifications.
General information for practitioners, not legal advice. Legal requirements, rules and regulator guidance change; verify the current text, commencement position and facts relevant to your organisation before relying on this article.