Skip to content
SimpleAct Logo

Guide · GDPR Art. 35

As of 4 October 2026

Data Protection Impact Assessment (DPIA): When It Is Required – with AI and the German Must-List

Not every processing operation needs a DPIA – but AI systems often do. This guide gives you the complete must-list of the German Data Protection Conference, the nine criteria of the European guidelines, the minimum content under Art. 35(7) and a threshold check that documents your decision on the spot.

Start the threshold checkSee the must-list
  • All 17 entries of the DSK must-list
  • 9 criteria from WP 248
  • DPIA and the AI Act (Art. 26, 27)
  • Check with documentation text
app.simpleact.de

Data protection impact assessment

AI assistant in customer service · Draft

A

Process

3/6
  1. Threshold analysis
  2. Description
  3. Necessity
  4. Risks
  5. Measures
  6. Approval

Risks

  • Sensitive details in free-text enquiriesHigh
  • Incorrect answers about contract dataMedium
  • Transfer to a model API in a third countryMedium
  • Histories stored for too longLow

Sample data · DSK must-list no. 11 applies

In short

Under Art. 35 GDPR, a data protection impact assessment (DPIA) must be carried out before any processing that is likely to result in a high risk to individuals – for example profiling with legal effects, large-scale processing of sensitive data or operations on the supervisory authorities' must-lists. AI in customer support is expressly on the German list.

Basics

What a data protection impact assessment is – and when you need one

The data protection impact assessment – DPIA, in German "Datenschutz-Folgenabschätzung" or DSFA – is governed by Art. 35 GDPR. 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, taking into account its nature, scope, context and purposes, the controller carries out an assessment of the impact beforehand (para. 1). A single assessment may cover a set of similar processing operations that present similar high risks.

Art. 35(3) names three cases in which a DPIA is required in particular: a 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 under Art. 9(1) or of criminal data under Art. 10; and systematic monitoring of a publicly accessible area on a large scale.

Because these three cases are abstract, supervisory authorities publish lists of processing operations that require a DPIA (Art. 35(4)). For the private sector in Germany, the list of the Data Protection Conference (DSK), version 1.1 of 17 October 2018, applies. It contains 17 groups of cases – from biometric access control and employee monitoring to the use of artificial intelligence. The list is expressly not exhaustive: processing that is not on it can still be high-risk. Other EU countries have their own lists.

For everything else, the DSK relies on the Article 29 Working Party's DPIA guidelines (WP 248 rev.01). They name nine criteria, such as scoring, systematic monitoring, sensitive data, vulnerable data subjects or innovative use of new technologies. If processing meets two of these criteria, the guidelines say a DPIA is required in most cases; in some cases one is enough.

Whether you need a DPIA is decided with a threshold analysis. The DSK stresses in its short paper no. 5 that the decision for or against a DPIA must always be documented in writing, with the relevant reasons. A "we don't need one" without reasons is hard to defend in an audit. The check further down gives you a text block for exactly that.

A DPIA must contain at least four things (Art. 35(7)): a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects and the measures envisaged to address them. The data protection officer must be consulted for advice (para. 2). If the DPIA shows that a high risk remains despite the measures, the supervisory authority must be consulted before processing starts (Art. 36).

The AI Act gives the DPIA extra weight. Deployers of high-risk AI systems use the information the provider supplies under Art. 13 AI Act for their DPIA (Art. 26(9) AI Act). Certain deployers must also carry out a fundamental rights impact assessment under Art. 27 AI Act and may refer to the DPIA. Following the Digital Omnibus, these deployer obligations apply to Annex III high-risk AI from 2 December 2027 – the GDPR DPIA obligation, by contrast, applies today.

groups of cases on the DSK must-list (version 1.1, private sector)
17
groups of cases on the DSK must-list (version 1.1, private sector)
WP 248 criteria: a DPIA is then required in most cases
2 of 9
WP 248 criteria: a DPIA is then required in most cases
weeks: authority deadline for prior consultation (Art. 36(2))
8 + 6
weeks: authority deadline for prior consultation (Art. 36(2))

