Pruebas de restauración listas para auditoría para ISO 27001, NIS2 y DORA
Son las 07:40 de un lunes por la mañana y Sarah, la CISO de una empresa de tecnología financiera en rápido crecimiento, ve cómo se materializa una crisis en tiempo real. El director financiero no puede abrir la plataforma de aprobación de pagos. La mesa de servicio cree que se trata de un problema de almacenamiento. El equipo de infraestructura sospecha de ransomware porque varias carpetas compartidas muestran ahora nombres de archivo cifrados. El director general quiere saber si la nómina está protegida. El equipo jurídico pregunta si es necesario notificar a los reguladores.
Sarah abre el panel de copias de seguridad. Está lleno de indicadores verdes.
Eso debería tranquilizarla, pero no lo hace. Un trabajo de copia de seguridad completado correctamente no prueba que la restauración vaya a funcionar. Es como ver un extintor en la pared sin saber si está cargado, accesible y utilizable bajo presión.
La empresa de Sarah está dentro del alcance de ISO 27001:2022, se considera una entidad importante bajo NIS2 y está sujeta a DORA como entidad financiera. La cuestión ya no es si la organización ejecuta copias de seguridad. La cuestión es si puede restaurar los sistemas adecuados, al punto temporal adecuado, dentro de los Objetivos de Tiempo de Recuperación y los Objetivos de Punto de Recuperación aprobados, con evidencias suficientemente sólidas para un auditor, regulador, cliente, aseguradora y Consejo de Administración.
Ahí es donde fallan muchos programas de copias de seguridad. Tienen trabajos de copia de seguridad. Tienen paneles. Tienen instantáneas. Puede que incluso tengan almacenamiento en la nube. Pero cuando llega la presión, no pueden demostrar que los sistemas críticos son recuperables, que se realizaron pruebas de restauración, que las pruebas fallidas activaron acciones correctivas y que las evidencias se asignan de forma clara a las expectativas de ISO 27001:2022, NIS2, DORA, NIST y COBIT 2019.
Las pruebas de copias de seguridad y restauración se han convertido en un asunto de resiliencia operativa a nivel del Consejo de Administración. NIS2 eleva las expectativas sobre gestión de riesgos de ciberseguridad y continuidad del negocio. DORA convierte la resiliencia operativa digital de las TIC en una obligación esencial para las entidades financieras y sus proveedores críticos de servicios TIC. ISO 27001:2022 proporciona la estructura del sistema de gestión para alcance, riesgo, selección de controles, evidencias, auditoría y mejora continua.
El reto práctico consiste en convertir una prueba técnica de restauración en evidencias listas para auditoría.
La copia de seguridad no es evidencia hasta que se demuestra la restauración
Un trabajo de copia de seguridad completado correctamente es solo una señal parcial. Indica que los datos se copiaron en algún lugar. No demuestra que los datos puedan restaurarse, que las dependencias de la aplicación estén intactas, que las claves de cifrado estén disponibles, que los servicios de identidad sigan funcionando ni que el sistema recuperado soporte las operaciones reales de la organización.
Los auditores lo saben. Los reguladores lo saben. Los atacantes lo saben.
Un auditor técnicamente maduro no se detendrá ante una captura de pantalla que muestre un 97 por ciento de éxito en los trabajos de copia de seguridad. Preguntará:
- ¿Qué sistemas son críticos o de alto impacto?
- ¿Qué RTO y RPO aplica a cada sistema?
- ¿Cuándo se realizó la última prueba de restauración?
- ¿La prueba fue completa, parcial, a nivel de aplicación, a nivel de base de datos o a nivel de archivo?
- ¿Quién validó el proceso de negocio después de la restauración?
- ¿Los fallos se registraron como no conformidades o acciones de mejora?
- ¿Durante cuánto tiempo se conservan los registros técnicos y los registros de pruebas de restauración?
- ¿Las copias de seguridad están segregadas entre ubicaciones?
- ¿Cómo se asignan las evidencias al Registro de Riesgos y a la Declaración de Aplicabilidad?
Por eso el lenguaje de las políticas de Clarysec es deliberadamente directo. La Política de Copias de Seguridad y Restauración para pymes [BRP-SME], sección Requisitos de gobernanza, cláusula de política 5.3.3, exige:
Las pruebas de restauración se realizan al menos trimestralmente, y los resultados se documentan para verificar la capacidad de recuperación
Esa frase cambia la conversación de auditoría. Traslada a la organización de “tenemos copias de seguridad” a “verificamos la capacidad de recuperación con una periodicidad definida y conservamos los resultados”.
La misma Política de Copias de Seguridad y Restauración para pymes, sección Aplicación y cumplimiento, cláusula de política 8.2.2, refuerza la obligación de evidencias:
Los registros y los registros de pruebas de restauración se conservan con fines de auditoría
Esa cláusula evita que las pruebas de restauración se conviertan en conocimiento informal no documentado. Si un ingeniero de infraestructura dice: “Lo probamos en marzo”, pero no existe ningún registro, no es evidencia lista para auditoría.
La misma política también aborda la capacidad de supervivencia mediante diversidad de almacenamiento. En la sección Requisitos de implementación de la política, cláusula de política 6.3.1.1, las copias de seguridad deben estar:
Almacenadas en al menos dos ubicaciones (local y nube)
Esta es una configuración de referencia práctica. No sustituye a una evaluación de riesgos, pero reduce la probabilidad de que un único dominio de fallo físico o lógico destruya tanto los datos de producción como los datos de copia de seguridad.
La cadena de evidencias de ISO 27001:2022 empieza antes de la prueba
Las organizaciones suelen tratar el cumplimiento en materia de copias de seguridad como un asunto de Operaciones de TI. En términos de ISO 27001:2022, ese enfoque es demasiado limitado. Las pruebas de copias de seguridad y restauración deben integrarse en el Sistema de Gestión de la Seguridad de la Información, conectadas con el alcance, el riesgo, la selección de controles, la supervisión, la auditoría interna y la mejora continua.
El Zenith Blueprint: hoja de ruta de 30 pasos para auditores [ZB] de Clarysec inicia esta cadena de evidencias antes de que se realice cualquier prueba de restauración.
En la fase de Fundamentos y liderazgo del SGSI, Paso 2, Necesidades de las partes interesadas y alcance del SGSI, Zenith Blueprint indica a las organizaciones que definan qué queda dentro del SGSI:
Elemento de acción 4.3: Redactar una declaración del alcance del SGSI. Enumerar qué se incluye (unidades de negocio, ubicaciones, sistemas) y cualquier exclusión. Compartir este borrador con la alta dirección para recibir aportaciones: deben acordar qué partes de la organización estarán sujetas al SGSI. También es recomendable contrastar este alcance con la lista anterior de requisitos de las partes interesadas: ¿cubre el alcance todas las áreas necesarias para cumplir esos requisitos?
Para las pruebas de restauración, el alcance define el universo de recuperación. Si la plataforma de pagos, el proveedor de identidad, la base de datos ERP, el servidor de gestión de endpoints y el almacenamiento de objetos en la nube están dentro del alcance, las evidencias de restauración deben incluirlos o justificar por qué no. Si un sistema se excluye, la exclusión debe ser defendible frente a los requisitos de las partes interesadas, las obligaciones contractuales, las obligaciones regulatorias y las necesidades de continuidad del negocio.
El siguiente eslabón es el riesgo. En la fase de Gestión de riesgos, Paso 11, Creación y documentación del Registro de Riesgos, Zenith Blueprint describe el Registro de Riesgos como el registro maestro de riesgos, activos, amenazas, vulnerabilidades, controles actuales, propietarios y decisiones de tratamiento.
Una entrada de riesgo relacionada con copias de seguridad debe ser práctica, no teórica.
| Elemento de riesgo | Ejemplo de entrada |
|---|---|
| Activo | Plataforma de aprobación de pagos y base de datos de soporte |
| Amenaza | Cifrado por ransomware o acción destructiva de un administrador |
| Vulnerabilidad | Copias de seguridad no restauradas trimestralmente y dependencias de aplicación no validadas |
| Impacto | Retraso en nóminas, exposición regulatoria, impacto en la confianza del cliente |
| Controles actuales | Trabajos diarios de copia de seguridad, almacenamiento inmutable en la nube, prueba trimestral de restauración |
| Propietario del riesgo | Responsable de Infraestructura |
| Decisión de tratamiento | Mitigar mediante copias de seguridad probadas, evidencias de restauración documentadas y actualizaciones del BCP |
Aquí es donde la copia de seguridad se vuelve auditable. Ya no es “tenemos copias de seguridad”. Es “identificamos un riesgo para la organización, seleccionamos controles, asignamos la propiedad, probamos el control y conservamos evidencias”.
El Zenith Blueprint, fase de Gestión de riesgos, Paso 13, Planificación del Tratamiento de Riesgos y Declaración de Aplicabilidad, cierra el ciclo de trazabilidad:
Asignar controles a riesgos y cláusulas (trazabilidad)
Ahora que dispone tanto del Plan de Tratamiento de Riesgos como de la SoA:
✓ Asignar controles a riesgos: En el plan de tratamiento de su Registro de Riesgos, ha enumerado determinados controles para cada riesgo. Puede añadir una columna “Referencia de control del Anexo A” a cada riesgo y enumerar los números de control.
Para las copias de seguridad y las pruebas de restauración, la Declaración de Aplicabilidad debe conectar el escenario de riesgo con los controles del Anexo A de ISO/IEC 27001:2022, especialmente 8.13 Copia de seguridad de la información, 5.30 Preparación de las TIC para la continuidad del negocio, 8.14 Redundancia de las instalaciones de tratamiento de la información y 5.29 Seguridad de la información durante interrupciones.
La SoA no debe limitarse a marcar estos controles como aplicables. Debe explicar por qué son aplicables, qué evidencias de implementación existen, quién es el propietario del control y cómo se gestionan las excepciones.
El mapa de controles que los auditores esperan ver
Zenith Controls: guía de cumplimiento cruzado [ZC] de Clarysec no crea controles ni propietarios separados. Organiza normas y marcos oficiales en una vista práctica de cumplimiento cruzado para que las organizaciones entiendan cómo una práctica operativa, como las pruebas de restauración, respalda múltiples obligaciones.
Para el control 8.13 Copia de seguridad de la información de ISO/IEC 27002:2022, Zenith Controls clasifica el control como Correctivo, vinculado a Integridad y Disponibilidad, alineado con el concepto de ciberseguridad Recuperar, de soporte a la capacidad operativa de Continuidad y ubicado en el dominio de seguridad de Protección. Ese perfil reformula las copias de seguridad como una capacidad de recuperación, no solo como un proceso de almacenamiento.
Para el control 5.30 Preparación de las TIC para la continuidad del negocio de ISO/IEC 27002:2022, Zenith Controls clasifica el control como Correctivo, centrado en Disponibilidad, alineado con Responder, de soporte a Continuidad y situado en el dominio de seguridad de Resiliencia. Aquí es donde las pruebas de restauración se conectan directamente con la resiliencia operativa.
Para el control 8.14 Redundancia de las instalaciones de tratamiento de la información de ISO/IEC 27002:2022, Zenith Controls identifica un control Preventivo centrado en Disponibilidad, alineado con Proteger, de soporte a Continuidad y Gestión de activos, y vinculado a los dominios de Protección y Resiliencia. La redundancia y las copias de seguridad no son lo mismo. La redundancia ayuda a prevenir la interrupción. Las copias de seguridad habilitan la recuperación después de una pérdida, corrupción o ataque.
Para el control 5.29 Seguridad de la información durante interrupciones de ISO/IEC 27002:2022, Zenith Controls muestra un perfil más amplio: Preventivo y Correctivo, que cubre Confidencialidad, Integridad y Disponibilidad, alineado con Proteger y Responder, de soporte a Continuidad y vinculado a Protección y Resiliencia. Esto importa durante la recuperación frente a ransomware porque la restauración no debe crear nuevos fallos de seguridad, como restaurar imágenes vulnerables, eludir el registro de eventos o reactivar privilegios excesivos.
| Control del Anexo A de ISO/IEC 27001:2022 | Función en resiliencia | Evidencias que esperan los auditores |
|---|---|---|
| 8.13 Copia de seguridad de la información | Demuestra que los datos y sistemas pueden recuperarse después de una pérdida, corrupción o ataque | Calendario de copias de seguridad, registros de pruebas de restauración, criterios de éxito, registros técnicos, excepciones, evidencias de conservación |
| 5.30 Preparación de las TIC para la continuidad del negocio | Demuestra que las capacidades TIC respaldan los objetivos de continuidad | BIA, asignación de RTO/RPO, runbooks de recuperación, informes de prueba, lecciones aprendidas |
| 8.14 Redundancia de las instalaciones de tratamiento de la información | Reduce la dependencia de una única instalación de procesamiento o ruta de servicio | Diagramas de arquitectura, resultados de pruebas de conmutación por error, revisión de capacidad, mapeo de dependencias |
| 5.29 Seguridad de la información durante interrupciones | Mantiene la seguridad durante operaciones degradadas y recuperación | Registros de acceso en crisis, aprobaciones de cambios de emergencia, registro de eventos, cronología del incidente, validación de seguridad posterior a la restauración |
La lección práctica es sencilla. Una prueba de restauración no es un control aislado. Es evidencia a lo largo de una cadena de resiliencia.
La brecha de auditoría oculta: RTO y RPO sin prueba
Uno de los hallazgos de auditoría de continuidad más frecuentes es la brecha entre el RTO/RPO documentado y la capacidad real de restauración.
El Plan de Continuidad del Negocio puede indicar que el portal de clientes tiene un RTO de cuatro horas y un RPO de una hora. La plataforma de copias de seguridad puede ejecutarse cada hora. Pero durante el primer ejercicio realista de restauración, el equipo descubre que la restauración de la base de datos tarda tres horas, los cambios de DNS requieren otra hora, el certificado de la aplicación ha caducado y la integración de identidad nunca se incluyó en el runbook. El tiempo real de recuperación es de ocho horas.
El RTO documentado era ficticio.
La Política de Continuidad del Negocio y Recuperación ante Desastres para pymes [BCDR-SME] de Clarysec, sección Requisitos de gobernanza, cláusula de política 5.2.1.4, hace explícito el requisito de continuidad:
Objetivos de Tiempo de Recuperación (RTO) y Objetivos de Punto de Recuperación (RPO) para cada sistema
Esto importa porque “restaurar rápidamente los servicios críticos” no es medible. “Restaurar la base de datos de aprobación de pagos en un plazo de cuatro horas con no más de una hora de pérdida de datos” sí es medible.
La misma Política de Continuidad del Negocio y Recuperación ante Desastres para pymes, sección Requisitos de implementación de la política, cláusula de política 6.4.2, convierte las pruebas en mejora:
Todos los resultados de las pruebas deben documentarse, y las lecciones aprendidas deben registrarse y utilizarse para actualizar el BCP.
Una restauración fallida no es automáticamente un desastre de auditoría. Una restauración fallida sin lección documentada, propietario, corrección y repetición de la prueba sí lo es.
Para entornos empresariales, la Política de Copias de Seguridad y Restauración [BRP] de Clarysec proporciona una gobernanza más formal. En la sección Requisitos de gobernanza, cláusula de política 5.1, establece:
Debe mantenerse un Calendario Maestro de Copias de Seguridad y revisarse anualmente. Debe especificar:
Ese requisito inicial establece el artefacto principal de gobernanza. Un Calendario Maestro de Copias de Seguridad debe identificar sistemas, conjuntos de datos, frecuencia de copia de seguridad, conservación, ubicación, propiedad, clasificación, dependencias y periodicidad de pruebas.
La misma Política de Copias de Seguridad y Restauración, sección Requisitos de gobernanza, cláusula de política 5.2, vincula las expectativas de copia de seguridad con el impacto en el negocio:
Todos los sistemas y aplicaciones clasificados como Críticos o de Alto impacto en el análisis de impacto en el negocio (BIA) deben:
Aquí convergen el BIA y la gobernanza de copias de seguridad. Los sistemas críticos y de alto impacto requieren mayor aseguramiento de recuperación, pruebas más frecuentes, mejor mapeo de dependencias y evidencias más disciplinadas.
Un único modelo de evidencias para ISO 27001:2022, NIS2, DORA, NIST y COBIT 2019
Los equipos de cumplimiento suelen enfrentarse a la duplicación entre marcos. ISO 27001:2022 exige selección de controles basada en riesgos y evidencias. NIS2 espera medidas de gestión de riesgos de ciberseguridad, incluida la continuidad del negocio. DORA espera resiliencia operativa de las TIC, respuesta y recuperación, procedimientos de copia de seguridad y restauración, y pruebas de resiliencia operativa digital. NIST y COBIT 2019 utilizan, de nuevo, un lenguaje distinto.
La respuesta no consiste en crear programas de copias de seguridad separados para cada marco. La respuesta consiste en crear un único modelo de evidencias que pueda analizarse desde múltiples lentes de auditoría.
| Lente del marco | Qué demuestran las pruebas de copias de seguridad y restauración | Evidencias que deben mantenerse listas para auditoría |
|---|---|---|
| ISO 27001:2022 | Los riesgos se tratan mediante controles seleccionados, probados, supervisados y mejorados a través del SGSI | Alcance, Registro de Riesgos, SoA, calendario de copias de seguridad, registros de restauración, resultados de auditoría interna, registro CAPA |
| NIS2 | Los servicios esenciales o importantes pueden resistir y recuperarse de una interrupción cibernética | Planes de Continuidad del Negocio, procedimientos de crisis, pruebas de copias de seguridad, vínculos con respuesta a incidentes, supervisión de la dirección |
| DORA | Los servicios TIC que soportan funciones críticas o importantes son resilientes y recuperables | Mapeo de activos TIC, RTO/RPO, informes de pruebas de restauración, evidencias de dependencias de terceros, procedimientos de recuperación |
| NIST CSF | Las capacidades de recuperación respaldan resultados resilientes de ciberseguridad | Planes de recuperación, comprobaciones de integridad de copias de seguridad, procedimientos de comunicación, lecciones aprendidas |
| COBIT 2019 | Los objetivos de gobierno y gestión están respaldados por controles medibles y propiedad responsable | Propiedad de procesos, métricas, desempeño del control, seguimiento de problemas, informes a la dirección |
Para NIS2, la referencia más directa es Article 21 sobre medidas de gestión de riesgos de ciberseguridad. Article 21(2)(c) incluye específicamente la continuidad del negocio, como la gestión de copias de seguridad, la recuperación ante desastres y la gestión de crisis. Article 21(2)(f) también es relevante porque aborda políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad. Las pruebas de restauración son exactamente eso: evidencia de que la medida funciona.
Para DORA, los vínculos más sólidos son Article 11 sobre respuesta y recuperación, Article 12 sobre políticas y procedimientos de copia de seguridad, procedimientos y métodos de restauración y recuperación, y Article 24 sobre requisitos generales para las pruebas de resiliencia operativa digital. Para las entidades financieras, una prueba de restauración de base de datos por sí sola puede ser insuficiente si el servicio de negocio depende de identidad en la nube, conectividad con pasarela de pagos, alojamiento externalizado o supervisión gestionada. Las evidencias al estilo DORA deben estar a nivel de servicio, no solo a nivel de servidor.
| Control ISO/IEC 27001:2022 | Conexión con DORA | Conexión con NIS2 |
|---|---|---|
| 8.13 Copia de seguridad de la información | Article 12 exige políticas de copia de seguridad, procedimientos y métodos de restauración y recuperación | Article 21(2)(c) incluye la gestión de copias de seguridad y la recuperación ante desastres como medidas de continuidad del negocio |
| 5.30 Preparación de las TIC para la continuidad del negocio | Article 11 exige capacidad de respuesta y recuperación, y Article 24 exige pruebas de resiliencia | Article 21(2)(c) incluye continuidad del negocio y gestión de crisis |
| 8.14 Redundancia de las instalaciones de tratamiento de la información | Articles 6 y 9 respaldan la gestión del riesgo de las TIC, la protección, la prevención y la reducción de puntos únicos de fallo | Article 21 exige medidas adecuadas y proporcionadas para gestionar los riesgos de los sistemas de redes y de información |
| 5.29 Seguridad de la información durante interrupciones | La respuesta y recuperación de Article 11 exige una recuperación controlada durante incidentes | Las medidas de gestión de riesgos de Article 21 exigen continuidad sin abandonar los controles de seguridad |
Esta es la eficiencia de una estrategia de cumplimiento unificada. Una prueba trimestral de restauración de un sistema de pagos puede respaldar evidencias del Anexo A de ISO 27001:2022, expectativas de continuidad de NIS2, requisitos de recuperación TIC de DORA, resultados de Recuperación de NIST CSF e informes de gobernanza de COBIT 2019, si las evidencias se estructuran correctamente.
Una prueba de restauración práctica que se convierte en evidencia lista para auditoría
Volvamos al escenario del lunes por la mañana de Sarah, pero imaginemos que su organización se preparó utilizando el toolkit de Clarysec.
La plataforma de aprobación de pagos está clasificada como Crítica en el BIA. El RTO aprobado es de cuatro horas. El RPO aprobado es de una hora. La plataforma depende de un clúster de bases de datos, un proveedor de identidad, una bóveda de secretos, una canalización de registros, DNS, certificados y un relé de correo saliente.
El equipo de Sarah diseña una prueba trimestral de restauración en torno a seis pasos.
Paso 1: Confirmar el alcance y las dependencias
Usando Zenith Blueprint Paso 2, Sarah confirma que la plataforma de pagos, la base de datos, la integración de identidad, la infraestructura de copia de seguridad y el entorno de recuperación están dentro del alcance del SGSI. Legal confirma la relevancia regulatoria. Finanzas confirma el impacto en el negocio. TI confirma las dependencias.
Esto evita el error clásico de restaurar solo la base de datos e ignorar el servicio de autenticación necesario para acceder a la aplicación.
Paso 2: Vincular la prueba al Registro de Riesgos
Usando Zenith Blueprint Paso 11, el Registro de Riesgos incluye el escenario: “La pérdida o el cifrado de datos de la plataforma de aprobación de pagos impide las operaciones de pago y crea exposición regulatoria”.
Los controles actuales incluyen copias de seguridad diarias, almacenamiento inmutable en la nube, copias de seguridad en múltiples ubicaciones, pruebas trimestrales de restauración y runbooks de recuperación documentados. El Propietario del Riesgo es el Responsable de Infraestructura. El propietario de negocio es Operaciones Financieras. La decisión de tratamiento es Mitigar.
Paso 3: Asignar el tratamiento a la SoA
Usando Zenith Blueprint Paso 13, la SoA asigna el riesgo a los controles del Anexo A de ISO/IEC 27001:2022 8.13, 5.30, 8.14 y 5.29. La SoA explica que las pruebas de copia de seguridad proporcionan capacidad correctiva de recuperación, los procedimientos de continuidad TIC respaldan la continuidad del negocio, la redundancia reduce la probabilidad de indisponibilidad y la seguridad durante interrupciones evita atajos inseguros de recuperación.
Paso 4: Usar cláusulas de política como criterios de prueba
El equipo utiliza la cláusula 5.3.3 de la Política de Copias de Seguridad y Restauración para pymes para las pruebas trimestrales de restauración, la cláusula 8.2.2 para la conservación de evidencias y la cláusula 6.3.1.1 para el almacenamiento en múltiples ubicaciones. Utiliza la cláusula 5.2.1.4 de la Política de Continuidad del Negocio y Recuperación ante Desastres para pymes para los objetivos de RTO/RPO y la cláusula 6.4.2 para lecciones aprendidas y actualizaciones del BCP.
| Criterio de prueba | Objetivo | Evidencia |
|---|---|---|
| Periodicidad de restauración | Trimestral | Calendario de pruebas y programación aprobada |
| RTO | 4 horas | Hora de inicio, hora de fin, tiempo de recuperación transcurrido |
| RPO | 1 hora | Marca de tiempo de la copia de seguridad y validación de transacciones |
| Ubicaciones | Fuentes de copia de seguridad local y en la nube disponibles | Informe del repositorio de copias de seguridad |
| Integridad | Las comprobaciones de consistencia de la base de datos se superan | Registros de validación |
| Aplicación | Un usuario de Finanzas puede aprobar un pago de prueba | Aprobación formal de validación de negocio |
| Seguridad | Registro de eventos, controles de acceso y secretos validados después de la restauración | Lista de verificación de seguridad y capturas de pantalla |
Paso 5: Ejecutar la restauración y registrar los hechos
La restauración se realiza en un entorno de recuperación aislado. El equipo registra marcas de tiempo, identificadores de conjuntos de copias de seguridad, pasos de restauración, errores, resultados de validación y aprobaciones.
Un registro sólido de prueba de restauración debe incluir:
| Campo de prueba de restauración | Ejemplo |
|---|---|
| ID de prueba | Q2-2026-PAY-RESTORE |
| Sistema probado | Plataforma de aprobación de pagos |
| Conjunto de copias de seguridad utilizado | Copia de seguridad de la plataforma de pagos desde el punto de recuperación aprobado |
| Ubicación de restauración | Entorno de recuperación aislado |
| Objetivo RTO | 4 horas |
| Objetivo RPO | 1 hora |
| Tiempo real de recuperación | 2 horas 45 minutos |
| Punto real de recuperación | 42 minutos |
| Validación de integridad | Comprobaciones de consistencia de la base de datos superadas |
| Validación de negocio | Usuario de Finanzas aprobó un pago de prueba |
| Validación de seguridad | Registro de eventos, controles de acceso, secretos y supervisión confirmados |
| Resultado | Aprobado con condición |
| Aprobación formal | CISO, Responsable de Infraestructura, Propietario de Operaciones Financieras |
Durante la prueba, el equipo descubre un problema. La aplicación restaurada no puede enviar correos electrónicos de notificación porque la lista de permitidos del relé de correo no incluye la subred de recuperación. La aprobación básica de pagos funciona, pero el flujo de trabajo está degradado.
Paso 6: Registrar las lecciones aprendidas y la acción correctiva
Aquí es donde muchas organizaciones se detienen demasiado pronto. El enfoque de Clarysec lleva el problema al sistema de mejora.
En la fase Auditoría, revisión y mejora, Paso 29, Mejora continua, Zenith Blueprint utiliza un registro CAPA para hacer seguimiento de la descripción del problema, causa raíz, acción correctiva, propietario, fecha objetivo y estado.
| Campo CAPA | Ejemplo |
|---|---|
| Descripción del problema | La plataforma de aprobación de pagos restaurada no pudo enviar notificaciones por correo electrónico desde la subred de recuperación |
| Causa raíz | La red de recuperación no estaba incluida en el diseño de la lista de permitidos del relé de correo |
| Acción correctiva | Actualizar la arquitectura de recuperación y el procedimiento de lista de permitidos del relé de correo |
| Propietario | Responsable de Infraestructura |
| Fecha objetivo | 15 días hábiles |
| Estado | Abierto pendiente de nueva prueba |
Esta única prueba de restauración produce ahora una cadena de evidencias lista para auditoría: requisito de política, confirmación de alcance, mapeo de riesgos, mapeo de SoA, plan de prueba, registro de ejecución, validación de negocio, validación de seguridad, registro del problema, acción correctiva y actualización del BCP.
Cómo inspeccionan distintos auditores las mismas evidencias
Un paquete sólido de evidencias anticipa la lente del auditor.
Un auditor de ISO 27001:2022 normalmente empezará por el sistema de gestión. Preguntará si los requisitos de copia de seguridad y restauración están dentro del alcance, se basan en riesgos, se han implementado, se supervisan, se auditan internamente y se mejoran. Esperará trazabilidad desde el Registro de Riesgos hasta la SoA y los registros operativos. También puede conectar las pruebas fallidas y las acciones correctivas con la cláusula 10.2 de ISO/IEC 27001:2022 sobre no conformidad y acción correctiva.
Un revisor de DORA se centrará en la resiliencia operativa digital de las TIC para funciones críticas o importantes. Querrá ver recuperación a nivel de servicio, dependencias de terceros TIC, pruebas basadas en escenarios, supervisión del órgano de administración y evidencias de que los procedimientos de restauración son eficaces.
Una perspectiva supervisora de NIS2 buscará medidas de gestión de riesgos de ciberseguridad adecuadas y proporcionadas. Las evidencias de copia de seguridad y recuperación ante desastres deben demostrar que los servicios esenciales o importantes pueden mantener o restaurar las operaciones después de incidentes, con la dirección informada del riesgo residual.
Un evaluador orientado a NIST se centrará en los resultados de ciberseguridad en Identificar, Proteger, Detectar, Responder y Recuperar. Puede preguntar por copias de seguridad inmutables, acceso privilegiado a repositorios de copias de seguridad, restauración en entornos limpios, procedimientos de comunicación y lecciones aprendidas.
Un auditor de COBIT 2019 o con enfoque ISACA hará énfasis en gobernanza, propiedad de procesos, métricas, informes a la dirección y seguimiento de problemas. Le impresionará menos una restauración técnicamente elegante si la propiedad y los informes no están claros.
Las mismas evidencias pueden satisfacer todas estas perspectivas, pero solo si están completas.
Fallos comunes en pruebas de restauración que generan hallazgos de auditoría
Clarysec observa repetidamente las mismas deficiencias de evidencias evitables.
| Patrón de fallo | Por qué crea riesgo de auditoría | Solución práctica |
|---|---|---|
| El éxito de la copia de seguridad se trata como éxito de restauración | La finalización de la copia no demuestra la capacidad de recuperación | Realizar pruebas de restauración documentadas con validación |
| El RTO y el RPO están definidos pero no se prueban | Los objetivos de continuidad pueden ser poco realistas | Medir el tiempo real de recuperación y el punto real de recuperación durante las pruebas |
| Solo infraestructura valida la restauración | El proceso de negocio puede seguir siendo inutilizable | Exigir la aprobación formal del propietario de negocio para sistemas críticos |
| Los registros de prueba están dispersos | Los auditores no pueden verificar la consistencia | Usar una plantilla estándar de informe de prueba de restauración y una carpeta de evidencias |
| Las pruebas fallidas se comentan pero no se siguen | No hay evidencias de mejora continua | Registrar problemas en CAPA con propietario, fecha límite y nueva prueba |
| Las copias de seguridad se almacenan en un único dominio lógico de fallo | El ransomware o una configuración incorrecta pueden destruir la capacidad de recuperación | Usar ubicaciones segregadas, almacenamiento inmutable y control de acceso |
| Se excluyen dependencias | Las aplicaciones restauradas pueden no funcionar | Mapear identidad, DNS, secretos, certificados, integraciones y registro de eventos |
| Se ignora la seguridad durante la recuperación | Los servicios restaurados pueden ser vulnerables o no estar supervisados | Incluir validación de seguridad posterior a la restauración |
El objetivo no es la burocracia. El objetivo es una recuperación fiable bajo presión y evidencias defendibles en auditoría.
Crear un paquete de evidencias de recuperación para el Consejo de Administración
La alta dirección no necesita registros brutos de copias de seguridad. Necesita aseguramiento de que los servicios críticos son recuperables, que las excepciones se conocen y que las acciones de mejora avanzan.
Para cada servicio crítico, informe:
- Nombre del servicio y propietario de negocio
- Criticidad según el BIA
- RTO y RPO aprobados
- Fecha de la última prueba de restauración
- RTO y RPO alcanzados
- Resultado de la prueba
- Acciones correctivas abiertas
- Dependencias de terceros que afectan a la recuperación
- Declaración de riesgo residual
- Siguiente prueba programada
| Servicio crítico | RTO/RPO | Última prueba | Resultado | Problema abierto | Mensaje a la dirección |
|---|---|---|---|---|---|
| Plataforma de aprobación de pagos | 4h/1h | 2026-04-12 | Aprobado con condición | Lista de permitidos de la subred de recuperación del relé de correo | Aprobación básica de pagos restaurada dentro del objetivo, remediación del flujo de notificaciones en curso |
| Portal de clientes | 8h/2h | 2026-03-20 | Fallo | La restauración de la base de datos superó el RTO en 90 minutos | Se requiere mejora de capacidad y del proceso de restauración |
| Recuperación del proveedor de identidad | 2h/15m | 2026-04-05 | Aprobado | Ninguno | Respalda la recuperación de servicios críticos dependientes |
Este estilo de informe crea un puente entre los equipos técnicos, los auditores y la dirección. También respalda la revisión por la dirección del SGSI y la supervisión de resiliencia bajo NIS2 y DORA.
Lista de verificación práctica de auditoría para los próximos 30 a 90 días
Si su auditoría se aproxima, empiece por las evidencias que ya tiene y cierre primero las deficiencias de mayor riesgo.
- Identifique todos los sistemas Críticos y de Alto impacto a partir del BIA.
- Confirme el RTO y el RPO de cada sistema crítico.
- Verifique que cada sistema crítico aparece en el Calendario Maestro de Copias de Seguridad.
- Confirme las ubicaciones de copia de seguridad, incluidos repositorios locales, en la nube, inmutables o segregados.
- Seleccione al menos una prueba de restauración reciente por servicio crítico o programe una prueba de inmediato.
- Asegúrese de que los registros de pruebas de restauración muestran alcance, marcas de tiempo, conjunto de copias de seguridad, resultado, RTO/RPO alcanzado y validación.
- Obtenga la aprobación formal del propietario de negocio para la recuperación a nivel de aplicación.
- Valide la seguridad después de la restauración, incluidos control de acceso, registro de eventos, supervisión, secretos, certificados y exposición a vulnerabilidades.
- Asigne las evidencias al Registro de Riesgos y a la SoA.
- Registre los problemas en CAPA, asigne propietarios y supervise la nueva prueba.
- Resuma los resultados para la revisión por la dirección.
- Prepare una vista de cumplimiento cruzado para conversaciones de auditoría sobre ISO 27001:2022, NIS2, DORA, NIST CSF y COBIT 2019.
Si no puede completar todos los elementos antes de la auditoría, sea transparente. Los auditores suelen responder mejor a una deficiencia documentada con un plan de acción correctiva que a afirmaciones vagas de madurez.
Haga de las pruebas de restauración su evidencia de resiliencia más sólida
Las pruebas de copias de seguridad y restauración son una de las formas más claras de demostrar resiliencia operativa. Son tangibles, medibles, relevantes para la organización y están directamente conectadas con ISO 27001:2022, NIS2, DORA, NIST, COBIT 2019, informes al Consejo de Administración, aseguramiento de clientes y expectativas de aseguradoras.
Pero solo si se documentan correctamente.
Clarysec ayuda a las organizaciones a convertir las operaciones de copia de seguridad en evidencias listas para auditoría mediante la Política de Copias de Seguridad y Restauración, la Política de Copias de Seguridad y Restauración para pymes, la Política de Continuidad del Negocio y Recuperación ante Desastres para pymes, Zenith Blueprint y Zenith Controls.
Su siguiente paso práctico es sencillo. Elija un servicio crítico esta semana. Ejecute una prueba de restauración frente a su RTO y RPO aprobados. Documente el resultado. Asígnelo al Registro de Riesgos y a la SoA. Registre cada lección aprendida.
Si quiere que ese proceso sea repetible en ISO 27001:2022, NIS2, DORA, NIST y COBIT 2019, el toolkit de Clarysec le proporciona la estructura para demostrar la recuperación sin construir desde cero un laberinto de cumplimiento.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
