GDPR: What a Data Protection Impact Assessment is and isn’t
There has been a lot written over the past year or so about the EU General Data Protection Regulation (GDPR) – what is required, and what needs to be accomplished sooner rather than later in order to meet the May 25, 2018 compliance date. And with 99 articles, with hundreds of requirements within them, covered within the GDPR, there are certainly many topics that must be addressed.
While seven to eight months may seem like a long time to address them all, it is important for those responsible for GDPR compliance activities to realize that some of those activities will necessarily take many weeks of planning and preparation, and then most likely many additional weeks of actual implementation.
One case in point is performing a GDPR compliant data protection impact assessment (DPIA). I’ve heard and read a variety of statements made about DPIAs over the past several months, and I want to correct and clarify a few of the ones that I’ve heard that have been especially of concern.
- “I’ve already done a privacy impact assessment (PIA), so I’ve got the GDPR DPIA requirement already taken care of!” Wait; not so fast. While I view a DPIA as a specific type of PIA (this is debated by various fans and foes of both the DPIA and PIAs, but in my experience doing more than 100 PIAs and more than a dozen DPIAs, I believe that, with the outliers that can be effectively addressed, a DPIA fits well within the larger PIA domain), a DPIA does have important and significant differences to a traditional PIA. So, don’t think that just since you’ve done a PIA at some point within the past year or two that you’ve met all the GDPR requirements for a DPIA.
- “Our lawyers told us it was a legal activity, and that IT, privacy and information security folks don’t need to bother with worrying about doing a DPIA.” While you need to do a DPIA to meet GDPR legal requirements, the answers that you will need to provide will typically not be known to the legal department, so it will need to include involvement from key stakeholders in IT, information security and privacy. And if you’re waiting for the legal department to contact you to ask you simple yes and no questions, keep in mind that many of the answers you will need to provide for an accurate and acceptable DPIA will not be yes or no. To determine as accurate of risk level calculations as possible, you must provide more detailed descriptions for where you are at with accomplishing activities.
- “I got a free 10-question GDPR readiness checklist from the Internet, so I’ll use that for my DPIA.” That is a dangerous, and incorrect, belief. A checklist is not an assessment. I am a fan of using checklists to keep track of progress with projects to make sure that I have addressed specific topics fully, to answer truly yes/no types of dichotomy questions, or to cross off the items I wanted to get at the grocery store after I put each in my cart. An assessment is not an either/or dichotomy. An assessment includes doing various types and levels of analysis, and arriving to an assessment that could be any number of answers, representing a multitude of risk levels. GDPR checklists that boil down the high-level activities you need to do can be helpful; a checklist, though, will not accomplish the necessary GDPR required DPIA.
A significant purpose for requiring organizations to conduct DPIAs is to identify and reduce the data protection risks within projects, networks and systems, reduce the likelihood of privacy harms to data subjects, and to determine the levels to which all of the applicable 99 GDPR articles have been implemented by the organization. Traditional PIAs have not fully addressed consideration of harms to data subjects (but that is important for all to address whether or not it is for DPIA), and certainly traditional PIAs did not look at the specific DPIA requirements that are unique from traditional PIA topics covered.
To the specific point of performing a DPIA, I recommend that organizations use a framework that not only addresses and meets the GDPR requirements, but can also meet other requirements for performing other types of privacy impact assessments. I’ve created a PIA framework, based upon the ISACA Privacy Principles, which consolidates similar privacy principle requirements and topics into the 14 ISACA Privacy Principles, and maps all the DPIA requirements within them, in addition to those DPIA questions also mapping to other standards, frameworks and regulatory data protection requirements.
(This blog originally appeared on the ISACA blog site, which can be viewed here).