Una carpeta con proyectos de control y fechas recientes puede dar tranquilidad hasta que alguien necesita recuperar un activo y descubre que faltan la versión compatible del software, una licencia o el cable de ingeniería. La pregunta útil no es solo «¿hay una copia?», sino «¿podría el equipo autorizado reconstruir, verificar y devolver a servicio la función prevista dentro de las condiciones de seguridad de esta planta?».
Esa respuesta se obtiene antes de la urgencia, mediante un inventario completo y pruebas acotadas.
NIST publicó en junio de 2026 una guía breve específica para copias OT. Recomienda ligarlas a los procesos de gestión de cambios y riesgos, priorizar activos según criticidad, considerar dependencias y probar restauraciones en sistemas que no sean de producción. NIST SP 1339, págs. 1 y 2.
Esta guía convierte esas ideas en un método de preparación y documentación de evidencias; no enseña a cargar lógica en un PLC, escribir en una HMI ni intervenir una línea. La operación y las decisiones de recuperación siguen en manos de las personas responsables y de los procedimientos aprobados de la instalación.
Una copia no equivale a capacidad de recuperación
Una copia responde a una pregunta limitada: ¿se conservó una versión de ciertos archivos o datos?
La capacidad de recuperación añade más preguntas: ¿se identifica el activo al que pertenece?, ¿se puede leer el medio?, ¿se dispone del software y de las credenciales autorizadas?, ¿la versión conserva relaciones con el resto de la celda?, ¿hay personal y repuestos compatibles?, ¿y quién valida la función antes de que el activo vuelva a formar parte de la operación?
La guía OT de NIST trata la recuperación como una restauración que debe considerar el estado del sistema y las consecuencias físicas. Advierte que devolver variables de estado a valores iniciales o anteriores puede alterar un proceso que siga en marcha; la pertinencia de un estado depende del sistema concreto. NIST SP 800-82 Rev. 3, §F.7.6, control CP-10, p. 251.
NIST SP 1339, más reciente y específica sobre copias OT, recomienda probar restauraciones en sistemas no productivos y validar la integridad funcional del sistema recuperado. NIST SP 1339, p. 2.
Registra cada avance por separado:
- Copia creada: existe un conjunto guardado y asociado a una fuente identificada.
- Copia verificable: hay evidencia de que el contenido almacenado coincide con el contenido esperado y sigue accesible.
- Recuperación ensayada: el conjunto se pudo recuperar dentro del alcance de prueba y pasó comprobaciones funcionales previamente acordadas.
Un control de integridad, como un hash, ayuda con la segunda pregunta. No responde por sí solo si las herramientas, el equipo, la licencia, el manual o la secuencia de validación están disponibles. NIST SP 1339 recomienda guardar procedimientos para usar hashes antes de la restauración y realizar pruebas recurrentes fuera de producción; ambas son comprobaciones diferentes. NIST SP 1339, p. 2.
CISA también recomienda ensayar periódicamente las copias y mantenerlas aisladas de conexiones que puedan propagar malware. CISA, FBI y NSA, recomendaciones para sistemas OT/ICS.
El objetivo tampoco es prometer que toda la planta volverá a su condición anterior en un tiempo fijo. Una prueba demuestra lo que se ensayó, para una configuración y un alcance declarados. Si se cambian versiones, componentes, herramientas o relaciones entre sistemas, la evidencia anterior puede dejar de representar el entorno actual.
Haz inventario de lo que permite reconstruir la función
Empieza por los activos que sostienen operaciones y contienen configuraciones importantes. NIST SP 1339 menciona PLC, conmutadores, cortafuegos, transmisores, actuadores, DCS, servidores SCADA, variadores de frecuencia y HMI. También recomienda usar la criticidad para definir la frecuencia, el periodo de retención y la secuencia de recuperación. La lista es un punto de partida: cada planta debe contrastarla con su propio inventario y proceso. NIST SP 1339, p. 1.
Para cada activo, documenta qué elementos hacen falta para reconstruir su función. La guía incluye archivos de programa y lógica, configuración, listas de entradas y salidas, firmware, gráficos de HMI, licencias, herramientas de configuración del proveedor, documentación de soporte e imágenes de sistemas operativos o máquinas virtuales cuando sean necesarias.
Menciona además las piezas de repuesto compatibles con las copias digitales y los objetivos de recuperación definidos. NIST SP 1339, p. 1. CISA, en sus objetivos voluntarios para distintos sectores, cita configuraciones, roles, lógica PLC, planos de ingeniería y herramientas entre la información OT que debe incluirse en las copias. CISA, Cross-Sector CPG, acción 2.R.
Conviene distinguir el archivo de proyecto de las dependencias que lo hacen interpretable y utilizable. Una copia del proyecto puede quedar incompleta si no se sabe qué versión del entorno de ingeniería lo abre, qué licencia se necesita o qué hardware puede ejecutarlo.
No todas las celdas tienen las mismas dependencias; por eso la ficha debería apuntar al documento o inventario que confirma cada relación, no convertir una lista genérica en una receta universal.
La ficha de cada activo debe responder, como mínimo, a estas preguntas:
| Campo | Pregunta que debe resolver |
|---|---|
| Activo y ubicación funcional | ¿Qué parte del proceso soporta y dónde se encuentra? |
| Identificador y versión | ¿Qué equipo, firmware, proyecto y revisión representa la copia? |
| Contenido incluido | ¿Qué archivos, parámetros documentados, licencias o manuales acompañan a la copia? |
| Dependencias | ¿Qué servidor, herramienta, repuesto, medio o servicio externo se necesita? |
| Criticidad y prioridad | ¿Qué operación depende de este activo y qué secuencia ha aprobado la planta? |
| Custodio y responsable | ¿Quién conserva el material y quién valida su uso? |
| Evidencia de prueba | ¿Cuándo se verificó el acceso, la integridad y la recuperación, y con qué resultado? |
La secuencia de recuperación depende de las interdependencias. Un servidor de ingeniería, el sistema de autenticación o una licencia pueden ser necesarios antes de trabajar sobre el controlador; una HMI puede mostrar valores que no sustituyen la verificación del proceso. NIST pide considerar dependencias de infraestructura y tener manuales, utilidades, software, cableado y licencias especializados disponibles para responder en la propia instalación. NIST SP 1339, págs. 1 y 2.
El estudio revisado por pares de Staves y coautores analiza estándares y entrevistas con operadores y reguladores británicos, y propone evaluar la capacidad de respuesta y recuperación como una práctica organizativa más amplia que la mera existencia de herramientas.
Su contexto es la infraestructura crítica del Reino Unido; sus entrevistas no deben considerarse representativas de plantas de otros países. Staves et al., International Journal of Critical Infrastructure Protection, 37 (2022).
Vincula copias, cambios y versiones confiables
Una copia solo sirve si se puede saber a qué estado autorizado corresponde. Asocia cada conjunto con el activo, la revisión, el momento de captura, la fuente y el cambio aprobado que lo motivó. Conserva también los datos necesarios para identificar diferencias entre versiones, sin reemplazar el original ni describir como vigente una copia cuya relación con el equipo no se haya confirmado.
NIST SP 1339 recomienda integrar la gestión de copias con los procesos de cambio y riesgo. También pide definir frecuencia, medio y ubicación según cuánto cambia la información, el tipo de sistema y el riesgo, además de etiquetar e indexar el medio con datos como el nombre del sistema, fecha y hora. NIST SP 1339, p. 1.
Esto permite evitar una cifra arbitraria de periodicidad: un activo que cambia con frecuencia o cuya pérdida interrumpe una operación crítica puede requerir un control distinto de otro que apenas cambia. La política debe registrar el criterio y quién lo aprobó.
La separación y protección también importan. Los objetivos voluntarios de CISA proponen copias almacenadas por separado del sistema de origen y pruebas recurrentes; para OT incluyen configuraciones, roles, lógica PLC, diagramas de ingeniería y herramientas.
El documento de CISA muestra una referencia de frecuencia mínima para su propio programa de objetivos; no debe convertirse en una regla universal ni en asesoramiento regulatorio aplicable a cualquier planta. CISA, Cross-Sector CPG, acción 2.R.
Define quién puede crear, revisar, almacenar y retirar copias; qué rol aprueba un cambio que las afecte; y cómo se anota una discrepancia entre el registro y el activo observado. No hace falta que el repositorio tenga una tecnología concreta para que exista trazabilidad: una ficha controlada puede apuntar a un almacén autorizado. Sí hace falta que el acceso y la custodia estén definidos.
NIST SP 1800-10 usa en un entorno de laboratorio de manufactura capacidades como control de cambios e integridad de archivos; es un ejemplo técnico ensayado, no una arquitectura que todas las plantas deban replicar. NIST SP 1800-10, resumen del proyecto.
Un cambio de proveedor, una sustitución de hardware, una actualización de firmware o un cambio de licencia pueden afectar la posibilidad de recuperar, aunque el archivo permanezca intacto. El propio NIST SP 1339 recomienda mantener documentación, herramientas especializadas y repuestos compatibles, además de revisar las limitaciones de equipos heredados. NIST SP 1339, págs. 1 y 2.
No concluyas que una copia es válida solo porque su fecha sea reciente; confirma qué estado y qué dependencias representa.
Ensaya la restauración fuera del proceso productivo
El ensayo debe probar una pregunta concreta en un entorno autorizado. Por ejemplo: «¿Puede el equipo reconstruir el entorno de ingeniería y confirmar que el proyecto recuperado corresponde a una revisión conocida?». Esa pregunta no equivale a cargar lógica en el PLC de planta ni a interrumpir una operación para ver qué ocurre.
NIST SP 1339 recomienda pruebas recurrentes de restauración en sistemas no productivos, tanto para validar la fiabilidad del medio como para practicar procedimientos y comprobar la integridad funcional del sistema recuperado. También recomienda hashes criptográficos cuando sea factible y metodologías de ingeniería aprobadas para verificar activos OT. NIST SP 1339, p. 2.
NIST SP 800-82 Rev. 3 explica que probar copias y restauraciones en OT puede depender de que existan equipos de repuesto o sistemas redundantes; si no se dispone de ellos, contempla métodos alternativos para verificar, como comprobaciones mediante hashes o sumas de comprobación. NIST SP 800-82 Rev. 3, §F.7.6, p. 251.
Una prueba puede empezar por una revisión de inventario y acceso, pasar a comprobaciones de integridad y seguir con una recuperación aislada en un banco de pruebas, en un equipo de repuesto o en un entorno virtual si ese entorno representa adecuadamente la dependencia ensayada. No todas las verificaciones prueban lo mismo.
Un hash confirma la coincidencia del contenido bajo el algoritmo usado, pero no verifica que el sistema arranque, que el proyecto sea compatible o que el proceso produzca un resultado aceptable. La validación funcional requiere criterios previos y personas con autoridad técnica para aplicarlos.
Acuerda el alcance antes de empezar: activo o grupo, revisión elegida, dependencias incluidas, supuestos, responsables, medios, criterios de aceptación y condición de parada. Los criterios pueden referirse a que el material se identifique y abra, que la versión corresponda a la configuración controlada, que las funciones relevantes se puedan validar en el entorno de prueba y que cualquier diferencia quede registrada.
Son criterios de planificación, no una secuencia de operaciones para un controlador productivo.
CISA recomienda establecer pruebas planificadas, ensayar equipos de respaldo frente a plazos realistas y definir pruebas de aceptación que permitan declarar el sistema plenamente operativo por la autoridad correspondiente. El mismo documento advierte que la recuperación ICS tiene complejidades distintas de la recuperación IT corriente. CISA, Developing an Industrial Control Systems Cybersecurity Incident Response Capability, §4.4.
Si la instalación no tiene un medio seguro para representar el activo en prueba, no conviertas una prueba de copia en un experimento en producción. Documenta la limitación, decide si puede ensayarse una parte del procedimiento sin afectar el control físico y asigna la evaluación a las personas responsables de operaciones, automatización y seguridad de procesos, junto con el proveedor.
Una prueba parcial sirve si se describe como parcial; no debe presentarse como demostración completa.
Mide lo que se probó y deja claro lo que falta
El registro del ejercicio debe permitir que otra persona reconstruya la evidencia sin repetir la prueba a ciegas. Anota fecha, activo, revisión, fuente de la copia, entorno de prueba, componentes incluidos, dependencias disponibles, criterio usado, observaciones, resultado, responsable y acción pendiente. Si se usaron herramientas de comprobación, guarda su versión o referencia cuando sea relevante para interpretar el resultado.
Separa los hitos: copia localizada, contenido legible, integridad comprobada, sistema recuperado en el entorno previsto, función validada, dependencias resueltas y resultado aceptado por la persona autorizada. Cada hito contesta una pregunta distinta. No marques todo como «recuperado» cuando solo se calculó un hash o se abrió un archivo.
NIST SP 1339 pide revisar los procedimientos y documentos a partir de lo aprendido en las pruebas, para mejorar la preparación de recuperación; también enumera registros técnicos como listas de E/S, especificaciones, narrativas de control, matrices causa-efecto, diagramas de red y cableado, y configuraciones del historiador. NIST SP 1339, p. 2.
El CISA Cross-Sector CPG trata por separado las copias y los planes de respuesta, y recomienda que estos se mantengan, practiquen y actualicen con escenarios comunes y propios de la organización. Es una guía voluntaria, no una auditoría ni una declaración automática de conformidad. CISA, Cross-Sector CPG, acciones 2.R y 2.S.
Una prueba también puede revelar que no hay una versión confiable, que falta una licencia o que el repuesto disponible no coincide con el hardware esperado. El resultado útil no siempre es «aprobado»: puede ser «no concluyente» o «bloqueado por dependencia». Esas salidas evitan que una ausencia de evidencia se convierta en una afirmación de capacidad.
La investigación de Staves y coautores recoge desafíos que influyen en la calidad de los planes de respuesta y recuperación para operadores británicos de infraestructura crítica; su propuesta incluye usar la evaluación de capacidad como parte de la mejora organizativa. Es evidencia sobre ese contexto, no una medida cuantitativa de la madurez de una instalación española. Staves et al., 2022, resumen del artículo.
NIST SP 1800-11 presenta un banco de laboratorio para recuperación ante corrupción de datos en entornos empresariales IT. Puede aportar ideas sobre cómo estructurar evidencia y detectar versiones no confiables, pero su ámbito declarado no es el control OT. NIST SP 1800-11, resumen y alcance.
Después de cada prueba, asigna responsables y fechas de revisión a los hallazgos. Si el alcance fue parcial, conserva esa etiqueta y programa el próximo ensayo según el riesgo, los cambios efectuados y los recursos disponibles. Para hablar de tiempo de recuperación, mide el ejercicio y declara sus condiciones.
Un resultado de laboratorio no predice por sí solo cuánto durará una parada real: también cuentan las dependencias, la autorización, la disponibilidad del personal y las restricciones del proceso.
Integra la preparación con la continuidad de planta
Las copias forman parte de la continuidad operativa. El plan debe enlazar inventario, responsables, almacenamiento, herramientas, disponibilidad de repuestos, dependencias, criterios de validación, canales de contacto y decisiones de escalado. También debe distinguir una recuperación tras un fallo técnico de una respuesta ante la sospecha de compromiso: no siempre se debe elegir la copia más reciente si se desconoce cuándo se alteró el sistema.
La guía CISA/FBI/NSA para entornos OT recomienda conservar procedimientos de recuperación con parámetros de configuración de equipos habituales y críticos, probar periódicamente las copias y mantenerlas separadas de conexiones de red que puedan extender malware. CISA, FBI y NSA, guía sobre infraestructura crítica. La sección anterior sobre inventario ya detalla manuales, herramientas, licencias, documentación y repuestos que la planta puede necesitar para cerrar esas dependencias.
Los objetivos de recuperación necesitan una decisión local. Puede haber objetivos de tiempo o de pérdida de datos, pero no son propiedades automáticas de la copia ni valores que una guía genérica pueda fijar para la planta. Acordarlos exige saber qué servicio se prioriza, qué operación puede permanecer degradada, qué riesgos introduce una restauración parcial y qué evidencia permite declarar aceptable el estado recuperado.
CISA describe pruebas de aceptación y autorización explícita como parte de la recuperación ICS; NIST recuerda que restituir estados puede tener consecuencias para el proceso físico. CISA, §4.4; NIST SP 800-82 Rev. 3, CP-10.
Empieza por un activo prioritario con responsables operativos y técnicos identificados. Reúne su inventario, las versiones conocidas, la documentación de dependencias y la ubicación autorizada de la copia. Decide qué prueba se puede hacer fuera de producción con los recursos disponibles, quién validará el resultado y qué aspectos quedarán sin demostrar. Programa la revisión siguiente cuando haya un cambio relevante o lo justifique la criticidad del activo.
Si todavía faltan datos, el siguiente paso no es prometer una recuperación. Es cerrar la brecha concreta: localizar el archivo original, confirmar quién mantiene la herramienta, comprobar un repuesto compatible o reservar un entorno de ensayo. Para revisar cómo definir límites entre sistemas de información y operación, consulta la guía práctica de integración IT/OT para planta.
Para relacionar una copia nueva con cambios aprobados, puede servir la guía de gestión de cambios con evidencia.
Preguntas frecuentes
¿Qué debería incluir una copia de seguridad OT?
Depende del activo y de qué haga falta para reconstruir su función. El archivo de lógica puede no bastar si faltan el firmware compatible, el proyecto de ingeniería, las licencias, los gráficos, los planos, los repuestos o la documentación. NIST recomienda identificar el conjunto necesario para cada activo. CISA también incluye configuraciones, roles, lógica de PLC, diagramas de ingeniería y herramientas en sus objetivos voluntarios para copias OT.
La ficha debería señalar qué elemento está guardado y dónde se conserva; una lista genérica no demuestra que las dependencias concretas estén disponibles.
Fuentes: NIST SP 1339, p. 1; CISA, Cross-Sector CPG, acción 2.R.
¿Cada cuánto hay que hacer copias de seguridad de PLC y HMI?
No hay una frecuencia universal para todos los activos. NIST recomienda definirla según cuánto cambia la información, el tipo de sistema, la criticidad y el riesgo, y vincular las copias a la gestión de cambios. CISA propone una referencia anual mínima dentro de sus objetivos voluntarios; no es una regla jurídica ni sustituye el análisis de la planta.
Tras un cambio aprobado que afecte al activo, la organización debe aplicar su política documentada y comprobar qué versión corresponde al estado controlado.
Fuentes: NIST SP 1339, p. 1; CISA, Cross-Sector CPG, acción 2.R.
¿Comprobar un hash demuestra que el sistema podrá recuperarse?
No. Un hash ayuda a comprobar que el contenido coincide con el hash esperado, pero no demuestra que el medio se pueda leer, que estén disponibles las dependencias o que el sistema restaurado cumpla su función. NIST recomienda probar restauraciones en sistemas no productivos.
Su guía de seguridad OT también explica que los ensayos pueden depender de equipos de repuesto o sistemas redundantes y contempla comprobaciones alternativas de integridad cuando no se dispone de ellos. La prueba funcional debe registrarse como una evidencia distinta de la comprobación criptográfica.
Fuentes: NIST SP 1339, p. 2; NIST SP 800-82 Rev. 3, §F.7.6, p. 251.
¿Se debe probar la restauración directamente en un PLC de producción?
Este artículo no recomienda hacer una prueba de escritura o restauración en un controlador productivo. NIST aconseja ensayar en sistemas no productivos, mientras que NIST SP 800-82 advierte de que restituir estados puede alterar el proceso físico en marcha. CISA recomienda acordar pruebas de aceptación y dejar la declaración de operación a la autoridad responsable.
Cualquier actividad sobre equipos de planta requiere evaluación, autorización y procedimientos locales de seguridad y operación; si no existe un entorno seguro que represente el activo, documenta la limitación y deja el ensayo funcional pendiente.
Fuentes: NIST SP 1339, p. 2; NIST SP 800-82 Rev. 3, control CP-10, p. 251; CISA, Developing an Industrial Control Systems Cybersecurity Incident Response Capability, §4.4.
¿Qué diferencia hay entre una copia de seguridad y una prueba de recuperación?
La prueba reúne evidencia de que, en un entorno autorizado, el sistema puede recuperarse y cumplir los criterios definidos. Además de comprobar los archivos, el ensayo debe dejar constancia del alcance, las dependencias disponibles, el resultado y las condiciones que siguen pendientes. CISA recomienda pruebas de aceptación para que la autoridad correspondiente decida cuándo declarar operativo un sistema ICS.
Esa validación no se deduce de que exista una copia ni de que su hash coincida.
Fuentes: CISA, Developing an Industrial Control Systems Cybersecurity Incident Response Capability, §4.4; NIST SP 800-82 Rev. 3, control CP-10, p. 251.