Running a data protection impact assessment

If you came here because somebody has told you that a thing you are about to launch "needs a DPIA" and you are not sure what that means or who does it, the short version is: a data protection impact assessment is a written analysis, done before the processing starts, of what could go wrong for the people whose data it is — and of whether your safeguards bring that risk down far enough. This page is where you write and keep one.

Find it at Govern → DPIAs (/compliance/gdpr/dpia).

When an assessment is required

Article 35(1) requires one where processing is likely to result in a high risk to the rights and freedoms of natural persons — in particular where new technology is involved. The Regulation then names three cases outright: systematic and extensive automated evaluation of people, including profiling, where decisions with legal or similarly significant effects follow; large-scale processing of special-category data such as health, biometrics or criminal convictions; and systematic monitoring of a publicly accessible area. Your national supervisory authority publishes its own list on top of that, and those lists differ between member states.

In an SMB the honest triggers are usually mundane: putting cameras up, screening job applicants with a tool that ranks them, tracking staff devices or location, or handling health data for the first time.

The two risk questions, which are not the same question

The form asks about risk twice, and people routinely answer the second with the first. They are asking different things and the modal says so at the top.

Art. 35(1) high-risk processing — the checkbox

Is this the kind of processing that requires an assessment at all? This is about the processing as designed, before you do anything about it. It is the reason the record exists.

Residual risk — the dropdown

What is left over after the measures you describe in the assessment. A processing operation can be firmly high-risk under 35(1) and still end at a low residual risk, because that is what a good DPIA is for. This is the field that drives everything else on the page.

The residual-risk choices are Not assessed (the default), Low, Medium and High, and each carries its consequence in the dropdown itself — for example High — triggers the Art. 36(1) duty to consult.

Not assessed is itself a finding. Leave residual risk at its default and the register records an outstanding duty against the assessment: no residual risk has been assessed, so the record cannot show whether the Article 36(1) duty is triggered. An assessment that stops before the conclusion is not neutral — it is one that has not answered the question it was written to answer.

What a high residual risk actually means

Article 36(1) is the sharp edge of the whole regime. If your assessment concludes that a high risk remains after your mitigations, you must consult your supervisory authority before the processing begins. Not notify afterwards. Consult first, and wait.

So the Prior consultation field is not decoration. Its four states are the steps of that duty: Not required (residual risk is not high), Not started (owed and not begun), Submitted (sent to the authority), and Advice received (the authority has responded). Record a high residual risk while consultation is not required or not started and the register raises an obligation against that row, shown in the table and thrown as a fifteen-second error toast when you save:

The server also accepts the combination that should not exist — high residual risk with prior consultation left at Not required — because forcing the field would be the product overruling your assessment. It records the contradiction as an obligation instead.

The five elements the register counts

Article 35(7) sets out what an assessment must contain, and 35(2) adds the DPO's advice. That makes five counted elements, shown in the table as N/5.

Processing description — Art. 35(7)(a)

A systematic description of the operations and their purposes, including any legitimate interest you are relying on.

Necessity and proportionality — Art. 35(7)(b)

Why this processing is necessary and proportionate to the purposes. Not to your convenience, and not to the cost of the alternative. This is the element assessments most often skip.

Risks to data subjects — Art. 35(7)(c)

Risks to the rights and freedoms of the people whose data it is — not risks to the organisation. If what you have written is about fines and reputation, you have answered a different question.

Measures addressing the risks — Art. 35(7)(d)

The safeguards, security measures and mechanisms that actually reduce the risks described immediately above. These are what justify a residual risk lower than the risk itself.

DPO advice — Art. 35(2)

The advice you sought from your data protection officer. Required where one is designated. If you have not designated a DPO, say so here rather than leaving it blank.

There is a sixth long field, Views of data subjects — Art. 35(9), and it is deliberately excluded from the N/5. The Regulation qualifies it with "where appropriate", so an assessment that leaves it empty is not thereby incomplete. It is on the form because seeking those views is often the right thing to do and is worth recording when you did — or worth recording why it was not appropriate.

Recording an assessment

1. 1

   Press Add assessment

   Top right, or from the empty state. The empty state is blunt about what it means: this register is empty because nothing has been recorded, not because no high-risk processing exists.

2. 2

   Name the processing operation

   The only genuinely required field. "Automated candidate screening", "Reception area CCTV". As with the Article 30 register, this name is the key the assessment is stored under, so choose it carefully.

3. 3

   Answer the two risk questions and write the five elements

   Residual risk and prior consultation are marked required but both already carry a default, so they can never actually block the save. Everything else is free text and nothing checks it.

4. 4

   Save assessment

   Expect up to three toasts: one confirming the save, a warning if elements are missing, and one error toast per outstanding legal duty. The duty toasts stay on screen for fifteen seconds because they are the ones that matter.

As with the record of processing, an incomplete assessment saves. It is then permanently marked: This DPIA states 3 of the 5 elements the Regulation requires. Missing: … It is recorded and versioned, but it is not a complete record and must not be filed as one. The N/5 counts fields that contain text; it cannot judge whether what you wrote is any good, so do not read 5/5 as approval.

Amending an assessment, and the consultation workflow that is missing

There is also no delete, for an assessment or for anything in either GDPR register. A record created by mistake stays. And unlike the NIS2 incident register, which enforces its reporting sequence and refuses to skip a step, the consultation status here can be written to any value in any order, including backwards — nothing validates the transition.

Every write is entered in the hash-chained compliance audit log, including the residual risk and the count of open obligations at the time. That log is where a prior version of an assessment can be recovered, and this page does not link to it — see Verifying the audit chain. If a save reports that the audit receipt was not written, the assessment was stored outside the integrity proof; report it.

Reading the register

The counters appear only once there is at least one assessment. The table sorts by operation, elements or last updated, has a search box, and — like the Article 30 register — has no row actions, no row click and no detail view. Everything each assessment contains beyond its summary lines is visible only in the evidence bundle.

Obligations are recomputed from scratch every time the register is read. They cannot be acknowledged, assigned, dated, justified or waived. An obligation disappears only when the underlying facts change — when consultation moves to submitted, or the residual risk is reassessed.

Getting an assessment out of the product

There is no export on this page. Assessments leave through the evidence bundle at Govern → Evidence, and the two forms differ badly here.

What this register does not do

• No prior-consultation workflow, no consultation date, and nowhere to record the authority's response.
• No edit and no delete. Amendment is overwrite-by-retyping the operation name.
• Nothing is blocked by a high-risk assessment, anywhere in the product.
• No notification outside this page. No email, no task, no reminder, no dashboard mention. An outstanding Article 36 duty is invisible unless somebody opens this screen.
• No reviewer, approver, review date or validity period. The only provenance is who wrote it last and when. A DPIA is supposed to be revisited when the processing changes; nothing here tracks that.
• No link to the Article 30 record, to an AI system card, to an asset or to a vendor, even though a DPIA and a record of processing usually describe the same activity.
• No version history in the interface, despite assessments being versioned in the audit log.
• Nothing highlights the missing elements when you reopen the form; the server names them once, in a toast.

What to do next

1. Record the assessment before the processing starts, even if it is skeletal. A DPIA written afterwards is a different document with a different name.
2. Write the risks to the people first, then the measures, then conclude the residual risk. Doing it in that order is what stops the conclusion being decided in advance.
3. If the conclusion is High, set prior consultation to Not started immediately and treat the obligation as a live blocker in your own planning — because the product will not treat it as one.
4. Set a calendar reminder yourself to revisit each assessment. Nothing here will remind you.
5. Keep the matching entry in the record of processing activities in step by hand; the two registers do not know about each other.