The far from simple task of responding to a subject access request

What’s the full process and GDPR requirements when responding to a subject access request?

When individuals call into your fulfilment centre, or reach you via email or letter, with a request exercising their rights under GDPR, they will be triggering what is, in reality, a complex process. They may alternatively be directly accessing your on-line privacy portal, using self-service, but the steps that they will follow will be broadly the same.

 

Here’s a 10 step guide to all the process intricacies involved when responding to a subject access request

 

Step 1: Have all your data relating to each individual that your organisation deals with joined together into a single customer view

This will need to include on-line data you are holding like pages browsed linked to cookie IDs, as well as off-line data such as transactions. To make matters more difficult, the personal data may be held in an unstructured form such as emails or reports. It will be far beyond the capabilities of most organisation to have the unstructured data pre-packaged as part of the single customer view, but you will at least need the capability of searching for it.

 

Step 2: Identify that the individual approaching you is who they purport to be

If they reach you by email or letter, you will most probably have a requirement to verify them by checking on some other identifiers you may hold, to avoid handing over personal information to the wrong recipient or making false changes to the information you hold on someone.

 

Step 3: Be able to access what some people are now calling a consent vault

This is the place where all the opt-ins and opt-outs are held. GDPR has defined the information you need to hold about each consent that has been provided, such as how it was obtained and what statement the individual is agreeing or not agreeing to. The consent vault will, we expect, naturally form part of the single customer view. However, as well as holding the individual consents you will need to interpret them so that you can inform Mrs Smith of what, as things stand, you may or may not use her data for. We suggest developing a set of ‘traffic lights’ that work off the consents already provided, and which give clear guidance about what types of activity may be undertaken by which channel.

 

Step 4: Allow Mrs Smith to change her consents

This is going to be much easier if you have the traffic light system as Mrs Smith will have a clear idea of what is in place for her now, and hence what she might want to change. The new consents or withdrawal of consents will need to be data captured and potentially a record of that change sent to Mrs Smith.

 

Step 5: Mrs Smith asks for a copy of all the information you hold about her

A relatively easy step if you have the single customer view in place, but a much more difficult one if you don’t. And then if you have unstructured data referring to Mrs Smith this will also need to be searched. There are technology tools around to help your search process if the amount of unstructured data is very considerable or spread over several different systems.

 

Step 6: Mrs Smith sees her data and wants to correct it

The corrections will need to be data captured and the changes will need to be communicated to any systems that are upstream of where the single customer view is being held. Good practice will, we expect, be to send Mrs Smith some form of notification of the new details you are holding.

 

Step 7: Mrs Smith exercises her rights to data portability

You will then have to provide her data in machine readable format to another data controller that she specifies. We envisage creating an HTML or equivalent file, and sending it to Mrs Smith by email. The data transferred should include not just data provided by Mrs Smith but data generated by you.

 

Step 8: Mrs Smith exercises her right to be forgotten

In this case, you can maintain any non-personal data like transactions relating to her, but you have to delete or overwrite any personal data like email, mobile phone number, postal address, cookie ID etc. As well as deleting them in the single customer view, you will need to inform the upstream systems of the request so that they can do the same thing.

 

Step 9: Take account of Mrs Smith’s requests when it comes to further processing of her data

She may have opted out of profiling, which means that you will not be able to manipulate her data using algorithms to make decisions concerning what you do or do not want to say to her, or what offers you want to make to her. She may alternatively not have provided positive consent to be emailed, so you must not include her in email campaigns etc.

 

Step 10: Maintain an audit trail of what has been done with respect to responding to her subject access request.

We suggest that these actions are most conveniently recorded as part of the information held in the single customer view. In this way, you can meet any challenges from an individual or the ICO concerning how you are managing the GDPR processes.

 

We have developed our own cloud-based technology, called UniFida, to support clients in fulfilling such individual requests.

Contact us if you’d like our help with this.

 


UniFida logo

UniFida is the trading name of Marketing Planning Services Ltd, a London based technology and data science company set up in 2014. Our overall aim is to help organisations build more customer value at less marketing cost.

Our technology focus has been to develop UniFida. Our data science business comes both from existing users of UniFida, and from clients looking to us to solve their more complex data related marketing questions.

