ICO Guidance on Subject Access Requests

The ICO has finally published its updated Guidance on Subject Access Requests (SARs) under GDPR, which is required reading for all those involved in responding to requests from individuals based on their right of access to their personal data and related supplementary information. Whilst there may not have been the avalanche of SARs that were predicted under GDPR, our impression and experience from supporting clients is that there has certainly been a noticeable increase. Without doubt, SARs can often be time-consuming for controllers, particularly where limited information is provided by the individual, and the time period for responding is short, being just one month. The updated Guidance deals with, in particular, three areas of concern for organisations responding to SARs:

Seeking clarification and the impact on the time period in which to respond
The circumstances in which it is legitimate to refuse to comply with a SAR because it is 'manifestly unfounded or excessive'
The basis for being able to charge a 'reasonable fee' in circumstances where a SAR is 'manifestly excessive'

Notably, some of the provisions of the new Guidance arguably make it easier for controllers to refuse to comply with certain types of SARs. Although some may welcome this, it could be another factor ultimately taken into account when the European Commission decides whether or not to confer "adequacy status" on the UK, post-Brexit. It might also be challenged, in due course, through the courts.

Stopping the clock for clarification

Under GDPR, a controller has one month to respond to a SAR. This time period can be very tight particularly where a request is particularly complex or the information sought is not clearly identified in the request, and clarification is needed from the data subject. It is possible to extend the time limit by two months where the request is complex or the individual makes a number of requests. The ICO's Guidance now also provides a mechanism for 'stopping the clock' in order to seek clarification.

Where a controller processes a large amount of information about an individual, it may ask them to specify the information or processing activities that their request relates to before it responds to the request. The one month time limit for responding to the request will then be paused until the clarification sought is received, at which point the clock starts running again. If the data subject does not reply, a controller should wait a reasonable period of time (the ICO suggests one month, but it will depend upon whether there is particular complexity or accessibility issues) before considering the request 'closed'.

Clarification must not be sought on a blanket basis but only where a large amount of information about the individual is being processed, and the clarification is genuinely required to respond to the SAR. Relevant factors as to whether it is reasonable to seek clarification will include the size of the controller and its resources, and the extent to which it will be possible to find all of the requested information by performing a reasonable search. No matter how large the volume of information, if it will be possible to find the information quickly and easily, it is unlikely to be reasonable to seek clarification.

There are limitations which suggest that, in some cases, the ability to 'stop the clock' may be of only minimal benefit to controllers:

If the data subject responds by repeating their initial request or refusing to provide any additional information, the controller is unable to do anything other than comply with the request by making reasonable searches for the information.
Whilst clarification may be requested in relation to certain issues, there may be other information that can be supplied in response to the SAR without seeking clarification, and this should be provided within the normal one month timescale.
The clock only stops once clarification about the information sought is requested; controllers should therefore seek clarification as soon as possible after receiving a SAR.

When seeking clarification, controllers should provide the individual advice and assistance to help them clarify their request, together with an explanation that the clock has 'stopped' until they respond. It is possible to specify that the data subject should reply by a certain date.

What is a manifestly excessive request?

A data controller can refuse to comply with a SAR where it is 'manifestly unfounded or excessive' (it could alternatively seek a fee, see below).

The ICO Guidance provides clarification as to when a request is 'manifestly excessive'. Such a request is one which is clearly or obviously unreasonable, based on whether the request is proportionate when balanced with the burden or costs involved in dealing with the request. Simply asking for a lot of information does not make a request manifestly excessive. All of the circumstances of the request should be taken into account (on a case by case basis, there cannot be a blanket policy) including:

The nature of the information
The context of the request, and the relationship with the individual
Whether refusing to provide the information or even acknowledging it is held may cause substantive damage to the individual
The resources available
Whether the request largely repeats previous requests and a reasonable interval has not elapsed
Whether it overlaps with other requests

We have laid emphasis on notable wording – there is no indication in GDPR that lack of damage to the data subject is a relevant consideration when determining whether to comply with a SAR or not. We expect this proposition (and reliance on it by controllers) to be challenged by data subjects and their representatives.

Where a controller concludes a request is manifestly unfounded or excessive, it must ensure it has 'strong justifications' which can be clearly demonstrated to both the individual and the ICO.

An example of a recent case where a Court considered such issues is Lees v Lloyds Bank where the numerous and repetitive SARs were found to be abusive and based upon a collateral purpose to obtain assistance in preventing Lloyds Bank bringing claims for possession.

Charging a fee where a request is 'manifestly unfounded or excessive'

The general position is that, under GDPR, it is no longer possible to charge a fee to respond to a SAR. However, a 'reasonable fee' can be charged for the administrative costs of complying with a SAR where it is 'manifestly unfounded or excessive' or an individual requests further copies of their data following a request. If the individual does not pay the fee, the controller does not need to comply with the SAR. A fee should be requested as soon as possible and the individual should be given a reasonable period of time in which to respond to the request (again, the ICO suggests a one month period is reasonable for proceeding on the basis that the request is closed where there is no response).

The Guidance identifies the particular activities and expenses to which a fee may relate. In particular, it confirms that it can include staff time, and how this can be calculated: the costs of staff time should be based on the estimated time it will take staff to comply with the specific request, charged at an hourly rate. We note that this inclusion of staff time (for instance in locating, retrieving and extracting information) in the factors which might be taken into account is not necessarily supported by the plain language of GDPR, which speaks of the costs of providing the information, and which might be said to cover only the disbursements incurred when actually sending a response.

The Secretary of State has the power to set out limits on the fee, and these have not yet been set. It may be that, when or if they are, they will provide more clarity, and at least some statutory basis, for the ICO's position. In the absence of statutory limits, the Guidance recommends that controllers establish an unbiased set of criteria for charging fees. These criteria should be made available on request (but need not be published online) and should explain: