GDPR Practical advice – data inventories and data maps (part 1)

GDPR Practical advice – data inventories and data maps (part 1)

By Steven Orpwood, Senior Consultant and DPO

When I was a young child, when phones had dials not keyboards, the family telecommunications device, which sat on a table specially designed to hold it, remembered nothing. It didn’t know my friends’ numbers and their names were a mystery to it. I did however, get an itemised bill, detailing numbers called and call durations. My phone was also low on memory. In order to store names and numbers I used a portable storage device called an address book; it was made of paper and I didn’t have a backup. I also had two bought-in contact databases, called the telephone directory and yellow pages. The other issue with my transponder, to borrow Star Trek vernacular, was that it wasn’t that portable, since it was connected to the wall by a wire; in fact increasing portability meant buying a very long wire, but it was of no use to me if I was stranded in a snow drift, even if the snow drift was in the vicinity of my garden gate.

Fast forward a year or forty and my transponder would put Captain Kirk’s to shame. It remembers, predicts and stores things, it tells me where I am, traces my route, takes photographs and allows me to buy things. It’s fully mobile, and doesn’t need additional storage, unless I want to use it, in which case I can push images and music into the ether, and retrieve it at will. My provider, sort of like my butler, knows even more about me: where I am at any point and what messages I’ve received, who called me, who I called, what I looked at, where I looked at it, on and on and on… It’s also, like Henry Hill in Goodfellas, connected, although much better; it has apps, maps, iTunes, you name it.

The juxtaposition between the two states above is marked; however, it’s worth noting that in both cases, the phone was in some way connected to other systems, and whilst my two tone brown number (which went well with the 1970’s shag pile) didn’t remember things, it did present a door through which data could be captured, stored, and processed. In fact, whilst the systems are more complex, and the volume far greater, the youthful me, and the current me, both have data and both have the same rights to personal privacy, and as a result to data protection, as do the people we hold data about. Whilst GDPR feels like a year zero, a new dawn where we actually need to be proactive about  the information we hold about individuals, there has always in recent memory been a need to protect data. So how is GDPR different from what’s gone before? The answer is both in many ways, and in very few.

To pick on one aspect, given that data must be adequate, relevant and not processed in a manner which is incompatible with the stated purpose, it is more imperative than ever that an organisation knows what data it holds, for what reasons, and if it’s allowed to do so. And so we come to the reason we need to compile a data inventory; self-protection…

Perhaps this is simplistic, but I want you to actually compile an inventory, not just think about it. Think of it as a helpful device that will streamline your processes and maximise efficiency, it will be part of your accountability documentation, but will, most of all, allow you to know what data to keep, what to remove, and will protect you when you’re asked why you have data, or allow you to find that data if it’s requested.

Thinking practically, since jumping in feet first and trying to tackle the activity en masse will be difficult for even the smallest organisation, the first step can be to create a simple spreadsheet showing what data repositories you have within your organisation; these can be paper, databases, file stores, cloud etc. Each entry can be accompanied by a short description of the type of data held, whether it contains sensitive data, the number of different personal data elements, its use and how it’s stored. Next, conduct a ‘finger in the air’ risk assessment, based on these factors, to establish if you believe the repository to present a risk to the rights and freedoms of the individuals whose data is contained within it.

Yes, you need to conduct an inventory exercise for all your data stores, but to make sure your efforts are efficient, concentrate on red flashing lights first (so high risk elements), and remember to document what you’ve done. Can you miss things with this approach? Yes maybe, but you’re demonstrating that you’re thinking about your business, how it uses data, and assessing the impact of potential data loss on others. This can only be seen in a positive light.

So what now? You have a list of high risk data repositories, and so the next step is to document what data is held in each repository, i.e. list all the categories of data it holds (and by categories, I mean nothing more complex than forename, surname, preferred name, address, passport number, date of birth etc). And for each category you need to document why you need it, the legal basis for collecting and holding it (there are six legal bases), how long you’ll hold it, what’s done with it, who uses it, especially 3rd parties, and how you hold it. This will potentially be a large spreadsheet, but once you’ve done it, nothing should change unless you amend your systems or processes, or build new ones.

Now you have a document that can be used to guide your data retention, but it’s just a list.  Perhaps we could go the extra mile and show how this data enters, moves around, and leaves the organisation. Welcome to the data map which I’ll look at in more detail in the next blog…

 

AiM has a range of services to guide you through the GDPR journey, including IT solutions to locate, identify, classify and protect all data. Click here to find out more or arrange a demo.