Evidência de registo NIS2 na ISO 27001:2022

O e-mail chegou à caixa de entrada da Anna com um impacto discreto que soou como uma sirene. Enquanto CISO da CloudFlow, um prestador B2B SaaS em rápido crescimento que serve clientes em toda a UE, ela estava habituada a questionários de segurança, auditorias de aquisição e auditorias de acompanhamento ISO 27001. Esta mensagem era diferente.

O assunto dizia: “Pedido de informação relativo à implementação nacional da Diretiva (UE) 2022/2555 (NIS2)”. A autoridade nacional de cibersegurança pretendia que a CloudFlow confirmasse a sua classificação, preparasse informação de registo da entidade, identificasse os serviços abrangidos e estivesse pronta para demonstrar medidas de gestão de riscos de cibersegurança.

Anna tinha um certificado ISO 27001:2022 emoldurado na parede. A equipa comercial utilizava-o em negócios empresariais. O conselho de administração tinha aprovado a Política de Segurança da Informação. A auditoria interna tinha encerrado recentemente duas constatações. Mas a pergunta à sua frente era mais exigente do que o estado da certificação.

A CloudFlow conseguiria provar, de forma rápida e defensável, que o seu SGSI ISO 27001:2022 cobria as obrigações NIS2?

É aqui que muitas organizações dão o passo errado. Tratam o registo de entidade NIS2 como uma formalidade administrativa, semelhante à atualização de um registo comercial ou de um portal fiscal. Não é. O registo é a porta de entrada para a visibilidade perante as autoridades de supervisão. Depois dessa porta, a autoridade competente pode solicitar a fundamentação do âmbito, registos de aprovação pelo conselho de administração, procedimentos de comunicação de incidentes, evidência de risco de fornecedores, pontos de contacto, métricas de eficácia dos controlos e prova de que a organização sabe quais são os seus serviços críticos.

Para prestadores SaaS, serviços em nuvem, serviços geridos, segurança gerida, centros de dados, infraestrutura digital e determinados prestadores do setor financeiro, a verdadeira pergunta já não é “Temos uma política de segurança?”. É “Conseguimos demonstrar uma cadeia de evidência desde a obrigação legal até ao âmbito do SGSI, ao tratamento de riscos, à operação dos controlos e à supervisão pela gestão?”.

O programa mais sólido de preparação para a aplicação da NIS2 não é uma folha de cálculo paralela. É um modelo de evidência rastreável dentro da ISO 27001:2022.

O registo NIS2 é, na prática, um problema de evidência

A NIS2 aplica-se amplamente a entidades públicas ou privadas dos setores constantes do Anexo I e do Anexo II que atinjam ou excedam o limiar aplicável de média empresa. Também abrange determinadas entidades independentemente da dimensão, incluindo prestadores de redes ou serviços públicos de comunicações eletrónicas, prestadores de serviços de confiança, registos TLD, prestadores de serviços DNS, prestadores únicos de serviços essenciais e entidades cuja perturbação possa afetar a segurança pública, a saúde, o risco sistémico ou a criticidade nacional ou regional.

Para empresas tecnológicas, as categorias digitais são especialmente importantes. O Anexo I inclui infraestrutura digital, como prestadores de serviços de computação em nuvem, prestadores de serviços de centro de dados, prestadores de redes de distribuição de conteúdos, prestadores de serviços de confiança, prestadores de serviços DNS e prestadores de redes ou serviços públicos de comunicações eletrónicas. O Anexo I também inclui a gestão de serviços TIC para serviços entre empresas, incluindo prestadores de serviços geridos e prestadores de serviços de segurança geridos. O Anexo II inclui prestadores digitais, como mercados em linha, motores de pesquisa em linha e plataformas de serviços de redes sociais.

Isto significa que uma organização pode entrar no âmbito da NIS2 sem se considerar “infraestrutura crítica”. Uma empresa B2B SaaS com funcionalidades de segurança gerida, uma plataforma em nuvem que suporta clientes regulados ou um prestador adjacente ao setor fintech pode subitamente precisar de um dossier de registo, de um modelo de contacto com a autoridade competente e de uma narrativa de controlos defensável.

