Mapeamento de evidência NIS2 para a ISO 27001:2022 em 2026

O problema da NIS2 em 2026 não é a sensibilização, é a prova

É segunda-feira de manhã, 08:35. Maria, a CISO recentemente nomeada de um prestador B2B de serviços em nuvem e serviços geridos em rápido crescimento, entra na reunião trimestral de risco do órgão de administração com uma extensa avaliação de lacunas NIS2 aberta no portátil. O primeiro slide parece tranquilizador. Existem políticas. Existe uma avaliação de riscos. A resposta a incidentes está documentada. Os fornecedores estão listados. Os varrimentos de vulnerabilidades são executados mensalmente.

Então, o presidente faz a pergunta que muda a reunião:

“Conseguimos provar que estas medidas funcionaram no último trimestre e demonstrar que controlos, responsáveis e registos ISO 27001:2022 suportam cada obrigação NIS2?”

A sala fica em silêncio.

O departamento jurídico sabe que a empresa se enquadra no âmbito da NIS2 porque presta serviços TIC geridos e serviços em nuvem a clientes da UE. A função de conformidade sabe que o artigo 21 exige medidas técnicas, operacionais e organizacionais de gestão de riscos de cibersegurança. As operações sabem que a equipa aplica correções aos sistemas, revê fornecedores e monitoriza registos de eventos. Mas a evidência está dispersa por sistemas de tickets, exportações do SIEM, pastas de políticas, folhas de cálculo, consolas de nuvem, portais de fornecedores e notas de reuniões.

Ninguém consegue demonstrar rapidamente uma cadeia defensável desde o artigo 21 da NIS2 até ao âmbito, risco, controlo, política, responsável, procedimento, registo operacional e constatação de auditoria da ISO 27001:2022.

Esse é o verdadeiro desafio de 2026.

Muitas organizações já não perguntam: “Estamos no âmbito da NIS2?” Estão a colocar uma pergunta mais difícil: “Conseguimos provar que as nossas medidas técnicas NIS2 funcionam efetivamente?” A resposta não pode ser uma folha de cálculo de mapeamento pontual. Tem de ser um modelo operacional vivo dentro do Sistema de Gestão de Segurança da Informação, no qual as obrigações legais são traduzidas em riscos, políticas, controlos, responsáveis, evidência e melhoria contínua.

O modelo da Clarysec usa a ISO/IEC 27001:2022 como espinha dorsal do sistema de gestão, o artigo 21 da NIS2 como conjunto de obrigações regulamentares, as cláusulas das políticas como referencial operacional, Zenith Blueprint: o roteiro de 30 passos do auditor como percurso de implementação e Zenith Controls: o guia de conformidade cruzada como mapa de conformidade cruzada para ISO 27001:2022, NIS2, DORA, RGPD da UE, NIST CSF e garantia ao estilo COBIT.

Comece pelo âmbito, porque a evidência NIS2 começa antes dos controlos

Uma falha comum na NIS2 é avançar diretamente para MFA, registo de eventos, resposta a incidentes e gestão de vulnerabilidades antes de confirmar o âmbito da entidade, o âmbito dos serviços e o âmbito jurisdicional.

A NIS2 aplica-se a entidades públicas e privadas abrangidas em setores regulados que cumpram critérios de dimensão e atividade, sendo certos tipos de entidades abrangidos independentemente da dimensão. As categorias digitais e de TIC relevantes incluem prestadores de serviços de computação em nuvem, prestadores de serviços de centros de dados, prestadores de redes de distribuição de conteúdos, prestadores de serviços de confiança, prestadores de serviços públicos de comunicações eletrónicas, prestadores de serviços geridos, prestadores de serviços geridos de segurança, mercados em linha, motores de pesquisa em linha e plataformas de redes sociais.

