Article 35(1) and 35(3) DPIA requirement: evidence and tests

When does a DPIA become mandatory under GDPR Article 35?

A DPIA is mandatory when a processing operation is likely to result in a high risk to individuals, and Article 35(1) requires the assessment before processing starts. If your answer is "possibly," treat it as a yes until a documented screening shows otherwise. The GDPR does not issue a certificate for this decision, and the controller owns it, so the decision record is the evidence an assessor or supervisory authority will ask for. Article 35(1) also covers a single assessment for a set of similar operations with similar high risks, and it names new technologies as a case that calls for closer attention.

Article 35(3) sets three cases where a DPIA is always required: systematic and extensive automated evaluation of people with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area. For the wider cases, the Article 29 Working Party's WP248 rev.01 guidance lists nine criteria, including evaluation or scoring, systematic monitoring, sensitive data, large-scale processing, matching datasets, vulnerable data subjects and innovative technology. It states that processing meeting two criteria will in most cases require a DPIA. Check your supervisory authority's published list of operations that require a DPIA, because Article 35(4) obliges each authority to publish one. The WP248 guidance is the natural next read for scoring each criterion.

For each new or changed operation, record the date, the criteria tested, the result, the reasoning, the names of the people consulted, and the DPO's advice where a DPO is designated, since Article 35(2) requires that advice. Confirm with your legal or privacy lead which national list applies to your establishment. Revisit the screening when the purpose, data types, recipients or technology change, because a "no" decision can become a "yes" without any new system being purchased. Where the screening supports a DPIA, the content requirements in Article 35(7) apply, and a documented screening is what lets you show that a DPIA was not needed.

The three cases where a DPIA is always required

Article 35(3) names three processing patterns that need a DPIA without further analysis. Each one changes how a system should be designed, logged and reviewed, so engineering teams should identify them before architecture decisions are locked in.

Automated evaluation with significant effects

This covers systematic and extensive evaluation of people through automated processing, such as scoring, profiling or ranking, where the output produces legal effects or similarly significant effects, for example on credit, employment, insurance or access to services. For system design, identify every model, rule engine or scoring job that feeds a decision about a person. Check whether a human reviews the output in practice, what data the logic relies on, and whether the person can contest the result. Document each of these answers, because they shape the assessment.

Large-scale special category data

Processing special category data, such as health, biometric, genetic, political or trade union data, on a large scale triggers a DPIA. Systems that store or transmit these fields in clinical records, HR platforms, identity services or analytics pipelines should be inventoried by field, not only by database. Ask which fields are special category, how many data subjects are affected, and whether those fields are copied into logs, backups, exports or test environments. Scale is a judgment call, so record how you reached it.

Criminal offence data at scale

Large-scale processing of personal data about criminal convictions and offences also requires a DPIA under the same paragraph. This often appears in background screening, fraud case management, compliance watchlists and HR vetting tools that import third-party records. Map where these records enter the system, which teams can query them, and how long they persist. Access controls, segregation from general customer data and deletion workflows are the design points an assessor will ask about first.

Monitoring a publicly accessible area

Large-scale systematic monitoring of a publicly accessible area covers camera networks, Wi-Fi or Bluetooth tracking, and video analytics in shops, transport hubs, stadiums or streets. Engineering teams should record what is captured, where sensors are placed, whether faces or identifiers are extracted, and who can retrieve footage. Confirm retention periods and whether the monitored public can reasonably avoid the area. The assessment should follow the sensor placement and data flow, not only the vendor's product description.

How the WP248 nine-criteria screen decides the gray areas

The WP248 rev.01 screen is the practical tool for the cases Article 35(3) does not settle. It lists nine criteria: evaluation or scoring, automated decisions with legal or similarly significant effect, systematic monitoring, sensitive data, large-scale processing, matching or combining datasets, vulnerable data subjects, innovative use or application of new technologies, and processing that prevents data subjects from exercising a right or using a service. Guidance from the Article 29 Working Party says that processing meeting two or more of these criteria will in most cases require a DPIA. Treat that as a presumption to document, not a mechanical rule: a single criterion can still justify a DPIA where the risk is high, and two criteria can be rebutted with written reasons.

