What is a Data Subject Access Request?
This part 1 of a series of articles on ‘What is a Data Subject Access Request’ you can read Part 2 here.
Data Subject Access Requests are new under the GDPR and come with the right to be aware of and verify the lawfulness of processing if a data subject requests from you. Data Subjects can exercise this right to obtain confirmation of what data you’re holding and how it’s been used. DSARs must be provided to customers within 30 days of the original request being made and this request could come in any format (e.g. A Data Subject may call, E-Mail, Write a letter etc – You must take it as it comes).
One of the primary examples given for DSARs is that around the Health industry, for us in the UK it gives a data subject access to all of the information concerning their health including any data in their medical records such as a diagnosis, any test results, Doctors/staff notes, treatments etc.
Handling an initial request
It’s important to provide an easy to use method for DSARs the easier it is to find this method and fill in, the more likely it is for a data subject to use it. Make sure that if you have a website that there is a link in the footer, or perhaps if applicable clearly in the log-in area as data subjects don’t have to use it, you can’t make any requirement or limitation on them on how they make a DSAR. So train your team to recognise one when they see it or hear it as a request could come in any format (doesn’t have to be in writing), it could also be part of a bulk set of requests and so the better you have the initial inflow procedure (and staff comfortable with recording these DSARs) the better.
It’s clear that these sort of requests especially for a long-term data subject (e.g. Someone requesting 30 years of medical records, 10 years of bank records, or even two years of social media records) is going to take time to produce and is unlikely to be a small document and so the system you have in place must be able to track, trace and respond to data subjects within the 30-day limit. This includes a procedure in authenticating that the data subject making the request is entitled to actually have that information (e.g. That they are making a request about themselves and that the person they say they are, is who they are).
Verifying the requesters identify.
When you’re going to be providing personal data to someone who has requested it, potentially very sensitive information you better be damn sure that the person requesting it has the right to do so. The most likely scenario is that it’s someone requesting information about themselves or a parent about a child. The GDPR requires you to seek enough information (but not excessive) from the requester that you believe is sufficient to verify their identity (or their right to request on behalf of someone else).
This means that if one of your employees makes a request about themselves then it’s unlikely you’ll need to make any verification checks – You should know your employee and be able to verify them on the spot. However, if the person making the request is one of 100,000 customers on your database that you will only ever have known as a statistic in a meeting then you’re team are going to want to verify specific bits of information about them (such as secret questions and responses) or even requesting documentation such as photographic identification, utility bills (The same evidence that you’re likely to need if opening a bank account or requesting a mortgage). It’s important to remember that you cannot store the information provided to you for verification – It needs to be destroyed no matter if they pass or fail the verification. It’s also possible to verify a user by asking them to sign-in their account area held with you (say if an Energy provider) and submit a DSAR verification request or through a multi-factor system (such as those used by online banking). As long as you as an organisation the person is who they say they are (and you can evidence the logic in that decision) then you can authenticate them.
While Data Subjects must receive their answered DSAR within 30 days, you can in theory pause this counter when you request the customer verify themselves and only continue it once you are happy.
What you should provide to the Data Subject.
When a DSAR is made the data subject may have requested ‘all information’ or they may have been more specific. It’s possible during the authentication stage with the data subject that you might be able to limit down the scope after speaking with them to understand what it is they actually want to see but otherwise, you provide them with a ‘copy of the personal data undergoing processing’ with the organisation as a controller (including data processors that you might use).
As titles you’ll need to provide them with the following in an organised and clear format;
- The purposes of the data processing
- The Categories of personal data held.
- To whom the data has been, or is likely to be disclosed (such as third-party processors – especially when these are outside of the European Economic Area EUA).
- How long the personal data will be stored for – or where this information is variable then a reasonable estimate.
- Any and all information regarding where this data was sourced, or where it was sourced directly from the data subject then when this was (and if they agreed to any consent agreements, contractual etc as well as a copy of those terms).
- Whether the data held has undergone any automated decision-making processes (such as data profiling) – If so then the rational and logic used by the automated process must be described with any consequences listed.
Finally, you’ll need to provide them with the organised and formatted ‘raw’ information of the records you have on them. This information should be redacted to protect the rights and freedoms of other data subjects and is likely to be redacted again for any business confidentiality requirements (where this doesn’t infringe on the rights and freedoms of the original data subject making a request).
Making sure you don’t forget any ‘raw’ information/records
There is no such thing as ‘accidentally’ leaving out information of a DSAR. It is your responsibility as a controller to ensure everything you have is presented to the data subject so make sure ahead of time you have a data map as well as a checklist of ‘other’ resources in which to check such as;
- List of all electronic databases
- List of all paper-based or archive databases
- Records of written (letters) or digital (email, chat, text messages etc) correspondence
- Security video footage (or other general video or audio recordings held – such as those from recorded phone calls – or in the case of the Google Assistant or Amazon Alexa anything you’ve ever said to them).
What about information stored with a third-party that I use?
Responsibility for complying with the DSAR under GDPR is with the Data Controller – You need to obtain the information from any Data processors that you use. You also need to make sure that each of your third-party data processors is able to provide this information to you easily in the first place. Should you be unable to provide the data subject with the information requested under the DSAR because a third-party Data Processor is unable to give it to you then it’s you who will be at fault and you who will be reported, investigated and potentially funded by the ICO.
As part of any contract you with a third-party data processor you should have a ‘Data Processing Agreement’ written with GDPR in mind. Apart from ensuring that they comply with the GDPR, you should also include Service Level Agreements (SLAs) that require them to provide you with the data requested within a reasonable time (perhaps 7 days) or require direct access to the data they process for you so you can fulfil it yourself automatically.