Security Awareness baseado em risco: por que o mesmo treinamento não prepara toda a empresa

Aplicar o mesmo treinamento de segurança para todos os colaboradores parece uma escolha eficiente.

Uma única apresentação pode ser distribuída para toda a empresa. Os temas são padronizados. A participação é registrada. Os resultados ficam disponíveis para auditorias, relatórios e exigências de conformidade.

Essa base comum é importante. Todas as pessoas precisam conhecer princípios essenciais de proteção de dados, autenticação, uso seguro de dispositivos, engenharia social, phishing, reporte de atividades suspeitas e utilização responsável das ferramentas corporativas.

O problema começa quando o programa termina nessa camada.

Um executivo, um analista financeiro, um profissional de suporte, um desenvolvedor e uma pessoa do Recursos Humanos não possuem os mesmos acessos, não tomam as mesmas decisões e não enfrentam as mesmas tentativas de manipulação.

Eles podem trabalhar na mesma empresa, mas ocupam posições diferentes dentro da superfície de ataque.

Por isso, um programa de Security Awareness realmente conectado ao risco não deve abandonar os conteúdos gerais. Deve complementá-los com trilhas, simulações e comportamentos relacionados às situações que cada público pode encontrar em sua própria rotina.

O objetivo não é transformar cada colaborador em especialista em cibersegurança.

É preparar cada pessoa para reconhecer e interromper os riscos associados às decisões que ela realmente precisa tomar.

Uma base comum continua sendo necessária

Security Awareness não deve ser confundido com uma coleção de treinamentos isolados para diferentes departamentos.

Existem conhecimentos e comportamentos que precisam ser compartilhados por toda a organização.

Todos os colaboradores devem saber proteger suas contas, identificar sinais de engenharia social, utilizar os canais autorizados, lidar adequadamente com informações sensíveis e reportar situações suspeitas.

Também precisam entender que ataques nem sempre chegam como ameaças evidentes.

Uma tentativa pode aparecer como um pedido de ajuda, uma atualização de sistema, um documento compartilhado, uma solicitação urgente, uma mensagem enviada por alguém conhecido ou uma notificação de autenticação aparentemente legítima.

Essa base organizacional cria uma linguagem comum.

Ela ajuda as pessoas a reconhecer que segurança não é responsabilidade exclusiva da área técnica e estabelece comportamentos essenciais, como pausar, verificar, confirmar, reportar e escalar.

Mas uma base comum não é suficiente para preparar todos os públicos com a mesma profundidade.

Algumas funções lidam com decisões, acessos e informações que exigem orientações adicionais.

É nesse ponto que entram as trilhas específicas baseadas em risco.

O risco muda conforme acesso, decisão e processo

A segmentação de um programa de awareness não deveria seguir apenas o organograma.

Nem todas as pessoas de uma mesma área possuem a mesma exposição. Da mesma forma, profissionais de departamentos diferentes podem compartilhar riscos semelhantes.

O critério mais útil é observar três dimensões:

• O que a pessoa pode acessar.

• O que ela pode decidir.

• Quais processos ela pode executar ou alterar.

Uma pessoa com acesso administrativo pode ampliar o impacto de uma credencial comprometida.

Um profissional do financeiro pode aprovar um pagamento.

O help desk pode redefinir um fator de autenticação.

O RH pode alterar informações cadastrais ou participar do desligamento de um colaborador.

Um executivo pode autorizar uma exceção que outras pessoas não teriam poder para conceder.

Cada uma dessas possibilidades cria uma forma diferente de exposição.

O programa precisa, então, identificar como esses públicos podem ser manipulados, quais seriam as consequências de uma decisão incorreta e quais comportamentos ajudariam a reduzir o risco.

Liderança executiva: autoridade também é uma superfície de ataque

Executivos e membros da liderança concentram autoridade, informações estratégicas e poder de aprovação.

Isso os transforma em alvos valiosos não apenas pelo que conseguem acessar, mas pelo que conseguem fazer outras pessoas executarem em seu nome.

Um atacante pode simular uma solicitação urgente atribuída à presidência. Pode falsificar uma voz, criar uma reunião virtual, utilizar informações públicas ou explorar um momento de viagem para pressionar por uma exceção.

