Violações de dados pessoais: mantenha a decisão de notificação em andamento

Uma violação de dados pessoais cria duas tarefas paralelas: conter o incidente e decidir o que tem de ser comunicado. Nenhuma deve esperar que a outra termine. Os engenheiros podem ainda estar a reconstruir os registos de acesso quando o responsável pelo tratamento já dispõe de informação suficiente para avaliar a notificação.

O desafio prático é manter essa decisão em andamento sem apresentar pressupostos como factos. Um processo de resposta útil regista o momento de conhecimento, produz um conjunto mínimo e fiável de evidências, atribui a responsabilidade pela decisão e atualiza a avaliação à medida que as conclusões mudam. Na perspetiva de um CTO, o resultado essencial não é uma investigação forense concluída em 72 horas. É uma decisão atempada e defensável, sustentada em evidências técnicas, com responsáveis claros pelas questões que ficam em aberto.

Reconheça a violação antes de discutir a notificação

Uma violação de dados pessoais é mais ampla do que o roubo de dados. O artigo 4.º, ponto 12, do RGPD abrange uma violação da segurança que provoque, de modo acidental ou ilícito, a destruição, a perda, a alteração, a divulgação ou o acesso não autorizados a dados pessoais.

Há três dimensões relevantes:

Um mesmo evento pode envolver as três. Um ransomware pode interromper o acesso, corromper registos e expor informação. Repor uma cópia de segurança resolve apenas parte desse incidente.

Um e-mail enviado ao destinatário errado e um incidente de ransomware podem, por isso, exigir ambos uma avaliação documentada, ainda que as investigações sejam diferentes. Inversamente, um ataque falhado que não comprometeu dados pessoais não é automaticamente uma violação de dados pessoais. Pode, ainda assim, exigir investigação de segurança e notificação ao abrigo de outro regime.

Comece por estabelecer se foram afetados dados pessoais, e não se alguém se queixou ou se ocorreram danos financeiros. Nomes, identificadores de conta, registos de colaboradores, identificadores de dispositivos e combinações de informação aparentemente banal podem ser dados pessoais. Os registos pseudonimizados podem continuar a ser dados pessoais quando as pessoas continuam a ser identificáveis.

Nos incidentes de disponibilidade, analise as consequências em vez de usar uma duração fixa de indisponibilidade como atalho. Perder o acesso ao registo de uma marcação durante um tratamento urgente é diferente de interromper brevemente o acesso a uma lista arquivada de subscritores de uma newsletter.

Estabeleça o momento de conhecimento e designe o responsável pela decisão

Nos termos do artigo 33.º do RGPD, o responsável pelo tratamento tem de notificar a autoridade de controlo competente sem demora injustificada e, sempre que possível, até 72 horas após ter tido conhecimento de uma violação de dados pessoais, a menos que a violação não seja suscetível de resultar num risco para os direitos e liberdades das pessoas.

O prazo não começa automaticamente quando o ataque subjacente se iniciou. Do mesmo modo, não espera por um relatório forense final nem pela aprovação da administração. Nas orientações das autoridades de controlo, o conhecimento entende-se como um grau razoável de certeza de que ocorreu um incidente de segurança que comprometeu dados pessoais. Uma investigação inicial pode estabelecer essa certeza; não se deve tornar num mecanismo para adiar responsabilidades.

Mantenha separadas três marcas temporais:

• Ocorrência: quando o incidente aconteceu, se for conhecido.
• Deteção: quando alguém observou ou comunicou pela primeira vez um possível incidente.
• Conhecimento: quando a organização teve certeza suficiente de que dados pessoais foram comprometidos.

Registe as evidências que sustentam o momento de conhecimento. Se uma marca temporal for contestada, mantenha as interpretações concorrentes e a respetiva fundamentação, em vez de substituir discretamente o registo anterior. Os atrasos no escalamento interno devem ser visíveis e não servir para presumir que o conhecimento só começou quando a área de privacidade ou a administração receberam a comunicação.

Setenta e duas horas significam horas decorridas, incluindo fins de semana e feriados. São uma referência temporal máxima sempre que possível, não uma autorização para esperar se a notificação puder ser feita mais cedo.

Designe um coordenador do incidente para manter a cronologia e as questões pendentes. Os responsáveis técnicos apuram os factos; a especialização em privacidade avalia as consequências e os requisitos legais; um representante autorizado do responsável pelo tratamento é responsável pela decisão de notificação. Quando exista um EPD designado, envolva-o prontamente no seu papel independente de aconselhamento e controlo. Não torne o EPD responsável pela contenção nem presuma que ele substitui a responsabilidade do responsável pelo tratamento.

