A Data Protection Impact Assessment (DPIA) is a systematic process for identifying and minimising the data protection risks of new projects or changes to existing processing activities that are likely to result in a high risk to the rights and freedoms of individuals. DPIAs are required under Article 35 of the UK General Data Protection Regulation (UK GDPR), which is the version of the EU GDPR retained in UK law by the European Union (Withdrawal) Act 2018 and subsequently amended by the Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019. The Data Protection Act 2018 supplements the UK GDPR and Section 64 provides additional guidance on when prior ICO consultation is required under Article 36.

The ICO defines a DPIA as a process to help organisations identify and minimise the data protection risks of a project. This is both a risk management tool and a demonstration of accountability — one of the core principles of the UK GDPR under Article 5(2). Completing a DPIA before embarking on high-risk processing reduces the likelihood of a compliance failure and the associated reputational damage and regulatory consequences.

Recital 84 of the UK GDPR explains the purpose of the DPIA: to assess the particular likelihood and severity of the high risk to the rights and freedoms of natural persons, taking into account the nature, scope, context, and purposes of the processing. A DPIA is not a box-ticking exercise — it must be a genuine, evidence-based assessment that leads to informed decisions about how to design the processing activity to minimise privacy impact.

The ICO has published a mandatory list of processing types that always require a DPIA in the United Kingdom, in accordance with Article 35(4). This list includes: large-scale profiling; biometric data for unique identification; special category data matched or combined from multiple sources; personal data of vulnerable individuals processed on a large scale; innovative technology with significant privacy implications; and systematic monitoring of publicly accessible areas using CCTV or similar technology. Where a processing activity falls within any of these categories, a DPIA is legally required before the processing begins.

A DPIA is needed whenever your organisation plans to introduce a new processing activity or significantly change an existing one that is likely to result in a high risk to individuals. The ICO provides a screening checklist to help organisations determine whether a DPIA is required, but the following situations always require one under Article 35(3) UK GDPR or the ICO's mandatory list.

Biometric and genetic data processing requires a DPIA whenever you plan to use technology that processes facial recognition, fingerprints, iris scans, voice recognition, DNA, or other biometric identifiers to uniquely identify individuals. This applies to employee access control systems, customer authentication systems, and any other application that captures biometric data, even where the data is immediately converted into a mathematical template rather than stored as a raw image.

Large-scale profiling and automated decision-making requires a DPIA where you use automated systems — including machine learning, AI, or algorithmic scoring — to evaluate personal aspects of individuals (creditworthiness, health risks, job performance, behaviour patterns) and make or support decisions that produce legal or similarly significant effects. This includes credit scoring engines, insurance risk algorithms, recruitment screening tools, and fraud detection systems.

Employee monitoring projects require a DPIA where you plan to introduce new monitoring technologies such as email monitoring, internet usage tracking, keystroke logging, GPS vehicle tracking, productivity analytics, or any other systematic monitoring of employees' activities. The ICO and the Employment Practices Code both recognise that employees have a reasonable expectation of privacy even in the workplace, and systematic monitoring must be justified and proportionate.

Data sharing between organisations on a large scale, including creating centralised databases combining data from multiple organisations, requires a DPIA. This is particularly relevant for healthcare data sharing programmes, fraud prevention databases, and public-private data sharing initiatives.

New technologies and innovative applications of existing technologies require a DPIA where the privacy implications are not fully understood or where the technology could be used in ways that individuals would not reasonably anticipate. The ICO specifically identifies the Internet of Things (IoT), smart city infrastructure, wearable health devices, and AI-based decision support systems as examples of processing requiring a DPIA.

Systematic Processing Description — The foundation of any DPIA is a clear, accurate description of the processing operations. The description must address the four dimensions specified in Article 35(7)(a): nature (what operations are performed on the data), scope (the volume, frequency, and geographic spread), context (the environment and circumstances of the processing), and purpose (the specific objectives). A vague or incomplete description undermines the entire DPIA and may indicate that the controller does not have adequate understanding of its own processing.

Lawful Basis and Special Category Conditions — Every processing activity must rest on one of the six lawful bases in Article 6 UK GDPR. For special category data (health, biometric, genetic, racial, criminal, religious, sexual orientation, political), an additional condition under Article 9(2) must be identified. Where DPA 2018 Schedule 1 conditions are relevant (employment, research, substantial public interest), these must also be cited. The DPIA should confirm that the lawful basis has been documented in the controller's Records of Processing Activities (ROPA) under Article 30.

Data Subjects and Retention Assessment — The DPIA must identify the categories of data subjects with precision, noting any vulnerable groups (children, elderly individuals, people with disabilities, patients, job applicants) whose data warrants elevated protection. The data retention period must be specified for each category of personal data, with reference to the legal, regulatory, or operational basis for the chosen period. The UK GDPR Article 5(1)(e) storage limitation principle prohibits retaining personal data for longer than necessary.

Automated Decision-Making Evaluation — Where the processing involves automated decisions (including profiling) that produce legal or similarly significant effects, the DPIA must describe the logic involved and assess compliance with Article 22 UK GDPR. Data subjects have the right to human review of automated decisions, the right to express a point of view, and the right to contest the decision. The DPIA must address how these rights are facilitated.

Necessity and Proportionality Test — Article 35(7)(b) requires a genuine assessment of whether the processing is necessary and proportionate to its stated purpose. The ICO expects this to include consideration of: whether a less privacy-intrusive approach could achieve the same objective; whether the same purpose could be achieved using anonymised or pseudonymised data; the minimum volume of personal data needed; and whether the data minimisation principle (Article 5(1)(c)) has been applied.

Risk Identification and Assessment Matrix — The core of the DPIA is a structured assessment of the risks to data subjects. The ICO identifies four categories of harm: physical (injury, safety risks), material (financial loss, identity theft, discrimination), non-material (distress, reputational damage, loss of opportunity), and loss of control (inability to manage one's own data). For each identified risk, the DPIA should assess the likelihood of occurrence and the severity of harm if the risk materialises, resulting in a risk rating (low, medium, high).

Risk Mitigation Measures — For each identified risk, the DPIA must describe specific technical and organisational measures to reduce the likelihood or severity of the harm. Technical measures include encryption, pseudonymisation, access controls, data minimisation, and security monitoring. Organisational measures include data retention policies, staff training, contractual obligations on processors, and audit procedures. After applying mitigation measures, the residual risk must be re-assessed.

DPO Consultation Record — Article 35(2) requires the controller to seek the DPO's advice, and Article 38(1) requires the DPO to be involved in a timely manner. The DPIA must record the DPO's specific recommendations and whether they were accepted. If the DPO disagrees with the controller's risk assessment or conclusions, this disagreement must be documented, with the DPO's reasoning and the controller's response. This record protects both the DPO (who has statutory independence under Article 38(3)) and the controller (who can demonstrate that proper governance was followed).

ICO Prior Consultation Decision — Where the residual risk after mitigation is assessed as high, Article 36(1) requires prior consultation with the ICO before processing begins. The DPIA must document this decision. Where ICO consultation is conducted, the controller must provide the ICO with the completed DPIA, the purposes and means of processing, the measures and safeguards, and the DPO's contact details. The ICO's written advice must be documented and implemented or formally disagreed with.

Formal Approval and Review Schedule — The DPIA must conclude with a formal approval decision by senior management. Where processing is approved with conditions, those conditions must be documented and tracked to completion. The review schedule must specify when the DPIA will be reassessed — at minimum before any material change to the processing, after any related breach, and at periodic intervals consistent with ICO guidance.