The question “do we need a DPIA for this” arrives every time a team stands up a new system that touches personal data, and the honest answer depends on a specific legal test, not a gut feeling about how sensitive the project seems. Article 35 of the GDPR sets that test, and getting it wrong has a cost either way: skip a required DPIA and a supervisory authority can fine you for the omission alone, run one for every minor change and the compliance team drowns in paperwork nobody reads. This article covers the trigger conditions, the four sections a DPIA must legally contain, where security testing evidence fits, when prior consultation becomes mandatory, how often to redo the assessment, and how a DPIA differs from a legitimate interest assessment and a transfer impact assessment.
Article 35 triggers and national authority lists
Article 35(1) sets the general rule: a DPIA is required whenever 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. Article 35(3) names three processing types that always meet that bar: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that produces legal or similarly significant effects; large scale processing of special category data under Article 9 or of criminal conviction data under Article 10; and systematic monitoring of a publicly accessible area on a large scale.
The former Article 29 Working Party guidelines, WP248, endorsed by the EDPB, turned this into a practical nine-criteria test: evaluation or scoring, automated decision-making with legal or similarly significant effect, systematic monitoring, sensitive or highly personal data, large scale processing, matching or combining datasets, vulnerable data subjects, innovative use of new technology, and processing that blocks a data subject from exercising a right or using a service. Meeting two or more criteria is the standard working threshold for likely high risk, though one alone can be enough for a genuinely novel or large scale case.
Article 35(4) requires every supervisory authority to publish a list of processing operations subject to mandatory DPIA, and Article 35(5) lets them publish an optional whitelist of operations that do not need one. These lists are binding locally and often go further than the generic test: the French CNIL list names wearable health data combined with insurance pricing, and large scale behavioural advertising profiling; UK ICO guidance flags large scale profiling, biometric data, and any combination of two or more WP248 criteria as presumptively high risk. For a multinational deployment, run the generic Article 35(3) and WP248 test first, then check every national list for every country in scope, since a single yes from any authority list makes the DPIA mandatory regardless of the generic score.
DPIA structure: the four elements Article 35(7) actually requires
Article 35(7) sets a hard floor of four elements. Anything short of these four is not a legally sufficient DPIA, no matter how long the document is.
Systematic description of the processing and its purposes
This is a data flow map, not a narrative. List the categories of personal data collected, the source of each category, every internal and third-party recipient, the retention period per category, any cross-border transfer, and each processing operation from collection through deletion. Teams that already maintain an Article 30 record of processing activities can reuse most of this section directly; keeping the DPIA and the ROPA entry cross-referenced by a shared processing ID keeps the two documents from drifting apart after the first update.
Assessment of necessity and proportionality
This section justifies the legal basis under Article 6 (and the Article 9 condition if special category data is involved), confirms that each data field collected is actually needed for the stated purpose, and ties the retention period to that purpose rather than to an arbitrary round number. A common gap is a field kept “in case it’s useful later”: if there is no current purpose for a data point, Article 5(1)(c) data minimization means it should not be in the flow at all, and the DPIA is where that gap gets caught before launch.
Risk assessment to the rights and freedoms of data subjects
The risk register in a DPIA is about harm to the individual, not to the organisation; a section that only discusses regulatory fines and reputational damage is assessing the wrong thing. The CNIL methodology, widely used because it is concrete, scores each feared event (illegitimate access, unwanted modification, disappearance of data) on severity and likelihood using a four-point scale (negligible, limited, significant, maximum), driven by the threat sources that could cause it and the controls that make it more or less likely.
Measures envisaged to address the risks
Article 32 technical and organisational measures get listed against each risk identified above, not as a generic security policy summary but as a control mapped to the specific feared event it mitigates.
The security measures section and how testing results feed it
Article 32(1)(d) explicitly requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” That clause is the legal hook that turns vulnerability scan results and penetration test reports into required DPIA evidence rather than optional appendices. A security measures section that states “annual penetration test performed” satisfies almost nothing; one that states the last scan cycle’s date, the count of critical and high findings, the mean time to remediate, and the number of findings re-tested and confirmed closed gives a supervisory authority something it can actually evaluate against Article 32(1)(d).
A concrete threshold worth adopting: if a critical finding on an in-scope system is still open past an agreed SLA (a common baseline is 30 days for critical, 90 for high) when the DPIA is signed off, record it in the risk assessment as a residual risk, not in the measures section as if it were resolved. Either document a compensating control with a named owner, or get explicit risk acceptance signed by someone with authority to accept it, because “we have a scanner” is not itself a mitigation. Platforms that run continuous vulnerability management, such as SITEY, generate this evidence automatically because each finding carries a discovery timestamp, a remediation timestamp, and a re-test result as part of its normal lifecycle, which the security section can cite directly instead of summarizing a single annual audit from memory. The vulnerability lifecycle record and the retest and closure step are the two artifacts worth pulling in verbatim, since they answer exactly what Article 32(1)(d) asks: was the fix verified, and when.
Where a finding maps to a specific control, tying it to the framework language the DPIA already cites, an ISO 27001 Annex A number or a GDPR Article 32 measure, saves the reviewer from re-deriving that mapping by hand. A compliance mapping view that keeps findings linked to the relevant control across ISO 27001, PCI DSS, and GDPR at once turns a scan export into DPIA-ready evidence instead of a raw list someone has to translate.
Prior consultation with the supervisory authority
Article 36(1) makes consultation mandatory, not optional, when the DPIA indicates that the processing would result in a high risk in the absence of measures the controller takes to mitigate it, meaning the residual risk after every reasonably available technical and organisational measure is still assessed as high. This is narrower than “the DPIA found some risk”: it fires only when the risk remains high after mitigation, so the DPIA has to run to completion, including the measures section, before the consultation question can be answered.
Article 36(3) lists what the authority needs to review the request: the respective responsibilities of controller and any joint controllers or processors, the purposes and means of the intended processing, the measures and safeguards for data subjects’ rights, the DPO’s contact details where one exists, and the DPIA itself. Article 36(2) gives the authority up to eight weeks to respond, extendable by six weeks for complex cases, and it can prohibit the processing if it considers the infringement likely and the controller has not taken adequate mitigating steps. Prior consultation therefore belongs in the project timeline as a gating step measured in months, not a formality handled the week before launch.
Review cadence: when a change requires a new DPIA
A DPIA is not a one-time document filed at project kickoff. The GDPR’s risk-based framing implies ongoing review, and several concrete changes should trigger a new or updated assessment rather than waiting for an annual cycle: a new category of personal data added to the flow, a new recipient or sub-processor, a change in the cross-border transfer mechanism, an extended retention period, a new automated decision-making or profiling feature, a material increase in data volume or in the population affected, a security incident that reveals a risk the original assessment missed, or a technology change such as a cloud migration or a new AI-based scoring feature.
Even absent a specific trigger, a fixed review interval, commonly annual for high-risk processing, is worth keeping on the calendar because the threat landscape moves independently of the system itself: new CVE classes and new attack techniques against the same architecture shift the risk score without a single line of the processing changing. Continuous external attack surface monitoring gives a low-effort signal for this between scheduled reviews: a newly exposed service, an old subdomain back online, or a forgotten admin panel is itself a proportionality-relevant change to the processing’s risk profile. Standing attack surface management that runs as a continuous background phase, the way SITEY’s discovery phase does, is what catches this kind of drift between fixed review dates instead of leaving it for the next scheduled refresh.
DPIA versus legitimate interest assessment and transfer impact assessment
These three get confused because they can apply to the same processing operation at once, but each answers a different question and none substitutes for the others.
A legitimate interest assessment (LIA) is needed only when the controller relies on Article 6(1)(f) as the lawful basis. It runs a three-part test: a purpose test (is there a legitimate interest), a necessity test (is the processing necessary to achieve it), and a balancing test (do the data subject’s rights override that interest). The LIA is about whether the lawful basis holds up, independent of how risky the processing is overall.
A transfer impact assessment (TIA) is needed whenever personal data leaves the EEA under an Article 46 mechanism such as Standard Contractual Clauses, a requirement that became concrete practice after the Schrems II ruling. It checks whether the destination country’s laws and government access practices undermine the protection the transfer mechanism is supposed to provide, and what supplementary measures, such as encryption with keys held in the EEA, close that gap.
The table below separates the three by trigger and output, since that is usually where teams start treating them as interchangeable.
| Assessment | Triggered by | Core question | Typical output |
|---|---|---|---|
| DPIA | Article 35(3) criteria, WP248 nine-factor test, or national authority list | Is the residual risk to data subjects’ rights and freedoms acceptable | Risk register plus mitigation plan, possible prior consultation |
| LIA | Reliance on Article 6(1)(f) as the lawful basis | Does the legitimate interest outweigh the individual’s rights | Three-part balancing test recorded in the ROPA |
| TIA | Transfer of data outside the EEA under Article 46 | Does the destination country’s law undermine the transfer safeguard | Supplementary measures list or decision not to transfer |
A single high-risk operation involving an international vendor can legitimately need all three: a DPIA because it meets two WP248 criteria, an LIA because part of the processing relies on legitimate interest rather than consent, and a TIA because the vendor’s support team accesses data from outside the EEA. Rather than duplicating analysis, the DPIA’s necessity and proportionality section can reference the LIA’s balancing outcome and the TIA’s supplementary measures as supporting evidence, with one document as the anchor and the other two as inputs to it.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.