Designe substitutos. Um processo que depende da disponibilidade de um único administrador não é um processo funcional fora do horário de expediente.

Produza nas primeiras horas um conjunto de evidências pronto para decisão

A contenção e a preservação de evidências têm de avançar em conjunto. Desligar um endpoint comprometido pode ser adequado, mas apagá-lo antes de recolher as evidências relevantes pode destruir a base para avaliar o acesso e o âmbito. Inversamente, preservar todos os artefactos não é motivo para deixar por conter uma divulgação ativa.

O que se segue é uma sequência prática de resposta, não um calendário legal.

Estabilize o incidente

Revogue as sessões ou credenciais expostas, restrinja permissões inseguras, isole os componentes afetados quando adequado e interrompa transferências mal direcionadas em curso. Registe cada ação, a sua hora e o efeito esperado. Preserve os registos relevantes, instantâneos de configuração, cabeçalhos de mensagens e outro material volátil antes que os limites de conservação ou os trabalhos de recuperação os eliminem.

Restrinja o acesso às evidências do incidente. A própria investigação de uma violação pode criar coleções sensíveis: documentos de identificação, mensagens de colaboradores, dados de autenticação ou listas de clientes afetados. Utilize um local de evidências aprovado, em vez de reencaminhar registos em bruto através de um chat de incidente com muitos participantes.

Construa o pacote mínimo de factos

Dê aos revisores de privacidade um relato curto e estruturado que contenha:

• O que aconteceu e que observações o confirmam.
• Sistemas, serviços e prestadores responsáveis afetados.
• Categorias de dados pessoais e categorias de pessoas afetadas.
• Números aproximados de pessoas e registos, com o método de contagem.
• Período de exposição, destinatários conhecidos e possíveis vias de acesso.
• Proteções relevantes, incluindo a cifragem e o acesso às chaves.
• Consequências conhecidas ou plausíveis para as pessoas.
• Medidas já tomadas e questões ainda por resolver.

Separe os factos confirmados, as estimativas fundamentadas e as hipóteses. “Não surge nenhum evento de exportação no registo de auditoria disponível” é mais restrito do que “ninguém acedeu aos dados”. Indique as lacunas de cobertura e de conservação dos registos, para que os revisores compreendam o que as evidências não conseguem estabelecer.

Mantenha uma fila de questões

Atribua a cada questão por resolver um responsável e uma próxima data de revisão. Dê prioridade às questões capazes de alterar a decisão: se um objeto exposto continha dados pessoais, se um atacante acedeu a chaves de cifragem ou se registos indisponíveis afetaram serviços essenciais.

Outras questões, como a técnica exata de exploração inicial, podem ser muito importantes para a correção sem serem necessárias para a primeira notificação. Manter essas vertentes separadas impede que a curiosidade técnica atrase a ação jurídica.

Um inventário atualizado de sistemas e dados torna este trabalho mais rápido. A descoberta de dados para a privacidade fornece o contexto necessário para traduzir “serviço de armazenamento comprometido” em categorias de dados, finalidades de tratamento e populações afetadas identificáveis.

Avalie os danos para as pessoas, não apenas o impacto no negócio

A exceção do artigo 33.º é que o risco para os direitos e liberdades seja improvável. Não é uma regra segundo a qual só as violações de grande dimensão, os dados de categorias especiais ou os danos comprovados têm de ser notificados.

Avalie tanto a probabilidade como a gravidade das possíveis consequências. Uma divulgação pequena pode ser grave, enquanto um incidente maior pode contar com proteções eficazes que reduzem substancialmente o risco. Documente por que razão as circunstâncias sustentam a conclusão.

Considere estas dimensões em conjunto:

A cifragem exige análise técnica. Um disco cifrado em repouso não protege necessariamente informação acedida através de uma conta de aplicação comprometida. Determine a camada de cifragem, a separação das chaves, as permissões do atacante e se havia texto em claro utilizável. O mesmo raciocínio aplica-se às credenciais com hash: a sua proteção depende do método e das circunstâncias, não do rótulo “com hash”. Consulte cifragem e gestão de chaves.

