EDPB Guidance on the Right to Access Data

We would prefer if there was some additional guidance on the restrictions to what has to be released, however, there are some good examples in the guidance.

Below are some of the key takeaways and actions from the guidance.

Scope of Personal Data

• There is a wide scope given to the definition of personal data under the GDPR. It includes basic identifiers such as name, date of birth, email address but also extends to medical records or purchase history etc.
• Given the wide scope, it is important to ensure your records of processing activities (RoPA) are up to date to be aware of what personal data you are processing.

Action: Update your RoPA (and maybe your transparency notices)

Receiving Data Subject Requests

• Although a data controller may have established clear communication channels to assist them in facilitating access requests, data subjects are not obliged to use them. The only requirement for data subjects is to not send requests to apparently incorrect emails. This emphasises the importance of awareness training in all departments to recognise a subject access requests and refer it to the data protection team.
  • Example: A data subject who sent a subject access request to the cleaning department of a retailer would have no reasonable expectation that the request would be forwarded to the data protection team as it is a random email address.
  • Example: A data subject who sent a subject access request to the sales department of a retailer would have a reasonable expectation their request would be forwarded to the data protection team as it is not a random or apparently incorrect email address.

Action: Make sure your staff are trained on how to recognise a DSAR and what to do when they do get one

Responding to Data Subject Requests

• Unless otherwise specified by the data subject in their access request, any request should be understood by the controller as referring to ALL data concerning the data subject.
• Where a large volume of personal data is being processed, the data subject may not be aware of the extent of the processing. As to not overburden the data subject with unnecessary information, the controller may provide the data subject with a complete list of the categories of processing undertaken by the controller and ask the data subject to clarify what categories of data they are seeking. The data subject is not obliged to specify and may still request all their data.

Action: Have a process in place to help the data subject narrow down the search (if they want!)

Verifying the Identity of a Data Subject

• To avoid a data breach, a data controller must be able to verify the identity of the data subject before completing an access request. Any measures used to verify the identity of a data subject cannot require information that was not required for initial authentication. Below are some examples of methods used to verify the identity of the data subject and when to use them;
  • Where a request is being made by a data subject through a web portal or application, logging into this account would be sufficient in most instances
  • Where a data subject has provided a mobile number or email address, a controller may send “one-time-use verification codes” to those accounts
  • Where a data subject has answered security questions, the controller may ask the data subject to recite one or more answers
  • Where National ID was required for the initial verification, the controller should redact non-essential personal data on their record. Where possible a controller should avoid storing the ID when verifying and instead the subjects’ record should be amended to include “ID Checked”

Action: Make sure that you are only asking for “sufficient” proof of identification, the rule of thumb is to try and match it to something that you already have on file

Providing Access to a Data Subject

• The general requirement under the GDPR is that requested data is provided in a concise, transparent, intelligible and easily accessible format.
• In addition to the personal data, the controller may have to provide additional information to assist the data subject in understanding the processes their data is being used for.
  • Where personal data is being shared with third parties, additional information from the controller’s Privacy Notice may be included to highlight what third parties have access to the data subjects personal data. This should be tailored to be specific to each request by specifying who data “has” been shared with rather than “could” be shared with
  • Where personal data exists in raw formats (e.g. code or user logs), additional documentation should explain any “jargon” or abbreviations etc

Action: Make sure you have a secure sharing facility when sending softcopy information to data subjects.

Restricting Access Requests

• There is very limited scope under the GDPR to restrict a data subjects right of access. One instance where it can be restricted is where granting of access would adversely affect the rights or freedoms of others.
  • A controller must weigh the competing rights and the impact on each party if a request is granted
    • Example: A voice recording of a sales representative and customer discussing a product in a professional manner would pose a minor risk to the sales representative's rights
• The controller must attempt to reconcile the competing rights
  • Example: Rendering the information of the other party illegible through redaction
•  If there is no way for the controller to reconcile the conflicting rights and grant full access to their data, the controller must inform the data subject of the reasons for their refusal and include information on lodging a complaint with a supervisory authority

Action:  Make sure you have a clear and transparent decision-making process that is documented, when assessing the adverse effects on others, make sure you look at all of their rights, not just their data protection rights