Engineering teams should run the screen at design review, before a feature is built, and record the answer for each criterion. Two criteria that most often appear together in product work are new technologies and matching datasets. A new analytics model that joins a customer's transaction history with third-party enrichment data, for example, would touch both. This is illustrative only, but it shows why the screen belongs in the same ticket as the architecture decision. Ask the product owner which datasets are combined, which vendor models are used and whether anyone can reverse a decision the system makes about an individual.

The screen decides where the question is asked, not the answer. The Article 35(1) test remains a judgment about whether processing is likely to result in high risk to individuals, and a clean score does not end that judgment. Check the national lists published by your supervisory authority, since they can add operations that must have a DPIA. Confirm with your data protection officer, where one is designated, whether the screen result is recorded and signed off. Also confirm the current status of the Digital Omnibus proposal, which would move EU-wide lists to the EDPB, because that proposal has not yet been adopted.

How national lists and EU-wide proposals change the answer

Article 35(4) requires each supervisory authority to publish a list of processing operations that need a DPIA. If your processing matches an entry on your lead authority's list, the question is settled and the assessment must be carried out before processing starts. The list is a floor, not a ceiling: a match does not waive the duty to document the assessment properly, and a processing operation can still need a DPIA where it is not listed.

Match the wording, not the headline: Lists describe operations in specific terms. Compare the processing description against each entry, including its scope conditions.
Check the version date: Authorities revise their lists. Record which version you relied on and when you checked it.
Confirm the lead authority: For cross-border processing, the lead authority's list is the one to check, and it may differ from the list of another country where you have customers.
Keep the match on file: Retain a short note linking each operation to the listed entry, so an assessor can see why a DPIA was run.
Do not stop at the list: Still apply the Article 35(1) high-risk test to any changes the list does not describe.

Before relying on any list, check the current publications of your lead authority and the EDPB.

How a supervisory authority or auditor tests the DPIA decision

This table sets out what an assessor checks when testing whether an organization decided correctly that a DPIA was or was not required, the evidence they ask for, and the findings that usually come up. Read it as a checklist against your system inventory: each row maps to a question an assessor will put to the screening records for every processing activity.

Test point	Evidence requested	Common finding
Documented screen per processing activity	Screening record for each activity in the processing inventory, showing the date, owner and outcome (DPIA required or not required)	Screens exist for large systems only; newer tools, SaaS features and spreadsheets have no recorded decision
Nine-criteria test applied	Completed checklist against the WP248 rev.01 criteria, with the count of criteria met and the reasoning for the outcome	Criteria ticked without reasoning, or two or more criteria met with no DPIA and no justification
Article 35(3) cases checked	Explicit check for automated evaluation with significant effects, large-scale special category or criminal data, and large-scale public monitoring	Screen skips these cases, so HR scoring or large health datasets are marked as low risk
National list cross-check	Record that the supervisory authority's published DPIA list was compared with the inventory for the organization's establishments	Lists never checked, or checked once and not updated when the authority published a new list
DPO consulted under Article 35(2)	Dated DPO advice on each DPIA, and on screening decisions where the DPO was involved, with the controller's response	DPO named in the policy but not consulted; advice recorded only after processing had started
Decision revisited on change	Change log linking new features, new data sources, new vendors or new purposes to a re-run of the screen	Screens completed at launch and never repeated, even after data use expanded
High-risk systems have a DPIA on file	Inventory flags for high-risk systems matched to completed DPIAs, with dates and version numbers	Inventory marks a system as high risk, yet no DPIA exists or the file predates the current design
Screen linked to the system inventory	Each screen references a unique system or processing ID that matches the asset and data flow records	Screens written against project names that do not appear in the inventory, so coverage cannot be proven

How to run the DPIA screen across a system inventory

This sequence turns a list of systems into a documented decision for each processing activity, showing whether a DPIA is required under Article 35 and why. It gives the DPO and later reviewers a register they can audit and keep current.

