Backup NIS2: por qué una copia no garantiza la recuperación

Muchas empresas creen que están razonablemente protegidas porque “tienen backup”. Sin embargo, cuando llega un incidente —ransomware, borrado accidental, fallo de proveedor, caída de infraestructura o error humano— la pregunta relevante no es si existe una copia, sino si la empresa puede volver a operar en un plazo aceptable, con datos íntegros y con decisiones claras. Bajo NIS2, esta diferencia importa porque conecta la ciberseguridad con la continuidad, la responsabilidad directiva y la capacidad de demostrar que se han tomado medidas proporcionadas.

Backup NIS2: el problema no es solo copiar datos

En un comité de dirección, “tenemos copias” suele sonar tranquilizador. Pero desde una perspectiva de riesgo, esa frase está incompleta.

Una copia de seguridad puede existir y, aun así, no servir para recuperar la actividad. Puede estar incompleta, corrupta, cifrada por un atacante, almacenada en el mismo entorno comprometido, depender de credenciales afectadas o tardar demasiado en restaurarse.

El enfoque de backup NIS2 debe ir más allá de la herramienta utilizada. Lo relevante es comprobar si las copias protegen los procesos críticos y si la organización tiene capacidad real de restauración.

Esto afecta directamente a:

• continuidad de negocio;
• impacto económico de una parada;
• obligaciones frente a clientes y proveedores;
• reputación;
• evidencias ante auditorías o revisiones internas;
• presupuesto de adaptación y mejora.

Si la empresa está revisando si entra en el ámbito de aplicación de la directiva, puede ser útil partir de una evaluación inicial como la explicada en empresa obligada por NIS2 en Galicia, especialmente cuando existen servicios esenciales, cadenas de suministro o dependencias tecnológicas relevantes.

Copia, restauración y continuidad: tres niveles distintos

El error más habitual es tratar estos tres conceptos como si fueran equivalentes. No lo son.

Una copia responde a una cuestión técnica. La restauración probada responde a una cuestión operativa. La continuidad responde a una cuestión de negocio.

Para dirección, esta distinción es fundamental. No se trata de saber si el departamento técnico ha configurado un sistema de backup, sino de decidir qué procesos no pueden detenerse, cuánto tiempo puede asumir la empresa una interrupción y qué pérdidas serían aceptables o inasumibles.

Qué puede salir mal aunque haya copias de seguridad

Los incidentes reales rara vez se comportan como un ejercicio ideal. En muchas organizaciones, las copias existen, pero no se han probado en condiciones realistas.

Algunos escenarios frecuentes:

• el backup se ejecuta, pero no incluye una base de datos crítica;
• la copia está en la misma red que el sistema atacado;
• el ransomware cifra también los repositorios de respaldo;
• nadie conoce el orden correcto de recuperación;
• la restauración requiere claves, licencias o proveedores no disponibles;
• los tiempos de recuperación son incompatibles con la operativa;
• no hay evidencias documentadas de pruebas recientes;
• las copias cumplen para algunos sistemas, pero no para filiales, sedes o entornos cloud.

Desde el punto de vista NIS2, el riesgo no está solo en el fallo técnico. También está en la falta de gobierno: no haber definido prioridades, responsables, pruebas, dependencias y criterios de aceptación.

Por eso conviene conectar las copias de seguridad con el análisis de riesgos, la continuidad y la auditoría. Si la empresa ya trabaja con ISO 27001 o con controles internos de seguridad, puede aprovechar parte de esa estructura para ordenar evidencias y responsabilidades, evitando duplicidades.

La restauración probada: el punto que muchas empresas aplazan

Probar una restauración no significa hacer una demostración superficial. Significa verificar que la empresa puede recuperar datos, sistemas o servicios dentro de unos parámetros aceptables.

Para dirección, hay dos indicadores especialmente útiles:

RTO: cuánto tiempo puede estar parado el proceso

El RTO, o tiempo objetivo de recuperación, ayuda a decidir cuánto tiempo puede estar inactivo un proceso antes de causar un impacto grave.

No todos los sistemas requieren el mismo nivel de urgencia. Un portal informativo puede admitir más margen que un sistema de pedidos, una plataforma logística, una línea industrial conectada o una herramienta de atención a clientes.

RPO: cuántos datos puede permitirse perder la empresa

El RPO, o punto objetivo de recuperación, define cuánta información puede perderse entre la última copia válida y el incidente.

Perder una hora de datos puede ser asumible en algunos procesos. En otros, puede provocar conflictos contractuales, reprocesos, errores de facturación, incumplimientos o pérdida de trazabilidad.

Estas decisiones no deberían quedar solo en manos técnicas. Son decisiones de negocio, porque implican coste, riesgo y prioridades.