A NIS2 também distingue entidades essenciais e importantes. As entidades essenciais enfrentam, em geral, um modelo de supervisão mais proativo, enquanto as entidades importantes são normalmente supervisionadas após evidência de incumprimento ou incidentes. A distinção é relevante, mas não elimina a necessidade de preparação. Ambas as categorias precisam de governação, gestão de riscos, comunicação de incidentes, segurança de fornecedores e evidência.

As entidades financeiras também devem considerar o DORA. O NIS2 Article 4 reconhece que, quando um ato jurídico setorial da União impõe obrigações de gestão de riscos de cibersegurança e de comunicação de incidentes pelo menos equivalentes, essas regras setoriais aplicam-se às áreas correspondentes. O DORA é aplicável a partir de 17 de janeiro de 2025 e estabelece gestão do risco das TIC, comunicação de incidentes graves relacionados com TIC, testes de resiliência operacional digital, partilha de informações, gestão do risco de terceiros de TIC, controlos contratuais e supervisão de prestadores terceiros críticos de serviços de TIC. Para as entidades financeiras abrangidas, o DORA é o principal quadro de ciber-resiliência para requisitos sobrepostos, mas as interfaces NIS2 e a coordenação com autoridades nacionais continuam a ser relevantes.

A lição é simples. Não espere pelo campo do portal ou pelo e-mail do regulador para construir evidência. Cada resposta de registo implica uma futura pergunta de auditoria.

Comece pelo âmbito do SGSI, não pelo formulário do portal

A ISO 27001:2022 é útil porque obriga a organização a definir contexto, partes interessadas, obrigações regulamentares, âmbito, riscos, planos de tratamento, operação dos controlos, monitorização, auditoria interna, revisão pela gestão e melhoria.

As cláusulas 4.1 a 4.4 exigem que a organização determine questões internas e externas, identifique partes interessadas e respetivos requisitos, decida quais os requisitos a endereçar através do SGSI, defina o âmbito do SGSI considerando interfaces e dependências, documente esse âmbito e opere os processos do SGSI.

Para a NIS2, esse âmbito deve responder a perguntas práticas:

• Que serviços da UE, entidades jurídicas, subsidiárias, plataformas, componentes de infraestrutura e unidades de negócio são relevantes?
• Que categoria do Anexo I ou do Anexo II pode aplicar-se?
• A organização é essencial, importante, abrangida pelo DORA, fora do âmbito ou aguarda classificação nacional?
• Que serviços são críticos para clientes, segurança pública, estabilidade financeira, cuidados de saúde, infraestrutura digital ou outros setores regulados?
• Que prestadores de serviços em nuvem, MSP, MSSP, centros de dados, subcontratantes e outros fornecedores suportam esses serviços?
• Que Estados-Membros, autoridades competentes, CSIRT, autoridades de controlo e supervisores financeiros podem ser relevantes?

O Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec Zenith Blueprint coloca este trabalho numa fase inicial, no Passo 2, necessidades das partes interessadas e âmbito do SGSI. Instrui as organizações a identificar reguladores e autoridades, rever requisitos legais e regulamentares, rever contratos e acordos, conduzir entrevistas com partes interessadas e considerar normas setoriais expectáveis.

Item de ação 4.2: Compile uma lista de todas as partes interessadas significativas e registe os respetivos requisitos relacionados com segurança da informação. Seja exaustivo — pense em qualquer pessoa que reclamaria ou sofreria consequências se a sua segurança falhasse ou se faltasse determinado controlo. Esta lista orientará aquilo que deve cumprir ou satisfazer através do seu SGSI e alimentará a avaliação de riscos e a seleção de controlos.