DSK must-list

The German Data Protection Conference must-list: all 17 groups

For these operations a DPIA must be carried out in the German private sector (list under Art. 35(4) GDPR, version 1.1 of 17 Oct 2018). The descriptions summarise the original in our own words; the wording of the DSK list linked in the sources is authoritative.

1
Processing (summary)Biometric data for unique identification, where at least one of the further WP 248 criteria named in the list applies (e.g. monitoring, scoring, vulnerable data subjects)
Typical fields of useBiometric access control or billing
Example from the listFingerprint sensors for access control; paying by fingerprint in a school canteen
2
Processing (summary)Genetic data (Art. 4(13)), where at least one of the further WP 248 criteria named in the list applies (e.g. monitoring, scoring, vulnerable data subjects)
Typical fields of useEarly detection of hereditary diseases, ancestry databases
Example from the listDNA tests for newborns; a service matching genetic data
3
Processing (summary)Large-scale processing of data subject to social, professional or special official secrecy – even without Art. 9/10 data
Typical fields of useInsolvency registers, large social institutions, large law firms
Example from the listRegister of personal insolvencies; large family law firm
4
Processing (summary)Large-scale processing of data on the location of people
Typical fields of useCar sharing and mobility services, vehicle data, offline tracking in shops, traffic flow analysis from mobile network data
Example from the listCar sharing provider processing extensive location and billing data
5
Processing (summary)Combining data from different sources on a large scale, not all collected directly, using algorithms data subjects cannot follow, as a basis for decisions with legal effect
Typical fields of useFraud prevention, scoring by credit agencies, banks or insurers
Example from the listOnline shop screening orders against extensive data for fraud
6
Processing (summary)Mobile optical-electronic capture in public areas, centrally combined on a large scale
Typical fields of useVehicle environment sensors
Example from the listUsing vehicle sensor data to find parking spaces or improve automated driving
7
Processing (summary)Large-scale collection and publication or transfer of rating data that third parties can use for decisions
Typical fields of useRating portals, debt collection
Example from the listPortal publicly rating self-employed people; debt collection with extensive debtor data
8
Processing (summary)Large-scale processing of data on employee behaviour that can be used for assessments with legal consequences
Typical fields of useData loss prevention creating staff profiles, employee geolocation
Example from the listCentral recording of web and email traffic; movement profiles via RFID, phone location or GPS
9
Processing (summary)Comprehensive profiles of interests, network of relationships or personality
Typical fields of useDating and contact portals, large social networks
Example from the listWeb portal profiling users for contact suggestions
10
Processing (summary)Combining data from different sources on a large scale, with algorithms data subjects cannot follow, to discover unknown correlations for purposes not set in advance
Typical fields of useBig data analysis of customer data enriched with third-party sources
Example from the listPurchasing behaviour and web use linked with credit data and analysed
11
Processing (summary)Use of artificial intelligence to process personal data to steer interaction with data subjects or to assess personal aspects
Typical fields of useCustomer support using artificial intelligence
Example from the listCall centre automatically analysing callers' mood; system advising customers in dialogue and processing their personal data with AI
12
Processing (summary)Using sensors or radio signals of mobile devices, other than as intended, to locate people over a substantial period
Typical fields of useOffline tracking in shops, traffic flow analysis
Example from the listAnalysing Wi-Fi, Bluetooth or mobile signals to track walking routes
13
Processing (summary)Automated analysis of video or audio recordings to assess personality
Typical fields of useAlgorithmic analysis of phone calls
Example from the listCall centre automatically analysing callers' mood
14
Processing (summary)Comprehensive profiles of movement and purchasing behaviour
Typical fields of useLoyalty programmes with discounts
Example from the listCustomer card with loyalty points used to build comprehensive customer profiles
15
Processing (summary)Anonymising Art. 9 data, not only in individual cases, for transfer to third parties
Typical fields of useAnonymisation of special categories
Example from the listPharmacy data centre or insurer anonymising extensive health data for disclosure
16
Processing (summary)Art. 9/10 data – even if not large-scale – collected repeatedly via innovative sensors or mobile apps and processed centrally
Typical fields of useTelemedicine
Example from the listMedical practice continuously collecting health values via app and sensors
17
Processing (summary)Art. 9/10 data – even if not large-scale – used by providers of new technologies to determine people's performance
Typical fields of useCentral storage of sensor data from fitness trackers or smartphones
Example from the listService analysing fitness tracker data to improve training

