The EU General Data Protection Regulation is now applicable, and many data subject requests have been already sent. But the question about how to identify the data subjects sending requests and be GDPR compliant remains.
It's an important question because, obviously personal data need to be protected, and you need to ensure confidentiality, integrity and availability more than ever. Any data subject-access requests made by unauthorized persons will result in a breach.
At the same time, you must process the data subject requests made under the GDPR promptly and in a way that allows data subjects to exercise their rights, such as access and rectification, data portability, right to withdraw consent, right to object, right to be forgotten, right to restriction of processing and not to be subject to automated decision-making and profiling, which would have significant impact on the individual rights and freedoms. Also, the data subjects have right to contact your DPO, if you have one.
Breaches of personal data naturally are feared by the data controllers for a very good reason and should be avoided. On the other hand, you should beware of being overzealous, as you can be also very well penalized for either making the request process too burdensome for the data subjects or for collecting excessive amounts of personal data just for the authentication itself.
How can I be penalized for doing my best to authenticate the data subjects?
Basically, if you make it too difficult for the data subjects to exercise their rights, by creating for them unreasonable and disproportionate requirements, you will in fact infringe the very basic rights of the data subjects. This way, you risk the highest administrative fines, that is up to 20,000,000 euros, or in the case of an undertaking, up to 4 percent of the total worldwide annual turnover of the preceding financial year, whichever is higher.
It is highly recommended that you do not obtain clearly more sensitive or potentially more harmful data, for the purpose of authentication, than the data that is subject to the request. If you actually need some additional information, it should be the minimum amount and only what is relevant in the given context. This is important not only because of the principle of data minimization, but also to ensure purpose limitation and fairness.
Accordingly, the highest administrative fines, as provided by the GDPR, may fall upon you.
What should be specifically avoided?
Asking for a copy of ID document, passport or other official, government-issued document, such as a birth certificate, as a standard way of verifying the identity of data subjects should be definitely avoided.
The obvious reason why is because it is disproportionate and not always relevant. The less obvious reason is that this is not considered a secure and efficient method of authentication, and the level of assurance as to the real identity of a person, in contrast to what some might think, is quite low.
Authentication in an online environment is widely disputed, and most people will tell you that you should not use the information that basically stays the same for all your life or for a long period of time, such as Social Security numbers or government issued identifiers, as it is likely that such data may already be in possession of unauthorized persons, simply because they exist for a long time. Also, if this would be a prevalent practice, many companies would be, and sometimes already are, in possession of such information, and they very often fall pray to breaches and hacker attacks.
Last but not least, by collecting such information, you will create additional risks for data subjects, as such data may be used, for identity theft or fraud, for example, and you will need to protect it with higher security measures than for the innocuous data that is subject to the request itself, e.g., history of purchased items or the like. Quite likely you would need, under the GDPR, to conduct the data protection impact assessment before implementing such method of authentication.
So how should I authenticate data subjects to be compliant?
You should follow a few easy, yet distinct and very important rules, in order to be compliant and to meet the privacy expectation of individuals.
First, consider the context and reasonable expectations of data subjects. Basically, if some method of verifying identify was good enough when you obtained the data in the first place (e.g., you received them by email), it should be good enough when you receive a request (e.g., email request sent from the same email address).
The GDPR is clear about withdrawing consent, saying that it shall be as easy to withdraw as to give consent. Apply cautiously the same rule for other data subject requests, unless you feel it is unreasonable in the context of risks to data subjects. This means that you also should consider how sensitive the data is and what are the risks. The more sensitive the data, the more effort to authenticate is expected. This is in accordance with the risk-based approach, and you can justify asking for more information or more critical or sensitive information if you do this to protect the data subjects against possible risks to their rights and freedoms.
Even then, use the data you have rather than ask for more new data. It means that you should try to verify the data subject's knowledge (e.g., by asking some questions) in relation to such data that are subject to the request, or that you hold for related purposes, and also consider how the data were obtained in the first place. If your method of authentication was previously nickname and password, the very nickname and password should enable you to process request. If nickname or password were lost, of course, asking for name and surname will not make sense, if they were not linked to the profile.
In the online context, the GDPR explicitly says that identification should include the digital identification of a data subject, for example, through an authentication mechanism, such as the same credentials, used by the data subject to log in to the online service offered by the data controller.
Consider also industry recognized standards, which are widely available, such as that of NIST's digital identity guidelines. They should help you to apply state-of-the-art methods of identification, authentication and authorization, which belong to the foundational concepts and tenets of information security.
What if I cannot still confirm the identity of a data subject who did send a request?
Do not despair or panic! In such a situation, you may refuse to process the subject request unless the data subject provides you with additional information.
In cases where you do not take action on the request of the data subject, the data subject needs to be informed accordingly, within GDPR time limits (without delay and at the latest within one month of receipt of the request) and about the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy.
The GDPR also says that, if the purposes for which a controller processes personal data do not or no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with the GDPR.
Where this is the case, and the controller is able to demonstrate that it is not in a position to identify the data subject, the controller shall inform the data subject accordingly, if possible. In such cases, data subject rights specified in Articles 15 to 20 shall not apply, except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification.
Again, the final and clear guideline is that you should not collect identifying information if you do not need it otherwise unless the data subject himself/herself wishes to prove her identity.
It seems that it is far better and wise to avoid having too much data in accordance with the principle of data minimization, and thus refuse to process some subject requests when not in a position to identify her, then be overzealous and collect too much information just for the purpose of authentication.
photo credit: CreditDebitPro via photopin