Chapter 11: Subject Access Requests – EU General Data Protection Regulation (GDPR): An Implementation and Compliance Guide


As we’ve already seen, a data subject has the right to request the personal information held about them by a data controller. These requests are known as subject access requests, and the GDPR states that they enable the data subject “to be aware of, and verify, the lawfulness of the processing”176.

In making a subject access request, an individual is exercising their right to obtain confirmation that their data is being processed by the data controller, and to have access to that personal data and any other supplementary information to help explain the data revealed to that individual.

The right to access personal information under the Regulation is very similar to that granted by the Data Protection Directive (DPD). The GDPR extends the right to allow data subjects access to additional information, within a shorter timeframe of just one month and also includes more specific information on, for example, the provision of online services for subject access requests177.

The Regulation also highlights the importance of a data subject’s access to information concerning their health. This includes any data in their medical records such as diagnoses, examinations results, medical assessments and any treatments or interventions that have been provided178.

It is worth noting that any organisation that holds personal information could receive a subject access request. This request could come in any format (it does not have to be in writing), could form part of a high-volume bulk request, or require the information is returned in a format that is not used by the organisation.

While organisations that process subject access requests under the DPD will have a head start compared to those starting from scratch, it is clear that subject access requests under the GDPR will place an additional administrative burden on organisations. They need to identify, respond and have suitable systems in place to answer all subject access requests within just one month.

The controller must also give individuals the opportunity to make a subject access request and “to exercise that right easily and at reasonable intervals”179. This could necessitate a review of customer-facing processes, procedures and additional staff training to ensure they can meet the Regulation’s data access and portability rules.

The information to provide

The data controller must provide the data subject with “a copy of the personal data undergoing processing”180. This simple statement has many implications for the data controller in terms of the range of information they must provide when responding to a subject access request.

More specifically, the data subject has the right to access the following information in addition to the relevant personal data:

  • the purposes of the data processing;
  • the categories of personal data stored;
  • where the data has or will be disclosed, particularly to third countries or international organisations;
  • how long the personal data will be stored or, if an estimate is not possible, the criteria used to determine that period of time;
  • any available information on the source of the data, if the personal data was not collected directly from the data subject;
  • whether any automated decision-making processes, such as data profiling, have been applied to the individual’s personal data. If they have, the controller must provide “meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject”181.

Once they’ve received this data, data subjects of course have:

  • the right to request the rectification or object to such processing, or the right to request that personal data is restricted182;
  • the right, under certain limited circumstances, to request erasure of personal data,
  • the right to lodge a complaint with a supervisory authority.

This list is quite extensive and exceeds the previous requirements of the DPD. Organisations that already have systems in place in order to comply with the DPD will need to ensure that they are still adequate for the purposes of the Regulation.

Data portability

Under the GDPR, data subjects have the right to data portability. This is a new requirement that was not covered under the DPD, but it is an important premise of the GDPR, which states that “data controllers are encouraged to develop interoperable formats that enable data portability. That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract”183. This right can complement the right of access and a data subject can request that their data is provided in a “structured, commonly used and machine-readable format”184.

If the subject access request is made in electronic form, then the information should also be provided in a commonly used electronic form, unless the data subject specifically and reasonably requests an alternative format185. The format the information is presented in could have a significant financial impact on controllers who use special formats or only hold paper records. It may, therefore, be necessary for data controllers to develop formatting capabilities to comply with the GDPR.

It’s important to remember that this applies to all information requested from the data controller in exercising a data subject’s rights. You must endeavour to provide the information in a common format, and you must offer to reply electronically if you allow data subjects to make requests electronically. For many organisations, this won’t be a problem: the data is packaged in a machine-readable database format, and you can provide it via a user account web application or similar. For organisations that handle data in other ways, it would be sensible to invest in tools to convert data into a useable format, and to consider offering a web application or similar solution. Note, however, that you only have to offer the information electronically if you allow the data subject to make the request electronically.

Responsibilities of the data controller

Responsibility for complying with a subject access request lies with the data controller and this places new obligations on organisations seeking compliance. Data controllers will need to ensure that data processors are able to provide all relevant information within the one month allotted by the Regulation to respond to a subject access request. It would make sense to design, document and deploy a subject access request process that complies with the specific GDPR requirements, and to train relevant staff in its use, in advance of receiving any such requests.