The DSK points out that the list is not exhaustive and supplements the general rules in Art. 35(1) and (3). Public bodies are covered by separate lists of the respective authorities; other EU countries have their own lists.

WP 248

The nine criteria for a likely high risk

If an operation is not on the must-list, check these criteria from the WP 248 rev.01 guidelines, on which the DSK list is also based. The AI examples in the right-hand column are our own classification.

a) Evaluation or scoring
What it meansEvaluating personal aspects such as work performance, economic situation, health, preferences, behaviour or location, including profiling and predicting.
Typical AI exampleRanking applications, credit prediction, churn score
b) Automated decision with legal effect
What it meansDecisions with legal or similarly significant effects without meaningful human involvement (cf. Art. 22).
Typical AI exampleAutomatic rejection of an application or contract
c) Systematic monitoring
What it meansObserving, monitoring or controlling people, including in publicly accessible areas or via networks.
Typical AI exampleAnalysis of workplace activity, video analytics
d) Sensitive or highly personal data
What it meansSpecial categories under Art. 9, criminal data under Art. 10 and other highly personal data such as financial or location data.
Typical AI exampleFree-text inputs with health details in a support chat
e) Large-scale processing
What it meansMeasured by number of data subjects, volume of data, duration and geographical extent.
Typical AI exampleChatbot for all customers of a utility
f) Matching or combining datasets
What it meansLinking data from different operations or sources beyond what data subjects would expect.
Typical AI exampleAI enriching CRM data with web and third-party sources
g) Data concerning vulnerable data subjects
What it meansPeople in a power imbalance, such as employees, children or patients.
Typical AI exampleAI analysis of employee data
h) Innovative use of new technologies
What it meansNew technological or organisational solutions whose consequences are not yet well understood.
Typical AI exampleUse of generative AI and large language models
i) Preventing exercise of a right or use of a service
What it meansThe processing helps decide whether people can exercise a right, use a service or enter a contract.
Typical AI exampleAI-supported lending or pricing decision

WP 248 rule of thumb: the more criteria are met, the more likely a high risk. Two criteria lead to a DPIA in most cases; sometimes one is enough.

Interactive

DPIA threshold check: do you need a DPIA?

Work through three levels: the cases in Art. 35(3), the DSK must-list and the nine WP 248 criteria. On the right you see the result and a text to document your threshold analysis. Nothing is stored or transmitted.

1 · Cases in Art. 35(3) GDPR
2 · DSK must-list (German private sector)
3 · WP 248 criteria
app.simpleact.de

Result of the threshold analysis

e.g. AI assistant in customer service

A

DPIA probably not required

None of the levels checked applies. Document the decision with reasons and check again when the processing changes.

Documentation (text block)

Threshold analysis under Art. 35 GDPR – [processing activity]
Date: [DD/MM/YYYY] · Prepared by: [name] · DPO advice sought: [yes/no]

Art. 35(3) GDPR: no case applies
DSK must-list (v1.1): no group applies
WP 248 rev.01 criteria: none
AI system involved: no

Result: DPIA not required.
Reasons: [why a high risk is unlikely – nature, scope, context, purposes]
Review when the processing changes, at the latest: [date]

A working aid for orientation, not legal advice. The threshold analysis does not replace a case-by-case assessment; the DSK list is not exhaustive and applies to the German private sector.

Minimum content

