El problema no es la OT: es que nadie sabe de quién es el incidente

La ciberseguridad industrial tiene un vicio muy humano: cuando aparece una vulnerabilidad seria, todo el mundo reacciona y nadie manda. Seguridad ve riesgo de intrusión, ingeniería ve riesgo de parada, operaciones quiere seguir produciendo y facilities descubre el problema cuando algo crítico deja de responder. El resultado no es sofisticado. Es burocracia con consecuencias físicas.

Por eso tiene bastante más miga de la que parece el webinar que Claroty celebrará el 21 de octubre de 2026 a las 11:00 AM EDT, centrado en cómo construir una RACI de seguridad OT. Sobre el papel, suena a tema de gobierno interno, de esos que muchos directivos aparcan porque no lleva siglas nuevas ni demo vistosa. En la práctica, toca el nervio de casi todas las obligaciones serias que hoy pesan sobre operadores esenciales, fabricantes, utilities, hospitales, transporte y entidades financieras con infraestructura física o dependencia operativa de terceros industriales.

La paradoja es bastante elegante, si se quiere ver así: llevamos años hablando de segmentación, visibilidad, detección, hardening y gestión de vulnerabilidades en entornos OT, pero en demasiadas organizaciones sigue sin estar resuelta la pregunta más básica de todas: quién decide qué se hace, cuándo, con qué criterio y quién asume el riesgo si no se hace. Sin eso, el resto es tecnología a la espera de un atasco organizativo.

Y no, esto no es un detalle menor. El gobierno de responsabilidades ya está metido de lleno en la regulación. NIS2 no pide magia, pide medidas de gestión de riesgos y rendición de cuentas de la dirección. El NIST CSF 2.0 ha puesto la función Govern en la puerta de entrada del marco. IEC 62443 lleva años insistiendo en roles, zonas, conduits y procesos sostenibles. DORA, aunque nació para el sector financiero, ha terminado de normalizar una idea incómoda: si una organización depende de tecnología crítica, la resiliencia no puede descansar en acuerdos informales entre equipos que apenas se soportan.

Un webinar comercial, sí. Pero sobre un problema que sigue sin resolverse

Conviene no disfrazarlo: el evento de BankInfoSecurity es un webinar patrocinado por Claroty, con una duración prevista de 60 minutos. No es una guía oficial de un regulador ni un estándar normativo. Aun así, el ángulo importa porque apunta a un agujero muy real. La propia descripción del evento acierta al identificar la fricción histórica entre IT, OT e incluso facilities. Cuando una vulnerabilidad afecta a un activo operacional, no basta con aplicar el reflejo de TI: escanear, parchear, reiniciar, cerrar puertos y seguir. En un entorno de planta, una acción técnicamente correcta puede causar indisponibilidad, pérdida de producción, problemas de seguridad física o incumplimientos contractuales con clientes.

Eso explica por qué la matriz RACI no es un formalismo de PMO. En OT es, en muchos casos, la única manera de convertir un incidente o una exposición crítica en una secuencia de decisiones trazables. Responsible, Accountable, Consulted, Informed. Cuatro casillas. Nada glamuroso. Pero prueba a gestionar una vulnerabilidad en un PLC o en un servidor HMI sin haber definido antes esas cuatro cosas y verás cuánto tarda en aparecer el caos.

La promesa de Claroty es ofrecer el marco que usa con sus clientes para “establecer propiedad clara, alinear traspasos y hablar un lenguaje común” entre IT y OT. Traducido a castellano llano: ayudar a que no acabe todo en una reunión de emergencia con ocho personas, doce opiniones y ninguna autoridad real para aprobar una mitigación.

La RACI en OT no es una plantilla de Excel: es una decisión de poder

Aquí está el quid. Muchas compañías creen que ya tienen una RACI porque existe un documento con nombres y columnas de colores. Eso no basta. En entornos OT, una RACI solo sirve si refleja quién puede parar, quién puede aceptar una exposición temporal, quién debe validar el impacto operativo y quién activa escalado cuando la ventana de mantenimiento no existe. Si la matriz no aterriza en esas decisiones, es decoración.

