/

Blog

ISO 27001 e ISO 28000 en Transporte: El Caso Renfe/Adif (2026)

Un ciberataque golpeó a Renfe y Adif sin detener un solo tren. La nueva Ley de Ciberresiliencia de la UE exige reportarlo en 24 horas. Qué controles de ISO 27001 e ISO 28000 debe revisar hoy cualquier operador de transporte o infraestructura crítica.

 

El jueves 24 de septiembre de 2026, Adif (el administrador de la infraestructura ferroviaria de España) detectó actividad inusual en servidores conectados con las redes de Renfe. El ataque, que según Moncloa se ejecutó con apoyo de un sistema de inteligencia artificial, había comenzado días antes en el portal web de Adif y se había extendido de forma progresiva a la infraestructura en la nube de ambas empresas, hasta alcanzar su punto más intenso ese jueves.

Ningún sistema de explotación ferroviaria resultó comprometido. Los trenes siguieron circulando con normalidad. Y sin embargo, dos operadores estatales de un país europeo tuvieron que suspender preventivamente sus sitios web, activar protocolos de respuesta inmediata, aislar los entornos afectados y notificar el incidente al Centro Criptológico Nacional y al Centro Nacional de Inteligencia. Es exactamente el tipo de caso que explica por qué ISO 27001 e ISO 28000 dejaron de ser dos sistemas que las empresas de transporte pueden implementar por separado.

Qué pasó exactamente

Según Moncloa, el ataque expuso alrededor de 500 GB de información: nombres, correos, teléfonos y trayectos de viajeros, datos suficientes para construir campañas de suplantación de identidad dirigidas contra pasajeros específicos. Renfe, por su parte, sostiene que el acceso fue «limitado» y descarta que se hayan filtrado datos de tarjetas de pago (procesados por un proveedor externo) o documentos de identidad. Adif confirmó que sus portales ya están operativos y que el ataque no llegó a ningún sistema vinculado a la circulación de trenes.

La diferencia entre ambas versiones (500 GB según el grupo atacante, acceso «limitado» según las empresas) es, en sí misma, una lección para cualquier organización: cuando el incidente se hace público, la empresa ya no controla completamente el relato, y lo único que puede controlar es qué tan bien puede demostrar, con evidencia, qué sistemas y qué datos estuvieron realmente en riesgo.

No es un caso aislado

Es la tercera vez en menos de dos semanas que un ciberataque con participación de inteligencia artificial golpea a una organización europea o a infraestructura crítica de transporte y logística. A mediados de septiembre, la Agencia Española de Protección de Datos confirmó el primer ciberataque ejecutado de forma autónoma por un agente de IA (caso que desarrollamos en detalle en [[Articulo_Blog_ISO27001_CiberataqueIA_AEPD_Chile_2026-09-27]]). Entre el 22 y el 23 de septiembre, Forbes reportó una campaña que combinó varios modelos de IA para atacar a más de 100 empresas en cinco días. Y en agosto, ya habíamos documentado cómo un ciberataque a los puertos de Carolina del Norte paralizó terminales sin robar un solo contenedor, y cómo los incidentes cibernéticos marítimos globales subieron 103% entre 2024 y 2025.

El patrón que se repite en los cuatro casos es el mismo: el ataque no necesita tocar la operación física para paralizarla. Un portal web, un sistema de tracking o una plataforma en la nube son hoy tan críticos para que un tren, un barco o un camión sigan moviendo carga como el propio vehículo.

La Ley de Ciberresiliencia de la UE: 24 horas para reportar

El 11 de septiembre de 2026 entró en vigor el Reglamento (UE) 2024/2847, conocido como Ley de Ciberresiliencia, con implementación escalonada hasta 2027. Exige a fabricantes, importadores y distribuidores de productos con elementos digitales (software, servicios en la nube, dispositivos IoT, sistemas de IA integrados, vehículos conectados) notificar a las autoridades cualquier vulnerabilidad crítica o incidente grave en un plazo máximo de 24 horas desde su detección, no desde el cierre de la investigación. El INCIBE opera como canal central de notificación en España.

Es un plazo considerablemente más estricto que las 72 horas que exige el RGPD, y también más estricto que el que fija la Ley 21.719 de Chile (que obliga a reportar «por los medios más expeditos posibles y sin dilaciones indebidas», sin fijar una cifra exacta de horas). Para una empresa chilena o latinoamericana que exporta a Europa, tiene filiales allí o depende de proveedores tecnológicos europeos, este reglamento ya es, indirectamente, parte de su propio mapa de cumplimiento.

Qué exige ISO 27001 a un operador de transporte o infraestructura crítica

Con un caso como el de Renfe y Adif sobre la mesa, hay controles concretos del Anexo A de ISO/IEC 27001:2022 que un auditor va a revisar con más atención en cualquier empresa de transporte, logística o infraestructura crítica:

A.5.7, inteligencia de amenazas. El patrón de ataque combinando IA contra portales web e infraestructura en la nube ya no es una hipótesis de futuro. Es información de amenazas que este control exige recolectar y analizar de forma activa, no archivar como noticia curiosa.

A.5.15 y A.8.2, control de acceso y gestión de privilegios. En los tres casos con IA documentados este mes (AEPD, campaña de 100 empresas y Renfe/Adif) el punto de entrada o de escalamiento estuvo relacionado con credenciales o accesos mal segmentados. La autenticación multifactor y el privilegio mínimo siguen siendo la barrera más efectiva y, a la vez, la que con más frecuencia se implementa de forma parcial.

