Przejdź do treści

Notificação de incidentes NIS2 em 24 e 72 horas: procedimento, responsabilidades e exercício de prontidão

19 min czytania Systemy zarządzania

O procedimento de notificação de incidentes nos prazos de 24 e 72 horas não pode começar num formulário nem terminar na responsabilidade do departamento de TI. A sua eficácia depende do momento em que a organização considera ter tomado conhecimento do incidente, de quem avalia o respetivo impacto, de quem toma a decisão e da capacidade de preparar e enviar a notificação mesmo com dados incompletos, pessoas-chave indisponíveis ou sistemas essenciais inoperacionais. A prontidão deve, por isso, ser estruturada como um processo transversal e posteriormente validada através de um exercício realizado sob pressão de tempo.

Por que razão o prazo começa a contar mais cedo do que a gestão normalmente pressupõe

O início da contagem do prazo não deve ficar dependente da confirmação técnica integral nem da transferência do caso para a pessoa autorizada a efetuar a notificação. A organização deve distinguir um evento — uma anomalia ou um alerta observado — de um incidente de segurança com impacto na confidencialidade, integridade, disponibilidade ou autenticidade dos ativos e serviços. Num nível seguinte encontra-se o incidente que cumpre os critérios legais de notificação. Assim, nem todos os alertas acionam os prazos de 24 e 72 horas, mas todos os sinais devem ser classificados segundo critérios previamente definidos.

O maior risco de atraso surge quando o procedimento não define o momento em que a organização toma conhecimento do incidente. A primeira informação pode chegar ao suporte técnico, a um operador de linha, a um administrador, a um prestador de serviços ou ao serviço de apoio ao cliente. Se o prazo apenas começar a ser contado quando um membro da administração ou o coordenador de segurança for informado, cria-se uma lacuna artificial entre a deteção efetiva da perturbação e a resposta formal. O procedimento deve identificar as fontes internas e externas de alerta, os critérios de escalonamento e a função com autoridade para determinar se a ocorrência ultrapassou o limiar de uma avaria corrente.

Se o fornecedor responsável pela manutenção de um sistema de produção comunicar ao suporte uma indisponibilidade acompanhada da suspeita de intervenção externa, a causa, a extensão total e o prazo previsto para reposição podem ainda ser desconhecidos. Isso não justifica aguardar pelo relatório técnico final. Para iniciar o escalonamento são suficientes a hora em que o sinal foi identificado, os serviços e locais afetados, o impacto observado, as consequências possíveis e as medidas de contenção adotadas. Com base nestes elementos, a pessoa autorizada realiza uma avaliação preliminar e documenta a decisão de ativar, ou não, o circuito de notificação.

As etapas das 24 e 72 horas devem ser entendidas como o desenvolvimento progressivo do conhecimento sobre o mesmo incidente: primeiro transmite-se um alerta precoce com base nos elementos disponíveis e, posteriormente, complementa-se a avaliação com conclusões mais precisas. Não se trata de duas obrigações administrativas independentes. Os prazos concretos, os limiares de classificação e os canais aplicáveis devem ser sempre confirmados na legislação nacional em vigor que transpõe a NIS2 e nos requisitos da autoridade competente, em vez de se basear o procedimento exclusivamente na diretiva. A eficácia das soluções adotadas pode ser verificada no âmbito de Auditoria NIS2 numa empresa industrial — como avaliar se a organização está preparada para as novas obrigações.

Onde se perdem as primeiras horas

Frequentemente, as primeiras horas não são consumidas pela análise técnica, mas pela espera. O alerta fica retido no sistema de suporte, não existe um circuito de contacto fora do horário de trabalho, o fornecedor está a preparar um parecer, os departamentos discutem a dimensão do impacto e a pessoa autorizada a decidir está indisponível. A recolha manual de dados provenientes de várias fontes agrava o atraso. O problema concentra-se sobretudo nas interfaces entre tecnologias de informação, tecnologia operacional, produção, qualidade, área jurídica, comunicação, proteção de dados, compras e gestão de topo, porque cada área dispõe apenas de uma parte da informação.

Estrangulamento Consequência Responsável pelo risco Medida preventiva
Alerta sem escalonamento automático Início tardio da classificação Responsável pelo processo de gestão de incidentes Limiares de prioridade e alerta das funções designadas
Ausência de contacto fora do horário de trabalho Espera até ao dia útil seguinte Administração e direção operacional Prevenção, substituições e testes periódicos dos contactos
Espera pela resposta do fornecedor Decisão dependente de um relatório externo Compras e gestor do contrato Prazos contratuais de aviso, âmbito dos dados e disponibilidade de especialistas
Desacordo sobre o impacto ou ausência do decisor Falta de decisão formal Membro autorizado da direção Matriz de classificação, delegações de poderes e substituição
Consolidação manual da informação Visão incoerente do incidente Coordenador do incidente Registo comum de tempos, serviços, locais, consequências e ações

