With the EU-approved General Data Protection Regulation (GDPR) set to be implemented in the U.K. on May 25, 2018, this topic must be a consideration for all insight leaders.
In my own work with clients and in my conversations with others, I find GDPR is cropping up more often. However, I’ve become a little alarmed at a general sense of complacency and of putting off looking into this for now. Given the scale of impact and the time needed to deliver any significant data projects, I suggest leaders focus on this issue — now.
Do you know if you already comply with the likely requirements of GDPR? Have you at least identified any significant data model or systems changes that are needed so that project planning can begin ASAP?
Getting clearer on GDPR
Two reasons appear as to why people may not have started looking into GDPR yet. The first is that people are awaiting interpretation of elements of GDPR for U.K. businesses from the Information Commissioner (ICO). The ICO did appear a little slow off the mark (perhaps it was waiting for greater clarity on Brexit), but its guidance is beginning to appear.
The second issue is a sense that GDPR was not “as bad as expected” or “as draconian as feared,” even if a business leader still isn’t crystal clear on GDPR's scope and impact.
See also: Cyber Insurance: Coming of Age in ’17?
Now this blog post is too short to answer all the questions you may have about GDPR. But, given that 2017 will also see data leaders needing to engage with changes in ePrivacy regulation, GDPR is too timely to be ignored. So, I'll use this article to point out some aspects of GDPR that data insight leaders should be considering.
In no particular order, here are some potential points of impact to check out:
Change in definition of consent
The GDPR expands upon and clarifies the looser definition of consent that had previously been in force. That new definition is:
“…‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.”
Two key phrases in that text are “unambiguous” and “clear affirmative action.” With the caveat that I am not able to offer any actual or implied legal advice, it’s also worth pointing out that the supporting notes (given the strange name “recitals”) clarify that:
“Silence, pre-ticked boxes or inactivity should not therefore constitute consent.”
So, the first point of impact that I would encourage leaders to check out is all your data-capture touch-points and comms. Are you sure all operate on positive opt-in and that none are still getting away with the passive opt-out requirement?
I won’t bore you with the detailed text here, but GDPR also makes clear that this consent should not be a condition of accessing elements of product or service that don't require the data to operate. It must be “freely given.” Are you sure you don’t have requirements for marketing consent that are hiding behind special offers, competitions or newsletters?
Is “legitimate interests” your get-out-of-jail-free card?
One of the collective sighs of relief heard from the direct marketing industry when the final text of GDPR was confirmed was that direct marketing was still identified as a “legitimate interest.” To some, that held out the potential for businesses to define their use of data as such, rather than require explicit consent before marketing.
A few provisos are still worth clarifying. Recital 47 makes clear that there might be a legitimate interest in direct marketing toward existing customers, but the recital also states that the data subject could “reasonably expect” this to happen. Other caveats make clear that any objection by the data subject would override this “right.”
So, while it might seem tempting to have a way around unambiguous positive opt-in, this might be fools gold. I say that because when marketing on such a basis, the onus will be on the data processor to make clear to the data subject that they are using this permission and to provide a suitably clear means of opting out. Are you sure you can explain to your customers in plain English what your use of their data under “legitimate business interests” means?
Your profiling has been spotted
Another popular topic among those who like to discuss GDPR (you know who you are) is that of “profiling.” By this, the EU means use of personal data to analyze or predict people's performance, behavior, situation, interests, location or movements. Not only is this profiling issue new (as compared to the U.K.’s Data Protection Act), but it includes the right for people to opt out of their data being used for this purpose.
Anyone who leads analytics or modeling teams will know this opens a Pandora’s Box. Nowadays, most direct marketing and occasionally all customer interactions are targeted by the use of predictive models. Many models are also personalized or timed through use of segmentations, scores and flags or as a result of behavioral profiling.
Now, it’s bad enough that an individual might want to opt out of your company being able to target interactions using standard processes. It's still unclear whether the customer's data should also then be removed from datasets on which any existing models/rules were built and the analytics repeated. What is clear is that data subjects will have a right to object to their information being used and that profiling is only legal with their permission.
Do you have data models/structures that capture an individual's permission at this level of granularity? Plus, do you have analytics and modeling processes that enable rebuilds on the basis of customers withdrawing permission for data that was previously in modeling datasets? It's not easy, but a pragmatic solution will need to be found. Plus, it will be your responsibility to inform the data subject of the right to object to such profiling. (How will you explain it?)
Will people want to go incognito?
Legal cases against Google and Facebook have raised the public awareness of the right to be forgotten. This is another addition via GDPR. Not only will data processors need to make clear that people have this right but that, if they want to opt out, their data must then be erased “without undue delay.” So, data controllers are required to inform data processors of any erasure requests and take all “reasonable steps” to tell other data controllers where data has been shared.
Think for a moment about the connections in your current IT systems. If you are a large U.K. corporation, chances are that you not only have a myriad of legacy systems internally but also share data with external systems for operations, marketing and other functions. Do your data models and current processes enable all the data about an individual to be found and erased? Does your answer to that question include confidence in your suppliers' and partners' ability to take action should such an erasure request occur?
There are a myriad of details to be worked out on this one. If an individual has asked to be suppressed from marketing, is it reasonable to keep sufficient data to still enforce that request? For now, realize that the bar will be higher than just having a data retention policy and answering subject access requests.
You need to test run how you would execute an individual erasure request across your data landscape.
See also: Insurers’ Call Centers: a Cyber Weakness?
Building on everything else in GDPR will be the right to data portability. Individuals should have the right to leave and take their data with them. We have all seen the changes in utilities to enable this, and banks are currently preparing for open banking protocols.
What about your business?
How could you provide customers with all the data they need to easily change provider? That may well be coming — so plan ahead.
There is more to GDPR!
That’s sufficient information to chew on in this article. But there are more topics for data leaders to worry about.
In part-2 of this mini-series, I’ll share my thoughts on these aspects of GDPR:
- Data model impacts (can you prove consent and when is its use-by date?)
- Data protection impact assessments (are you designing for compliance?)
- Record-keeping and contracts (what should these cover?)
- Data protection officers (do you need one, and what should he or she do?)
