Article 29 Working Party issues draft guidelines on Data Protection Impact Assessments & high risk processing

DPIAs are mandated for high risk processing in GDPR. However, the WP recommends that they should be seen as a tool for accountability and could be used in somewhat wider situations as well: in the view of the WP, conducting a DPIA will help organisations build compliance (at the outset) and demonstrate compliance at a later date.

When is a DPIA required?

When processing is 'likely to result in a high risk'. Predictably, the WP recommends that, if in doubt: carry one out. 

GDPR includes a list of occasions when DPIAs are required at Art. 35(3). However, the WP emphasises that this list is non-exhaustive. The guidelines include examples of high risk  processing - both of processing included in the GDPR list and other processing not specifically called out in this way.

The WP suggests that if two or more of the above criteria are met, then a DPIA should be carried out. Interestingly, the WP suggests that this means that employee monitoring should be subject to a DPIA – because this involves systematic monitoring and a vulnerable group. Trawling data from public profiles would also trigger a DPIA – because this is evaluation or scorning and on a large scale.

The WP suggests that if a controller concludes that processing does not need a DPIA, because it is not high risk, then this should also be documented.

Supervisory authorities are, of course, able to issue guidance on occasions when DPIAs are, or are not, required. The guidance suggests that this could be similar to the current system of authorisations and exemptions in France – for example, where a whistleblowing hotline, which is strictly in accordance with pre-approved criteria, can be deployed, but where others must be reviewed.

Old or new processing?

The WP considers that DPIAs are only required for processing initiated after GDPR comes into force. However, a similar review would have to be carried out for existing processing if there is a change in risk.

Carrying out the DPIA

Timing: a DPIA should be carried out at an early enough stage that recommendations can be acted on. This may mean a need to re-assess later on. Periodic review is also likely although the WP suggests that they should both be carried out continuously and re-assessed at least every three years or perhaps sooner, if circumstances required.

Who: the data controller is ultimately responsible, although it could seek external assistance. A data processor may be required to help, if it is largely responsible for the processing. The DPO must be involved and must monitor performance of the DPIA. ‘Where appropriate’ the controller should seek the views of data subjects (e.g. via a survey or study). If a controller decides not to do this, it should document its decision.

Although not mentioned in GDPR, others should be involved if they are a relevant stakeholder (e.g. business unit responsible for the processing); and/or relevant expert (lawyer, security expert etc.).

Methodology:  this is iterative and includes:

• Describing the processing
• Assessing necessity and proportionality
• Assessing compliance
• Assessing risks – to the data subject, from their perspective, not risks to the organisation. This could also extend to risks beyond data protection risks (e.g. to freedom of thought and movement)
• Measures to address risk
• Documentation
• Monitoring and review.

Form of DPIA: The WP is not prescriptive - and notes that there are various templates available for this. The guidelines take account of two relevant ISO documents - one on risk management and one on PIAs in an information security context.

Publication: Although the WP notes that GDPR does not require this, it states that publication should be undertaken, either in full or in part, to demonstrate trust and accountability - in particular where members of the public could be impacted by the processing.

Consulting the supervisory authority: is required whenever risks cannot be mitigated and remain high - such as where individuals may encounter significant or even irreversible consequences, or when it is obvious that a risk may occur. In addition, member state law may require that data controllers consult the authority in some cases (e.g. processing in the public interest in relation to public health), irrespective of the level of residual risk.

Other points to note:

Failure to conduct a DPIA at all, or correctly, or to consult a supervisory authority, where required, after having undertaken a DPIA, could all lead to penalties of up to 2% of worldwide turnover.

Organisations often talk about Privacy Impact Assessments, or PIAs: the WP considers that PIAs and DPIAs are essentially the same.

Efficient use of DPIAs: DPIAs can be carried out on a single processing operation. However, the guidelines draw attention to recital 92, which notes that, in some circumstances it may be appropriate for a DPIA to be broader than this. The guidelines suggest that:

• *local authorities could undertake a single DPIA covering use of CCTV in similar ways in multiple areas; or
• *a product manufacturer could make available a DPIA - which would allow a controller using the product to use this to inform its own DPIA (which would then presumably be more efficient and allow the controller to focus on matters specific to its use of the product, rather than aspects which are universally true for everyone deploying the product). 

The WP encourages sector specific DPIA frameworks - which will allow the analysis to be more focussed on the particular risks and mitigations relevant in that context.

Want to know more? There is a list of know-how and sample DPIA frameworks at the end of the guidelines. A list of criteria which DPIAs should meet is also attached to the guidelines. There is nothing surprising here, but it is a useful document.

A copy of the draft guidelines can be found here.