Skip to content

How to Avoid Falling Foul of a DSAR Breach

| Written by Imogen Fraser-Clark

Since the introduction of GDPR in 2018, Data Subject Access Requests – more commonly known as DSARs – have seen a monumental surge.

To the uninitiated, a DSAR is when an individual (or ‘data subject’) requests that an organisation provide evidence of all of the personal data they have stored on that particular individual.

These requests are most commonly made by employees to their employers – often to support their case in a tribunal, grievance, or some other form of legal dispute.

Today, DSARs are not only becoming more frequent, they’re also becoming more costly and more complicated. Increasing numbers of businesses report having to take on new staff, or even implement new technology, just to cope with the operational strain that a DSAR can create. But it doesn’t have to be this way. With sufficient knowledge and preparation, you can handle a Data Subject Access Request without it having an adverse effect on your operations, your productivity, or your bottom line. Read on to find out how…


Recognising when a DSAR has been submitted


Day 1 card isolated on white backgroundOne thing that makes DSARs so difficult to handle is that there is no official process or protocol for submitting one.

This can make them difficult to recognise – particularly if it comes through to a junior team member in a non-legal department, such as a social media or admin executive. Regardless though, once a DSAR has been made, the recipient organisation has one calendar month to fulfil the request – so any additional time it takes to recognise a DSAR, and figure out who it should be escalated to, is likely to be time you can’t afford. Missing this deadline can lead to serious sanctions from the Information Commissioner’s Office (or ICO), not to mention lasting damage to your credibility and reputation.

Because of this, it’s vital that staff at every level of your organisation, from operations to HR to legal, have a foundational knowledge of what constitutes a Data Subject Access Request. So whether it comes via email, or over Twitter, and no matter how formally or casually it’s worded, your team can recognise it, escalate it, and ensure it is treated with the appropriate levels of efficiency and severity.


Know what information you have to supply


While your gut reaction might be to find some kind of loophole, or run far far away, being faced with a DSAR means you have a legal duty to conduct a proper and thorough process on behalf of the requester. As well as collating and sending across the requested data itself, the organisation on the receiving end of a Data Subject Access Request (the ‘controller’) is also legally obligated to send across the following:-

- The purposes for storing the data

- All parties the personal data has been disclosed to (or who it may be disclosed to in future)

- How long the data will be held for

- Where the data has been sourced from (unless obtained directly from the data subject)

- Clarification of how the data has been or will be processed, and the reason for this.

In your communications with the requester, it’s also important to reiterate their rights. Remind them that they withhold the right to object to the processing of their personal data, and may even request that these processes be rectified, erased, or otherwise restricted.


You may need to make redactions


TOFU-part2-redact_imgWhile it is vital that controllers comply with the rules and regulations of a DSAR, they must also ensure that by fulfilling the said request, they do not jeopardise the security and privacy of any other data subjects, or of their personal information. In short, the information you provide to the requester following a DSAR can only include the personal information of the data subject alone. If it includes the personal information of other parties without good reason, then you may be at risk of non-compliance and of facing the repercussions that come with that.

So how can you fulfil a DSAR to the best of your ability without compromising anyone else’s information security? The answer is by redaction.

Controllers are required to redact any potentially sensitive information from the data they send across. This ensures that the privacy of any third parties remains secure and intact. However, it’s worth noting that there are no cut and dry rules when it comes to processing third-party information. The way you handle this should be thought about thoroughly and dealt with on a case by case basis. If any exemptions are made to the usual protocol for good reason, be sure to highlight them in the information you send across, and add annotations explaining why.


Prevention is always better than cure


If you take one thing away from this blog, it should be this. When it comes to handling DSARs as effectively and painlessly as possible, preparation is everything. That means not just educating your organisation on what a DSAR is and how to notice one, but ensuring you have established systems, processes and workflows in place so that each one can be dealt with with the same level of diligence and efficiency. In fact, it may be that you need to strip things back even further and shine the spotlight on your data retention policies themselves. Having a rigorously planned DSAR response strategy is excellent, but if the data handling practices of your organisation aren’t up to scratch, it won’t be enough.

Your aim here should be to put an end to storing data for the sake of it. All the data held by your organisation should be held for a reason – if you can’t justify why information on your systems is relevant, or there is no lawful reason for processing it, then it should be disposed of. As with many things in the world of litigation, prevention is always preferable to cure.

Looking for more information on how to complete a DSAR or how DSARs should be handled? Take a look at our Subject Access Request page, or download our FREE eBook now! (Click the image below)

New call-to-action