A confirmação de eliminação por parte de um destinatário pode ser relevante, em especial numa divulgação acidental a um destinatário conhecido e cooperante. Não é uma prova universal de que o risco desapareceu. Considere se o conteúdo foi visualizado, copiado, reencaminhado ou se esteve acessível por outro canal.

Evite transformar uma pontuação numérica de risco numa conclusão jurídica automática. Uma matriz de pontuação pode tornar o raciocínio consistente, mas os revisores continuam a ter de explicar as consequências reais e as incertezas. A indisponibilidade do negócio, a perda de receitas e os danos reputacionais para a organização pertencem à gestão operacional do incidente; não substituem a avaliação dos efeitos sobre as pessoas.

Reavalie quando surgirem novos factos. A descoberta de anexos sensíveis ou de acesso do atacante às chaves pode alterar uma decisão inicialmente razoável de não notificar.

Tome duas decisões de comunicação separadas

A notificação à autoridade e a comunicação às pessoas afetadas têm limiares diferentes. Registe ambas as decisões explicitamente, incluindo quando nenhuma é exigida.

Notifique com o que se sabe

O artigo 33.º exige que a notificação descreva a natureza da violação, incluindo, se possível, as categorias e o número aproximado de titulares e de registos afetados. Deve também indicar o contacto do EPD ou outro ponto de contacto, descrever as consequências prováveis e descrever as medidas adotadas ou propostas, incluindo, se for caso disso, medidas para atenuar os seus efeitos.

Não espere por contagens exatas se dispuser de estimativas fiáveis e de ressalvas claras. O artigo 33.º, n.º 4, permite que a informação seja fornecida por fases quando não puder ser fornecida ao mesmo tempo, sem demora injustificada adicional. Guarde uma cópia da submissão, o comprovativo de receção, o número de referência e uma lista das atualizações prometidas.

Se a notificação ocorrer depois das 72 horas, indique os motivos do atraso. Ultrapassar o prazo não elimina a obrigação. Explique a cronologia real, em vez de apresentar uma afirmação genérica de que a investigação foi complexa.

Confirme cedo a autoridade competente e o canal de notificação, em particular no caso de tratamento transfronteiriço. Não presuma que a autoridade do local do servidor é o destinatário correto.

Comunique quando for provável um risco elevado

O artigo 34.º do RGPD exige uma comunicação em linguagem clara e simples às pessoas afetadas, sem demora injustificada, quando for provável um risco elevado. O seu conteúdo inclui a natureza da violação, os contactos, as consequências prováveis e as medidas relevantes.

Explique o que as pessoas podem fazer: por exemplo, alterar uma palavra-passe afetada, recusar instruções de pagamento suspeitas ou utilizar um canal de apoio verificado. Não dê a entender que os conselhos de precaução lhes transferem a responsabilidade.

O artigo 34.º inclui exceções para medidas eficazes que tornem os dados incompreensíveis para pessoas não autorizadas, para medidas subsequentes que assegurem que o risco elevado já não é suscetível de se concretizar e para o esforço desproporcionado. Esta última exige uma comunicação pública ou uma medida semelhante igualmente eficaz; não é uma autorização para ficar em silêncio. A autoridade pode exigir a comunicação ou avaliar se se aplica uma exceção.

Trate os incidentes de subcontratantes sem perder o controlo da avaliação

Um subcontratante tem de informar o responsável pelo tratamento sem demora injustificada após ter conhecimento de uma violação de dados pessoais. Não deve esperar pela sua própria conclusão de que a notificação à autoridade de controlo é necessária. A avaliação do responsável pelo tratamento não deve ser substituída pelo rótulo de “risco baixo” de um fornecedor.

Peça evidências relevantes para o seu tratamento: tenant ou conta afetados, categorias de dados, período de exposição, evidências de acesso, proteções, contenção e questões por resolver. Uma declaração de incidente para todo o fornecedor pode não estabelecer quais dos seus registos foram afetados.

O atraso do fornecedor não consome mecanicamente o prazo de 72 horas do responsável pelo tratamento antes de este ter conhecimento. Pode, no entanto, atrasar ações de proteção, obscurecer a cronologia e levantar questões sobre o cumprimento dos deveres do subcontratante. Registe quando o fornecedor detetou o incidente, quando teve conhecimento e quando o informou.

Como recomendação contratual prática, especifique contactos operacionais, um aviso inicial rápido, informação mínima, atualizações contínuas e assistência na investigação e nas comunicações. Estes acordos devem apoiar, e não substituir, os requisitos do artigo 28.º.

Quando a sua organização for simultaneamente subcontratante para clientes e responsável pelo tratamento de dados de colaboradores, tome decisões separadas em função de cada papel. Um incidente técnico comum pode exigir avisos aos clientes numa qualidade e uma avaliação para a autoridade de controlo noutra.

Mantenha um registo de decisões que sobreviva ao incidente

O artigo 33.º, n.º 5, exige a documentação das violações de dados pessoais, incluindo os factos, os respetivos efeitos e a medida de reparação adotada, de modo a permitir à autoridade de controlo verificar o cumprimento. Isto inclui as violações que não foram notificadas.

Um registo de incidente útil contém:

• Identificador do incidente, âmbito, coordenador e papel no tratamento.
• Marcas temporais de ocorrência, deteção, conhecimento e escalamento.
• Referências às evidências e os limites da telemetria disponível.
• Avaliação de risco, revisor, responsável pela decisão e horas das decisões.
• Conclusões separadas sobre a notificação à autoridade e a comunicação às pessoas.
• Comunicações submetidas, confirmações de receção e atualizações posteriores.
• Ações de contenção, recuperação e prevenção com responsáveis.
• Revisão de encerramento e motivos de qualquer incerteza remanescente.

Em caso de não notificação, escreva o raciocínio, e não apenas “abaixo do limiar”. Identifique os factos que sustentam a improbabilidade do risco e que evidências desencadeariam uma reavaliação.

Preserve as avaliações sucessivas. Uma conclusão inicial pode ter sido razoável face às evidências disponíveis, mesmo que conclusões posteriores a alterem. Sobrescrever a versão anterior oculta essa cronologia.

Defina deliberadamente os acessos e a conservação. O artigo 33.º não prevê um prazo de conservação universal para os registos de violações. Escolha um calendário justificado, tendo em conta a responsabilidade, as obrigações aplicáveis e a minimização dos dados. Sempre que possível, conserve referências às evidências em vez de duplicar conjuntos extensos de dados pessoais.

A notificação não confere imunidade ao escrutínio. As autoridades podem pedir esclarecimentos e examinar as medidas de segurança ou outras obrigações. Do mesmo modo, evite tratar a notificação como motivo para adiar a contenção enquanto aguarda instruções do regulador.

Exemplo prático: uma exportação de recrutamento exposta

Este exemplo é ilustrativo; os seus horários e números são pressupostos, não resultados reportados.

Suponha que uma organização descobre na sexta-feira às 16:00 que uma exportação de recrutamento pode estar acessível através de uma ligação pública de armazenamento. O ficheiro contém os nomes, contactos, notas de candidatura e alguns anexos de 240 candidatos. Às 16:20, um engenheiro confirma o acesso sem autenticação e verifica que o ficheiro contém dados pessoais. O coordenador regista as 16:20 como o momento de conhecimento fundamentado. A referência das 72 horas é segunda-feira às 16:20, embora a notificação deva continuar a ser feita sem demora injustificada.

Às 16:35, a equipa já removeu o acesso público e preservou o histórico de configuração e os registos de acesso disponíveis. Esses registos cobrem apenas parte do período de exposição. A equipa não pode concluir de forma responsável que ninguém acedeu ao ficheiro.

A primeira avaliação identifica possível phishing direcionado e a divulgação de intenções profissionais confidenciais. O conteúdo dos anexos continua incerto. Os revisores de privacidade e o responsável pela decisão concluem que o risco não é improvável, pelo que a notificação à autoridade de controlo é obrigatória. Avaliam separadamente se é provável um risco elevado; o número de candidatos, por si só, não responde a essa pergunta.

A notificação inicial descreve a exposição confirmada, o âmbito aproximado, a cobertura incompleta dos registos, as consequências conhecidas e a contenção. Indica que a revisão dos anexos está em curso e identifica a pessoa responsável por fornecer atualizações.

No sábado, a revisão conclui que um subconjunto dos anexos contém informação de saúde. A equipa revê a avaliação de risco elevado e determina que é necessária uma comunicação a esse grupo afetado. As mensagens descrevem a exposição relevante e precauções práticas sem revelar informação de outros candidatos.

O registo concluído preserva ambas as avaliações, as evidências de suporte, os comprovativos de submissão e as tarefas corretivas. O seguimento inclui controlos de aprovação de exportações, prevenção do acesso público, registo adequado e testes que confirmem que os ficheiros de recrutamento já não estão publicamente acessíveis.