Qué debería pedir dirección al revisar el backup bajo NIS2

Un enfoque ejecutivo no exige entrar en configuraciones técnicas, pero sí pedir respuestas claras. Algunas preguntas útiles son:

1. Qué procesos críticos dependen de los sistemas respaldados.
   No basta con listar servidores. Hay que relacionar sistemas con operaciones, clientes, facturación, producción o servicio.

2. Dónde están las copias y quién puede acceder a ellas.
   La segregación, el control de accesos y la protección frente a manipulación son claves.

3. Cuándo se hizo la última prueba de restauración.
   Y, sobre todo, qué resultado tuvo, cuánto tardó y qué incidencias se detectaron.

4. Qué proveedor interviene en la recuperación.
   Si el backup depende de un tercero, debe revisarse su papel, sus compromisos y su disponibilidad en crisis.

5. Qué evidencias existen.
   Informes de prueba, registros, actas de revisión, incidencias corregidas y decisiones aprobadas ayudan a demostrar diligencia.

6. Qué presupuesto requiere mejorar el nivel actual.
   No siempre hace falta empezar por grandes inversiones. A menudo conviene priorizar sistemas críticos y reducir riesgos evidentes. Para entender factores de coste, puede consultarse esta guía sobre cuánto cuesta adaptarse a NIS2.

Backup y proveedores: una dependencia que debe revisarse

Muchas empresas tienen parte de sus sistemas en cloud, aplicaciones gestionadas por terceros o servicios externalizados. En esos casos, la continuidad no depende solo de las copias internas.

Dirección debería saber:

• si el proveedor realiza backups;
• con qué frecuencia;
• durante cuánto tiempo conserva las copias;
• si se han probado restauraciones;
• qué ocurre si el proveedor sufre un incidente;
• qué compromisos contractuales existen;
• cómo se coordina la comunicación en caso de crisis.

El problema aparece cuando la empresa asume que el proveedor “lo tiene cubierto”, pero no lo ha verificado. Bajo un enfoque NIS2, las dependencias de terceros deben formar parte del análisis de riesgos y de la planificación de continuidad.

Esto también puede convertirse en una mejora competitiva: una empresa capaz de explicar cómo protege la continuidad de sus servicios transmite más confianza. En algunos sectores, la ciberseguridad ya forma parte de la relación comercial, como se aborda en NIS2 como ventaja competitiva.

Evidencias: lo que no está probado es difícil de defender

En una auditoría, revisión interna o investigación posterior a un incidente, no basta con afirmar que había copias. Es importante poder mostrar qué se había planificado, probado y corregido.

Las evidencias pueden incluir:

• política de copias de seguridad;
• inventario de sistemas incluidos;
• relación entre procesos críticos y sistemas;
• resultados de pruebas de restauración;
• incidencias detectadas y acciones correctivas;
• revisión de accesos a repositorios de backup;
• contratos o acuerdos con proveedores;
• decisiones de dirección sobre RTO y RPO.

Estas evidencias no son burocracia sin valor. Ayudan a gestionar mejor, a priorizar inversiones y a demostrar que la organización ha actuado con criterio. Si la empresa está preparando revisiones, puede ser útil ampliar el enfoque con el artículo sobre auditoría NIS2 interna y externa.

Cómo empezar sin bloquear la operativa

La adaptación no tiene que convertirse en un proyecto inmanejable. Un punto de partida razonable es seleccionar los procesos que más daño causarían si se detuvieran y revisar sus copias con una prueba realista.

Un plan inicial podría incluir:

• identificar procesos críticos;
• asociar cada proceso a sistemas y proveedores;
• revisar frecuencia, ubicación y protección de copias;
• definir RTO y RPO orientativos;
• ejecutar una restauración controlada;
• documentar resultados;
• priorizar mejoras según impacto y coste;
• revisar periódicamente el esquema.

Para una primera autoevaluación, el checklist NIS2 puede ayudar a detectar brechas y ordenar prioridades antes de solicitar apoyo externo.

Recuperarse es una capacidad de negocio

El backup no debe verse como un asunto aislado del área técnica. Es una capacidad de resiliencia empresarial. La pregunta que debe hacerse dirección no es “¿tenemos copias?”, sino “¿podemos recuperar lo que sostiene la actividad, en el tiempo necesario y con pruebas que lo demuestren?”.

Esa diferencia cambia la conversación: de comprar almacenamiento a gestionar continuidad; de confiar en una herramienta a verificar resultados; de reaccionar en crisis a prepararse con evidencias.

Si tu empresa quiere revisar sus copias de seguridad, restauraciones, dependencias y continuidad dentro de un plan NIS2 realista, puedes consultar el servicio de adaptación NIS2 para empresas.