Data protection impact assessment (DPIA)

The trigger is risk to people, not risk to the company. Classic triggers: systematic profiling or scoring with real effects on individuals, large-scale processing of sensitive categories like health data, monitoring of public or workplace behavior, combining datasets in unexpected ways, and deploying novel technology — AI features running against personal data being today’s most common example. European regulators publish lists of processing types that demand one; when a launch sits near the line, running the assessment is cheaper than debating it.

A DPIA reads like a risk assessment with the roles reversed — the risk owner is the data subject. It describes the processing and its purpose, tests whether the data collected is necessary and proportionate to that purpose, identifies what could harm individuals, and pairs each risk with mitigations: minimization, pseudonymization, access restriction, retention limits. If high risk remains after mitigation, the path leads through consultation with the regulator — a place product launches rarely want to be, and good pre-launch design avoids.

Teams that treat DPIAs as one-off emergencies write them badly, under deadline. The alternative is a lightweight screening question in product and vendor intake — does this change process personal data in new ways? — escalating to a full assessment only when triggers hit. Your counsel or DPO owns the legal judgment; the security team supplies the honest system description and the controls. Where the DPIA sits inside a broader GDPR program, alongside the DPA and records-of-processing work, is covered on the framework page.