NIS2 e NP EN ISO 27001: o que o certificado cobre e o que falta para cumprir a KSC

Em muitas empresas, a discussão sobre a NIS2 começa com uma pergunta sobre o certificado NP EN ISO 27001. É compreensível, mas, do ponto de vista da gestão de topo e dos responsáveis pelos processos, esse não é o ponto de partida adequado. Primeiro, é necessário determinar se a organização está abrangida pelas obrigações, a que serviços e ativos estas se aplicam e quem deve assumir a responsabilidade. Só depois é possível avaliar, com rigor, o que o atual sistema de gestão da segurança da informação cobre efetivamente e o que ainda falta para cumprir a KSC. Na prática, é neste ponto que se distingue um sistema estruturado de uma dispendiosa ilusão de preparação.

O erro mais dispendioso: confundir certificação com conformidade

O maior erro inicial não é a ausência de um certificado NP EN ISO 27001, mas a convicção de que a sua existência comprova, por si só, a conformidade com as obrigações decorrentes da NIS2 e da legislação nacional que implementa a KSC. Para a gestão, a pergunta correta não é «temos a NP EN ISO 27001?», mas sim «estamos abrangidos pelas obrigações, em que qualidade e relativamente a que serviços, processos e ativos?». Só depois de determinar o estatuto da entidade, o âmbito das atividades abrangidas e as responsabilidades da gestão é possível avaliar em que medida o sistema existente apoia efetivamente a conformidade e onde apenas cria uma aparência de controlo.

Esta distinção tem consequências diretas no projeto e no orçamento. O certificado confirma a conformidade do sistema de gestão com os requisitos da norma dentro de um âmbito de certificação definido, normalmente descrito no certificado e detalhado na Declaração de Aplicabilidade. Contudo, não substitui a análise das obrigações legais, a identificação dos serviços relevantes, a avaliação das dependências de fornecedores nem a determinação das medidas formais que uma organização abrangida pela regulamentação deve executar. A gestão deve, portanto, separar três dimensões que frequentemente se confundem: o sistema de gestão, a conformidade regulamentar e a capacidade operacional para atuar sob a pressão de um incidente.

Os projetos mais dispendiosos são os que seguem a ordem inversa. A organização começa por estruturar a documentação e os controlos para a auditoria de certificação e só depois descobre que ficaram fora do âmbito processos críticos, obrigações de notificação de incidentes, requisitos aplicáveis aos fornecedores, responsabilidades da gestão ou exigências setoriais. Nessa fase, não basta acrescentar alguns procedimentos. É necessário redesenhar o âmbito do sistema, as funções de decisão e o modelo de resposta.

Do ponto de vista operacional, não se deve medir apenas a existência do certificado, mas três aspetos: o alinhamento entre o âmbito da certificação e os serviços críticos, o resultado da autoavaliação sobre a aplicabilidade da KSC e o número de lacunas entre os procedimentos e a capacidade real de atuação. Por isso, o primeiro passo natural não é aumentar a documentação, mas determinar se a organização está abrangida pelas obrigações e que medidas formais são exigidas. Esta sequência também é bem estruturada no artigo NIS2: autoavaliação e inscrição no Registo KSC — o que deve fazer uma empresa industrial?, porque é nesse momento que se decide se a empresa está a construir um sistema orientado para obrigações reais ou para uma confortável, mas dispendiosa, ilusão de preparação.

O que a NP EN ISO 27001 cobre na prática, e não apenas no plano declarativo

O principal valor prático da NP EN ISO 27001 não reside na simples posse do certificado, mas no facto de um sistema bem implementado estruturar a segurança como uma área de gestão. O seu contributo é mais forte onde a organização deve atuar por processos: análise e tratamento de riscos, definição de políticas e mecanismos de controlo, atribuição de funções e responsabilidades, identificação dos ativos de informação, resposta a incidentes, continuidade do negócio e mecanismos de análise e melhoria. Quando estes elementos funcionam efetivamente, e não apenas para efeitos de auditoria, a empresa dispõe de uma base sólida para demonstrar que a segurança não é um conjunto de controlos isolados, mas um sistema gerido e ligado às decisões operacionais.

A gestão deve, contudo, avaliar não apenas o certificado, mas a sua utilidade relativamente aos serviços, processos e dependências com relevância regulamentar. O mesmo certificado pode representar um sistema maduro, que abrange processos críticos, análises regulares, ações corretivas e supervisão efetiva pelos responsáveis dos processos, ou um sistema restrito a uma pequena parte da organização. Antes da autoavaliação segundo os requisitos da NIS2 e da KSC, importa verificar não apenas a Declaração de Aplicabilidade, mas também a lista de processos abrangidos pela análise de risco, os resultados das auditorias internas, as conclusões das revisões pela gestão e se as decisões sobre riscos se refletem no orçamento, nos contratos, na arquitetura dos serviços e no modelo de resposta.