What goes into a DPIA: Art. 35(7) and the duties around it

The GDPR does not prescribe a method, but it does set minimum content and procedural steps. The right-hand column shows what to look at for AI systems – that is our recommendation.

Systematic description
What belongs in itProcessing operations, purposes, legitimate interests where relevant; data, systems, data flows, parties involved.
For AI systemsModel, vendor, inputs, outputs, logs, use for training, third country
ReferenceArt. 35(7)(a)
Necessity and proportionality
What belongs in itIs the processing necessary for the purpose? Would less data or milder means work?
For AI systemsDoes the system need personal data, or would pseudonymised inputs do?
ReferenceArt. 35(7)(b)
Risk assessment
What belongs in itRisks to the rights and freedoms of data subjects by likelihood and severity.
For AI systemsIncorrect outputs, discrimination, unintended disclosure, loss of control
ReferenceArt. 35(7)(c)
Measures
What belongs in itSafeguards, security measures and mechanisms to address the risks and demonstrate compliance.
For AI systemsHuman review, filters, training excluded, short retention, EU region
ReferenceArt. 35(7)(d)
Advice of the DPO
What belongs in itThe controller seeks the advice of the data protection officer, where designated.
For AI systemsInvolve early, not just for sign-off
ReferenceArt. 35(2)
Views of data subjects
What belongs in itWhere appropriate, seek the views of data subjects or their representatives.
For AI systemsFor employee data e.g. the works council (the DSK names co-determination bodies)
ReferenceArt. 35(9)
Codes of conduct
What belongs in itCompliance with approved codes of conduct is taken into account.
For AI systems–
ReferenceArt. 35(8)
Review
What belongs in itWhere necessary, review whether processing follows the DPIA – at least when the risk changes.
For AI systemsNew model, new features, new vendor = reason to review
ReferenceArt. 35(11)
Prior consultation
What belongs in itIf a high risk remains despite measures, consult the supervisory authority before starting.
For AI systemsAssess and document the residual risk honestly
ReferenceArt. 36

In short paper no. 5 the DSK describes four phases: preparation, execution, implementation, review. Methods and standards are permitted, but GDPR requirements take precedence.

DPIA and AI

When AI systems trigger a DPIA – and what the AI Act changes

AI systems often meet several criteria at once. These points summarise what applies and what to watch for.

01

Must-list no. 11

The DSK expressly names the use of AI to steer interaction with data subjects or to assess personal aspects – with customer support as the example. A chatbot answering customer enquiries with personal data typically falls under it.

02

New technologies

Art. 35(1) highlights the use of new technologies; WP 248 lists it as a criterion of its own. Combined with large scale or sensitive data in free text, two criteria are quickly met.

03

Profiling and decisions

If a system evaluates applications, creditworthiness or performance and this is the basis for decisions with legal effect, Art. 35(3)(a) applies – regardless of the must-list.

04

Use provider information

Deployers of high-risk AI use the provider information under Art. 13 AI Act for their DPIA (Art. 26(9) AI Act). For other AI systems too: request details on how it works, data flows and security in the DPA.

05

Fundamental rights impact assessment

Public bodies, private providers of public services and deployers under Annex III point 5(b) and (c) (creditworthiness, life and health insurance) also need a FRIA under Art. 27 AI Act. Under para. 4 they may refer to a DPIA already carried out.

06

Mind the timeline

Following the Digital Omnibus, deployer obligations for Annex III high-risk AI apply from 2 December 2027. The DPIA obligation under Art. 35 GDPR applies now – including to AI systems that are not high-risk under the AI Act.

Whether an AI system is high-risk under the AI Act depends on Art. 6 and Annex III. That is a different question from high risk under Art. 35 GDPR – document both assessments separately.

Delimitation

DPIA (GDPR) and fundamental rights impact assessment (AI Act) compared

Both instruments assess risks to people, but they have different triggers, obligated parties and content. They do not replace each other but fit together well.

