Data Privacy Impact Assessment
Data Privacy Impact Assessment
Begin
14 pages · ~28 min
Interactive digital-human course

Data Privacy Impact Assessment

A concise course for professionals on conducting Data Privacy Impact Assessments to identify and mitigate privacy risks in data processing activities.

My workspace28 minFree to watchDownloads

What you’ll learn

  1. 01Data Privacy Impact AssessmentWelcome. This course focuses on the Data Privacy Impact Assessment, or DPIA. It is a structured, documented process to identify and mitigate privacy risks before processing begins. It is no longer just a best practice. Under GDPR, CCPA, and a growing number of state laws, it is a core compliance obligation. The DPIA sits at the intersection of privacy governance, product development, and regulatory accountability. You need to understand when it triggers, how to run the methodology, and how to operationalize it for review. This course covers the triggers, the methodology, the regulatory variations, and the operational realities of running a DPIA program. Let's start by clarifying the terms. We will distinguish the PIA from the DPIA, and map accountability.Data Privacy Impact Assessmentcompliquest.comprivacyforge.iofticonsulting.com+22 min
  2. 02PIA vs. DPIA: Terms, Roles, and AccountabilityLet's clarify the terminology before we dive into the workflow. Privacy Impact Assessment is the broad, global term for any structured review of privacy risk. It's been best practice since the nineties, and many laws now require it. The Data Protection Impact Assessment is the specific GDPR obligation under Article 35, and it carries real legal consequences, including fines. But set the paperwork aside for a moment. The DPIA is foremost a preventive, forward-looking exercise. You run it before you build or launch a high-risk process, not after something goes wrong. So who owns it? The project or system owner holds the accountability. They coordinate with privacy, legal, security, and the Data Protection Officer, who provides the required consultation. In practice, the method is similar across frameworks, but the trigger and the authority differ. Keep that distinction clear, and your program stays credible. Now, let's look at exactly what triggers the GDPR requirement for a DPIA in the first place.PIA vs. DPIA: Terms, Roles, and Accountabilitycompliquest.comprivacyforge.iofticonsulting.com+21 min
  3. 03The GDPR Trigger: High Risk Before ProcessingNow, let's talk about when GDPR actually forces your hand before you even start. The trigger comes from Article 35, Section 1. Any processing that's likely to result in high risk to people's rights and freedoms demands an assessment, especially when new technologies are involved. The standard is predictive and forward-looking. You must evaluate on probability of harm, not wait for it to materialize. Timing is non-negotiable. The assessment happens before processing begins. This is a preventive tool, not a post-launch cleanup task. It's easy to assume this only applies to exotic tech like facial recognition or mass surveillance. It doesn't. Novel uses of existing technology count too, and so do familiar data practices applied to new contexts. There's a useful efficiency built into the regulation. You can run one assessment for a set of similar processing operations that carry similar high risks. Instead of repeating work for each instance, scope the assessment across the whole family of operations. But here's the catch. Conducting a DPIA when it's borderline is low cost. Failing to conduct one when it's clearly required exposes you to supervisory action, not to mention reputational risk. The asymmetry of that trade-off should guide your judgment. To formalize your screening, check whether the operation falls into one of the three always-mandatory categories under Article 35, Section 3, which is exactly what we'll dig into next.The GDPR Trigger: High Risk Before Processingrecordinglaw.comlegislation.gov.ukico.org.uk+21 min
  4. 04Article 35(3): Three Always-Mandatory CasesNow let's turn to the three cases where Article 35 makes a DPIA mandatory. No screening judgment needed. If your processing falls into one of these, you assess. Full stop. First, systematic and extensive automated evaluation, including profiling, that produces legal effects or similarly significant effects. Think automated credit decisions or algorithmic recruitment screening. Second, large-scale processing of special categories or criminal offence data. A hospital analysing patient records, or a fraud unit working with conviction data. Third, systematic monitoring of a publicly accessible area on a large scale. City-centre CCTV networks with analytics are the paradigm case, not a single shop camera. Remember the critical point. These three are a floor, not a ceiling. They are the legislator's automatic triggers. Other processing that meets the general high-risk test still requires a DPIA. So use Article 35(3) for your first pass, then screen against the EDPB criteria. And if only one criterion is met, but the potential impact is severe, document your reasoning and lean towards assessing. Now, let's move to the practical screening framework itself, the EDPB's Nine Criteria.Article 35(3): Three Always-Mandatory Casesrecordinglaw.comlegislation.gov.ukico.org.uk+21 min
  5. 05The EDPB Nine Criteria: Practical ScreeningLet's turn those Article 35 triggers into a practical screening tool. The EDPB's nine criteria are your checklist for spotting high risk early. Run your processing against each one. Evaluation or scoring, automated decisions, systematic monitoring, sensitive data, large scale, dataset matching, vulnerable subjects, innovation, blocking services. That's the full set. Now the threshold. Two criteria met is the trigger to conduct a DPIA. One can suffice if the severity is plain. If you are screening a personalization engine that scores customers, monitors behavior at scale, and uses machine learning, you are four for nine. Not a close call. But here's the discipline that separates strong programs. Document every screening, even the no-DPIA conclusions. A short memo stating you considered the nine criteria, none applied, and here is the reasoning, is a defensible compliance artifact. Silence is not. It's the difference between demonstrating accountability and hoping nobody asks. Remember, the cheapest DPIA is the screening that correctly concludes you don't need one, documented. Now, the nine criteria are the baseline. National regulators have added their own lists, so let's look at how sectoral and jurisdictional triggers extend the framework.The EDPB Nine Criteria: Practical Screeningcompliquest.comprivacyforge.iofticonsulting.com+22 min
  6. 06National and Sectoral Additions to the TriggerNational lists add another layer to the trigger. Article 35, paragraph 4 requires each supervisory authority to publish a blacklist of processing operations that always demand a DPIA. These are mandatory, regardless of what the EDPB criteria suggest. Consider the French example. The CNIL treats internal alert and whistleblowing systems as requiring a DPIA in all cases. The Dutch authority, the AP, does the same for employee camera surveillance and credit scoring. Meanwhile, the Italian Garante flags systematic monitoring of workplace email and internet use. The key takeaway for cross-border work is that one list is never sufficient. If you operate in multiple markets, check each authority's published list. A processing activity that looks routine in one jurisdiction can be automatically high-risk in another. Build this into your screening workflow. Include the national blacklist check right after your Article 35, paragraph 3 assessment. Now let us turn to the United States, where state-level triggers add another layer of complexity.National and Sectoral Additions to the Triggerrecordinglaw.comlegislation.gov.ukico.org.uk+22 min
  7. 07US State Law Triggers and DivergencesLet's turn to the US state landscape. Over fifteen states now mandate data protection assessments. The good news is that most triggers converge on familiar territory: targeted advertising, data sales, profiling that carries significant effects, and sensitive data processing. Where it gets complicated is California. Its Article Ten is the most prescriptive framework in the country, with six distinct trigger categories. These include selling or sharing data, processing sensitive information, using automated decision-making for significant decisions, profiling in employment and education, location-based profiling, and training those algorithms in the first place. That's a broader net than most other states cast. And remember, the other key divergence lies in submission mechanics. California requires a scheduled filing with the CPPA, with an attestation under penalty of perjury by April first, 2028 for the first cycle. The other states generally keep your assessments internal unless the attorney general requests them during an investigation. So your documentation strategy matters. Build one master assessment capable of flexing to California's prescriptive requirements while remaining credible for AG review elsewhere. Next, we'll walk through what California's Article Ten actually demands in practice.US State Law Triggers and Divergencescompliquest.comprivacyforge.iofticonsulting.com+21 min
  8. 08CCPA Article 10: Risk Assessments in PracticeTurning now to California. Article 10 requires risk assessments before you launch any processing that presents significant risk. The regulation fixes six triggers: selling or sharing personal information, processing sensitive personal information, using automated decision-making for significant decisions, profiling in employment and education, profiling based on sensitive locations, and training AI or biometric systems. Unlike the GDPR’s criteria-based approach, these are categorical. You do not do a judgement call. The core of the assessment is a documented balancing test. You weigh the privacy risks to consumers against the benefits to them, to your business, to other stakeholders, and to the public. Documentation matters more than you may expect. A decision-maker with authority to initiate the processing must review and approve. Legal counsel providing advice may be excluded from that approval role. Note the continuous duties: you update your assessment within 45 days of a material change. You must refresh every three years regardless. And from 2028, you submit information to the CPPA annually by April 1st, certified under penalty of perjury by executive management. Plan your assessment program as a permanent capability, not as one-off compliance work. Next, let’s look at what an Article 35 assessment must contain under the GDPR.CCPA Article 10: Risk Assessments in Practicecompliquest.comprivacyforge.iofticonsulting.com+22 min
  9. 09Core DPIA Content: Article 35(7) MinimumsLet’s turn to the heart of the document itself. Article 35, paragraph 7, sets the four minimum elements every DPIA must contain. These are not suggestions; omit any one of them and the assessment is legally deficient. Start with a systematic description of the processing. That means the nature, scope, context, and purposes. List the data categories, the recipients, the retention periods. Do not just name the product; describe the operation itself. Second, assess necessity and proportionality against the stated purpose. Can you achieve the goal with less data or a less invasive method? The exercise must test data minimization against your lawful basis. Third, evaluate risks to data subjects’ rights and freedoms. Measure likelihood and severity of harm, looking at confidentiality, integrity, and availability. Then fourth, list the safeguards, security measures, and compliance mechanisms you will deploy to address those risks. Document each control against the specific risk. Finally, re-score the risk after mitigation. You must record the residual risk and decide if it is acceptable. If it remains high, you cannot proceed; you move to prior consultation. Keep that residual risk declaration explicit ——it is the decision point reviewers will scrutinize first. Next, we shift to how you actually conduct the risk analysis: the method and the perspective you take.Core DPIA Content: Article 35(7) Minimumscompliquest.comprivacyforge.iofticonsulting.com+22 min
  10. 10Risk Analysis: Method and PerspectiveNow let's focus on the risk analysis itself. This is where the assessment moves from description to judgment. For each risk, rate likelihood and severity of harm to individuals. A two-by-two matrix works well. Low, medium, high on each axis. But here is the key point: do not rate risks to your business. Rate risks to individuals. That is the perspective regulators expect. Assess risks across three dimensions: confidentiality, integrity, and availability. Confidentiality is unauthorized access. Integrity is unauthorized modification. Availability is loss of access. Now, a critical distinction. Focus on rights-based harms. Think discrimination, financial loss, exclusion from services, or loss of control over personal data. These are the harms that trigger regulatory concern. And do not ignore benefits. The CCPA framework explicitly requires weighing the benefits of processing to the consumer, the business, and the public against the risks. Finally, assess residual risk after mitigation. Document the controls you will apply, then re-score. If residual risk remains high, do not launch. That is your escalation trigger for prior consultation. We will cover that next with the D P O and consultation duties.Risk Analysis: Method and Perspectivecompliquest.comprivacyforge.iofticonsulting.com+22 min
  11. 11Consultation, DPO Advice, and Prior ConsultationNow let’s walk the consultation path. Under Article 35, paragraph two, you must seek your Data Protection Officer’s advice. But keep ownership clear: the DPO reviews and advises, they do not own the DPIA. Accountability sits with the controller, with you. Where appropriate, also seek the views of data subjects or their representatives. It is not always mandatory, but it is a fairness signal regulators notice. The critical fork comes under Article 36. If your residual risk remains high after mitigations, prior consultation with the supervisory authority is not optional; it is a legal precondition to launching. That consultation can result in conditions imposed on your processing, and in a worst case, a prohibition. Treat that threshold honestly. Commencing without consultation when high risk persists is a separate, and serious, compliance failure. So, the practical guide is this: Document the DPO’s opinion. Record the rationale if you skip data subject input. And if high risk survives your controls, file the Article 36 package before you go live. Now, let’s shift focus to where this work actually happens—operationalizing DPIAs in the development lifecycle.Consultation, DPO Advice, and Prior Consultationcompliquest.comprivacyforge.iofticonsulting.com+21 min
  12. 12Operationalizing DPIAs in the Development LifecycleNow let's turn to operationalizing DPIAs in the development lifecycle. The goal here is to make the assessment a natural checkpoint, not a compliance silo. Start by embedding a DPIA screening questionnaire directly into your project intake process. This should map to the GDPR Article 35 triggers and the EDPB's nine high-risk criteria. Remember the rule of thumb: if a project hits two or more criteria, you schedule a DPIA before build, not after. But here's the catch. You cannot rely solely on the European framework. Each national supervisory authority publishes its own list of mandatory cases. The French CNIL, the Dutch AP, and the Italian Garante all have lists that diverge meaningfully. Check the list for every market where you operate. Next, use a standardized template aligned to the 2026 EDPB structure. The Board adopted its first common template in March of 2026. It provides the clearest statement of what regulators consider a complete DPIA. You can save considerable effort by leveraging what already exists. Pull descriptions of data flows, purposes, and retention periods from your existing data maps and records of processing. Finally, treat the DPIA as a living document. Article 35, paragraph 11 requires a review whenever the risk profile changes. Tie these reviews directly to your change management process, not to the calendar alone. This keeps your assessments accurate and your evidence ready. Now, let's see how the 2026 EDPB template interacts with the AI Act's overlapping obligations.Operationalizing DPIAs in the Development Lifecyclecompliquest.comprivacyforge.iofticonsulting.com+22 min
  13. 13The 2026 EDPB Template and AI Act OverlapNow let's turn to the operational side and cover the 2026 EDPB template and its overlap with the AI Act. In March of 2026, the European Data Protection Board adopted its first standardized DPIA template. It is version one point zero, published with a plain language explainer and opened for public consultation through early June. This template walks a controller through the full DPIA lifecycle across seven sections, mirroring the minimum contents Article 35.7 has always required. A systematic description of the processing, an assessment of necessity and proportionality, a risk assessment, and mitigation measures. The critical point for you is this. The template is a harmonization tool, not a new obligation. National formats, such as the CNIL tooling or the German standard data protection model, remain valid. But this is the clearest available statement of what EU regulators collectively consider a complete DPIA, so it is the sensible default structure for any new assessment started in 2026. Now, on the AI Act overlap, if you deploy certain high risk AI systems, you must conduct a fundamental rights impact assessment, a separate obligation that heavily overlaps with DPIA content. The AI Act explicitly anticipates combining these, so build one assessment workflow that satisfies both rather than running parallel paperwork. Remember, the DPIA duty applies now. We'll now move on to practical strategies for programme managers.The 2026 EDPB Template and AI Act Overlapcompliquest.comprivacyforge.iofticonsulting.com+21 min
  14. 14Practical Strategies for Programme ManagersSo how do you make all of this operational without grinding your roadmap to a halt? Build your screen at intake. If your processing hits two or more EDPB criteria, or even one clearly severe risk, schedule the DPIA before anyone writes code. Next, stop duplicating effort. Your data maps and processing records already contain most of the groundwork a DPIA needs. Pull from them, don't rebuild. When you do screen something out, document that finding. A note explaining which criteria you considered and why none applied is valuable accountability evidence if a regulator comes knocking. Finally, build review triggers into your change process. New data categories, a new vendor, a change in model logic, or a shift in regulations are all material changes that call for a fresh look. Don't leave that to the calendar alone. This brings us to the end of the course. We've covered the triggers, the workflow, and the documentation that makes an impact assessment program defensible. Thanks for your focus, and go put these strategies into practice.Practical Strategies for Programme Managerscompliquest.comprivacyforge.iofticonsulting.com+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.