Para prestadores de serviços em nuvem, plataformas SaaS, MSPs, MSSPs e prestadores de infraestrutura digital, este trabalho de definição de âmbito não é teórico. O artigo 3 exige que os Estados-Membros distingam entidades essenciais e importantes. O artigo 27 exige que a ENISA mantenha um registo de vários prestadores digitais e de TIC, incluindo prestadores de serviços DNS, registos de nomes TLD, prestadores de serviços de registo de nomes de domínio, prestadores de serviços de computação em nuvem, prestadores de serviços de centros de dados, prestadores de redes de distribuição de conteúdos, prestadores de serviços geridos, prestadores de serviços geridos de segurança, mercados em linha, motores de pesquisa em linha e plataformas de redes sociais.

A ISO 27001:2022 fornece a estrutura adequada. As cláusulas 4.1 a 4.4 exigem que a organização compreenda as questões externas e internas, as partes interessadas, os requisitos, as interfaces e as dependências, e que depois defina o âmbito do SGSI. A NIS2 deve ser captada aqui, não deixada num memorando jurídico.

Um registo prático de definição de âmbito NIS2 deve incluir:

• Análise da entidade jurídica e do estabelecimento na UE
• Setor e categoria de serviço NIS2
• Estatuto de entidade essencial ou importante, quando confirmado por legislação nacional ou designação de autoridade
• Relevância para o registo da ENISA, quando aplicável
• Serviços críticos prestados a clientes
• Redes e sistemas de informação que suportam esses serviços
• Dependências de fornecedores de nuvem, centros de dados, telecomunicações, monitorização de segurança, identidade e software
• Ligações à DORA, ao RGPD da UE, a contratos com clientes e a obrigações setoriais específicas
• Repositórios de evidência, responsáveis pelos sistemas e cadência de revisão

É também aqui que a DORA deve ser corretamente separada. A NIS2 reconhece que, quando um ato jurídico setorial da UE impõe obrigações equivalentes de gestão de riscos de cibersegurança ou de notificação de incidentes, esse regime setorial se aplica em substituição das disposições correspondentes da NIS2. Para entidades financeiras abrangidas, a DORA é geralmente o regime operacional de cibersegurança e de reporte de incidentes TIC. A DORA aplica-se desde 17 de janeiro de 2025 e abrange gestão do risco das TIC, reporte de incidentes, testes de resiliência operacional digital, risco de terceiros TIC e supervisão de prestadores terceiros críticos de serviços TIC.

Um grupo fintech pode, por isso, ter diferentes tratamentos de conformidade dentro da mesma estrutura societária. A entidade de pagamentos pode estar principalmente sujeita à DORA. A subsidiária MSP pode estar diretamente sujeita à NIS2. Uma plataforma em nuvem partilhada pode suportar ambas. A resposta madura não é duplicar controlos. É ter um único modelo de evidência do SGSI que sirva várias perspetivas regulamentares.

ISO 27001:2022 como sistema operacional de conformidade NIS2

O artigo 21 da NIS2 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gerir os riscos para as redes e sistemas de informação e para prevenir ou minimizar o impacto dos incidentes nos destinatários dos serviços e noutros serviços.

A ISO 27001:2022 é adequada para operacionalizar esse requisito porque impõe três disciplinas.

Primeiro, governação. As cláusulas 5.1 a 5.3 exigem o compromisso da alta direção, alinhamento com a direção estratégica, disponibilização de recursos, comunicação, atribuição de responsabilidades e uma política de segurança da informação documentada. Isto alinha-se diretamente com o artigo 20 da NIS2, que exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação.

Segundo, tratamento de riscos. As cláusulas 6.1.1 a 6.1.3 exigem um processo repetível de avaliação de riscos, responsáveis pelos riscos, avaliação do risco, opções de tratamento, seleção de controlos, uma Declaração de Aplicabilidade, um plano de tratamento de riscos e aprovação do risco residual.

Terceiro, controlo operacional. A cláusula 8.1 exige que a organização planeie, implemente e controle processos do SGSI, mantenha informação documentada, controle alterações e gira processos, produtos e serviços fornecidos externamente que sejam relevantes para o SGSI.

Isto transforma a NIS2 de uma checklist jurídica num modelo operacional de controlos.

Cada linha precisa de um responsável, uma fonte de registos e um método de amostragem. Se estes elementos estiverem ausentes, a organização tem uma intenção de controlo, não um controlo.