Este é o ponto de partida correto para o registo NIS2. Antes da submissão, crie uma breve nota de âmbito NIS2 que ligue o modelo de negócio às categorias do Anexo I ou do Anexo II, documente pressupostos de dimensão e de serviço, registe a interpretação da lei nacional, identifique autoridades competentes e indique se DORA, RGPD, contratos com clientes ou regras setoriais também se aplicam.

A Política de Conformidade Legal e Regulamentar para PME da Clarysec Política de Conformidade Legal e Regulamentar - PME define claramente a finalidade:

“Esta política define a abordagem da organização para identificar, cumprir e demonstrar conformidade com obrigações legais, regulamentares e contratuais.”

Para programas maiores, a Política de Conformidade Legal e Regulamentar da Clarysec Política de Conformidade Legal e Regulamentar é ainda mais explícita:

“Todas as obrigações legais e regulamentares devem ser mapeadas para políticas, controlos e proprietários específicos no Sistema de Gestão de Segurança da Informação (SGSI).”

Essa frase é a base da preparação para a aplicação regulatória. Se um regulador perguntar como foram identificadas as obrigações NIS2, a resposta não deve ser “o departamento jurídico informou-nos”. A resposta deve ser um registo documentado, ligado ao âmbito, aos riscos, aos proprietários dos controlos, aos procedimentos, à evidência retida e à revisão pela gestão.

Construa a cadeia de evidência NIS2 dentro da ISO 27001:2022

O NIS2 Article 21 exige que entidades essenciais e importantes implementem medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gerir os riscos para redes e sistemas de informação utilizados nas operações ou na prestação do serviço. As medidas devem considerar o estado da arte, normas europeias e internacionais relevantes quando aplicável, custo, exposição ao risco, dimensão, probabilidade e severidade dos incidentes, e impacto social e económico.

O Article 21(2) enumera áreas mínimas, incluindo análise de riscos e políticas de segurança dos sistemas de informação, tratamento de incidentes, continuidade de negócio, cópias de segurança, recuperação de desastre, gestão de crises, segurança da cadeia de fornecimento, aquisição e desenvolvimento seguros, tratamento de vulnerabilidades, avaliação da eficácia, higiene cibernética, formação, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, autenticação multifator ou contínua, e comunicações seguras quando apropriado.

A ISO 27001:2022 mapeia naturalmente para essa estrutura. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos e tratamento de riscos, incluindo critérios de aceitação do risco, proprietários do risco, análise de probabilidade e consequências, um plano de tratamento de riscos, comparação com os controlos do Anexo A e uma Declaração de Aplicabilidade. A cláusula 8 exige planeamento e controlo operacional, evidência de que os processos foram operados conforme planeado, controlo de alterações, controlo sobre processos fornecidos externamente, avaliações de risco recorrentes e resultados documentados do tratamento. A cláusula 9.1 exige monitorização, medição, análise e avaliação. A cláusula 9.2 exige auditoria interna. A cláusula 10.2 exige atuação sobre não conformidades e ações corretivas.

A Política de Gestão de Riscos da Clarysec Política de Gestão de Riscos - PME transforma isto numa regra operacional:

“Todos os riscos identificados devem ser registados no Registo de Riscos.”

A Política de Gestão de Riscos empresarial Política de Gestão de Riscos liga o tratamento de riscos à seleção de controlos ISO 27001:2022:

“As decisões de controlo resultantes do processo de tratamento de riscos devem refletir-se na SoA.”

Isto é importante porque a evidência NIS2 deve ser rastreável. Se uma autoridade perguntar por que existe um controlo, aponte para a obrigação, o risco, a decisão de tratamento, o proprietário do controlo, a entrada na SoA, o procedimento e a evidência. Se a autoridade perguntar por que um controlo não foi selecionado, aponte para a justificação na SoA, a aceitação do risco aprovada e a revisão pela gestão.

A melhor cadeia de evidência é deliberadamente simples. Cada obrigação tem um responsável. Cada responsável tem um controlo. Cada controlo tem evidência. Cada exceção tem aprovação. Cada constatação de auditoria tem ação corretiva.

Transforme a governação do Article 20 em evidência do conselho de administração

