Una copia de seguridad cuenta solo si también ha probado que puede restaurarla — no solo si el archivo está allí, sino si el código fuente, la cadena de desarrollo y los secretos asociados vuelven a funcionar después de un incidente. En el desarrollo de software no se trata solo de un repositorio que pueda restaurar, sino de toda una cadena: control de versiones, servidores de construcción, canalizaciones, entornos de prueba y las claves y tokens que los acompañan. Sin un procedimiento de recuperación probado, solo descubre durante un incidente si funciona, y ese es el peor momento para enterarse.
La obligación de diligencia debida de la NIS2 menciona explícitamente la continuidad y la recuperación como parte de las diez medidas del artículo 21. La Directiva no prescribe una frecuencia de prueba fija ni una forma concreta — eso se completa por organización, y la transposición específica del país puede añadir sus propios énfasis. Lo que siempre reaparece, tanto en listas de verificación de seguridad de clientes como en lo que los reguladores consideran razonable, es la distinción entre tener una copia de seguridad y tener una copia de seguridad que ha restaurado y de la que sabe que el resultado funciona.
Qué significa exactamente 'probado'
Una prueba no es lo mismo que una marca de verificación verde en el software de copia de seguridad. Probado significa que alguien ha restaurado realmente la copia de seguridad en un entorno separado, ha verificado que el código se compila, que la construcción se realiza correctamente y que la aplicación funciona como se espera. Solo entonces sabe si el punto de recuperación es utilizable y cuánto tiempo lleva. Una copia de seguridad que se realiza pero nunca se restaura es en la práctica una suposición sobre la recuperación, no una recuperación probada.
Qué restaura específicamente en la cadena de desarrollo
En el desarrollo de software, el código fuente rara vez es lo único que puede perder. Piense en la configuración de la canalización CI/CD, los scripts de construcción, las dependencias de paquetes externos, las claves de acceso para registros y entornos en la nube, e historial en el propio sistema de control de versiones. Un plan de recuperación que solo cubre el código pero no la canalización o los secretos, deja a una organización aún inmovilizada después de un incidente. Por lo tanto, es útil determinar para cada uno de estos componentes por separado: dónde está la copia de seguridad, quién puede restaurarla, y si alguna vez se ha practicado.
Con qué frecuencia es razonable probar
No hay un plazo fijo en la Directiva para la frecuencia con la que debe realizar una prueba de recuperación. Lo que se considera razonable en la práctica depende de la frecuencia con la que cambie el entorno: una cadena de desarrollo que cambia la configuración de la canalización semanalmente requiere pruebas más frecuentes que un entorno estable que permanece sin cambios durante meses. Muchas organizaciones optan por un ritmo de calendario fijo — por ejemplo, cada trimestre — combinado con una prueba después de cada cambio importante en la infraestructura. Lo más importante que la frecuencia es que haya habido un momento, y que pueda señalar cuándo.
Qué registra como prueba
Un cliente que envía una lista de verificación de seguridad rara vez pregunta por la técnica detrás de su copia de seguridad. La pregunta es generalmente más simple: ¿cuándo se probó por última vez, quién la probó, y cuál fue el resultado? Para esa respuesta es suficiente registrar tres cosas: la fecha de la última prueba de recuperación, quién ejecutó la prueba, y qué componente se restauró — código, canalización, secretos, o los tres. Sin ese registro, la respuesta a la lista de verificación sigue siendo un recuerdo en lugar de una prueba, y esa es exactamente la diferencia que un evaluador al otro lado de la mesa quiere ver.
La relación con el resto del dossier
Las copias de seguridad y la recuperación rara vez funcionan de forma aislada. Quién puede ejecutar el procedimiento de recuperación está vinculado al control de acceso a la canalización de desarrollo; lo que salió mal durante una interrupción debe registrarse en el mismo registro de incidentes que se mantiene para otras medidas. Configurar un dossier de este tipo no tiene por qué ser un proyecto separado: las diez medidas desglosadas por situación muestra dónde encajan exactamente las copias de seguridad y la recuperación en el conjunto, y qué otras medidas están directamente relacionadas.
Si las copias de seguridad y la recuperación se aplican como medida de debida diligencia en su organización depende de si usted mismo está sujeto a la Directiva (EU) 2022/2555 o si recibe esta pregunta a través de un cliente que sí lo está. en unas pocas preguntas ver dónde se encuentra proporciona una primera indicación al respecto, con una explicación de por qué. Cómo llegamos a esa indicación y qué fuentes la respaldan se explica en la página sobre nuestra metodología.
Una copia de seguridad que nunca se ha restaurado no es una garantía — es una pregunta que espera una respuesta. ¿Desea saber si y cómo esta medida es relevante para su organización, y qué más implica? Realice el análisis rápido gratuito u hojee las preguntas más frecuentes sobre la Directiva (EU) 2022/2555 para las preguntas que otros empresarios ya formularon.