O anexo em que ninguém parou para pensar
O documento que saiu foi anexado por alguém que estava a fazer bem o seu trabalho. Uma associada da área fiscal encontra um erro de permissões na declaração de um cliente, abre um ticket junto da equipa interna de TI e anexa o ficheiro para que o analista possa reproduzir a falha. O ticket é fechado nessa tarde. Do anexo ninguém volta a falar.
A Ernst & Young revelou que um terceiro não autorizado acedeu a uma plataforma externa de gestão de serviços de TI usada pelas suas equipas internas de TI para apoiar a prática fiscal. Nas palavras da própria EY, os tickets de suporte submetidos através da plataforma "podem incluir documentos com informação fiscal de clientes". Os tipos de dados comunicados incluem dados pessoais e financeiros contidos em declarações fiscais ou usados para as preparar.
A EY afirma que o intruso esteve na plataforma entre 28 de março de 2026 e 12 de abril de 2026 e transferiu documentos relativos a um conjunto de clientes da EY. A firma declara também não ter conhecimento de qualquer utilização indevida nem de exposição adicional da informação pessoal envolvida. Ambas as declarações constam do processo. Apenas a segunda tranquiliza.
Duas semanas lá dentro, onze dias até notar, três meses até avisar
Aqui as datas pesam mais do que a técnica. O acesso decorreu de 28 de março de 2026 a 12 de abril de 2026. A EY identificou atividade anómala a 23 de abril de 2026. As cartas de notificação aos clientes afetados têm data de 13 de julho de 2026 e a 15 de julho de 2026 foi feita uma comunicação ao Procurador-Geral da Califórnia. Quatro estados foram notificados.
O que a EY não publicou pesa tanto quanto isso. O fornecedor por trás da plataforma não foi nomeado. O vetor de acesso inicial não foi divulgado. Não foi dado um número de vítimas e continua por esclarecer quantos clientes foram afetados. Nenhum grupo de ransomware reivindicou o ataque, o que elimina a fonte pública habitual para um inventário dos ficheiros levados.
Para um cliente da firma, é precisamente essa combinação que custa. Sabe que os seus documentos podem ter sido movidos. Não sabe quais, não conhece a via de entrada e não pode verificar nada de forma independente porque os registos nunca estiveram na sua posse. Tudo o que pode dizer a uma autoridade é uma citação alheia.
O suporte é um armazém de dados que ninguém mapeou
O sistema que expôs dados não era a plataforma fiscal. Era a fila de tickets. Essa distinção é a lição inteira e aplica-se a firmas muito mais pequenas do que a EY.
As equipas anexam documentos de clientes aos tickets de suporte por rotina, porque anexar o ficheiro é o caminho mais rápido para a falha ficar resolvida. Em poucos anos, o suporte acumula em silêncio uma cópia sombra, não classificada, alojada no fornecedor e conservada por tempo indeterminado, do material mais sensível que a firma detém. Ninguém a desenhou. É um subproduto da disponibilidade de todos.
Além disso, é quase sempre invisível no papel. A plataforma ITSM raramente surge num mapa de dados, raramente consta do registo de atividades de tratamento e raramente desencadeia uma avaliação de impacto, porque ninguém classifica o suporte de TI como um sítio onde vivem dados de clientes. A plataforma fiscal recebe a revisão de cifra, a recertificação de acessos e uma política de conservação. A fila que guarda cópias dos mesmos documentos recebe uma renovação de licença.
O seu prazo de 72 horas começa quando o subcontratante decidir
O atraso de notificação de um subcontratante é subtraído diretamente da sua própria janela de conformidade. Nos termos do RGPD, o dever de notificação em 72 horas corre a partir do momento em que o responsável pelo tratamento toma conhecimento da violação. Se quem detém os seus dados demora quase três meses a chegar até si, o seu prazo começa quase três meses depois de o atacante ter terminado.
Aplique isso a estas datas. Deteção a 23 de abril de 2026, cartas aos clientes de 13 de julho de 2026. Uma firma que receba essa carta abre em meados de julho a sua conversa com a CNPD sobre transferências ocorridas em finais de março, sem telemetria própria, sem fornecedor identificado e sem um âmbito de exposição para descrever.
As autoridades não são indiferentes a quem causou o atraso, e um responsável que agiu com prontidão face à informação disponível está numa posição defensável. Ainda assim, a experiência prática continua má: está a explicar um vazio que não criou, com factos que não pode verificar, perante uma autoridade que perguntará com razão porque é que o seu contrato permitia esse atraso.
Três alterações que compensam antes do próximo ciclo de auditoria
Comece por descobrir o que a sua fila de tickets contém de facto. Exporte um ano de anexos por tipo de ficheiro e faça amostragem. A maioria das firmas que faz este exercício encontra ficheiros de salários, documentos de identificação, contratos assinados e papéis de trabalho fiscais dentro de tickets fechados, resolvidos e esquecidos há anos.
Depois defina a conservação. Os anexos de tickets resolvidos devem caducar segundo um calendário definido e ser eliminados automaticamente, e o valor por omissão deve medir-se em semanas. Quando reproduzir uma falha exige mesmo dados de clientes, o fluxo deve encaminhar as equipas para uma localização controlada em vez do corpo do ticket, e a plataforma deve conseguir demonstrar essa diferença.
Por fim, leia o contrato do fornecedor especificamente contra este cenário. Confirme que o âmbito dos dados protegidos abrange corpos de tickets e anexos e não apenas os registos centrais do fornecedor. Confirme que a obrigação de notificação está expressa em horas a contar do conhecimento do fornecedor. Confirme que tem direito ao detalhe forense, incluindo o vetor de acesso, de que vai precisar perante a sua própria autoridade.
Leia a seguir: 570 correções do Windows num dia, duas já exploradas | Troque todos os segredos que o Grok Build alguma vez viu