O NIS2 Article 20 leva a cibersegurança para a sala do conselho. Os órgãos de gestão devem aprovar as medidas de gestão de riscos de cibersegurança adotadas para o Article 21, supervisionar a implementação e podem ser responsabilizados por infrações. Os membros do órgão de gestão devem seguir formação, e as entidades são incentivadas a fornecer formação regular em cibersegurança aos colaboradores.

Um conselho de administração não pode simplesmente delegar a NIS2 na TI. A evidência deve demonstrar que a gestão compreendeu a análise de âmbito NIS2, aprovou a abordagem de gestão de riscos, reviu riscos materiais, alocou recursos, acompanhou a implementação, analisou incidentes e exercícios, e recebeu formação.

As cláusulas 5.1 a 5.3 da ISO 27001:2022 suportam esse modelo de governação ao exigir compromisso da alta direção, alinhamento dos objetivos de segurança da informação com a estratégia de negócio, integração dos requisitos do SGSI nos processos de negócio, recursos, comunicação, responsabilização e reporte do desempenho do SGSI à alta direção.

A Política de Funções e Responsabilidades de Governação da Clarysec Política de Funções e Responsabilidades de Governação define o papel de ligação de segurança como aquele que:

“Atua como ligação principal com auditores, reguladores e alta direção em matérias de segurança da informação.”

Esse papel deve ser nomeado no pacote de evidência de registo NIS2. Não deve ficar implícito. Autoridades, auditores e clientes querem saber quem coordena o contacto regulatório, quem é responsável pela comunicação de incidentes, quem mantém o registo legal, quem atualiza os contactos das autoridades e quem reporta ao conselho de administração.

Um conjunto prático de evidência de governação inclui:

• Aprovação pelo conselho de administração do quadro de gestão de riscos de cibersegurança.
• Atas da revisão pela gestão que cubram âmbito NIS2, riscos, incidentes, fornecedores e preparação.
• Registos de formação dos membros do órgão de gestão e dos colaboradores.
• Uma matriz RACI para obrigações NIS2, controlos ISO 27001:2022, comunicação de incidentes, garantia de fornecedores e comunicação regulatória.
• Evidência de que as obrigações NIS2 estão incluídas na auditoria interna e na monitorização da conformidade.
• Acompanhamento de ações corretivas para lacunas, riscos vencidos, exceções e testes falhados.

Os Articles 32 e 33 também tornam a qualidade da evidência importante ao identificarem fatores de infração grave, como violações repetidas, falta de notificação ou remediação de incidentes significativos, falta de correção de deficiências após instruções vinculativas, obstrução de auditorias ou monitorização e informação falsa ou grosseiramente inexata. Evidência fraca pode tornar-se um problema de aplicação regulatória mesmo quando existem controlos técnicos.

Prepare evidência de contacto com autoridades e de comunicação de incidentes antes das 02:00

As falhas mais dolorosas de comunicação de incidentes começam muitas vezes com uma pergunta básica: “Quem notificamos?”. Durante ransomware, falha de DNS, comprometimento de ambiente em nuvem ou exposição de dados, as equipas perdem tempo à procura do CSIRT correto, da autoridade competente, da autoridade de controlo, do supervisor financeiro, do canal de aplicação da lei, do modelo para clientes e do aprovador interno.

O NIS2 Article 23 exige a notificação, sem demora indevida, de incidentes significativos que afetem a prestação do serviço. Um incidente significativo é aquele que causou ou pode causar perturbação operacional grave ou perda financeira, ou que afetou ou pode afetar terceiros ao causar danos materiais ou imateriais consideráveis. O prazo é faseado: alerta precoce no prazo de 24 horas após a tomada de conhecimento, notificação de incidente no prazo de 72 horas, atualizações intermédias mediante pedido e relatório final no prazo de um mês após a notificação de 72 horas ou após o tratamento do incidente no caso de incidentes em curso. Quando apropriado, os destinatários do serviço também devem ser informados sobre incidentes significativos ou ameaças cibernéticas significativas e medidas de proteção.