Who is obliged?
DPIA – Art. 35 GDPREvery controller
FRIA – Art. 27 AI ActCertain deployers of high-risk AI (public bodies, private providers of public services, Annex III point 5(b) and (c))
Trigger
DPIA – Art. 35 GDPRLikely high risk of processing personal data
FRIA – Art. 27 AI ActUse of a high-risk AI system under Art. 6(2) (except Annex III point 2)
Protected interest
DPIA – Art. 35 GDPRRights and freedoms of natural persons in data processing
FRIA – Art. 27 AI ActFundamental rights of the people affected as a whole
Timing
DPIA – Art. 35 GDPRBefore processing starts
FRIA – Art. 27 AI ActBefore the system is put into service
Applies from
DPIA – Art. 35 GDPR25 May 2018
FRIA – Art. 27 AI ActFor Annex III systems from 2 December 2027 (Digital Omnibus)
Authority
DPIA – Art. 35 GDPRPrior consultation only if a high residual risk remains (Art. 36)
FRIA – Art. 27 AI ActResults notified to the market surveillance authority (Art. 27(3))
Link
DPIA – Art. 35 GDPRCan serve as a basis for the FRIA
FRIA – Art. 27 AI ActMay refer to a DPIA already carried out (Art. 27(4))

Practical tip: one shared system description for DPIA, FRIA and AI inventory avoids duplicate work. The assessments stay separate.

Approach

Carrying out a DPIA in 8 steps

Based on the four phases of DSK short paper no. 5 – preparation, execution, implementation, review. The split into eight steps is our recommendation.

  1. 1

    Document the threshold analysis

    Check Art. 35(3), the must-list and the WP 248 criteria – and record the decision with reasons, even if no DPIA is needed.

  2. 2

    Set up team and plan

    A DPIA needs data protection, the business unit and IT. The data protection officer advises throughout; vendors and processors can be involved.

  3. 3

    Describe the processing

    Purposes, data, systems, data flows and parties – systematically and completely. The RoPA entry is a good starting point.

  4. 4

    Check necessity

    Legal basis, purpose limitation, data minimisation, retention: is every step necessary and proportionate?

  5. 5

    Assess the risks

    Individual risks with likelihood and severity from the data subjects' perspective – not the company's.

  6. 6

    Define measures

    Technical and organisational measures per risk, with owners and dates. Then assess the residual risk.

  7. 7

    Approve or consult

    If the residual risk is acceptable, management signs off. If a high risk remains, consult the supervisory authority before starting (Art. 36).

  8. 8

    Review

    Review again when the risk changes (Art. 35(11)). We also recommend a fixed review cycle, for example yearly.

Art. 36 GDPR

Prior consultation: when a high risk remains

If 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 controller consults the supervisory authority before processing (Art. 36(1)). In practice: if a high residual risk remains after your measures, you do not simply go live – you put the DPIA before the authority.

If the authority considers that the processing would infringe the GDPR – in particular because the risk has not been sufficiently identified or mitigated – it provides written advice within up to eight weeks and may use its powers under Art. 58. The period may be extended by six weeks; the authority informs you of the extension within one month. The periods may be suspended until the authority has obtained the information it requested (Art. 36(2)).

So a DPIA does not generally have to be sent to the authority. It remains an internal document you produce on request. Prior consultation is the exception – but it shows why an honest assessment of the residual risk matters so much.

  • Only if a high residual risk remains despite measures
  • Before processing starts
  • Authority responds within up to 8 weeks, extendable by 6
  • With the DPIA, responsibilities, measures and DPO contact details (Art. 36(3))

Common mistakes

Six mistakes in data protection impact assessments

No reasons for "not required"

The DSK requires the decision against a DPIA to be documented with reasons too. Without that note, the evidence is missing in an audit.

DPIA after go-live

The DPIA must be carried out before processing starts. Doing it afterwards misses the chance to avoid risks in the design.

Risks from the company's view

What is assessed is the risk to data subjects, not the company's fine or reputational risk.

Measures without effect rating

