A few practical tips for managing subject access requests

Editor’s Note: This is currently an EU issue, but the proposed changes to PIPDEA in Canada as well as the new California Consumer Protection Act 2018 (CCPA) will require us all to manage Data Subject Access Reports. Building it into your processes and systems now will keep you ahead of the game and help you better serve your customers.

Subject access requests are the bane of many an in-house privacy professional’s life.  It may seem curious that, on the one hand, we take seriously as privacy professionals our responsibility to uphold data subjects rights while, on the other, the exercise of one of the most fundamental of these rights – that of access to data – will typically cause even the most dedicated of privacy professionals to elicit a small whimper.

Why should that be?  There are several factors: the ever-growing data mountains held by organisations; the prohibition against charging for DSARs encouraging maliciously-motivated requests, and the subjective nature of many disclosure exemptions. However, at its core, it boils down to this: DSARs are expensive, time-consuming, and just really hard work.

The important thing, therefore, is not to be caught off-guard by DSARs.  I can’t count the number of times I’ve heard organisations say “we don’t need to worry about those yet – we’ve never had one”, only to find out that – five or six months down the line – they receive their first DSAR, don’t know what to do, and so fail to respond, or fail to respond adequately, within the statutory one month response period.  The result: data subject complaints, regulatory enquiry, and internal finger-pointing.

The good news is that a little early planning can save a world of pain down the line – an accountability stitch in time, if you will.  By way of just a few suggestions:

1.  Have a process.  ALWAYS have a process.

First and foremost, you must have a documented process for handling DSARs.   The act of documenting your DSAR response process will force you to think through the steps that will be involved, where your internal data sources reside (consult your Art 30 records!), the channels of communication you need with internal stakeholders, what exemptions will be most relevant in the context of your organisation, and so on.  This will help you to respond to DSARs in a methodical, thorough way, and within the relevant statutory time limit.  

In consulting with internal stakeholders to create your DSAR process, they will often make suggestions to improve it – engineering teams, for example, won’t be enamoured with the idea that they may have to manually extract data from product databases if they can instead build a tool to do it.  And, if they do that, so much the better!  They will have made both their and your lives easier, while facilitating a more efficient response to the data subject – a win-win all around.

2.  Reduce the data you hold.

We all know the GDPR says you shouldn’t hold more data than is “necessary”, but it’s difficult to incentivise the business to hold less data when data is so valuable.  However, the mountain of data your business holds will prove a nightmare when (not if) you receive a DSAR – there will be significantly more data to review, redact and disclose.  

This is especially so when managing employee DSARs, which nearly always entail reviewing large amounts of unstructured data.  These requests typically arise in the context of some kind of employment dispute, often where a disgruntled employee wants to find some kind of “smoking gun” within your data to support an employment claim.  

In making these requests, employees often request access to personal data about them contained within e-mails between third parties (e.g. other employees and managers).  To determine whether these e-mails contain personal data about the requesting employee, the organisation will have little choice but to conduct key word searches of the relevant organisation’s e-mail platform.  This will typically throw up thousands, if not tens of thousands (if not hundreds of thousands) of search results; results that some poor soul then has to sift through to determine whether or not the results returned really do include “personal data” about the requesting employee and, if so, whether an exemption from disclosure should be applied.  And the longer the employee has been with the business, or the more common the employee’s name is (think about all the “John Smiths” out there), the more search results you will get.

This problem can be substantially mitigated by the use of sensible data retention policies.  Clearly, an organisation that retains ten years’ worth of e-mail data is going to have an awful lot more information to sift through than one that retains only a single year’s worth of e-mails.  Keeping in mind the potential costs of sifting through thousands upon thousands of e-mails (and, remember, all to fulfil a request that the data subject can exercise for free), then limiting the amount of data you hold suddenly seems much more attractive.

Oh, and just in case you were wondering, don’t expect data protection authorities to have any sympathy with you refusing requests because “there is too much data to review”.  They won’t.  The more pain you experience dealing with DSARs due to the volumes of data you hold, the more likely you are to minimise the data you hold going forward – and this serves data protection authorities’ minimisation objectives nicely. 

3.  Don’t trust customer service.

I’m sure you remember the occasional really great customer service experience you’ve had over the years.  But I’m also willing to bet you remember bad customer service experiences much more readily.  Have you any idea how many subject access requests ultimately get farmed out to external lawyers and consultants to resolve because someone in customer service messed up?  I’ll tell you, it’s a lot.

Often, when a customer raises a subject access request, they’ll do it initially through a customer service touch point – whether through a CS e-mail address, web form, or phone number.  However, many CS reps seem not to recognise DSARs or fail to escalate them quickly enough, if at all.  The consequence: a data subject submits a DSAR, the one-month clock passes, and the first that anyone in the privacy or legal team hears of it is when the upset data subject complains to a regulator.  Cue cycles of correspondence with the data subject and regulator, internal disciplinary measures, and staff re-education to put things right.

Don’t leave this to chance.  Training CS staff is essential to ensure they know how to spot a DSAR and when, and to whom, to escalate it.  In addition, make sure you have call scripts that direct staff what to do when an access request is made, and perhaps consider whether you can use technology to automatically spot and escalate any DSARs that come into the CS mailbox to appropriately trained CS staff or privacy team members. 

4.  Technology is both the problem and the solution...

Read The Full Article