NIS2 e ISO 27001: reutilize controlos e examine as lacunas

Um programa ISO 27001 pode proporcionar uma estrutura operacional sólida para a NIS2: avaliação de riscos, responsáveis designados, controlos, evidências e melhoria. O passo seguinte é uma avaliação, requisito a requisito, daquilo que essa estrutura cobre efetivamente.

Para um CTO, a pergunta útil não é se os referenciais se sobrepõem. É saber se um controlo implementado protege o serviço relevante, satisfaz a obrigação aplicável e produz evidências que sustentam essa conclusão. Reutilize a implementação quando essas condições se verificam; preserve as diferenças jurídicas e operacionais quando não se verificam.

Compreenda o que cada referencial estabelece

A ISO/IEC 27001 especifica requisitos para um sistema de gestão da segurança da informação, ou SGSI, com âmbito definido. As cláusulas 4 a 10 abordam a sua estrutura de gestão, incluindo o tratamento do risco, a avaliação do desempenho e a melhoria. O Anexo A contém 93 controlos de referência nas categorias organizacional, de pessoas, física e tecnológica. A aplicabilidade dos controlos baseia-se no risco; não é um requisito para implementar todos os controlos de forma idêntica. A ISO 27002 fornece orientações de implementação.

A NIS2 é uma diretiva da UE transposta através da legislação nacional. A aplicabilidade depende do setor, da dimensão, do serviço e de regras de inclusão específicas. Os Anexos I e II identificam os setores relevantes, mas o setor, por si só, não determina se uma organização é uma entidade essencial ou importante. Algumas entidades estão abrangidas independentemente da dimensão.

As diferenças práticas são:

A certificação é realizada por organismos de certificação independentes, não pela ISO. Não estabelece a conformidade com a NIS2, e a NIS2 não exige, em geral, a certificação ISO 27001. A aplicação da lei pode incluir medidas de supervisão e sanções; a certificação ISO tem uma finalidade de garantia diferente.

Comece por fazer coincidir as fronteiras

Compare o âmbito do SGSI certificado com as entidades jurídicas e os serviços sujeitos à NIS2. Um certificado que abrange uma equipa de desenvolvimento pode deixar fora da sua fronteira as operações de produção, outra filial ou localizações adicionais.

Crie uma comparação de âmbitos que registe:

• As entidades jurídicas, os países e os serviços abrangidos e o fundamento da inclusão.
• Os sistemas, redes, localizações e fornecedores de suporte relevantes.
• O âmbito do SGSI, o âmbito do certificado e as exclusões.
• Os requisitos nacionais, as regras setoriais e as autoridades responsáveis aplicáveis, incluindo os deveres de registo, a informação exigida sobre a entidade, os canais de submissão e as obrigações de atualização.
• Quem aprovou a avaliação de aplicabilidade e quando tem de ser revista.

Distinga uma lacuna de âmbito de uma lacuna de controlo. Um ambiente de produção fora do SGSI pode já ter bons controlos de acesso, mas esses controlos continuam a precisar de responsável, avaliação e evidências no âmbito da frente de trabalho da NIS2.

Verifique a legislação setorial antes de duplicar obrigações. O artigo 4.º aborda a relação com os atos jurídicos setoriais da UE. Para as entidades financeiras, a relação com o DORA exige uma análise específica de cada papel. Para operações na Alemanha, consulte a informação do BSI sobre a NIS2, em vez de presumir que os deveres KRITIS existentes e os deveres da NIS2 são idênticos.

Mapeie controlos implementados, e não rótulos coincidentes

O artigo 21.º exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas. As suas dez áreas mínimas de medidas constituem um ponto de partida para o mapeamento, mas uma redação semelhante é uma pista útil, não uma prova de equivalência.

Utilize o seguinte como pontos de revisão, e não como declarações automáticas de cobertura:

A Declaração de Aplicabilidade regista os controlos necessários e a fundamentação da sua inclusão ou exclusão. Não é intercambiável com o plano de tratamento do risco, as constatações da auditoria interna ou os registos da revisão pela gestão. Utilize esses artefactos em conjunto para explicar tanto o desenho como o funcionamento.

Uma política estabelece expectativas. Uma exportação de configuração pode mostrar a implementação. Os resultados de revisões de acessos, os tickets de correção e os registos de testes podem mostrar o funcionamento. Reutilize evidências apenas quando o sistema, o período e o objetivo da avaliação coincidirem.

Evite percentagens fixas de sobreposição. A cobertura depende da implementação e do âmbito jurídico; um número universal não consegue estabelecer o grau de preparação.

Construa um percurso de notificação de incidentes que funcione sob pressão

Um plano de resposta alinhado com a ISO pode apoiar a deteção, a contenção, a investigação e a recuperação sem definir a notificação regulamentar. O artigo 23.º da NIS2 acrescenta obrigações de notificação para incidentes significativos.

As fases de notificação da diretiva incluem, em geral:

• Um alerta precoce, sem demora injustificada e no prazo de 24 horas após ter tido conhecimento de um incidente significativo.
• Uma notificação do incidente, sem demora injustificada e no prazo de 72 horas, que atualize o alerta precoce e apresente uma avaliação inicial.
• Um relatório final, em geral no prazo de um mês após a apresentação da notificação do incidente. No caso de um incidente em curso, é exigido nesse momento um relatório intercalar de progresso, sendo o relatório final devido no prazo de um mês após o tratamento do incidente.

Tem também de ser apresentado um relatório intercalar, se solicitado pela CSIRT ou pela autoridade competente.

Verifique as regras nacionais e setoriais aplicáveis: a diretiva prevê um prazo de notificação diferente para os prestadores de serviços de confiança. Não utilize um limiar genérico de indisponibilidade como substituto dos critérios de significância aplicáveis.

Como recomendação prática de implementação, crie um runbook de notificação que especifique o responsável pela avaliação, a via de escalamento, a pessoa autorizada a submeter, o pessoal de reserva, o canal da autoridade e a informação necessária em cada fase. Registe separadamente as marcas temporais da deteção, do conhecimento, da avaliação de significância e da submissão.

Exercite o processo com informação incompleta. A equipa deve conseguir submeter o relatório inicial exigido sem esperar por uma investigação forense concluída. Preserve as versões submetidas, os comprovativos de receção, os factos de suporte e as decisões sobre se um incidente atinge o limiar.

Quando se aplicar também outro regime de notificação, coordene a investigação, mas avalie cada dever de notificação separadamente. Um registo de incidente partilhado não torna idênticos os destinatários, os fatores desencadeadores ou os prazos.

Torne a governação e a resiliência demonstráveis

O artigo 20.º exige que os órgãos de gestão aprovem as medidas de gestão dos riscos de cibersegurança e supervisionem a sua aplicação. Aborda também a formação dos membros dos órgãos de gestão. Uma revisão pela gestão existente é uma evidência útil, mas verifique se regista explicitamente as aprovações, a supervisão, as decisões e o seguimento relevantes.

Dê à gestão uma visão pronta para decisão: serviços afetados, riscos materiais, opções de tratamento, exceções por resolver e resultados de eficácia. Atas de reunião que se limitam a indicar “foi discutida a segurança” fornecem poucas evidências de uma supervisão significativa. Atribua a cada ação aprovada um responsável e uma data de revisão.

A continuidade precisa de um tratamento igualmente concreto. O artigo 21.º inclui as cópias de segurança, a recuperação de desastres e a gestão de crises; não impõe um requisito universal de certificação ISO 22301. Determine a profundidade necessária a partir do serviço, dos riscos e das regras aplicáveis.

Teste a reposição e a recuperação do serviço, e não apenas a conclusão das tarefas de backup. Inclua dependências como os serviços de identidade, o DNS, o suporte de fornecedores, as credenciais privilegiadas e as comunicações quando o ambiente normal está indisponível. Registe os resultados de recuperação alcançados e os bloqueios por resolver face aos objetivos acordados.