A política é onde a NIS2 se torna comportamento operacional

As políticas são frequentemente tratadas como modelos. Para a NIS2, isso é perigoso. Um regulador ou auditor não ficará convencido com uma pasta de políticas se as políticas não atribuírem responsabilidade, não definirem registos, não se ligarem aos riscos e não produzirem evidência.

A política empresarial Política de Conformidade Legal e Regulamentar estabelece a base na cláusula 6.2.1:

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

Essa cláusula é a ponte entre a NIS2 e a ISO 27001:2022. O artigo 21 da NIS2 não é simplesmente listado como requisito externo. É decomposto em obrigações de políticas, mapeado para controlos, atribuído a responsáveis e testado por meio de evidência.

Para organizações mais pequenas, a Política de Conformidade Legal e Regulamentar para PME mantém o mesmo conceito de forma leve. A cláusula 5.1.1 exige:

O Diretor-Geral (GM) deve manter um Registo de Conformidade simples e estruturado que liste:

A formulação é deliberadamente prática. As PME não precisam de uma implementação GRC complexa para começar. Precisam de um Registo de Conformidade que capte obrigação, aplicabilidade, responsável, política, evidência e cadência de revisão.

O tratamento de riscos converte então a obrigação em ação. A política empresarial Política de Gestão de Riscos, cláusula 6.4.2, estabelece:

O Responsável pelo Risco deve assegurar que os tratamentos são realistas, têm prazo definido e estão mapeados para os controlos do Anexo A da ISO/IEC 27001.

Para PME, a Política de Gestão de Riscos - PME, cláusula 5.1.2, define o registo de risco mínimo viável:

Cada entrada de risco deve incluir: descrição, probabilidade, impacto, pontuação, responsável e plano de tratamento.

Estas cláusulas são importantes porque a NIS2 é explicitamente baseada no risco e proporcionada. O artigo 21 espera que as medidas reflitam o estado da arte, normas relevantes, custo de implementação, exposição ao risco, dimensão, probabilidade e severidade de incidentes, incluindo impacto social e económico. Um Registo de Riscos sem responsáveis e planos de tratamento não consegue comprovar proporcionalidade.

A política empresarial Política de Segurança da Informação completa o princípio da evidência na cláusula 6.6.1:

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

Essa é a diferença entre ter um programa NIS2 e ter um programa de evidência NIS2.

O percurso da Clarysec do mapeamento à operação

O Zenith Blueprint é valioso porque reflete a forma como os auditores pensam. Eles não perguntam apenas se um controlo existe. Perguntam por que razão foi selecionado, onde está documentado, como opera, quem é o responsável, que evidência o comprova e como a organização o melhora.

Na fase de Gestão de Riscos, o passo 13 orienta as equipas a acrescentarem rastreabilidade entre riscos, controlos e cláusulas:

✓ Mapear controlos para riscos: no plano de tratamento do seu Registo de Riscos, listou determinados controlos para cada risco. Pode acrescentar uma coluna “Referência do controlo do Anexo A” a cada risco e listar os números dos controlos.

Para a NIS2, isto significa que o Registo de Riscos e a Declaração de Aplicabilidade devem mostrar por que razão controlos como 8.8 Gestão de vulnerabilidades técnicas, 5.19 Segurança da informação nas relações com fornecedores e 5.24 Planeamento e preparação da gestão de incidentes são aplicáveis.

O passo 14 do Zenith Blueprint torna explícito o mapeamento regulamentar:

Para cada regulamento, se aplicável, pode criar uma tabela simples de mapeamento (que pode ser um anexo a um relatório) que liste os principais requisitos de segurança do regulamento e os controlos/políticas correspondentes no seu SGSI.

Isto evita a fragmentação. A segurança de dados pessoais do RGPD da UE, a comunicação de incidentes NIS2, os testes de resiliência TIC da DORA e os compromissos de segurança assumidos perante clientes podem depender todos da mesma evidência: revisões de acessos, remediação de vulnerabilidades, registos de eventos, testes de cópias de segurança, revisões de fornecedores e relatórios de incidente.

O passo 19 passa da conceção para a operação:

Ligue cada um destes documentos ao controlo adequado na sua SoA ou no manual do SGSI. Estes servirão como prova de implementação e referência interna.

O conjunto documental do passo 19 inclui segurança de endpoints, gestão de acessos, autenticação, configurações de referência seguras, registo de eventos e monitorização, gestão de correções, gestão de vulnerabilidades, planeamento de capacidade e reporte de operações de TI. Estes são exatamente os documentos operacionais necessários para tornar auditáveis as medidas técnicas NIS2.

O passo 26 explica como a evidência de auditoria deve ser recolhida:

À medida que recolhe evidência, registe as suas constatações. Assinale onde os elementos cumprem o requisito (constatações positivas) e onde não cumprem (potenciais não conformidades ou observações).

Para a NIS2, isto significa amostrar evidência antes de um regulador, avaliador de cliente ou auditor de certificação a solicitar.

O papel de conformidade cruzada do Zenith Controls

O Zenith Controls não é um quadro de controlos separado. É o guia de conformidade cruzada da Clarysec para mapear controlos ISO/IEC 27001:2022 e ISO/IEC 27002:2022 para controlos relacionados, expectativas de auditoria e referenciais externos. Ajuda as equipas a compreender como um único controlo ISO 27001:2022 pode suportar NIS2, DORA, RGPD da UE, NIST CSF 2.0 e garantia ao estilo COBIT.

Três controlos ISO 27001:2022 são especialmente importantes para o mapeamento de evidência NIS2.

O controlo 5.1 Políticas de segurança da informação é o ponto de entrada porque o artigo 21 da NIS2 inclui análise de riscos e políticas de segurança dos sistemas de informação. Se uma medida técnica NIS2 não estiver refletida numa política, é difícil governá-la e difícil auditá-la de forma consistente.

O controlo 5.36 Conformidade com políticas, regras e normas de segurança da informação é a verificação da realidade. Liga os requisitos das políticas à conformidade efetiva com regras internas, normas e obrigações externas. Em termos NIS2, é aqui que uma organização pergunta se está a fazer o que o seu mapeamento do artigo 21 diz que faz.

O controlo 8.8 Gestão de vulnerabilidades técnicas é uma das áreas de teste mais difíceis em 2026. A gestão de vulnerabilidades é diretamente relevante para aquisição segura, desenvolvimento, manutenção, tratamento e divulgação de vulnerabilidades. Também suporta testes e remediação DORA, responsabilização pela segurança no RGPD da UE, resultados Identify e Protect do NIST CSF e amostragem de auditoria ISO 27001.

Normas de suporte podem melhorar a conceção sem exigir certificações adicionais. A ISO/IEC 27002:2022 fornece orientações de implementação para controlos do Anexo A. A ISO/IEC 27005 suporta a gestão de riscos de segurança da informação. A ISO/IEC 27017 suporta a segurança em nuvem. A ISO/IEC 27018 suporta a proteção de informações pessoais identificáveis em cenários de subcontratante de nuvem pública. A ISO 22301 suporta a continuidade do negócio. A ISO/IEC 27035 suporta a gestão de incidentes. A ISO/IEC 27036 suporta a segurança das relações com fornecedores.

O objetivo não é ter mais normas por si só. O objetivo é melhorar a conceção da evidência.

Exemplo prático: criar um pacote de evidência NIS2 para vulnerabilidades

Considere a plataforma SaaS da Maria. Presta serviços a clientes industriais da UE e depende de serviços em nuvem, componentes open source, pipelines de CI/CD e monitorização gerida. O relatório de lacunas afirma “gestão de vulnerabilidades implementada”, mas a evidência está dispersa por scanners, Jira, GitHub, ferramentas de configuração de nuvem e tickets de alteração.

Um pacote de evidência preparado para a NIS2 pode ser construído num sprint focado.

Passo 1: Definir o cenário de risco

Risco: uma vulnerabilidade explorável numa aplicação exposta à Internet, numa dependência ou num componente de nuvem causa interrupção de serviços, acesso não autorizado ou exposição de dados de clientes.