A abordagem pode envolver:

• Aprovação de pagamento fora do fluxo.

• Compartilhamento de documento estratégico.

• Criação emergencial de acesso.

• Alteração de prioridade.

• Uso de canal pessoal.

• Solicitação para ignorar temporariamente um controle.

O conteúdo destinado à liderança precisa ser objetivo e conectado a decisões empresariais.

Não faz sentido oferecer apenas uma versão resumida do treinamento aplicado aos demais colaboradores.

Esse público precisa saber confirmar solicitações sensíveis por canais independentes, evitar que sua autoridade seja utilizada para contornar processos e compreender seu papel durante um incidente.

Também precisa entender que controles de segurança não devem ser tratados como obstáculos que podem ser removidos sempre que a operação estiver sob pressão.

Quando a liderança normaliza exceções, o restante da empresa aprende que determinados procedimentos podem ser negociados.

Financeiro e compras: o ataque pode imitar uma relação legítima

Áreas financeiras e de compras lidam diariamente com fornecedores, notas fiscais, dados bancários, contratos, aprovações e pagamentos.

É justamente essa rotina que pode ser explorada.

Uma fraude pode começar com uma mensagem aparentemente enviada por um parceiro conhecido. O atacante utiliza o nome correto, conhece o contexto comercial e informa que os dados bancários foram alterados.

Em outros casos, a solicitação parece partir de um executivo e apresenta urgência suficiente para tentar interromper o fluxo normal de aprovação.

Os riscos mais comuns incluem:

• Alteração fraudulenta de dados bancários.

• Faturas adulteradas.

• Falsos fornecedores.

• Conta legítima de parceiro comprometida.

• Pressão para pagamento fora do processo.

• Documentos e links maliciosos enviados durante negociações.

O treinamento desse público deve ensinar procedimentos concretos.

Alterações sensíveis precisam ser confirmadas por contato previamente cadastrado. A validação não deve utilizar o telefone ou o e-mail apresentado na própria mensagem suspeita.

Exceções precisam de justificativa e aprovação. A confirmação deve ser registrada. Solicitações fora do padrão devem ser interrompidas e reportadas.

Uma boa simulação para esse público não mede apenas se alguém clicou em um link.

Ela verifica se o processo de pagamento resistiu à tentativa de manipulação.

Help desk: ajudar rápido não pode significar validar mal

O suporte técnico existe para resolver problemas com rapidez.

Recuperar acessos, redefinir senhas, trocar dispositivos, remover bloqueios e ajustar fatores de autenticação fazem parte de sua rotina.

Esses processos, no entanto, podem se transformar em caminhos de ataque.

Um criminoso pode ligar se passando por um colaborador. Pode alegar perda do celular, troca de aparelho ou viagem inesperada. Pode mencionar nomes, cargos e informações obtidas em vazamentos ou redes sociais.

Também pode utilizar autoridade aparente, dizendo representar uma liderança ou uma área crítica que precisa de acesso imediato.

O risco não está apenas na capacidade do atacante de convencer uma pessoa.

Está em processos de recuperação que foram desenhados para serem rápidos, mas não necessariamente resistentes à manipulação.

O awareness para help desk precisa reproduzir situações reais de atendimento.

Esse público deve saber:

• Quais informações realmente comprovam identidade.

• Quais dados não podem ser aceitos como prova suficiente.

• Quando uma solicitação precisa de validação adicional.

• Quais contas exigem cuidados especiais.

• Como interromper uma abordagem suspeita.

• Quando escalar a situação para a segurança.

• Como preservar os detalhes da tentativa.

Reconhecer um e-mail de phishing não prepara necessariamente alguém para resistir a uma ligação convincente.

O treinamento precisa refletir o canal e a pressão presentes no trabalho real.

Tecnologia e desenvolvimento: acesso técnico exige preparação específica

Profissionais de tecnologia, desenvolvimento e administração de sistemas lidam com códigos, ambientes, dependências, integrações, credenciais e acessos privilegiados.

Por isso, não deveriam receber apenas conteúdos genéricos sobre senhas ou phishing.

Os riscos associados a essas funções incluem:

• Segredos inseridos em código.