Numa empresa industrial, a perda de acesso ao sistema de planeamento, combinada com a instabilidade de alguns equipamentos, não permite obter de imediato uma visão completa. Pode tratar-se de uma falha em sistemas interdependentes, de uma perturbação da tecnologia operacional ou de um incidente de maior dimensão. A organização deve proteger simultaneamente as operações e a continuidade da produção, identificar os ativos e locais afetados e assegurar o escalonamento. A contenção dos efeitos técnicos não pode aguardar por uma decisão formal, mas a decisão de notificar também não deve ser adiada até à identificação da causa ou à resolução integral da perturbação.

Os estrangulamentos são mais bem identificados através de um exercício baseado em cenários que inclua uma ocorrência noturna e a indisponibilidade de uma pessoa-chave. Devem ser medidos os tempos entre o primeiro sinal e o escalonamento, a classificação, o contacto com o decisor e a recolha do conjunto mínimo de dados. Também é necessário verificar as condições contratuais aplicáveis aos prestadores de serviços de tecnologias da informação e comunicação. O fornecedor pode apoiar a preparação da informação, mas a notificação em nome da organização exige uma base expressa, poderes adequados e conformidade com o procedimento em vigor. A mera manutenção do sistema não transfere a responsabilidade.

A avaliação da prontidão deve abranger toda a organização, e não apenas o departamento de TI: funções, fluxos de informação, fornecedores, tecnologia operacional e gestão de crises. As evidências de funcionamento destes mecanismos devem ser coerentes com o âmbito descrito em Documentação NIS2 e KSC antes de uma inspeção: políticas, registos e evidências efetivamente necessários.

Procedimento desde o primeiro sinal até à notificação

O procedimento deve conduzir o processo desde o primeiro sinal até ao envio documentado, sem condicionar a decisão à conclusão da análise técnica. O fluxo inclui a receção do alerta, o registo da hora e da fonte, a classificação preliminar, a preservação de elementos de prova e a avaliação do impacto no serviço. Seguem-se o escalonamento, a decisão, a preparação da comunicação, o envio pelo canal adequado e a conservação do respetivo comprovativo. Cada etapa exige um responsável, um substituto, um prazo interno e um registo definido. Os prazos internos devem reservar tempo para aprovação e para a resolução de problemas de envio, em vez de coincidirem com o limite legal.

Na primeira fase, até 24 horas, é necessário um conjunto mínimo de informação confirmada: identificação da entidade, momento da deteção, serviço afetado, efeitos observados, extensão conhecida e medidas adotadas. A informação incerta deve ser assinalada como preliminar, identificando-se a respetiva fonte e o método de verificação. A falta de conhecimento sobre a causa, a extensão total ou o momento de conclusão do evento não deve conduzir a uma aparência artificial de completude nem suspender automaticamente a comunicação. O procedimento tem de definir quem aprova a notificação, quem assume essa competência em substituição e como são atualizadas as informações já transmitidas.

Quando uma unidade industrial perde o acesso ao sistema que controla a execução das ordens, o coordenador regista o alerta, a hora da deteção e os relatos dos utilizadores, enquanto a equipa técnica preserva os registos de eventos e limita os efeitos. O responsável pelo serviço avalia o impacto na produção, na logística e nos clientes, ao passo que o decisor determina a obrigação de notificação com base nos dados disponíveis. Se o incidente continuar, o sistema de registo estiver indisponível ou o evento tiver origem num fornecedor, deve ser utilizado o canal alternativo previamente preparado, sem aguardar pelo relatório final. Num grupo com várias sociedades, é necessário determinar separadamente os serviços afetados, a entidade abrangida e os poderes para agir em nome de cada entidade.

Até à etapa das 72 horas, a organização complementa a avaliação da natureza e gravidade do incidente, do seu impacto, dos indicadores de compromisso disponíveis e das medidas de contenção, dentro do âmbito definido pela legislação e pelos formulários atualmente aplicáveis. Se as conclusões posteriores alterarem a dimensão, a causa ou a classificação do evento, a informação anterior deve ser corrigida de forma controlada, e não substituída sem manutenção do histórico. Antes da implementação do procedimento, devem ser verificados a autoridade ou equipa de resposta competente para a categoria da entidade, o canal de notificação, as regras de contagem dos prazos e os requisitos de atualização e comunicação subsequente. O âmbito subjetivo é abordado em maior detalhe em NIS2 para empresas industriais: entidades abrangidas, novas obrigações e preparação da organização sem reduzir o tema exclusivamente às TI.