El problema de fondo no es semántico, sino político. En TI, el responsable de seguridad suele tener más margen para exigir cambios sobre sistemas corporativos. En OT, la propiedad histórica de los activos suele recaer en ingeniería, producción o mantenimiento. La seguridad llega después y muchas veces como invitada poco deseada. Cuando se descubre una vulnerabilidad con potencial de explotación remota, esas líneas de autoridad chocan.

Un ejemplo clásico: aparece una exposición en un sistema de supervisión conectado a una red industrial. El equipo de ciberseguridad pide aislamiento inmediato. El responsable de planta responde que cualquier cambio no validado puede afectar a la continuidad. El proveedor del sistema exige pruebas previas. El equipo legal quiere saber si existe obligación de notificar si ya hay indicios de compromiso. El CISO pregunta por la criticidad del activo. El director de operaciones pregunta cuánto costará parar. Si tu organización no ha definido por anticipado quién es Accountable y bajo qué umbrales, la discusión no se resuelve técnicamente. Se resuelve por jerarquía, presión o azar. Ninguna de las tres opciones suele ser una gran política de resiliencia.

Por eso una buena RACI en OT no se construye por departamentos, sino por flujos concretos. Vulnerability management. Segmentación. Acceso remoto de terceros. Gestión de cambios. Respuesta a incidentes. Recuperación tras parada. Validación de compensating controls. Aprobación de excepciones. Cada flujo necesita decisiones distintas, tiempos distintos y, muy a menudo, responsables distintos.

Lo que exige NIS2 no cabe en una organización donde nadie decide

Si el lector trabaja en infraestructura crítica o en una entidad esencial o importante sujeta a NIS2, esto ya dejó de ser una preferencia operativa. La Directiva (UE) 2022/2555, conocida como NIS2, aprieta precisamente en los puntos donde una RACI deficiente acaba rompiéndose.

El artículo 20 obliga a los órganos de dirección de las entidades esenciales e importantes a aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad y a seguir formación. No es un detalle ornamental: el legislador europeo quiso dejar por escrito que la responsabilidad no puede quedarse en el departamento técnico. Si la dirección debe aprobar y supervisar, necesita una arquitectura interna de responsabilidades. Si no existe, la aprobación es nominal y la supervisión, teatro.

El artículo 21 concreta medidas mínimas de gestión de riesgos, entre ellas políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, y prácticas de higiene cibernética. Fíjate en la lista y hazte una pregunta incómoda: ¿cuántas de esas medidas pueden ejecutarse con eficacia en un entorno OT si no está decidido de antemano qué área lidera y cuál valida el impacto sobre procesos físicos? La respuesta corta es bastante sencilla: pocas.

También pesa el régimen de notificación. El artículo 23 de NIS2 fija una alerta temprana en 24 horas desde que la entidad tenga conocimiento de un incidente significativo, una notificación en 72 horas y un informe final en el plazo máximo de un mes. En una crisis OT, donde primero hay que averiguar si el problema es técnico, operativo o ya afecta a seguridad física, esos plazos vuelan. Si no existe una RACI para incidentes que vincule SOC, OT, operaciones, legal y dirección, la organización pierde tiempo justo donde el regulador menos paciencia tiene.

La ironía aquí es conocida: muchas empresas invierten fortunas en tecnología de monitorización para detectar eventos en minutos y luego tardan horas en decidir quién puede declarar formalmente el incidente. El adversario no necesita aplaudir. Con esperar le basta.

NIST CSF 2.0 entendió antes que muchos CISO que el gobierno va primero

Otro dato que no conviene pasar por alto: NIST actualizó el Cybersecurity Framework a la versión 2.0 en febrero de 2024 e introdujo una función nueva, Govern, al mismo nivel que Identify, Protect, Detect, Respond y Recover. No fue un retoque cosmético. Fue un reconocimiento bastante explícito de que la ciberseguridad madura depende de gobierno, estrategia, roles, supervisión y cadena de responsabilidad.

Dentro de esa función, el subapartado GV.RR se refiere a roles, responsabilidades y autoridades relacionados con el riesgo de ciberseguridad. Dicho de otro modo: NIST cogió uno de los problemas más aburridos de presentar en un comité ejecutivo y lo colocó en primera línea. Porque sin eso, el resto del marco se queda cojo.