Build the processing activity inventory
Start by listing every processing activity that touches personal data, not every system. For each activity, record the purpose, the categories of personal data, the data subjects, the systems and hosting locations that hold the data, and any processors or sub-processors involved. Engineering, product and business owners usually supply this content, and the privacy or compliance lead checks it for completeness. The output is an inventory with one row per activity, and it is done when every system in the asset register maps to at least one activity or is recorded as out of scope.
Flag the Article 35(3) mandatory cases
Read each inventory row against the three cases where Article 35(3) always requires a DPIA: systematic and extensive automated evaluation with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area. Mark any activity that matches one of these cases as a DPIA requirement without further weighing. The output is a flag column in the register, and the step is complete when each row has an explicit yes or no against all three cases.
Apply the WP248 nine-criteria screen
For the remaining activities, test each one against the nine criteria in the Article 29 Working Party guidance, WP248 rev.01. The criteria include evaluation or scoring, automated decisions with significant effect, systematic monitoring, sensitive data, large-scale processing, matching or combining datasets, vulnerable data subjects and innovative use of technology. Record which criteria apply for each activity. The guidance indicates that meeting two criteria will in most cases require a DPIA, so treat that as a strong signal, not a substitute for judgment. The output is a criteria count and a short note per activity.
Check national lists of operations
Compare the activities against the lists of processing operations that the supervisory authorities in each relevant Member State must publish under Article 35(4), and any lists of operations that do not need a DPIA under Article 35(5). Confirm the current versions directly with the authority in each country where your processing takes place, because these lists are national and can change. The output is a note on each activity recording which list was checked and the result. Where no list applies, record that check as completed.
Record the decision and rationale
For each activity, write the decision in the screening register: DPIA required, DPIA not required, or DPIA required pending further information. Add the rationale, the Article 35(3) or national list reference if relevant, the WP248 criteria met, the date of the decision and the name of the person who approved it. Keep a short rationale even for negative decisions, because a regulator reviewing your accountability will look for the reasoning. The output is the completed screening register, and the step is complete when every inventory row has a recorded decision.
Consult the DPO where designated
Where a data protection officer has been designated, seek their advice on each screening decision that requires a DPIA and on the decisions to exclude an activity. Article 35(2) requires the controller to seek this advice when carrying out a DPIA. Record the DPO's advice, the date it was given, and how the controller responded, including any disagreement and the reasons for the final choice. The output is the DPO advice log linked to the register. If no DPO has been designated, record that fact and who is responsible for the screening decision instead.
Scope each required DPIA and schedule re-screening
For each activity marked as requiring a DPIA, create a DPIA scope document that names the activity, the systems involved, the data flows and the owner who will carry out the full assessment. Group similar operations with similar high risks into one assessment where Article 35(1) permits it. Then set a trigger for re-screening whenever the purpose, data categories, systems, processors, hosting location or automated decision logic changes, and assign an owner to review the register on that basis. The output is the scope documents and a change-trigger list, and the step is complete when every required DPIA has an owner and every change trigger is listed.

Which evidence shows the screening decision holds up

A screening decision under Article 35(1) and 35(3) is only as strong as the records behind it. The cards below cover the artifacts an assessor will ask for, and the routines that keep each one current between audits, so the screening result still matches how systems run today.

Processing inventory

The inventory lists every activity that uses personal data, with its purpose, data categories, data subjects, recipients and systems. It is the starting point for every screening, because a trigger cannot be checked for an activity nobody has recorded. Check that each new system, integration and vendor feature adds or updates an entry, and that owners confirm the entry each quarter. A missing inventory line is the most common reason a screening gap surfaces late.

Screening record per activity

For each processing activity, the record shows the answers to the Article 35(3) cases and the nine WP248 criteria, the number of criteria met, and the reasoning for the outcome. Two or more criteria usually point to a DPIA, so a record that says none apply needs a clear explanation. Date each record, name the approver, and reopen it when the activity's data or purpose changes.

DPIA where triggered

Where screening finds a likely high risk, the DPIA file is the evidence that the assessment was done before processing began. An assessor will check the date of the DPIA against the go-live date and whether the risk treatment was actually built. Confirm that the DPIA covers a set of similar operations if one assessment was used for several activities, and that it records residual risk so Article 36 can be considered.

DPO advice records