O Zenith Blueprint, na fase Controlos em Ação, Passo 22, trata o contacto com autoridades como preparação, não como pânico:

O princípio aqui é simples: se a sua organização fosse alvo de um ciberataque, estivesse envolvida numa violação de dados ou sob investigação, quem faria a chamada para as autoridades? Como saberia o que dizer? Em que condições esse contacto seria iniciado? Estas perguntas devem ser respondidas com antecedência, não depois do facto.

O Zenith Controls: guia de conformidade cruzada da Clarysec Zenith Controls cobre o controlo 5.5 da ISO/IEC 27002:2022, Contacto com autoridades. Classifica o controlo como preventivo e corretivo, associado à confidencialidade, integridade e disponibilidade, e ligado aos conceitos identificar, proteger, responder e recuperar. Também liga o controlo 5.5 aos controlos ISO/IEC 27002:2022 5.24 Planeamento e preparação da gestão de incidentes de segurança da informação, 6.8 Comunicação de eventos de segurança da informação, 5.7 Informações sobre ameaças, 5.6 Contacto com grupos de interesse especial e 5.26 Resposta a incidentes de segurança da informação.

Numa perspetiva de conformidade cruzada, o Zenith Controls mapeia o contacto com autoridades para o NIS2 Article 23, notificação de violações ao abrigo do RGPD, comunicação de incidentes DORA, NIST SP 800-53 IR-6 Comunicação de Incidentes e práticas de escalonamento externo do COBIT 2019. Um único registo de contactos das autoridades pode servir várias obrigações se for corretamente concebido.

A Política de Resposta a Incidentes da Clarysec Política de Resposta a Incidentes - PME torna explícita a triagem jurídica:

“Quando estejam envolvidos dados de clientes, o Diretor-Geral deve avaliar as obrigações legais de notificação com base na aplicabilidade do RGPD, NIS2 ou DORA.”

Um pacote robusto de evidência de contactos com autoridades deve incluir:

• Dados de contacto da autoridade competente e do CSIRT por Estado-Membro e serviço.
• Contactos de autoridades de controlo para notificação de violação de dados pessoais ao abrigo do RGPD.
• Contactos de supervisores financeiros se o DORA se aplicar.
• Vias de contacto com autoridades policiais e cibercrime.
• Comunicadores internos autorizados e substitutos.
• Limiares de incidentes para NIS2, RGPD, DORA, contratos com clientes e seguro cibernético.
• Modelos de reporte para 24 horas, 72 horas, atualização intermédia e relatório final de um mês.
• Registos de exercícios tabletop que testem a notificação externa.
• Registos de notificações anteriores, decisões de não notificar e fundamentação jurídica.

Mapeie o NIS2 Article 21 para controlos ISO 27001 e evidência de políticas

Um certificado, por si só, não responde à pergunta de um regulador. Um mapeamento de controlos responde. A tabela seguinte oferece às equipas de segurança e conformidade uma ponte prática entre as áreas do NIS2 Article 21, os controlos ISO/IEC 27002:2022, as âncoras de políticas da Clarysec e a evidência.

O Zenith Controls da Clarysec também cobre o controlo 5.31 da ISO/IEC 27002:2022, Requisitos legais, estatutários, regulamentares e contratuais, como controlo preventivo com impacto em confidencialidade, integridade e disponibilidade. Liga o 5.31 à privacidade e proteção de informações pessoais identificáveis (PII), retenção de registos, revisão independente e conformidade com políticas internas. Também mapeia o 5.31 para responsabilização ao abrigo do RGPD, conformidade da cadeia de fornecimento NIS2, gestão do risco das TIC DORA, governação NIST CSF, controlos de programa NIST SP 800-53 e supervisão de conformidade externa COBIT 2019.

“O controlo 5.31 assegura que todos os requisitos legais, regulamentares, estatutários e contratuais relevantes relacionados com segurança da informação são identificados, documentados e geridos continuamente.”

