GDPR accelerator - DPIA Lite
Ardi Kolah BA (Hons), LL.M, CIPP/E, CIPM, FIP
Previously Senior Global Privacy Specialist, Global DPO Office, Dentons and Global DPO, Cohen Veterans Bioscience (New York)
Last week I had the honour of speaking at the IAPP Europe Data Protection Congress 2016 in Brussels that was the biggest gathering of data protection professionals to date on mainland Europe with over 1100 delegates drawn from across Europe, US and the Far East.
My short talk was about sizing the risk and the GDPR accelerator ‘DPIA Lite’ that was devised by our team led by Martin Hickley, Associate, Henley Business School and Director of Data Protection, GO DPO?.
A significant aspect of the EU General Data Protection Regulation (GDPR) is demonstrating and verifying compliance – making it evident to the Supervisory Authority that the organisation is meeting its obligations under the EU Regulation.
There are three key ways in which an organisation can demonstrate that it's compliant with the GDPR:
- Data Protection Impact Assessment (DPIA) - this is a tool designed to enable organisations to work out the risks that are inherent in proposed personal data processing activities before those activities commence. This, in turn, enables organisations to address and mitigate those risks to the Data Subject before the personal data processing begins.
- Appointment of a Data Protection Officer (DPO) - this is a senior manager that’s formally tasked with ensuring that the organisation is aware and complies with the GDPR and its other data protection responsibilities.
- Codes of Conduct - organisations within the same industry, business sector or profession or engaging in similar types of personal data processing are likely to encounter similar data protection issues. Codes of Conduct provide such organisations with useful guidance on industry-standard approaches to these issues. Compliance with a Code of Conduct may provide evidence of compliance with the GDPR and carries the same force as the GDPR.
Risk management has for a long time been a critical tool for complying with data protection laws by ensuring that data is processed appropriately and individual fundamental rights and interests are protected effectively. However, these efforts have often been applied informally and in an unstructured way. In practice, they often failed to take effective advantage of many principles and tools of risk management that are widely accepted in other areas.
The Data Protection Impact Assessment (DPIA)
A full-blown DPIA is the core tool used by the Data Controller to comply with the Accountability Principle (Art.5(2), GDPR) that demonstrates in one place where and how the Data Controller complies with GDPR.
DPIA (Art.35, GDPR) must be conducted when specific (high) risks occur to the rights and freedoms of Data Subjects. Risk assessment and mitigation is required as well as advice from the Supervisory Authority.
Some organisations will be familiar with the concept of an Impact Assessment from their experiences under the previous Data Protection Directive 95/46/EC, but many won’t. In essence, an Impact Assessment is a step-by-step review of the relevant processing activity. It’s designed to examine each stage of a processing activity and help an organisation to ensure that it has identified and addressed all of the risks involved in that activity before it commences personal data processing.
In the opinion of the Article 29 Working Party (WP29): ‘A PIA is a tool designed to promote ‘privacy by design’, better information to individuals as well transparency and dialogue with competent authorities.’ Under Art.30, GDPR the Data Controller is also required to complete a record of processing activities. The previous PIA is different from a DPIA in a significant way – the DPIA is a risk-based approach to sizing the risk.
In summary, a DPIA is:
- A systematic description of the envisaged personal data processing operations and the purposes of the processing, including (where applicable) the legitimate interest pursued by the Data Controller.
- An assessment of the necessity and proportionality of the personal data processing operations in relation to the purposes.
- An assessment of the risks to the rights and freedoms of Data Subject.
- The organisational and technical measures to secure the personal data and mitigate the absolute risk to an acceptable risk.
The Data Controller must seek the advice of the Data Protection Officer (DPO) where such a person must be appointed under the GDPR. This is particularly required in situations that involve:
- Automated processing/new technologies are deployed
- Profiling of Data Subjects
- Creation of legal effects
- High risk to the rights and freedoms of Data Subjects
- Processing of large scale categories of sensitive data (special data)
- Data that relates to criminal offences or convictions
- Monitoring of Data Subjects on a large scale.
In addition, the DPO must conduct a post-implementation review when the risk profile of the organisation changes, for example, with the introduction of new technologies or products and services.
The DPIA isn’t a quick process and could take as long as six months to complete, depending on the nature of the organisation and the type of personal data processing that’s being undertaken. It can suck up a lot of management time and resources and increase compliance costs at a time when there’s much to be done right now in the current transition period that runs out in May 2018.
There are two fundamental questions that the DPIA must answer conclusively to the satisfaction of the Board:
Q1: Have all material risks been identified?
An organisation can only demonstrate it complies with the GDPR if it has identified all material risks that arise in connection with its personal data processing activities.
Q2:Have all appropriate steps been taken to address those risks?
In relation to each of those personal data processing risks, the Data Controller/Data Processor will need to keep a record of the steps that were taken to resolve or mitigate any danger to the rights and freedoms of the Data Subject.
Under Art.35(7), GDPR the DPIA must cover the following assessments:
Prior consultation with the Supervisory Authority
Under Art. 36 (1), GDPR, the Data Controller shall consult the Supervisory Authority prior to processing where a DPIA under Art.35 indicates that the processing would result in a high risk in the absence of measures taken by the Data Controller to mitigate that risk.
Recital 84, GDPR says that the Data Controller should consult the Supervisory Authority prior to such processing taking place that’s high risk and can’t be mitigated by appropriate measures.
However, this is problematic:
? can’t see the Data Controller going ahead with personal data processing because the DPIA shows it can't mitigate the high risk to the Data Subject in the absence of appropriate measures!
? appropriateness is defined by availability of technology and cost reasonableness and this will require documentation!
Why organisations need to conduct a DPIA Lite
The DPIA as laid out in the GDPR doesn’t lend itself to the environment of today's rapid systems development. Many technological and organisational developments can’t be predicted with any accuracy or indeed what effects (if any) there will be on the rights and freedoms of the Data Subject.
Our suggested approach that will mitigate the risk is to conduct a DPIA Lite and then extend this to a full DPIA when the decision has been made to use that technology.
Template for DPIA Lite
- Executive Summary
This describes the key points of the DPIA and should cover:
- The absolute risk to the personal data processed.
- The technical and organisational measures to manage the risk.
- Whether the residual risk is acceptable for the Data Subject and therefore the Data Controller.
- Any other required activities to further mitigate risk whilst processing the data
- The ability to deliver the Rights and Freedoms of the Data Subject.
- Any other considerations required for the production environment.
2. Introduction and description of the project
A description and the context of all data processing within the project.
3.Data purposes and processing
- A description of each purpose of the personal data processing and how the conditions are met to lawfully process personal data.
- It should cover the types of personal data processing taking place and the categories of personal data used.
4. Data flows
- A description of the data flows from first receipt to erasure or anonymization. This should be data flow diagrams and tables of the personal data being processed.
- It should identify and describe the processing by Data Processors and other recipients of personal data.
5. Identification and quantification of absolute risk
- The personal data being processed should be categorised according to the risk to do damage and harm to the Data Subject if security is breached. (Absolute Risk - maximum potential exposure the group has to a specific risk. This represents exposure BEFORE controls).
- It’s envisaged a workshop should be run by the senior manager/DPO to identify those risks and share understanding in the organisation.
6. Mitigation of risk
- A description of the measures to address the absolute risk to a residual risk, including safeguards, security measures and mechanisms, both technical and organisational.
- This section should clearly indicate how the technical measure comply with the principles of the GDPR and key Articles, for example Art.25, GDPR, Data Protection by Design and Default and Art.32, GDPR, Security of Processing.
- It should ensure the protection of personal data and demonstrate compliance with the GDPR taking into account the rights, freedoms and legitimate interests of Data Subjects and other persons concerned.
7. Assessment of risk and proportionately
- An overall assessment should describe whether the personal data processed and associated risks are of an acceptable level - the necessity and proportionality of the processing. It should specifically consider if the amount of personal data is over collected and is it over retained with respect to the original purposes it was given in the first place by the Data Subject.
- The criteria to determine the acceptable level of risk should be described in line with corporate risk appetite (a matter for the Board).
- Suggestions for further mitigation of risk should be described here.
8. Consultation with Data Subjects
The best DPIA’s involve Data Subjects and document their views on the necessity and proportionality of the personal data processing. These views should be here.
9. Recommendations and summary
The recommendations should be described and listed with an overall summary.
For information about the GDPR Transition Programme at Henley Business School, click here.
Investor Relations Consultant: Founder of Investor Reach
7 年Like it. And good fun doing the event(s) with you recently Ardi
Legal Services for business owners who want to grow with confidence and peace of mind
7 年Nicely stepped out overview, thank you. I suspect their will be challenges in engendering change at a cultural level within organisations that are used to hanging on to personal data long after it has been used, and will struggle with customers empowered to request that their data be permanently deleted.
Previously Senior Global Privacy Specialist, Global DPO Office, Dentons and Global DPO, Cohen Veterans Bioscience (New York)
7 年Hi Cindy - you'lll be interested to learn that the entire GDPR Transition Programme at Henley Business School is written in colloquial English. One of the big challenges for DP professionals is to communicate in simple English in a way that non-DP people can understand. It's about making something complex like this subject human and accessible. That's what we are very good at doing. And we understand the detail but don't get people lost in it.
Thanks this - main problem I am finding is finding people who can bridge the gap between tech speak and boardroom speak :)
ISV's, PayFacs, PayVARs (ISOs) at Elavon Europe
8 年I would be very interested in any good articles that have references or predictions on the likely consequences of GDPR and PCI crossover - specifically tokenisation, and data breach.