# Data protection impact assessments and privacy by design > **Key takeaway:** DPIA mandatory where processing is likely high-risk (Art 35(3) examples, or ICO's required list) — describe processing, assess necessity/proportionality and risk, identify mitigations; consult the ICO under Art 36 if high risk remains. Separately, Art 25 by-design/by-default applies to all processing, not just high-risk projects. - **Jurisdiction:** England & Wales - **Practice area:** Commercial - **Last reviewed:** 2026-09-05 - **Interactive page:** https://www.kttclegal.info/library/notes/Commercial/dpias-and-privacy-by-design - **Keywords:** DPIA, data protection impact assessment, Article 35, Article 36, privacy by design, data protection by default, ICO consultation, UK GDPR ## What is this about? A data protection impact assessment (DPIA) is a structured process for identifying and reducing the data protection risks of a project before it goes ahead. It is mandatory for processing likely to result in a high risk to individuals, and sits alongside the broader, always-applicable duty to build data protection into systems and processes by design and by default. ## What is the core rule? Article 35(1) requires a controller to carry out a DPIA before starting processing that, taking account of its nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of natural persons — Article 35(3) gives specific examples (systematic and extensive profiling with legal or similarly significant effects, large-scale processing of special category data, and systematic monitoring of publicly accessible areas on a large scale), and the ICO maintains a list of UK processing operations that always require a DPIA. A DPIA must contain a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to individuals, and the measures to address those risks (Art 35(7)). If residual high risk remains after mitigation, Article 36 requires prior consultation with the ICO. Separately, Article 25 requires 'data protection by design and by default' — implementing appropriate technical and organisational measures at the time of determining the means of processing, and by default processing only the personal data necessary for each specific purpose. ## What are the elements or test? 1. Does the processing meet the Art 35(3) high-risk indicators, or appear on the ICO's DPIA-required list? 2. If uncertain, has a screening assessment been done to decide whether a full DPIA is needed? 3. Description of the processing, its purposes, and (where relevant) the legitimate interest pursued 4. Assessment of necessity and proportionality of the processing against those purposes 5. Assessment of risks to individuals' rights and freedoms 6. Measures identified to address the risks, including safeguards and security measures 7. If residual high risk remains after mitigation: consult the ICO before proceeding (Art 36) 8. Separately and always: has data protection by design and by default (Art 25) been considered in the system's architecture? ## Which authorities matter? - **UK GDPR, Art 35** — Establishes when a DPIA is mandatory and what it must contain. - **UK GDPR, Art 35(3)** — Gives non-exhaustive high-risk indicators that trigger the DPIA duty. - **UK GDPR, Art 36** — Requires prior consultation with the ICO where a DPIA identifies residual high risk that cannot be mitigated. - **UK GDPR, Art 25** — The general, always-applicable data protection by design and by default duty, distinct from the DPIA trigger. - **ICO guidance and DPIA screening/required-processing lists** — Practical guidance and the ICO's list of UK processing types that always require a DPIA. ## How does this apply in practice? This note covers when and how a DPIA is triggered and structured; it does not provide a completed risk assessment for any specific technology (e.g. AI/ML systems, biometric identification, or large-scale employee monitoring), each of which needs its own fact-specific analysis. A DPIA is a living document — it should be revisited if the nature, scope, or risk profile of the processing changes materially. ## What are common pitfalls? - Treating a DPIA as a one-off compliance form rather than a genuine risk-reduction exercise run before the project is built - Only screening against the Art 35(3) examples and missing the ICO's more detailed 'must do a DPIA' list - Failing to consult the ICO under Art 36 when a DPIA honestly discloses unmitigated high risk - Confusing Art 25 (by design/by default, always applicable) with Art 35 (DPIA, only for high-risk processing) - Not revisiting a DPIA when the processing's scope or purpose changes after the initial assessment ## When would a practitioner use this? Required at the design stage of any new system, product, or processing activity carrying elevated privacy risk, and central to demonstrating accountability if a high-risk activity is later challenged or investigated. ## Quick reference DPIA mandatory where processing is likely high-risk (Art 35(3) examples, or ICO's required list) — describe processing, assess necessity/proportionality and risk, identify mitigations; consult the ICO under Art 36 if high risk remains. Separately, Art 25 by-design/by-default applies to all processing, not just high-risk projects. --- *Reference material from [KTTC Legal](https://www.kttclegal.info/), not legal advice. Work product supports instructing solicitors and barristers under their supervision. England & Wales.*