En OT el mensaje es todavía más pertinente. Las organizaciones industriales suelen tener madureces desiguales: puede haber una disciplina sólida de safety, una ingeniería de procesos robusta y, al mismo tiempo, un gobierno muy inmaduro sobre acceso remoto de proveedores, gestión de activos conectados o respuesta coordinada con TI. La función Govern sirve precisamente para ordenar esas zonas grises. Una RACI bien hecha no sustituye al marco, pero lo vuelve ejecutable.

Si quieres una señal de por dónde va el mercado este año, ahí la tienes. Ya no basta con presumir de visibilidad sobre activos OT. Los clientes, los auditores y cada vez más reguladores preguntan quién aprueba las excepciones, quién revisa los riesgos de terceros, quién puede activar una desconexión, quién documenta el residual risk y quién da la cara ante el consejo si algo sale mal.

OT y vulnerabilidades: el parche no siempre es la respuesta, pero alguien tiene que decidirlo

El texto promocional del webinar menciona dos casos prácticos muy reveladores: gestión de vulnerabilidades y segmentación. No es casualidad. Son dos áreas donde la diferencia entre un entorno IT y OT se hace más visible.

En TI, una vulnerabilidad crítica suele activar una cadena bastante automatizada: inventario, priorización CVSS o explotación observada, cambio, ventana, parche, validación. En OT, el análisis exige variables adicionales: ciclo de producción, requisitos del fabricante, compatibilidad con sistemas heredados, ventanas de parada planificadas, impacto en safety instrumented systems, dependencia de terceros y, en ocasiones, certificaciones regulatorias que no admiten modificaciones improvisadas.

Por eso una RACI útil para vulnerabilidades OT debe ir más allá de “seguridad identifica, operaciones ejecuta”. Necesita fijar al menos cinco decisiones:

Primero, quién clasifica la criticidad real del activo, no solo la severidad técnica de la vulnerabilidad. Un CVSS alto en un activo de baja exposición no pesa igual que una vulnerabilidad media en un sistema que afecta a continuidad operacional.

Segundo, quién valida la explotabilidad en ese entorno concreto. En OT abundan vulnerabilidades teóricamente graves cuya explotación práctica depende de condiciones de red, acceso físico o arquitectura que no siempre se cumplen.

Tercero, quién decide si procede parche, mitigación compensatoria o aceptación temporal del riesgo. Esa decisión no puede quedar flotando entre CISO e ingeniería.

Cuarto, quién autoriza cambios que puedan afectar a disponibilidad. Aquí la diferencia entre responsable y accountable importa mucho. El que ejecuta no siempre debe ser el que asume.

Quinto, quién conserva evidencia de la decisión tomada, la razón operativa y la revisión posterior. Sin eso, el aprendizaje desaparece y la auditoría se vuelve una sesión de arqueología corporativa.

La segmentación añade otra capa de complejidad. Aislar redes, limitar flujos o endurecer accesos remotos parece sensato hasta que una regla mal ajustada corta una dependencia operacional que nadie había documentado. Por eso la RACI aquí debe incluir a arquitectura de red, OT, ingeniería de proceso, proveedor del sistema, operaciones y seguridad. Si falta una pieza, la segmentación se convierte en una ruleta.

La cadena de suministro OT es el elefante en la sala

Hay una razón adicional por la que este debate llega en buen momento: la seguridad OT ya no puede analizarse solo dentro del perímetro propio. Acceso remoto de integradores, mantenimiento por terceros, actualizaciones de firmware, proveedores de equipos industriales, plataformas de monitorización y conexiones temporales forman un ecosistema donde la titularidad del riesgo y la capacidad real de intervención rara vez coinciden.

NIS2 vuelve a aparecer aquí. El artículo 21.2.d incluye expresamente la seguridad de la cadena de suministro, incluyendo los aspectos relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. En OT, eso afecta de lleno a integradores de sistemas, OEM, mantenedores y proveedores de acceso remoto. Una RACI pobre deja un hueco clásico: el tercero puede hacer mucho, pero nadie dentro de la organización tiene claramente asignado el deber de autorizar, supervisar y revocar.

