The ICO recently published new guidelines to further explain the rules regarding a data subject access request (DSAR). This was welcome news for a number of people who were confused about certain scenarios. We’ll look at the basics of the DSAR and how the ICO is providing more concrete examples for data controllers to better understand what’s expected of them.
The Nature of the DSAR
A DSAR is any request from a data subject that pertains to their information. The definition of a subject access request (SAR) is intentionally broad and can cover anything from a phone call to a hand-written letter to an email. People are allowed to ask a data controller to erase their information, object to the collection of certain details, or restrict the processing of their data.
However, these requests can prove more complicated for controllers. It’s not always clear who the person is based on the details provided. If the requester doesn’t give the controller key details, then it would be unreasonable for the controller to complete the request. If the data subject is simply trying to cause havoc within an organisation, then the data controller isn’t expected to spend countless hours trying to comply. Since the interpretation of these guidelines could be viewed in different ways by different people, the ICO is doing its best to clarify the terms.
3 Key Differences
Data controllers were first notified of DSAR laws at the end of 2019. The ICO received hundreds of responses offering feedback of every variety, including questions about how the rules applied to certain situations and whether exceptions could be made. After reviewing the correspondence, the ICO noticed several key themes repeated again and again. In an effort to support organisations beholden to these rules, the ICO was prompted to prepare the following clarifications.
Stopped Clocks
Data controllers bear the burden of gathering additional information if the data subject hasn’t fully identified themselves. So if Ann James emails a company and there’s no way to cross-check her name and email address, then the controller might have to email the data subject for more information in order to move forward with the request. If the email goes into a Spam folder or is otherwise ignored by the requester, then the data controller might be left feeling at a loss of what to do next.
This is why the ICO is allowing data controllers to stop the clock, giving them enough time to fulfill their duties. According to the ICO, you should only make further enquiries if it’s absolutely necessary and it needs to be done within a reasonable timeframe. This means that you can’t request additional information on day 29 of the 30-day time limit. The goal is to give the controller and requester a reasonable cushion to communicate with one another.
Manifestly Excessive Request Definition
This term refers to the right to deny a request if it’s manifestly excessive, and the tongue-twister was met with some confusion. What exactly constitutes manifestly excessive? In a technical sense, the controller is meant to judge the burden of complying with the request against the severity of the consequences should the request go unfulfilled.
Here are a few key examples of when a request would likely be judged to be unfounded:
- The individual is making the request without any intention of exercising their access rights or if they’re using the request for their own gain. For instance, if a customer asks to be deleted from all records, unless they’re given a free product.
- The request explicitly states it’s being made to cause disruption to the company. For example, a customer states that they want to waste the staff’s time so they can’t devote it to other matters.
- The request is accompanied by reckless accusations that have no basis in truth. For instance, if a requester states that the organisation is a criminal front without any evidence to support it.
- The request is targeting a particular person with whom the requester holds a grudge. For example, requesting that just one particular employee should not have any access to their information.
The ICO has made this a little clearer by prioritizing data transparency above all else. In other words, to justify an excessive request, you would really need a very good reason. If there’s any ambiguity in the case of a dispute, the point will go in favor of the requester. It’s up to the data controller to consider the nature of the request, context, relationships, and the consequences of a refusal before making their final decision.
Admin Fees
The financial burden for a data controller can be heavy when it comes to responding to all the requests. Staff hours will need to be surrendered to tracking down data subjects, and this can quickly influence productivity across the board of an organisation. In the case of excessive, unfounded, or repeat requests, the ICO has conceded that it would be fair for data controllers to charge an admin fee in these cases. You can also charge a fee if the subject requests additional copies of their information following a request.
When you determine a reasonable fee, you can take into account who’s processing the data, how long it takes to find, and how you’re communicating with the data subject. So you might factor in the costs of postage, equipment, and staff time used. It should be noted that there are no official recommendations on fees. It’s up to to the controller to decide.
The purpose of the DSAR is to provide a convenient way for data subjects to exercise their rights. No complicated forms to fill out, no hour-long phone calls, just a simple ask that data controllers can respond to. Yet the complications of these requests are all too evident when you start to fulfill them. The staff at the ICO is doing everything they can to ensure that organisations have the information they need to make smarter decisions that still protect the rights of the public.