A Lei Geral de Proteção de Dados determina que o controlador deverá comunicar a ANPD e os titulares de dados em caso de incidente envolvendo dados pessoais que acarretem risco ou dano relevante aos titulares de dados.
No entanto, a legislação não traz muitas informações sobre quando os incidentes de dados devem ser notificados à autoridade e aos titulares. Para esclarecer essa questão, vamos tratar de algumas situações fictícias que precisam ser comunicadas aos titulares, à autoridade ou apenas registrar internamente – essas recomendações foram feitas com base no guia 01/2021 emitido pelo EPDB (Conselho Europeu de Proteção de Dados).
Antes de entrar nas situações, é oportuno dizer que a necessidade de notificar a autoridade e os titulares varia conforme o tipo de violação, natureza, sensibilidade e volume dos dados pessoais afetados, bem como do plano de resposta ao incidente, da quantidade de titulares que podem sofrer com o incidente, quanto tempo durou a indisponibilidade dos dados, entre outros, já que modificam o risco aos direitos e liberdades dos titulares de dados.
O primeiro caso que podemos citar é sobre o Ransomware, um código malicioso enviado por um atacante para codificar os dados pessoais e impossibilitar o seu acesso para pedir um valor de resgate para “devolver” os dados.
Por exemplo, os computadores de uma pequena empresa, contendo dados criptografados, foram expostos a um Ransomware. A chave de descriptografia não foi comprometida. O atacante só tinha acesso a dados criptografados. Em parceria com uma empresa de cibersegurança foi constatado que os dados apenas foram armazenados por criptografia pelo atacante, sem vazamento deles. Os dados pessoais afetados pela violação referem-se a clientes e funcionários da empresa, somando algumas dezenas de indivíduos. Um backup estava disponível e os dados foram restaurados em poucas horas. Não teve nenhuma consequência na atividade da empresa.
Nesse caso, o atacante teve acesso aos dados pessoais, o que confirma um incidente, mas como estavam criptografados não podiam ser utilizados ou lidos, o que reduziu os riscos aos titulares, inclusive porque existia um backup ativo e utilizável. Sem backup, os dados são perdidos e a severidade poderia aumentar.
A partir disso, o Controlador após a análise dos riscos e plano de respostas ao incidente determinou improvável que a violação surtisse um risco para os direitos e liberdade das pessoas, portanto não há necessidade de comunicar os titulares nem a Autoridade, mas devem ser documentadas internamente, para avaliações e melhorias.
Seria diferente se o alvo do ataque fosse um hospital, em que os dados estão associados a milhares de pacientes e funcionários e a restauração dos dados demorou 2 dias úteis, levando a cancelamentos e adiamentos de cirurgias e diminuição do nível de serviço.
Assim, como envolve dados pessoais sensíveis – exames e informações de consultas, por exemplo – e a restauração levou um certo tempo, tornando-o indisponível, há um alto risco devido às consequências das pessoas afetadas e, por isso, deve ser documentado o incidente internamente, além de comunicar a autoridade e os titulares diretamente afetados nesse período.
Outra situação, é quando o colaborador, antes de sair da empresa, copia os dados de clientes para entrar em contato posteriormente para fins comerciais próprios.
Nesse caso, pode-se interpretar como um risco moderado a alto pois não se sabe exatamente como o ex-colaborador irá utilizar esses dados.
Porém, como não são considerados dados sensíveis as informações de contato, a quantidade de dados copiados foi baixa e o banco de dados do controlador permaneceu intacto seria necessária uma notificação à autoridade e registrar internamente o incidente.
E quando o notebook do colaborar é roubado/furtado? Supõe-se que dentro do computador, continha nome, sobrenomes, endereços e data de nascimento de mais de 100.000 clientes da empresa. O acesso ao HD não foi protegido por senha e os dados poderiam ser restaurados a partir de backups diários.
A falta de proteção por senha ou criptografia deixou o notebook vulnerável. Bem como, a falta de medidas básicas e a impossibilidade de identificar os atingidos aumentam o risco aos direitos e liberdades dos titulares. Por conta disso, deve ser registrado internamente, comunicado à autoridade e os titulares.
Podemos citar também, casos de engenharia social, como o roubo de identidade. Por exemplo, uma pessoa se passa por um cliente de uma empresa de telecomunicações pedindo alteração do endereço de email para receber a fatura. O empregado da empresa valida a identidade com certos dados pessoais e confere o identificador de chamada, que indica corretamente o número fiscal e o endereço postal do cliente, depois altera conforme a solicitação. Apenas no mês seguinte, a partir da reclamação do verdadeiro cliente, que a empresa altera o email novamente.
A fatura encaminhada pode fornecer informações privadas como o hábito, os contatos da pessoa e pode levar à perseguição do cliente e risco à integridade física. Por isso, deve ser documentado internamente, notificado a autoridade e os titulares.
Nesse caso, seria recomendável modificar a forma de autenticação para verificar com acurácia quem está solicitando informações e serviços, a exemplo de multi-fator.
Os exemplos de situações trazidos pelo EPDB revelam ser muito importante conhecer os aspectos técnicos da empresa para melhorar e implementar as medidas para evitar a ocorrência de incidente e, caso ocorra, a empresa tenha condições de continuar as atividades de negócio sem comprometer a integridade, disponibilidade e confidencialidade dos dados pessoais.
Como também, para a organização conseguir avaliar a extensão do dano que um incidente pode causar, as categorias de dados e os titulares afetados, é imprescindível conhecer todas as informações pessoais coletadas e ter uma boa gestão dessas informações.
Portanto, revela-se altamente recomendável ter um programa de proteção de dados e de segurança da informação bem estruturados dentro da empresa.
