A few practical tips for managing subject access requests

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.

We’ve already discussed how holding too much data exacerbates DSAR challenges (see 2 above).  Yet, in a technologically-driven world, the systems we use generate and store ever great volumes of data all the time.

So it’s a given that technology is part of the problem.  However, it’s also part of the solution: anyone who treats responding to a DSAR as a purely manual process will be missing a trick and making far more work for themselves than they need.

For example, why not use technology to build an automated self-service SAR tool for your data subjects?  Maybe have them log into their online account to access the tool (in doing so, they’ll have validated their identity) and then provide an “access my data” link or button under their account that they can click on to access their data.  If you do this then, hey presto, you’ve shown great customer service, saved yourself a laborious manual exercise, and delivered the data promptly.  Further, by providing the data online in electronic format, you’ll likely not only be fulfilling data access requirements, but also data portability requirements too - killing two birds with one stone.

Similarly, if you’re dealing with employee DSARs and need to sift through e-mails, then consider how technology can help here - for example, de-duplicating identical copies of e-mail, removing unnecessary e-mail threads, masking third party e-mail addresses and signatures, removing irrelevant attachments and so on.  While you’ll still end up with a pile of e-mails to review, technology can make that pile an awful lot smaller and save you a lot of time.

5.  Commoditise, commoditise, commoditise.

When doing anything at scale, you need to commoditise.  You don’t want to have to write out responses to DSARs entirely from scratch each and every time.  Create yourself a series of commoditised DSAR responses - from early initial communications simply acknowledging receipt of the DSAR, through to requests for identity verification, through to template letters supplying the information requested.  

Obviously, some level of tailoring will still be required in each case, but preparing templates early on and using them for each and every DSAR you receive will help speed your process up and save you effort.  In addition, by having template responses ready, you can delegate to others to send out DSAR responses for you, safe in the knowledge that they will be using language that you have prepared and approved, with consistency across all data subjects who make requests.  

If you’re a large multinational, you may even want to consider having your templates translate into local languages in advance.  Seeking translation in the middle of a DSAR request will only further eat up precious time.  

Conclusion

DSARs are a fundamental data protection right and it is your organisation’s responsibility to respond to them in the manner, and timescale, prescribed by the GDPR (and other comparable laws, like the CCPA).  While no one ever looks forward to receiving a DSAR, taking the few simple practicable measures described above can make them significantly more manageable and help to keep you on the right side of both data subjects and regulators.