O fluxo de informação deve assentar num único registo do incidente, contendo a cronologia, as sucessivas versões das conclusões, as fontes dos dados, as decisões e respetiva fundamentação, o conteúdo das comunicações e os comprovativos de envio. O correio eletrónico e as plataformas de mensagens podem ser utilizados para alertar, mas não devem criar versões paralelas da descrição do evento. A prontidão do processo deve ser medida pelo tempo decorrido entre o sinal e o registo, o escalonamento, a decisão e o envio, pela percentagem de entradas com a fonte identificada e pela possibilidade de reconstruir quem alterou a avaliação do incidente e com que fundamento.

Funções, substituições e limiar de decisão

O processo de notificação exige uma separação clara entre tarefas, responsabilidades e autoridades. A pessoa que deteta o evento regista-o e inicia o escalonamento. O coordenador do incidente mantém a cronologia e gere o fluxo de informação, enquanto o especialista técnico avalia a natureza do evento e preserva os dados. O responsável pelo serviço ou processo determina o impacto operacional, a pessoa com competência jurídica avalia a obrigação de comunicação, o aprovador decide sobre a notificação e o colaborador autorizado efetua o envio e conserva a respetiva evidência. Uma pessoa pode acumular várias funções, desde que isso não torne ambígua a autoridade de decisão nem crie um ponto único de dependência.

Uma matriz de responsabilidades só é eficaz quando, além da designação da função, especifica o âmbito da tarefa, o tempo de resposta exigido, a autoridade decisória, o substituto e a evidência esperada da execução. Deve igualmente definir quem pode decidir com informação incompleta e como resolver conflitos entre continuidade da produção, segurança e obrigação de comunicação. A gestão de topo aprova o modelo de resposta, os limiares de escalonamento e os recursos disponíveis. Não pode transferir integralmente o risco decisório para o administrador de sistemas ou para o responsável da qualidade, que normalmente não dispõem de mandato para decidir sobre consequências empresariais e jurídicas.

Nem todas as notificações têm de ser aprovadas por um membro da administração, se o modelo interno de competências prever uma procuração ou autorização adequada, compatível com os requisitos aplicáveis à entidade e ao canal de notificação. A substituição exige a designação nominal da pessoa seguinte, contactos disponíveis 24 horas por dia e uma regra de assunção do processo após o termo, sem sucesso, do prazo interno estabelecido. O substituto deve dispor de acesso efetivo ao registo, ao formulário, à caixa de correio, às assinaturas eletrónicas necessárias e ao canal alternativo. Uma disposição formal no procedimento, sem a concessão das respetivas permissões, não assegura a continuidade operacional.

Se o incidente ocorrer durante a noite, o coordenador não deve aguardar indefinidamente pelo aprovador. Terminado o limite interno de contacto, deve acionar o respetivo substituto e, em seguida, a pessoa autorizada a tomar uma decisão de emergência. Os prazos internos devem ser claramente inferiores aos prazos externos, reservando margem para verificar os dados, proceder à classificação jurídica, obter aprovação, resolver dificuldades técnicas e documentar o envio. Os tempos entre a deteção, o escalonamento, a decisão e a transmissão da notificação devem ser medidos durante os exercícios.

Este modelo exige financiamento para prevenção, acessos, formação e ferramentas, devendo ser considerado no planeamento descrito em Quanto custa implementar a NIS2 e a uKSC — como preparar um orçamento para auditoria, documentação, formação e controlos sem erros dispendiosos. Manter um único decisor ou uma única pessoa com permissões é uma falsa economia: durante um incidente, uma ausência organizacional transforma-se na causa de um atraso formal.

Um exercício que revela o verdadeiro nível de prontidão

A prontidão para notificar um incidente não é demonstrada pelo conhecimento do procedimento, mas pela capacidade de o executar sob pressão de tempo e com informação incompleta. O cenário do exercício deve basear-se na divulgação progressiva de dados. O sinal inicial pode ser ambíguo, parte dos sistemas e da documentação pode estar indisponível, o fornecedor pode responder com atraso e o impacto operacional pode aumentar à medida que chegam novas informações. Esta estrutura permite verificar se a organização consegue iniciar o escalonamento sem aguardar por uma análise técnica integral.

