O treinamento de conscientização em segurança no desenvolvimento de software não é um capítulo separado na lei, mas decorre do dever de diligência: a obrigação de adotar medidas técnicas e organizacionais apropriadas contra riscos para sistemas de redes e informação. A conscientização dos colaboradores é uma das medidas que se enquadram nesta obrigação, porque uma grande parte dos incidentes começa com um erro humano: um e-mail de phishing que é aberto, uma senha que é compartilhada, um acesso mal configurado que ninguém percebe.
Além disso, a diretiva estabelece uma segunda obrigação separada que não diz respeito aos colaboradores, mas ao próprio administrador: ele próprio também deve receber treinamento e deve supervisionar a implementação da segurança cibernética dentro da organização. Esta é uma obrigação diferente da obrigação de treinamento do pessoal, com um objetivo diferente e um proprietário diferente. Para uma empresa de software que está sujeita ao dever de diligência, ou que enfrenta requisitos de NIS2 por meio de um cliente, a distinção entre estas duas camadas é exatamente onde surge muita confusão.
O que o dever de diligência exige da organização
O dever de diligência não descreve um programa de treinamento fixo com um número mínimo de horas ou um fornecedor obrigatório. O que a diretiva exige é que uma organização demonstre atenção adequada à conscientização em segurança como parte de sua gestão de riscos. Na prática, isso significa: os colaboradores que trabalham com código, dados de clientes ou ambientes de produção devem saber o que é engenharia social, como reconhecer uma solicitação suspeita e o que fazer se tiverem dúvidas.
Numa empresa de software, a ênfase costuma recair em alguns riscos específicos que não são relevantes para todas as pequenas e médias empresas: acesso ao código-fonte, segredos em arquivos de configuração, e a tentação de proteger ambientes de teste de forma menos rigorosa do que a produção. Um programa de conscientização que apenas alerta contra e-mails de phishing, mas não fala sobre compartilhamento de uma chave de API numa mensagem de chat, está ignorando exatamente o risco que mais frequentemente falha na linha de desenvolvimento. Quem quiser documentar isso sistematicamente, encontra em a visão geral de tópicos por setor como outras medidas do dever de diligência se conectam a isso, como controle de acesso e registro de incidentes.
A obrigação separada do administrador
Além da obrigação de treinamento para o pessoal, a diretiva impõe uma responsabilidade própria ao administrador: ele deve ter conhecimento suficiente para avaliar as medidas adotadas e deve ser capaz de avaliar os riscos associados à organização. Esta não é uma complementação ao treinamento do pessoal, mas uma obrigação independente, dirigida àquele que é o responsável final.
Esta distinção é relevante porque é frequentemente ignorada: uma empresa organiza um e-learning para todos os colaboradores e pensa que com isso também cumpriu a obrigação do administrador. Ou o diretor de uma empresa de software assume que sua própria experiência técnica é suficiente, sem que nada tenha sido documentado. Ambas as situações revelam uma lacuna entre o que realmente acontece e o que está organizado de forma demonstrável. Para a implementação exata desta obrigação e para o que foi estabelecido especificamente em cada país na transposição nacional, o texto oficial da diretiva é o ponto de partida apropriado; mantemos um registro na nossa base de conhecimento sobre quais publicações vimos e quando.
O que isso significa na prática para uma empresa de software
Uma empresa de software que está sujeita à obrigação de diligência ou que recebe um questionário de segurança de um cliente que está sujeito, normalmente enfrenta dois tipos de perguntas simultaneamente: se existe um programa de sensibilização para colaboradores e se a direção seguiu ou organizou atividades de formação. Quem consegue demonstrar apenas o primeiro aspecto deixa uma obrigação sem resposta no papel, obrigação essa que o questionário realmente solicita.
Para determinar se, e em que função, isto é relevante para sua organização, ajuda primeiro mapear o setor, o tamanho e a posição na cadeia de fornecimento. É exatamente por onde verificação gratuita de NIS2 começa: em algumas perguntas fica claro se uma organização está sujeita por si própria, é afetada apenas através de um cliente, ou nenhum dos dois.
Documentar: comprovação e responsável
Uma obrigação de formação que existe apenas em teoria não é demonstrável numa inspeção ou questionário. O que funciona é documentar, por cada obrigação, um estado, uma comprovação e um responsável: quando qual grupo de colaboradores recebeu qual formação, e houve um momento distinto em que o administrador foi informado sobre as medidas tomadas e os riscos da organização. Ambos devem estar num dossier, não em dois e-mails separados.
Dúvidas frequentes sobre o que exatamente cai sob a obrigação de formação, e como se relaciona com outras medidas da obrigação de diligência, estão detalhadas na perguntas frequentes. Aí também lê como secria.eu mantém as fontes e quando uma página foi verificada pela última vez, encontrável através de a explicação sobre como a informação é construída.
Quer saber primeiro se este tópico é relevante para sua organização, ou apenas chega até si através de um cliente? Faça a verificação NIS2 gratuita ou navegue pelos tópicos; ambos podem ser consultados sem conta e dão um próximo passo concreto imediatamente.