DPIA Guidelines: When and How to Assess Privacy Risk

Article 35(1) sets the standard: a DPIA is required 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, and Article 35(3) names three always-DPIA cases: systematic and extensive automated evaluation (including profiling) producing legal or similarly significant effects; large-scale processing of special-category or criminal-conviction data; and systematic large-scale monitoring of publicly accessible areas. The WP29 guidelines (WP248, endorsed by the EDPB) operationalize 'likely high risk' with nine criteria: evaluation or scoring; automated decision-making with legal or similar effect; systematic monitoring; sensitive or highly personal data; large scale; matching or combining datasets; vulnerable data subjects (employees, children, patients); innovative technology or novel application; and processing that prevents subjects from exercising rights or accessing services. The working rule: two or more criteria, do the DPIA; one criterion, document why you concluded no high risk (that negative screening record is itself the audit artifact, because 'we considered it and reasoned X' defends where silence cannot). Each member state DPA also publishes mandatory-DPIA lists under Article 35(4), biometrics, geolocation, health data patterns vary by country, so multi-country deployments check the strictest applicable list. Common triggers in practice: deploying employee-monitoring tooling, launching AI features that evaluate people, adding biometric authentication, large-scale location processing, connected products in homes or vehicles, matching datasets across services, and children's products, roughly the same list state-law assessment mandates and the EU AI Act's high-risk categories converge on, which is why a single screening gate can feed all three regimes.

Article 35(7) mandates four elements: a systematic description of the processing and its purposes (including legitimate interests pursued); an assessment of necessity and proportionality; an assessment of the risks to data subjects' rights and freedoms; and the measures envisaged to address those risks, including safeguards and mechanisms to demonstrate compliance. A method that produces defensible assessments rather than paperwork: Describe concretely, data categories and sources, flows and recipients, retention, the technology's actual mechanics (a diagram beats prose), because vague descriptions make every later step vacuous. Test necessity honestly: could the purpose be achieved with less data, shorter retention, coarser granularity, or without the intrusive component; this is where DPIAs earn their keep, and where reviewers can tell a real assessment from a ratification, the necessity section of a rubber-stamp DPIA never says no to anything. Assess risks from the individual's perspective, not the company's: what could go wrong for the people (discrimination, identity theft, chilling effects, loss of control, physical safety for location data), through what scenarios (breach, function creep, re-identification, erroneous decisions), with likelihood and severity rated on a defined scale; the classic defect is a risk register full of corporate risks (fines, reputation) which is precisely not what Article 35 asks. Mitigate specifically: each material risk gets measures (minimization, pseudonymization, access controls, transparency, human review, opt-outs), an owner, and a residual-risk rating, and mitigation items feed the actual project backlog, a DPIA whose mitigations never became tickets is a confession. Record the DPO's advice (Article 35(2) requires seeking it) and, where appropriate, data subjects' views. Then version it: the DPIA is living documentation, revisited when the processing changes, Article 35(11)'s review duty.

Article 36: if the DPIA concludes that residual risk remains high despite the mitigations you can take, the controller must consult the supervisory authority before processing begins. The DPA then has eight weeks (extendable by six) to respond with written advice, which can range from recommendations through formal warning to using any of its Article 58 powers, including banning the processing. Consequences worth internalizing: prior consultation is not approval-seeking for anything risky, it is the escape valve for the narrow case where you cannot mitigate to acceptability but believe the processing is still justified; most DPIAs should conclude below that threshold, because if mitigation cannot tame the risk, the usual right answer is redesign, not regulatory submission. Skipping a required consultation is an independent violation stacked on any substantive ones, and it surfaces badly, typically after a breach or complaint, when the regulator asks for the DPIA and reads its own risk conclusion. The practical calibration: treat 'would we need to consult?' as a design forcing function; teams facing an Article 36 conclusion almost always find the redesign (more minimization, human oversight, staged rollout, narrower scope) preferable to an eight-week regulatory pause with an uncertain outcome. Where consultation does happen, arrive with the complete DPIA, the mitigation history showing what you tried, and the specific question you want answered; DPAs respond materially better to 'we assessed, mitigated, and here is the residual dilemma' than to a project seeking blessing. And one procedural footnote: some processing (e.g. under national law provisions per Article 36(5)) may require consultation or authorization regardless of the DPIA's conclusion, health registries and public-interest processing being the usual suspects.

