In any case, if high risk is likely, a DPIA has to be carried out prior to processing (Article 35(1) GDPR). This constitutes a safeguard that ensures that processing involving a high risk cannot happen, unless the risks have been identified and sufficiently mitigated.
As stated above (see What is a DPIA above), a DPIA is a continuous process that provides guidance to the design and implementation of a processing activity. To successfully guide decisions and guarantee compliance with the GDPR, it is evident that “[t]he DPIA should be started as early as is practicable in the design of the processing operation even if some of the processing operations are still unknown. Updating the DPIA throughout the lifecycle [of the] project will ensure that data protection and privacy are considered and will encourage the creation of solutions which promote compliance.”[1] This approach is evidently required by the obligation of data protection by design (Article 25(1) GDPR).
The process of a DPIA is also not completed, once the processing has started. Rather, “[w]here necessary, the controller shall carry out a review to assess if processing is performed in accordance with the [DPIA] at least when there is a change of the risk represented by processing operations.” (Article 35(11) GDPR). There are several factors that may change the risk, including the following:
- The processing activity changes,
- the efficiency of the mitigation measures changes.
In the former case, a change could be caused by a change in the intended usage of the data (new purposes of processing), changes in the scope of data collection and processing, changes in the number of affected person (e.g., due to the success of the activity), a change in the application software (e.g., a new version with additional functionality), a change in the technical infrastructure (e.g., a migration into the cloud), or a change in the legal situation (e.g., a court decision that affects the interpretation of the GDPR).
In the latter case, a change could be caused by the discovery of new vulnerabilities in the mitigation measures (e.g., software vulnerabilities), an increase in threats and capability of attackers (e.g., new methods to re-identify pseudonymous or anonymous data), or an organizational change that threatens the effectiveness of measures (e.g., new staff who is unaware of what can be disclosed).
References
1wp248rev.01, page 14, Section III.D.a), 2nd paragraph, highlighting and text in brackets added by authors. ↑