
A preparação para a NIS2 começa com uma decisão de aplicabilidade documentada. O setor, o serviço, a dimensão, o estabelecimento e as regras especiais de inclusão podem ser todos relevantes. O questionário de um cliente é um contexto útil, mas não determina o seu estatuto jurídico. Do mesmo modo, um certificado de segurança não demonstra que todas as entidades, serviços e obrigações de notificação relevantes foram tratados.
Para um CEO, estar preparado significa conseguir explicar o que a gestão aprovou, por que razão as medidas são adequadas, quem as vai implementar e como será avaliada a sua eficácia. Significa também garantir que a organização consegue notificar um incidente significativo quando a informação ainda está incompleta e as operações normais estão perturbadas.
A tarefa prática consiste em ligar o âmbito jurídico, os riscos dos serviços, as prioridades de execução e as evidências revistas. Essa ligação dá à gestão uma base para decidir sobre investimento, perturbação operacional, fornecedores e exposição ainda não resolvida.
A Diretiva NIS2 estabelece um nível mínimo comum de cibersegurança na UE para determinadas atividades. Os artigos 2.º e 3.º, em conjunto com os anexos, definem o seu âmbito de aplicação e a estrutura de classificação. A legislação nacional de transposição estabelece as obrigações e os procedimentos locais aplicáveis.
Avalie cada entidade jurídica relevante, em vez de tratar o nome do grupo como fronteira regulatória. As atividades de uma filial, as relações de propriedade e os locais de estabelecimento podem alterar a resposta. A gestão deve exigir uma conclusão registada, os factos que a sustentam e um responsável pelas questões em aberto.
O Anexo I inclui setores como a energia, os transportes, a saúde, a água, os serviços financeiros, as infraestruturas digitais, a gestão de serviços de TIC, a administração pública e o espaço. O Anexo II alarga a cobertura a áreas como os serviços postais, a gestão de resíduos, os produtos químicos, a alimentação, determinadas atividades de fabrico, os prestadores de serviços digitais e a investigação.
O título do setor é apenas o ponto de partida. Leia os tipos de entidade e as atividades descritos na entrada relevante. O fabrico não é uma categoria de inclusão universal, e vender software não transforma automaticamente uma empresa num prestador de serviços de computação em nuvem ou num prestador de serviços geridos.
Descreva o que a entidade efetivamente presta: o serviço, os seus destinatários, o modo como funciona e se administra sistemas de clientes. Os códigos de atividade económica e as descrições no sítio web podem apoiar essa análise, mas não a devem substituir.
Por exemplo, vender uma aplicação licenciada e operar os sistemas de informação de um cliente são atividades diferentes. Uma empresa descrita como consultora pode, ainda assim, prestar administração contínua que exige uma avaliação face às definições de serviços geridos. Resolva estas questões antes de desenhar a fronteira de conformidade.
O artigo 2.º recorre à definição de dimensão das empresas da UE. Como atalho de triagem inicial, o limiar geral de inclusão é de 50 ou mais trabalhadores, ou um volume de negócios e um balanço total ambos superiores a 10 milhões de euros. De forma geral, ultrapassar os limites das médias empresas implica pelo menos 250 trabalhadores, ou um volume de negócios superior a 50 milhões de euros juntamente com um balanço total superior a 43 milhões de euros.
Estes valores não substituem o cálculo completo. Os períodos contabilísticos relevantes, a metodologia de contagem de efetivos e as empresas parceiras ou associadas podem afetar o resultado. Uma filial localmente pequena pode ultrapassar um limiar quando se consideram as relações de propriedade adequadas.
Conserve o cálculo, os valores de base e o raciocínio sobre as relações de grupo. Evite registar apenas «média empresa» sem explicar como se chegou a essa conclusão. O volume de negócios, por si só, não é a alternativa financeira completa ao número de trabalhadores.
Quando a dimensão estiver próxima de um limiar ou a estrutura de propriedade for complexa, encomende uma avaliação jurídica específica. O custo de resolver essa incerteza deve ser tratado como parte da definição dos requisitos operacionais, e não adiado até que uma autoridade ou um cliente conteste a conclusão.
Algumas categorias de serviços podem ser abrangidas independentemente da dimensão. O artigo 2.º trata de determinadas atividades de comunicações, de confiança, de DNS e de domínios de topo, de certos organismos da administração pública e de entidades identificadas como críticas ao abrigo do quadro europeu pertinente. A identificação a nível nacional também pode incluir entidades no âmbito devido à sua importância para a sociedade ou às consequências de uma perturbação.
O artigo 3.º determina depois se uma entidade abrangida é essencial ou importante. As grandes entidades do Anexo I constituem uma categoria significativa de entidades essenciais, mas o artigo contém regras adicionais específicas de serviço e de designação. Uma empresa média do Anexo I não é automaticamente essencial; os anexos não são simplesmente duas listas de níveis de supervisão.
Ambas as classificações implicam os deveres essenciais de gestão dos riscos de cibersegurança e de notificação de incidentes significativos. O estatuto de entidade importante altera o modelo de supervisão; não elimina a necessidade de medidas eficazes.
A abrangência jurídica direta e os requisitos dos clientes devem ser registados separadamente. Um fornecedor mais pequeno pode estar fora do âmbito direto e, ainda assim, enfrentar deveres contratuais de segurança substanciais. Inversamente, um questionário de cliente que afirme «a NIS2 aplica-se» não é uma decisão de classificação vinculativa.
Um registo de âmbito defensável deve conter:
Os fatores que desencadeiam uma reavaliação devem incluir aquisições, novos serviços, alterações materiais de dimensão e evoluções legislativas. Uma decisão de exclusão pode ser sólida no momento em que é tomada e ficar desatualizada mais tarde.
A NIS2 é uma diretiva aplicada através do direito nacional. Os Estados-Membros tinham como prazo de transposição 17 de outubro de 2024, com medidas de execução destinadas a aplicar-se a partir de 18 de outubro de 2024. Essas datas não indicam a uma empresa concreta qual é o seu prazo nacional de registo atual nem o procedimento que deve utilizar.
Crie um registo de obrigações para cada entidade e país relevantes. Identifique a legislação aplicável, a autoridade, o processo de registo, o canal de notificação, as disposições setoriais e o responsável interno. Distinga um requisito legal de uma orientação da autoridade ou de uma recomendação interna de implementação.
O artigo 26.º liga, em geral, a jurisdição ao estabelecimento, mas certos serviços seguem regras diferentes. Os prestadores de comunicações eletrónicas públicas são regulados onde prestam os serviços em causa. Determinados prestadores digitais seguem uma abordagem de estabelecimento principal, incluindo serviços de computação em nuvem, centros de dados, redes de distribuição de conteúdos, serviços geridos, serviços de segurança geridos e certas plataformas em linha e atividades relacionadas com domínios.
Para essa avaliação do estabelecimento principal, analise onde são predominantemente tomadas, na União, as decisões relativas às medidas de gestão dos riscos de cibersegurança. Se esse local não puder ser determinado ou se essas decisões não forem tomadas na União, avalie onde são realizadas as operações de cibersegurança na União; se também isso não puder ser determinado, utilize o estabelecimento na União com o maior número de trabalhadores. A sede social de uma holding pode, por isso, ser insuficiente.
Certos prestadores que oferecem serviços na União sem estabelecimento na UE têm de designar um representante na UE. Uma sede no estrangeiro não constitui uma isenção automática, mas os clientes europeus também não colocam automaticamente no âmbito todas as empresas de fora da UE. O tipo de serviço e as restantes condições de aplicabilidade continuam a ser relevantes.
Registe os deveres de registo e de prestação de informações sobre a entidade separadamente do programa de segurança. Conserve os comprovativos de submissão, os contactos atualizados e a responsabilidade pelas atualizações. Se o registo estiver em atraso, confirme o processo atual da autoridade e atue com rapidez. A conclusão do registo não prova a implementação das medidas de segurança.
Para operações na Alemanha, verifique os requisitos KRITIS juntamente com as regras de transposição da NIS2 aplicáveis. Os dois regimes sobrepõem-se, mas não são idênticos. A abrangência pela NIS2 não designa automaticamente todas as instalações como instalações críticas, e um programa KRITIS já estabelecido não cumpre automaticamente todas as obrigações da NIS2.
Mantenha registos separados para a classificação da entidade, as instalações críticas e os deveres adicionais. Consulte as informações do BSI sobre a NIS2 para conhecer o processo nacional em vigor, em vez de confiar em anúncios antigos de prazos.
O artigo 4.º trata também de requisitos setoriais equivalentes da UE. Para as entidades financeiras abrangidas, o DORA pode reger as áreas relevantes. Determine que deveres se aplicam à entidade e ao serviço em concreto, em vez de manter, por defeito, circuitos de notificação duplicados.
O artigo 20.º atribui aos órgãos de gestão das entidades essenciais e importantes a aprovação e a supervisão da implementação. Prevê também a responsabilização por infrações ao artigo 21.º; as consequências jurídicas dependem do direito nacional e da forma jurídica da entidade.
A execução pode ser delegada nas equipas de segurança, TI, operações, compras e outras. A delegação deve preservar uma supervisão visível por parte da gestão. O papel do CEO não é configurar sistemas, mas garantir que os riscos significativos dos serviços recebem decisões informadas, recursos e acompanhamento.
Um dossiê de aprovação deve ligar a avaliação de riscos a um plano executável. Inclua os serviços abrangidos, os principais cenários de perturbação, as medidas propostas, as alternativas, as dependências de execução, as necessidades de pessoal, os marcos e as evidências esperadas.
Para cada obrigação, registe a implementação, o responsável, a evidência, a lacuna e a próxima decisão. Isto permite distinguir uma intenção aprovada de uma capacidade concluída. Expõe também medidas sem responsável identificado ou que dependem de recursos que nunca foram atribuídos.
As atas da gestão devem explicar a decisão e a sua fundamentação. Por exemplo, a aprovação de um investimento em recuperação deve registar que interrupção de serviço visa resolver, o resultado de recuperação esperado e as restrições operacionais. Uma assinatura numa política não explica se a gestão ponderou o problema de implementação que lhe está subjacente.
As discussões orçamentais devem incluir a capacidade interna e a interrupção da atividade, e não apenas a despesa com software. Uma alteração de rede pode exigir uma paragem da produção; uma revisão de um fornecedor pode exigir negociação jurídica; um teste de reposição pode exigir um ambiente isolado e pessoal de operações.
A aceitação de riscos merece especial cuidado. Pode documentar uma decisão de tratamento no âmbito de um processo de gestão de riscos, mas não pode dispensar um requisito legal. Quando uma exceção puder entrar em conflito com uma obrigação, obtenha uma interpretação jurídica, identifique proteções provisórias e mantenha a questão não resolvida visível.
Um projeto pode concluir a implantação de uma medida sem alcançar a proteção pretendida. Os relatórios à gestão devem responder a duas perguntas: se o trabalho aprovado está concluído e se funciona em toda a fronteira de serviço relevante.
| Pergunta para a gestão | Evidência útil | Decisão possível |
|---|---|---|
| Que serviço poderá sofrer a maior perturbação? | Avaliação de riscos do serviço e mapa de dependências | Reordenar as prioridades de investimento |
| Que trabalho aprovado continua bloqueado? | Marcos, bloqueios e salvaguardas provisórias | Reforçar a capacidade ou alterar a sequência |
| A recuperação consegue satisfazer as necessidades do negócio? | Resultados de reposição e dependências identificadas | Financiar melhorias ou rever as operações |
| Que constatações sobre fornecedores continuam por resolver? | Conclusões da avaliação e estado do tratamento | Restringir o acesso ou mudar de fornecedor |
| A notificação pode avançar fora do horário de expediente? | Cronologia do exercício e teste de autorização | Eliminar estrangulamentos de aprovação ou de acesso |
| Onde é que a garantia está incompleta? | Âmbito dos testes, exceções e limitações das evidências | Encomendar verificação adicional |
Defina uma cadência de revisão proporcional ao programa. Revisões trimestrais pela gestão podem ser práticas numa operação estável, com revisões mais frequentes durante a implementação. Trata-se de uma recomendação, e não de uma frequência universal prescrita pelo artigo 20.º.
Defina a escalada entre reuniões. Um teste de recuperação falhado, uma conta privilegiada comprometida ou uma dependência crítica recém-identificada não devem esperar pela próxima apresentação agendada.
O artigo 20.º exige que os membros dos órgãos de gestão frequentem formação suficiente para os ajudar a identificar riscos, avaliar as práticas de gestão de riscos e compreender as consequências para os serviços. Não fixa uma duração única para os cursos nem um intervalo de renovação universal.
A formação deve abordar a significância dos incidentes, os compromissos na recuperação, a concentração de fornecedores, as limitações das evidências e as decisões em contexto de incerteza. Inclua um cenário que obrigue os administradores a autorizar uma notificação, restringir operações ou financiar um tratamento urgente.
Conserve as datas, os participantes, os conteúdos e as ações de seguimento. A formação dos trabalhadores é também tratada no artigo 21.º, mas as sessões de sensibilização do pessoal não substituem a formação da própria gestão. A liderança deve conseguir questionar as alegações de garantia sem precisar de se tornar especialista técnica.
O artigo 21.º exige proteção técnica, operacional e organizativa proporcionada. A sua avaliação de proporcionalidade tem em conta a exposição, a dimensão da organização, o custo de implementação e a probabilidade e gravidade dos incidentes, incluindo os efeitos mais amplos na sociedade e na economia.
A abordagem exigida abrange perigos para além da atividade cibernética maliciosa. Uma falha de energia, uma inundação, uma intrusão física, a indisponibilidade de pessoal ou a perturbação das telecomunicações podem ameaçar o mesmo serviço.
Os exemplos de implementação seguintes são recomendações práticas. Explicam as dez áreas temáticas sem prescrever um desenho técnico idêntico para todas as entidades. Certos serviços digitais estão também sujeitos a requisitos de execução da UE mais detalhados; verifique a aplicabilidade antes de confiar apenas numa lista de verificação genérica.
Comece pelo serviço: o que tem de continuar a funcionar, quem depende dele e o que significaria uma perturbação. Mapeie os sistemas, as instalações, as pessoas e os prestadores externos que o suportam antes de atribuir classificações de risco.
Utilize critérios de impacto que distingam a perda financeira da segurança das pessoas, dos danos para os destinatários do serviço e de uma perturbação mais ampla. Registe cenários, proteções existentes, tratamentos propostos, exposição residual e fatores de reavaliação. Uma lista genérica de ameaças cibernéticas é menos útil do que uma explicação de como uma dependência concreta pode interromper o serviço.
O resultado é uma avaliação de riscos que apoia decisões, com políticas que descrevem como essas decisões se tornam requisitos operacionais.
Defina a deteção, a triagem, a escalada, a contenção, a investigação, a coordenação da recuperação e o encerramento. Nomeie um coordenador e substitutos e dê às equipas de resposta procedimentos utilizáveis para os incidentes prováveis.
A gravidade operacional e a significância legal estão relacionadas, mas são distintas. Um incidente técnico urgente pode exigir contenção antes de estar resolvida a obrigação legal de notificação. O processo deve suportar ambas as atividades sem permitir que uma bloqueie a outra.
Conserve as cronologias dos incidentes, as decisões, as evidências relevantes e as ações corretivas. Verifique se as melhorias acordadas foram concluídas; um documento de lições aprendidas sem seguimento oferece uma garantia fraca.
Utilize a análise de impacto no negócio para identificar as atividades essenciais e a perturbação aceitável. Acorde com os responsáveis pelos serviços os objetivos de tempo de recuperação e os objetivos de ponto de recuperação. Os primeiros dizem respeito ao tempo de reposição; os segundos, à perda de dados tolerável.
Os registos de conclusão das cópias de segurança são úteis, mas não demonstram que um serviço pode ser recuperado. Teste a reposição, as identidades de suporte, as chaves, as interfaces e os dados utilizáveis. Verifique se os sistemas recuperados conseguem suportar o fluxo de trabalho real do negócio.
As disposições de gestão de crises devem abranger as decisões operacionais e a comunicação, bem como a recuperação técnica. Registe os resultados dos testes, os objetivos não cumpridos, as ações e as decisões da gestão sobre a exposição remanescente.
Identifique os fornecedores diretos cuja falha ou comprometimento possa afetar materialmente o serviço. Considere o acesso administrativo, a informação sensível, as dependências de software e a disponibilidade.
Avalie a relevância da relação concreta para a segurança, incluindo as vulnerabilidades específicas do fornecedor e as suas práticas de produto ou de desenvolvimento. Ligue as constatações aos controlos de acesso, às disposições contratuais, aos planos de contingência e aos fatores de revisão.
Um certificado do fornecedor pode apoiar a avaliação. Não abrange automaticamente o serviço que adquiriu, a sua configuração nem as suas responsabilidades de integração.
Defina critérios de aceitação de segurança para aquisições e novos sistemas. Defina responsabilidades pelo desenvolvimento seguro, pela configuração, pelas alterações, pela manutenção, pelas atualizações e pelos relatórios de vulnerabilidades recebidos.
Acompanhe as vulnerabilidades significativas ao longo da avaliação, do tratamento, da gestão de exceções e da verificação. As prioridades de correção devem refletir o potencial de exploração e as consequências para o serviço, e não apenas uma classificação numérica de gravidade.
A tecnologia operacional pode exigir validação pelo fabricante e paragens planeadas antes da aplicação de correções. Documente as salvaguardas provisórias e o calendário de tratamento. «Não é possível corrigir» é uma restrição a gerir, não uma decisão de risco completa.
Para as medidas importantes, defina a pergunta a que o teste tem de responder. Uma revisão de acessos verifica a autorização; um exercício de reposição verifica a recuperação; uma simulação de incidente verifica a coordenação e a tomada de decisões.
Registe o âmbito testado, o resultado esperado, o método, o revisor, as constatações e a resposta em caso de falha. Recorra a garantia independente quando esta acrescentar valor ou quando as regras aplicáveis o exigirem.
O artigo 21.º exige uma avaliação da eficácia, mas não impõe uma frequência única de testes de intrusão a todas as organizações abrangidas. Os testes devem corresponder à necessidade de garantia e a quaisquer requisitos detalhados relevantes.
Dê ao pessoal instruções práticas para comunicar atividades suspeitas, proteger credenciais, tratar informação e trabalhar de forma segura. Acrescente conteúdos específicos por função para programadores, administradores, pessoal de compras e equipas de resposta.
A presença em ações de formação mostra participação, não necessariamente a capacidade de agir. Os exercícios e o desempenho observado podem revelar instruções pouco claras ou circuitos de escalada fracos.
Utilize as constatações para melhorar os procedimentos. Se os trabalhadores comunicam corretamente mensagens suspeitas, mas a equipa que as recebe responde com lentidão, repetir o mesmo curso de sensibilização não resolve o problema de fundo.
Defina que informação e que fluxos de trabalho precisam de proteção criptográfica, incluindo os dados relevantes em trânsito e em repouso. Identifique a titularidade das chaves e dos certificados, a renovação, a revogação, o acesso e a recuperação.
As evidências devem incluir decisões de configuração e disposições de gestão de chaves, e não apenas a afirmação de que existe cifragem. A proteção pode falhar se as cópias de segurança cifradas dependerem de chaves indisponíveis ou se o acesso às chaves não estiver devidamente restringido.
Mantenha exceções justificadas e reveja-as quando os sistemas ou os riscos mudarem. Evite considerar suficiente uma afirmação genérica como «está tudo cifrado».
Ligue as contratações, as mudanças de função e as saídas às decisões de acesso. Identifique os responsáveis de negócio, os administradores, as contas externas, as identidades de serviço e os ativos relevantes.
Reveja os acessos privilegiados e remova as permissões que já não se justificam. Inclua na avaliação as contas partilhadas ou não humanas, em vez de a limitar às listas de utilizadores dos trabalhadores.
As evidências podem incluir pedidos aprovados, amostras de registos de saída, revisões de acessos concluídas e exceções resolvidas. Um inventário de ativos deve explicar a titularidade e a dependência dos serviços, e não apenas contar dispositivos.
O artigo 21.º trata da autenticação reforçada e das comunicações protegidas, incluindo as disposições de emergência, com uma ressalva de adequação.
Como prioridade prática, analise os acessos privilegiados e remotos aos serviços críticos. Identifique as limitações dos sistemas legados e avalie alternativas de proteção, em vez de presumir que todos os sistemas suportam o mesmo mecanismo.
Teste também a comunicação de crise quando o correio eletrónico habitual, as ferramentas de colaboração ou os serviços de identidade estiverem indisponíveis. Um procedimento de emergência que dependa inteiramente da plataforma que falhou pode ser inutilizável precisamente quando é necessário.
A segurança da cadeia de abastecimento torna-se muitas vezes uma questão de gestão, porque as compras não conseguem eliminar todas as dependências através de um questionário. Comece pela consequência da falha: este fornecedor pode interromper a prestação, introduzir alterações não autorizadas, expor informação ou impedir a recuperação?
Para os fornecedores diretos críticos, registe o serviço suportado, o acesso concedido, o responsável pela avaliação, a garantia revista, as constatações pendentes e as decisões de tratamento. Verifique o âmbito e o período abrangidos pelos documentos de garantia. Um relatório que abrange outro serviço ou um modelo operacional anterior pode não responder à pergunta atual.
A negociação contratual deve tratar os riscos da relação. Os temas práticos incluem as responsabilidades de segurança, a comunicação de incidentes, a cooperação na investigação, o tratamento de vulnerabilidades, as restrições de acesso, a disponibilidade de evidências, a continuidade e o apoio à saída. Trata-se de temas de negociação recomendados, e não de cláusulas legais idênticas para todos os contratos.
As disposições de notificação por parte dos fornecedores devem suportar o seu calendário de notificação. Confirme os contactos operacionais e os substitutos; a caixa de correio do gestor de conta, disponível apenas no horário de expediente, pode ser inadequada para um incidente grave.
O artigo 21.º trata especificamente das relações diretas. As dependências a montante podem, ainda assim, ser relevantes quando criam risco de concentração ou comprometem a recuperação. Aprofunde a investigação quando isso alterar a decisão, em vez de tentar um inventário ilimitado de todos os fornecedores dos fornecedores.
Se a garantia continuar a ser insuficiente, a gestão pode restringir o acesso, reforçar a monitorização, negociar melhorias, introduzir alternativas, redesenhar a dependência ou substituir o prestador. Registe a fundamentação e as medidas provisórias. Subcontratar a prestação de serviços não elimina a responsabilidade pelo programa de gestão de riscos da própria entidade.
O artigo 23.º estabelece a notificação de incidentes significativos. Um incidente é significativo se causar ou for suscetível de causar perturbações operacionais graves dos serviços ou perdas financeiras para a entidade, ou danos materiais ou imateriais consideráveis a outras pessoas singulares ou coletivas. Confirme as regras nacionais e setoriais de significância aplicáveis antes de desenhar o processo de decisão.
O prazo conta a partir do conhecimento de um incidente significativo, e não da conclusão da análise forense. Registe quando a informação relevante ficou disponível, a avaliação da significância e quem tomou a decisão. Não fabrique um momento de conhecimento posterior atrasando a escalada interna.
| Fase de notificação | Base da diretiva | Preparação necessária |
|---|---|---|
| Alerta precoce | Sem demora injustificada; no prazo máximo de 24 horas após o conhecimento | Avaliação de possível atividade maliciosa ou ilícita e de efeitos transfronteiriços |
| Notificação do incidente | Sem demora injustificada; em regra, no prazo de 72 horas após o conhecimento | Informação atualizada, avaliação inicial do impacto e da gravidade, indicadores de comprometimento disponíveis |
| Relatório intercalar | A pedido da autoridade ou da CSIRT | Ponto de situação atual e evoluções relevantes |
| Relatório final | Em regra, no prazo de um mês após a notificação | Efeitos detalhados, causa ou ameaça provável, medidas de mitigação e consequências transfronteiriças relevantes |
| Incidente ainda em curso | Relatório de progresso ao fim de um mês | Progresso até ao momento, seguido de um relatório final no prazo de um mês após a conclusão do tratamento |
Os prestadores de serviços de confiança têm uma disposição específica de notificação em 24 horas para incidentes significativos que afetem os seus serviços de confiança. Tanto as entidades essenciais como as importantes têm deveres de notificação faseados; a classificação como entidade importante não elimina o alerta precoce.
Nomeie o responsável pela avaliação, a pessoa autorizada a submeter, o substituto, o contacto jurídico e o circuito de escalada para a gestão. Acorde a forma de aprovar informação provisória. A gestão precisa de visibilidade sem se tornar um estrangulamento inevitável para cada submissão.
Prepare modelos que separem os factos confirmados, as avaliações preliminares, as incógnitas e as atualizações previstas. Evite atribuições sem fundamento ou promessas de recuperação. A notificação precoce deve ser rigorosa quanto à incerteza, e não artificialmente completa.
Teste o acesso ao canal de notificação, as credenciais, os contactos e as soluções alternativas. Se a pessoa que submete depender de um serviço de identidade corporativo comprometido, o processo precisa de uma alternativa.
Faça um exercício com um cenário à noite ou ao fim de semana. Meça o tempo necessário para reconhecer a potencial significância, reunir as pessoas necessárias, preparar o alerta, autorizá-lo e chegar ao canal. Mantenha esta atividade ligada à contenção e à recuperação, atribuindo pessoas suficientes para evitar que a notificação absorva toda a equipa de resposta.
O artigo 23.º trata também da comunicação aos destinatários dos serviços, quando adequado. Os contratos e outras leis podem criar notificações adicionais. Uma violação de dados pessoais exige a sua própria avaliação ao abrigo do RGPD; uma submissão ao abrigo da NIS2 não a satisfaz automaticamente. Coordene os factos, mantendo decisões e prazos separados.
As políticas, as certificações, os acordos com fornecedores e os comprovativos de registo podem apoiar a preparação. Ainda assim, as evidências têm de mostrar o que funciona dentro do âmbito aplicável.
Distinga conceção, implementação e funcionamento. Uma política de acessos descreve o comportamento pretendido. As evidências de configuração mostram a implantação. Uma revisão de acessos concluída, que mostre permissões removidas e exceções resolvidas, demonstra o funcionamento. Estes registos respondem a perguntas diferentes e não devem ser tratados como intermutáveis.
Para cada evidência, conserve a origem, o âmbito, a data ou o período, o responsável, o revisor, a conclusão e as limitações. Um teste de reposição bem-sucedido de uma aplicação não prova a recuperação de todo o ambiente. Uma captura de ecrã pode mostrar uma configuração num dado momento, e não um funcionamento continuado.
Proteja as evidências sensíveis. Os registos de incidentes, os diagramas de arquitetura e as exportações de acessos podem expor informação operacional ou pessoal. Defina regras adequadas de acesso, conservação e partilha externa.
As lacunas de evidências devem tornar-se tarefas. «Sem teste recente», «âmbito do fornecedor pouco claro» e «o responsável não reviu a exportação» são problemas distintos que exigem ações diferentes. Uma contagem de documentos não os revela.
Um SGSI segundo a ISO 27001 pode fornecer registos de avaliação e tratamento de riscos, políticas, auditorias, revisões pela gestão e funcionamento. Compare a sua fronteira certificada com as entidades e os serviços abrangidos pelas regras nacionais da NIS2.
A certificação das TI corporativas pode excluir sistemas de produção, um serviço gerido ou uma empresa adquirida. Reutilize os controlos e as evidências relevantes e trate depois de forma explícita a classificação, o registo, a notificação legal e a formação da gestão. O nosso guia sobre NIS2 e ISO 27001 explica como o trabalho já existente no SGSI pode apoiar este processo.
A NIS2 não cria um certificado geral de conformidade da UE. A certificação apoia a garantia dentro do seu próprio âmbito; não resolve todos os deveres legais. Aplique as mesmas verificações de relevância às evidências KRITIS existentes, em vez de presumir que uma aceitação anterior cobre as obrigações atuais.
Considere, a título ilustrativo, um fabricante alemão com 180 trabalhadores que produz equipamentos no âmbito de uma atividade de fabrico enumerada no Anexo II. Suponha que um cálculo revisto confirma o estatuto de média empresa, que a análise nacional confirma a classificação como entidade importante e que uma avaliação separada não identifica qualquer designação como instalação crítica KRITIS. Estes pressupostos são específicos do exemplo, e não uma regra para todos os fabricantes dessa dimensão.
O primeiro foco da implementação é o planeamento da produção numa fábrica. As dependências incluem uma aplicação ERP, controladores industriais, serviços de identidade, cópias de segurança e um fornecedor de manutenção com acesso remoto. A avaliação do âmbito jurídico continua a abranger as obrigações relevantes da entidade para além deste serviço inicial.
A revisão identifica três fragilidades relacionadas. Os técnicos do fornecedor partilham uma conta privilegiada. As tarefas de cópia de segurança concluem-se, mas nenhum teste de reposição recente inclui a dependência de identidade da aplicação de planeamento. O procedimento de incidentes indica um responsável pela notificação, sem um substituto autorizado a submeter.
A gestão pede opções, em vez de aprovar três atualizações de políticas isoladas. As operações propõem um acesso do fornecedor nominativo e limitado no tempo, através de um canal de acesso remoto controlado. As TI propõem um exercício de reposição do serviço face a objetivos aprovados pelo negócio. A segurança e a área jurídica propõem uma autoridade de notificação alternativa e um ensaio fora do horário de expediente.
Apenas para efeitos de planeamento, considere seis semanas e uma janela de manutenção agendada. A gestão aprova a capacidade de pessoal, as disposições para a paragem e restrições provisórias ao acesso do fornecedor. O registo da decisão explica as consequências para o serviço, por que razão os tratamentos foram escolhidos e que evidências demonstrarão a sua conclusão.
O trabalho sobre os acessos produz registos de configuração, uma confirmação por parte do fornecedor e uma revisão que confirma a remoção da conta partilhada. O exercício de reposição recupera os dados, mas não cumpre o tempo de recuperação do serviço acordado, porque a autenticação não pode ser reposta com rapidez. Essa constatação continua em aberto: tarefas de cópia de segurança bem-sucedidas não se sobrepõem ao resultado falhado do serviço.
A gestão decide então se melhora a solução de recuperação da identidade, altera a arquitetura ou adota uma contingência operacional diferente. Qualquer objetivo de recuperação revisto precisa de uma fundamentação de negócio e tem de permanecer coerente com as obrigações aplicáveis.
O ensaio de notificação revela que o substituto não consegue aceder de forma independente ao canal de notificação. A equipa corrige a dependência de acesso e volta a testá-la. A preparação melhora através de alterações verificadas e decisões revistas, e não através de uma declaração de que os procedimentos revistos estão concluídos.
Os artigos 32.º e 33.º distinguem abordagens de supervisão. As entidades essenciais podem ser sujeitas a poderes de inspeção e auditoria proativos. As entidades importantes estão sujeitas a supervisão ex post quando há informações que indiciam um possível incumprimento. Nenhuma delas deve interpretar a ausência de incidentes ou de pedidos da autoridade como prova de preparação.
Para infrações aos artigos 21.º ou 23.º, o artigo 34.º exige que os montantes máximos das coimas nacionais atinjam, pelo menos, os seguintes níveis: para as entidades essenciais, o valor mais elevado entre 10 milhões de euros e 2 % do volume de negócios anual a nível mundial da empresa em causa; para as entidades importantes, o valor mais elevado entre 7 milhões de euros e 1,4 %. Estes valores são pisos para os limites máximos nacionais das coimas, e não montantes de coima padrão nem tetos fixos universais.
As autoridades dispõem também de poderes corretivos. O artigo 32.º prevê mecanismos condicionais para as entidades essenciais que envolvem a certificação ou autorização relevante e restrições temporárias ao exercício de determinadas funções de gestão após as etapas de execução previstas. Não se trata de consequências automáticas de qualquer incidente, e a disposição exclui as entidades da administração pública.
A responsabilidade dos administradores e o tratamento em matéria de seguros exigem aconselhamento específico da jurisdição. A liderança deve concentrar-se em registos verdadeiros, num tratamento atempado e numa supervisão informada, em vez de encarar as potenciais sanções como substituto da implementação das medidas exigidas.
Comece a execução pelo serviço com maior impacto e pelas suas dependências, mantendo completa a avaliação jurídica para todas as entidades relevantes. Dê prioridade à urgência legal, às consequências para os serviços e às tarefas que desbloqueiam trabalho posterior. Uma fronteira de implementação focada ajuda a estabelecer o fluxo de trabalho; não reduz as obrigações legais da entidade a esse piloto.
A próxima revisão pela gestão deve aprovar ou resolver a decisão de âmbito, confirmar as disposições de registo e de notificação, financiar os tratamentos prioritários, atribuir responsáveis e agendar exercícios de recuperação e de notificação. Deve também definir quando a gestão vai rever as evidências de funcionamento e que constatações exigem uma escalada antecipada.
No Secani, as equipas podem modelar o serviço selecionado, os sistemas de suporte e as dependências de prestadores externos, e depois ligar requisitos, controlos, responsáveis e evidências revistas. As provas em falta e as conclusões por resolver podem tornar-se tarefas. Os revisores humanos devem aprovar os mapeamentos e as conclusões sobre as evidências, conservando as ligações às fontes, os comentários, as aprovações e os registos temporais, para que o raciocínio permaneça verificável.
Leve para essa reunião um mapa de serviços, um registo de obrigações e as lacunas com maiores consequências. Saia dela com ações financiadas, uma autoridade de notificação utilizável e uma data para analisar os resultados, e não apenas com o compromisso de produzir mais documentação.
A Secani liga âmbitos, evidências, tarefas e agentes de IA num espaço de trabalho partilhado.
Utilize um SGSI existente para apoiar a implementação da NIS2, preservando os deveres legais, as diferenças de âmbito e os requisitos de notificação.
Ligue o âmbito do CRA, o tratamento de vulnerabilidades, os compromissos de suporte e as evidências dos produtos ao calendário atual de notificação e de aplicação.
Aproveite o próximo Dia da Proteção de Dados para ensaiar pedidos, rever fluxos de dados, melhorar a conservação e medir resultados práticos.