Building guarantees of responsiveness into service-level agreements (SLAs) is one method of getting processors to help you meet the requirements of the Regulation. You might also be able to arrange direct access to the data as it is held by the processor, or to establish a system whereby you can request relevant data to be fulfilled automatically or with a minimum of human interaction.

The data controller must also provide the data subject with explanations of their rights with regard to rectification or erasure of their personal information, or to objecting to processing activities, as well as their right to lodge a complaint with the relevant supervisory authority. These are all possible results of providing data subjects with their personal data and relevant related information.

The controller must identify where they have collected a requester’s personal data from, if it has not been sourced directly from the individual. The requester also has the right to obtain details of the safeguards applied where their information is transferred outside of the EU and international organisations.

Transparency is a core component of the GDPR. Data controllers have a responsibility to facilitate this transparency at every stage of a subject access request.

Processes and procedures

The GDPR places pressure on data controllers to provide more information in response to subject access requests in a shorter time frame than allotted under previous directives such as the DPD. Controllers should thus outline a specific process for handling subject access requests as soon as is possible, and review the current processes, procedures and tools available to customer-facing teams to ensure they are sufficient to deal with the GDPR’s data access rules.

The controller must ensure staff are sufficiently trained to identify that a request from an individual constitutes a subject access request, which could be made in any format and not just through the channels provided by the data controller. The controller should also ensure that staff are prepared to handle potentially high volumes of requests, given that data subject cannot generally be charged for an initial subject access request under the GDPR186.

If the subject access request is valid, the data must be exported in a structured and machine-readable format. Depending on the nature of the request, the data may need to be delivered in additional formats. The data controller should take reasonable steps to develop new systems, improve existing architecture, or establish a process for converting data to common formats in order to assure data portability.

For many organisations, the simplest solution will be to expand an existing data access portal to allow the data subject to directly exercise their access rights. This has the advantage that the organisation can contextualise the personal data and would also meet the intent of Recital 63, which states that “where possible, the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to his or her personal data”.

The Regulation also states that the right to access personal data or obtain a copy of information through a remotely accessed secure system should also not adversely affect the freedoms and rights of others. To ensure that this is the case, the controller should review the nature of remote access provided and the data that is held there. The controller will need to address, amongst other considerations, how the system proves the user’s identity, the sensitivity of the data available, and whether there are any additional privacy concerns or legal restrictions to making the personal data accessible over the Internet.

Options for confirming the requester’s identity

Confirming the requester’s identity is critical to complying with the Regulation, and the Regulation explicitly enables controllers to require proof of identity from the data subject before they release personal information. This is an important change from the DPD, which does not directly address the need to confirm the identity of the data subject. It also helps to reduce the risk of unscrupulous third parties gaining access to personal data unlawfully.

The data controller must ask for sufficient information to judge whether the person making the request is the individual to whom the personal data relates to (or a person authorised to make a subject access request on their behalf). The controller cannot ask for excessive amounts of information if the identity of the individual is obvious. This point is particularly applicable if the data controller has an ongoing relationship with the data subject.

For example, if an organisation receives a written subject access request from a current employee, it would seem excessive to go through the usual channels to verify their identity by asking for a copy of their passport or utility bill. Because the organisation knows the person making the request, it is reasonable to grant this request automatically and deliver the information directly to the data subject.

If, on the other hand, an organisation receives a written subject access request from a customer where there is no longstanding relationship, it would be reasonable to verify that individual’s identity by asking them to submit specific documentation and information such as date of birth, address, photographic identification, utility bills, and so on.

However, although the data controller must use reasonable means to verify that the individual making the subject access request is the data subject, the data controller must not retain information specifically to meet such data requests.

The requirement that controllers not hold supplementary information about the data subject solely for the purpose of identifying them is stated in Recital 64: “The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers. A controller should not retain personal data for the sole purpose of being able to react to potential requests”. Historically, supplemental information might have been the data subject’s mother’s maiden name, the school they attended, or some other piece of personal information that was otherwise unrelated to the data subject’s business with the organisation.

Where the controller has reasonable doubts as to the identity of the data subject, the controller is permitted to request additional information. The controller should also not refuse to take additional information from the data subject if it is provided “in order to support the exercise of his or her rights”187.

