Over the last year or two there has been an increasing trend for data subject access requests (DSARs) made under the Data Protection Act 1998 (DPA) being used as a way of obtaining pre-action disclosure. Indeed, there have been two fairly recent cases that have considered this way of using DSARs, the Taylor Wessing case and the Community Safety Development case. Given the outcome of these cases as originally decided, and regardless of the outcome of any appeals, it is clear that the Information Commissioner’s Office (ICO) will take some convincing to dismiss a DSAR on the basis of an “abuse of process” argument (especially in light of the Community Safety Development case).
With this in mind, as well as the ever-looming General Data Protection Regulation (GDPR), the safest approach for data controllers to adopt is to ensure that they take the necessary steps to respond to the DSAR, regardless of any suspicions they may have about the purpose of the DSAR. Organisations commonly do not have processes in place for collecting personal data relevant to a DSAR request, which can cause problems. These processes often have to be created from scratch while responding to a DSAR. Alternatively, even if there are processes in place, there may not be protocols and procedures to actually deal with the information that has been returned by the searches. There may be many reasons for the lack of such processes or procedures, from not having received a DSAR before to a lack of understanding of what falls within the concept of personal data. Regardless of the reason, having to develop processes and procedures “on the fly” means that there is less time to actually deal with the DSAR that has been received.
Many data controllers underestimate the time it takes to respond to a DSAR, and the resources that may be needed to complete this task in the alloted statutory timeframe. I often tell clients to think of DSARs in the same way as litigation disclosure, but without the boundries or limitations which surround litigation disclosure. With this in mind, any action that reduces the hassle or time needed to comply with such a request, and that can be taken before a request is even received, is a good thing. In the context of a DSAR, data controllers should develop policies and procedures for handling DSARs as a standard practice. In order to do this, a data controller will need to have a good understanding of what personal data they have, where that personal data is stored and processed and, importantly, who to contact to get a search authorised and underway.
Of course not every DSAR will be the same (although there may often be similarities or similar types of requests), and so the searches may need to be tailored for each DSAR request. Knowing what you have and where you have it will allow for a quick initial decision about what systems should be searched for relevant personal data. This may seem fairly simple, but as organisations start sharing platforms and systems this process quickly becomes messy. After all, it is only the personal data held by the data controller that must be disclosed in response to a DSAR, not all information that a data controller may have access to. In developing their process for systems searches, organisations should question if they have access to personal data and are processing it in the capacity as data controller, or merely as a data processor. Information they access as a data processor must be ring-fenced from any DSAR search performed in relation to their data controller activities.
It is also beneficial to have a document setting out the types of searches that will be performed if the organisation receives a DSAR. What are the keywords, nicknames and other search criteria that will be used when looking for the personal data requested? As with understanding the systems to be searched, any pre-prepared list of search criteria is not something cast in stone. Rather, it sets the base from which to start. It could be that there are certain terms or criteria that will always be used (for example, full name, first initial and surname and initials are always used) and any other criteria are then considered on a case-by-case basis depending on the nature of the request and the individual concerned.
Data controllers can also prepare for receipt of a DSAR by having a procedure in place for handling the data that is returned from the searches. This procedure should be flexible, depending on the nature of the DSAR and the volume of data returned from the searches. If the request is a simple one and the volume of data small, then it may be easy for a single individual to review the personal data and prepare the response to be sent to the data subject. If it is not simple (for example, the request is made in the context of possible litigation or during the course of litigation) or a significant volume of data is returned from the searches, then data controllers should have clear plans about how to handle this. Are there steps that can be taken to separate immaterial data from the personal data that is actually relevant to the DSAR? Who will handle this process? Do you need to use outside resources to assist with this task? Having clear plans in place saves time and gives data controllers a better chance of meeting their statutory obligations, rather than wasting time trying to figure out what to do.
Setting up the above processes and protocols in advance of any DSAR will mean that data controllers are able to “attack” DSARs when they arrive, rather than just react to them. This, in turn, should save a little bit of time, which will become even more crucial when the GDPR comes into effect in 2018. The period of time that data controllers will have for compliance with a DSAR under the GDPR is just one month, as opposed to 40 calendar days under the DPA. In addition, the penalty for not complying with the DSAR requirements (including the response time) will increase significantly under the GDPR. Currently the maximum fine in the UK for a serious breach of the DPA is £500,000. Under the GDPR, failure to comply with the DSAR requirements could cost a data controller the higher of 4% of annual global turnover for the previous financial year or €20,000,000! With the possibility of such a penalty hanging like the sword of Damocles over the heads of data controllers, developing proactive ways in which to deal with DSARs seems to be the very minimum that data controllers can do to manage this compliance requirement.
Excellent article Penelope, very thorough.
We are completely involved in ensuring asset/data breaches do not occur during end of life IT equipment disposal but my experience tells me that little thought is given in this area. The largest risk of a data/asset breach can be not following InfoSec i5A guidelines when disposing of electronic data whether the data resides on traditional HDD’s, SSD’s or other data carrying assets. More education should be made available from the ICO in this area as misleading information is rife in the industry which means the staff normally tasked with asset disposal can easily make uneducated decisions which they sincerely believe to be correct. This is fine until an organisation is audited, at which point it is quite often too late
AND
then there is the WEEE legislation which can often be an after thought.
Large fines are also being awarded for illegal IT asset disposals when equipment is found on landfill sites although the organsiation where they came from often believe they will be dealt with ethically and legally by the disposal companies they choose. Good article non-the-less.
Thanks
Ray Collyer –
Greenworld Electronics Limited