Notificação de incidentes NIS2 em WordPress: 24 horas, 72 horas, um mês
O artigo 23.º da Diretiva 2022/2555 define como funciona, na prática, a notificação de incidentes. O artigo 21.º trata da gestão de riscos em contínuo; o artigo 23.º trata da notificação de um incidente significativo. As três fases contam a partir do momento em que a entidade tomou conhecimento de um incidente significativo. Um alerta em bruto não é automaticamente um incidente sujeito a notificação.
Este é um artigo de apoio dentro do pilar NIS2 e DORA para WordPress.
Resumo
- O relógio começa quando se toma conhecimento de um incidente significativo, não quando termina a análise da causa.
- 24 horas: alerta precoce, presumível causa maliciosa, indicador transfronteiriço.
- 72 horas: notificação completa com avaliação inicial e indicadores.
- Um mês: relatório final com tipo de ameaça, medidas de mitigação e impacto transfronteiriço.
- Nem todos os alertas ou incidentes de WordPress têm de ser notificados; é preciso avaliar a significância e registar a decisão.
A partir de quando conta o prazo de notificação NIS2
A pergunta-chave é quando a entidade tomou conhecimento do incidente significativo. O simples disparo de um alerta técnico não resolve a questão de forma automática. Ainda assim, a organização não pode adiar à vontade o momento do conhecimento com uma fila por tratar ou sem um circuito de escalamento.
Num site WordPress, isto significa normalmente:
- Uma ferramenta de monitorização (Wordfence, Sucuri, IDS do alojamento, alerta da Cloudflare, pico de erros no Sentry) assinala uma anomalia.
- O engenheiro de prevenção faz a triagem do alerta e avalia o âmbito.
- Se a avaliação ultrapassar o limiar de significância do artigo 23.º, n.º 3, regista-se o momento em que a entidade tomou conhecimento do incidente e o prazo conta a partir daí.
O erro a evitar: um júnior faz a triagem de uma vaga de credential stuffing às 23:50, despacha-a como “ruído normal” e deixa o assunto para a manhã seguinte. Se essa vaga era de facto uma fuga de credenciais com acesso confirmado a uma conta, o relógio das 24 horas corre desde as 23:50. O regulador vai reconstituí-lo a partir dos registos.
O que inclui o alerta precoce NIS2 no prazo de 24 horas
Conteúdo exigido pelo artigo 23.º, n.º 4, alínea a):
- Se há suspeita de que o incidente foi causado por um ato ilícito ou malicioso.
- Se o incidente pode ter impacto transfronteiriço.
É curto. O alerta precoce não é uma análise de causa, é uma sinalização. A CSIRT ou a autoridade competente precisa de saber que algo significativo está a acontecer; os pormenores seguem na notificação das 72 horas.
O papel da agência WordPress dentro das 24 horas:
- Confirmar o âmbito do incidente com base em registos, alertas e análise forense do painel de administração.
- Entregar à equipa de compliance do cliente um rascunho de uma página do alerta precoce, com o nome do serviço afetado, a categoria suspeita (maliciosa ou operacional) e o elemento transfronteiriço (site multilingue, clientela em toda a Europa).
- Preservar as provas: registos do servidor, cronologia das atualizações de plugins, histórico de logins de administração, registo de auditoria do alojamento. Um snapshot da base de dados, se for viável.
- Estancar a hemorragia: rotação de credenciais, bloqueio de IP, isolamento de plugins suspeitos, modo só de leitura quando o incidente atinge o checkout ou os pagamentos.
O alerta precoce não deve incluir especulação sobre atribuição. “Suspeita de origem maliciosa” chega; identificar o agente é trabalho para especialistas forenses.
O que inclui a notificação de incidente NIS2 às 72 horas
Conteúdo exigido pelo artigo 23.º, n.º 4, alínea b):
- Uma avaliação inicial do incidente, incluindo a gravidade e o impacto.
- Indicadores de comprometimento, quando disponíveis.
A linguagem da gravidade importa. A ENISA trabalha com três níveis: baixo, médio e alto. Um incidente de WordPress que deixou o site offline menos de uma hora sem fuga de dados é, no máximo, médio. Uma fuga de credenciais confirmada com acesso a contas de clientes é alto. A desfiguração de um site de marketing sem acesso adicional é baixo ou médio.
A entrega da agência dentro das 72 horas:
- Uma cronologia escrita do incidente com marcas temporais retiradas dos registos.
- Uma avaliação sobre se foram afetados dados de clientes, dados de pagamento ou dados de sessão.
- Indicadores de comprometimento: IP de origem, user agents, hashes de ficheiros em caso de malware, ficheiros de plugins ou do tema alterados, contas de administração suspeitas criadas durante o incidente.
- Uma primeira lista das medidas tomadas: credenciais rodadas, plugin removido ou atualizado, regra de WAF adicionada, auditoria das contas de administração.
É aqui que a maioria dos incidentes de WordPress ganha o seu nome nos arquivos do regulador. A notificação das 72 horas é mais tarde comparada com o relatório final.
O que deve conter o relatório final NIS2
Conteúdo exigido pelo artigo 23.º, n.º 4, alínea c):
- Uma descrição pormenorizada do incidente, da gravidade e do impacto.
- O tipo de ameaça ou a causa de origem.
- As medidas de mitigação aplicadas e em curso.
- O impacto transfronteiriço, quando aplicável.
Até ao fim do mês, a agência WordPress deve ter:
- Uma análise completa da causa de origem. Um plugin vulnerável? Uma fuga de credenciais? Uma má configuração do servidor? Um administrador comprometido por phishing?
- Prova de que a correção imediata funciona e está estável. Regra de WAF ativa, plugin atualizado em produção, credenciais rodadas, MFA obrigatório, monitorização afinada.
- Uma lista de medidas de longo prazo. Atualização da política de plugins, remoção de dependências sem manutenção, auditoria periódica de credenciais, formação dos editores que podem ser alvo de phishing.
- Um parágrafo de confirmação que o cliente possa encaminhar ao regulador.
Se o incidente ainda estiver em curso quando o relatório final for devido, o artigo 23.º, n.º 4, alínea d), prevê um relatório de progresso e, depois, um relatório final no prazo de um mês após o fim da gestão do incidente. Se novas provas alterarem a avaliação, o responsável pela notificação deve documentar a alteração e acordar os passos seguintes com a autoridade competente; a diretiva não descreve uma notificação autónoma “sem medidas”.
De que documentos de resposta a incidentes precisa uma agência WordPress
Seis artefactos que qualquer contrato WordPress regulado deve ter antes do primeiro incidente:
- Runbook de resposta a incidentes com responsável nomeado, circuito de escalamento e modelos para 24/72/30 dias.
- Lista de contactos da CSIRT e das autoridades para a jurisdição do cliente e para as jurisdições transfronteiriças relevantes.
- Modelo de comunicação para os clientes afetados em caso de acesso confirmado a dados.
- Política de preservação de provas: retenção de registos, integridade das cópias de segurança, notas de cadeia de custódia.
- Biblioteca de linguagem de notificação: formulações pré-aprovadas para “suspeita de origem maliciosa”, “sem exposição de dados de clientes”, “vulnerabilidade corrigida”, “monitorização afinada”. Poupa 30 minutos dentro da janela das 24 horas.
- Calendário de simulacros: pelo menos um exercício de mesa por trimestre que percorra 24/72/30 sem um incidente real.
Esta caixa de ferramentas é a diferença entre uma janela de 24 horas que produz um alerta precoce sereno de uma página e uma janela de 24 horas que produz um telefonema em pânico para o departamento jurídico às 03:00.
Quando um incidente é significativo segundo a NIS2
Os três níveis devem ter registos separados. Um evento é um facto observável, por exemplo uma série de logins falhados, o disparo de uma regra de WAF ou um deploy falhado. Um incidente compromete ou pode comprometer a disponibilidade, a autenticidade, a integridade ou a confidencialidade de dados ou serviços. Na avaliação da significância, o artigo 23.º, n.º 3, refere, entre outros, a perturbação operacional grave ou as perdas financeiras para a entidade e os danos materiais ou imateriais consideráveis a terceiros.
A equipa WordPress fornece os factos. O responsável autorizado do lado da entidade toma a decisão jurídica e regulatória. O registo de decisões deve mostrar o primeiro alerta credível, o momento em que a pessoa responsável tomou conhecimento dele, o impacto conhecido no serviço e nos clientes, as provas disponíveis, a avaliação de significância, quem aprovou e a próxima data de revisão. Registam-se tanto a decisão de notificar como a decisão fundamentada de não notificar.
Um site multilingue, utilizadores na UE ou uma suspeita de atividade maliciosa não provam, por si só, a significância. Por outro lado, um comprometimento aparentemente pequeno de um plugin pode ser significativo se interromper o serviço da entidade ou afetar muitas contas de clientes. A transposição nacional, as orientações da autoridade e o contexto setorial podem concretizar o limiar, pelo que o caminho certo é confirmado pelo departamento jurídico ou de compliance do cliente.
Que provas exige cada fase da notificação NIS2
O alerta precoce precisa de um identificador fixo, do nome da entidade e do serviço, do momento em que se tomou conhecimento do incidente, da base atual para a significância, da suspeita de causa ilícita ou maliciosa e do possível impacto transfronteiriço. A incerteza é assinalada às claras. “Em investigação” é melhor do que uma atribuição sem provas.
Até às 72 horas, reúne-se a cronologia, os ambientes e funções afetados, a duração observada, o impacto em clientes e operações, os tipos de dados possivelmente envolvidos, os indicadores de comprometimento, o isolamento já feito e a exposição atual. Cada facto recebe o estado confirmado, inferido ou desconhecido. A cronologia principal usa UTC e mantém o fuso horário original junto de cada fonte.
O relatório final acrescenta a análise de causa desenvolvida, a gravidade e o impacto, o tipo de ameaça, se for conhecido, as medidas executadas e planeadas e eventuais efeitos transfronteiriços. Cada afirmação é ligada a um registo, a um ticket, a uma alteração, a uma nota de investigação ou a uma decisão identificada. Os originais das provas ficam, sempre que possível, só de leitura, e a recolha, a exportação e a entrega são registadas. Este rasto dá reprodutibilidade, mas não significa que todas as agências façam informática forense formal.
Quem notifica o incidente NIS2 e quem responde por quê
O fornecedor de monitorização ou alojamento comunica o alerta e preserva os dados técnicos. Quem responde pelo WordPress limita o impacto na aplicação e constrói a cronologia factual. O incident commander garante a coordenação, para que a correção não destrua provas. O responsável pelo serviço avalia o impacto operacional. A equipa de segurança ou de investigação conduz a análise. O departamento jurídico, de compliance ou o interlocutor regulatório decide o canal e envia a notificação. A comunicação trata das mensagens para clientes e para o público, se forem necessárias.
Cada função precisa de um responsável e de um substituto. Os contratos com fornecedores definem contactos, escalamento fora do horário de trabalho e o prazo de entrega dos registos. Uma passagem de testemunho só está concluída quando a receção é confirmada, os factos e as incógnitas estão anexados e o próximo prazo está indicado. A agência não deve notificar a autoridade em nome do cliente sem mandato inequívoco e procedimento acordado.
Como fazer um exercício de mesa de notificação de incidentes NIS2
Um bom exercício de mesa começa com um alerta ambíguo, não com uma intrusão confirmada. A equipa regista o momento do conhecimento, avalia a significância, pede ao fornecedor as provas em falta, prepara o alerta precoce e atualiza-o para a fase das 72 horas. Mais tarde surge informação nova, por exemplo uma conta de cliente comprometida ou um subcontratado noutro Estado. Vale também a pena treinar um relatório de progresso para um incidente que continua ativo ao fim de um mês.
Depois do exercício, mede-se o tempo de triagem, de decisão, de preservação de provas, de passagem ao jurídico e de preparação do rascunho. Registos em falta, contactos desatualizados, um portal da autoridade indisponível e relógios contraditórios entram numa lista de ações com responsável e prazo. A seguir, testa-se de novo a passagem que falhou. A frequência dos exercícios decorre da avaliação de risco da entidade; um ritmo trimestral não é uma exigência universal da diretiva.
Como verificar a notificação NIS2 antes de a enviar
Cada rascunho deve passar por uma verificação rápida a quatro olhos, sem bloquear o prazo. A pessoa técnica confirma a cronologia, os nomes dos sistemas, os indicadores e o estado do isolamento. O responsável pelo serviço verifica o impacto operacional e nos clientes. O responsável pela notificação confirma o destinatário, a base, a decisão sobre a significância e a aprovação. A atribuição, o volume de dados e o alcance geográfico só se apresentam como confirmados quando há prova.
O número de versão, a hora de aprovação e o conteúdo efetivamente enviado vão para o processo do incidente. Os anexos são verificados quanto a dados sensíveis e segredos desnecessários. O comprovativo de receção do portal ou da autoridade fica guardado com a versão enviada. Perguntas posteriores mantêm o mesmo identificador e alimentam a cronologia comum.
A necessidade de uma correção posterior não justifica atrasar o alerta precoce. Ainda assim, as afirmações anteriores não são sobrescritas sem rasto. O registo mostra a alteração, o motivo e a nova prova. Um versionamento controlado permite atualizar a avaliação e, ao mesmo tempo, preservar um retrato fiel do que se sabia em cada prazo.
Login de administrador WordPress não autorizado e notificação NIS2
Às 09:10, o alojamento comunica um login bem-sucedido de administrador WordPress a partir de uma rede desconhecida e, logo a seguir, a instalação de um plugin. A equipa tem um evento e uma suspeita de segurança credível, mas ainda poucos dados para considerar o incidente significativo. A pessoa de prevenção abre um único registo, preserva os registos do alojamento e do sistema de identidades, bloqueia a conta pelo circuito aprovado e pergunta ao responsável pelo serviço se houve alterações em funcionalidades disponíveis para os clientes.
Às 09:35, confirma-se que a conta pertencia a um antigo prestador externo e que o plugin criou um endpoint de exportação não autorizado. O registo de exportação está incompleto. O incident commander anota os novos factos, o momento de conhecimento mais cedo que se consegue defender e as perguntas: o endpoint foi chamado, que registos estavam acessíveis, quanto tempo durou o acesso e se as mesmas credenciais foram usadas noutro ambiente. O compliance avalia os critérios do artigo 23.º, n.º 3, pelo impacto operacional e pelo dano possível. A mera presença de código malicioso não é tratada automaticamente como limiar de significância.
Se os registos do WAF e da aplicação mostrarem ausência de chamadas, ausência de interrupção do serviço e ausência de acesso fora do ambiente de testes, o responsável autorizado pode concluir, de forma fundamentada, que o limiar não foi atingido. A monitorização continua e fica registada uma avaliação paralela de proteção de dados. Se mais tarde surgirem pedidos em produção ou contas de clientes, a decisão é reaberta sem apagar o retrato anterior das provas.
Na segunda variante, os registos confirmam a chamada ao endpoint em produção e uma interrupção para os clientes durante o isolamento. A equipa regista quando a entidade teve factos suficientes para tomar conhecimento de um incidente significativo, prepara o alerta precoce sem esperar pela atribuição completa e mantém o mesmo registo de provas até à fase das 72 horas. O exemplo mostra que o conhecimento é uma decisão controlada e assente em factos, não uma marca temporal escolhida para dar um prazo cómodo.
Como documentar a cadeia de custódia dos registos de incidentes
Cada entrega indica o identificador do incidente, o sistema de origem, o período abrangido, quem recolheu, a hora da recolha, o fuso horário original, a soma de integridade, se for usada, o local de armazenamento, as restrições de acesso e a confirmação de receção. O destinatário regista também se o material chega para a decisão pedida. Uma captura de ecrã pode mostrar um alerta, mas para reconstituir a sequência e o âmbito costuma ser necessária uma exportação de registos ou um registo do fornecedor.
Se o fornecedor não entregar os dados antes de uma fase de notificação, o rascunho descreve o que foi pedido, quando, a quem e como a falta afeta a avaliação. Assim, um registo ausente não se transforma num pressuposto escondido. O pedido fica em aberto depois do envio, e um resultado relevante segue para o responsável pela notificação, que decide se há atualização.
Quando está uma empresa preparada para notificar incidentes NIS2
A preparação pode ser dada como concluída quando existe uma matriz de significância aprovada, decisores e substitutos, contactos atualizados das autoridades, fontes de prova sincronizadas, modelos testados, um circuito de escalamento confirmado com o fornecedor e um resultado de exercício datado. Todas as fases usam o mesmo identificador e a mesma cronologia, para não criar versões concorrentes dos factos.
Este processo não torna notificável qualquer incidente de segurança, não toma pela entidade a decisão jurídica sobre a significância e não garante que a autoridade concorde com a avaliação inicial. Também não substitui a avaliação paralela de uma violação de dados pessoais ao abrigo do RGPD nem as obrigações setoriais. Prazos e destinatários diferentes exigem circuitos de decisão coordenados.
Para definir o âmbito de uma revisão de preparação, envie um briefing escrito com a entidade e o setor, as jurisdições, o papel do WordPress, as fontes de monitorização, os fornecedores, as funções atuais em incidentes, os canais de notificação e o histórico de exercícios. Uma auditoria de conformidade UE para WordPress pode então organizar o ponto de decisão, as provas, as passagens de testemunho, os modelos e o plano de exercícios, sem apresentar o resultado como certificação jurídica.
Como proteger os registos do WordPress como prova para a NIS2
O artigo 23.º da NIS2 exige expressamente que o material enviado à CSIRT seja verificável e cronologicamente coerente:
- Repositórios de registos imutáveis (WORM): Num ataque avançado, os atacantes tentam de imediato apagar os ficheiros
access.loglocais e as tabelas da base de dados do WordPress. O envio de eventos em tempo real para um SIEM externo (por exemplo Wazuh, Datadog ou AWS CloudWatch) garante que os registos de autenticação e de chamadas à API ficam intactos. - Somas de verificação criptográficas do material de prova: Cada exportação de registos ou cópia da base de dados entregue às equipas de investigação deve ter uma soma SHA-256 calculada e anotada no auto de entrega. Isto protege a organização contra acusações de manipulação de dados.
Notificação NIS2 e notificação de violação à autoridade de proteção de dados
Quando um incidente de cibersegurança envolve acesso não autorizado a dados pessoais:
- Prazos processuais diferentes: O relógio do alerta precoce NIS2 exige a primeira notificação em 24 horas, enquanto o artigo 33.º do RGPD prevê 72 horas para notificar a violação à autoridade de controlo de proteção de dados (na Polónia, o UODO).
- Coerência das declarações perante os reguladores: As equipas jurídica e técnica têm de acertar em conjunto o conteúdo dos dois documentos. Declarar no relatório NIS2 uma fuga da base de dados de clientes e, ao mesmo tempo, ocultar esse facto à autoridade de proteção de dados expõe a administração da empresa a coimas pesadas e a responsabilidade pessoal.
O que documentar antes de enviar o relatório final NIS2
Antes da entrega formal do relatório final (ao fim de 30 dias), deve estar reunido o pacote completo de documentação:
- Lista documentada de medidas corretivas: Um levantamento pormenorizado dos tokens de sessão invalidados, das chaves de autenticação (SALT) rodadas no
wp-config.phpe dos scripts maliciosos removidos. - Análise de causa de origem (Root Cause Analysis): Um relatório técnico independente que explique o vetor exato da intrusão (por exemplo, uma vulnerabilidade de SQL Injection num plugin desatualizado ou uma fuga de credenciais no posto de trabalho de um colaborador).
- Ata de informação à administração: Confirmação de que as principais conclusões do incidente foram apresentadas à gestão da empresa, o que cumpre diretamente o requisito de responsabilidade pessoal dos órgãos de gestão do artigo 20.º da NIS2.
- Síntese: Um processo maduro de resposta a incidentes transforma uma crise de segurança numa prova de elevada resiliência operacional e de profissionalismo de toda a organização.
Uma gestão rigorosa da segurança da informação e a supervisão contínua da infraestrutura tecnológica garantem estabilidade ao negócio e conformidade com normas europeias exigentes. Responsabilidade e precisão protegem os ativos e a reputação da empresa em todas as fases.
A maturidade em cibersegurança é a base de um sucesso duradouro no mercado europeu.