Isto é particularmente evidente nas empresas integradas em cadeias de abastecimento. A NP EN ISO 27001 normalmente estrutura os requisitos contratuais, a classificação da informação, as regras de acesso, as responsabilidades dos fornecedores e a forma de documentar exceções. É uma base útil, sobretudo quando os clientes exigem evidências do controlo exercido sobre os parceiros. No entanto, não resolve automaticamente todas as expectativas do setor nem critérios setoriais específicos; um dilema semelhante é abordado em NP EN ISO 27001 ou TISAX — qual escolher quando o cliente exige segurança da informação na cadeia de abastecimento? Na prática, o certificado ajuda a estruturar relações e responsabilidades, mas não substitui a verificação das obrigações que ainda devem ser incluídas nos contratos, nos procedimentos de escalamento e no controlo dos serviços externos.

A conclusão é simples: o certificado pode reduzir significativamente o percurso necessário para estruturar a segurança, mas não constitui, isoladamente, prova do cumprimento das obrigações decorrentes da KSC. A auditoria de certificação avalia a conformidade do sistema de gestão com os requisitos da norma dentro de um âmbito definido; não avalia necessariamente os mesmos elementos que podem ser exigidos na verificação das obrigações legais e da preparação operacional. A organização deve, por isso, confirmar em paralelo se o âmbito do sistema abrange os processos relevantes, se a análise de risco foi atualizada considerando os serviços e as dependências reais e se os procedimentos de resposta, continuidade e controlo de fornecedores funcionam na prática.

Onde o certificado não é suficiente

A primeira lacuna diz respeito à própria conformidade regulamentar. Um sistema de gestão da segurança da informação estrutura princípios, funções e mecanismos de supervisão, mas não determina automaticamente se uma entidade foi corretamente classificada no contexto das obrigações da KSC, quem é responsável pelas notificações formais, quem mantém a relação com a autoridade competente e como as decisões são escaladas para a gestão. Não se trata da falta de um único documento, mas de uma deficiência na conceção das responsabilidades. Se estes elementos não estiverem integrados no modelo real de funcionamento da empresa, o certificado proporciona organização interna, mas ainda não assegura capacidade de governação regulamentar.

A segunda lacuna relaciona-se com o âmbito. Muitas organizações têm uma certificação limitada a uma determinada instalação, empresa, direção ou parte dos serviços de suporte. A avaliação da preparação para a KSC deve, porém, partir do mapa real de serviços, processos críticos, ativos e dependências, e não dos limites da auditoria de certificação. Se um serviço essencial ou importante for prestado por várias entidades de um grupo, com a participação de um centro de dados externo, uma equipa de manutenção partilhada ou um processo distribuído de gestão de incidentes, um certificado formalmente correto pode abranger apenas uma parte do conjunto. Neste caso, a decisão da gestão não se reduz a saber se o certificado deve ser alargado, mas exige determinar se deve existir um único projeto integrado de conformidade ou dois fluxos paralelos: certificação e conformidade regulamentar.

A terceira lacuna é de natureza probatória e, geralmente, só se torna visível durante um incidente, exercício ou inspeção. A organização dispõe de procedimentos de resposta, continuidade do negócio e controlo de fornecedores, mas não consegue demonstrar que estes mecanismos funcionam operacionalmente. Faltam o registo de incidentes, a rastreabilidade das decisões da gestão, os resultados dos exercícios, as análises posteriores aos eventos, os indicadores de eficácia e as ações corretivas documentadas. Neste estado, o sistema está descrito, mas não demonstrado. É também aqui que surgem as correções mais dispendiosas, porque é necessário alterar não apenas os procedimentos, mas também o reporte à gestão, a periodicidade das revisões e a responsabilidade dos responsáveis pelos processos. O mesmo mecanismo é visível noutros sistemas de gestão, nomeadamente no artigo IATF 16949 — quais os requisitos que realmente criam dificuldades na gestão diária da qualidade e como geri-los sem uma conformidade meramente aparente.

A quarta lacuna diz respeito à cadeia de abastecimento e às dependências externas. A norma ajuda a estruturar os requisitos aplicáveis aos fornecedores, mas a conformidade com a KSC pode exigir um mapeamento mais aprofundado: quais os serviços externos que sustentam a prestação do serviço crítico, onde existem pontos únicos de falha, quais os cenários de perturbação e qual a capacidade de substituição do fornecedor, das pessoas ou da instalação. Na prática, não basta medir a existência de contratos e avaliações de fornecedores. Importa verificar o alinhamento do âmbito do certificado com o mapa real dos serviços críticos, a completude dos registos de incidentes e exercícios e a atualidade das revisões de fornecedores e dependências. Só esta análise permite determinar se a organização possui um sistema estruturado ou apenas a sua representação formal.