Article 35(2) requires the controller to seek the advice of the data protection officer where one is designated. Keep the dated request, the advice given, and the controller's decision, including any reasons for departing from that advice. Where no DPO is designated, record that fact and who performed the screening instead, so the file is not silent on the point.

Change triggers in engineering workflow

Screening goes stale when systems change without a privacy check. Add a question to design reviews, change tickets and pull request templates asking whether new personal data, new purposes, automated decisions, monitoring or new technology are involved. Route a yes answer back to the screening record. Ask engineering to show the trigger in its ticket history during an assessment, because a documented rule is weaker evidence than a record of it firing.

National authority lists consulted

Supervisory authorities publish lists of operations that require a DPIA and may publish lists of operations that do not, under Article 35(4) and (5). Keep a dated log of each list checked for the Member States where you operate, with the version or publication date and the result for each activity. Re-check the lists on a fixed schedule and when an authority announces an update, since the lists are the national layer on top of the EU rules.

What screening and DPIAs cost in staff time and tooling

This table compares the cost components of screening processing operations and carrying out DPIAs under Article 35, showing who is paid for each, whether the cost is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no price list applies and every figure depends on your own inventory. The main takeaway is that open-source tooling removes license spend but not the staff time needed to screen, assess and review.

Cost component	Who is paid or who spends time	One-time or recurring, and what drives it
Inventory and initial screen	Internal privacy or IT staff, sometimes an external consultant	One-time for the baseline, then recurring for new systems. Driven by the number of systems and how well the processing register is kept
Legal review of screening outcomes	Internal counsel or external data protection lawyers	Recurring per screened operation. Driven by ambiguity in lawful basis and the number of national lists that apply
DPO advice during the DPIA	Designated DPO, internal or outsourced	Recurring per assessment. Driven by how many high-risk operations are in scope and how often they change
Tooling and platform	Open-source software is free to license, but hosting, configuration and upkeep are paid to staff or a partner	Mostly one-time setup, then recurring maintenance. Driven by the number of workflows and integrations with your asset inventory
DPIA writing for high-risk operations	Process owners, system architects and privacy staff	Recurring per high-risk operation. Driven by system complexity, data sensitivity and the volume of data subjects affected
Stakeholder and data subject consultation	Business owners, works councils, researchers or user panels where used	Recurring per assessment. Driven by how many groups must be consulted and whether consultation is practical
Review after change	Engineering and privacy staff	Recurring. Driven by change frequency, new data uses and changes in risk, so ask how the quote covers repeat reviews
External review or assessor	Independent advisers or auditors you engage	Optional and recurring when used. Ask whether the quote includes a second review and who signs off the final document

How CISO Assistant can hold the screening register

A team that wants to keep its DPIA screening decisions in one place can use CISO Assistant, an open-source platform licensed under AGPL-3.0-only. The platform ships more than 200 frameworks, and GDPR is among them, so the same tool that holds the processing inventory can also record which frameworks an operation touches and run assessments against them. The register itself is a practical record: each processing activity, its purpose, the data categories involved, the data subjects, and the answer to the screening questions, including which of the three Article 35(3) cases apply and which of the nine WP248 criteria are met. Because the platform supports mapping between frameworks, a team can also link a screening outcome to the security controls and risk items that address it, which helps later when the outcome is revisited.

Before relying on this approach, confirm the exact modules, object types and workflow in the current project README on GitHub, since the names and features of an open-source project change between releases. Check whether the tool supports a dedicated processing-activity or privacy object, whether it can hold a free-text screening rationale and a sign-off by the DPO where one is designated, and how it records a decision to proceed without a DPIA. Also confirm how the platform handles the review date and version history, because a screening result that is never revisited is weak evidence. A short pilot with a handful of operations will show whether the fields and reports match what your assessors ask for.

The platform records and organizes the decision. It does not make the legal judgment whether processing is likely to result in high risk, and it does not replace the controller's responsibility for that conclusion. Plan for the cost of configuring the register, importing existing processing records, training the people who complete screening, and maintaining the data over time. Those costs are the organization's own staff time or a partner's fixed-scope work, and they recur whenever processing changes. If you bring in an implementation partner, ask for the configuration, data import and documentation to be specified in writing before work starts.

