Qué pide realmente ISO 27001 sobre copias de seguridad (A.8.13)
Tener copias de seguridad no significa automáticamente poder recuperar el negocio ante un desastre. Es común encontrar organizaciones con trabajos automáticos en estado "verde" y terabytes almacenados que, durante un incidente real, descubren que la restauración falla por corrupción, contraseñas perdidas, falta de configuraciones o copias cifradas por ransomware.
En la norma ISO/IEC 27001:2022, el control de referencia principal del Anexo A es A.8.13 (Information backup). Complementariamente, la guía práctica de ISO 27002 aporta orientación para su diseño e implementación.
Lo que NO impone ISO 27001: La norma no fija una frecuencia obligatoria (como "diaria"), una retención única ni una tecnología concreta (como la regla 3-2-1). Exige que las copias se mantengan, protejan y prueben de acuerdo con la gestión de riesgos y las necesidades del negocio.
Distinciones clave: Backup ≠ Continuidad ≠ Redundancia ≠ Archivo
Para evitar errores de diseño en la información documentada del SGSI, es necesario precisar estos cuatro conceptos:
| Concepto | Propósito Principal | Limitaciones / Matiz Técnico |
|---|---|---|
| Backup (Copia de seguridad) | Conservar versiones recuperables de datos e información para restaurar tras pérdida o corrupción. | Un backup no restaura automáticamente la infraestructura ni garantiza la continuidad por sí solo. |
| Continuidad del negocio / DR | Mantener o restablecer los servicios y procesos críticos dentro de plazos aceptables. | Requiere personas, infraestructura, licencias, procedimientos y comunicaciones además de datos. |
| Redundancia (ej. RAID, Clúster) | Aumentar la disponibilidad y tolerancia a fallos de hardware en tiempo real. | Si un archivo se borra o se corrompe en producción, la redundancia replica el error inmediatamente. |
| Archivado | Conservar datos históricos a largo plazo por motivos legales, fiscales o normativos. | No está optimizado para la rápida restauración operativa de servicios activos. |
RPO y RTO: cómo definirlos según las necesidades del negocio
El diseño técnico de las copias de seguridad debe responder a dos métricas fundamentales fijadas por la dirección:
- RPO (Recovery Point Objective - Objetivo de Punto de Recuperación): La pérdida máxima de datos admisible expresada en tiempo. Determina la frecuencia necesaria de las copias (ejemplo: si el RPO es de 4 horas, se requiere generar puntos de restauración al menos cada 4 horas).
- RTO (Recovery Time Objective - Objetivo de Tiempo de Recuperación): El tiempo máximo aceptable para restablecer el servicio tras la interrupción. El backup influye en el RTO, pero la velocidad total de recuperación depende también del ancho de banda, la automatización y la infraestructura disponible.
Error habitual: IT no debe fijar el RPO/RTO en función de lo que la herramienta actual realiza por defecto ("es diario porque el software corre de noche"). Debe derivarse del impacto de negocio y diseñar la arquitectura para cumplirlo.
Metodología de 15 pasos para diseñar la política de backup
Al implementar el SGSI siguiendo la implementación ISO 27001 paso a paso, estructurar la política en 15 pasos asegura su validez operativa:
Definir el alcance de la información
Identificar qué bases de datos, archivos, imágenes de sistemas, configuraciones y servicios SaaS deben respaldarse.
Clasificar la criticidad
Asignar niveles de criticidad (alta, media, baja) para priorizar las ventanas de copia y restauración.
Fijar el RPO por servicio
Documentar el tiempo máximo de pérdida de datos tolerable acordado con el propietario de la información (data owner).
Alinear el RTO con la continuidad
Asegurar que los procedimientos de extracción e ingesta de datos permitan cumplir los tiempos de restauración.
Seleccionar el tipo de copia
Combinar esquemas completos (Full), incrementales, diferenciales o snapshots según la capacidad disponible.
Diseñar la frecuencia de copia
Establecer la programación periódica (continua, horaria, diaria) necesaria para garantizar el RPO.
Establecer los plazos de retención
Definir cuánto tiempo se conservan las copias diarias, semanales o mensuales por exigencias operativas y legales.
Garantizar la separación de entornos
Aislar el almacenamiento de backups respecto del entorno de producción principal para evitar compromisos simultáneos.
Proteger la confidencialidad (Cifrado)
Cifrar las copias en reposo y en tránsito, limitando el acceso mediante autenticación robusta (MFA) y control de accesos.
Proteger la integridad
Generar y validar verificaciones criptográficas (hashes/checksums) para asegurar que los archivos no sufran alteraciones.
Monitorizar trabajos y gestionar fallos
Configurar alertas e integrar los errores de copia en el sistema de ticketing con SLAs de resolución asignados.
Ejecutar pruebas de restauración (Restore Testing)
Realizar ensayos periódicos de restauración real en entornos aislados para validar la funcionalidad de los datos.
Registrar y conservar evidencias
Documentar los informes de pruebas, logs de ejecución y actas de restauración para auditorías internas y externas.
Asignar roles y responsabilidades
Definir quién aprueba la política, quién opera los trabajos, quién custodia las claves y quién audita el control.
Gestionar excepciones y revisiones
Documentar los sistemas que no puedan cumplir la política formal, justificando controles compensatorios y fechas de caducidad.
Comparativa técnica: Full, Incremental, Snapshots, Inmutabilidad y 3-2-1
Existen múltiples estrategias tecnológicas para implementar la política de backups. Es clave conocer sus fortalezas y límites:
- Regla 3-2-1: Recomendación clásica de ingeniería que sugiere mantener 3 copias de los datos, en 2 medios distintos, con 1 de ellas ubicada fuera de la sede (offsite). Aunque muy utilizada, no es un requisito textual de ISO 27001.
- Snapshots: Útiles para congelar estados de volumen rápidamente, pero si residen en la misma cabina o cuenta cloud que la producción, no constituyen una copia independiente ante una caída total de la plataforma.
- Almacenamiento Inmutable (Object Lock / WORM): Impide que los datos almacenados puedan ser modificados o eliminados durante un periodo fijado, protegiendo las copias de seguridad frente a ataques de ransomware o intentos de borrado malicioso por administradores comprometidos.
Copias de seguridad en Cloud, plataformas SaaS e Infraestructura como Código
El uso de entornos en la nube exige adaptar la política a la responsabilidad compartida:
Servicios SaaS (Microsoft 365, Google Workspace, GitHub, Jira)
Los proveedores SaaS garantizan la disponibilidad de la plataforma, pero la protección y retención a largo plazo de la información del cliente recae en la organización. Confiar únicamente en la papelera de reciclaje o retención nativa suele provocar pérdidas irreversibles tras borrados accidentales o incidentes.
Infraestructura como Código (IaC) y configuraciones
Un error común es respaldar los datos de las bases de datos pero no la configuración de redes, firewalls, repositorios de código, manifiestos de Terraform o registros DNS. Sin la copia de las configuraciones y scripts de despliegue, el tiempo de reconstrucción del entorno (RTO) se multiplica exponencialmente.
Protección contra Ransomware y gestión segura de claves de cifrado
Los ataques modernos de ransomware buscan activamente las consolas de copia de seguridad y los repositorios de backup para destruirlos antes de cifrar el entorno de producción.
Para mitigar este riesgo, la política debe exigir: segregación de cuentas administrativas (las credenciales de producción no deben tener permisos de borrado en el repositorio de copias), autenticación multifactor (MFA) obligatoria, almacenamiento inmutable y la existencia de copias aisladas (air-gapped u offline).
Gestión de claves: Cifrar las copias de seguridad es esencial para preservar la confidencialidad. Sin embargo, si las claves o certificados de cifrado se almacenan dentro del mismo servidor que se destruye en el incidente, las copias quedan inutilizables. La custodia y copia de seguridad de las claves debe gestionarse en un almacén de claves (KMS/Vault) aislado.
Ejemplo práctico completo de política de copias de seguridad
A continuación se presenta un modelo de política temática redactado para un entorno empresarial:
POLÍTICA TEMÁTICA: COPIAS DE SEGURIDAD Y RECUPERACIÓN DE DATOS (POL-IT-004)
1. Propósito: Garantizar la disponibilidad e integridad de la información y sistemas de la organización mediante la creación, custodia, protección y prueba periódica de copias de seguridad.
2. Alcance: Aplica a todos los sistemas de información, bases de datos de producción, servicios en la nube (SaaS/IaaS), configuraciones de red e infraestructura gestionados por la organización.
3. Responsabilidades:
- Propietario del servicio (Service Owner): Clasifica la información y establece los requisitos de RPO y RTO.
- Administrador de Sistemas / IT: Ejecuta, supervisa y documenta los trabajos de copia de seguridad y las pruebas de restauración.
- Responsable de Seguridad (CISO): Define los controles de cifrado, acceso e inmutabilidad de las copias.
4. Requisitos de Ejecución y Retención:
- Sistemas de Criticidad Alta (Tier 1): Copias de seguridad incrementales cada 4 horas (RPO = 4h) y completas semanales. Retención de 90 días. Almacenamiento inmutable habilitado.
- Sistemas de Criticidad Media (Tier 2): Copias de seguridad diarias (RPO = 24h) con retención de 30 días.
5. Seguridad y Separación: Todas las copias de seguridad deberán cifrarse en reposo mediante algoritmo AES-256. Las credenciales de acceso al repositorio de copias serán independientes del directorio activo principal y requerirán MFA.
6. Pruebas de Restauración: Se ejecutará una prueba de restauración real en entorno de pruebas de forma trimestral para sistemas de Tier 1 y semestral para Tier 2, registrando el informe de evidencia correspondiente.
7. Gestión de Excepciones: Cualquier desviación debe solicitarse mediante el procedimiento formal de excepciones, contando con la aprobación del CISO y la fijación de un control compensatorio temporal.
Cómo auditar la política de backup y definición de métricas eficaces
Al evaluar el control dentro del proceso de evaluación del desempeño del SGSI, el auditor debe cotejar el inventario de activos con la configuración real de los trabajos de copia.
Métricas de desempeño para la política de backups
- Porcentaje de cobertura: Porcentaje de activos de información críticos respaldados según la política (Objetivo: 100 %).
- Tasa de éxito de pruebas de restauración (Restore Success Rate): Porcentaje de ensayos de prueba en los que los datos se recuperaron sin errores y de forma funcional.
- Desviaciones de RPO (RPO Compliance Rate): Número de trabajos de copia fallidos que superaron la ventana de pérdida de datos permitida.
- Tiempo real de restauración (RTO Observado): Medición del tiempo transcurrido durante la restauración de prueba frente al RTO objetivo.
Normas de referencia: ISO/IEC 27031:2025 e ISO/IEC 27040:2024
Para profundizar en los aspectos normativos y técnicos de esta política, consulta:
- ISO/IEC 27031:2025: Orientación sobre la preparación de las tecnologías de la información y la comunicación para la continuidad del negocio, ayudando a integrar las copias de seguridad dentro de la resiliencia organizativa.
- ISO/IEC 27040:2024: Estándar enfocado en la seguridad del almacenamiento, ofreciendo directrices sobre el cifrado de medios, saneamiento y protección de arquitecturas de almacenamiento de copias.
Errores frecuentes en la gestión de copias de seguridad
| Práctica Errónea | Impacto / Riesgo | Solución Recomendada |
|---|---|---|
| Confiar en el estado "verde" del job sin probar la restauración. | Los archivos copiados pueden estar corruptos o ser inoperables. | Establecer un calendario de pruebas de restauración periódicas (restore tests). |
| Usar la misma cuenta de administrador para producción y backup. | Si la cuenta es comprometida por ransomware, se borran las copias. | |
| Olvidar hacer copias de seguridad de servicios SaaS. | Pérdida de correos, repositorios o tareas ante borrados o ataques. | Contratar o configurar soluciones de backup dedicadas para SaaS. |
| No guardar copias de las claves de cifrado en lugar seguro. | Incapacidad para descifrar las copias durante la recuperación del desastre. | Custodiar las claves en un KMS aislado con procedimiento break-glass. |
Preguntas frecuentes (FAQ)
¿ISO 27001 exige implementar la regla 3-2-1 obligatoriamente?
No. ISO/IEC 27001 no impone la regla 3-2-1 de forma explícita. La norma exige que las copias de seguridad (control A.8.13) estén adecuadamente protegidas, separadas e inspeccionadas conforme a los riesgos de la organización. La regla 3-2-1 es una buena práctica de ingeniería ampliamente aceptada.
¿Un snapshot en la nube sustituye a un backup?
Un snapshot aporta velocidad de recuperación, pero si reside dentro del mismo volumen o cuenta sin aislamiento de permisos ni inmutabilidad, no sustituye a un backup independiente ante compromisos de la cuenta o borrados catastróficos.
¿Con qué frecuencia deben probarse las restauraciones?
ISO 27001 exige realizar pruebas de restauración de forma regular, pero no fija una frecuencia universal. Las organizaciones suelen realizar pruebas de archivos individuales mensualmente y ejercicios de restauración completa trimestral o semestralmente según la criticidad del servicio.
Checklist de verificación para la política de backups
- [ ] Política de copias de seguridad formalmente documentada y aprobada.
- [ ] Alcance definido especificando sistemas, datos, configuraciones y SaaS.
- [ ] Responsabilidades asignadas entre propietarios de información y administradores IT.
- [ ] RPO y RTO definidos por criticidad de servicio.
- [ ] Cifrado de copias de seguridad en reposo y en tránsito habilitado.
- [ ] Separación lógica o física entre entorno de producción y almacenamiento de copias.
- [ ] Inmutabilidad o protección contra ransomware configurada en repositorios clave.
- [ ] Sistema de alertas ante fallos de copia integrado con escalado de tickets.
- [ ] Calendario de pruebas de restauración programado y ejecutado con evidencias conservadas.
Una política de backup bien diseñada conecta riesgo, continuidad, tecnología, evidencia y auditoría. Si quieres profundizar en cómo gobernar este tipo de controles dentro de un SGSI, puedes continuar con Analista GRC: Gobernanza de IT, Riesgo y Cumplimiento.
Cursos recomendados de ISO 27001 y Ciberseguridad
Analista GRC. Gobernanza de IT, Riesgo y Cumplimiento.
Gobernanza de IT, Riesgo y Cumplimiento. Perfil corporativo en alza.
Ver curso GRC
Prepara Todas las Certificaciones ISO 27001, con Práctica.
Prepárate para todas las certificaciones ISO 27001 con práctica real.
Ver curso ISO 27001