• Chaves de API expostas.

• Credenciais armazenadas inadequadamente.

• Dependências comprometidas.

• Uso de contas privilegiadas para tarefas cotidianas.

• Alterações sem revisão.

• Confusão entre ambientes de teste e produção.

• Compartilhamento de código em ferramentas públicas de IA.

O comportamento esperado também é diferente.

Essas pessoas precisam saber utilizar mecanismos aprovados para gestão de segredos, separar contas administrativas, validar dependências, revisar alterações e acionar segurança nos pontos previstos pelo processo.

Também precisam entender que o uso de ferramentas de IA pode criar novas formas de exposição.

Inserir código, arquivos de configuração, informações de clientes ou detalhes de infraestrutura em serviços não autorizados pode transferir dados sensíveis para fora do controle da empresa.

Nesse público, a aprendizagem deve ser mais prática e próxima das tarefas executadas.

Um quiz genérico dificilmente substitui exercícios de revisão de código, gestão de credenciais, configuração segura e resposta a exposições.

Recursos Humanos: dados pessoais e identidade em movimento

O RH acompanha diferentes momentos da relação entre a pessoa e a organização.

Admissão, benefícios, alterações cadastrais, folha, afastamentos e desligamentos envolvem informações pessoais e mudanças de acesso.

Isso cria oportunidades para fraude e engenharia social.

Uma solicitação pode tentar alterar dados bancários de um colaborador. Um portal falso pode imitar o sistema de benefícios. Um currículo pode conter anexo malicioso. Uma mensagem pode pedir documentos pessoais por canal inadequado.

Há também riscos relacionados à integração entre RH, gestores e tecnologia.

Se uma admissão ou um desligamento não for comunicado corretamente, contas podem ser criadas com permissões inadequadas ou permanecer ativas depois que deixaram de ser necessárias.

O programa deve orientar esse público a:

• Validar alterações sensíveis.

• Utilizar apenas plataformas autorizadas.

• Tratar anexos e links externos com cautela.

• Evitar compartilhamento excessivo de informações.

• Reconhecer pedidos fora do padrão.

• Integrar segurança aos processos de entrada e saída.

• Reportar rapidamente tentativas de falsificação.

O objetivo não é apenas proteger documentos.

É proteger a relação entre identidade, dados e acesso durante todo o ciclo do colaborador.

Como definir comportamentos esperados

Um programa de awareness perde força quando termina em recomendações vagas, como “tenha cuidado” ou “preste atenção”.

Essas orientações são difíceis de aplicar e quase impossíveis de medir.

O conteúdo precisa indicar comportamentos observáveis.

Diante de uma alteração bancária, confirmar por canal independente.

Diante de um reset de MFA, aplicar o procedimento completo de validação.

Diante de uma solicitação urgente, não ignorar o fluxo de aprovação.

Diante de uma exposição de segredo, revogar a credencial e reportar imediatamente.

Diante de um contato suspeito, interromper, registrar e escalar.

Quanto mais claro for o comportamento esperado, maior será a capacidade de transformar awareness em ação.

Também será mais fácil avaliar se o programa está funcionando.

Conteúdos gerais e trilhas específicas precisam coexistir

Segmentar não significa criar um curso completamente diferente para cada cargo.

Uma estrutura viável pode combinar diferentes camadas.

Campanhas gerais estabelecem a base comum.

Módulos específicos aprofundam riscos de determinados públicos.

Simulações direcionadas reproduzem situações reais.

Reforços imediatos são aplicados depois de testes, incidentes ou comportamentos observados.

Exercícios interfuncionais avaliam processos que dependem de várias áreas.

Um exemplo é a tentativa de alteração de dados bancários de fornecedor. O cenário pode envolver compras, financeiro, gestor do contrato e o próprio parceiro.

Outro exemplo é o desligamento de um colaborador, que depende da coordenação entre RH, liderança, tecnologia e segurança.

Essas situações mostram que o risco raramente cabe em um único departamento.

Por isso, o programa precisa trabalhar tanto a responsabilidade individual quanto a capacidade coletiva de interromper uma ameaça.

Participação não é sinônimo de efetividade

Taxas de conclusão são importantes.