O projeto de conformidade deve começar pelos serviços, não pelos documentos

O erro inicial mais frequente consiste em começar o projeto pela revisão das políticas, dos procedimentos e dos registos da NP EN ISO 27001, em vez de perguntar quais os serviços que devem efetivamente ser mantidos e que obrigações regulamentares lhes estão associadas. A sequência correta é a inversa: primeiro identificam-se os serviços, processos, ativos e dependências críticos para a continuidade do negócio e para as responsabilidades decorrentes da KSC; depois, associam-se os requisitos do sistema e as evidências necessárias. Só esta abordagem permite distinguir os documentos necessários dos que não acrescentam valor.

Para a gestão, isto implica decidir pela elaboração de um mapa dos serviços críticos, das dependências de fornecedores e sistemas e dos procedimentos existentes que podem ser aproveitados sem duplicar mecanismos. Só então será possível perceber se o sistema atual abrange o que é efetivamente relevante para a manutenção dos serviços e para a conformidade, ou apenas o que historicamente foi incluído no âmbito da certificação.

O segundo passo diz respeito ao modelo de responsabilidades. Se a segurança da informação estiver distribuída entre informática, qualidade, compliance, manutenção e compras, sem uma divisão inequívoca das funções, o projeto transforma-se rapidamente num conjunto de iniciativas locais. É necessário determinar quem é responsável pelo risco, quem gere os incidentes, quem controla as relações com fornecedores, quem toma as decisões de gestão e quem mantém as evidências de conformidade. Na prática, uma matriz simples de funções e responsabilidades e um único ciclo de revisão pela gestão tendem a funcionar melhor do que vários circuitos de reporte paralelos. Este é também o momento para decidir se deve ser criado um único comité de direção para a conformidade e a segurança e se a tecnologia operacional deve ser integrada no mesmo modelo de risco.

Esta lógica assume especial importância em organizações industriais e com múltiplas instalações. Nestes contextos, um incidente não se limita à perda de confidencialidade dos dados: pode provocar a paragem de uma linha, perturbar o planeamento, comprometer a rastreabilidade de lotes ou eliminar a capacidade de prestar um serviço. A segurança da informação deve, por isso, estar ligada à continuidade operacional, à manutenção e aos ambientes de tecnologia operacional. Se o sistema de gestão abranger apenas o ambiente administrativo e ignorar os sistemas de controlo, a assistência remota, as dependências de integradores ou os procedimentos de emergência da unidade industrial, a visão do risco estará formalmente estruturada, mas será operacionalmente incompleta. A mesma disciplina de projeto pode ser observada noutras áreas sujeitas a elevados requisitos de supervisão, incluindo referências como ASME, NQA-1 e ISO 19443 — três siglas que qualquer fornecedor do setor nuclear deve conhecer.

Só depois de estabelecer esta base deve a organização utilizar a NP EN ISO 27001 existente como camada de suporte e realizar uma análise de lacunas específica para a KSC. Esta análise não serve para colocar o certificado em causa, mas para verificar onde existe cobertura efetiva e onde são necessários procedimentos, registos, circuitos de escalamento ou evidências de funcionamento adicionais. Esta abordagem limita o excesso de documentação e assegura maior coerência entre os mecanismos do que a condução de implementações separadas e concorrentes.

Como verificar a situação real antes de uma auditoria ou inspeção

Antes de uma auditoria, autoavaliação ou inspeção, a pergunta não deve ser se a organização «tem a NP EN ISO 27001», mas se consegue demonstrar uma capacidade real de atuação e a rastreabilidade das decisões. Esta preparação deve ser avaliada em quatro níveis: primeiro, confirmar o âmbito e a aplicabilidade das obrigações; depois, verificar a conceção do sistema de gestão; em seguida, avaliar a eficácia dos processos; por fim, confirmar a completude das evidências. Só esta sequência permite distinguir organização documental de capacidade operacional.

As perguntas mais úteis não são, portanto, «temos um procedimento?», mas «sabemos quando o ativar, quem toma a decisão, quais são os limiares de escalamento, como o demonstraremos e já exercitámos este cenário?». Se a gestão de um incidente depender do conhecimento de uma única pessoa, se as relações com fornecedores não incluírem critérios de segurança definidos e se a gestão receber apenas relatórios genéricos, sem decisões nem prazos, o sistema pode estar formalmente alinhado com a sua própria descrição e, ainda assim, não estar preparado para atuar sob pressão.