A lição é operacional: o conteúdo incerto dos anexos não impediu uma notificação inicial, e as conclusões posteriores alteraram a decisão de comunicação às pessoas sem invalidar a avaliação anterior, baseada nas evidências disponíveis.

Acompanhe outros deveres de notificação na mesma cronologia

O mesmo incidente pode desencadear notificações ao abrigo do RGPD, de contratos, de regras setoriais e de cibersegurança. Utilize uma única cronologia factual, mas separe as avaliações de cada obrigação, os destinatários, os responsáveis e os prazos.

O artigo 23.º da NIS2 aborda os incidentes significativos das entidades abrangidas, envolvam ou não dados pessoais. A sua estrutura de notificação da UE inclui um alerta precoce em 24 horas, uma notificação do incidente em 72 horas e, em geral, um relatório final no prazo de um mês após a notificação. A NIS2 é aplicada através da legislação nacional: verifique a aplicabilidade, os procedimentos nacionais e as regras setoriais relevantes, em vez de presumir que todas as organizações têm estes deveres.

Para as entidades financeiras abrangidas, o DORA pode estabelecer requisitos setoriais. Não duplique notificações automaticamente nem trate uma única submissão como suficiente para todos os regimes.

Também pode ser exigido um aviso contratual aos clientes, mesmo quando a notificação à autoridade de controlo não é. Mantenha uma matriz de notificações que identifique, para cada obrigação aplicável, a fonte, o fator desencadeador, o destinatário, o responsável, a via de submissão e a evidência de conclusão.

Prepare as passagens de testemunho antes do próximo incidente

Um teste prático de preparação é um exercício numa sexta-feira à tarde com um cenário de e-mail mal direcionado, de prestador comprometido ou de ransomware. Peça aos participantes que produzam o primeiro pacote de factos e o registo de decisão reais, e não que se limitem a descrever a política.

Verifique se a equipa consegue:

• Contactar o coordenador, o consultor de privacidade, o responsável pela decisão e os substitutos.
• Identificar os dados e os prestadores relevantes a partir dos inventários existentes.
• Preservar os registos antes que a reposição ou os limites de conservação os eliminem.
• Aceder ao canal de notificação da autoridade correta.
• Redigir uma notificação faseada com os aspetos desconhecidos claramente assinalados.
• Comunicar de forma segura com os clientes e com as pessoas afetadas.
• Registar uma decisão de não notificação e agendar a reavaliação.

Quando uma resposta depender de encontrar uma pessoa desconhecida ou de recuperar credenciais inacessíveis, crie uma tarefa de preparação. As responsabilidades do CISO e do EPD devem ser suficientemente claras para que o apuramento técnico dos factos e o aconselhamento independente em matéria de privacidade possam avançar em conjunto.

A Secani pode apoiar o registo de conformidade passível de revisão em torno deste trabalho. Modele os sistemas e prestadores afetados como objetos-alvo, ligue as evidências aos requisitos e decisões relevantes e atribua responsáveis às tarefas de seguimento. Os seus fluxos de evidências ligadas e de revisão suportam ligações às fontes, comentários, aprovações e marcas temporais. Trate os resumos assistidos por IA como rascunhos que exigem revisão humana; mantenha a contenção e a investigação forense nos sistemas operacionais e ligue as suas evidências ao registo de decisões.

Questões que surgem durante a resposta

Podemos esperar por uma confirmação de eliminação antes de decidir?

Peça-a prontamente, mas continue a avaliação em paralelo. A sua relevância depende do destinatário, do conteúdo e de um possível acesso posterior. Um pedido sem resposta não é evidência de que a exposição terminou.

E se o portal de notificação estiver indisponível?

Registe as tentativas e procure a via de contacto alternativa publicada pela autoridade. Preserve a informação pronta para submissão e explique qualquer atraso daí resultante. Um problema técnico de submissão não deve interromper a avaliação nem a comunicação necessária às pessoas.

Quando pode o incidente ser encerrado?

A recuperação operacional e o encerramento no plano da privacidade são marcos distintos. Confirme que os avisos e atualizações exigidos estão concluídos, que as questões residuais têm um responsável e que as ações corretivas continuam a ser acompanhadas. Como próximo passo prático, teste um caso recente não notificado face à lista de verificação do registo: se outro revisor não conseguir reconstruir a decisão, melhore a passagem de testemunho antes do próximo incidente.