A Data Protection Impact Assessment (DPIA) is a legal requirement under UK GDPR for high-risk processing. This guide walks you through every step — from deciding whether you need one to documenting your outcome and knowing when to consult the ICO.
A DPIA is mandatory under UK GDPR Article 35 for processing that is "likely to result in a high risk" to individuals. The ICO provides a list of processing types that automatically require a DPIA. For other types of processing, a screening question helps you decide.
Systematic and extensive profiling or automated decision-making with significant effects. Large-scale processing of special category data (health, biometrics, ethnicity, religion). Systematic monitoring of publicly accessible areas (CCTV, tracking technologies).
Innovative technology use, matching or combining datasets, processing data of vulnerable individuals (children, employees), data transferred outside the UK, or processing where individuals cannot easily object.
If you can answer "yes" to two or more of the ICO's nine screening questions, a DPIA is strongly recommended even if not strictly mandatory.
Low-volume, low-sensitivity processing with no special category data and no profiling or automated decision-making typically does not require a DPIA — but document your reasoning.
What they look for
Document your screening decision — not just your conclusion. If you decide a DPIA is not required, record why: which ICO screening criteria you considered, how you answered each one, and who made the decision. If the ICO investigates and questions why you did not conduct a DPIA, a documented screening decision is your evidence that the choice was made deliberately.
The first substantive section of a DPIA is a structured description of what you are planning to do. This is not a brief summary — it needs enough detail that an auditor or the ICO could understand the full scope of the processing without asking follow-up questions.
What data are you collecting, how, and what will you do with it? Include any profiling, enrichment, or automated decisions.
Volume and variety of data, range of individuals affected, geographical extent, and how long the data will be retained.
What is the relationship between your organisation and the individuals whose data is being processed? Do they expect this processing? Is it a novel use of data they provided for a different purpose?
What is the specific, explicit, and legitimate purpose? What is the lawful basis under Article 6 (and Article 9 if special category data)?
What they look for
The description section of your DPIA must be detailed enough for someone unfamiliar with the project to understand the full processing picture. A one-paragraph description is almost never sufficient. Auditors expect to read the description and understand the nature, scope, context, and purpose without follow-up questions.
Before assessing risk, the DPIA must demonstrate that the processing is necessary for its purpose and proportionate — that you could not achieve the same outcome with less privacy-intrusive means. This is a requirement under Article 35(7)(b).
Confirm the basis under Article 6 (legitimate interests, contractual necessity, legal obligation, vital interests, public task, or consent). If relying on legitimate interests, complete a Legitimate Interests Assessment (LIA) alongside the DPIA.
Are you collecting only the minimum data necessary? Could you achieve the purpose with pseudonymised or aggregated data rather than identified personal data?
Is the retention period the shortest that meets the purpose? Does the processing stop when no longer necessary?
Have you considered how individuals can exercise their rights (access, erasure, objection) in relation to this specific processing?
What they look for
Necessity and proportionality must be demonstrated, not asserted. 'We need this data to provide the service' is an assertion. 'We evaluated pseudonymised alternatives and concluded they would not achieve X because Y' is a demonstration. If your DPIA just states that processing is necessary, it will not survive challenge.
This is the core of the DPIA. For each risk, assess the likelihood it will materialise and the severity of the impact on individuals. Risk is assessed from the perspective of the people whose data is being processed — not the organisation.
Inability to exercise rights. Discrimination. Financial loss. Reputational damage. Physical harm. Loss of confidentiality. Social disadvantage. Re-identification of pseudonymised data.
How likely is it that this harm will actually occur given current controls? Score 1 (remote) to 5 (near certain).
How serious would the impact be for the individual affected? Score 1 (minor inconvenience) to 5 (severe and irreversible harm).
Start with the inherent risk (before controls). Then identify what controls you will put in place and score the residual risk after those controls. If residual risk remains high, escalation or ICO consultation may be required.
What they look for
Risk scoring must be assessed from the individuals' perspective, not the organisation's. A risk that causes reputational damage to your organisation is not a DPIA risk — a risk that causes financial loss or discrimination to individuals whose data you process is. Your risk register should name specific scenarios and score them honestly, not conservatively.
For every risk identified, document what technical and organisational measures you will implement to reduce it. These become action items that must be completed before or during the processing activity.
Encryption at rest and in transit, pseudonymisation, access controls, data minimisation in system design, automated deletion, audit logging.
Staff training, data sharing agreements, vendor due diligence, privacy notices, consent management, documented procedures for breach response.
Each risk and its mitigation must have a named owner who is accountable for implementing and monitoring the control.
Where residual risk cannot be reduced to an acceptable level, this must be escalated to the DPO or senior leadership for acceptance or rejection of the processing.
What they look for
Each mitigation must have a named owner and a completion date. Mitigations that are listed but not implemented by the time processing starts are not controls — they are intentions. Auditors will check whether planned mitigations were actually implemented before the activity began.
Article 35(2) requires that you seek the advice of your Data Protection Officer where one is designated. The DPO's advice — and whether it was followed — must be recorded in the DPIA. Consulting individuals affected by the processing (or their representatives) is also good practice and sometimes required.
If you have a designated DPO (mandatory for public authorities, and organisations whose core activities involve large-scale monitoring or special category processing), their review of the DPIA is required. Record their advice and your response to it.
If the processing involves a data processor, they must provide all necessary information to conduct the DPIA. Check your processor agreements.
Where feasible, seek the views of individuals affected by or their representatives. Document why it was or was not done.
What they look for
If you have a DPO, their involvement must be recorded in the DPIA itself — their name, their advice, and whether you followed it. If you did not follow the DPO's advice, you must document why. A DPIA that does not show DPO involvement where a DPO is required is incomplete and will fail an ICO review.
The DPIA must include a documented decision: proceed, proceed with additional controls, or do not proceed. If the residual risk remains high and cannot be mitigated, you must consult the ICO under Article 36 before commencing the processing. The ICO has 8 weeks (extendable to 14) to respond.
Prior consultation is required when the DPIA identifies a high residual risk that cannot be adequately mitigated through technical or organisational measures.
The full DPIA, the controller's contact details, the DPO's contact details, the purposes of the processing, and any other relevant information.
A DPIA is not a one-time exercise. Review it when the processing changes, when a data breach occurs, or at defined intervals. Record the review date and outcome.
What they look for
The decision to proceed (or not) must be signed off by a named individual with appropriate authority. If you need prior ICO consultation, you must submit the DPIA before starting the processing — not after. Starting processing before completing required prior consultation is a serious breach and grounds for enforcement action.
Where people go wrong
Conducting a DPIA after starting the processing activity
A DPIA is a prior assessment — it must be completed before processing begins. A retrospective DPIA has limited value and will not be treated as compliance with Article 35 by the ICO.
Completing a DPIA without involving the DPO where one is designated
Where a DPO is designated, consulting them on the DPIA is a legal requirement under Article 35(2). A DPIA completed without DPO involvement or with no record of DPO advice is legally deficient.
Listing mitigations that are never implemented
A DPIA that identifies mitigations but does not track whether they were implemented is not complete. The ICO will ask whether the mitigations exist in practice, not just on paper.
Not updating the DPIA when the processing changes
A DPIA covers the processing as described. If the processing changes materially — new data categories, new automated decisions, new recipients — the DPIA must be updated. An outdated DPIA provides no protection for the changed processing.
When is a DPIA mandatory under UK GDPR?
A DPIA is mandatory when processing is likely to result in a high risk to individuals. The ICO specifies certain types of processing that always require a DPIA: large-scale processing of special category data, systematic profiling with significant effects, and systematic monitoring of publicly accessible areas. If two or more of the ICO's nine screening criteria apply to your processing, a DPIA is strongly recommended even if not strictly mandatory.
Who signs off a DPIA?
The data controller (your organisation) is ultimately responsible. Where a DPO is designated, they must be consulted and their advice recorded. Where the DPO's advice is not followed, the reasons must be documented. Senior management sign-off is good practice for any processing that reaches the stage of a DPIA.
What if we identify a high risk we cannot mitigate?
If the residual risk after all planned mitigations remains high, you must consult the ICO under Article 36 before starting the processing. The ICO has 8 weeks (extendable to 14 weeks in complex cases) to respond. Starting high-risk processing without prior ICO consultation where required is a serious breach of UK GDPR.
How often should DPIAs be reviewed?
A DPIA should be reviewed whenever the processing changes materially, following a data breach involving the processing, or when the risks to individuals change. Even without a trigger event, reviewing active DPIAs annually is good practice. The review date and outcome should be documented within the DPIA itself.
Can a DPIA cover multiple related processing activities?
Yes — where several related processing activities share similar risks (for example, a new product that involves multiple data flows), a single DPIA can cover them all, provided the scope clearly describes each activity. Separate DPIAs for each activity are also acceptable and may be clearer for audit purposes.
Fortify's free GDPR readiness check identifies gaps in your data protection programme — including whether you have the right processes in place for DPIAs and data subject rights.