How to avoid getting bitten on the bum by GDPR (part 2)

This is part 2 of our series focussed on helping Data Insight Leaders plan for GDPR. With the EU approved General Data Protection Regulation (GDPR) due to be implemented in UK on 25th May 2018, this must be a consideration for all insight leaders.

There has been a positive response to the first post on this topic, which has confirmed the concern about this topic that I’m hearing in my conversations. It seems many leaders are grateful to just have a simple overview that identifies areas of potential concern.

Although these two posts can only be the start of your journey to assess GDPR impact for your business, I hope they help you.

In our first post we focussed on you needing to check your potential exposure w.r.t these topics:

• Higher standard of what constitutes consent;
• Challenges if using ‘legitimate interest’ basis;
• Permission needed for profiling & implications;
• 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. From talking further about this with some leaders, it seems one cause is Risk & 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 & compliance perspective, many of the principles in GDPR are not hugely different from existing UK Data Protection Act. Many of the changes come through greater evidence requirements & more specific guidance as to what is expected in specific situations. For that reasons, 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 & 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 last week 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 & 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 & their teams talking through practical implications with their risk & compliance advisers. Now, onto some other considerations for you to discuss.

Data Model impacts from GDPR

The reason for entitling this topic, Data Model impacts, rather than just Database impacts — is our 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 & changes that may be needed to enable compliance.

In our first post we touched on both the need for consent (to marketing & 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 & storage of consent data within any 3rd 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 & more importantly a 3rd party list”
• “As a general rule… it does not rely on any indirect consent given more than 6 months ago”

Do your data models both capture that granularity of data permission (what & when) and hold it against both internally captured personal data and any you may have purchased from 3rd parties?

Data Protection Impact Assessments

Data & 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 (esp. on ‘downstream’ systems like data warehouses) are not considered or are de-scoped from testing. This can result in considerable rework & 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 & 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 2 posts)?
• Which principles/regulations might be breached?
• Is there any associated organisation risk (e.g. reputations risk if goes wrong)?
• Who should be consulted (inc. 3rd parties & 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 & use data in line with GDPR rules. So, well worth reviewing any current & planned projects to ensure they are allowing for the data fields & checks that will be required. Don’t assume the same opportunity to blame ‘legacy systems’.

Record keeping & Contracts (what should these cover?)

Financial Services firms will be used to the record keeping requirements from other regulation (inc. 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 & people, including:

• Name & contact details of Data Controller & 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 & the insights they have gleaned whilst working there — an easy way to store both insights, data & data about data is clear. However, despite years of variants of database, intranet, groupware & 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 (do you need one & what should they do?)

Over the course of reading these two posts on GDPR, you may be beginning to wonder ‘who carries the can’. 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). 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 & 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 & they have to report directly to highest level of organisation. Given that freedom & responsibility, it is not surprising that a number of businesses will ask their CDO to take on DPO role as well.

What are DPOs expected to do then (if they can’t be over guided internally)?

• Inform & 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 & 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 & may not pay out if any ‘insider’ collusion is identified.

How are you preparing, any tips?

I hope that content was helpful. Listing so many ‘watch outs’ makes me feel like reusing the hackneyed phrase “we are all in this together”. It certainly is true that 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 implications for your organisation? Any tools or tips & tricks you’d recommend.

As ever, we’d like to encourage the Customer Insight Leader community to share best practice & help improve our profession.

For further information & perhaps a next step, I’d recommend the training & certification provided by The IDM. I’ve completed both & found them very useful.