O Registo de Riscos deve incluir descrição, probabilidade, impacto, pontuação, responsável e plano de tratamento. O plano de tratamento deve referenciar o controlo 8.8 Gestão de vulnerabilidades técnicas da ISO 27001:2022, bem como controlos relacionados para inventário de ativos, desenvolvimento seguro, registo de eventos, controlo de acesso, gestão de fornecedores e resposta a incidentes.

Passo 2: Mapear o risco para o artigo 21 da NIS2

O risco suporta os requisitos do artigo 21 relativos a aquisição, desenvolvimento e manutenção seguros, tratamento e divulgação de vulnerabilidades, análise de riscos, tratamento de incidentes, segurança da cadeia de fornecimento e avaliação da eficácia dos controlos.

Passo 3: Ancorar as regras operacionais na política

Use um procedimento de gestão de vulnerabilidades, uma norma de desenvolvimento seguro, requisitos de gestão de correções, uma política de testes de segurança e regras de evidência de auditoria.

A política empresarial Política de Testes de Segurança e Red Teaming, cláusula 6.1, estabelece:

Tipos de testes: o programa de testes de segurança deve incluir, no mínimo: (a) varrimento de vulnerabilidades, consistindo em varrimentos automatizados semanais ou mensais de redes e aplicações para identificar vulnerabilidades conhecidas; (b) testes de intrusão, consistindo em testes manuais aprofundados de sistemas ou aplicações específicos por testadores qualificados para identificar fraquezas complexas; e (c) exercícios de red teaming, consistindo em simulações baseadas em cenários de ataques reais, incluindo engenharia social e outras táticas, para testar as capacidades de deteção e resposta da organização como um todo.

Essa cláusula cria uma referência de testes defensável. Também se alinha com a expectativa da DORA de testes recorrentes e baseados no risco de resiliência operacional digital para entidades financeiras abrangidas.

Passo 4: Definir metadados da evidência

A Política de Auditoria e Monitorização da Conformidade - PME, cláusula 6.2.3, estabelece:

Os metadados (por exemplo, quem os recolheu, quando e a partir de que sistema) devem ser documentados.

Para evidência de vulnerabilidades, o pacote deve captar:

• Nome e configuração do scanner
• Data e hora do varrimento
• Âmbito de ativos e exclusões
• Constatações críticas e elevadas
• Número do ticket e responsável
• Decisão de aplicação de correção ou mitigação
• Decisão de aceitação do risco, quando aplicável
• Data de remediação
• Varrimento de validação
• Ligação ao registo de alteração
• Responsável pela exceção e data de expiração

Passo 5: Acrescentar evidência de registo de eventos

A Política de Registo de Eventos e Monitorização - PME, cláusula 5.4.4, inclui registos de sistema como:

Registos de sistema: alterações de configuração, ações administrativas, instalações de software, atividade de aplicação de correções

Um ticket de correção, por si só, pode não provar que a alteração ocorreu. Registos de configuração, ações administrativas e registos de instalação de software reforçam a cadeia de evidência.

Passo 6: Executar uma auditoria por amostragem

Selecione cinco vulnerabilidades críticas ou elevadas do trimestre anterior. Para cada item, verifique se o ativo constava do inventário, se o scanner detetou a constatação, se foi aberto um ticket dentro do SLA, se foi atribuído um responsável, se a remediação correspondeu à severidade e à explorabilidade, se os registos de eventos demonstram a alteração, se a validação confirma o encerramento e se qualquer exceção tem aprovação do responsável pelo risco com data de expiração.

Esse sprint produz um pacote de evidência de vulnerabilidades preparado para a NIS2 e uma amostra de auditoria interna ISO 27001:2022.

A segurança de fornecedores é governação do ecossistema

O artigo 21 da NIS2 exige segurança da cadeia de fornecimento, incluindo aspetos de segurança relativos às relações com fornecedores diretos e prestadores de serviços. Também espera que as organizações considerem vulnerabilidades dos fornecedores, qualidade dos produtos, práticas de cibersegurança dos fornecedores e práticas de desenvolvimento seguro.

