Un ciberataque ha conseguido elevar hasta los 50 °C la temperatura de los sistemas frigoríficos de cientos de supermercados franceses, provocando pérdidas millonarias. No ha sido necesario atacar sus sistemas financieros ni paralizar sus servidores corporativos. Ha bastado con manipular un sistema técnico conectado.
El incidente demuestra por qué la ciberseguridad ya no puede limitarse a proteger datos y ordenadores. También debe proteger los procesos que permiten funcionar a una empresa. Y es precisamente aquí donde la Directiva NIS2 adquiere todo su sentido.
Qué ha pasado en los supermercados franceses
Durante la noche del 11 al 12 de octubre de 2026, un ciberataque afectó a los sistemas de refrigeración de numerosos supermercados en Francia, entre ellos establecimientos de Intermarché, Netto, Coopérative U y E.Leclerc.
Los atacantes consiguieron manipular a distancia los sistemas de regulación frigorífica, activando procesos de deshielo y elevando las temperaturas hasta los 50 °C. Las consecuencias fueron inmediatas: alimentos frescos y congelados inutilizados, interrupciones operativas, daños en instalaciones y pérdidas económicas que podrían alcanzar varios millones de euros.
Según las primeras informaciones, el incidente afectó a cientos de establecimientos. Las autoridades francesas han abierto una investigación para determinar el alcance del ataque, identificar a sus responsables y esclarecer el mecanismo de acceso.
Las informaciones publicadas apuntan a sistemas de control de refrigeración del fabricante Danfoss y a posibles vulnerabilidades en versiones antiguas del software, pendientes de confirmar. Sin embargo, la investigación continúa y todavía deben esclarecerse los detalles técnicos y las responsabilidades concretas.
En paralelo, se han comunicado incidentes informáticos en las cadenas Albert Heijn, en Países Bajos, y Delhaize, en Bélgica, pertenecientes al grupo Ahold Delhaize. Por el momento no existe una conexión confirmada entre estos incidentes y el ataque francés.
Lo más relevante para cualquier empresa es que el ataque no necesitó comprometer el ERP, la contabilidad o las bases de datos de clientes. El objetivo fueron los sistemas tecnológicos que controlaban un proceso físico esencial para el negocio.
Y eso cambia la forma de entender la ciberseguridad.
Un ejemplo de por qué existe NIS2
Cuando hablamos de ciberataques, solemos pensar en ransomware, robo de información, filtraciones de datos personales o interrupciones de páginas web. Pero ¿qué sucede cuando un ataque informático impide conservar alimentos, detiene una línea de producción, bloquea un sistema de climatización hospitalario o paraliza un almacén automatizado?
En estos casos, el problema ya no es únicamente tecnológico. Se convierte en un problema de continuidad operativa, seguridad y pérdidas económicas.
La Directiva (UE) 2022/2555, conocida como NIS2, busca precisamente elevar la capacidad de las organizaciones para prevenir, resistir y responder a incidentes que comprometan la seguridad de sus redes y sistemas de información y la continuidad de sus servicios.
No sustituye al Reglamento General de Protección de Datos (RGPD), sino que aborda riesgos distintos y complementarios. El RGPD protege los datos personales. NIS2 establece obligaciones de gestión de riesgos de ciberseguridad y notificación de incidentes para determinadas entidades, aunque no exista una filtración de información personal.
El caso francés permite identificar tres aspectos especialmente importantes.
1. La tecnología industrial también forma parte de la ciberseguridad
Los sistemas de refrigeración, climatización, control de accesos, alarmas o automatización industrial forman parte de lo que conocemos como tecnología operacional (OT). Cada vez más, estos equipos están conectados a redes informáticas y pueden administrarse remotamente.
Esto facilita su mantenimiento y permite optimizar costes, pero también introduce nuevas superficies de ataque.
Una empresa puede tener sus servidores protegidos, sus empleados utilizando autenticación multifactor y sus ordenadores actualizados, mientras mantiene un sistema industrial accesible desde Internet con un software obsoleto.
La seguridad del entorno corporativo no garantiza automáticamente la seguridad de sus sistemas operacionales.
2. Los proveedores también forman parte del perímetro de seguridad
Muchas empresas externalizan el mantenimiento de sus instalaciones técnicas. El proveedor de refrigeración, climatización o automatización puede disponer de acceso remoto para supervisar equipos, modificar parámetros o resolver incidencias. Ese acceso puede convertirse en una vía de entrada si no está adecuadamente protegido.
Todavía no se ha determinado públicamente toda la cadena de acceso utilizada en el ataque francés. Pero el incidente ilustra un riesgo conocido: la exposición de sistemas operacionales conectados y la dependencia de tecnologías y servicios de terceros.
El artículo 21.2.d de NIS2 exige a las entidades sujetas a la Directiva adoptar medidas relativas a la seguridad de la cadena de suministro, incluidos los aspectos de seguridad de las relaciones con sus proveedores directos y prestadores de servicios.
Esto implica que contratar a un tercero no elimina la necesidad de gestionar los riesgos asociados a su actividad.
3. Un incidente digital puede tener consecuencias físicas
El elemento más llamativo del ataque es que una instrucción informática terminó destruyendo mercancía. Un sistema de refrigeración debe disponer de controles que eviten operar fuera de condiciones seguras, incluso cuando recibe órdenes incorrectas o maliciosas.
La protección no debería depender exclusivamente del software. En función del sistema, pueden resultar necesarias limitaciones independientes, alarmas, supervisión de temperatura, mecanismos de desconexión y procedimientos de actuación manual.
La ciberseguridad y la seguridad operacional deben trabajar conjuntamente.
La pregunta ya no es solamente si alguien puede entrar en nuestros sistemas, sino qué puede suceder físicamente si consigue hacerlo.
¿Estaría un supermercado español obligado a cumplir NIS2?
Aquí conviene introducir un matiz importante. NIS2 incluye entre sus sectores la producción, transformación y distribución de alimentos, recogida en el Anexo II de la Directiva.
Sin embargo, su ámbito no comprende automáticamente cualquier establecimiento que venda alimentos. El texto europeo se refiere específicamente a empresas alimentarias dedicadas a la distribución mayorista y a la producción y transformación industrial.
Por tanto, un supermercado dedicado exclusivamente al comercio minorista no queda incluido por esa sola actividad.
La situación puede ser diferente para una gran cadena que también desarrolle actividades de distribución mayorista, producción o transformación industrial mediante su propia estructura empresarial. En estos casos, habrá que analizar las actividades reales, las entidades jurídicas involucradas, su dimensión y los criterios de aplicación previstos en la normativa.
No basta con afirmar que una organización es grande o que dispone de centros logísticos para concluir automáticamente que está obligada.
Pero hay otra cuestión incluso más relevante.
NIS2 también afecta indirectamente a empresas que no están obligadas
Imaginemos una empresa de 150 trabajadores especializada en mantenimiento de refrigeración industrial. Sus clientes son grandes operadores logísticos, industrias alimentarias y cadenas de distribución. Aunque esa empresa no esté directamente incluida en NIS2, algunos de sus clientes sí pueden estarlo.
Y esos clientes tendrán que gestionar los riesgos de ciberseguridad de su cadena de suministro. En la práctica, podrán exigirle contractualmente requisitos como:
- Autenticación multifactor para los accesos remotos.
- Identificación y autorización de los técnicos que intervienen.
- Gestión de vulnerabilidades y actualizaciones.
- Registro de accesos y actuaciones.
- Procedimientos de notificación de incidentes.
- Evaluaciones periódicas de seguridad.
- Evidencias de las medidas implantadas.
El resultado es que NIS2 se extiende comercialmente a organizaciones que no están directamente sujetas a la Directiva.
No porque todas adquieran automáticamente las mismas obligaciones legales, sino porque sus clientes necesitan garantías para cumplir las propias. Esta es una de las transformaciones más importantes que introduce NIS2 en las relaciones entre empresas.
NIS2 en España: esperar a la ley no elimina el riesgo
El plazo europeo para transponer NIS2 finalizó el 17 de octubre de 2024.
El 8 de julio de 2026, la Comisión Europea anunció su decisión de llevar a España, Francia, Irlanda y Países Bajos ante el Tribunal de Justicia de la Unión Europea por no haber notificado la transposición completa de la Directiva.
En España, el Gobierno aprobó en enero de 2025 el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, destinado a incorporar NIS2 al ordenamiento jurídico nacional.
A fecha de este artículo, la transposición sigue pendiente de completarse.
Esto no significa que NIS2 pueda exigirse íntegramente a cualquier empresa privada española como si ya existiera una ley nacional de transposición en vigor. Las obligaciones directamente exigibles deben analizarse conforme al marco jurídico aplicable, incluida la normativa de ciberseguridad ya vigente y los compromisos contractuales.
Pero tampoco significa que las empresas deban esperar. Hay tres razones para empezar a prepararse.
Primera: los clientes ya están trasladando exigencias de seguridad a sus proveedores.
Una organización obligada a gestionar su cadena de suministro necesita conocer los riesgos asociados a los servicios que contrata.
Segunda: adaptarse requiere tiempo.
Inventariar activos, evaluar proveedores, revisar accesos remotos, implantar controles, definir procedimientos y formar a los responsables son actividades que no se resuelven en unas semanas.
Esperar a la publicación definitiva de la ley puede convertir una adaptación planificada en un proyecto urgente y costoso.
Tercera: los ciberataques no esperan al BOE.
Los riesgos que pretende reducir NIS2 ya existen. El ataque a los supermercados franceses es un ejemplo de sus consecuencias.
La ausencia de una transposición completa no impide que una empresa sufra mañana un incidente similar.
Tres lecciones prácticas para cualquier empresa
El caso francés permite extraer tres lecciones aplicables tanto a las organizaciones obligadas por NIS2 como a aquellas que quieren mejorar su capacidad de prevención y respuesta.
Lección 1. Tus proveedores con acceso remoto también forman parte de tu perímetro
Una empresa puede disponer de una política de seguridad de proveedores perfectamente redactada y, al mismo tiempo, desconocer cuántas empresas externas pueden conectarse a sus instalaciones.
Pensemos en una fábrica. El proveedor de maquinaria accede remotamente para realizar ajustes. El de climatización supervisa las instalaciones. El mantenedor de alarmas puede modificar configuraciones y otro proveedor administra los sistemas de control de accesos.
Cada una de estas conexiones representa una dependencia y un riesgo potencial.
La organización debería poder responder, para cada proveedor, a cinco preguntas:
- ¿Quién tiene autorización para acceder?
- ¿A qué sistemas puede conectarse?
- ¿Qué mecanismo de autenticación utiliza?
- ¿Cuándo accedió por última vez y qué hizo?
- ¿Quién puede suspender o revocar ese acceso?
No basta con disponer de una relación de proveedores homologados.
Es necesario identificar los accesos, evaluar su criticidad, establecer condiciones de seguridad y revisar periódicamente las autorizaciones.
Para los accesos de mayor riesgo, conviene incorporar autenticación multifactor, privilegios mínimos, registros de actividad, accesos temporales y mecanismos de revocación inmediata.
Una política de proveedores describe cómo debería funcionar el control. La evidencia de los accesos demuestra si realmente funciona.
Lección 2. Si no está en el inventario, difícilmente estará protegido
Muchas organizaciones mantienen inventarios de ordenadores, servidores, aplicaciones y licencias. Pero ¿incluyen también sus cámaras frigoríficas conectadas, sistemas de climatización, controladores industriales, sensores, dispositivos de acceso o equipos de mantenimiento remoto?
Con frecuencia, estos activos dependen de departamentos distintos de informática: mantenimiento, operaciones, producción o servicios generales.
El resultado puede ser una visión incompleta de la superficie de ataque. El primer paso es identificar los activos tecnológicos que intervienen en los procesos críticos del negocio.
Después hay que analizar:
- Qué función desempeñan y qué impacto tendría su indisponibilidad.
- Qué conexiones tienen con otras redes y sistemas.
- Qué proveedores pueden administrarlos.
- Qué vulnerabilidades y dependencias presentan.
- Qué controles existen para limitar sus consecuencias.
En sistemas OT, además, es especialmente importante estudiar la segmentación de redes y los mecanismos de protección independientes.
No todos los equipos pueden actualizarse o protegerse igual que un ordenador convencional. Por eso las medidas deben adaptarse a sus características técnicas y operativas.
En el caso de una cámara frigorífica, por ejemplo, deberían existir mecanismos que permitan detectar temperaturas anómalas, generar alertas y limitar situaciones peligrosas, sin depender exclusivamente del controlador que podría estar comprometido.
El inventario de activos no es un trámite documental. Es el punto de partida para saber qué necesita protección y por qué.
Lección 3. Cuando ocurre un incidente, el reloj empieza a correr
Una de las novedades más conocidas de NIS2 es su sistema de notificación de incidentes significativos.
El artículo 23 establece, para las entidades sujetas y los incidentes que cumplen los criterios de notificación, un procedimiento escalonado.
| Plazo | Actuación |
|---|---|
| 24 horas | Alerta temprana desde que se tiene conocimiento del incidente significativo. |
| 72 horas | Notificación con una evaluación inicial, gravedad, impacto e indicadores disponibles. |
| 1 mes | Informe final, con descripción del incidente, causas probables, medidas adoptadas e impacto. |
El plazo del informe final se calcula, con carácter general, desde la presentación de la notificación de las 72 horas. La Directiva también contempla informes intermedios y supuestos en los que la investigación continúa abierta.
No todos los incidentes deben notificarse conforme a este procedimiento. Es necesario determinar si cumplen los criterios de incidente significativo y atender a las normas aplicables.
Pero el principal problema operativo aparece antes de enviar cualquier notificación. ¿Quién detecta el incidente? ¿Quién evalúa su gravedad? ¿Quién decide si debe notificarse? ¿Quién reúne la información? ¿Quién conserva las evidencias?
Si estas responsabilidades no están definidas previamente, las primeras horas pueden perderse intentando organizar la respuesta.
La organización necesita un procedimiento que permita registrar el incidente, clasificarlo, asignar responsables, controlar los plazos, documentar las decisiones y conservar las evidencias.
Y la responsabilidad no recae exclusivamente en el departamento de informática.
El artículo 20 de NIS2 exige que los órganos de dirección de las entidades sujetas aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación adecuada.
La ciberseguridad deja de ser una cuestión puramente técnica para convertirse también en una responsabilidad de gobierno corporativo.
Checklist: ¿estaría preparada tu empresa para un incidente similar?
Estas seis preguntas permiten realizar una primera revisión de la preparación de una organización.
- Proveedores: ¿Sabemos qué proveedores tienen acceso remoto a nuestros sistemas y qué permisos tiene cada uno?
- Evaluación: ¿Hemos evaluado los riesgos de ciberseguridad de nuestros proveedores críticos durante los últimos 12 meses?
- Activos: ¿Nuestro inventario incluye sistemas OT e IoT, además de servidores, aplicaciones y ordenadores?
- Incidentes: ¿Tenemos un procedimiento que contemple los plazos de 24 horas, 72 horas y un mes cuando resulten aplicables?
- Dirección: ¿La dirección ha aprobado las medidas de gestión de riesgos y supervisa su aplicación?
- Continuidad: ¿Sabemos cómo mantener o recuperar nuestros procesos físicos críticos si falla uno de sus sistemas tecnológicos?
No se trata de obtener seis respuestas afirmativas en un cuestionario. Lo importante es poder demostrar cada respuesta mediante información actualizada, responsables identificados y evidencias verificables.
Porque una empresa puede responder que controla los accesos de sus proveedores, pero no disponer de un registro que permita saber quién se conectó a un sistema durante la madrugada.
Y esa diferencia puede resultar decisiva cuando se produce un incidente.
Del cumplimiento documental al compliance operacional
El ataque a los supermercados franceses demuestra que los riesgos de ciberseguridad pueden materializarse lejos de los sistemas informáticos tradicionales. Una cámara frigorífica, un controlador industrial o un acceso remoto de mantenimiento pueden convertirse en el punto de partida de un incidente con consecuencias económicas y operativas importantes.
NIS2 establece un marco para gestionar estos riesgos, pero disponer de políticas y procedimientos no garantiza por sí solo que estén funcionando. La diferencia está en la ejecución.
No es lo mismo tener una política de evaluación de proveedores que saber cuáles han sido evaluados, cuándo, con qué resultado y qué medidas correctoras siguen pendientes. No es lo mismo disponer de un inventario de activos que conocer qué sistemas críticos dependen de un proveedor externo y qué controles se han implantado.
Y no es lo mismo tener un procedimiento de incidentes que poder demostrar cuándo se detectó uno, quién tomó cada decisión y si se cumplieron los plazos aplicables.
La diferencia entre el compliance documental y el compliance operacional es pasar de decir que cumplimos a poder demostrar cómo cumplimos.
Cómo puede ayudar Ithikios
En Ithikios trabajamos para que las organizaciones puedan gestionar sus obligaciones de compliance mediante procesos definidos, responsables identificados y evidencias verificables.
Nuestro enfoque permite conectar distintas actividades que tradicionalmente se gestionan de forma aislada:
- Third Party Manager: homologación, evaluación y seguimiento de proveedores, incluidos los riesgos asociados a terceros críticos.
- Risk Manager: identificación y evaluación de riesgos, relacionándolos con activos, amenazas y medidas de tratamiento.
- Controls Manager: gestión de controles, responsables, tareas y evidencias, con correspondencias entre marcos como NIS2, ISO 27001 y ENS.
- Incident Manager: registro, clasificación y seguimiento de incidentes, con asignación de responsables, plazos y trazabilidad de las actuaciones.
Estas capacidades ayudan a organizar y demostrar la gestión del cumplimiento, aunque no sustituyen las soluciones técnicas de ciberseguridad ni los mecanismos específicos de continuidad operacional. El objetivo es que las medidas de seguridad no se queden únicamente en documentos, sino que formen parte del funcionamiento cotidiano de la organización.
Porque, después de un incidente, la pregunta importante no será solamente si existía una política de seguridad. Será si alguien sabía quién podía acceder al sistema, qué controles se habían aplicado y qué ocurrió exactamente a las tres de la madrugada.
Eso es compliance operacional: personas responsables, procesos definidos y evidencias de lo que realmente se hace.
Descubre cómo gestionar el cumplimiento de NIS2, ISO 27001 y ENS con Ithikios: https://ithikios.com/compliance/
* Artículo mejorado con IA
