Tratamento de incidentes na NIS 2 nos termos do artigo 21.o, n.o 2, alínea b)
O artigo 21.o, n.o 2, alínea b), é o dever interno: detetar, conter, recuperar, documentar, aprender. O artigo 23.o é o dever externo: avisar o BSI ou o seu CSIRT nacional. Dois deveres diferentes, muitas vezes confundidos. A CIR (UE) 2024/2690 §3 detalha o interno.
A versão curta
O tratamento de incidentes é a alínea b) na lista de dez deveres de cibersegurança do artigo 21.o, n.o 2. Trata do que faz dentro da empresa quando algo corre mal: detetá-lo, contê-lo, recuperar, registar o que aconteceu, aprender com isso.
A CIR (UE) 2024/2690 §3 preenche o detalhe em seis subsecções: §3.1 um conceito escrito de tratamento de incidentes, §3.2 monitorização e registo, §3.3 escalonamento interno de eventos, §3.4 classificação, §3.5 a resposta em si (contenção, erradicação, recuperação), §3.6 a revisão pós-incidente. Se explora DNS, nuvem, um centro de dados, um MSP ou qualquer outro setor do anexo da CIR, isto vincula-o diretamente.
A Alemanha coloca o mesmo dever na lei nacional através do §30(2)(2) BSIG. A expressão é 'Bewältigung von Sicherheitsvorfällen', as mesmas palavras da diretiva. Esta página percorre a diretiva, o regulamento de execução da UE e a transposição alemã, por esta ordem.
Artigo 21.o, n.o 2, alínea b), da diretiva NIS 2 (2022/2555)
Tratamento de incidentes.
A alínea b) na lista de dez medidas de cibersegurança. Duas palavras no texto da diretiva. A CIR §3 transforma essas duas palavras em detalhe operacional. Importante: este é o dever interno de tratamento. O dever externo de notificar o CSIRT está no artigo 23.o e é uma página separada.
CIR (UE) 2024/2690, anexo §3
Para efeitos do artigo 21.o, n.o 2, alínea b), da Diretiva (UE) 2022/2555, as entidades em causa estabelecem e aplicam uma política de tratamento de incidentes, definindo papéis, responsabilidades e procedimentos para a deteção atempada, a análise, a contenção ou resposta, a recuperação, bem como a documentação e a comunicação de incidentes.
Por ser um regulamento, é lei da UE diretamente vinculativa. Não é necessária transposição nacional. O anexo §3 divide o dever em seis subsecções: conceito (§3.1), registo (§3.2), escalonamento interno (§3.3), classificação (§3.4), resposta (§3.5), revisão pós-incidente (§3.6).
§30(2)(2) BSIG (Alemanha)
Bewältigung von Sicherheitsvorfällen.
A Alemanha copia a redação da diretiva palavra por palavra. A substância é idêntica à do artigo 21.o, n.o 2, alínea b). O BSI usa depois os blocos do IT-Grundschutz (em particular o DER.2 'Vorfall-Bewältigung') para mostrar como é, na prática, um conceito escrito de tratamento de incidentes.
Um conceito escrito de tratamento de incidentes
Registe quem faz o quê quando algo corre mal. Papéis, responsabilidades, os passos para deteção, análise, contenção, recuperação, documentação e comunicação interna. A CIR §3.1.1 exige que o conceito exista antes do incidente, não depois. O órgão de gestão tem de o aprovar.
Monitorização e registo
Não pode tratar o que não consegue ver. A CIR §3.2 lista doze tipos de evento que tem de registar (tentativas de início de sessão, alterações de privilégios, deteções de malware, anomalias de rede e outros). Os registos têm de ser resistentes à adulteração e conservados o tempo suficiente para suportar a análise. Esta é a camada de deteção.
Fases de resposta: contenção, erradicação, recuperação
A CIR §3.5 divide a resposta em três fases. A contenção impede a propagação do incidente. A erradicação remove a causa raiz. A recuperação repõe os sistemas num estado conhecido como bom. Cada fase tem de ser documentada à medida que avança, para que a §3.6 (revisão pós-incidente) tenha com o que trabalhar.
O tratamento interno não é a comunicação externa
O artigo 21.o, n.o 2, alínea b), é o que faz dentro da empresa. O artigo 23.o é o que comunica ao regulador (alerta precoce em 24 horas, notificação de incidente em 72 horas, relatório final em um mês ao BSI ou ao seu CSIRT nacional). Dois deveres separados. Fazer a comunicação não dispensa o tratamento, e fazer o tratamento não dispensa a comunicação.
A revisão pós-incidente alimenta de novo a gestão de riscos
A CIR §3.6 fecha o ciclo. As lições de cada incidente alimentam de novo o enquadramento de gestão de riscos da CIR §2. Novos riscos são acrescentados, os planos de tratamento são atualizados, os controlos são ajustados. É o ciclo PDCA. Um incidente que trata mas com o qual não aprende é meio trabalho.
BSI / §30(2)(2) BSIG
O BSI lista o tratamento de incidentes nos Infopakete como a segunda das dez medidas do artigo 21.o, n.o 2. A transposição alemã usa a mesma expressão da diretiva. O BSI aponta para o bloco DER.2 ('Vorfall-Bewältigung') do IT-Grundschutz como via prática. O DER.2 guia-o pelo conceito, pelo manual de procedimentos, pelos papéis e pela revisão pós-incidente.
Orientação Técnica de Implementação da ENISA
A TIG da ENISA pega na CIR §3 e mostra como é a prova na prática: o conceito escrito, o manual de procedimentos, os registos de simulação, as notas de revisão pós-incidente. Mapeia também a §3 nos controlos consolidados da ISO/IEC 27001:2022 (cláusulas A.5.24 a A.5.28) e do NIST CSF 2.0 (as funções Responder e Recuperar), por isso uma certificação existente dá-lhe vantagem inicial.
Leis nacionais de transposição
Cada Estado-Membro tem a sua própria lei de transposição (Países Baixos: Cyberbeveiligingswet, Áustria: NISG, Bélgica: NIS2-Wet). O dever é o mesmo porque a diretiva define uma única norma à escala da UE. O que difere: a que CSIRT fala para a comunicação do artigo 23.o, e como cada autoridade nacional formula a orientação prática.
Comunicamos ao BSI quando algo acontece, por isso estamos cobertos.
Isso cobre o artigo 23.o, não o artigo 21.o, n.o 2, alínea b). Comunicar ao CSIRT é o dever externo. O artigo 21.o, n.o 2, alínea b), é o interno: detetar, conter, recuperar, documentar, rever. Os dois têm de existir. Um auditor vai pedir para ver o conceito de tratamento de incidentes (CIR §3.1) além do registo de comunicação do artigo 23.o.
Vamos escrever o manual de procedimentos quando algo acontecer.
A CIR §3.1.1 é explícita: o conceito tem de estar 'estabelecido e aplicado' antes do incidente. Papéis, responsabilidades, procedimentos, tudo no papel, aprovado pela gestão. Escrevê-lo durante o incidente não é tratamento, é improvisação. Os auditores procuram primeiro o conceito datado e assinado.
A equipa de TI trata disso, é suficiente.
A CIR §3.1.1 exige papéis e responsabilidades documentados. Quem declara um incidente. Quem decide a contenção. Quem fala com o jurídico. Quem aprova a recuperação. O órgão de gestão tem de aprovar o conceito. 'A equipa de TI trata disso' não é uma estrutura, é um pressuposto.
A lacuna típica da média empresa é a documentação, não a capacidade. A deteção acontece (alguém repara, a TI investiga, o problema é resolvido). A documentação não. Sem o registo datado de quem fez o quê, o auditor não tem forma de verificar que a §3 foi cumprida. A solução é construir primeiro o manual de procedimentos, depois simular duas vezes por ano e depois registar as lições no modelo de revisão pós-incidente.
Duas simulações por ano é o que a maioria dos profissionais com quem falamos adota. Uma de mesa (pessoas à volta de uma mesa, percorrendo o manual de procedimentos num cenário), uma técnica (uma reposição controlada a partir de cópia de segurança, um exercício de resposta a phishing, algo que exercite as ferramentas). O objetivo é encontrar as lacunas antes de um auditor o fazer, ou antes de um incidente real o fazer. A proporcionalidade do artigo 21.o, n.o 1, permite-lhe dimensionar a simulação à sua dimensão e ao seu perfil de risco; não lhe permite saltá-las.
Integrámos a CIR §3 na plataforma como o módulo INC. Regista um incidente, captura a classificação ao abrigo da §3.4, percorre as fases de resposta (contenção, erradicação, recuperação) com marcas temporais e executa a revisão pós-incidente no fim. O trilho de auditoria regista cada passo. Nada de montes de folhas de cálculo.
A revisão pós-incidente da §3.6 é a parte que a maioria das equipas salta. Tornámo-la um campo obrigatório antes de um incidente poder ser fechado: o que correu mal, o que funcionou, que alterações são reintroduzidas no enquadramento de riscos da CIR §2. A comunicação do artigo 23.o (24h / 72h / um mês) é um módulo separado que usa o mesmo registo de incidente, por isso não escreve os factos duas vezes.
- Diretiva (UE) 2022/2555 (NIS 2), artigo 21.o, n.o 2, alínea b). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), anexo §3. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei do BSI (BSIG), §30(2)(2) com a redação dada pela Lei de Implementação da NIS2 e de Reforço da Cibersegurança
- Bloco DER.2 do IT-Grundschutz do BSI, 'Vorfall-Bewältigung'. bsi.bund.de/grundschutz
- Orientação Técnica de Implementação da ENISA para a CIR (UE) 2024/2690, mapeamento da §3 para a ISO/IEC 27001:2022 e o NIST CSF 2.0