É exatamente isto que uma autoridade nacional quer ver após o registo: não apenas que a NIS2 está listada, mas que a organização tem um mecanismo vivo para identificar, mapear, implementar, monitorizar e atualizar obrigações.

Não separe a NIS2 do DORA, do RGPD, dos fornecedores e da nuvem

A evidência NIS2 raramente existe isoladamente.

O NIS2 Article 21(2)(d) exige segurança da cadeia de fornecimento, incluindo aspetos relacionados com segurança nas relações com fornecedores e prestadores de serviços. O Article 21(3) exige que as decisões de risco de fornecedores considerem vulnerabilidades, qualidade geral dos produtos, práticas de cibersegurança, procedimentos de desenvolvimento seguro e avaliações de risco da cadeia de fornecimento realizadas ao nível da União.

O Anexo A da ISO 27001:2022 fornece a ponte operacional através de A.5.19 a A.5.23. Para organizações SaaS e em nuvem, estes controlos determinam frequentemente se a evidência de registo é superficial ou defensável.

O DORA torna mais exigente o quadro de fornecedores para entidades financeiras. Os Articles 28 a 30 exigem gestão de risco de terceiros de TIC, um registo de contratos de serviços TIC, distinção de serviços que suportam funções críticas ou importantes, avaliação de riscos pré-contratual, diligência prévia, requisitos contratuais de segurança, direitos de auditoria e inspeção, direitos de cessação, estratégias de saída testadas, avaliação de subcontratação, transparência da localização dos dados, assistência em incidentes, cooperação com autoridades e disposições de transição. Se um prestador SaaS servir clientes regulados pelo DORA, os seus contratos e pacote de garantia podem ser examinados mesmo que não seja ele próprio a entidade financeira.

A Política de Segurança de Terceiros e Fornecedores - PME da Clarysec Política de Segurança de Terceiros e Fornecedores - PME deve, por isso, estar ligada ao pacote de evidência NIS2. A preparação de fornecedores deve incluir:

• Inventário de fornecedores e classificação de criticidade.
• Diligência prévia de fornecedores e avaliações de riscos.
• Cláusulas contratuais para segurança, assistência em incidentes, direitos de auditoria, localização dos dados, subcontratação e saída.
• Matrizes de responsabilidade partilhada em nuvem.
• Registos de monitorização de fornecedores críticos.
• Testes de saída e recuperação para serviços críticos.
• Procedimentos de notificação e escalonamento de incidentes de fornecedores.

O RGPD também deve ser integrado. Um incidente significativo NIS2 também pode ser uma violação de dados pessoais se dados de clientes, colaboradores ou utilizadores forem comprometidos. O RGPD exige que os responsáveis pelo tratamento demonstrem responsabilização e, quando os limiares de notificação são atingidos, notifiquem a autoridade de controlo no prazo de 72 horas após tomarem conhecimento de uma violação de dados pessoais. O seu fluxo de trabalho de resposta a incidentes deve avaliar em paralelo obrigações NIS2, RGPD, DORA, contratuais e perante clientes.

Monte um pacote de evidência NIS2 numa semana

Um prestador SaaS, MSP, MSSP, prestador de serviços em nuvem ou empresa de infraestrutura digital consegue fazer progressos substanciais numa semana focada.

Dia 1, classifique a entidade e os serviços. Utilize a Declaração do Âmbito do SGSI e o registo de partes interessadas. Acrescente uma nota de âmbito NIS2 que identifique categorias do Anexo I ou do Anexo II, serviços na UE, Estados-Membros, clientes, dependências, pressupostos de dimensão e se DORA ou regras setoriais se aplicam. Registe a incerteza de classificação como risco se a interpretação jurídica não for definitiva.

Dia 2, atualize o registo de obrigações legais e regulamentares. Acrescente NIS2 Articles 20, 21 e 23, requisitos de registo ao abrigo da lei nacional, deveres de violação do RGPD, obrigações DORA quando relevantes e requisitos contratuais essenciais de notificação. Mapeie cada obrigação para uma política, responsável, controlo, fonte de evidência e frequência de revisão.

