A data protection impact assessment is the GDPR's tool for processing that is likely to result in a high risk to individuals. Article 35 makes it mandatory in those cases and leaves it optional in the rest. The difficulty is the threshold. "Likely to result in a high risk" is not a test you can apply by reading the words more carefully.
Teams tend to fail in one of two directions. Some run a full DPIA for every new feature, which buries the real risks under paperwork. Others run none, on the reasoning that nothing they do is high risk, and have nothing to show when a regulator or a customer asks how they decided.
This article sets out the test as the GDPR and the EDPB describe it, how to screen a new activity in a few minutes, and what to record either way.
The legal test in Article 35
Article 35(1) requires the controller to carry out a DPIA before processing where a type of processing, "in particular using new technologies", is likely to result in a high risk to the rights and freedoms of natural persons. You judge that likelihood by the nature, scope, context, and purposes of the processing.
Three points in that sentence matter in practice:
It is the controller's duty. A processor does not own the DPIA, though Article 28(3)(f) obliges it to assist the controller. A good processor arrives with the information already prepared.
It comes before the processing. A DPIA written after launch documents a decision already made. It does not meet the requirement.
It is about risk to people, not to your company. The question is the effect on individuals: discrimination, loss of confidentiality, financial loss, loss of control over their data. Reputational risk to you is a different exercise.
Where you have designated a data protection officer, Article 35(2) requires you to seek their advice when carrying out a DPIA.
The three cases Article 35 names
Article 35(3) lists three situations where a DPIA is always required:
Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the individual.
Large-scale processing of special category data under Article 9(1), or of personal data relating to criminal convictions and offenses under Article 10.
Systematic monitoring of a publicly accessible area on a large scale.
The list is not exhaustive. Article 35(3) introduces these cases as instances where a DPIA is "in particular" required, so they are examples of high risk, not the full set. Much of the SaaS processing that needs a DPIA fits none of the three neatly.
The nine screening criteria
The Article 29 Working Party's guidelines on DPIAs, endorsed by the EDPB, give nine criteria that indicate likely high risk:
Evaluation or scoring, including profiling and predicting.
Automated decision-making with legal or similarly significant effect.
Systematic monitoring of data subjects.
Sensitive data or data of a highly personal nature.
Data processed on a large scale.
Matching or combining datasets.
Data concerning vulnerable data subjects.
Innovative use or application of new technological or organizational solutions.
Processing that prevents data subjects from exercising a right or using a service or a contract.
The guidelines' rule of thumb is that processing meeting two or more criteria will in most cases need a DPIA. They also allow that one criterion can be enough in some cases. And if you meet two but conclude the risk is not high, they expect you to document why. The criteria structure the decision; they do not make it for you.
"Large scale" has no number in the GDPR. The guidelines point to the number of data subjects, the volume and range of data, the duration or permanence of the processing, and its geographic extent.
Employees can be vulnerable data subjects
Criterion 7 surprises SaaS teams. The guidelines list employees among potentially vulnerable data subjects, because of the power imbalance with their employer. Employee monitoring, such as productivity analytics or screen and keystroke capture, can meet criteria 3 and 7 at once. That is two, and a DPIA is then likely.
National lists
Article 35(4) requires each supervisory authority to publish a list of processing types that require a DPIA. Article 35(5) allows it to publish a list of types that do not. The lists differ by country, and they often add specifics the guidelines leave open, such as large-scale location tracking or certain uses of biometric data.
If you are established in the EU, check the list of your lead authority. If you process data about people in several member states, check the lists where the processing has the most effect. Treat a match as a requirement, not a hint.
A screening process that takes minutes
Most new activities need a short screen, not a DPIA. Build the screen into the moments where processing changes: feature design review, vendor onboarding, and the adoption of new internal tools.
Describe the activity in two sentences: what data, about whom, for what purpose.
Check the three Article 35(3) cases. A match means a DPIA.
Check your authority's list. A match means a DPIA.
Score the nine criteria. Two or more means a DPIA unless you can explain why not.
Record the outcome, with the reasoning and the name of the person who decided.
The output of step 5 matters as much as any DPIA. The guidelines recommend documenting the reasons when you decide a DPIA is not needed. When a customer's privacy team or a regulator asks why an activity was not assessed, a dated screening record answers the question. A blank does not.
Link each screening record to the activity in your Article 30 record of processing, so anyone looking at the activity can see that it was screened and what the answer was.
What the DPIA itself must contain
When the screen says yes, Article 35(7) sets the minimum content:
a systematic description of the processing operations and their purposes, including any legitimate interest pursued,
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, security measures, and mechanisms to ensure protection of personal data.
The necessity and proportionality section is the one teams skip. It asks whether you need this data for this purpose and whether a less intrusive design would do, which is a product question as much as a legal one. The lawful basis analysis for the activity feeds directly into it.
Article 35(9) adds that, where appropriate, you seek the views of data subjects or their representatives. For employee processing, that can mean consulting a works council or staff representatives where they exist.
When the risk stays high
Article 36 requires prior consultation with the supervisory authority where the DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate it. The guidelines read this as applying when you cannot find sufficient measures to bring the risk down. You consult before you start processing.
Article 36(2) gives the authority up to eight weeks to give written advice, extendable by six weeks for complex processing. A high residual risk is also a signal to revisit the design. Changing what you collect, or who can see it, is often cheaper than consultation and the delay it brings. Whatever you decide, the DPIA should record it.
Whether a specific activity crosses the threshold is a judgment that can depend on national lists and regulator guidance. Confirm borderline calls with counsel or your DPO.
How TrustLynce helps
TrustLynce's data privacy workflows include DPIA screening and assessment templates linked to each activity in your record of processing, with a dated record of who decided and why. Risk management carries high residual risks into your risk register with an owner and a treatment plan.