A quick and dirty guide to implementing GDPR in an operational setting (part 1)

I'm not a legally qualified privacy professional - so you should be consulting with one if you're commencing a data protection initiative in earnest. 

However, I have been at the sharp end of implementing GDPR in operational settings for around 18 months now - here's some of what I've learned. 

There are 99 Articles in GDPR and 173 Recitals. The GDPR articles are specific legal requirements, the recitals provide more context and background. One of the best resources I've come across to quickly review or search articles and recitals is https://gdpr-info.eu/ 

In most instances, you (the reader) will not be a legally qualified privacy expert. So here's the first really important point. While you may be able to read the recitals and render them appropriately into an operational setting the only fit arbiter of either what is, or is not GDPR compliant is a legally qualified privacy professional. Unless you are that person, it won't be you relying on a law degree to debate the finer points of case law with the ICO's enforcement division. 

If you do not know where your data is, what data you have and for what purpose you use it, you cannot be compliant. Equally, you need to ascertain 'where you are' against where you 'need to be' if you are to succeed in generating a scope of work. You are almost certainly going to need to conduct some sort of audit or discovery exercise and I suggest, depending on the specific circumstances you could consider this approach.

Split data into two distinct categories - structured and unstructured. We could discuss what comprises structured data all day but perhaps the simplest definition is data which is either an input, a by-product or an output of a process. Most repositories of structured data will be an 'information asset' and in the UK's heavily service orientated industries, those information assets will often contain personal data.

 Unstructured data is anything that isn't structured.

You're going to need to know what your structured information assets are, what they're used for and what they contain. There will need to be some sort of central information asset register collecting a high quality minimum data set for each information asset. Fields could include some or all of the following.

You'll see above that we have introduced the role of information asset custodian. For each information asset, you're going to need to find a single accountable individual to take ownership and accountability for safeguarding the personal data that information asset contains. If the custodian is not not performing reviews of access controls (who can access the data), what the data is being used for and enacting some sort of retention protocol who is? And who else could?  

I think identifying a 'single throat to choke' for each information asset is crucial. You need to rehearse your lines to ensure that this doesn't end up IT's job or the Data Protection Officer's (DPO). It is the business's data and they must step up. If they won't (or can't), the DPO might want to consider taking information assets 'offline' until such a person can be found. 

You're likely to be carrying some sort of 'compliance debt'. Privacy Impact Assessments were best practice under the previous Data Protection Act (1998) but I've never seen nor heard of one being carried out. In fact, I've come across some CRM environments in which it simply isn't possible to delete customer records (no one ever thought it would be necessary / desirable). So you'll have platforms which will likely give you some problems. That's still a business problem and it is the job of the information asset custodian to fix. And, issues of retention or subject access requests (among other things) are not a new with GDPR but '...the way you always should have been doing things'. So that compliance debt (I'm afraid) is a 'credit card bill' which the business is going to need to pick up.

 But of course, you're already DPA (1998) compliant - so it's just a small hop to get GDPR compliant isn't it? Two quick tests for this (not conclusive but they will help build confidence). 

Pull a report from your off-site paper archive storage folks. What are the oldest boxes you have got on the shelves, how many of them are there and what do they contain? Do you have a published retention rule which (say) supports you keeping personal data for 30 years (or other period as applicable in your specific situation)? Thought not. 

Pull a report from your IT department for your shared mailboxes. You know the ones I'm talking about - applications@globalmegacore.com. How much data is in those mailboxes, how old is it, who has access to it and again, do you have a published retention rule which supports you keeping data for x years (or other period as applicable)? 

Assuming you're not the isolated instance where you are in fact delighted with your findings, you may well have just ascertained that perhaps you need a bit of a data spring clean. The more you have, the more you can breach, and if I was an ICO enforcement officer - this is where I would start. 

Crucially by the way - you can derive a reasonably broad assumption from the output of the two activities above. If your paper assets and email are a little behind with their information retention protocols (or there isn't one) then it is probably safe(r) to assume that the rest of your estate is in a similar position. 

You need to think about training. And, I mean really think about it. There's the pragmatic box ticking exercise to demonstrate that to the regulator that you have engaged with and acquainted all your staff with GDPR and its requirements. However, there's a better perspective to take on this. Neither you nor those with specific compliance and risk duties can be everywhere all the time. I'd be thinking about putting 1 in 10 staff through specific enhanced training so that you are able to leverage a much greater level of presence and awareness across your business. A previous client instated the roles of 'Data Reps' and 'Data Champions' and incorporated it into internal progression and award. It worked well.

Data incidents, near misses and breaches - call it what you will. You need a slick and quick process so that when an incident is observed (wrong email sent to the wrong person, a sack full of confidential materials left out for recycling or a supplier is accidentally sent payroll data for every employee), you can quickly capture the salient details and manage the incident. Embedding this and ensuring that it communicated and adhered to is crucial.

The benefit of having a data incident process incidentally is that it becomes a high value resource for near misses and training so you should see incidents diminish over time.

Okay - that will do for the minute. If I get 5 likes - I'll write a part two in which I'll talk about Data Protection Impact Assessments, how to manage unstructured data and how to generate a benefits case which will hopefully pay for your entire GDPR / Data Protection initiative. Who knows - you might even make a profit!