Um ciberataque conseguiu elevar a temperatura dos sistemas de refrigeração de centenas de supermercados franceses até aos 50 °C, causando prejuízos na ordem dos milhões. Não foi preciso atacar os seus sistemas financeiros nem paralisar os seus servidores corporativos. Bastou manipular um sistema técnico ligado à rede.
Este incidente mostra porque é que a cibersegurança já não se pode limitar a proteger dados e computadores. Também tem de proteger os processos que permitem que uma empresa funcione. E é precisamente aqui que a Diretiva NIS2 ganha todo o seu sentido.
O que aconteceu nos supermercados franceses
Durante a noite de 11 para 12 de outubro de 2026, um ciberataque afetou os sistemas de refrigeração de vários supermercados em França, incluindo lojas da Intermarché, Netto, Coopérative U e E.Leclerc.
Os atacantes conseguiram manipular à distância os sistemas de regulação da refrigeração, ativando processos de descongelação e elevando as temperaturas até aos 50 °C. As consequências foram imediatas: alimentos frescos e congelados inutilizados, interrupções operacionais, danos nas instalações e prejuízos económicos que podem chegar a vários milhões de euros.
Segundo as primeiras informações, o incidente afetou centenas de estabelecimentos. As autoridades francesas abriram uma investigação para determinar a dimensão do ataque, identificar os responsáveis e esclarecer como foi possível o acesso.
As informações publicadas apontam para sistemas de controlo de refrigeração da fabricante Danfoss e para possíveis vulnerabilidades em versões antigas do software, ainda por confirmar. No entanto, a investigação continua e ainda é preciso esclarecer os detalhes técnicos e as responsabilidades concretas.
Ao mesmo tempo, foram comunicados incidentes informáticos nas cadeias Albert Heijn, na Holanda, e Delhaize, na Bélgica, que fazem parte do grupo Ahold Delhaize. Por enquanto, não há nenhuma ligação confirmada entre estes incidentes e o ataque francês.
O mais importante para qualquer empresa é que o ataque não precisou de comprometer o ERP, a contabilidade ou as bases de dados de clientes. O alvo foram os sistemas tecnológicos que controlavam um processo físico essencial para o negócio.
E isso muda a forma como entendemos a cibersegurança.
Um exemplo do porquê de existir a NIS2
Quando falamos de ciberataques, costumamos pensar em ransomware, roubo de informação, fugas de dados pessoais ou interrupções em sites. Mas o que acontece quando um ciberataque impede a conservação de alimentos, interrompe uma linha de produção, bloqueia um sistema de climatização num hospital ou paralisa um armazém automatizado?
Nestes casos, o problema já não é apenas tecnológico. Torna-se um problema de continuidade operacional, segurança e prejuízos económicos.
A Diretiva (UE) 2022/2555, conhecida como NIS2, visa precisamente reforçar a capacidade das organizações para prevenir, resistir e responder a incidentes que comprometam a segurança das suas redes e sistemas de informação e a continuidade dos seus serviços.
Não substitui o Regulamento Geral sobre a Proteção de Dados (RGPD), mas aborda riscos diferentes e complementares. O RGPD protege os dados pessoais. A NIS2 estabelece obrigações em matéria de gestão de riscos de cibersegurança e notificação de incidentes para determinadas entidades, mesmo que não haja uma fuga de informações pessoais.
O caso francês permite identificar três aspetos especialmente importantes.
1. A tecnologia industrial também faz parte da cibersegurança
Os sistemas de refrigeração, climatização, controlo de acessos, alarmes ou automação industrial fazem parte do que conhecemos como tecnologia operacional (OT). Cada vez mais, estes equipamentos estão ligados a redes informáticas e podem ser geridos remotamente.
Isto facilita a sua manutenção e permite otimizar os custos, mas também cria novas vulnerabilidades.
Uma empresa pode ter os seus servidores protegidos, os seus funcionários a usar autenticação multifator e os seus computadores atualizados, mas, ao mesmo tempo, manter um sistema industrial acessível pela Internet com software obsoleto.
A segurança do ambiente corporativo não garante automaticamente a segurança dos seus sistemas operacionais.
2. Os fornecedores também fazem parte do perímetro de segurança
Muitas empresas externalizam a manutenção das suas instalações técnicas. O fornecedor de refrigeração, climatização ou automação pode ter acesso remoto para monitorizar equipamentos, alterar parâmetros ou resolver incidências. Esse acesso pode tornar-se uma porta de entrada se não estiver devidamente protegido.
Ainda não foi divulgada publicamente toda a cadeia de acesso utilizada no ataque francês. Mas o incidente ilustra um risco já conhecido: a exposição de sistemas operacionais interligados e a dependência de tecnologias e serviços de terceiros.
O artigo 21.º, n.º 2, alínea d), da NIS2 exige que as entidades abrangidas pela diretiva adotem medidas relativas à segurança da cadeia de abastecimento, incluindo os aspetos de segurança das relações com os seus fornecedores diretos e prestadores de serviços.
Isto significa que contratar um terceiro não elimina a necessidade de gerir os riscos associados à sua atividade.
3. Um incidente digital pode ter consequências físicas
O que mais chama a atenção neste ataque é o facto de uma instrução informática ter acabado por destruir mercadoria. Um sistema de refrigeração tem de ter controlos que impeçam o seu funcionamento fora das condições de segurança, mesmo quando recebe ordens incorretas ou maliciosas.
A proteção não devia depender exclusivamente do software. Dependendo do sistema, podem ser necessárias limitações independentes, alarmes, monitorização da temperatura, mecanismos de desligamento e procedimentos de intervenção manual.
A cibersegurança e a segurança operacional têm de trabalhar em conjunto.
A questão já não é só se alguém consegue entrar nos nossos sistemas, mas sim o que pode acontecer fisicamente se isso acontecer.
Um supermercado espanhol seria obrigado a cumprir a NIS2?
Aqui, é importante fazer uma distinção importante. A NIS2 inclui, entre os seus setores, a produção, transformação e distribuição de alimentos, tal como consta do Anexo II da diretiva.
No entanto, o seu âmbito de aplicação não abrange automaticamente qualquer estabelecimento que venda alimentos. O texto europeu refere-se especificamente às empresas do setor alimentar dedicadas à distribuição grossista e à produção e transformação industrial.
Por isso, um supermercado dedicado exclusivamente ao comércio a retalho não é abrangido apenas por essa atividade.
A situação pode ser diferente no caso de uma grande cadeia que também desenvolva atividades de distribuição grossista, produção ou transformação industrial através da sua própria estrutura empresarial. Nestes casos, será preciso analisar as atividades reais, as entidades jurídicas envolvidas, a sua dimensão e os critérios de aplicação previstos na regulamentação.
Não basta dizer que uma organização é grande ou que tem centros logísticos para concluir automaticamente que está obrigada a isso.
Mas há outra questão ainda mais importante.
A NIS2 também afeta indiretamente as empresas que não estão sujeitas a essas obrigações
Imaginemos uma empresa com 150 trabalhadores especializada na manutenção de sistemas de refrigeração industrial. Os seus clientes são grandes operadores logísticos, indústrias alimentares e cadeias de distribuição. Mesmo que essa empresa não esteja diretamente abrangida pela NIS2, alguns dos seus clientes podem estar.
E esses clientes vão ter de gerir os riscos de cibersegurança da sua cadeia de abastecimento. Na prática, podem exigir-lhe contratualmente requisitos como:
- Autenticação multifator para acessos remotos.
- Identificação e autorização dos técnicos envolvidos.
- Gestão de vulnerabilidades e atualizações.
- Registo de acessos e ações.
- Procedimentos de notificação de incidentes.
- Avaliações periódicas de segurança.
- Comprovativos das medidas implementadas.
O resultado é que o NIS2 é aplicado comercialmente a organizações que não estão diretamente sujeitas à diretiva.
Não porque todas assumam automaticamente as mesmas obrigações legais, mas porque os seus clientes precisam de garantias para cumprir as suas próprias obrigações. Esta é uma das transformações mais importantes que a NIS2 introduz nas relações entre empresas.
NIS2 em Espanha: esperar pela lei não elimina o risco
O prazo europeu para a transposição da NIS2 terminou a 17 de outubro de 2024.
A 8 de julho de 2026, a Comissão Europeia anunciou a sua decisão de levar a Espanha, a França, a Irlanda e os Países Baixos ao Tribunal de Justiça da União Europeia por não terem notificado a transposição completa da diretiva.
Em Espanha, o Governo aprovou, em janeiro de 2025, o anteprojeto de Lei de Coordenação e Governação da Cibersegurança, destinado a incorporar a NIS2 no ordenamento jurídico nacional.
À data deste artigo, a transposição ainda está por concluir.
Isto não significa que a NIS2 possa ser exigida na íntegra a qualquer empresa privada espanhola, como se já existisse uma lei nacional de transposição em vigor. As obrigações diretamente exigíveis devem ser analisadas de acordo com o quadro jurídico aplicável, incluindo a regulamentação de cibersegurança já em vigor e os compromissos contratuais.
Mas isso também não quer dizer que as empresas devam ficar à espera. Há três razões para começarem a preparar-se.
Primeiro: os clientes já estão a impor requisitos de segurança aos seus fornecedores.
Uma organização que tenha de gerir a sua cadeia de abastecimento precisa de conhecer os riscos associados aos serviços que contrata.
Segundo: adaptar-se leva tempo.
Fazer o inventário dos ativos, avaliar fornecedores, rever os acessos remotos, implementar controlos, definir procedimentos e formar os responsáveis são atividades que não se resolvem em poucas semanas.
Esperar pela publicação definitiva da lei pode transformar uma adaptação planeada num projeto urgente e dispendioso.
Terceiro: os ciberataques não esperam pelo BOE.
Os riscos que a NIS2 pretende reduzir já existem. O ataque aos supermercados franceses é um exemplo das suas consequências.
A falta de uma transposição completa não impede que uma empresa venha a sofrer amanhã um incidente semelhante.
Três lições práticas para qualquer empresa
O caso francês permite retirar três lições aplicáveis tanto às organizações sujeitas à NIS2 como àquelas que querem melhorar a sua capacidade de prevenção e resposta.
Lição 1. Os teus fornecedores com acesso remoto também fazem parte do teu perímetro
Uma empresa pode ter uma política de segurança de fornecedores perfeitamente elaborada e, ao mesmo tempo, não saber quantas empresas externas podem ligar-se às suas instalações.
Pensemos numa fábrica. O fornecedor de maquinaria acede remotamente para fazer ajustes. O responsável pela climatização supervisiona as instalações. O técnico de alarmes pode alterar as configurações e outro fornecedor gere os sistemas de controlo de acessos.
Cada uma destas ligações representa uma dependência e um risco potencial.
A organização devia conseguir responder, para cada fornecedor, a cinco perguntas:
- Quem tem autorização para aceder?
- A que sistemas é que se pode ligar?
- Que mecanismo de autenticação usa?
- Quando foi a última vez que acedeu e o que fez?
- Quem pode suspender ou revogar esse acesso?
Não basta ter uma lista de fornecedores aprovados.
É preciso identificar os acessos, avaliar a sua importância, definir condições de segurança e rever periodicamente as autorizações.
Para os acessos de maior risco, convém incorporar autenticação multifator, privilégios mínimos, registos de atividade, acessos temporários e mecanismos de revogação imediata.
Uma política de fornecedores descreve como o controlo deve funcionar. Os registos de acesso mostram se isso funciona mesmo.
Lição 2. Se não estiver no inventário, dificilmente estará protegido
Muitas organizações mantêm inventários de computadores, servidores, aplicações e licenças. Mas será que também incluem as suas câmaras frigoríficas conectadas, sistemas de climatização, controladores industriais, sensores, dispositivos de acesso ou equipamentos de manutenção remota?
Muitas vezes, estes ativos dependem de departamentos que não são o de informática: manutenção, operações, produção ou serviços gerais.
O resultado pode ser uma visão incompleta da superfície de ataque. O primeiro passo é identificar os ativos tecnológicos envolvidos nos processos críticos do negócio.
Depois, é preciso analisar:
- Que função desempenham e que impacto teria a sua indisponibilidade.
- Que ligações têm com outras redes e sistemas.
- Que fornecedores podem geri-los.
- Que vulnerabilidades e dependências apresentam.
- Que controlos existem para limitar as suas consequências.
Nos sistemas OT, além disso, é especialmente importante analisar a segmentação das redes e os mecanismos de proteção independentes.
Nem todos os equipamentos podem ser atualizados ou protegidos da mesma forma que um computador convencional. Por isso, as medidas têm de ser adaptadas às suas características técnicas e operacionais.
No caso de uma câmara frigorífica, por exemplo, deviam existir mecanismos que permitissem detetar temperaturas anormais, gerar alertas e limitar situações perigosas, sem depender exclusivamente do controlador, que poderia estar comprometido.
O inventário de ativos não é só uma formalidade burocrática. É o ponto de partida para saberes o que precisa de proteção e porquê.
Lição 3. Quando ocorre um incidente, o relógio começa a contar
Uma das novidades mais conhecidas da NIS2 é o seu sistema de notificação de incidentes significativos.
O artigo 23.º estabelece, para as entidades abrangidas e para os incidentes que cumprem os critérios de notificação, um procedimento por etapas.
| Prazo | Ação |
|---|---|
| 24 horas | Alerta precoce assim que se tiver conhecimento do incidente significativo. |
| 72 horas | Notificação com uma avaliação inicial, gravidade, impacto e indicadores disponíveis. |
| 1 mês | Relatório final, com descrição do incidente, causas prováveis, medidas tomadas e impacto. |
O prazo para o relatório final é, em geral, calculado a partir da apresentação da notificação das 72 horas. A diretiva também prevê relatórios intermédios e casos em que a investigação continua em aberto.
Nem todos os incidentes têm de ser notificados de acordo com este procedimento. É preciso verificar se cumprem os critérios de incidente significativo e ter em conta as regras aplicáveis.
Mas o principal problema operacional surge antes mesmo de se enviar qualquer notificação. Quem deteta o incidente? Quem avalia a sua gravidade? Quem decide se deve ser notificado? Quem reúne a informação? Quem guarda as provas?
Se essas responsabilidades não estiverem definidas de antemão, as primeiras horas podem ser desperdiçadas a tentar organizar a resposta.
A organização precisa de um procedimento que permita registar o incidente, classificá-lo, atribuir responsabilidades, controlar os prazos, documentar as decisões e guardar as provas.
E a responsabilidade não recai exclusivamente sobre o departamento de informática.
O artigo 20.º da NIS2 exige que os órgãos de direção das entidades abrangidas aprovem as medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação adequada.
A cibersegurança deixa de ser uma questão puramente técnica para se tornar também uma responsabilidade da governança corporativa.
Lista de verificação: a tua empresa estaria preparada para um incidente semelhante?
Estas seis perguntas permitem fazer uma primeira avaliação do grau de preparação de uma organização.
- Fornecedores: Sabemos quais os fornecedores que têm acesso remoto aos nossos sistemas e quais são as permissões de cada um?
- Avaliação: Já avaliámos os riscos de cibersegurança dos nossos fornecedores críticos nos últimos 12 meses?
- Ativos: O nosso inventário inclui sistemas OT e IoT, além de servidores, aplicações e computadores?
- Incidentes: Temos um procedimento que preveja prazos de 24 horas, 72 horas e um mês, quando aplicável?
- Direção: A direção aprovou as medidas de gestão de riscos e supervisiona a sua aplicação?
- Continuidade: Sabemos como manter ou recuperar os nossos processos físicos críticos caso um dos nossos sistemas tecnológicos falhe?
Não se trata de conseguir seis respostas afirmativas num questionário. O importante é conseguir comprovar cada resposta com informações atualizadas, responsáveis identificados e provas verificáveis.
Porque uma empresa pode dizer que controla o acesso dos seus fornecedores, mas não ter um registo que permita saber quem se ligou a um sistema de madrugada.
E essa diferença pode ser decisiva quando ocorre um incidente.
Da conformidade documental à conformidade operacional
O ataque aos supermercados franceses mostra que os riscos de cibersegurança podem surgir longe dos sistemas informáticos tradicionais. Uma câmara frigorífica, um controlador industrial ou um acesso remoto para manutenção podem tornar-se o ponto de partida de um incidente com consequências económicas e operacionais significativas.
A NIS2 estabelece um quadro para gerir estes riscos, mas ter políticas e procedimentos não garante, por si só, que estejam a funcionar. A diferença está na execução.
Não é a mesma coisa ter uma política de avaliação de fornecedores do que saber quais foram avaliados, quando, com que resultado e que medidas corretivas ainda estão pendentes. Não é a mesma coisa ter um inventário de ativos do que saber quais os sistemas críticos que dependem de um fornecedor externo e que controlos foram implementados.
E não é a mesma coisa ter um procedimento para incidentes e poder demonstrar quando foi detetado um, quem tomou cada decisão e se os prazos aplicáveis foram cumpridos.
A diferença entre a conformidade documental e a conformidade operacional é passar de dizer que cumprimos para conseguirmos demonstrar como é que cumprimos.
Como é que a Ithikios pode ajudar
Na Ithikios, trabalhamos para que as organizações possam gerir as suas obrigações de conformidade através de processos definidos, responsáveis identificados e provas verificáveis.
A nossa abordagem permite ligar diferentes atividades que, tradicionalmente, são geridas de forma isolada:
- Gestor de Terceiros: homologação, avaliação e acompanhamento de fornecedores, incluindo os riscos associados a terceiros críticos.
- Gestor de Risco: identificação e avaliação de riscos, relacionando-os com ativos, ameaças e medidas de tratamento.
- Gestor de Controlos: gestão de controlos, responsáveis, tarefas e evidências, com correspondências entre quadros normativos como o NIS2, a ISO 27001 e a ENS.
- Gestor de Incidentes: registo, classificação e acompanhamento de incidentes, com atribuição de responsáveis, prazos e rastreabilidade das ações.
Estas capacidades ajudam a organizar e a demonstrar a gestão da conformidade, embora não substituam as soluções técnicas de cibersegurança nem os mecanismos específicos de continuidade operacional. O objetivo é que as medidas de segurança não fiquem apenas no papel, mas façam parte do funcionamento quotidiano da organização.
Porque, depois de um incidente, a questão importante não vai ser só se havia uma política de segurança. Vai ser se alguém sabia quem podia aceder ao sistema, que controlos tinham sido aplicados e o que aconteceu exatamente às três da madrugada.
É isso que é conformidade operacional: pessoas responsáveis, processos definidos e provas do que realmente se faz.
Descobre como gerir a conformidade com a NIS2, a ISO 27001 e a ENS com a Ithikios: https://ithikios.com/compliance/
* Artigo melhorado com IA
