Data Protection Impact Assessments can be used to identify and mitigate against any data protection related risks arising from a new project, which may affect your organisation or the individuals it engages with. Read this guide to learn more about how and when to carry out a DPIA.
When your organisation collects, stores or uses personal data, the individuals whose data you are processing are exposed to risks. These risks range from personal data being stolen or inadvertently released and used by criminals to impersonate the individual, to worry being caused to individuals that their data will be used by your organisation for unknown purposes. A Data Protection Impact Assessment (DPIA) describes a process designed to identify risks arising out of the processing of personal data and to minimise these risks as far and as early as possible. DPIAs are important tools for negating risk, and for demonstrating compliance with the GDPR.
This document assumes that a DPIA will be conducted for a defined project, rather than for an organisation’s operations as a whole. A particular function of your organisation, or a programme of changes to your organisation’s operations as a whole, may be viewed as a project.
Conducting a DPIA will improve awareness in your organisation of the data protection risks associated with a project. This will help to improve the design of your project and enhance your communication about data privacy risks with relevant stakeholders. Some of the benefits of conducting a DPIA are as follows:
Data Protection by design means embedding data privacy features and data privacy enhancing technologies directly into the design of projects at an early stage. This will help to ensure better and more cost-effective protection for individual data privacy.
Data Protection by default means that service settings must be automatically data protection friendly.
While long recommended as good practice, both of these principles are enshrined in law under the GDPR (Article 25).
Under the GDPR, a DPIA is mandatory where data processing “is likely to result in a high risk to the rights and freedoms of natural persons.” This is particularly relevant when a new data processing technology is being introduced. In cases where it is not clear whether a DPIA is strictly mandatory, carrying out a DPIA is still good practice and a useful tool to help data controllers comply with data protection law.
The GDPR provides some non-exhaustive examples of when data processing is “likely to result in high risks”:
The Article 29 Working Party, consisting of the representatives from each data protection authority in the EU, has published guidelines on DPIAs and whether processing is likely to result in a high risk for the purposes of the GDPR. The guidelines were recently subject to public consultation and it is anticipated that the final text will be adopted at the next meeting of the Working Party. The guidelines are available at http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083. In assessing whether processing is likely to result in a high risk the Article 29 Working Party has set forth the following criteria to consider:
The Working Party considers that the more criteria are met by the processing, the more likely it is to present a high risk to the rights and freedoms of data subjects, and therefore to require a DPIA. As a rule of thumb, a processing operation meeting less than two criteria may not require a DPIA due to the lower level of risk, and processing operations which meet at least two of these criteria will require a DPIA. If the controller believes that a processing operation which meets at least two of these criteria is not likely to be high risk, the controller should thoroughly document the reasons for not carrying out a DPIA.
A DPIA is generally not required in the following cases:
The GDPR is effective from the 25th May 2018, and DPIAs are legally mandatory only for processing operations that are initiated after this date. Nevertheless, the Article 29 Working Party strongly recommends carrying out DPIAs for all high risk operations prior to this date. Indeed a DPIA can be a powerful tool in ensuring that any operations commencing now will not leave you at risk of non-compliance once the law changes on the 25th May 2018, and save your organisation from operational disruption by allowing you to future proof new projects against the GDPR at an early stage.
Additionally, new DPIAs or reviews of DPIAs for existing processing that commenced before the 25th May 2018 may be required after that date in the following circumstances:
As a matter of good practice, the Article 29 Working Party recommends that all DPIAs should be re-assessed after 3 years, or sooner if circumstances have changed quickly.
The DPIA should be carried out “prior to the processing” (GDPR Articles 35(1) and 35(10), recitals 90 and 93). It is generally good practice to carry out a DPIA as early as practical in the design of the processing operation. It may not be possible to conduct a DPIA at the very inception of the project, as project goals and some understanding of how the project will operate must be identified before it will be possible to assess the data protection risks involved.
For some projects the DPIA may need to be a continuous process, and be updated as the project moves forward. The fact that a DPIA may need to be updated once processing has actually started is not a valid reason for postponing or not carrying out a DPIA.
The Data Controller is responsible for ensuring the DPIA is carried out. It may be delegated to someone else, inside or outside the organisation, but the Data Controller is ultimately accountable.
The DPIA should be driven by people with appropriate expertise and knowledge of the project in question, normally the project team. If your organisation does not possess sufficient expertise and experience internally, or if a particular project is likely to hold a very high level of risk or affect a very large number of people, you may consider bringing in external specialists to consult on or to carry out the DPIA.
A wide internal consultation process can benefit the DPIA, as some data protection risks will only be apparent to individuals working on specific aspects of the project. It will also allow you to gain feedback from those whose work will be affected by the project after implementation, such as engineers, designers and developers, who will have a practical knowledge of the operations. Involving your organisations Public Relations team will allow for effective communication of the DPIA’s outcomes to external stakeholders.
Under the GDPR (Article 35), it is necessary for any Data Controller with a designated Data Protection Officer (DPO) to seek the advice of the DPO. This advice and the decisions taken should be documented as a part of the DPIA process. If a Data Processor is involved in the processing, the
The Data Controller is bound to “seek the views of data subjects or their representatives” (Article 35(9)), “where appropriate” in carrying out the DPIA. In some cases, the data subjects may be people within the organisation. Seeking the views of Data Subjects will allow the Data Controller to understand the concerns of those who may be affected, and to improve transparency by making individuals aware of how their information will be used.
The views of Data Subjects can be sought through a variety of means, depending on the context. Staff could be consulted through a trade union; customers could be consulted by means of a survey. If the Data Controller’s final decision differs from the views of Data Subjects, the reasons should be recorded as a part of the DPIA. If the Data Controller does not feel it appropriate to seek the views of Data Subjects, the justification for this should be documented.
The GDPR sets out the minimum features of a DPIA (Article 35(7), and recitals 84 and 90):
The GDPR presents a broad, generic framework for designing and carrying out a DPIA. This allows for scalability, so even the smallest Data Controllers can design and implement a DPIA; as well as for flexibility, so the Data Controller can determine the precise structure and form of the DPIA, allowing it to fit with existing working practices.
The GDPR does not prescribe the exact process for carrying out a DPIA beyond the minimum features outlined above, allowing for flexibility and scalability in line with your organisation’s needs. Although there is no one prescribed approach to take, the following steps can guide you through the process:
You can use the steps described in the above section “How do I know if a DPIA is required” to assess if you need to perform a DPIA. This should take place as early as practicable in the lifecycle of the project. You will also need to identify the resources needed, the individuals who will be involved, and the timeframe of the DPIA process.
As the nature and operational implications for data privacy of a project may not be apparent at an early stage in the planning, the DPIA may need to be an ongoing process, and may need to be reviewed or repeated as the project moves forward.
At an early point in the DPIA project, you should identify how it is intended to collect, store, use and delete personal information as part of the project. This exercise should also identify what kinds of information will be used as part of the project and who will have access to the information.
The aim of this step is to get an early understanding of how information will be used as part of a project at each step along the process. This is crucial to being able to recognise the data privacy risks which may be posed by a project and to identifying what means might be used to mitigate those risks.
You should consider if any new personal information will be generated by the project, and include it in your record of this stage. For example, a project involving the processing of psychometric tests might take one type of personal information (the answers to psychometric test questions) and process it to another (a psychometric profile). This new type of personal information is different in character, and so recording it separately in your map of information flows will help to ensure that its special characteristics are taken account of later in the DPIA process.
This part of the DPIA will often mirror other elements of your project design process, such as a general scoping exercise to identify how the project will be carried out, and can be integrated with such a scoping exercise. Paying attention in the design of a project to how information will be used as part of the project may also yield efficiency benefits for your organisation by assisting you in streamlining processes for handling information.
At this stage of the DPIA process, you should consult with internal stakeholders with a view to identifying the technical aspects of information collection, storage and processing, and how the different elements of the project will fit together in operation. You may also want to consult with external partners, who may be engaged by your organisation as a data processor, or to whom information might be disclosed as part of a project.
This exercise should be documented using whatever means are most suitable for your organisation and the project concerned. Using visual aids, such as flow charts, to document how information will be used as part of a project can assist in identifying potential data privacy risks. This may also help with internal communication by better allowing the project team and others in your organisation to understand the design of the project.
This stage involves examining the project design to assess what data protection issues arise in the project, and to identify any risks it may expose individuals to, as well as any data protection-related risks that the project might create for your organisation.
There are a range of different ways that an individual’s data privacy can be compromised or put at risk by a new project. The types of risk range from the risk of causing distress, upset or inconvenience to risks of financial loss or physical harm. There are equally as many kinds of data privacy-related risks to organisations, related to compliance issues and commercial factors. Breaches of the GDPR, such as excessive data processing or data breaches, can lead to significant penalties, as well as causing reputational damage to your organisation.
This step should build upon work done at previous stages of the DPIA. The responses to the criteria laid out in the above section “How do I know if a DPIA should be conducted” should act as a guide to the risks which may be present. The map of information flows generated in stage 2 may help you to identify particular weak spots, where general data privacy risks are likely to be particularly acute, or which might give rise to specific risks.
For public sector bodies contemplating data processing measures that limit the EU fundamental right to data protection under Article 8 of the EU Charter of Fundamental Rights, a detailed analysis of the ‘necessity’ of the measure must be undertaken. Guidance published by the European Data Protection Supervisor will assist public sector policy makers in conducting the necessary analysis. The EDPS guidance is available at https://edps.europa.eu/sites/edp/files/publication/17-06-01_necessity_toolkit_final_en_0.pdf
Examples of the types of risks that you should be alert for at this stage of the DPIA process are outlined below. You should also examine sector-specific guidance which may be provided by regulators or industry groups in your area of operations, which can highlight types of risk which may be relevant for your organisation or project.
You should take note of the magnitude of the risks identified, having regard to both the likelihood of a risk manifesting itself, and its impact. In assessing the severity of the risk, it is important to bear in mind the sensitivity of the personal data to be processed as part of the project, the number of people likely to be affected by any of the risks identified, and how they might be affected.
You should keep a record of all risks identified at this stage. This will assist later on in the DPIA process in creating solutions to avoid or reduce those risks. Record keeping may be especially important in the event of an investigation or audit by the DPC. Good record keeping may help to demonstrate how your organisation complied with its obligations under the GDPR.
This identification exercise should be carried out relatively early in the project design, as the sooner that data privacy risks can be identified, the easier and cheaper it will be to mitigate them. However, it is not a once-and-for-all exercise; you should keep the project design under review throughout the DPIA process to monitor the emergence of any new risks, which may occur by reason of a change to the design or scope of the project, and to assist in assessing which risk reduction techniques work.
Your organisation can choose the risk management approach that best suits your existing project management process. The same tools you use for identifying other regulatory or commercial risks as part of your project management process can be used to assess the data protection risks involved in a project. The key point is to ensure that a methodological approach to identifying risks is adopted, and that records are kept of this process, and of all the risks identified. Your organisation may wish to maintain a data protection risk register to describe the risks associated with a project and assess their likelihood and impact. You can then go back to the register in the event of any changes to the project, to make note of any steps taken to mitigate risk, or any additional risks that emerge. This can be incorporated into an existing risk register if one exists for the project. Small scale projects may adopt a relatively informal approach to risk. You can still use a data protection risk register in such cases, but with the entries reflecting the less formal approach adopted.
A Data Protection risk register is a master document that is used to record information about data protection risks which have been identified in relation to a particular project, as well as an analysis of risk severity and evaluations of the possible solutions to be applied.
The data protection risk register should be updated as the project progresses, to reflect any solutions or new risks which have been identified.
Your organisation may face risks of prosecution, significant financial penalties, or reputational damage if you fail to comply with the GDPR. Individuals affected by a breach of the GDPR can seek compensation for both material and non-material damage.
Failure to carry out a DPIA where appropriate is itself a breach of the legislation, as well as a lost opportunity to identify and mitigate against the future compliance risks a new project may bring.
This stage follows on from the identification of data protection risks at stage 3, with the aim of minimising the data privacy risk associated with the project, insofar as possible. In almost all cases, it will not be possible to eliminate data protection risks completely, but the aim of this stage is to balance those risks against the aims of the project, to ensure that any risks that are accepted are proportionate to the outcomes of the project. However, under GDPR, if there are remaining high risks, then you will need to consult with the Data Protection Commissioner, as described below.
Data Protection solutions are steps which may be taken to reduce the likelihood or severity of data privacy risks being realised.
During this stage, you should try to identify “data protection solutions” to reduce the impact of the project on data protection. You should do this by looking at each of the risks identified as part of the previous stage in the DPIA process and seeking to address it individually, or as part of a privacy solution which may address a number of risks together.
In some cases, data protection solutions may be able to eliminate some types of risk, for example by abandoning unnecessary parts of a project which create unique risks. In others, data protection solutions may simply mitigate against risk or reduce the significance of data breaches, for example by adopting pseudonymisation to reduce the risk of identification of data subjects. The nature of these solutions will depend on the types of risk that have been identified, and the aims of the project. You should keep a full record of the process, to document any data protection solutions which have been identified, and which risks they were intended to address, as well as any risks which have been accepted. This can be done in a data protection risks register created under step 3.
This step involves conducting a balancing exercise between the benefits to individuals and your organisation from the project, and the data protection and related risks to those individuals and your organisation. Equally, in assessing whether a particular data protection solution should be pursued, it is necessary to weigh up the costs and benefits of each solution. For example, anonymising data may help to prevent the risk of data relating to an identifiable person being accidentally disclosed to a third party, but it is likely to cost the organisation money to put an anonymisation system in place, and it may prevent some of the goals of the project from being realised (if those goals depend on processing information about identified individuals).
Every project will have its own unique circumstances and risk profile, so there is no “one size fits all” set of data privacy solutions which may be adopted. However, the following are examples of data protection solutions, some of which may be applied in a range of different scenarios:
In most cases, there are some data protection risks which cannot be eliminated or reduced. These risks can be accepted if they are proportionate to the outcomes that will be achieved by proceeding with the project notwithstanding the risk. Any decisions to accept data protection risks should be recorded in the data protection risk register, or otherwise in accordance with your project management process.
At this stage, you should also ensure that the project will be in compliance with data protection laws. In particular, you should consider whether the project complies with the data protection principles, and ensuring that you have a good legal basis for processing personal data.
The primary aim of conducting a DPIA is to identify and minimise the data protection risks involved in a project. However, as has been emphasised throughout this guide, keeping a record of all steps taken as part of the DPIA will help to ensure that the process is completed thoroughly, and to reassure stakeholders that all data protection risks have been considered. This written record should also form that basis of putting into effect the data protection solutions which have been identified, and can be used to check off the implementation of each solution.
There is no requirement to produce a final DPIA report but it is good practice to do so. This report should bring together, in summary form, the record keeping from each stage of the DPIA process and note the conclusions from each step of the process. It should also include an overview of the project, explaining why it was undertaken and how it will impact on data protection. It should describe the process adopted in conducting the DPIA, and set out the data protection risks and solutions which were identified as part of the process. Your organisation may decide to publish the DPIA report or a summary of it. The decision of whether or not to publish the report will probably have a bearing on how much detailed information is put into the report, as it may not be appropriate to publish commercially sensitive information or information containing too much detail about security vulnerabilities which have been identified.
A DPIA does not necessarily require a formal signing-off process, but your organisation may require it, particularly if it recommends significant changes to the nature of a project, or if it recommends accepting significant risks.
If the data privacy risks which have been identified are not capable of mitigation consistent with the goals of a project, and it would not be proportionate to accept them, this stage should be used for re-evaluating the viability of the project. In such circumstances, an organisation may decide to either change the goals of a project to allow for mitigation of data protection risks, or abandon the project altogether.
Once it has been signed off, it is necessary to put the findings of the DPIA into action by integrating any necessary changes into the plans for the project. The earlier the DPIA can be completed, the easier it will be to give effect to the data privacy solutions, but as the DPIA will not normally be completed until the project has already progressed somewhat in the planning stages, it will normally be necessary to adjust plans to give effect to the data privacy solutions identified.
As part of the implementation of the DPIA, you should keep data protection issues under review. In particular, you should assess whether the data protection solutions implemented are having the intended effect of mitigating data protection risks. Additionally, if the project aims change or expand over its lifetime, it may be necessary to assess whether a further DPIA is required to assess the effect of the changes on the data protection risks identified. Such a review can be built into your organisation’s existing procedures.
If, during the DPIA process, the Data Controller has identified and taken measures to mitigate any risks to personal data, it is not necessary to consult with the DPC before proceeding with the project.
If the DPIA suggests that any identified risks cannot be managed and the residual risk remains high, you must consult with the Data Protection Commissioner before moving forward with the project.
Regardless of whether or not consultation with the DPC is required, your obligations of retaining a record of the DPIA and updating the DPIA in due course remain.
Even if consultation is not required, the DPIA may be reviewed by the DPC at a later date in the event of an audit or investigation arising from your use of personal data.
It is not legally mandatory to publish the DPIA. However, there are a number of benefits to doing so. Publishing the DPIA can help to foster trust in your handling of personal data, and demonstrate accountability and transparency, particularly where members of the public are affected. This may be especially beneficial for DPIAs carried out by public bodies.
The published DPIA does not need to contain the whole assessment, especially when the DPIA could present information concerning security risks or commercially sensitive information. It could even consist of just a summary of the DPIA’s main findings.
Data Protection Commissioner
June 2017
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.