Dia 3, atualize a avaliação de riscos e o tratamento. Inclua impacto legal, regulamentar, operacional, de fornecedores, financeiro, reputacional e social nos critérios de risco. Acrescente riscos como falta de registo, classificação incorreta da entidade, incumprimento do alerta precoce de 24 horas, indisponibilidade de contactos das autoridades, indisponibilidade de fornecedor que afete serviços críticos, supervisão insuficiente pelo conselho de administração e incapacidade de evidenciar a eficácia dos controlos.

Dia 4, atualize a SoA. Confirme os controlos relevantes para NIS2, incluindo A.5.5 contacto com autoridades, A.5.19 a A.5.23 controlos de fornecedores e nuvem, A.5.24 a A.5.28 controlos de incidentes, A.5.29 segurança durante perturbações, A.5.30 preparação das TIC para a continuidade de negócio, A.5.31 requisitos legais, A.5.34 privacidade, A.8.8 gestão de vulnerabilidades, A.8.13 cópias de segurança, A.8.15 registo de eventos, A.8.16 atividades de monitorização, A.8.24 criptografia e controlos de desenvolvimento seguro A.8.25 a A.8.32.

Dia 5, teste a comunicação de incidentes. Execute um exercício tabletop: uma configuração incorreta na nuvem expõe dados de clientes e interrompe o serviço em dois Estados-Membros. Inicie o relógio. A equipa consegue classificar o evento, avaliar limiares do RGPD, NIS2, DORA, contratuais e de clientes, preparar um alerta precoce de 24 horas, redigir uma notificação de 72 horas, preservar evidência e atribuir análise de causa raiz?

Dia 6, reúna evidência. Crie uma pasta preparada para o regulador com a nota de âmbito, registo legal, registo de riscos, SoA, lista de contactos das autoridades, playbook de incidentes, registo centralizado de fornecedores, atas do conselho de administração, registos de formação, registos de eventos, relatórios de monitorização, testes de cópias de segurança, relatórios de vulnerabilidades, âmbito da auditoria interna e registo de ações corretivas.

Dia 7, revisão pela gestão. Apresente o pacote de preparação à liderança. Registe aprovações, riscos residuais, ações em aberto, prazos, recursos e responsabilização dos responsáveis. Se o registo estiver vencido, anexe o índice de evidência ao registo da decisão de registo.

A Política de Auditoria e Monitorização da Conformidade para PME da Clarysec Política de Auditoria e Monitorização da Conformidade - PME antecipa esta necessidade:

“A evidência deve estar alinhada com as obrigações NIS2 quando a organização for designada como entidade importante ou se enquadrar de outra forma no âmbito da lei nacional.”

A Política de Auditoria e Monitorização da Conformidade empresarial Política de Auditoria e Monitorização da Conformidade declara o objetivo:

“Gerar evidência defensável e uma trilha de auditoria em apoio a pedidos de esclarecimento regulamentares, processos legais ou pedidos de garantia por parte de clientes.”

Esse é o objetivo: evidência defensável antes de o pedido chegar.

Prepare-se para diferentes perspetivas de auditoria

Um auditor de certificação, uma autoridade nacional, um auditor de cliente, um auditor de privacidade e uma equipa de garantia de fornecedores não farão perguntas idênticas. Um pacote robusto de evidência NIS2 funciona para todos eles.

Para o controlo 5.5 da ISO/IEC 27002:2022, os auditores esperam normalmente contactos de autoridades documentados, responsabilidades atribuídas, manutenção dos contactos, playbooks de resposta a incidentes e clareza baseada em cenários. Uma simples pergunta de auditoria pode revelar maturidade: “Em caso de ransomware, quem contacta as autoridades policiais ou o CSIRT nacional?”. Se a resposta depender de alguém se lembrar de um nome, o controlo não está pronto.

A Política de Registo de Eventos e Monitorização da Clarysec Política de Registo de Eventos e Monitorização - PME reforça a expectativa de evidência:

