This is Part Two of a two-part series focused on helping data insight leaders plan for GDPR. Find the first part here.
With the EU-approved General Data Protection Regulation (
GDPR) set to be implemented in the U.K. on May 25, 2018, GDPR must be a consideration for all insight leaders.
In the first post, we focused on needing to check your potential exposure with regard to these topics:
- Higher standard of what constitutes consent;
- Challenges if using “legitimate interest” basis;
- Permission needed for profiling and implications; and
- Data impact of people's right to be forgotten.
Is there more to GDPR than that?
I mentioned in my first post that I was concerned about an apparent complacency regarding GDPR readiness. After talking further about this with some leaders, I believe that one cause is risk and compliance teams advising that GDPR isn't as bad as feared. This means there's a danger of potential threats “falling between two stools.”
Let me explain.
From a risk-and-compliance perspective, many of the principles in GDPR aren't hugely different from the existing U.K. Data Protection Act. Many of the changes come through greater evidence requirements and more specific guidance regarding what is expected in specific situations. For that reason, I can understand compliance experts not seeing the need for vastly different paperwork. However, leaving such an assessment to that team risks missing critical implications.
One of the reasons that insight leaders and data teams should get involved in discussions about GDPR is to spot technical/data/system implications of change. What may seem to be simply a clarification of language to a compliance expert sometimes has far-reaching implications for company data models and how data will be used or stored — for instance, the rights mentioned in Part One with regard to withdrawing permission for profiling (or the “right to be forgotten”). Most businesses’ existing data models will not currently cater to the new fields, and separation of records is required.
So, although wading through EU legal language may not sound like a fun day out, it's worth data insight leaders and their teams talking through practical implications with their risk and compliance advisers.
Here are some other considerations for you to discuss.
Data model impacts from GDPR
The reason for titling this topic “Data model impacts” rather than “Database impacts” is our
advice to maintain up-to-date data models for your business that give you independence from specific IT solutions. Whatever this is called, data insight leaders will want to identify any impacts to their data structures and any changes that may be needed to enable compliance ASAP.
See also: Missed Opportunity for Customer Insight
In our first post, we touched on both the need for consent (to marketing and profiling) as well as the need for evidence of this. There are further considerations.
Applying meaningful data-retention policies that can be justified as reasonable requires knowing the recency of such consent. In addition, data-controller responsibilities require the capturing and storage of consent data within any third-party sources of personal data.
Even the current Information Commissioners Office (ICO) guidance (before it was updated for GDPR) makes clear:
- “Organizations should therefore make sure they keep clear records of exactly what someone has consented to.”
- “Organizations may be asked to produce their records…”
- “Organizations should decide how long is reasonable to continue to use their own data and more importantly a third party list.”
- “As a general rule… it does not rely on any indirect consent given more than six months ago.”
Do your
data models capture that granularity of data permission (what and when) and hold it against both internally captured personal data and any you may have purchased from third parties?
Data Protection Impact Assessments (DPIAs)
Data and analytics leaders within businesses often complain to me about not being consulted by internal project teams. It seems all too often the data implications of projects (especially on downstream systems like data warehouses) aren't considered or are de-scoped from testing. This can result in considerable rework and in the worst cases to inappropriate marketing or customer contact.
Data Protection Impact Assessments (DPIAs) are intended to protect against such unintended data changes. Previously only recommended by the ICO, the GDPR is more explicit in what is expected:
“DPIAs to be carried out if the planned processing is likely to result in a high risk to rights and freedoms of individuals — including where processing involves ’new technologies’ or ‘large-scale processing.’”
So, what do you need to do for a DPIA? Basically, it’s an investigation to identify how such risks will be mitigated. Could the planned systems changes produce effects on either data stored or on use of data that would breach the GDPR? Is monitoring required to avoid this? Given that the ICO is due to publish a list of the kind of processing operations that require DPIAs, it’s worth planning for them.
As a quick checklist, you should seek to answer these questions regarding your DPIA:
- What is the possible risk to individuals from changes (to systems, processes, etc.)?
- What is the risk of non-compliance with GDPR? (Consider all the topics in our two posts.)
- Which principles and regulations might be breached?
- Is there any associated organizational risk? (E.g. reputations at risk if goes wrong?)
- Who should be consulted? (This includes third parties and teams using personal data.)
One final point: Within the GDPR guidance, there's also an expectation of being “
designed for compliance.” There's far less tolerance for new systems not being designed to store and use data in line with GDPR rules. So, it's well worth reviewing any current and planned projects to ensure they are allowing for the data fields and checks that will be required. Don’t try to use the opportunity to blame legacy systems.
Record-keeping and contracts (What should these cover?)
Financial services firms will be used to the record-keeping requirements from other regulations (including FCA’s
Conduct Risk). Another area where GDPR goes further than previous rules is in the expectation of records being kept. If a data controller or data processor has more than 250 employees, “
detailed records of the processing” need to be kept. SMEs (fewer than 250 employees) are generally exempt, unless the processing carries a “
high privacy risk” or involves “
sensitive data.”
So what records must you keep?
As a rough guide, it’s high-level records on policies and people, including:
- Name and contact details of data controllers and DPOs (more about them soon);
- Purpose of processing;
- Classes of data (e.g. personal, sensitive, product, etc.);
- Details of recipients of data;
- Details of any overseas transfers;
- Data retention periods (replying on date stamps on data items); and
- Security measures in place (data access, authentication, etc)
As an aside for insight leaders, recognizing the need to keep all these records prompts me to speak up about the need for better knowledge management solutions. Previously, I made
a plea for more emphasis on metadata. Given that insight leaders also have a
challenge to retain analysts and the insights they have gleaned while working there, an easy way to store insights and data as well as data about data is clear. However, despite years of variants of database, intranet, groupware and other potential solutions, most businesses still lack a routinely used knowledge management solution. I hope the success of products such as
Evernote will prompt more complete solutions.
Data Protection Officers (DPOs) (Do you need one, and what should they do?)
Over the course of reading these two posts on GDPR, you may be beginning to wonder who carries the can. In other words, who is liable to go to jail or be prosecuted if this work is not done? The answer, for many firms will be the Data Protection Officer (DPO). Far from being a scapegoat, the DPO is intended to be the internal conscience — akin to an internal audit role in helping prevent breaches.
The ICO was previously silent on any formal need for such a position, despite the growing popularity of appointing
Chief Data Officers (CDO). At one stage, it was expected that GDPR would require every organization to have a DPO, but the final wording was more tolerant.
The following have to have DPOs:
- Organizations where processing is “likely to results in a risk to data subjects”;
- Organizations involving large-scale monitoring or sensitive data (ICO guidance should clarify); and
- Public authorities or bodies.
A DPO is required to have the requisite data skills, and their details should be published to encourage contact with data subjects. But there are also protections to ensure the DPO isn't brought under undue internal pressure. The DPO isn't to be instructed how to carry out the duties. DPOs may not be dismissed or penalized for performing their tasks, and they have to report directly to the highest level of the organization. Given that freedom and responsibility, it isn't surprising that a number of businesses will ask their CDO to take on the DPO role, as well.
See also: It’s Time for a New Look at Metadata
What are DPOs expected to do, then, if they can’t be over-guided internally? Well, this:
- Inform and advise data controllers to ensure compliance;
- Monitor compliance with GDPR;
- Provide advice to others where requested (e.g. DPIAs); and
- Cooperate with the ICO, including notifying the ICO about any breaches.
Given all the concerns, it's not surprising to see a growing industry of data breach insurance. However, it’s worth reading about the requirements. Many require very stringent internal controls and may not pay out if any insider collusion is identified.
How are you preparing? Do you have any tips?
Only time will tell how the ICO operates under these regulations and how firms respond. So, it’s the start of a journey — but I encourage all data insight leaders to start that journey ASAP.
Please do also share what has worked for you. What have you found useful in thinking through the implications for your organization? Are there any tools or tips and tricks that you’d recommend?
As ever, we’d like to encourage the Customer Insight Leader community to share best practice and help improve our profession.
For further information — and perhaps a next step — I’d recommend the
training and
certification provided by the IDM. I’ve completed both and found them very useful.