A.8.16, actividades de monitoreo. Un ataque que avanza de un portal web a infraestructura en la nube durante varios días, antes de alcanzar su punto máximo, exige capacidad de detectar movimiento lateral progresivo, no solo firmas de ataques ya conocidos.

A.5.24 a A.5.28, gestión de incidentes de seguridad de la información. Renfe y Adif lograron algo que muchas empresas no logran: contener el ataque antes de que llegara a los sistemas de explotación ferroviaria. Eso no ocurre por improvisación; ocurre porque existe un plan de respuesta con roles y decisiones definidas de antemano, algo que este control exige documentar y probar.

A.5.30, preparación de las TIC para la continuidad del negocio. La separación entre sistemas web/administrativos y sistemas operativos ferroviarios fue, en este caso, lo que evitó que el incidente se convirtiera en una interrupción del servicio. Esa segmentación es, en esencia, lo que este control pide diseñar y mantener.

A.5.31, cumplimiento de requisitos legales, estatutarios, regulatorios y contractuales. El registro de requisitos legales del sistema de gestión de seguridad de la información ya debería incluir, con nombre y fecha, tanto la Ley de Ciberresiliencia de la UE como, para empresas chilenas, la Ley 21.719, que entra en vigencia el 1 de diciembre de 2026.

Qué exige ISO 28000 cuando el riesgo ya no es solo físico

Cuando trabajamos ISO 28000 para el sector transporte en Chile, el foco suele estar en el robo físico de carga: rutas, horarios, bandas organizadas (ver [[Articulo_Blog_ISO28000_RoboRutas_Chile_2026-09-11]]). El caso Renfe/Adif obliga a ampliar ese enfoque. ISO 28000:2022 exige que la evaluación de riesgos de seguridad de la cadena de suministro (cláusula 6.1) cubra toda amenaza relevante para la continuidad de la operación, sea física o cibernética, y que los controles operacionales (cláusula 8.1) y los planes de continuidad y recuperación se diseñen para ambas.

Tres elementos de ISO 28000 son directamente relevantes para un operador de transporte o infraestructura crítica después de este caso:

  • Segmentación como control de seguridad, no solo de TI. Que un ataque a sistemas administrativos no pueda escalar a sistemas de operación (señalización, control de flota, gestión de tráfico) es una decisión de arquitectura que ISO 28000 espera ver reflejada en la evaluación de riesgos de la cadena completa, no solo en un documento de TI.
  • Gobernanza desde la dirección, no delegada solo al área de sistemas. Un incidente que obliga a suspender sitios web, activar protocolos de emergencia y coordinar con organismos de inteligencia nacional es, por definición, una decisión que involucra a la alta dirección, tal como exige la cláusula 5 de la norma.
  • Simulacros probados, no solo planes firmados. La velocidad con la que Renfe y Adif lograron contener el ataque y restablecer sus portales (48 horas) es el tipo de resultado que solo se consigue cuando el plan de continuidad se ensayó antes del incidente real.

El error más común de auditoría

En empresas de transporte y logística, el hallazgo que se repite con más frecuencia es que la seguridad física (control de acceso a instalaciones, patios, flota) y la seguridad de la información (accesos a sistemas, redes, nube) siguen evaluándose como dos riesgos separados, con responsables distintos que no comparten el mismo registro de riesgos ni el mismo plan de respuesta a incidentes. El caso Renfe/Adif muestra exactamente lo contrario: el ataque entró por un canal digital y el control que evitó una crisis mayor fue arquitectónico (la separación entre sistemas), no físico. Un auditor de ISO 27001 o ISO 28000 que revise por separado la matriz de riesgos de «seguridad» y la de «sistemas» está evaluando, en 2026, un modelo de amenaza que ya quedó atrás.

Qué hacer ahora

Primero, verificar que la segmentación entre sistemas administrativos/web y sistemas de operación crítica esté documentada, probada y no solo asumida. Segundo, incorporar al registro de requisitos legales del sistema de gestión tanto la Ley de Ciberresiliencia de la UE (si la empresa exporta, tiene filiales o proveedores europeos) como la Ley 21.719 en Chile. Tercero, revisar si el plan de respuesta a incidentes distingue entre un ataque a sistemas administrativos y uno que amenaza la continuidad operativa, con tiempos y responsables distintos para cada escenario. Cuarto, si la empresa tiene o está evaluando ISO 28000, confirmar que la evaluación de riesgos de la cadena de suministro incluya de forma explícita el riesgo cibernético, no solo el robo físico de carga o mercancía. Quinto, ensayar el plan de continuidad con un simulacro real, no solo revisarlo en papel.

Ningún operador de transporte necesita esperar un incidente propio para actuar. El caso Renfe/Adif es, para cualquier empresa que mueve personas o carga en Chile y Latinoamérica, una vista previa razonable de qué tan rápido puede escalar un ataque que ni siquiera se dirige a la operación física, y de qué tan rápido se puede contener cuando el sistema de gestión ya estaba diseñado para ese escenario.

¿Tu empresa de transporte o logística evalúa el riesgo cibernético y el riesgo físico de su cadena de suministro como un solo sistema, o siguen siendo dos matrices que no se hablan? En Profile Empresarial te ayudamos a integrar ISO 27001 e ISO 28000 en un diagnóstico único para tu operación. Agenda tu diagnóstico con nuestro equipo.

Cesar Laya, Profile Empresarial. Tu Certificación, Nuestro Compromiso.