Brazil: Operationalising the LGPD: Part One - DSARs & breach notification requirements
Brazil's data protection law, Law No. 13.709 of 14 August 2018, General Personal Data Protection Law (as amended by Law No. 13.853 of 8 July 2019) ('LGPD'), is on the verge of coming into force. Approved back in August 2018, the law was expected to become effective in August 2020, but it now seems that this deadline could be later extended to May 2021 due to the COVID-19 ('Coronavirus') pandemic. In Part One of our Operationalising the LGPD series, Felipe Palhares, Partner at Palhares Advogados, breaks down requirements in relation to data subject access requests ('DSARs') and breach notification.
The LGPD shares a lot of commonalities with the General Data Protection Regulation (Regulation (EU) 2016/679) ('GDPR'), as it was clearly inspired by the European legislation. However, complying with the GDPR does not mean that you would also be fully complying with the LGPD, as there are several differences between the two legislations. Two of the major distinctions between the LGPD and the GDPR are those related to the provisions that set forth how to handle data subject access requests ('DSARs') and those that establish breach notification requirements.
The LGPD prescribes a range of rights that are available to data subjects under the law, including the right of getting access to a copy of their personal data processed by the controller upon an express request to be delivered to the controller by the data subjects or by their legal representative. Apart from that, there is a lack of clarity under the LGPD on how controllers should handle such DSARs, especially on the deadlines to respond to them and on how to authenticate the data subject involved before providing the information requested.
The LGPD sets forth two specific deadlines for complying with a DSAR: the controller should either provide the data subject with his or her data immediately, in a simplified format; or the controller should answer the request with a clear and complete report that states the origin of the data, the criteria used for the processing, and its purposes within 15 days from the date of the request.
Although there is no explanation in the LGPD for what would be a 'simplified format,' it appears that this would actually be something close to a 'yes' or 'no' answer to the question of whether the controller processes data related to that individual; considering that a more complete answer is defined in the second scenario, which requires the provision of a clear and complete report on the data.
Another instance where an answer in a 'simplified format' could be provided is when a controller makes available a user self-service portal or platform that is capable of automatically retrieving and presenting some data, even if it is only simple record information such as names, shipping addresses, last purchases, and the like. Further information could be requested but at least some information, in a simplified format, would be made available immediately to the data subject.
Regarding the second scenario, where a clear and complete report is required, the LGPD also brings some uncertainty. Firstly, not only is the timeframe of 15 days significantly shorter than the one set forth by the GDPR, but there are also no provisions under the LGPD allowing an extension of that deadline, regardless of the volume of requests or their complexity. Although the LGPD states that this could be later regulated by Brazil's data protection authority ('ANPD') (not structured yet), which could set different timelines according to the sector of a company, at the time of publication, 15 days is the maximum deadline allowed for a response under the LGPD.
Secondly, the metric assigned as the beginning of the count of a deadline is also problematic. According to the LGPD, the deadline starts on the date of the request but the law is completely silent on how the request should be made, especially whether it can be made orally, via email, social media, or even mail correspondence. The latter is highly complex as a letter could be sent via postal service on a given day and arrive at its destination more than 10 days later, thus making the beginning of the count the day the request was made (the day the letter was sent) not feasible.
Thirdly, there is the issue of authenticating the data subject, which is not taken into consideration by the LGPD. Nothing in the LGPD says that a request should be verified in order to establish that it was in fact made by the data subject or their legal representative. Nonetheless, complying with the provisions set forth by the LGPD, especially with its guiding principles of safety, prevention, and accountability would entail making sure that personal data is not disclosed or made available to unauthorised third parties, which would in turn result in a data breach.
It gets even trickier considering that the LGPD also does not provide any specific situations where refusing the request is acceptable, such as where the request would be manifestly unfounded, excessive, or have a repetitive nature. The LGPD only states that in case the controller cannot immediately adopt the measures requested by the data subject, it should answer to them with an indication of the reasons that prevent it from immediately acting on a request. And it goes further as the LGPD sets forth that any requests shall be responded free of charge.
It goes without saying that controllers should authenticate data subjects prior to delivering the information requested by DSARs but they also should account for the time that will take to do that and have in mind that compliance with the 15 day deadline is still necessary. On that note, it is extremely important to act fast on any access request received to give some leeway to answer the request within the timeframe established by the LGPD and to structure a streamline process that allows tracking of the requests, and the ability to instantly flag those which have not been authenticated yet, providing the data subject with a reminder where he or she fails to verify their identity. Although this could still be questioned by the data subject as a failure to comply with their access request, as the LGPD does not set forth any express need for authentication, it is a safer and more defendable route than freely granting access to personal data by unauthorised parties.
The LGPD states that the information requested on DSARs shall be provided either by electronic means or in writing, according to the choice manifested by the data subject. Furthermore, where the processing has been based on consent or on the need to fulfil a contract, the LGPD expresses that the data subject is entitled to request a complete electronic copy of all their personal data, in a format that allows the data's subsequent use in other processing activities.
Data breach notification under the LGPD
Besides these specificities regarding DSARs, data breach notification requirements under the LGPD are also remarkably different than those established by the GDPR. The LGPD is actually more stringent than its European counterpart in this case, as it prescribes that a controller should notify both the ANPD and the involved data subjects of any security incident that may result in a risk or a relevant damage to the data subjects.
There are two factors here that make the LGPD a more rigorous legislation than others around the world: the first is that in all cases that require notification both the ANPD and the data subjects must be notified of the incident. There are no thresholds to limit when only the ANPD may be notified, thus creating a general obligation to always communicate the incident to the data subjects as well, which puts heavier burdens on controllers. While the GDPR allows the controller to notify the supervisory authorities alone in some scenarios, the LGPD makes no such differentiation. According to the gravity of the situation, the ANPD may actually order the controller to make a wide disclosure of the fact in the media.
The severity of such provision is heightened by the lack of a definition of what would be a security incident to trigger the notification requirement and by the absence of more restrictive bounds regarding the level of risk that triggers such requirement. This is especially problematic as a 'security incident' is a broader term than a 'data breach.' Although all data breaches are security incidents, not all security incidents are necessarily data breaches, such as, for example, distributed denial of service attacks, malware infections and unauthorised accesses to corporate information.
If the language of the LGPD is interpreted to, in fact, include such security incidents beyond data breaches, the notification requirement would be triggered in a huge array of situations. As this is a possible interpretation of the LGPD, a more conservative approach would be to prepare companies to notify security incidents as a whole where the second threshold established by the LGPD is triggered. And that second threshold is also set on low standards.
The language adopted by the LGPD here is vague and subjective: 'result in a risk or relevant damage to the data subjects' gives room for several different interpretations. First of all, there is no clear prescription of what level of risk triggers the notification requirement. The idea of risk, alone, with no attribution of its actual level could be easily viewed as an indication that any kind of risk, even a low risk, would trigger the requirement, which once again is a more stringent measure than the one imposed by the GDPR. As almost all situations where there is a security incident carry some intrinsic risk, this would amount to an unlimited obligation of notifying each and all security incidents, regardless of it actually being able to inflict damages to data subjects.
The last term used by the LGPD is also highly questionable as 'relevant damage' may be viewed in different forms, according to the perception of the data subject involved. A breach of sensitive personal data, depending on the specific type of data, may be regarded as resulting in relevant damages to some but not to others.
In any case, at a minimum the notification should include a description of the nature of the personal data affected, information on the data subjects involved, a description of the technical and security measures adopted to protect the data, the risks related to the incident, the measures adopted or that will be adopted to mitigate or revert the effects of the incident and, if the notification is not made within the prescribed deadline, the reasons for the delay.
Under the LGPD, the notification should be made within a 'reasonable period of time,' a term that will be defined later on by the ANPD. While the ANPD is not fully functioning and there is no specific regulation on this issue, it is advisable to use the GDPR standards of completing the notification not later than 72 hours after becoming aware of the incident, as this will most likely than not be deemed as a reasonable period of time by regulators and courts in Brazil.
Operationalising both DSARs and data breach notification requirements set by the LGPD into an organisation's privacy program is a challenge and should be performed carefully as those are two instances where the Brazilian law largely diverges from the prescriptions of the GDPR and that are expected to be highly enforced by the ANPD.
Moreover, taking into consideration that Brazil has a high level of litigation, both issues should also be frequent claims to be brought by data subjects before the courts, where the procedures established by the privacy program of a company defending against such claims will be thoroughly scrutinised and reviewed in order to assess if they comply with the LGPD.
Felipe Palhares Partner
Palhares Advogados, São Paulo