NIS2 e ITIL: como o framework ajuda a cumprir o regulamento

A diretiva NIS2 substitui a NIS1 e alarga o universo de empresas obrigadas a cibersegurança gerida com seriedade. Em Portugal, a transposição está em curso e muitas organizações descobrem agora que estão abrangidas. Outras descobrem que sempre estiveram, mas escaparam à primeira diretiva por interpretação extensiva.

O reflexo natural é correr para comprar tecnologia: SIEM, EDR, MDR. Importante, mas insuficiente. A NIS2 é em primeiro lugar uma diretiva de governança e processos. Auditores não vão pedir o último relatório do firewall. Vão pedir o procedimento de notificação em 24 horas, a evidência de que foi treinado, o registo de que funcionou no último incidente e a análise pós-evento que conduziu a melhorias. O ITIL entra como base sólida para tudo isto.

O que a NIS2 exige na prática

O artigo 21.º da diretiva lista dez medidas mínimas obrigatórias para gestão de risco de cibersegurança. Reduzido ao essencial, agrupam-se em cinco blocos:

1. Análise de risco e política de segurança da informação documentadas e revistas periodicamente.
2. Gestão de incidentes com capacidade de deteção, resposta, recuperação e notificação dentro dos prazos legais (24h para alerta inicial, 72h para relatório intermédio, 1 mês para relatório final).
3. Continuidade de negócio com planos de recuperação, cópias de segurança e gestão de crise testados.
4. Segurança da cadeia de fornecimento, incluindo avaliação de fornecedores e contratos com cláusulas de cibersegurança.
5. Higiene cibernética básica e formação dos colaboradores, controlos de acesso, criptografia, autenticação multifator e gestão de vulnerabilidades.

Para cada um destes blocos, a NIS2 exige medidas proporcionais ao risco, mas a interpretação prática que está a emergir nos primeiros incidentes europeus é simples: tem de existir um processo escrito, treinado, executado regularmente e auditável. Não basta ter um documento na gaveta.

Mapa: o que a NIS2 exige e que prática ITIL responde

Esta tabela cruza os blocos da NIS2 com as práticas ITIL 4 e v5 que cobrem cada exigência. Serve para perceber rapidamente onde já tem maturidade e onde precisa de investir.

Se a sua organização já tem cinco ou mais destas práticas com maturidade razoável, a NIS2 é principalmente um exercício de adaptação. Se tem menos de cinco, o caminho passa por construir a base ITIL antes de pensar em cumprir a diretiva.

Três lacunas que aparecem em quase todos os projectos

Em conversas com responsáveis de TI portugueses nos últimos meses, três lacunas repetem-se sistematicamente, mesmo em organizações com ITIL bem implementado:

1. O processo de incidente não fala com o regulador

A maior parte das equipas tem incident management para problemas operacionais (sistema parado, performance degradada, utilizador bloqueado), mas falta o gatilho específico que classifica um incidente como significativo no sentido da NIS2 e dispara a notificação às autoridades. O fluxo padrão termina em "resolvido". Tem de passar a ter um ramo "resolvido + notificação iniciada".

A correção é pequena no papel mas crítica na execução: adicionar um campo de classificação NIS2 no formulário de incidente, definir critérios objectivos (impacto em utilizadores, indisponibilidade, exposição de dados) e treinar o service desk a perguntar essas perguntas no primeiro minuto.

2. Os fornecedores estão fora do mapa

A NIS2 trata explicitamente da segurança da cadeia de fornecimento. Quase todas as organizações têm contratos com fornecedores de cloud, software ou serviços geridos, mas poucas conseguem em 30 minutos responder a três perguntas simples: que fornecedores acedem aos nossos sistemas, que dados tocam, e o que diz o contrato sobre cibersegurança e notificação de incidentes.

A prática de supplier management cobre isto, mas raramente é instanciada com profundidade suficiente. A NIS2 obriga a fechar este vazio com um inventário formal de fornecedores críticos, avaliação de risco por fornecedor e cláusulas contratuais alinhadas com a diretiva.

3. Continuidade existe no plano e não nos exercícios

É comum encontrar planos de continuidade actualizados em PDF e completamente desconhecidos das equipas que os teriam de executar. A NIS2 exige evidência de testes regulares, não documentação. Um plano que nunca foi exercitado é, para efeitos de auditor, equivalente a não existir.

O caminho prático passa por exercícios de mesa trimestrais (90 minutos, sem desligar nada, só simular a tomada de decisão), e exercícios técnicos anuais com falha controlada de pelo menos um sistema crítico.