Marketing is changing at an explosive speed, and our ambition is to help our clients stay empowered and ahead in this challenging environment.


Forget-me-not: The right to erasure of personal data

As many of us know, the right to erasure of ‘personal data’ is one of the key elements within GDPR.

But that leaves a big question mark over exactly what ‘personal data’ is, and hence what data is to be erased.

 

What is personal data?

Back in 2007 the European Data Protection Working Party published Article 39, and defined personal data as ‘any information relating to an identifiable natural person’.

They went on to say that ‘a natural person can be identified when, within a group of persons, he or she is distinguished from other members of the group’.

 

What data items uniquely identify an individual?

The ICO recently wrote ‘the more expansive [GDPR] definition provides for a wide range of personal identifiers to constitute personal data’. Here I assume that they are not changing the definition itself, but rather just adding in new forms of identifier, like cookie ID.

So, are we being asked to deduce that if a data item is not an identifier relating to a natural person, it is not personal data?

Assuming that this is the case, there are then two important questions that follow and which need to be answered: when is an item of data definitely not relating to a natural person, and hence something that does not need to be erased and within the remaining population of possible identifiers, how uniquely do identifiers need to point to a single individual to be classed as a true identifier?

Personal data does also need to be about an individual in order to relate to it. The value of a house is not personal data until you relate it to an owner, in which case it tells us something about how rich he is.

Many ordinary transactions for instance would not on their own relate to or identify an individual, but certain ones might do.

To take an extreme example, a sale record in the Land Registry for Buckingham Palace would certainly identify the transaction as being associated with the Queen. But less extreme examples like a pattern of phone calls made at certain times of day could also point to a unique individual.

And although a number on its own is clearly not an identifier, when you put it in the category of a list of customers, each with a customer number, then it definitely can become one.

So the question of whether an item of data does or does not point to an individual will depend on its context.

However, I suspect that GDPR is not expecting us marketers to use GCHQ level intercepts to trace links to an individual, which would then make almost every item of data a potential identifier, but rather expect us to employ simpler and more straight forward ones like an IP address, name or email.

But, at this point a further problem arises, which is that many of these ‘straightforward’ identifiers, like forename and surname, can point to more than one person. When I Googled 192.com I found that there are 50 people called Julian Berry in the UK, so Julian Berry in itself is not a unique identifier until it is associated with other information like his address.

Another experiment we ran was to look at whether through knowing data of birth, outbound postcode and gender you could uniquely identify an individual from a UK wide lifestyle database. And the unexpected answer was that in 70%+ cases you can.

This shows that although each of these data items on their own do not uniquely identify an individual, in combination they do.

So where is this taking us?

 

Identifying personal data to comply with the right to erasure

Data items on their own may not be relating to an individual or unique identifiers, and hence personal information, but that they may become so when associated with other data items. A forename and surname plus an address becomes a unique personal identifier. This means that, when deciding what are personal data, we will need to identify either individual data items that point uniquely to an individual like an email, or groups of data items that in combination may do so.

Data items that either on their own, or in association with other data items on a database, definitely do not relate to or point to an individual, are not personal information. Broadly speaking this will mean that when erasing personal data, we can leave areas like ‘transactions’ or ‘donations’ untouched.

This implies that we will need to do a review of all the data held by an organisation to define what could be, and what could not be, personal data, before setting up the technology to erase that personal data when requested to do so.

And when erasing it, we will need not just to erase the personal data held in downstream systems like a single customer view, but also upstream in source data systems. So this implies knowing where all the personal data about an individual has originated, and where it is currently being stored.

Want to understand more about GDPR? Read our 10 step guide to all the process intricacies involved when responding to a subject access request.


UniFida logo

UniFida is the trading name of Marketing Planning Services Ltd, a London based technology and data science company set up in 2014. Our overall aim is to help organisations build more customer value at less marketing cost.

Our technology focus has been to develop UniFida. Our data science business comes both from existing users of UniFida, and from clients looking to us to solve their more complex data related marketing questions.

Marketing is changing at an explosive speed, and our ambition is to help our clients stay empowered and ahead in this challenging environment.