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.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.