The family resemblance is strong, the details diverge. UK GDPR: essentially identical (Article 35/36 with ICO guidance and its own mandatory list); one assessment serves both EU and UK with a jurisdictions annex. US state laws: Colorado, Connecticut, Virginia, and most of the post-2023 wave require 'data protection assessments' for processing presenting heightened risk, defined to include targeted advertising, sale of personal data, sensitive-data processing, and profiling with foreseeable significant effects; the assessments weigh benefits against risks to consumers, must be produced to the attorney general on request (civil investigative demand, not public disclosure), and Colorado's rules are the most prescriptive about content; California's CCPA regulations add risk assessments for ADMT, sensitive data, and behavioral advertising with submission-to-CPPA mechanics phasing in (abridged summaries from 2028 for 2026-2027 processing). Quebec Law 25: PIAs required for information-system projects involving personal information and before communicating data outside Quebec, a broader trigger than the GDPR's. Elsewhere: Brazil's LGPD contemplates the RIPD, China's PIPL mandates personal information protection impact assessments for sensitive data, automated decisions, transfers, and disclosures (closer to always-on than the GDPR's threshold), Singapore and India's frameworks push DPIA-like duties onto significant processors. Convergence strategy: one master template whose core (description, necessity, individual-risk analysis, mitigations) satisfies the strictest regime, with jurisdiction modules (the state-law benefit-balancing section, Quebec's transfer analysis, PIPL's specifics) toggled per applicability; one screening gate in the product/procurement workflow that routes to whichever assessments the processing triggers; and one register of completed assessments, because the AG's civil investigative demand and the DPA's inquiry both begin with 'produce them,' and the response-time difference between a register and an archaeology project is the difference between a routine interaction and a finding.

The failure modes are known: DPIAs done after launch (ratification, not assessment), done by legal alone (missing the technical truth), boilerplate risk registers (corporate risks, generic mitigations), and orphaned conclusions (mitigations that never reached a backlog). The countermeasures. Wire screening into intake paths that already exist: the product-launch checklist, procurement onboarding, and architecture review each get the two-question screen (personal data? any of the nine criteria?), so assessments start when design is still fluid; a DPIA that begins after the vendor contract is signed can only bless or embarrass. Compose the right team: the assessment needs the product owner (purposes), an engineer who knows the actual data flows (truth), and privacy counsel or the DPO (law and method); any one alone produces a document with a characteristic blind spot. Time-box proportionately: a focused DPIA for a typical feature is days of elapsed work, not months, with depth scaling to risk; the heavyweight version is for the genuinely heavyweight processing, and a program whose every DPIA takes a quarter will be routed around by every deadline-driven team. Make mitigations tickets: each measure gets an owner and lands in the delivery backlog with the release dependency stated; the DPIA is done when the mitigations ship, not when the document saves. Close the loop: post-launch, verify the processing matches the description (drift between DPIA and deployment is a finding regulators specifically look for), and set review triggers, scope changes, new data categories, model retraining, vendor swaps. Keep the register with metrics: assessments completed, screening coverage of launches, median cycle time, open mitigation age, numbers that tell management whether the process works and tell a regulator that it exists. The tone-setting insight: teams stop fearing DPIAs when the process reliably improves designs (catching the over-collection, the missing retention limit, the absent opt-out) early enough to fix cheaply; the assessment that saves a team from an expensive post-launch retrofit converts more engineers than any policy mandate.