DPIA and Privacy Risk

A statutory requirement for Significant Data Fiduciaries, and a genuinely useful habit for everyone else building anything new that touches personal data.

7 min readLast updated: Last updated: September 2026
Key Takeaway
  • A DPIA is a structured assessment of the risk to Data Principals' rights posed by a specific processing activity — required periodically for Significant Data Fiduciaries under Section 10.
  • Non-SDFs aren't legally required to run one, but it's a genuinely useful practice before launching anything that changes how personal data is collected or used.
  • A DPIA works best done before a feature or processing activity launches, not as a retrospective justification after the fact.
  • The output should be a documented decision, not just an exercise — what risk was identified, what mitigation was applied, and what residual risk was consciously accepted.

What Is a DPIA?

LawA Data Protection Impact Assessment is a structured review of the risk a specific processing activity poses to Data Principals' rights — considering the nature and purpose of the processing, the categories of data involved, and the potential harm if something goes wrong. For Significant Data Fiduciaries, Section 10 requires this be carried out periodically and reported to the Data Protection Board alongside the independent compliance audit covered in Chapter 13.

Why DPIA Matters

PracticeBeyond the SDF requirement, a DPIA forces a genuinely useful conversation before a new feature or processing activity ships: why do we need this specific data, what happens if it's misused or breached, and is there a less risky way to achieve the same goal. Running this conversation before launch is materially cheaper than discovering the same issues after a feature is live and being used by real Data Principals.

When a DPIA May Be Relevant

Beyond the SDF statutory trigger, a DPIA is worth running before: launching a new feature that collects a new category of personal data, introducing a new tracking or profiling capability, starting a new large-scale data-sharing arrangement with a third party, or processing data in a way that could plausibly affect a vulnerable group (including, notably, children — see Chapter 11).

Privacy Risk Assessment

PracticeAt its core, a DPIA is a risk assessment with a specific subject: not "what could go wrong for the business" (the usual frame of a general risk assessment) but "what could go wrong for the individual whose data this is." That reframing tends to surface different concerns than a standard security or product risk review would on its own.

Identifying Risks

  • What categories of personal data does this activity involve, and how sensitive are they?
  • Who could be harmed if this data were breached, misused, or inferred incorrectly, and how seriously?
  • Is the processing proportionate to the purpose, or does it collect more than necessary?
  • Does this activity involve automated decision-making that could affect a Data Principal without meaningful human review?
  • Does it involve a vulnerable group, including children?

Risk Mitigation

Once risks are identified, the DPIA should document what mitigation is applied to each — reducing the data collected, adding stronger access controls, anonymising or pseudonymising where the purpose still works without full identifiability, or in some cases deciding not to proceed with the processing as originally scoped. Not every identified risk needs to be eliminated — some can be consciously accepted — but the assessment should make that a deliberate decision, not a gap nobody noticed.

DPIA Process

StepWhat happens
Describe the processingWhat data, what purpose, what systems, who has access
Assess necessity and proportionalityIs this the minimum data needed for the stated purpose?
Identify risksWhat could go wrong, for whom, and how severely
Apply mitigationReduce, safeguard, or redesign the processing
Document and sign offRecord the assessment, decisions made, and residual risk accepted
Example DPIA workflow

A consumer app is planning a new feature that infers a user's likely location patterns from GPS data to personalise recommendations. A DPIA run before launch identifies that raw location history is more granular than the feature actually needs, that the data would be highly sensitive if breached, and that a coarser, less precise location signal would serve the same product purpose with meaningfully lower risk — leading the team to redesign the feature around the coarser signal before shipping, rather than after a privacy complaint or incident forces the same conversation later.

Documentation

PracticeA DPIA that exists only as a conversation nobody wrote down isn't much use if it's ever questioned later — by the Data Protection Board for an SDF, or simply by your own team six months on trying to remember why a particular design decision was made. A short, consistently used template (the process table above is a reasonable starting point) is more valuable than an elaborate one nobody actually completes.

Related Topics

Frequently Asked Questions

Who is legally required to run a DPIA under DPDP?

Significant Data Fiduciaries, periodically, under Section 10. Other Data Fiduciaries aren't statutorily required to, though running one before a data-heavy launch is good practice regardless.

Is a DPIA the same as a general security risk assessment?

Related, but not identical — a DPIA specifically centres the risk to the individual Data Principal, rather than risk to the business, and considers proportionality and necessity of the processing itself, not only technical security controls.

What should a completed DPIA actually document?

The processing activity assessed, the risks identified, the mitigation applied, and any residual risk consciously accepted — a decision record, not just a completed exercise.

Sources