A list of measures alone is not enough. Assess how much each measure reduces the risk and document the residual risk.

Created once, never reviewed

New models, new features or new vendors change the risk. Art. 35(11) then requires a review.

DPO only as a signature

The advice of the data protection officer must be sought (Art. 35(2)). It belongs in the process, not just at the end.

With SimpleAct

DPIAs in SimpleAct

The GDPR module (from Professional) keeps the DPIA as a record of its own – linked to the RoPA entry and the AI system, with risks, measures, residual risk and a real approval.

  • Necessity check with reasons, including for "not required"
  • Basic details from the linked RoPA entry
  • Individual risks with likelihood and severity
  • Measures with effectiveness and links to controls
  • Residual risk low, medium, high or unknown
  • Approval status with approver and time
  • List of AI systems without a linked DPIA
  • Part of the full GDPR export

DPIA and FRIA separate but connected

In SimpleAct the fundamental rights impact assessment under Art. 27 AI Act sits in the assurance file of each AI system – next to the DPIA, not in its place.

See the GDPR module

FAQ

Frequently asked questions about the DPIA

When processing is likely to result in a high risk to the rights and freedoms of natural persons (Art. 35(1) GDPR). That is the case in particular for the three cases in para. 3 and for the groups on the supervisory authorities' must-lists. Otherwise the nine WP 248 criteria help: where two are met, a DPIA is needed in most cases.
The Data Protection Conference list for the private sector (version 1.1 of 17 Oct 2018) contains 17 groups, including biometric access control, employee monitoring, scoring, rating portals, loyalty cards with profiling and the use of artificial intelligence to interact with data subjects or assess personal aspects. The list is not exhaustive.
Often, yes. No. 11 of the DSK must-list expressly names the use of AI to steer interaction with data subjects, with customer support as the example. If the chatbot processes customers' personal data, assume a DPIA is required and document the outcome of your assessment.
The controller – the organisation, not the data protection officer. The DPO advises and must be consulted under Art. 35(2). In practice a team from the business unit, IT and data protection works together; processors assist under Art. 28(3)(f).
No, not as a rule. Only if a high risk remains despite measures must the supervisory authority be consulted before processing starts (Art. 36). Otherwise the DPIA is an internal document produced on request.
Under Art. 35(7): a systematic description of the processing and purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects and the measures envisaged, including safeguards and security measures.
The GDPR sets no fixed interval. Art. 35(11) requires a review at least when the risk has changed. The DSK sees the DPIA as an ongoing process. We also recommend a regular review, for example yearly, and always with new models, features or vendors.
The DPIA under Art. 35 GDPR concerns the risk of processing personal data and applies to every controller. The fundamental rights impact assessment (FRIA) under Art. 27 AI Act applies only to certain deployers of high-risk AI and looks at fundamental rights as a whole. The FRIA may refer to a DPIA already carried out.
The DSK points out that existing operations can also fall under the DPIA obligation. At the latest when processing changes significantly – for example by adding AI – you should repeat the threshold analysis.
A breach of Art. 35 or 36 can be fined under Art. 83(4)(a) GDPR with up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher.
Yes. A single assessment may address a set of similar processing operations that present similar high risks (Art. 35(1), second sentence) – for example where similar technologies are used for comparable data and the same purposes.

More questions? We're happy to help. Send email · Try 7 days (credit card required)

Sources and status

As of · SimpleAct editorial team

This guide is general information and not legal advice. The must-list is summarised in our own words; the original DSK document is authoritative.

Changes

  • 2026-10-04 – Page rebuilt: complete DSK must-list, WP 248 criteria, minimum content, DPIA/FRIA comparison, Art. 36, threshold check with documentation text.
  • 2026-06-13 – First version.

Related topics

DPIA, AI inventory and FRIA in one place

SimpleAct links DPIAs, the record of processing and AI systems. Try 7 days (credit card required) or let us show you the GDPR module.

Book a demoTry 7 days (credit card required)