“Os registos de eventos devem estar disponíveis e ser inteligíveis para auditores externos ou reguladores mediante pedido.”

A Política de Segurança da Informação da Clarysec Política de Segurança da Informação estabelece a norma empresarial mais ampla:

“Todos os controlos implementados devem ser auditáveis, suportados por procedimentos documentados e por evidência retida da sua operação.”

Este é o teste de auditoria numa frase. Se um controlo não puder ser evidenciado, terá pouco peso quando uma autoridade competente solicitar prova.

Lista de verificação final de evidência de registo NIS2

Utilize esta lista de verificação antes do registo ou antes de responder a um pedido de uma autoridade nacional.

• Documente a análise de âmbito NIS2, incluindo a fundamentação do Anexo I ou do Anexo II, descrições de serviços, pressupostos de dimensão, presença em Estados-Membros e classificação da entidade.
• Identifique se o DORA se aplica diretamente ou indiretamente através de clientes do setor financeiro e contratos de serviços TIC.
• Atualize o âmbito do SGSI para incluir serviços relevantes, dependências, processos externalizados e interfaces regulamentares.
• Acrescente NIS2, RGPD, DORA, regras setoriais e requisitos contratuais ao registo de obrigações legais e regulamentares.
• Mapeie cada obrigação para políticas, controlos, responsáveis, evidência, frequência de revisão e reporte à gestão.
• Confirme a aprovação e supervisão pelo conselho de administração das medidas de gestão de riscos de cibersegurança.
• Mantenha registos de formação em cibersegurança da gestão e dos colaboradores.
• Atualize os critérios de risco para incluir impacto regulatório, interrupção de serviços, dano a clientes, impacto transfronteiriço e dependência de fornecedores.
• Registe riscos relacionados com NIS2 no registo de riscos e ligue-os a planos de tratamento.
• Atualize a SoA com controlos do Anexo A relevantes para NIS2 e o estado de implementação.
• Mantenha listas de contactos das autoridades e procedimentos de notificação para CSIRT, autoridades competentes, autoridades de controlo, supervisores financeiros e autoridades policiais.
• Teste o fluxo de trabalho de alerta precoce de 24 horas, notificação de 72 horas, atualização intermédia e relatório final de um mês.
• Mantenha evidência de fornecedores e nuvem, incluindo diligência prévia, contratos, direitos de auditoria, monitorização, subcontratação e planos de saída.
• Evidencie a eficácia dos controlos através de registos de eventos, métricas, auditorias, painéis de gestão, resultados dos testes e ações corretivas.
• Prepare um índice de evidência para que qualquer pedido de regulador, cliente ou auditor possa ser respondido rapidamente.

O próximo passo da Clarysec

O registo de entidade NIS2 não é a linha de chegada. É o ponto em que a sua organização passa a estar visível para a supervisão nacional de cibersegurança. A pergunta certa não é “Conseguimos registar-nos?”. A pergunta certa é “Se a autoridade pedir evidência após o registo, conseguimos produzir uma narrativa ISO 27001:2022 coerente em horas, não em semanas?”.

A Clarysec ajuda as organizações a construir essa narrativa através do Zenith Blueprint Zenith Blueprint, dos Zenith Controls Zenith Controls e de conjuntos práticos de políticas ISO 27001:2022 que ligam obrigações legais, tratamento de riscos, comunicação de incidentes, segurança de fornecedores, registo de eventos, monitorização, evidência de auditoria e responsabilização da gestão.

Execute uma revisão de lacunas de evidência NIS2 face ao seu SGSI atual. Comece pela nota de âmbito, registo legal, registo de riscos, SoA, lista de contactos das autoridades, fluxo de comunicação de incidentes, registo centralizado de fornecedores e pasta de evidência de auditoria. Se esses artefactos estiverem incompletos ou desligados entre si, a Clarysec pode ajudá-lo a transformá-los num pacote de evidência preparado para o regulador antes que a sua autoridade nacional o solicite.