How to Do a GDPR DPIA (Data Protection Impact Assessment)

A DPIA is the documented risk assessment GDPR Article 35 requires before you start high-risk processing. Here is what it is, when it is mandatory, the step-by-step process, and when you must consult your regulator first.

What a DPIA is — and why GDPR requires one

A Data Protection Impact Assessment (DPIA) is a structured, documented process for identifying and minimising the data-protection risks of a processing activity before you begin it. It is set out in Article 35 of the EU General Data Protection Regulation (GDPR), and the equivalent provision carries over into the UK GDPR. In plain terms, a DPIA forces you to think through what could go wrong for the people whose data you are about to process — and to design in safeguards before, not after, the harm occurs.

The DPIA is one of the clearest expressions of GDPR's accountability principle (Article 5(2) and Article 24). You are not just required to handle data lawfully; you must be able to demonstrate that you assessed the risks and made deliberate choices to reduce them. A completed DPIA is exactly that evidence. It is also a living document: you revisit it when the processing, the technology, or the risk picture changes.

Responsibility for the DPIA sits with the data controller — the organisation that decides why and how personal data is processed. Where you have appointed a Data Protection Officer (DPO), Article 35(2) says you must seek their advice on the DPIA, and the DPO monitors how it is carried out. But accountability for the outcome stays with the controller, not the DPO and not a vendor.

When a DPIA is mandatory: the Article 35(3) triggers

The general rule in Article 35(1) is that a DPIA is required whenever a type of processing — in particular one using new technologies — is "likely to result in a high risk to the rights and freedoms of natural persons," taking into account the nature, scope, context and purposes of the processing. "High risk" is the threshold; ordinary, low-risk processing does not require a formal DPIA.

Article 35(3) then names three situations where a DPIA is always required. First, a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person (think automated credit scoring or eligibility decisions). Second, large-scale processing of special categories of data under Article 9 (health, biometric, racial or ethnic, religious, political, sexual-orientation data, and so on) or of criminal-offence data under Article 10. Third, systematic monitoring of a publicly accessible area on a large scale (for example, large-scale CCTV or location tracking in public spaces).

Beyond those three, Article 35(4) requires each supervisory authority to publish a list of processing operations for which a DPIA is mandatory, and Article 35(5) allows them to publish a list of operations that do not require one. Always check the list issued by your lead authority — for instance the Irish DPC, the German authorities, or the UK ICO — because they add specific high-risk activities relevant to their jurisdiction. The European Data Protection Board (EDPB) also publishes nine criteria (such as profiling, automated decision-making, large-scale processing, data matching, and processing of vulnerable individuals); as a widely used rule of thumb, processing that meets two or more of these is usually treated as likely high-risk and warranting a DPIA. When in doubt, doing a DPIA is the defensible choice.

The step-by-step DPIA process

A DPIA follows a repeatable sequence, and Article 35(7) sets the minimum content it must contain. Step one is screening: assess whether the processing is likely to result in high risk. If it clearly is not, record that conclusion and stop; if it is, or you are unsure, proceed to a full DPIA. Documenting the screening decision itself is good practice, because it shows you considered the question.

Step two is to describe the processing systematically: what data you collect, from whom, why, how it flows, how long you keep it, who it is shared with, and the technology involved. Step three is to assess necessity and proportionality — confirming you have a valid lawful basis, that you are collecting only what you need (data minimisation), and that less intrusive alternatives would not achieve the same purpose. Step four is the heart of the DPIA: identify and assess the risks to individuals' rights and freedoms (discrimination, identity theft, financial loss, reputational damage, loss of confidentiality, and similar harms), and rate each by likelihood and severity.

Step five is to identify measures to address those risks — safeguards, security controls, pseudonymisation, retention limits, transparency measures — and record the residual risk that remains after them. Throughout, Article 35(9) says you should seek the views of data subjects or their representatives where appropriate, and Article 35(2) requires you to take the DPO's advice where one is appointed. Step six is the decision and sign-off: an accountable owner accepts the residual risk (if it is acceptable) or escalates it. If high risk remains and you cannot reduce it, you move to prior consultation, covered next.

Prior consultation under Article 36

Article 36 is the step many organisations forget. If your DPIA indicates that the processing would result in a high risk to individuals, and you cannot bring that risk down through mitigation measures, you must consult your supervisory authority before you start the processing. This is prior consultation, and it is a legal obligation — not a courtesy. Crucially, the trigger is high residual risk you cannot mitigate, not merely the fact that a DPIA was required; most DPIAs end with risk reduced to an acceptable level and never reach this stage.

When you consult, Article 36(3) requires you to provide the authority with details including the respective responsibilities of any joint controllers, the purposes and means of the processing, the safeguards you have in place, the DPO's contact details, and the DPIA itself. The authority reviews your plan and, under Article 36(2), provides written advice within up to eight weeks of the request — a period it can extend by a further six weeks for complex processing, pausing the clock while it requests information from you.

The authority can use its corrective powers if it concludes the processing would breach the GDPR, for example by issuing a warning or, in a serious case, ordering you not to proceed. The practical lesson is to design the DPIA early enough that you have time to either engineer the risk down or build the consultation window into your launch timeline. Starting processing first and assessing later defeats the purpose and exposes you to enforcement.