Balancing the need to authenticate data subjects against the demand not to hold supplementary information can be difficult for data controllers, and online services that have no physical contact with the data subject may struggle with such verification processes. The Regulation provides some direction on online authentication in Recital 57, which states that “identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller”.

Multi-factor authentication is one option for verifying a data subject’s identity online, whereby the individual must present several separate pieces of evidence to the system. This evidence usually constitutes at least two pieces of information from the following categories: knowledge (something the subject knows, such as a PIN), possession (something the subject has, such as a credit card or physical token) and inherence (something the subject is, which includes biometric data like fingerprints or vocal patterns).

An individual can also make a subject access request through a third party, which includes (and is often) a solicitor acting on behalf of a client. This adds another layer of complexity to the authentication process, as the data controller must be satisfied that the third party making the request is entitled to act on behalf of the data subject. In this case, it is the third party’s responsibility to provide this evidence in the form of, for example, a power of attorney or other written form of authority.

Records to examine

A key consideration is the records that must be examined to comply with a subject access request. This depends on the nature of the request and of the data controller, but the following records may need to be examined:

  • any information held, or which will be held, on an electronic database or repository;
  • records of correspondence, whether in the form of physical letters, emails, text messages or other formats;
  • records held in a manual filing system, which is highly structured so that information can be easily retrieved;
  • health, education, social service or housing records;
  • any other information held by a public authority;
  • video footage and audio recordings;
  • records of processing activities carried out on the individual’s personal information.

The data controller does not need to provide information where the “subject proves to be impossible or would involve a disproportionate effort”188. For example, information held in a sprawling archive with a large number of data subjects where a high level of processing has been carried out to anonymise those subjects, could prove too costly or time-consuming, or could impinge on the rights of the other data subjects whose information is held in that repository.

Time and money

The data controller must comply with a subject access request “without delay and at the latest within one month of receipt of the request”189, although it is possible to extend this period under certain circumstances, as stated in the Regulation: “That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay”190.

The controller cannot ask for payment to fulfil the subject access request, which was previously permitted under the DPD. Under the Regulation, the first copy must be provided to the data subject free of charge, which is a change for UK-based controllers that could previously charge up to £10 for every copy. The controller can then charge “a reasonable fee based on administrative costs”191 for any additional copies.

Dealing with bulk subject access requests

An organisation may receive multiple subject access requests within a short timeframe or even multiple requests from one source if a management company is acting on behalf of multiple data subjects.

If a bulk request is received, then each subject access request must be considered individually and responded to appropriately. There are many potential resource implications here, so it is vital that the data controller can assess whether all, or any, of the requests are valid. A data controller can also extend the one-month timeframe to respond by a further two months if it receives an excessive number of requests. Whatever the case, the data controller must be prepared to respond to peaks in the volume of subject access requests.

Bulk subject access requests were highlighted in the Information Commissioner’s Annual Report and Financial Statements 2015/16192 for requests relating to compensation claims for health conditions. The ICO “advised Her Majesty’s Revenue and Customs and the Ministry of Defence about the importance of upholding information rights when dealing with high volumes of subject access requests”. A lack of resources is not a valid excuse for not complying with the GDPR.

Right to refusal

If the data controller does not intend to comply with a subject access request, they must provide reasons for this refusal within one month of receiving the request. Grounds for refusal include if the information required for the subject access request may “adversely affect the rights and freedoms of others”193. In other words, the protection of trade secrets or intellectual properties could be a valid reason to refuse to disclose information under the GDPR.

If a data controller decides to refuse a request, it needs to have policies and procedures in place to demonstrate why the request meets the criteria for exemption.


176 GDPR, Recital 63.

177 GDPR, Article 12, Clause 3.

178 GDPR, Recital 63.

179 GDPR, Recital 63.

180 GDPR, Article 15, Clause 3.

181 GDPR, Article 15, Clause 1.

182 NB: Where GDPR Article 16, 17, 18 or 21 applies.

183 GDPR, Recital 68.

184 GDPR, Article 20, Clause 1

185 GDPR, Article 12, Clause 3.

186 GDPR, Article 12, Clause 5.

187 GDPR, Recital 57.

188 GDPR, Recital 62.

189 GDPR, Article 12, Clause 4.

190 GDPR, Article 12, Clause 3.

191 GDPR, Article 15, Clause 3.

192 Information Commissioner’s Annual Report and Financial Statements 2015/16,

193 GDPR, Article 15, Clause 4.