Si además el entorno pertenece a sectores regulados por exigencias de resiliencia o seguridad industrial, la situación se complica. Algunos equipos de OT siguen operando bajo la lógica de “el proveedor lo conoce mejor que nadie”. A veces es verdad. Lo que no es verdad es que esa experiencia sustituya a la responsabilidad interna de gobierno. El proveedor puede recomendar. Quien responde ante el regulador eres tú.

Esto conecta también con la filosofía de DORA para el sector financiero, aunque el webinar no vaya de banca. DORA dedica su capítulo V y, en particular, los artículos 28 a 30, a la gestión del riesgo de terceros TIC. La lección extrapolable es obvia: cuando una función crítica depende de un tercero, la entidad no externaliza la responsabilidad. Externaliza parte de la ejecución. Parece un matiz jurídico. En una crisis, es la diferencia entre tener gobierno o tener excusas.

Por qué este tema importa también a banca, seguros y pagos

Puede parecer que una RACI OT es asunto exclusivo de industria pesada, energía o utilities. Sería una lectura cómoda y errónea. En 2026, entidades financieras, aseguradoras y operadores de pagos mantienen dependencias crecientes de infraestructura física y de tecnología operacional en edificios inteligentes, centros de datos, sistemas de climatización, control de acceso, generación de respaldo, logística de efectivo, cajeros, sensores ambientales y redes de facilities conectadas. No todo eso encaja en la definición tradicional de OT industrial, pero sí comparte un patrón: sistemas ciberfísicos donde una decisión de seguridad mal coordinada puede afectar a la continuidad de un servicio crítico.

DORA obliga desde el 17 de enero de 2025 y este año la conversación ya no gira alrededor de “llegar a tiempo”, sino de demostrar que los marcos aprobados son operativos. El artículo 5 atribuye al órgano de dirección la responsabilidad última sobre la gestión del riesgo TIC. El artículo 11 aborda la respuesta y recuperación ante incidentes relacionados con TIC. El artículo 17 exige una clasificación de incidentes graves y amenazas significativas. Todo esto presupone una cadena interna de decisión clara.

Si una interrupción en sistemas de energía, refrigeración o acceso físico afecta a la disponibilidad de servicios financieros, la frontera entre OT, facilities y TIC deja de ser una curiosidad técnica y pasa a ser un problema regulatorio. Muchas entidades han madurado mucho su gobierno sobre aplicaciones y cloud, pero siguen tratando las tecnologías operacionales del edificio o del centro de datos como si fueran un subcontrato de mantenimiento. Hasta que un incidente demuestra que no lo era.

En otras palabras: si tu entidad depende de infraestructura física conectada, una RACI OT ya no es solo un asunto de ingenieros. También es compliance, continuidad y reporting al consejo.

El error más común: diseñar la RACI por organigrama y no por escenario

La peor RACI es la que parece ordenada. Dirección arriba, CISO al lado, operaciones en otra columna, proveedor abajo. Queda muy presentable. Luego ocurre un incidente y el documento no responde a ninguna pregunta útil.

El enfoque correcto parte de escenarios operativos concretos, no del organigrama. Si el webinar de Claroty aporta valor, debería ir justo por ahí. Una RACI OT mínimamente seria necesita modelar al menos estos casos:

Descubrimiento de vulnerabilidad en activo crítico. ¿Quién valida la exposición? ¿Quién decide la mitigación? ¿Quién autoriza una parada no planificada?

Solicitud de acceso remoto por tercero. ¿Quién aprueba? ¿Quién verifica necesidad de negocio? ¿Quién revisa caducidad y trazabilidad? ¿Quién monitoriza la sesión?

Cambio de segmentación o reglas de firewall industrial. ¿Quién diseña? ¿Quién prueba? ¿Quién valida impacto sobre comunicaciones de proceso? ¿Quién mantiene rollback?

Detección de comportamiento anómalo. ¿Quién puede declarar incidente? ¿Quién activa respuesta? ¿Quién evalúa si hay obligación de notificación externa?

Fin de vida de un activo legado sin parche disponible. ¿Quién acepta el riesgo? ¿Con qué controles compensatorios? ¿Durante cuánto tiempo? ¿Con qué revisión periódica?