Documenting the DPIA — and where the GDPR pack fits

A DPIA only counts as accountability evidence if it is written down and kept. Your record should capture the systematic description of the processing, the necessity and proportionality assessment, the identified risks with their likelihood and severity, the mitigations, the residual risk, the DPO's advice, any consultation with data subjects, and the dated sign-off by the accountable owner. Keep it alongside your Records of Processing Activities (Article 30) so an assessor can trace a high-risk activity to the DPIA that governs it. Review and update each DPIA when the processing changes materially or at a sensible planned interval.

Building this from a blank page is slow, and inconsistency between assessments is a common audit finding. This is where a documentation toolkit helps honestly. The ComplianceDocs GDPR Compliance Pack for Small Business includes an editable Data Protection Impact Assessment Procedure — alongside a Data Protection Policy, privacy notices, a Data Subject Rights Request procedure, a breach response procedure, and a pre-filled Article 30 Records of Processing workbook — so you start from a structured method and tailor it to your actual processing rather than inventing the format each time.

Be clear about what that toolkit does and does not do. A template gives you the documentation layer: a repeatable DPIA structure and the surrounding policies an assessor expects to see. It does not make your organisation "GDPR compliant," and no document set can. Compliance comes from operating the controls, doing the analysis honestly, recording real risks and real mitigations, and consulting your supervisory authority when Article 36 requires it. The structure speeds the work; the judgement about your specific processing, and the obligation to act on it, remain yours.

Common DPIA mistakes to avoid

The most common mistake is timing: running the DPIA after the system is already live. Article 35 expects the assessment before the processing begins, because its whole purpose is to influence design decisions while they can still be changed. Treat the DPIA as a gate in your project plan, not a compliance write-up you bolt on at the end.

A second mistake is treating the DPIA as a tick-box exercise that records the conclusion you wanted. A credible DPIA names real, specific harms to individuals and rates them honestly; if every risk magically scores "low," an auditor or supervisory authority will not find it persuasive. Related to this is skipping the screening rationale — you should be able to show why you decided a DPIA was or was not needed, not just produce one (or fail to) without explanation.

Finally, organisations often forget that a DPIA is not one-and-done. New processing, a new vendor, a new technology such as an AI model, a change in data flows, or a fresh threat can all change the risk picture and call for a new or updated assessment. Forgetting Article 36 is the costliest version of this: when high risk genuinely cannot be mitigated, prior consultation is mandatory, and proceeding without it is itself a breach. Build review triggers into your process so DPIAs stay current and so the rare high-residual-risk case is escalated rather than quietly shipped.

Frequently asked questions

When is a DPIA legally required under GDPR?

A DPIA is required whenever processing is likely to result in a high risk to individuals' rights and freedoms (Article 35(1)). Article 35(3) makes it mandatory in three cases: systematic and extensive automated evaluation or profiling that drives decisions with legal or similarly significant effects; large-scale processing of special-category data (Article 9) or criminal-offence data (Article 10); and large-scale systematic monitoring of a publicly accessible area. Supervisory authorities also publish lists of operations that always require a DPIA, so check your lead authority's list. As a rule of thumb, processing meeting two or more of the EDPB's nine high-risk criteria usually warrants one.

Who is responsible for carrying out a DPIA?

The data controller is responsible — the organisation that decides why and how personal data is processed. Where a Data Protection Officer is appointed, Article 35(2) requires you to seek their advice on the DPIA, and the DPO monitors how it is performed. However, the DPO advises; they do not own the outcome. Accountability for the assessment and for accepting or escalating the residual risk stays with the controller, and you cannot delegate that responsibility to a processor or vendor.

What is prior consultation under Article 36?

Prior consultation is the step you must take when your DPIA shows a high risk that you cannot reduce through mitigation measures. Article 36 requires you to consult your supervisory authority before starting the processing, providing details including the purposes and means, the safeguards, the DPO's contact details, and the DPIA itself. The authority must give written advice within up to eight weeks, extendable by six weeks for complex cases, and can use corrective powers — including ordering you not to proceed — if it concludes the processing would breach the GDPR. Most DPIAs reduce risk to an acceptable level and never reach this stage.

What must a DPIA actually contain?

Article 35(7) sets the minimum content. A DPIA must include a systematic description of the processing operations and their purposes; an assessment of the necessity and proportionality of the processing relative to those purposes; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks, including safeguards and security controls. In practice you should also record the residual risk after mitigation, the DPO's advice, any consultation with data subjects (Article 35(9)), and a dated sign-off by an accountable owner so the document stands as accountability evidence.

Does the GDPR pack make my organisation GDPR compliant?

No. The ComplianceDocs GDPR Compliance Pack includes an editable DPIA Procedure and the surrounding privacy documents, which gives you a repeatable structure and removes the work of building the format from scratch. But a template is the documentation layer only. GDPR compliance comes from operating the controls, carrying out each DPIA honestly against your real processing, recording genuine risks and mitigations, and consulting your supervisory authority when Article 36 requires it. No document set can make you compliant on its own; it speeds the readiness work, while the analysis and the legal obligations remain yours.

Related guides: GDPR

Toolkits that help

← All articles