DPIA: the assessment that has to be done before you build

A DPIA — data protection impact assessment — is a structured assessment of how a planned processing activity affects people’s privacy, and what you will do about the risks. Under the GDPR it is required where processing is likely to result in a high risk to individuals, and supervisory authorities publish lists of the operations that always trigger one: large-scale profiling, systematic monitoring of public areas, processing special-category data at scale, and similar.

The timing is the substance of the obligation. A DPIA is meant to be done before the processing starts, while the design is still soft, because its output is supposed to be changes: less data collected, shorter retention, pseudonymisation, an opt-out that was not planned. Written after go-live it becomes a description of a system nobody intends to alter, which is both a compliance failure and a waste of everyone’s afternoon.

What a DPIA has to contain

• A systematic description of the processing: what data, whose, from where, for what purpose, on what lawful basis, shared with whom, retained how long.
• An assessment of necessity and proportionality — whether you could achieve the purpose with less data or less intrusion. This is the question most assessments skip.
• The risks to individuals, expressed as harms to them rather than as risks to the organisation. Distress, discrimination, financial loss, loss of control over their data.
• The measures to address each risk, and the residual risk after those measures.
• The views of data subjects or their representatives where it is appropriate to seek them.
• Sign-off, and the data protection officer’s advice where one is appointed.
• A review trigger — the assessment is revisited when the processing changes.

Risks to people, not risks to you

The commonest defect in a DPIA is that its risk table is a corporate risk register in disguise: reputational damage, regulatory fines, project delay. Those are consequences for the organisation. The assessment is about consequences for the individuals whose data is processed, and the two lists overlap far less than teams expect. A system with a low fine risk can carry a high risk of a person being wrongly refused something, and the whole point of the exercise is to notice that before it is built.

If the residual risk remains high after mitigation, the GDPR requires prior consultation with the supervisory authority before starting. That is a real step with a real timeline, not a formality — which is another reason to run the assessment early rather than the week before launch.

When you need one, and when you do not

The trigger is likelihood of high risk, assessed against the criteria your authority publishes; where it is unclear, the pragmatic answer is a short screening assessment recording why a full DPIA was or was not required. That screening record is worth as much as the DPIA itself when someone asks two years later why an activity was not assessed. Note also that a DPIA covering a type of processing can cover several similar operations — you do not need a separate one per feature.

Where it lives alongside the rest of the file

A DPIA is a structured questionnaire with owners and dates, and it belongs next to the other privacy records rather than in a project folder that disappears with the project. Ettex Forms collects the assessment with the same questions each time, so screening decisions and full assessments are comparable; Ettex Records keeps them alongside the record of processing activities and the review dates; and Ettex Docs holds the sign-off and the DPO’s advice with version history — the difference between the draft that flagged a risk and the final that accepted it.

Being direct: this is forms and records, not privacy management software, and none of it is legal advice. Whether a DPIA is required, what your supervisory authority expects in it and when prior consultation is triggered are legal questions for your data protection officer or counsel.