Who owns the screening decision and who can help

The controller owns the decision on whether a processing operation needs a DPIA. Under Article 35(1), the duty falls on the controller before processing starts, and Article 35(2) requires the controller to seek the advice of the data protection officer where one is designated. The controller's team therefore decides which operations are screened, who signs off the outcome, and what happens when the answer is yes. A consultant can draft the analysis, but the record of that decision belongs to the organization, and the organization answers to its supervisory authority if the screening was wrong or skipped.

Accountable sign-off: A named executive or privacy lead approves each screening result, including results that conclude no DPIA is needed.
Business owner input: Product and system owners describe the purpose, data categories and affected people, since screening depends on facts only they hold.
DPO involvement: Where a DPO is designated, record the advice given and any reasons the controller departed from it.
Retained register: Keep the screening outcome, date and rationale in the organization's own system, reviewed when processing changes.
Internal triggers: Agree who must re-screen when a new vendor, data source or automated decision is introduced.

Before engaging anyone, confirm that your team can name the owner of every screening decision and where those records are kept.

Where screening programs usually fall short

Most DPIA screening failures are not failures of legal reading. They come from missing inventories, one-off decisions that nobody revisits, and data that sits outside the systems everyone reviewed. Each card below names one gap, why it weakens the Article 35(1) and 35(3) screening decision, and the check that closes it.

No inventory of processing

Screening can only find high-risk processing that someone has written down. Teams often screen the systems they know about and miss shadow SaaS tools, batch jobs, vendor-hosted analytics and new features added to existing platforms. Build a register of processing activities that lists purpose, data categories, data subjects, systems and recipients, then run the screening against that register. Ask who signs off additions to it.

Screening done once, never revisited

A screen completed at launch says nothing about a system that later adds profiling, a new data source or a larger user base. The trigger is a change in risk, not a calendar date, so screening needs defined events that reopen it, such as a new purpose, new data category, new automated decision or a material change in scale. Record the date and version of each screen so an assessor can see what was reviewed and when.

Sensitive data hidden in logs

Screening often classifies a system by its primary database and overlooks what the application writes elsewhere. Application logs, error traces, analytics events, search indexes and support tool attachments can hold health data, criminal offence data or identifiers used for monitoring. Sample these stores during screening, look for special category and criminal offence data, and treat any large-scale copy as part of the processing under review.

Undocumented reasons for skipping a DPIA

When a team decides a DPIA is not needed, the reasoning often exists only in a chat thread or someone's memory. An assessor will ask why a processing operation with two or more WP248 criteria was not assessed. Write a short screening record for every decision that states the criteria tested, the data reviewed, the conclusion, the approver and the conditions that would reopen the question.

Missing DPO consultation

Where a data protection officer has been designated, Article 35(2) requires the controller to seek the DPO's advice when carrying out a DPIA. Screening decisions taken by engineering or product teams alone skip that step, even when the outcome is a conclusion that no DPIA is needed. Route every screening outcome, including negative ones, to the DPO and keep the advice and the controller's response with the screening record.

Questions buyers ask about DPIA triggers and effort

How much effort does a DPIA screening take?

A screening is usually the lightest step and its effort depends on how many processing operations you have and how well they are documented. Each operation needs a short description of what data it uses, who it affects, and whether it matches any of the nine criteria in WP248 rev.01. Two or more matches will in most cases mean a full DPIA is needed. Effort rises when systems have no current data inventory, when several teams own overlapping processing, or when the lawful basis and data flows are unclear. Ask any partner to quote screening separately from the full assessment so you can see what is one-time and what must be repeated when systems change.

Do we need an outside consultant to run a DPIA?

No. The GDPR places the duty on the controller, and nothing in the regulation requires an external firm. An outside partner is useful when your team lacks engineers who can describe data flows accurately, when the assessment spans many systems, or when the DPO needs independent support. The controller still owns the decisions, the risk acceptance and the final document. A partner can prepare system descriptions, technical evidence and draft mitigations, but it does not issue any approval or certificate. Confirm in writing who signs off each conclusion before work begins.

