This is part 2 of a mini-series focused on helping data insight leaders plan for GDPR. For part 1, click here.
With the EU-approved General Data Protection Regulation (GDPR) due to be implemented in the UK on 25th May 2018, the clock is ticking.
In our first post we focused on the need to check your potential exposure to these areas:
- Higher standard of what constitutes consent;
- Challenges if using ‘legitimate interest’ basis;
- Permission needed for profiling and implications;
- Data impact of people’s right to be forgotten.
However, there is more to GDPR.
I mentioned in my first post that I was concerned about an apparent complacency regarding GDPR readiness. From talking further about this with some leaders, it seems one cause is risk and compliance teams advising that ‘it’s not as bad as feared’. Here there is a danger of potential threats ‘falling between two stools’. Let me explain.
From a risk and compliance perspective, many of the principles in GDPR are not hugely different from the existing UK Data Protection Act. Many of the changes come through greater evidence requirements and more specific guidance as to 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 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 we mentioned in our previous post with regards to withdrawing permission for profiling (or right to ‘be forgotten’). Most businesses’ existing data models will not currently cater for the new fields and separation of records required.
So, although wading through EU legal language may not sound like a fun day out, it is worth data insight leaders and their teams talking through practical implications with their risk and compliance advisers. Now, onto some other considerations for you to discuss.
Data model impact
The reason for entitling this topic 'data model impact' rather than just 'database impact' is my earlier advice to maintain up-to-date data models for your business (that give you independence from specific IT solutions). But, either way, data insight leaders will want to identify ASAP any impacts to their data structures and changes that may be needed to enable compliance.
In our first post we touched on both the need for consent (to marketing and profiling) plus the need to evidence this. There are further considerations. To apply 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 updated for GDPR) makes clear:
- “Organisations should therefore make sure they keep clear records of exactly what someone has consented to”.
- “Organisations may be asked to produce their records…”.
- “Organisations should decide how long is reasonable to continue to use their own data and more importantly a 3rd party list”.
- “As a general rule… it does not rely on any indirect consent given more than six months ago”.
Do your data models both 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
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) are not 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, 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 use of that data which would breach 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 via 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/regulations might be breached?
- Is there any associated organisation risk (e.g. reputations risk if goes wrong)?
- Who should be consulted (including third parties and teams using personal data)?
One final point. Within the GDPR guidance, there is also an expectation of “designed for compliance”. That is far less tolerance for new systems not being designed to store and use data in line with GDPR rules. So, 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 assume the same opportunity to blame ‘legacy systems’.
Record keeping and contracts
Financial services firms will be used to the record keeping requirements from other regulation (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, then “detailed records of the processing” need to be kept. SMEs (less than 250 employees) are generally exempt, unless the processing carriers a ‘high privacy risk’ or involves ’sensitive data’.
So, if you are lucky enough to fall into one of those categories, 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 controller and DPO (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).
- Security measures in place (data access, authentication, etc).
As an aside for insight leaders, recognising the need to keep all these records, prompts me to speak up again about the need for better knowledge management solutions. In a previous post 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 whilst working there — an easy way to store both insights data and 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. Hopefully the success of products like Evernote will prompt more complete solutions.
Data protection officers
Over the course of reading these two posts on GDPR, you may be beginning to wonder ‘who carries the can’. Who is responsible when your organisation gets a 4% fine? The answer, for many firms will be the data protection officer (DPO). But. far from being a scapegoat role, they are intended to be the internal conscience akin to an internal audit role in helping to 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) in many firms. At one stage it was expected that GDPR would require every organisation to have one, but the final wording has settled on a tolerance.
The following have to have DPOs:
- Organisations where processing is ‘likely to results in a risk to data subjects’.
- Organisations involving large-scale monitoring or sensitive data (ICO guidance should clarify).
- 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 they aren’t brought under undue internal pressure. They are not to be instructed how to carry out their duties. They may not be dismissed or penalised for performing their tasks and they have to report directly to highest level of organisation. Given that freedom and responsibility, it is not surprising that a number of businesses will ask their CDO to take on the DPO role as well.
What are DPOs expected to do then (if they can’t be over guided internally)?
- Inform and advice data controller(s) to ensure compliance.
- Monitor compliance with GDPR.
- Provide advice to others where requested (e.g. DPIAs).
- Cooperate with ICO, inc. notifying any breaches (to ICO and data subjects).
Give all the concerns it is not surprising to see a growing industry of ‘data breach insurance’. However, it’s worth reading their requirements. Many require very stringent internal controls and may not pay out if any ‘insider’ collusion is identified.
How are you preparing?
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 as soon as possible.