When is a GDPR DPIA mandatory, and what must it contain?
Article 35(1) requires a DPIA where processing, in particular using new technologies, is likely to result in a high risk to rights and freedoms, with Article 35(3) naming three always-on triggers, systematic and extensive automated evaluation (profiling) producing legal or similarly significant effects, large-scale processing of Article 9/10 special categories, and systematic large-scale monitoring of publicly accessible areas, and the WP29's guidelines (WP248, EDPB-endorsed) supplying the operative nine criteria: evaluation or scoring, automated decisions with significant effect, systematic monitoring, sensitive data, large scale, matched or combined datasets, vulnerable subjects, innovative technology, and processing that prevents rights exercise, with two or more criteria creating a strong DPIA presumption; each DPA also publishes mandatory-DPIA blacklists under Article 35(4) (and some whitelists), so the screening checks the national lists too. Required content (Article 35(7)): a systematic description of the processing and purposes (including legitimate interests pursued), a necessity and proportionality assessment (could the purpose be achieved with less data, shorter retention, narrower access, the analysis DPAs read most critically), an assessment of risks to data subjects' rights and freedoms (not corporate risk: identity theft, discrimination, exclusion, chilling effects, physical safety, analyzed by likelihood and severity), and the measures addressing those risks, demonstrating compliance, with DPO advice sought where one exists (Article 35(2)) and subjects' views where appropriate. Prior consultation (Article 36): if the DPIA concludes residual risk remains high without mitigation, the controller must consult the supervisory authority before processing, an eight-week-extendable process regulators can answer with warnings or bans, rare in practice precisely because its existence forces mitigation to conclusion. The enforcement pattern: DPIA absence is independently finable (the 10M EUR/2% tier), DPIA requests open most DPA inquiries, and a documented, honest DPIA is the strongest single mitigation exhibit when something else goes wrong, while a DPIA that identified a risk the company then ignored is the opposite.
What do the US state data protection assessments require, and how do they differ from DPIAs?
The trigger architecture, first: the Virginia/Colorado/Connecticut family requires data protection assessments before processing that presents a heightened risk of harm, enumerated as targeted advertising, sale of personal data, profiling with foreseeable risks of unfair treatment or significant effects, and sensitive-data processing, so the American triggers catch routine adtech monetization that a European screening might pass through legitimate-interests analysis instead, and California's CPPA finalized its risk-assessment regulations (2025) requiring assessments for selling/sharing, sensitive-data processing, ADMT for significant decisions, and certain profiling, with phased filing of abridged summaries to the agency, the first US filing regime. Content: Colorado's rules are the most detailed, a short-form triggering analysis then a full assessment covering processing description, purpose, categories, recipients, the benefits weighed against risks to consumers with mitigations (an explicit balancing test, more consequentialist than the GDPR's rights framing), safeguards, and approval records; Connecticut and the family track similar elements; the statutes deem GDPR DPIAs satisfactory where they cover comparable processing, an explicit interoperability clause programs should exploit. The structural differences from DPIAs: production-on-demand rather than proactive filing (the AG can require the assessment in an investigation, with statutes preserving privilege claims, so the artifact must be written expecting adversarial reading), the balancing-test framing, single-document-per-processing-activity conventions, and no prior-consultation mechanism, the mitigation loop is internal. Adjacent US obligations that ride the same pipeline: the FTC's orders increasingly mandate privacy risk assessments as fencing-in relief; the 2025 COPPA amendments' written security program implies assessment; Washington MHMD and the health statutes make assessment prudent for consumer-health features; and the state AI laws (Colorado's AI Act's impact assessments for high-risk AI deployers, effective on its revised 2026 schedule) bolt algorithmic assessments onto the same triggers. Practical exploitation of the overlap: run one assessment whose sections map to both Article 35(7) and the Colorado elements, record the crosswalk, and render per-regime cover sheets, the analysis is 85% shared, and the state laws' GDPR-recognition clauses bless exactly this.
What do Quebec, China, Brazil, and the other regimes require?
Quebec (Law 25): the broadest trigger in North America, a privacy impact assessment is required for any project of acquisition, development, or redesign of an information system or electronic service delivery involving personal information (proportionate to sensitivity, purpose, and scale), plus the transfer-specific PIA before communicating personal information outside Quebec (the adequate-protection analysis), and PIAs before using biometrics (with the separate CAI disclosure duty for biometric databases); the CAI's guidance frames content along familiar lines (description, necessity, risks, mitigations) with the committee-on-access-to-information governance wrinkle for public bodies; the practical effect is that Quebec turns the assessment from an exceptional high-risk exercise into a default system-lifecycle gate. China (PIPL Articles 55-56): the personal information protection impact assessment (PIPIA) is mandatory before processing sensitive personal information, using personal information for automated decision-making, entrusting processing to others, providing to other handlers, public disclosure, cross-border transfer, and other high-impact activities, covering lawfulness/legitimacy/necessity of purpose and method, impact on individuals' rights and security risks, and the effectiveness of protection measures, with reports retained at least three years, and the transfer-route filings (CAC assessment, Chinese SCC filing) consuming the PIPIA as an exhibit, so China-facing programs produce PIPIAs as routinely as DPAs produce DPIAs. Brazil (LGPD Articles 5(XVII), 38): the relatório de impacto à proteção de dados (RIPD) is defined and demandable, ANPD may require it, and its regulations and guidance (including for high-risk and large-scale processing) have progressively firmed expectations for when a controller should have one ready, the practical posture being DPIA-equivalent preparation for high-risk processing without a proactive filing duty. The rest of the map: the UK mirrors Article 35 with ICO screening checklists; Singapore's PDPC treats DPIAs as accountability best practice underpinning its enforcement expectations; Korea's PIPA mandates PIAs for public institutions and incentivizes private ones; India's DPDP rules bring assessment duties for significant data fiduciaries; Australia's OAIC requires PIAs for government agencies (the Privacy (Australian Government Agencies, Governance) APP Code) and the reform process points private-sector-ward; and the EU AI Act's Article 27 fundamental rights impact assessment for high-risk AI deployers (public bodies and certain private services) plus DPIA-linkage provisions extend the family to AI, with Colorado's AI Act as the US sibling. The comparative note that matters operationally: triggers are converging on the same risk vocabulary, so the screening questionnaire can be unified, but filing/retention mechanics (PIPIA's 3 years, California's abridged submissions, Quebec's project-gate timing) stay jurisdiction-specific.
How does one assessment pipeline serve all these regimes at once?
Four shared stages with jurisdiction-specific rendering at the end. Universal screening: a short intake in the product/procurement/architecture workflow (what data, whose, what purpose, what triggers), evaluated against a merged trigger table, the WP248 criteria, the state heightened-risk enumeration, Quebec's system-project gate, PIPL's activity list, AI-specific triggers, with two outputs, no-assessment-needed (recorded, because the negative decision is itself demandable evidence) or route-to-assessment with the applicable regimes flagged; the screening must sit in the paths work actually flows through (ticket templates, procurement gates, launch checklists), since the failure mode of every assessment program is bypass, not bad analysis. One core analysis: processing description from the data inventory (systems, categories, flows, recipients, retention), purpose articulation with necessity and proportionality honestly argued (the section that improves products: teams asked 'could you do this with less' routinely can), risk identification from the subject's perspective using a maintained risk taxonomy (identity theft, discrimination, manipulation, exclusion, safety, chilling), likelihood-severity rating with the organization's standard scale, and mitigations with owners and dates, engineering controls preferred over policy promises. Multi-regime rendering: the core analysis papered per applicable regime, Article 35(7) structure for the EU/UK, the Colorado elements with the benefit-risk balancing paragraph, the PIPIA's lawfulness-necessity-effectiveness framing with 3-year retention, Quebec's PIA format with the transfer analysis where relevant, and the AI Act/Colorado-AI sections where the system is in scope, from templates that share sections rather than parallel documents that drift. Closure discipline: mitigations tracked to completion before launch (the assessment that identified risks nobody fixed is the prosecution exhibit), residual-risk sign-off by the accountable owner with DPO advice recorded, prior-consultation routing in the rare high-residual case, and re-assessment triggers wired to change management (purpose change, new data category, new recipient, model swap, scope expansion), because assessments date from the facts they describe. Governance metrics that indicate reality: screening coverage (initiatives screened versus shipped, the bypass rate), time-to-complete (assessments that take months get bypassed), mitigation completion rate, and the sampling audit, pick shipped features, check for the assessment trail, the same test the Colorado AG or a DPA will run.
What separates an assessment that protects the organization from one that hurts it?
Assessments are discoverable, demandable, and read in hindsight, which creates the quality bar. What protects: honesty about risk, the document names the real risks (reidentification of the 'anonymized' dataset, discriminatory error rates in the model, the chilling effect of workplace monitoring) and shows them mitigated or accepted by someone with authority, because regulators consistently treat candid-assessment-plus-mitigation as good faith, and because the alternative, an assessment that conspicuously omits the risk that later materialized, reads as concealment; specificity, actual data elements, actual flows, actual retention numbers, actual access lists, since generic template language ('appropriate technical and organizational measures') provides no defense and signals a paper exercise; the necessity argument taken seriously, with alternatives considered and the less-intrusive options either adopted or rejected for stated reasons, the analytical core every regime's framework shares and every regulator reads first; mitigation follow-through, tickets closed, controls verified, the loop from finding to fix documented, which is the difference between an assessment and a confession; and currency, re-run on material change, so the document describes the system that exists. What hurts: the retrofitted assessment (dated after launch, or transparently reverse-engineered to bless a decision already shipped, both visible from metadata and content); the risk-scoring theater (every risk landing just below the mitigation threshold, a pattern reviewers recognize instantly); the ignored finding (the assessment's own recommendation, unimplemented, no recorded acceptance decision, the single worst artifact to produce in litigation, and the pattern in multiple FTC and DPA matters where internal warnings predated the violation); scope gaming (assessing the pilot while the production system processes ten times the data); and privilege confusion, expecting attorney-client privilege to shield a document statutes make demandable, rather than structuring candid legal analysis separately from the producible assessment, a drafting architecture worth deciding with counsel before the first assessment is written, not during the first investigation. The summary standard: write every assessment as if its audience is the regulator who will read it beside the incident report, because for the assessments that matter, that is the audience.