How long does a first DPIA pass take for a large system estate?

The duration depends mainly on system count, data sensitivity and how many owners must be interviewed. A first pass usually moves faster when you group similar operations, since Article 35(1) allows one assessment to cover a set of similar operations with similar high risks. Expect longer timelines when systems share data, when processing involves profiling or monitoring, or when engineers must trace flows across cloud accounts and third parties. No general duration is supplied here, so ask for a timeline based on a named inventory of systems, a list of owners and an agreed scope before you compare offers.

Does every system in our environment need a DPIA?

No. A DPIA is required only where processing is likely to result in a high risk to individuals. Many systems, such as internal tools that process no personal data, will not trigger the test at all. The three cases in Article 35(3) always require one, including large-scale processing of special category data and systematic monitoring of a publicly accessible area. Member state lists under Article 35(4) may add further operations. Start with a complete record of processing, screen each operation against the triggers, and document the reasons for each decision, including the ones where no DPIA is needed.

What do engineers and the DPO need to contribute?

Engineers provide the facts a DPIA cannot be written without: data categories, storage locations, retention behavior, access paths, logging, encryption, third-party components and the points where data leaves the system. The DPO, where designated, must be consulted when the DPIA is carried out under Article 35(2), so they should review the scope, the risk reasoning and the mitigations. Plan for short working sessions with each system owner rather than long documentation requests. Agree in advance who records decisions and who keeps the assessment current as the system changes.

Can we run the DPIA program ourselves and still pass an audit?

A DPIA is not a certification and no regulator issues a pass for it, so the question is whether your documented assessment is complete, reasoned and kept current. Internal teams can meet that standard if they have the time, the technical depth and an independent reviewer such as the DPO. The weak points usually are missing triggers screening, descriptions that do not match the running system and reviews that were never repeated after a change. Before relying on a self-run program, test it against a sample of systems and check that each conclusion can be traced to evidence. Supervisory authorities can ask for the assessment at any time, so keep it in a form you can produce quickly.

What does an open-source platform change about DPIA evidence?

Self-hosted open-source platforms can hold the inventory, control mappings and evidence that a DPIA relies on, which helps when the assessment must be repeated. CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including GDPR, and can run assessments against them. Treat it as a record-keeping tool, not as a substitute for the assessment itself. Confirm in its documentation which GDPR items it covers and how its mappings are maintained before you rely on them in an audit file. Your own engineers still need to confirm that the recorded facts match the production environment.

How DeployOpen prepares DPIA screening evidence

DeployOpen agrees the scope of any DPIA screening work in writing before it starts, so the controller knows which processing operations are covered, which systems hold the data, and which people sign off each step. The engagement starts with a processing inventory: the systems, data stores, vendors and business owners behind each operation the organization is considering, recorded against the Article 35(1) high-risk test and the three Article 35(3) cases. DeployOpen builds this inventory and the screening records inside the client's own cloud accounts, data centers or air-gapped networks, so the personal data used to decide screening outcomes never leaves the client's environment.

For each operation, the screening record sets out the facts an assessor will ask about: the data categories involved, the scale, whether automated evaluation or systematic monitoring is in use, whether any matching of datasets or vulnerable data subjects is present, and whether the technology is new. Where the team tests against the nine criteria in WP248 rev.01, the record shows which criteria apply and why, so a reader can see how the conclusion was reached. DeployOpen can also configure the tooling used to hold this material, such as a self-hosted instance of CISO Assistant, and load the screening outcomes as assessment evidence. Confirm with the vendor which GDPR assessment features your chosen version provides before you rely on them.

DeployOpen does not decide whether a DPIA is required, approve a DPIA, issue an audit report or issue a certificate. Those decisions belong to the controller, and the DPO must be consulted where one is designated under Article 35(2). Independent auditors and certification bodies issue their own reports and certifications. At handover, the client receives the scope document, the inventory, the screening records, the tooling configuration and the evidence index, so the controller and DPO can review, challenge and adopt the conclusions in their own name. Ask any implementation partner to confirm in writing which of these deliverables they produce and which decisions stay with your organization.

Article 35(1) and 35(3) When a DPIA is required