Notificação de incidente: o que a NIS2 já ensinou

Existe um momento no ciclo de vida de um incidente de segurança que quase nenhuma empresa brasileira ensaiou: aquele em que você precisa contar para alguém de fora que foi atacada — e ainda não sabe direito o que aconteceu.

É um momento desconfortável por construção. Nas primeiras horas, o que se tem são fragmentos: um alerta estranho, um servidor que não responde, um log com um acesso que não deveria existir. E é exatamente nessa hora que os prazos regulatórios começam a correr.

A tese em uma frase: o alerta inicial vai ser incompleto — a regulação sabe disso e é por isso que a notificação é escalonada; quem trata o prazo como "hora de entregar o diagnóstico" acaba entregando silêncio, que é a única resposta que nenhum regulador aceita.

O que já vale no Brasil

Antes de olhar para fora, vale ser preciso sobre o que existe aqui — porque muita gente acha que "não tem regra ainda", e tem.

A Resolução CD/ANPD nº 15/2024 aprovou o Regulamento de Comunicação de Incidente de Segurança e é a régua mais concreta do país. Os pontos que importam na prática:

• Prazo de três dias úteis para o controlador comunicar à ANPD, contados da ciência, salvo prazo específico previsto em outra norma.
• Critério de relevância: a obrigação existe quando o incidente pode acarretar risco ou dano relevante aos titulares. A resolução ancora isso em categorias — dado sensível, dado de criança e adolescente, dado financeiro, dado de sistema de autenticação, dado sob sigilo, ou tratamento em larga escala.
• Conteúdo mínimo: natureza dos dados afetados e medidas adotadas para reverter ou mitigar o dano.
• Registro por cinco anos, no mínimo — inclusive dos incidentes que você decidiu não comunicar. Essa é a parte que mais escapa: a decisão de não notificar precisa estar documentada e justificada, senão vira omissão.

O canal e as orientações estão na própria página da ANPD. Se a sua empresa ainda não mapeou onde se enquadra, o guia de LGPD para PMEs cobre o básico.

Somem-se a isso as regras setoriais — Banco Central, Anatel, ANS têm as suas — e o CTIR Gov, que recebe notificações da administração pública federal.

O buraco: se um ataque derrubar o seu serviço por três dias sem vazar um único dado pessoal, e você não for regulado por ninguém, não existe prazo legal nenhum. É a lacuna que o Marco Legal da Cibersegurança pretende fechar.

O modelo europeu, e por que ele é escalonado

A NIS2 desenhou a notificação em três tempos, e a lógica por trás disso é a parte aproveitável:

• 24 horas — alerta inicial (early warning). Uma sinalização de que algo está acontecendo. Não é relatório, é aviso.
• 72 horas — notificação de incidente. Avaliação inicial de gravidade, impacto e indicadores de comprometimento.
• Um mês — relatório final. Descrição detalhada, causa raiz, medidas aplicadas e, quando cabível, impacto transfronteiriço.

A escala existe porque a alternativa não funciona. Prazo único e longo deixa a autoridade cega justamente na janela em que ela poderia alertar outras vítimas potenciais. Prazo único e curto força a empresa a inventar um diagnóstico que ela não tem. Escalonar resolve os dois: avisa cedo, detalha depois.

O que os europeus reclamam — e vale ouvir

Aqui entra a honestidade que falta na maioria dos textos de compliance: 24 horas é cedo demais para saber o que aconteceu, e quem opera sabe disso. O efeito colateral previsível é que o alerta inicial vira ruído: muita notificação genérica, pouca informação acionável, e uma autoridade com uma caixa de entrada cheia de "estamos apurando".

Some-se o problema que a própria União Europeia acabou reconhecendo. Como cada Estado-membro transpôs a diretiva à sua maneira, em 26 de maio de 2026 o Grupo de Cooperação NIS2 teve de adotar templates comuns de notificação, porque a multiplicação de formatos havia virado custo real para quem opera em vários países. E em 20 de janeiro de 2026 a Comissão propôs emendas de simplificação, incluindo regras harmonizadas sobre divulgação de pagamento de resgate e papel operacional ampliado para a ENISA.

Ou seja: os prazos são a parte fácil. O que dá trabalho é para quem e em que formato — e é exatamente aí que o Brasil ainda pode escolher o caminho curto, como discuto no post sobre quem deve comandar a cibersegurança no Brasil.

O runbook de notificação de incidente: as primeiras horas

Esta é a parte que você pode escrever hoje, e que não muda com o texto final de nenhuma lei.