Roadmap de 90 dias para começar

Para uma organização que tem ITIL operacional mas precisa de se preparar para auditoria NIS2, este plano de 90 dias é o que tem dado resultado. Ajustável à dimensão e maturidade.

1. Dias 1 a 15: assessment e mapa de lacunas Workshop com responsáveis de TI e segurança para mapear as 10 medidas do artigo 21.º contra os processos ITIL existentes. Output: tabela com cada exigência classificada como cumprida, parcialmente cumprida ou em falta. Sem reuniões teóricas. Documente provas reais.
2. Dias 16 a 30: incident management nivelado para NIS2 Adicionar classificação NIS2 ao processo de incident, definir matriz de severidade que dispara notificação, criar template de comunicação para o regulador, treinar todo o service desk. Validar com simulacro.
3. Dias 31 a 45: cadeia de fornecimento Inventariar fornecedores com acesso a sistemas ou dados críticos, classificar risco por fornecedor, identificar contratos sem cláusulas de cibersegurança e calendarizar renegociação. Output: registo de fornecedores críticos pronto a apresentar.
4. Dias 46 a 60: continuidade testada Realizar exercício de mesa cobrindo um cenário plausível (ransomware num sistema crítico, perda de fornecedor cloud, indisponibilidade prolongada de internet). Documentar lacunas, ajustar planos e calendarizar exercício técnico anual.
5. Dias 61 a 75: política de segurança e formação Rever política de segurança da informação para alinhar explicitamente com NIS2, garantir aprovação ao mais alto nível, lançar campanha de sensibilização para todos os colaboradores e treinar em phishing e password hygiene.
6. Dias 76 a 90: auditoria interna e plano de melhoria contínua Auditoria interna de cumprimento, fechar achados críticos, publicar dashboard de medidas para a administração e definir cadência de revisão (mensal para incidentes, trimestral para risco, anual para política).

Noventa dias bem investidos não fazem milagre, mas colocam a organização numa posição defensável. Em caso de inspeção, é melhor ter este histórico do que três anos a procrastinar.

Templates e ferramentas que aceleram o trabalho

Para evitar que cada equipa redesenhe a mesma roda, partilho os templates práticos que uso em projetos reais. Estão disponíveis na biblioteca de templates Better Skills, em PT e EN, formato Word e Excel:

• Registo de incidente NIS2: formulário com classificação automática de severidade e gatilho de notificação.
• Procedimento de notificação ao regulador: documento operacional com fluxograma e templates de comunicação para o alerta de 24h, relatório de 72h e relatório final.
• Matriz RACI de gestão de incidentes de segurança: clarifica quem decide, quem executa e quem é informado em cada fase.
• Registo de fornecedores críticos: planilha com classificação de risco, dados acedidos, cláusulas contratuais e data da última revisão.
• Plano de continuidade de serviço: estrutura completa com RTO, RPO, procedimentos de ativação e log de exercícios.
• Política de segurança da informação: documento base alinhado com ISO 27001 e NIS2, pronto a adaptar.

Quem prefere desenhar visualmente o ecossistema de práticas e ver o resultado em tempo real, o ITIL v5 Designer permite construir um canvas das práticas obrigatórias, validar contra 206 regras e exportar em PDF ou PowerPoint para apresentar à administração.

Para informação detalhada sobre o âmbito da NIS2, prazos de transposição em Portugal e checklists específicas por sector, visite o portal dedicado em nis2-portugal.com.

Erros que vejo repetir-se e como evitar

Cinco padrões que conduzem a projetos NIS2 que falham auditoria mesmo tendo investido tempo e dinheiro:

1. Comprar tecnologia antes de definir processos. SIEM sem playbooks de resposta é apenas ruído caro. Defina o processo primeiro, escolha a ferramenta que o serve.
2. Tratar a NIS2 como projeto IT. A diretiva exige envolvimento da administração, com responsabilidade pessoal em casos graves. Excluir o board do projeto é o caminho mais rápido para o fracasso.
3. Documentar para o auditor, não para quem executa. Procedimentos escritos em legal mas inexecutáveis na prática falham na primeira simulação. Escreva o que realmente vai ser feito, não o que soa bem.
4. Esquecer formação contínua. Uma sessão anual de phishing não cumpre o requisito de higiene cibernética. Precisa de um plano com cadência, métricas e melhoria.
5. Não testar a notificação de 24h. O primeiro exercício prático para muitas equipas é o incidente real. Faça simulacros antes, com cronómetro.

Perguntas frequentes