O exercício deve decorrer segundo uma cronologia realista, registando os momentos de receção e registo do sinal, transmissão ao coordenador, convocação da equipa, classificação preliminar, preparação do conteúdo, aprovação e tentativa de envio. A simulação não deve resultar numa notificação real, salvo se tiverem sido previamente acordados um ambiente de teste seguro e um método de identificação dos dados. A participação de entidades externas requer uma decisão específica. É aconselhável envolver o fornecedor quando a sua informação, acesso ou intervenção forem indispensáveis para classificar o incidente. A administração deve participar, pelo menos, numa variante que exija uma decisão de negócio, a aceitação de risco ou a ativação de uma substituição.

Um cenário exemplificativo pode começar com uma comunicação de lentidão no sistema de produção. Em seguida, o facilitador revela a falta de acesso ao registo de eventos, a indisponibilidade da pessoa responsável pela aprovação, dados divergentes sobre o número de processos afetados e a ausência de resposta do fornecedor. Os observadores não dão indicações à equipa; registam os tempos e as evidências reais. Avaliam o tempo necessário para o sinal chegar ao coordenador, a disponibilidade dos substitutos, o número de responsabilidades não esclarecidas, a completude da cronologia, as divergências entre fontes e a possibilidade de utilizar o canal alternativo. Registam também funções sem substituto, permissões em falta e contactos desatualizados.

A avaliação não se pode limitar a verificar se a notificação simulada foi preparada antes do prazo interno. É necessário confirmar se os participantes:

  • distinguiram os factos confirmados das hipóteses,
  • identificaram as fontes de informação,
  • documentaram o fundamento da classificação,
  • assinalaram os dados a complementar posteriormente,
  • ativaram as substituições segundo as regras definidas,
  • conseguiram utilizar o canal alternativo de notificação.

A forma de atuação em condições de incerteza constitui igualmente um resultado importante. A equipa não deve classificar automaticamente todas as perturbações como incidentes sujeitos a notificação, nem suspender o escalonamento até à conclusão de toda a análise técnica.

O exercício deve terminar com um plano de ações corretivas, e não apenas com um relatório. Cada lacuna exige um responsável, um prazo de resolução, um critério mensurável de eficácia e a identificação do elemento que será novamente testado. Deve ser monitorizada a percentagem de ações concluídas e cuja eficácia foi verificada dentro do prazo definido pela organização. A frequência dos exercícios seguintes e a alteração dos cenários são determinadas em função do risco, dos resultados do teste anterior e das mudanças organizacionais. Novas funções, fornecedores, sistemas ou canais de notificação, bem como deficiências relevantes, justificam especialmente um exercício adicional. Estas decisões devem ser coerentes com o calendário descrito em Implementação da NIS2 após a inscrição na lista KSC — plano de ação até 3 de abril de 2027.

O padrão mínimo de prontidão da gestão

A administração só pode considerar o processo de notificação de incidentes operacional depois de aprovar a sua estrutura organizacional completa. Esta inclui o procedimento, os critérios de escalonamento, uma lista de contactos atualizada, funções e substituições atribuídas, acesso aos canais principal e alternativo de notificação, modelos de comunicação, um único registo de incidentes, regras de preservação e conservação de evidências e um exercício realizado. A ausência de qualquer destes elementos deve ser tratada como um risco operacional, e não como uma simples lacuna editorial na documentação.

A evidência de prontidão não é o número de documentos aprovados, mas um rasto coerente do processo: desde a deteção do evento, passando pela classificação e decisão, até à preparação e ao envio da notificação. Esse rasto deve indicar os tempos, as fontes de informação, as pessoas que tomaram as decisões, o fundamento da classificação e o conteúdo transmitido à entidade competente. A organização deve ainda demonstrar que consegue atuar durante a ausência de pessoas-chave, a indisponibilidade dos sistemas principais e o acesso limitado aos dados.

Após o exercício, é necessária uma revisão pela gestão que transforme as conclusões em decisões antes de uma auditoria ou inspeção. O responsável pelo processo pode melhorar a instrução, o registo ou a lista de contactos dentro dos limites da sua autoridade. A administração deve decidir sobre as lacunas que exijam aceitação do risco residual, financiamento de alterações, recursos adicionais ou mudança de responsabilidades. Cada ação requer um responsável, um prazo e uma data para nova verificação da eficácia.

A notificação de incidentes deve integrar um plano de implementação mais amplo, verificando-se sempre a atualidade dos prazos e requisitos. Na avaliação da maturidade, também importa considerar NIS2 e NP EN ISO 27001: o que proporciona o certificado e o que continua a faltar para a conformidade com a KSC. A organização só está preparada quando consegue tomar, executar e demonstrar a decisão adequada dentro de um prazo limitado e com informação incompleta.

Rate this post
Udostępnij:
Ekspert BBQuality

Masz pytania? Porozmawiajmy.

Bezpłatna konsultacja – bez zobowiązań.

Umów konsultację