Una planta puede confiar en su ciberseguridad y, aun así, no saber cuánto tardaría en recuperar la producción si pierde una identidad administrativa, el servidor de recetas o la comunicación con su integrador. La resiliencia industrial empieza cuando esa confianza se convierte en evidencia: dependencias conocidas, responsabilidades claras y una recuperación que puede ejecutarse de forma segura.
Dos publicaciones recientes ayudan a plantear esa conversación. Rockwell Automation difundió el 22 de septiembre de 2026 resultados de su informe global sobre fabricación inteligente. Un día antes, NIST publicó el borrador inicial de la revisión 4 de su guía de seguridad de tecnología operacional. Son documentos distintos: una encuesta empresarial y una propuesta técnica abierta a comentarios. Ninguno demuestra por sí solo el estado de una fábrica colombiana o mexicana.
Para organizaciones industriales de Colombia, México y otros mercados latinoamericanos, su utilidad consiste en revisar una exposición concreta: la conexión entre sistemas corporativos y operaciones físicas. Este artículo propone preguntas y evidencias para esa revisión, sin atribuir incidentes locales ni presentar el borrador como una obligación normativa.
Qué aportan las dos publicaciones
En el estudio divulgado por Rockwell, el 46 % de las organizaciones encuestadas declaró haber experimentado un incidente de ciberseguridad durante el último año, mientras el 90 % expresó confianza en su capacidad de prevención, contención y recuperación. Son respuestas de una muestra industrial global, no tasas de incidencia para Colombia, México o toda Latinoamérica. Tampoco equivalen a resultados de pruebas independientes sobre cada organización.
La lectura útil es la distancia que puede existir entre percepción y comprobación. Una compañía puede haber invertido, disponer de herramientas y sentirse preparada, pero necesitar todavía un ejercicio que demuestre quién puede detener un acceso remoto, qué configuración debe restaurarse y quién autoriza la vuelta a operación.
NIST, por su parte, publicó el 21 de septiembre el borrador inicial de SP 800-82 revisión 4. El documento amplía y actualiza orientación para entornos operacionales, incorpora la relación con CSF 2.0 y mantiene la atención sobre restricciones de seguridad física, disponibilidad y funcionamiento. La revisión 3 continúa siendo la edición final publicada; la revisión 4 está sujeta a cambios.
La pregunta inicial: de qué depende producir
La convergencia IT/OT conecta aplicaciones empresariales, redes, identidades y procesos físicos. Puede facilitar mantenimiento, trazabilidad y análisis, pero también crea dependencias que atraviesan departamentos. El problema no se resuelve dibujando una frontera ideal entre oficina y planta: hay que identificar las conexiones que realmente existen y las funciones que cumplen.
Una línea puede depender de instrucciones de producción alojadas en un servidor, de una cuenta de proveedor o de una estación que conserva la única copia utilizable de una configuración. Esos ejemplos describen situaciones que deben investigarse; no implican que todas las plantas tengan la misma arquitectura.
Conviene empezar por un proceso relevante y seguirlo de extremo a extremo: pedido, planificación, receta o instrucción, ejecución, control de calidad y despacho. Para cada paso, anote qué información utiliza, qué equipo interviene, qué persona lo administra y qué sucede si la dependencia queda inaccesible. Ese recorrido suele producir una lista más útil que un inventario aislado de dispositivos.
Una matriz pequeña para ordenar la conversación
La siguiente matriz es una recomendación de trabajo, no un resultado del estudio. Puede utilizarse en una reunión conjunta de operaciones, tecnología, mantenimiento y seguridad para elegir qué evidencia obtener primero.
| Dependencia | Pregunta de decisión | Evidencia útil |
|---|---|---|
| Identidades y acceso remoto | ¿Podemos retirar un acceso sin perder soporte esencial? | Cuentas nominativas, responsables y procedimiento de revocación probado |
| Configuraciones y recetas | ¿Podemos reconstruir el estado autorizado? | Copias protegidas, versiones y prueba de recuperación compatible |
| Comunicación entre redes | ¿Qué conexión necesita realmente cada proceso? | Flujos documentados y reglas revisadas con operaciones |
| Equipos con restricciones | ¿Qué controles son viables mientras llega una ventana de cambio? | Limitaciones del fabricante, controles compensatorios y fecha de revisión |
| Retorno a producción | ¿Quién confirma que reiniciar es seguro? | Criterios de aceptación, responsables y registro de la decisión |
No intente completar toda la planta en la primera sesión. Seleccione una dependencia cuyo fallo pueda detener un producto importante o generar una condición insegura. Registre los vacíos con un propietario y una fecha; una celda sin evidencia es una tarea pendiente, no un control aprobado.
Revisar el acceso de proveedores sin improvisar
El soporte remoto merece atención porque combina necesidad operativa y privilegios. Primero hay que saber qué proveedores acceden, a qué activos, con qué identidad y bajo qué autorización. Una cuenta compartida que nadie reconoce dificulta tanto una investigación como una suspensión selectiva del acceso.
La revisión debe considerar ventanas de uso, permisos mínimos, autenticación compatible con la arquitectura y registros disponibles. También debe definir qué sucede cuando termina un contrato, cambia el técnico o se detecta actividad inesperada. El responsable de compras o mantenimiento puede conocer relaciones de soporte que no aparecen en el inventario corporativo.
No elimine conexiones a ciegas. Una dependencia desconocida puede ser esencial para operar o recuperar un equipo. El cambio debe acordarse con operaciones, contar con respaldo de configuración y prever una reversión segura. La urgencia comercial no reemplaza la evaluación de impacto sobre el proceso físico.
Recuperar archivos no equivale a recuperar producción
Una copia de seguridad de datos puede ser necesaria y resultar insuficiente. La recuperación industrial puede necesitar software compatible, licencias, configuraciones, versiones, instrucciones de fabricante, disponibilidad de personal y verificación de condiciones físicas. Si esos elementos están separados, la organización debe saber cómo reunirlos durante una interrupción.
La prueba debe partir de un escenario autorizado y acotado. Por ejemplo, comprobar en un entorno compatible que una configuración puede restaurarse y que existe documentación suficiente para validar su integridad. No se recomienda ensayar cambios directamente sobre una línea activa sin diseño previo, autorización y participación de especialistas del entorno.
Defina también el orden de recuperación. Restablecer una estación antes de recuperar su servicio de identidad o su comunicación puede no aportar valor. El objetivo de tiempo de recuperación debe relacionarse con el proceso completo y sus restricciones, no únicamente con el arranque de una máquina virtual.
Por último, establezca quién acepta el retorno a operación. Tecnología puede confirmar disponibilidad informática; operaciones y los responsables de seguridad física deben confirmar que el proceso está en condiciones de funcionar. Esa decisión conjunta debe quedar documentada.
Qué exigir a un diagnóstico inicial
Un diagnóstico útil debe producir un mapa comprensible de dependencias, brechas priorizadas y decisiones con responsables. Pregunte qué información necesita el equipo evaluador, cómo protegerá la continuidad y qué actividades quedan excluidas. Una evaluación documental o de gobierno no equivale a una prueba técnica exhaustiva de controladores industriales.
Solicite que el informe distinga hechos observados, información declarada y aspectos no comprobados. También que separe una vulnerabilidad técnica de una debilidad de procedimiento: ambas pueden importar, pero requieren acciones y validaciones diferentes. La severidad debe considerar el impacto operativo y las restricciones del activo.
Evite contratar únicamente una lista de hallazgos. El entregable debe ayudar a elegir qué corregir ahora, qué requiere una parada programada y qué riesgo necesita aceptación temporal. Esa clasificación permite discutir presupuesto y producción con el mismo contexto.
La responsabilidad también forma parte del control
Cuando una brecha cruza departamentos, puede quedarse sin dueño. Tecnología administra una red, mantenimiento gestiona un proveedor y producción decide cuándo detener la línea. Si ninguna función coordina esas decisiones, incluso una recomendación correcta puede permanecer meses sin ejecutarse.
Una dirección de seguridad debe traducir el riesgo técnico en decisiones de negocio, organizar prioridades y dar seguimiento a excepciones. El servicio de CISO as a Service de Insylux puede incorporarse a esa conversación de gobierno, según el alcance acordado. No sustituye al responsable operativo ni convierte automáticamente al proveedor en especialista de cada tecnología industrial.
Para sostener el trabajo, el servicio de SGSI de Insylux conecta políticas, riesgos, evidencias y revisión periódica. La utilidad está en que las decisiones se mantengan cuando cambian personas, proveedores o proyectos; una documentación extensa sin aplicación no demuestra resiliencia.
Un primer mes con resultados verificables
Primera semana: seleccione un proceso crítico y convoque a quienes lo conocen. Reúna arquitectura disponible, contratos de soporte, cuentas relevantes y procedimientos de recuperación. Identifique qué información falta antes de proponer herramientas o cambios.
Segunda semana: documente dependencias y accesos. Revise de forma autorizada las evidencias disponibles, evitando exploraciones activas que puedan alterar equipos sensibles. Priorice una pequeña lista de decisiones que reduzcan exposición o mejoren capacidad de respuesta.
Tercera semana: prepare un ejercicio de mesa. Plantee una pérdida de acceso o una indisponibilidad concreta y compruebe a quién se llama, qué se aísla, qué evidencia se conserva y quién decide. Registre los desacuerdos y vacíos como acciones, no como fallos personales.
Cuarta semana: acuerde responsables, fechas y condiciones de cierre. Una acción solo se considera resuelta cuando existe evidencia suficiente: acceso revocado, respaldo recuperable, procedimiento aprobado o dependencia documentada. Los cambios técnicos deben seguir su propio proceso de seguridad y autorización.
Preguntas para dirección y operaciones
¿El nuevo borrador de NIST es obligatorio en Colombia o México?
La publicación de un borrador técnico de NIST no crea por sí misma una obligación legal local. Puede servir como referencia de trabajo. Las obligaciones aplicables deben revisarse según actividad, contratos y jurisdicción, distinguiendo orientación técnica de exigencia normativa.
¿Podemos aplicar el mismo escaneo que usamos en oficinas?
No debe asumirse que una técnica es segura para todos los activos operacionales. La compatibilidad, las restricciones del fabricante y el impacto físico deben evaluarse antes de cualquier prueba. Un primer diagnóstico puede empezar por documentación, entrevistas y evidencia pasiva autorizada.
¿Hace falta sustituir todos los equipos antiguos?
No es una conclusión automática. Primero hay que conocer riesgo, soporte y alternativas. Puede ser necesario combinar restricciones de acceso, segmentación, supervisión, recuperación y un plan de sustitución. Los controles compensatorios deben tener responsables y revisarse; no son una excepción indefinida.
Convierta una dependencia crítica en un plan de trabajo
Fuentes y límites de esta lectura
- Rockwell Automation: resultados globales sobre fabricación inteligente, comunicado del 22 de septiembre de 2026. Encuesta de percepción y experiencia declarada; no diagnóstico de empresas latinoamericanas.
- NIST SP 800-82 revisión 4, borrador inicial, publicado el 21 de septiembre de 2026. Documento abierto a comentarios, todavía no final.
- NIST SP 800-82 revisión 3, edición final de septiembre de 2023, como referencia para distinguir versiones.
La matriz y el plan de trabajo son recomendaciones editoriales de Insylux. No describen incidentes, clientes ni instalaciones reales de la marca y no sustituyen un análisis técnico del entorno.
