DPIA Data Protection Impact Assessment.

When a DPIA is required, and when it is not

A Data Protection Impact Assessment is not paperwork you produce for every project. The GDPR ties it to one trigger: processing that is likely to result in a high risk to the rights and freedoms of individuals. The text names a few situations where the assessment is mandatory, such as systematic and extensive profiling that produces legal or similarly significant effects, large-scale processing of special category data, and large-scale systematic monitoring of a publicly accessible area. National supervisory authorities then publish their own lists of operations that always require a DPIA, and lists of operations that do not.

In practice you start with screening. Run a short list of risk criteria against the processing, the kind published by the European Data Protection Board, and count how many apply. Combinations such as evaluation or scoring plus automated decision-making, or sensitive data plus data processed on a large scale, push you over the threshold. When the answer is uncertain, the defensible move is to document why you concluded a full DPIA was not needed, not to skip the question silently.

What goes inside the assessment

The GDPR sets a minimum content. A DPIA must contain a systematic description of the processing operations and the purposes, an assessment of the necessity and proportionality of the processing in relation to those purposes, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged to address those risks, including safeguards and security measures. The CNIL ships a free PIA software tool that walks you through exactly this structure, and there is no reason to rebuild it from scratch.

Necessity and proportionality are where most assessments are thin. They are a legal test, not a security one: is each data field actually needed for the stated purpose, is the retention period justified, is there a lawful basis, are data subject rights served. The risk analysis is the security-flavoured part, and it borrows directly from risk management practice. This is where ISO 27005 and EBIOS Risk Manager give you the vocabulary of threats, feared events, likelihood and severity. A DPIA assesses risk to the individuals whose data is processed, not risk to the organisation, which is the distinction that trips people up.

Who does it, and how it stays alive

The controller is responsible for carrying out the DPIA. Where a Data Protection Officer is designated, the controller must seek their advice, and the DPO typically reviews the assessment and monitors its performance. You should also seek the views of data subjects or their representatives where appropriate. Processors have a duty to assist. If, after mitigation, the residual risk remains high and you cannot reduce it, the GDPR requires prior consultation with the supervisory authority before processing begins.

A DPIA is a living document. The controller must review it when there is a change in the risk represented by the processing, for instance a new data flow, a new technology, a new purpose, or a new subprocessor. Treat it as continuous: a useful rhythm is to re-examine assessments on a defined cycle and whenever the design changes, rather than filing them once and forgetting them.