Article 35

A DPIA is the written record of a decision you make before launch.

Some projects can hurt the people whose data they use: a scoring model that shuts someone out, a camera network that follows a crowd. For those, the GDPR wants you to stop, look at the harm from their side, and write down what you changed. That written look is the data protection impact assessment (DPIA), and it has to exist before the processing begins.

Back to GDPR services

01 · Screening first

Screening: the short test that decides if you need the long one

Nine warning signs. Two or more usually means a full assessment.

Most teams do not need a DPIA for every release. They need a screening step that runs on every release. The Article 29 Working Party, whose DPIA guidelines the European Data Protection Board (EDPB) later endorsed, listed nine signs that processing may be high risk. Where a plan shows two of them, the guidance treats a DPIA as the normal outcome.

Warning signIllustrative trigger in a product team
Evaluation or scoringRanking loan applicants or predicting churn per person
Automated decisions with real effectAn algorithm rejects a job application with no human review
Systematic monitoringTracking staff laptops or customer movement in a store
Sensitive or highly personal dataHealth notes, location history, private messages
Large scaleA whole national customer base, or years of records
Matching or combining datasetsJoining app data with a purchased marketing list
Vulnerable peopleChildren, patients, employees, asylum seekers
New technologyFace matching, voice analysis, a new AI feature
Blocking a right or a serviceA risk score that decides who may open an account

Keep the screening result even when it says no. A one-paragraph negative screening is the evidence that you asked the question.

02 · Mandatory cases

Three situations where the Regulation removes the choice

Article 35(3) names them; national lists add more.

Automated evaluation with serious consequences
Systematic and extensive assessment of people, including profiling, that drives decisions with legal or similarly serious effects on them.
Sensitive data in bulk
Large-scale processing of the special categories in Article 9, or of data on criminal convictions and offences.
Watching public spaces at scale
Systematic monitoring of a publicly accessible area on a large scale.

Each supervisory authority must also publish a list of processing types that always need a DPIA, and may publish a list of types that never do. Check the list of every authority whose residents you serve, because they differ.

03 · What it holds

What the finished document has to show

Four required elements, plus two voices you must ask.

  • A clear picture of the processing. What data, from whom, for what purpose, through which systems and vendors, and the legitimate interest relied on where there is one.
  • A necessity test. Why this much data, for this long, is needed for the purpose, and why a lighter design would not do.
  • The risks to people. Likelihood and severity of harm to the individuals, judged from their position.
  • The measures. Safeguards, security controls and design changes that reduce those risks, and how you will show they work.
  • The DPO's advice. Where you have a data protection officer, their view must be sought and recorded.
  • People's views, where appropriate. Feedback from those affected or their representatives, such as a staff council for a monitoring tool.

04 · Whose risk

The risk you measure is theirs, not yours

A security risk register and a DPIA look in opposite directions.

Company risk register

  • Asks what could hurt the business
  • Losses are outages, fines, lost deals
  • Owned by security or risk

DPIA

  • Asks what could hurt the individual
  • Harms are discrimination, financial loss, loss of control over their data, a chilling effect
  • Owned by the team that designs the processing

Security controls feed both. A DPIA that lists only firewalls and encryption has missed the point.

05 · High residual risk

When the risk is still high after your fixes

Article 36: ask the authority before you go live.

  1. Your measures are in place, and the assessment still shows a high residual risk to people.
  2. You submit the DPIA to the supervisory authority for prior consultation before processing starts.
  3. The authority has up to eight weeks to give written advice, extendable by six weeks for complex cases.
  4. If it finds the plan would break the GDPR, it can use its corrective powers, up to banning the processing.

A DPIA is not finished at sign-off

Review it when the risk changes: a new data source, a new vendor, a new country, a model retrained on different data. Article 35(11) expects that review where needed.

06 · Common failures

Where DPIAs fall apart under review

The patterns a regulator or customer auditor spots first.

  • Written after launch. A DPIA dated after go-live documents a decision nobody made.
  • Copied from the last one. Generic text with the product name swapped shows no real thinking about this processing.
  • No change to the design. If the assessment found nothing to adjust, reviewers ask whether anyone looked.
  • No named owner. Measures without an owner and a date rarely get built.

For AI features, an ISO 42001 AI impact assessment covers wider effects on society and can run in the same workflow, but it does not replace the GDPR document.

Sources: Regulation (EU) 2016/679 (GDPR), Articles 9, 10, 35 and 36; Article 29 Working Party, Guidelines on Data Protection Impact Assessment (WP248 rev.01), endorsed by the EDPB.

Questions teams ask about DPIAs

Who should write the DPIA?

The team that owns the processing, with the DPO advising.

The controller is responsible, and in practice the product or process owner drafts it because they know the design. The DPO, security and legal review it. Outsourcing the whole document usually produces text nobody in the team can defend.

We are a processor. Do we write DPIAs?

The duty sits with the controller, but you will be asked to help.

Article 35 places the duty on the controller. Under Article 28 a processor must assist with it, so expect customers to ask for system descriptions, security measures and sub-processor details.

Can one DPIA cover several similar projects?

Yes, when the risks are genuinely alike.

A single assessment may cover a set of processing operations that present similar high risks, such as the same tool rolled out across several sites. Note where each deployment differs.

Do we have to publish our DPIA?

The GDPR does not require it.

Publication is not mandatory. Some organisations publish a summary to build trust. The full version must be ready for the authority on request.

Make DPIAs part of how you ship.

A GDPR gap assessment includes a DPIA template and screening step your product team can use.