La diferencia entre una organización madura y otra improvisada se ve aquí. La madura traduce estos escenarios en decisiones, umbrales, evidencias y rutas de escalado. La improvisada espera a que llegue el problema para averiguarlo en directo. Suele ser un formato emocionante. No especialmente recomendable.

Qué debería incluir una RACI OT que merezca ese nombre

No hay un formato único y la estructura depende del sector, tamaño, criticidad y arquitectura. Pero sí hay componentes que, si no aparecen, suelen delatar una RACI insuficiente.

1. Delimitación exacta del alcance

No basta con escribir “entorno OT”. Hay que identificar si cubre planta, building management systems, SCADA, PLC, HMI, historian, acceso remoto, IIoT, sistemas de energía, HVAC crítico, centros de datos o todos ellos. Sin alcance, las responsabilidades se evaporan en la primera excepción.

2. Mapeo de activos y procesos a propietarios reales

Propietario no es sinónimo de administrador técnico. En OT suele haber diferencia entre dueño operacional, soporte técnico, tercero mantenedor y responsable de ciberseguridad. La RACI debe reflejar esa realidad, no simplificarla para que quede bonita en PowerPoint.

3. Umbrales de decisión

Una matriz útil fija qué tipo de decisiones suben de nivel: parada no planificada, desvío de proceso, exposición superior a cierto plazo, acceso de emergencia de tercero, activación de notificación regulatoria o aceptación de riesgo sin parche. Si no hay umbrales, cualquier conflicto acaba en discusión ad hoc.

4. Integración con gestión de incidentes y continuidad

La RACI no puede vivir separada del playbook de incidentes. Debe decir quién convoca el war room, quién mantiene el log de decisiones, quién habla con comunicación, legal, compliance y dirección, y quién aprueba el retorno a operación normal.

5. Gestión documental y evidencia

Esto se olvida mucho. Una RACI seria enlaza con tickets, change records, aprobaciones, actas de riesgo, inventario y excepciones. Si no deja rastro, no sirve ni para auditoría ni para aprender del incidente siguiente.

6. Relación con terceros

El proveedor que mantiene un PLC o un sistema de climatización crítica debe aparecer con tareas concretas, niveles de consulta y límites claros. Y, sobre todo, debe quedar claro quién dentro de la organización controla ese acceso y esa dependencia.

7. Revisión periódica

Las RACI OT caducan deprisa. Cambia un proveedor, se renueva una línea, se migra una planta, se centraliza el SOC, se externaliza facilities y el documento se vuelve ficción. Revisarla una vez al año puede ser insuficiente en entornos de cambio intenso. Tras incidentes relevantes o cambios materiales de arquitectura, la actualización debería ser inmediata.

La objeción habitual: “Esto nos ralentiza”

Siempre aparece. Y tiene algo de verdad, pero no la suficiente. Sí, una RACI bien definida introduce disciplina. Obliga a nombrar responsables, documentar decisiones y aceptar que algunas áreas pierden margen para decidir solas. Puede parecer más lenta que la improvisación. Lo parece hasta que llega una vulnerabilidad crítica o una interrupción real.

La improvisación es rápida solo antes del incidente. Durante el incidente, suele ser un desastre. Una RACI trabajada no elimina la fricción entre IT y OT; la encauza. Reduce discusiones repetitivas, acorta escalados, clarifica excepciones y deja por escrito quién asume el riesgo residual. Eso no es burocracia adicional. Es tiempo ganado cuando más caro resulta perderlo.

La otra objeción es cultural: “OT es distinto, no podemos aplicar modelos de gobierno de IT”. Correcto. No hay que copiarlos. Hay que adaptarlos. Una RACI OT no sirve si ignora safety, validación de ingeniería, mantenimiento, proceso y continuidad operacional. Pero precisamente por eso hace falta diseñarla. Lo que no funciona es seguir sin modelo porque el modelo corporativo de TI no encaja del todo.

Qué deberían preguntar los asistentes al webinar si no quieren salir con lugares comunes

El riesgo de este tipo de sesiones es salir con frases razonables y pocas respuestas accionables. Si el tema te afecta, hay preguntas concretas que merecen plantearse.