Elas demonstram que o conteúdo foi disponibilizado e que as pessoas participaram.

Mas não mostram, sozinhas, se o risco foi reduzido.

Um programa orientado a resultados deve combinar diferentes tipos de indicador:

• Participação.

• Conhecimento.

• Comportamento.

• Qualidade da resposta.

• Evolução ao longo do tempo.

Em uma simulação de phishing, por exemplo, não basta acompanhar quantas pessoas clicaram.

É necessário observar quantas reportaram, quanto tempo levou até o primeiro alerta e se as informações enviadas permitiram que a equipe de segurança agisse.

No financeiro, pode ser medido o cumprimento dos procedimentos de validação.

No help desk, a aderência aos processos de recuperação de contas.

No desenvolvimento, a recorrência de segredos encontrados em repositórios.

No RH, a qualidade dos fluxos de admissão, alteração cadastral e desligamento.

A escolha das métricas deve refletir o risco e o comportamento esperado de cada público.

O programa precisa evoluir com a empresa

Um programa baseado em risco não pode ser desenhado uma vez e repetido indefinidamente.

Novas tecnologias, fornecedores, processos, funções e formas de trabalho alteram a exposição da organização.

A adoção de ferramentas de IA é um exemplo claro.

Uma empresa pode começar com um conteúdo geral sobre uso responsável e, depois, identificar que desenvolvedores, jurídico, marketing ou atendimento precisam de orientações específicas.

Incidentes e simulações também devem alimentar o programa.

Se um Phishing Test revela dificuldade de reporte, o conteúdo seguinte precisa reforçar esse comportamento.

Se uma tentativa real explora o help desk, os procedimentos de validação devem ser revisados e novamente testados.

Se uma área apresenta reincidência, é preciso entender se o problema está no conhecimento, no processo, na ferramenta ou na pressão operacional.

Awareness não é uma campanha isolada.

É um ciclo de observação, aprendizagem, adaptação e validação.

O treinamento precisa parecer relevante para quem o recebe

O mesmo treinamento para toda a empresa pode criar uma base comum.

Mas não consegue preparar, com a mesma profundidade, pessoas que enfrentam riscos diferentes.

Um programa mais maduro considera acessos, decisões, processos e consequências.

Ele ensina o que cada público precisa reconhecer, mas principalmente o que precisa fazer diante de uma situação de risco.

A liderança aprende a não utilizar autoridade para contornar controles.

O financeiro aprende a validar alterações por canais seguros.

O help desk aprende a proteger os processos de recuperação.

A tecnologia aprende a reduzir exposições criadas durante o desenvolvimento e a administração de sistemas.

O RH aprende a proteger dados e identidades em momentos críticos.

O objetivo não é oferecer mais conteúdo.

É oferecer conteúdo mais relevante.

A Setrix apoia empresas na criação de programas de Security Awareness conectados ao perfil de risco de cada organização, combinando campanhas gerais, trilhas específicas, Phishing Tests, simulações de engenharia social e indicadores de comportamento.

Transforme conteúdos genéricos em aprendizado conectado às decisões reais de cada público. Desenvolva com a Setrix um programa de Security Awareness orientado a riscos, comportamentos e resultados.

Fontes

NIST — SP 800-50 Rev. 1: Building a Cybersecurity and Privacy Learning Programhttps://csrc.nist.gov/pubs/sp/800/50/r1/final

ENISA — NIS2 Technical Implementation Guidancehttps://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance

Verizon — 2026 Data Breach Investigations Reporthttps://www.verizon.com/business/resources/reports/dbir/

NIST — NIST Phish Scale User Guide — Technical Note 2276https://csrc.nist.gov/pubs/tn/2276/final

National Cyber Security Centre — Cyber Security Toolkit for Boardshttps://www.ncsc.gov.uk/cyber-governance-for-boards/toolkit

FBI — Business Email Compromisehttps://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise

FBI — Spoofing and Phishinghttps://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/spoofing-and-phishing

CISA — Scattered Spider Cybersecurity Advisory — AA23-320Ahttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a

CISA — Avoiding Social Engineering and Phishing Attackshttps://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks

OWASP — Secrets Management Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

OWASP — Secure Code Review Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html