Quando numa organização acontece alguma coisa, a história circula à mesma, é um facto. Alguém conta por chat o pouco que sabe, outra pessoa acrescenta o que imagina, e ao fim de poucos dias a história que circula já não se parece com a que aconteceu. Entretanto, a versão que explica passo a passo como funcionou o engano não aparece em lado nenhum. E é a única que serviria para que não voltasse a acontecer. Porque é que fica guardada? Porque contá-la por inteiro parece obrigar-nos a dizer quem foi, e é aí que o relato trava. É uma pena, porque esse incidente interno é o material de consciencialização mais forte que uma organização tem, e já está pago.
Porque é que o incidente interno ensina mais do que o exemplo de manual?
Porque um exemplo de manual descreve um engano que funcionou noutro sítio, e o incidente interno descreve um que funcionou aqui. Para quem ouve são duas coisas muito diferentes. Com o exemplo de fora temos de pôr o resto por nossa conta, porque é preciso imaginar como seria esse email no nosso posto, com os nossos sistemas e com as pessoas que nos escrevem todos os dias. Quando o relato vem de dentro não é preciso imaginar nada, porque aparecem os nomes das ferramentas que usamos, o tipo de pedido que circula por aqui e o momento em que um pedido assim não dá nas vistas.
E há mais uma coisa que nenhum conteúdo comprado consegue dar. O incidente interno demonstra que aqui acontece. Enquanto o risco se explica com casos alheios, as pessoas tendemos a ouvi-lo como se ouve uma notícia, com interesse e com a sensação de que é com os outros. Um caso interno encurta essa distância melhor do que qualquer estatística.
Dito isto, é essa mesma força que o torna delicado. O relato que mais ensina é também o que mais facilmente deixa uma pessoa exposta, por isso antes de o contar há que decidir como se conta.
O que há que retirar do relato antes de o contar
O nome é a primeira coisa que sai e é a parte fácil. O difícil vem depois, porque num relato detalhado há bastantes dados que reconstroem a pessoa sem a nomear: a área quando é pequena, o dia e a hora, o cliente que aparecia no email, o valor, a versão do sistema que só uma equipa usa. Com esses dados cruzados, quem trabalha com essa pessoa sabe de quem estamos a falar.
Aqui entra em jogo um critério simples, e é contar o mecanismo completo e o contexto mínimo. Do mecanismo não retiramos nada, já que é aí que está tudo o que se aprende. E quanto é o contexto mínimo? O que faça falta para entender o engano, e nem um dado a mais. Suponhamos que o rascunho está pronto e que quem o lê é a equipa da pessoa envolvida. Se a partir daí a conseguem apontar, ainda nos falta trabalho.
O que fica no relato descreve o ataque, e nada disso aponta para uma pessoa:
- O pedido e o canal por onde chegou. O que pedia a mensagem, com que urgência e por onde entrou, para reconhecermos a mesma tentativa da próxima vez.
- O sinal que estava à vista. O detalhe que não batia certo, contado sem ironia, porque se vê com facilidade assim que sabemos o final.
- Como foi detetado e o que o travou. O aviso, a chamada de verificação ou o controlo que disparou, que é a parte que mostra que o sistema fez o seu trabalho.
E fica mais uma coisa, que já não é sobre o texto. À pessoa envolvida avisamos antes, ainda que o relato saia sem nenhum dado seu. Saber por um comunicado interno que a própria história está a ser usada como material faz com que, da próxima vez, a história fique guardada.
Quando se conta?
O habitual é que esta decisão não esteja escrita em lado nenhum. O Cyber Security Breaches Survey 2025/2026 do Governo do Reino Unido mediu que 57% das médias empresas e 76% das grandes têm um plano formal de resposta a incidentes, pelo que uma em cada quatro organizações grandes não tem nenhum. E o inquérito conta como plano quem avisar, quem faz o quê e quando reportar para fora. Contar o incidente portas adentro, para que a organização aprenda alguma coisa, não entra nessa lista.
Não se conta enquanto se está a conter. Nessas horas o relato compete com o trabalho de o resolver, e ainda não sabemos bem o que aconteceu, pelo que o que sair vai ser a primeira versão, a que costuma ser corrigida ao fim de poucos dias. Também não se conta tão tarde que a organização o tenha dado por encerrado, porque um relato que chega quando o tema arrefeceu lê-se como um trâmite.
A janela que funciona melhor é quando o incidente está fechado e ainda nos lembramos de que aconteceu alguma coisa. Nesse momento há uma curiosidade que depois se apaga, e essa curiosidade é atenção que não tivemos de fabricar, a mesma que custa tanto conseguir no resto do ano. Deixá-la passar sai caro, porque a mesma história contada meses mais tarde precisa de um esforço enorme para que alguém a leia.
O relato tem uma segunda vida, isso sim. Quando entram pessoas novas, o incidente que para nós já é velho volta a ser informação útil. Para essas pessoas não é história velha, e explica melhor do que qualquer política porque é que aqui pedimos o que pedimos.
O tom decide se da próxima vez alguém avisa
Esta é a parte cara de fazer mal. Um relato que acaba em moral lê-se como um aviso, e percebemos depressa o que nos espera se um dia nos acontecer. O que se parte aí é o canal de reporte. A próxima pessoa a quem aconteça alguma coisa vai demorar mais umas horas a avisar, ou vai tentar resolver sozinha primeiro, e o tempo entre o erro e o aviso é o que decide o tamanho do incidente. Um programa pode perder numa só comunicação mal escrita boa parte da confiança que demorou anos a construir.
Há uma regra simples de aplicar quando a temos presente, e é que o sujeito das frases do relato é o engano e o sistema. O email pedia tal coisa, chegava de um endereço parecido com o do fornecedor e tornava-se credível porque aqui os pedidos desse tipo chegam assim. Tudo isso descreve o ataque com precisão e deixa a decisão de uma pessoa fora do relato. Também não é preciso acrescentar que a culpa não foi de ninguém, já que nomear a culpa instala-a.
E há uma parte do relato que pesa mais do que parece, que é o final. Se a história acaba em como foi detetado, com o nome do controlo ou do canal que a travou, fica-nos instalado o reflexo de avisar, e esse é exatamente o comportamento que procuramos para a próxima vez.
O que fazer quando o incidente não se pode contar
Às vezes não se pode e as razões são boas. Há um cliente envolvido, uma investigação aberta, uma obrigação de notificação com prazos próprios ou um contrato que define o que se pode dizer. Quando isso acontece, esperar que se possa costuma equivaler a nunca o contar. Perde-se então o ensinamento? Não todo, porque fica-nos a versão deslocada, que conta o mecanismo sem o caso.
Em vez de “aconteceu-nos isto”, a comunicação avisa que está a circular um pedido deste tipo, com estas características, e explica como o verificar antes de responder. Perde a prova de que aqui acontece, que era o mais valioso, e ganha algo que compensa bastante, porque pode publicar-se enquanto o mecanismo ainda está ativo.
A outra saída dura mais, porque em vez de comunicar transforma o mecanismo em algo que podemos voltar a usar.
De anedota solta a material que dura
Um relato contado uma vez chega até onde chegou nesse dia. Com o tempo há pessoas novas, pessoas que estavam de férias e pessoas que o leram por alto, por isso para que o incidente continue a ensinar há que tirá-lo do formato comunicado e passá-lo para o programa.
A forma mais direta é levar o mecanismo para uma simulação própria. Nas simulações de phishing da SMARTFENSE podem editar-se os conteúdos predefinidos ou criar-se novos de raiz, de maneira que o mesmo tipo de pedido, com o mesmo estilo de remetente e a mesma desculpa, volta a circular semanas depois sem ninguém exposto. Para quem realiza a ação de risco, um Momento Educativo explica nesse instante o que aconteceu e como reconhecer o engano da próxima vez, com uma pergunta de validação que confirma que o conteúdo foi lido.
Aqui há um limite que vale a pena respeitar, e é mais estrito do que o do comunicado. A simulação replica o mecanismo e o caso fica de fora. Se reproduzir o incidente com os seus detalhes reconhecíveis volta a expor a pessoa que o viveu, desta vez à frente de toda a organização e com o selo do programa por cima.
O resto dos usos é mais tranquilo e não nos pede nenhuma decisão difícil. O mecanismo entra no material de quem chega, volta uma vez por ano como lembrete e dá à política interna o exemplo que lhe faltava.
Que versão queremos que circule
Voltemos às versões do início. A história vai circular de qualquer maneira. A única coisa que a organização decide é qual delas tem os detalhes, explica o mecanismo e chega a toda a gente, e essa decisão toma-se nos dias a seguir ao incidente ou perde-se.
Em definitivo, a versão que serve tem uma forma bastante reconhecível. Conta com precisão como funcionou o engano, não permite apontar ninguém, acaba em como foi detetado e deixa-nos uma ideia clara do que fazer se amanhã nos chegar algo parecido.
Se na tua organização já aconteceu alguma coisa e ainda ninguém a contou, talvez este seja um bom momento para escrever essa versão. Porque o incidente já o pagámos, e o que falta decidir é se também nos ensina alguma coisa.
Deixe um comentário