5 common mistakes made with DPIAs

With the GDPR, a DPIA, or ‘Data Protection Impact Assessment’ has moved from being a good practice recommendation to being a mandatory activity for some kinds of personal data processing. The purpose of a DPIA is to identify potential risks to data subjects’ rights and freedoms before the processing begins, so that appropriate measures can be put into place to manage those risks.

A DPIA should not be confused with the requirement for ‘data protection by design and by default’ (DPbD2) – these are two different things, although they support and depend on each other. A DPIA is a particular process which is only required where processing is likely to have a high risk of impacting the rights and freedoms of data subjects, whereas DPbD2  is an attitude that must be adopted whenever and wherever personal data is being processed.

Since DPIAs are new to many organisations, it can be difficult to determine the ‘right’ way to go about carrying them out. There is no obligation to use a specific form, template or methodology – what matters is that the processing is examined, risks are identified and outputs from the DPIA are acted upon. Although there is no single ‘right’ way to conduct a DPIA, our experience as data protection specialists has provided us with some insight into some of the ‘wrong’ ways to go about it. We hope that by explaining these common ‘gotchas’, we can help your organisation to understand and make the best use of DPIAs.

The Mistakes

1. Starting too late

A DPIA should begin before you actually start the processing – preferably even before the specific procedures and operations are designed or any technology is purchased.

Doing a DPIA after the processing has already started may leave you with some difficult choices if you discover fundamental data protection problems when it’s already up and running. You may be left in the awkward situation of having to work out whether it’s least harmful to continue processing unlawfully, to retro-fit the necessary privacy safeguards with additional complexity, time and expense, or to cease the processing entirely and re-design it with privacy as a critical consideration. The old phrase ‘a stitch in time saves nine’ applies here.

By starting the DPIA process well in advance of the processing, you will be in a position to advise on safeguards, risks and options at a time when they can be designed in to the processing activity with minimum friction, saving you time and money and enabling you to demonstrate your compliance with the requirement for ‘data protection by design and by default’.

2. Tickbox thinking

Even if a DPIA is begun early in the project; unless it is an objective, critical examination of the privacy risks associated with ‘nature, scope and context’ of the processing, it will be of limited value – perhaps even giving a false sense of assurance to the organisation. Some degree of adversarial thinking is needed, putting the necessity of the processing, the selection of data, the organisational capability to carry out the processing in a compliant way, and the range of potential consequences for the data subjects, ‘on trial’.

If your organisation’s people are treating a DPIA as a form-filling exercise, or a gesture towards compliance, rather than the starting-point for essential design decisions, then it is likely that sooner or later, problems will arise – whether those problems are unwarranted impacts to individuals, damage to your organisation’s reputation, or regulatory action.

3. Leaving it all to the DPO

A Data Protection Officer (or the person responsible for overseeing data protection in the organisation) is a critical contributor to the DPIA, but should not be the sole contributor. Ideally, the information about the ‘nature, scope and context’ of the processing would be supplied by the business unit who are intending to carry out the processing, with the analysis of risks, consequences and options performed by the DPO. The management of those risks and the implementation of mitigating controls are then the responsibility of that business unit and so it is essential that they have a thorough understanding of them.

This means that the DPIA process needs to be a collaborative one, involving all stakeholders. A RACI (Responsible, Accountable, Consulted, Informed) matrix should be included at the start of any DPIA to ensure that the DPO doesn’t end up as a lone voice howling into the void. Article 35(9) of the GDPR recommends that a representative sample of data subjects are invited to contribute their views on the proposed processing. While doing so may increase the workload required to produce a DPIA, the perspectives and concerns of data subjects are critical factors for assessment of risk, ensuring fairness and transparency.

4. Fire-and-forget

As a project or programme develops, inevitably there will be changes along the way. A DPIA needs to keep pace with these changes, considering the effect on data protection risks at each stage, as well as monitoring the implementation of the safeguards identified and agreed along the way.

The DPIA should therefore be more than a one-time activity which is conducted in the beginning then set in stone forever more – at the time of initial assessment, there may be unknowns or decisions which have not yet been taken and risks which have not yet been identified. You should include monitoring checkpoints at critical phases of the work and updating the DPIA all the way through from planning to business-as-usual, only ‘signing off’ on the DPIA when the processing begins.

In addition, Article 35(11) acknowledges that processing may evolve over time and lead to changes in the risk profile. Because of this, any changes to the processing need to be risk-assessed from a data protection perspective and the DPIA will need to be revisited if the changes in risk are significant in their potential impact to the data subjects.

5. Treating paperwork as separate to reality.

The accountability principle of the GDPR requires organisations to maintain evidence of their compliance with data protection law and the effectiveness of their measures. In order to meet the accountability principle, records and documentation need to be a true and honest reflection of the practices of the organisation. Documentation of a ‘perfect’ data protection regime is of no use if it diverges from reality – in fact, it introduces a false sense of assurance and prevents risks from being identified and managed effectively; as well as failing to fulfil its fundamental purpose – as evidence that the organisation is doing things in the way that the law requires.

A DPIA must therefore be considered a critical business record, and must be identifiable, locatable, retrievable and reliable.


Protecture subscribers have access to our decision support tool ‘Do I need to do a DPIA’, the option to engage our data protection specialists to deliver workshops for your staff on DPIAs, and access to our Helpline, for direct advice on specific data protection questions.

If you have feedback for us about this privacy notice, please let us know using the Contact Form