Foi aqui que a primeira versão do relatório de lacunas da Maria foi mais fraca. Listava fornecedores, mas não comprovava diligência prévia, cláusulas contratuais de segurança, monitorização ou preparação para saída.

A Política de Segurança de Terceiros e Fornecedores fornece a âncora da política. A implementação relacionada pode ser suportada pela Política de Desenvolvimento Seguro, Política de Sensibilização e Formação em Segurança da Informação, Política de Gestão de Vulnerabilidades e Correções, Política de Controlos Criptográficos, Política de Controlo de Acesso e Política de Trabalho Remoto.

Um único registo de evidência de fornecedores pode suportar NIS2, DORA e ISO 27001:2022.

Esta tabela evita questionários duplicados, registos duplicados e responsabilidade de controlos contraditória.

Um único fluxo de trabalho de incidentes para NIS2, DORA e RGPD da UE

O artigo 23 da NIS2 exige que incidentes significativos sejam notificados sem demora injustificada. Estabelece uma cronologia faseada: alerta precoce no prazo de 24 horas a contar da tomada de conhecimento, notificação de incidente no prazo de 72 horas com avaliação inicial de severidade ou impacto e indicadores de compromisso disponíveis, atualizações intermédias se solicitadas e relatório final no máximo um mês após a notificação do incidente.

A DORA tem um ciclo de vida semelhante para entidades financeiras: deteção, classificação, registo, avaliação de severidade, escalonamento, comunicação a clientes, reporte à autoridade, análise de causa raiz e remediação. O RGPD da UE acrescenta a análise de violação de dados pessoais, incluindo papéis de responsável pelo tratamento e subcontratante, impacto nos titulares dos dados e o prazo de notificação de 72 horas quando aplicável.

A conceção correta não é ter três processos de incidentes. É ter um único fluxo de trabalho de incidentes com ramos de decisão regulamentares.

A Política de Resposta a Incidentes - PME, cláusula 5.4.1, estabelece:

Todas as investigações de incidentes, constatações e ações corretivas devem ser registadas num Registo de Incidentes mantido pelo Diretor-Geral.

Um Registo de Incidentes robusto deve incluir:

A ligação ao RGPD da UE não deve ser subestimada. As autoridades competentes NIS2 podem informar as autoridades de controlo do RGPD da UE quando falhas de gestão de riscos de cibersegurança ou de reporte possam implicar uma violação de dados pessoais. O SGSI deve, por isso, integrar a avaliação de privacidade na triagem de incidentes, e não tratá-la como uma reflexão posterior.

Como auditores e reguladores irão testar a sua evidência NIS2

Uma organização preparada para 2026 deve esperar que o mesmo controlo seja testado por diferentes perspetivas.

Um auditor ISO 27001:2022 começará pelo SGSI. Perguntará se as obrigações NIS2 estão identificadas como requisitos das partes interessadas, se o âmbito do SGSI cobre os serviços e dependências relevantes, se os riscos são avaliados e tratados, se a Declaração de Aplicabilidade justifica os controlos aplicáveis e se os registos comprovam a operação.

Uma autoridade competente NIS2 focar-se-á nos resultados jurídicos. Poderá perguntar se todas as medidas do artigo 21 estão tratadas, se os controlos são adequados e proporcionados, se a gestão aprovou e supervisiona as medidas e se a comunicação de incidentes consegue cumprir os prazos exigidos.

Um supervisor DORA, para entidades financeiras abrangidas, testará a gestão do risco das TIC, a classificação de incidentes, os testes de resiliência, o risco de terceiros, os acordos contratuais, o risco de concentração e as estratégias de saída.

Um revisor do RGPD da UE testará se as medidas técnicas e organizativas protegem dados pessoais, se a avaliação de violações está integrada no tratamento de incidentes, se os papéis de responsável pelo tratamento e subcontratante são claros e se existem registos de responsabilização.

Um avaliador ao estilo NIST CSF 2.0 ou COBIT 2019 focar-se-á em governação, responsabilidade pelo risco, métricas de desempenho, estados atual e alvo, capacidade dos processos e alinhamento com o apetite ao risco empresarial.

