What data controllers should do before receiving a possible subject access request
As a data controller, you obviously know it: one day you may receive an access request from a data subject.
Being available to promptly comply with the request when you receive it is far from being enough. Indeed, there is much more that a data controller should do. Organizational preparation is key.
Among other things, as a data controller, you should set up an organization that allows you to do the following:
2. You must have in place a good procedure to handle the request, including, providing proper guidance to processors and providers in outsourcing;
3. All the requests must be channeled to individuals capable of answering. Actually, every employee that may receive it should be able to recognize it as a access request and know whom to forward it, if he or she is not the right person to handle the request;
4. The relevant employees must be trained to promptly answer the requests. They must also be instructed on what to ask to confirm the identity of the data subject and the legitimacy of the request (so as to avoid data breach);
5. The data controller must have in place an organization that monitors the data processing, which allows those in charge of responding the requests to know to whom they should forward the request or, in the alternative, where to find the answer to data subject’s inquiry;
6. Employees must be made aware of deadlines and must know how to ask for an extension or how to reject an access request. An alert system allowing to schedule tasks is a useful tool;
5. Employees must know that they must deliver a complete and intelligible feedback to data subjects (e.g., providing appropriate language and format, and data mapping). In particular
– if data subject demands to know which data is processed, that data must be provided in an accessible and intelligible format, and in plain language;
– if data subject demands cancellation or limitation, data controller should use automatic systems that minimize errors;
6. Data controller must be able to smoothly and promptly deal with peculiar situations. For example: am I allowed to provide third party’s data? Can I omit that data if by omitting it, I provide incomprehensible data? How do I deal with request from a data subject’s heirs? How do I deal with access requests involving whistleblower situations or bank secrecy?
But this is not enough: Article 12 of the Regulation (“Transparent information, communication and modalities for the exercise of the rights of the data subjects) provides that the controller must “facilitate” the exercise of the right of access (and the other data subject’s rights). This means that when the controller is faced with an incorrect or incomplete request, the controller cannot simply refuse to answer. The controller shall indicate the additional information or documents necessary to complete the request.
In short, the GDPR requires the controller to adopt a productive approach. For example, in whereas 63 it 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. That right should not adversely affect the rights or freedoms of others, including trade secrets or intellectual property and in particular the copyright protecting the software. However, the result of those considerations should not be a refusal to provide all information to the data subject. Where the controller processes a large quantity of information concerning the data subject, the controller should be able to request that, before the information is delivered, the data subject specify the information or processing activities to which the request relates.”
Providing remote access entails the adoption of all relevant authentication procedures and, generally, compliance with duties concerning data security. Furthermore, whereas 64 specifies that “a controller should not retain personal data for the sole purpose of being able to react to potential requests.”
This should also affect the deactivation and deletion of profiles. Finally, this aspect should also be coordinated with the rules concerning data portability.