Hora zero: registre o relógio

A primeira ação não é técnica. É anotar a data e a hora exatas da detecção, e como se chegou a ela. Esse carimbo vira a origem de todos os prazos e é a primeira coisa que um regulador pede.

Registre também o que já se sabia antes. Se havia um alerta ignorado três dias atrás, é melhor que isso apareça na sua própria linha do tempo do que na de um auditor.

Conter antes de entender

A tentação de investigar primeiro é forte e quase sempre errada. Enquanto você monta a teoria, o invasor continua trabalhando. Conter significa isolar o host, derrubar sessões, revogar credenciais, cortar a integração suspeita — as ações que um serviço de MDR ou SOC gerenciado deveria estar autorizado a executar sem esperar aprovação.

Um cuidado: contenção destrói evidência. Desligar a máquina apaga a memória volátil, que muitas vezes é onde está a resposta. Se o incidente for grave, capture antes de desligar — imagem de disco e dump de memória. Se você não tem quem faça isso, contenha assim mesmo: perder evidência é melhor do que perder mais dados.

Comunicar com o que se tem

O alerta inicial correto é curto e factual:

Detectamos, às [hora], acesso não autorizado a [sistema]. Contenção iniciada às [hora]. Escopo e dados afetados em apuração. Novas informações em [prazo].

Quatro fatos, zero especulação. Não atribua autoria, não estime número de registros afetados e não prometa que "nenhum dado foi vazado" antes de saber — essa frase é a que mais se retrata depois, e cada retratação custa mais credibilidade do que o incidente original.

Investigar e fechar

Escopo, dados afetados, vetor de entrada, tempo de permanência do invasor. O ciclo formal está descrito no NIST SP 800-61, que organiza tudo em preparação, detecção e análise, contenção e erradicação, e atividade pós-incidente.

O relatório final não é burocracia: é o único momento em que a organização aprende. Se ele terminar em "reforçamos os controles", ninguém aprendeu nada.

O que preparar antes, e que ninguém prepara

Cinco itens, todos de custo zero e todos impossíveis de improvisar durante o incidente:

1. A lista de acionamento. Nomes, telefones e ordem. Quem decide desligar o sistema, quem assina a comunicação ao regulador, quem fala com a imprensa, quem avisa os clientes. Uma folha, impressa, fora do sistema que pode estar comprometido.
2. O texto-base de comunicação. Um modelo para o regulador e um para o cliente, com lacunas a preencher. Escrever isso às 4h da manhã produz o que você imagina.
3. A matriz de destinatários. Para cada tipo de incidente, quem precisa ser avisado e em quanto tempo. Se você é regulado, provavelmente são vários — e desenhar o processo uma vez, com os campos de todos, é mais barato do que descobrir isso no meio do fogo.
4. O contato do fornecedor crítico. Número de contrato e canal de emergência do provedor de nuvem, do MDR, do jurídico. Buscar isso no e-mail durante o incidente é perda de tempo que conta no prazo.
5. Um ensaio. Uma hora, uma vez por ano, com o cenário lido em voz alta e as decisões tomadas de mentira. É o exercício de maior retorno em segurança e o que quase ninguém faz. Se a empresa já tem plano de continuidade, o cenário cibernético entra como mais um capítulo.

Uma nota sobre pagar resgate

Vale registrar porque virou item de regulação. As emendas propostas à NIS2 em janeiro de 2026 incluem regras harmonizadas sobre divulgação de pagamento de resgate — ou seja, a Europa caminha para tornar o pagamento algo que se declara, não algo que se esconde.

No Brasil não há regra específica, mas a recomendação técnica é a de sempre: pagar não garante recuperação, financia a próxima campanha e marca a empresa como pagadora. O tema está detalhado no post sobre ransomware, e a decisão precisa estar prevista antes, com o conselho ciente — não ser tomada às pressas por quem está com o sistema parado.

O ponto que fica

A parte difícil da notificação de incidente não é jurídica, é psicológica: exige contar uma história incompleta sobre um fracasso em curso, no pior dia possível, sabendo que ela vai ser lida por quem pode punir.

A regulação europeia resolveu isso escalonando, e é a melhor ideia que existe no assunto — avisa cedo com pouco, detalha depois com tudo. Se o Marco Legal brasileiro copiar só uma coisa da NIS2, que seja essa estrutura, e não o prazo.

Do seu lado, a preparação que importa cabe numa folha de papel. E o melhor momento para escrevê-la é qualquer um que não seja durante o incidente.