A política empresarial Política de Auditoria e Monitorização da Conformidade, cláusula 3.4, capta a finalidade da evidência:

Gerar evidência defensável e um trilho de auditoria em suporte de pedidos de esclarecimento regulamentares, processos judiciais ou pedidos de garantia por parte de clientes.

Esse é o padrão operacional para o qual as equipas NIS2 devem construir.

Responsabilização da gestão: o órgão de administração não pode delegar a NIS2 para fora

O artigo 20 da NIS2 exige que os órgãos de gestão das entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação. Os membros dos órgãos de gestão podem ser responsabilizados por infrações, sujeitos às regras nacionais de responsabilidade.

Isto alinha-se com os requisitos de liderança da ISO 27001:2022. A alta direção deve assegurar que a política e os objetivos de segurança da informação estão alinhados com a direção estratégica, integrar os requisitos do SGSI nos processos de negócio, disponibilizar recursos, comunicar a importância, atribuir responsabilidades e promover a melhoria contínua.

Um órgão de administração não precisa de exportações brutas de scanners nem de registos SIEM completos. Precisa de garantia adequada à tomada de decisão.

Um pacote trimestral de evidência NIS2 para o órgão de administração deve incluir:

1. Alterações de âmbito e de estatuto regulamentar
2. Principais riscos NIS2 e estado do tratamento
3. Painel de eficácia dos controlos do artigo 21
4. Incidentes significativos, quase-incidentes e decisões de reporte
5. Exceções de risco de fornecedores e serviços em nuvem
6. Constatações de auditoria interna, ações corretivas e evidência em atraso

Este pacote dá à gestão a informação necessária para aprovar medidas, questionar exceções e aceitar risco residual.

O modelo operacional Clarysec para 2026

Operacionalizar medidas técnicas NIS2 com a ISO 27001:2022 exige um modelo simples, mas disciplinado:

• Definir o âmbito de NIS2, DORA, RGPD da UE e obrigações contratuais dentro do SGSI
• Mapear obrigações para riscos, políticas, controlos, responsáveis e evidência
• Usar a Declaração de Aplicabilidade como fonte de verdade dos controlos
• Criar pacotes de evidência para áreas de alto risco do artigo 21
• Integrar a comunicação de incidentes num único fluxo de trabalho regulamentar
• Tratar a segurança de fornecedores como um ciclo de vida, não como um questionário
• Executar auditorias internas com amostras reais
• Reportar a eficácia dos controlos aos órgãos de gestão
• Melhorar com base em incidentes, constatações de auditoria, testes e alterações regulamentares

Para Maria, o ponto de viragem foi perceber que não precisava de um projeto NIS2 separado. Precisava de um motor de evidência do SGSI mais forte.

As políticas da Clarysec, o Zenith Blueprint e o Zenith Controls foram concebidos para trabalhar em conjunto. As políticas definem o comportamento esperado e os registos. O Zenith Blueprint fornece o percurso de implementação e auditoria em 30 passos. O Zenith Controls disponibiliza o mapeamento de conformidade cruzada para que NIS2, ISO 27001:2022, DORA, RGPD da UE, NIST CSF e garantia ao estilo COBIT possam ser geridos como um programa coerente.

Próximo passo: criar o seu mapa de evidência NIS2 para ISO 27001:2022

Se o seu trabalho NIS2 ainda vive numa folha de cálculo de lacunas, 2026 é o ano para o operacionalizar.

Comece por uma medida técnica de alto risco, como gestão de vulnerabilidades, tratamento de incidentes ou segurança de fornecedores. Mapeie-a para riscos ISO 27001:2022, políticas, controlos do Anexo A, responsáveis, procedimentos e evidência. Depois, amostre os registos do último trimestre e coloque uma pergunta exigente: isto satisfaria um regulador, um avaliador de cliente e um auditor ISO 27001:2022?

A Clarysec pode ajudar a construir essa resposta usando a biblioteca de políticas, o Zenith Blueprint e o Zenith Controls.

O objetivo não é mais documentação. O objetivo é evidência defensável e repetível de que as suas medidas técnicas NIS2 funcionam efetivamente.