Una: cómo distingue Claroty entre “Responsible” y “Accountable” cuando la decisión implica posible impacto en uptime. Esa separación es crítica.

Dos: qué evidencias documentales recomienda conservar para demostrar que una decisión sobre vulnerabilidad, segmentación o acceso remoto fue evaluada y aprobada con criterio.

Tres: cómo integra la RACI con terceros que operan o mantienen activos OT. Mucha teoría interna se cae cuando entra el proveedor.

Cuatro: qué métricas permiten saber si la RACI funciona. Por ejemplo, tiempo desde detección hasta decisión, número de excepciones abiertas, porcentaje de accesos remotos con aprobación formal, revisiones de riesgo caducadas o cambios de segmentación revertidos.

Cinco: cómo alinear la RACI con NIS2, NIST CSF 2.0 o IEC 62443 sin convertirla en una sopa de frameworks que nadie operativo quiera tocar.

Seis: qué hacer con activos legados sin parche, que son el pan de cada día en OT y la tumba de muchas políticas demasiado limpias para el mundo real.

Si el webinar responde bien a esas preguntas, habrá ido bastante más allá del marketing. Si se queda en la idea genérica de “mejorar la colaboración”, será otra hora amable sobre un problema brutalmente concreto.

Mi lectura: la seguridad OT madura cuando deja de fingir que el conflicto no existe

Hay una tentación constante en ciberseguridad industrial: hablar como si IT y OT compartieran objetivos naturales y solo necesitaran “mejor comunicación”. Suena conciliador. También es falso a medias. Los objetivos se solapan, sí, pero no son idénticos. Seguridad quiere reducir exposición. Operaciones quiere continuidad. Ingeniería quiere estabilidad validada. El proveedor quiere intervenir con el menor coste y la menor responsabilidad posible. La dirección quiere no salir en prensa ni ante el regulador. Ese conflicto no es una anomalía. Es la condición normal del entorno.

La madurez empieza cuando la organización admite eso y lo traduce en gobierno explícito. Una RACI OT bien hecha no elimina tensiones. Decide cómo se resuelven antes de que llegue la crisis. Ahí está su valor.

También por eso el tema trasciende la industria pesada. Cualquier organización con tecnología ciberfísica relevante, dependencia operacional de terceros y obligación regulatoria de resiliencia necesita responder a la misma pregunta: quién tiene autoridad para decidir cuando seguridad y disponibilidad chocan. Si no puedes responderla con nombres, umbrales y evidencias, no tienes gobierno. Tienes esperanza. Y la esperanza, como estrategia de ciberseguridad, cotiza fatal.

Qué hacer ahora, antes del 21 de octubre

No hace falta esperar al webinar para saber si tu casa está ordenada o no. Hay una comprobación bastante simple. Coge tu último caso de vulnerabilidad relevante, un cambio sensible de segmentación o un acceso remoto de emergencia de un tercero. Reconstruye la secuencia. ¿Quién detectó? ¿Quién calificó? ¿Quién aprobó? ¿Quién asumió el riesgo? ¿Quién dejó evidencia? ¿Quién revisó la decisión después? Si en alguno de esos puntos la respuesta es “depende”, “se habló” o “lo vio el equipo”, ya tienes diagnóstico.

La buena noticia es que una RACI OT no exige una reestructuración mastodóntica. Exige trabajo incómodo, sí: mapear decisiones reales, exponer vacíos de autoridad, obligar a negocio y operaciones a aceptar su cuota de responsabilidad y vincular la ciberseguridad al lenguaje de continuidad y proceso. No es vistoso. Pero es de lo poco que mejora a la vez cumplimiento, tiempos de respuesta y resiliencia operativa.

El webinar de Claroty, programado para el miércoles 21 de octubre de 2026, puede ser una oportunidad útil si se aborda con ese nivel de exigencia. La clave no es salir con una plantilla. La clave es salir con mejores preguntas para deshacer un problema que demasiadas organizaciones siguen escondiendo detrás de organigramas ambiguos.

Porque el incidente OT más peligroso no siempre es el malware, ni el exploit, ni el tercero con acceso abierto más tiempo del debido. A veces es algo bastante menos cinematográfico: que nadie sepa de quién es la decisión cuando aún se está a tiempo de tomarla.