A avaliação da preparação deve, por isso, abranger as interfaces entre gestão, operações, informática, manutenção e fornecedores, porque é precisamente nesses pontos que surgem as lacunas menos visíveis nos procedimentos. Na prática, a solução mais eficaz é uma análise de lacunas conduzida num formato semelhante a uma auditoria operacional. Avalia-se não apenas o conteúdo dos documentos, mas também o processo decisório, os circuitos de escalamento, os registos de incidentes, os resultados de testes e exercícios e o registo de não conformidades, observações e ações corretivas.

Um cenário simples constitui um bom teste: ocorre um incidente num fornecedor crítico ou uma perturbação no ambiente industrial e é necessário determinar quem classifica o evento, quem ativa a comunicação, quem avalia o impacto no serviço e que evidências ficam registadas após a decisão. Se as respostas estiverem dispersas e a organização invocar uma «prática» que ninguém consegue reconstituir através de registos, a preparação é apenas aparente, mesmo quando o sistema de gestão é formalmente bem mantido.

Se a organização já realiza auditorias internas NP EN ISO 27001, estas podem ser utilizadas como instrumento desta verificação, mas os critérios de auditoria devem ser alargados às obrigações regulamentares e às evidências esperadas na perspetiva da KSC. As competências de auditoria são muito úteis neste contexto, tal como as desenvolvidas por profissionais que se preparam para exercer as funções de auditor coordenador ou auditor interno; uma referência natural é também o artigo Auditor coordenador NP EN ISO 27001: guia completo sobre certificação e requisitos da norma. Deve, porém, manter-se a sequência correta: a competência de auditoria ajuda a verificar o sistema, mas não substitui a análise das obrigações legais e organizacionais efetivamente aplicáveis à empresa.

Decisão da gestão: o certificado como base, não como álibi

A abordagem mais racional consiste em tratar a NP EN ISO 27001 como a base da organização da gestão, e não como prova autónoma do cumprimento de todas as obrigações decorrentes da NIS2 e da KSC. O certificado estrutura responsabilidades, avaliação do risco, gestão de incidentes, auditorias e melhoria, mas não dispensa a determinação das obrigações efetivamente aplicáveis à organização, do respetivo âmbito e das evidências necessárias para demonstrar a eficácia.

Para a gestão, o maior risco não é uma lacuna documental, mas a ilusão de preparação: a convicção de que um sistema certificado torna automaticamente a organização preparada para as exigências do quadro jurídico nacional. A decisão não deve, portanto, limitar-se a manter ou alargar a certificação. Primeiro, é necessário resolver três questões de gestão:

• confirmar o estatuto da organização e o âmbito das obrigações;
• realizar uma análise das lacunas entre o sistema existente e os requisitos da KSC;
• definir o modelo de supervisão da execução das ações e das evidências de eficácia.

Só com esta base é possível decidir de forma fundamentada se a empresa necessita de alargar o âmbito da certificação ou se pode utilizar o sistema NP EN ISO 27001 existente sem alterar o âmbito, complementando-o com os mecanismos organizacionais, jurídicos e operacionais em falta. Na prática, três instrumentos simples apoiam esta decisão: o âmbito atual da certificação comparado com o mapa dos processos críticos, uma lista de lacunas com avaliação do impacto no risco e na conformidade e um plano de ações com responsáveis, prazos e critérios de encerramento.

Quando uma organização ainda está a escolher o percurso, a ordem dos trabalhos não é universal. Nos casos em que existe uma forte pressão dos clientes ou requisitos de concursos, a implementação do sistema com vista à certificação pode constituir um primeiro passo justificado, desde que a análise das obrigações regulamentares decorra em paralelo. Nas empresas com elevado risco operacional ou com responsabilidades dispersas, pode ser mais prudente corrigir primeiro as lacunas regulamentares e só depois estruturar o âmbito da certificação. Não se trata de discutir a ordem das formalidades, mas a sequência da redução do risco. Neste sentido, o artigo Certificado ISO: benefícios e processo de implementação também deve ser analisado como parte de uma decisão mais ampla sobre o modelo de gestão da conformidade, e não de forma isolada do funcionamento da empresa.

Os melhores resultados são obtidos através de um único programa coerente, no qual a segurança da informação, a continuidade do negócio, o controlo de fornecedores e as obrigações regulamentares são geridos como componentes do modelo operacional da empresa, e não como iniciativas separadas de diferentes departamentos. Na realidade polaca, é precisamente a fragmentação das responsabilidades que mais frequentemente reduz a capacidade de execução e de apresentação de evidências. A conclusão é clara: o certificado ajuda e pode encurtar significativamente o percurso de estruturação do sistema, mas a conformidade ainda tem de ser concebida, implementada e demonstrada através de evidências adequadas às condições da NIS2 e da KSC.