Skip to content
atlas

Data protection impact assessment (DPIA)

Also known as: DPIA

A written check, done before starting, of how a planned use of personal data could harm people and how to reduce that harm.

Draft - this entry has not been reviewed yet.

Formal

A risk assessment required by GDPR Article 35 before processing likely to pose a high risk to people's rights, such as large-scale tracking or health data; it describes the processing, tests its necessity and proportion, rates the risks and sets measures against them.

In plain English

Like an architect checking how a new building will affect the neighbours' light and noise before building starts, not after.

In practice

A Danish municipality plans an app that logs home-care visits by location; the data protection officer writes a DPIA, finds the tracking goes further than needed, and the app is limited to working hours with data deleted after 30 days.

Why it matters

Privacy harm is cheapest to prevent while the design can still change; if a high risk cannot be reduced, Datatilsynet must be consulted before the processing starts.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

  1. Screen every new or changed processing early in the project against Art. 35(3), Datatilsynet's list of processing that always needs a DPIA and the nine WP248 criteria, and record the conclusion even when no DPIA is needed.
  2. Name an owner on the controller side, seek the advice of the DPO (Art. 35(2)) and involve IT security and any processor, who must assist.
  3. Describe the processing systematically, covering data, people, purposes, systems, recipients and retention, for example in Datatilsynet's template.
  4. Assess necessity and proportionality, including the legal basis, data minimisation, retention periods and how people are informed and can use their rights.
  5. Identify the risks to the data subjects, not to the organisation, such as discrimination, loss of confidentiality or financial loss, and rate each by likelihood and severity.
  6. Choose measures that reduce each risk and link them to it, and seek the views of the data subjects or their representatives where appropriate (Art. 35(9)).
  7. If a high residual risk remains, consult Datatilsynet before the processing starts (Art. 36); the authority has eight weeks to give written advice, extendable by six.
  8. Have the DPIA approved, keep it with the record of processing and review it whenever the processing or the risk changes (Art. 35(11)).

Common pitfalls

  • Doing the DPIA after procurement has already locked the design, when the findings can no longer change anything.
  • Assessing risks to the organisation's assets instead of risks to the people whose data is processed.
  • Copying generic security controls into the DPIA without linking them to specific identified risks.
  • Treating the DPIA as a one-off document rather than a living assessment that follows the system.

Good guides

Technical deep dive

GDPR Art. 35(1) requires a DPIA before processing that, taking into account its nature, scope, context and purposes, and in particular the use of new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. Art. 35(3) lists three cases where a DPIA is always required: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based; large-scale processing of special categories (Art. 9) or criminal-offence data (Art. 10); and systematic monitoring of a publicly accessible area on a large scale. Under Art. 35(4) each supervisory authority publishes a list of processing types that always require a DPIA, and Datatilsynet's eight-item list covers, for example, biometric identification, genetic data, location data and new technologies when combined with at least one further WP248 criterion, large-scale profiling, and processing where a breach could directly affect a person's physical health or safety.

For everything else, the Article 29 Working Party guidelines WP248 rev.01, endorsed by the EDPB, give nine criteria: evaluation or scoring, automated decision-making with legal or similar effect, systematic monitoring, sensitive or highly personal data, large scale, matching or combining datasets, data concerning vulnerable subjects (employees, children, patients), innovative use of technology, and processing that prevents people from exercising a right or using a service. As a rule of thumb, processing meeting two or more criteria requires a DPIA; if the controller concludes otherwise, the reasoning should be documented.

Art. 35(7) sets the minimum content: a systematic description of the processing and purposes, including any legitimate interest; an assessment of necessity and proportionality in relation to the purposes; an assessment of the risks to data subjects; and the measures envisaged to address those risks, including safeguards and security mechanisms. The controller must seek the advice of the DPO where one is designated (Art. 35(2)) and, where appropriate, the views of data subjects or their representatives (Art. 35(9)). A single DPIA may cover a set of similar processing operations, and it must be reviewed when the risk changes (Art. 35(11)).

If residual risk remains high after mitigation, Art. 36 requires prior consultation of the supervisory authority before processing starts; the authority has eight weeks to give written advice, extendable by six weeks for complex cases, and may use its Art. 58 powers, including a ban. The key conceptual difference from an ISO 27005 or NIS2 risk assessment is the object of harm: a DPIA assesses risk to data subjects (discrimination, loss of confidentiality, chilling effects, financial loss), not to the organisation's assets. Common failure modes are performing the DPIA after procurement has fixed the design, treating it as a one-off document rather than a living assessment, and copying generic security controls without linking them to specific identified risks.

What to learn first

Everything this builds on, foundations first.

  1. Confidentiality
  2. →Personal data
  3. →GDPR
  4. →Data protection impact assessment (DPIA)

Relationships

Mandated by
GDPR

Sources & further reading

Standards & official texts

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.