Mantenha um registo de diferenças visível

Para cada requisito, registe a sua fonte e versão, os controlos mapeados, o âmbito, as referências às evidências, o revisor e a fundamentação da reutilização. Distinga cobertura sustentada, cobertura parcial, implementação em falta, evidências em falta e uma decisão fundamentada de não aplicabilidade. A ausência de um documento nem sempre significa a ausência de um controlo, mas exige investigação.

Cada lacuna precisa de um responsável, da alteração necessária, de uma expectativa quanto às evidências, de uma data-limite e de um revisor do encerramento. Dê prioridade às falhas que ameaçam serviços ou impedem notificações sujeitas a prazos críticos, em vez de tratar todas as tarefas de documentação como igualmente urgentes.

Os erros comuns incluem mapear apenas o Anexo A e ignorar os requisitos de governação, aceitar o certificado de um fornecedor sem verificar o seu âmbito, tratar as evidências do ano anterior como atuais e encerrar uma tarefa quando uma política é publicada mas o processo continua por testar. O registo ou a certificação nunca devem ser tratados como prova de implementação operacional.

Exemplo prático: alargar um SGSI existente

Pressupostos ilustrativos: um prestador de serviços geridos tem um SGSI certificado pela ISO 27001 que abrange a sua equipa operacional principal. A sua avaliação de aplicabilidade conclui que um serviço operado através de uma entidade jurídica adicional está sujeito à NIS2. Essa entidade utiliza a mesma plataforma de identidades e a mesma equipa de incidentes, mas tem soluções de recuperação separadas.

A equipa começa por comparar as fronteiras dos serviços. As configurações de autenticação existentes podem suportar ambos os âmbitos, mas o revisor verifica se os administradores, as contas de emergência e as contas de serviço da entidade adicional estão incluídos. Uma exportação da revisão de acessos que abranja apenas a equipa original não consegue provar uma cobertura completa.

Em seguida, o responsável pelos incidentes mantém o procedimento de resposta estabelecido e acrescenta uma avaliação de incidentes significativos e um percurso de notificação às autoridades. Um exercício de mesa simula uma indisponibilidade de um fornecedor com impacto incerto nos clientes. Os participantes registam quando tiveram conhecimento dos factos relevantes, quem decidiu sobre a significância e como seria submetido um alerta precoce.

Por fim, o responsável pela infraestrutura realiza um exercício de recuperação do serviço da entidade adicional. O teste revela que as credenciais de recuperação dependem da plataforma de identidades indisponível. O registo de lacunas atribui uma ação corretiva e exige um novo teste bem-sucedido antes do encerramento.

Os resultados são uma comparação de âmbitos, mapeamentos revistos, evidências alargadas da revisão de acessos, registos do exercício de notificação, resultados da recuperação e a aprovação pela gestão das ações de tratamento pendentes. Os controlos partilhados continuam partilhados; as evidências e decisões específicas de cada entidade continuam visíveis.

Transforme a avaliação em trabalho mantido

O modelo de requisitos e evidências ligados da Secani dá às equipas uma estrutura para preservar o trabalho partilhado e as decisões específicas de cada referencial. Modele os serviços e as dependências, associe as evidências existentes aos controlos relevantes e transforme a cobertura em falta em tarefas com responsável. Mantenha explícita a aprovação humana dos mapeamentos e das conclusões sobre evidências, incluindo as sugestões assistidas por IA. O nosso guia sobre mapeamento rastreável entre referenciais explica como manter a fundamentação subjacente à reutilização.

Comece com um serviço regulado. Reúna o seu âmbito, o tratamento do risco, a Declaração de Aplicabilidade, o runbook de incidentes e as evidências de testes recentes numa revisão conjunta técnica e de conformidade. Produza um registo de diferenças revisto e utilize depois os ciclos normais de revisão do SGSI para o manter à medida que os serviços, os fornecedores e os requisitos mudam.