Continuidad de negocio en el ENS: medidas [op.cont]
Cómo implantar un plan de continuidad que cumpla op.cont.1, op.cont.2 y op.cont.3 del ENS: análisis de impacto, plan y pruebas documentadas.
La familia op.cont del Anexo II cubre la continuidad del servicio y es de las más exigentes en categoría Media y Alta. No basta con tener un documento titulado “Plan de Continuidad”: el ENS pide análisis de impacto (BIA), plan probado y evidencias de pruebas recientes. Es la familia donde aparecen con más frecuencia no conformidades mayores.
Qué exige el ENS
Tres medidas:
- op.cont.1 — Análisis de impacto (BIA).
- op.cont.2 — Plan de continuidad del servicio.
- op.cont.3 — Pruebas periódicas.
Según categoría:
| Básica | Media | Alta | |
|---|---|---|---|
| BIA | Recomendado | Obligatorio | Obligatorio con detalle |
| Plan | Básico | Formal | Formal + pruebas reforzadas |
| Pruebas | — | Anuales | Documentadas, al menos anuales, con escenario |
1. Análisis de impacto (BIA)
El BIA identifica, para cada servicio o proceso del alcance ENS:
- Tiempo máximo tolerable de interrupción (MTD).
- Objetivo de tiempo de recuperación (RTO): cuánto puede estar caído.
- Objetivo de punto de recuperación (RPO): cuánta pérdida de datos es admisible.
- Impacto económico, reputacional y operativo de una interrupción.
- Dependencias (personal clave, proveedores, infraestructura).
Sin BIA no puedes definir un plan sensato: los tiempos de recuperación se fijan al aire. Una plantilla típica en hoja de cálculo, con 1 fila por proceso y columnas para las variables anteriores, basta.
2. Plan de continuidad
El plan documenta cómo la organización mantiene o recupera los servicios críticos ante un incidente mayor. Contenidos mínimos:
a) Ámbito y supuestos
Qué servicios cubre, qué escenarios se han considerado (caída de CPD principal, ransomware, ataque DDoS, corte de proveedor cloud, corte de comunicaciones, indisponibilidad de personal clave).
b) Estructura organizativa de crisis
- Comité de crisis y su convocatoria.
- Roles de emergencia y suplentes.
- Canales de comunicación primarios y alternos.
- Portavoces hacia externos.
c) Procedimientos de activación
Criterios concretos para activar el plan. Responsable de la decisión. Formato del anuncio interno.
d) Procedimientos de recuperación
Por servicio, los pasos para recuperarlo. Con timestamps estimados. Con referencia a runbooks técnicos.
e) Recuperación de datos
Cómo se restauran los datos, de qué fuente, en qué entorno. Plazos objetivo.
f) Vuelta a la normalidad
Cuándo se declara cerrado el incidente y se vuelve al modo ordinario.
g) Formación
Cómo se entrena al equipo y a los responsables. Periodicidad.
3. Pruebas periódicas
La exigencia que más problemas da. En Media es obligatorio ejecutar pruebas al menos anuales. En Alta, con mayor profundidad y alcance.
Tipos de prueba (de menor a mayor ambición):
- Walkthrough: revisión en mesa del plan con los roles implicados.
- Simulacro técnico parcial: restauración de backup, fail-over de un servicio.
- Simulacro funcional: uno o varios servicios se mueven al entorno de recuperación y se valida que funcionan.
- Full test: corte total del entorno principal y operación en el alternativo durante un tiempo significativo.
No hace falta empezar por el full test. Un walkthrough + una restauración trimestral + un simulacro funcional anual cumplen en Media.
Evidencias que el auditor pedirá
- BIA vigente y aprobado.
- Plan de continuidad con fecha y versión.
- Registro de pruebas con:
- Fecha y duración.
- Escenario.
- Participantes.
- Objetivo y criterios de éxito.
- Resultados y tiempos reales medidos.
- Hallazgos y acciones de mejora.
- Acciones de mejora implementadas tras cada prueba.
- Formación específica registrada.
Alineación con ISO 22301
Si quieres ir más allá del ENS, la norma ISO 22301 es el estándar internacional de continuidad de negocio. Implantar ISO 22301 cubre con holgura las exigencias del ENS y da marco formal. Para organizaciones grandes con continuidad como prioridad, es una inversión razonable.
Errores típicos
- Plan bonito, cero pruebas. No sirve.
- Pruebas sin registro. Si no está escrito, no existe.
- BIA hecho hace 4 años y nunca revisado. El entorno cambió.
- Dependencias externas no identificadas. Si tu SaaS crítico depende de un proveedor único sin alternativa, el plan no es realista.
- No involucrar a negocio. La continuidad no es solo TI: es operaciones, atención al cliente, comunicación, legal.
Presupuesto realista
La inversión para cumplir op.cont no es necesariamente enorme, pero requiere tiempo:
- BIA: 40–80 horas de trabajo la primera vez (gente interna + consultor).
- Plan de continuidad: 60–120 horas de redacción.
- Simulacro anual: 16–40 horas de preparación y ejecución por iteración.
Inversión técnica (infraestructura redundante, DR site, replicación) es otro capítulo y depende de la categoría y del apetito de riesgo.
Cloud nativo y continuidad
Si tu sistema corre en cloud con servicios gestionados (RDS Multi-AZ, S3 cross-region, etc.), buena parte de la continuidad técnica la heredas. Pero sigue siendo necesario:
- Documentar qué contratas y qué SLA ofrece.
- Probar los escenarios (incluido el extremo: caída regional entera).
- Tener runbooks escritos para la recuperación manual si alguna capa falla.
Heredar no es delegar: la responsabilidad final es tuya.
Recomendación final
Una continuidad razonable es sinónimo de madurez. Aunque partas de cero, con un BIA ligero, un plan de 30 páginas bien estructurado y un simulacro anual documentado, estás por encima de la media. Evitas no conformidades y, sobre todo, te preparas para cuando (no si) ocurra el incidente real.