OP.CONT.3 Pruebas periódicas

☑️Aplicación de la medida

De acuerdo al ANEXO II, 2 Selección de medidas de seguridad, la medida de seguridad OP.CONT.3 Pruebas periódicas sí aplica dada la categoría de seguridad del sistema.

Documentos de referencia

• ISO/IEC 27000:
  • 27031:2011 - Guidelines for information and communication technology readiness for business continuity
  • 27002:2013:
    • 17.1.3 - Verify, review and evaluate information security continuity
• NIST SP 800-53 rev4:
  • [CP-4] Contingency Plan Testing
  • [CP-3] Contingency Training
• Otras referencias:
  • ISO 22301:2019 - Security and resilience — Business continuity management systems
  • NIST SP 800-34 Rev.1 - Contingency Planning Guide for Federal Information Systems
  • FDA Cybersecurity in Medical Devices: Quality System Considerations

Guía de implantación

186. El plan de continuidad estará sujeto a pruebas periódicas que permitan comprobar su efectividad y detectar deficiencias en su diseño o implementación.

Las pruebas periódicas incluirán aspectos como:

• Disponibilidad e integridad de los respaldos
• Funcionalidad de los sitios alternativos
• Coordinación entre los equipos
• Procedimientos de comunicación
• Tiempos de ejecución de los procedimientos de recuperación

Implementación en Legit Health Plus

Marco de testing de continuidad

El programa de pruebas periódicas de Legit Health Plus está diseñado para validar la efectividad del plan de continuidad, garantizar que los RTO/RPO definidos se pueden cumplir, y mantener la preparación del equipo para situaciones reales de crisis.

Objetivos del programa de testing

• Validar RTO/RPO: Confirmar que se cumplen objetivos de 30 min RTO y 5 min RPO
• Verificar procedimientos: Asegurar que todos los procedimientos documentados funcionan
• Entrenar equipos: Mantener competencias del personal en respuesta a crisis
• Detectar gaps: Identificar puntos débiles antes de que ocurran incidentes reales
• Cumplir regulaciones: Satisfacer requisitos de testing de FDA, MDR y NIS2

Tipos de pruebas implementadas

Pruebas técnicas automatizadas

• Backup recovery tests: Diarios, automáticos
• Failover tests: Semanales, programados fuera de horas de servicio
• Database replication tests: Continuos, monitorización 24×7

Ejercicios de simulación

• Table-top exercises: Trimestrales, para management y coordinadores
• Technical drills: Mensuales, para equipos técnicos
• Full disaster simulations: Semestrales, end-to-end con todos los equipos

Programa de pruebas estructurado

Cronograma anual de testing

Enero:

• Technical Drill: Fallo base datos principal
• Backup Recovery Test: Full restore Q4 data
• Table-top: Incidente prolongado fin de semana

Febrero:

• Automated Tests: Continuos
• Communication Drill: Cascade de alertas

Marzo:

• Technical Drill: Fallo servicio diagnóstico IA
• Table-top Exercise: Decisiones sobre modo degradado
• Quarterly Review: Análisis métricas Q1

Abril:

• Full Simulation: Fallo multi-región AWS
• Backup Recovery Test: Point-in-time recovery

Mayo:

• Technical Drill: Fallo conectividad principal
• Communication Test: Notificación autoridades

Junio:

• Semi-annual BCP Review: Actualización plan
• Table-top: Coordinación con terceros críticos

Julio:

• Full Simulation: Cyberattack + Recovery
• Technical Drill: Activación sitio respaldo

Agosto:

• Vacation Coverage Test: Equipos reducidos
• Communication Drill: Gestión de crisis en verano

Septiembre:

• Technical Drill: Fallo integración EMR/HIS
• Table-top: Cumplimiento regulatorio en crisis
• Quarterly Review: Análisis métricas Q3

Octubre:

• Full Simulation: Escenario pandemia (trabajo remoto)
• Backup Recovery: Complete system restore

Noviembre:

• Technical Drill: Fallo múltiples componentes
• Annual BCP Audit: Revisión completa plan

Diciembre:

• Year-end Simulation: Preparación para holidays
• Annual Review: Métricas, mejoras, planificación

Niveles de pruebas por complejidad

Nivel 1 - Pruebas automáticas diarias

• Objetivo: Validar componentes básicos sin intervención manual
• Duración: < 30 minutos
• Impacto: Cero en operaciones normales

PRO-CONT-TEST-001: Pruebas automáticas diarias del plan de continuidad

Objetivo: Ejecutar validaciones automáticas diarias de componentes críticos del plan de continuidad sin impacto en operaciones normales.

Frecuencia: Diariamente a las 02:00 AM (horario con menor carga)

Duración total: < 30 minutos

Impacto en servicio: Ninguno (pruebas no invasivas)

Prueba 1: Integridad de backups

PRO-CONT-TEST-001-A: Verificación de integridad de backups de últimas 24 horas

Qué se verifica:

1. Obtención del último backup:
   • Identificar el backup más reciente (debe tener < 24 horas)
   • Registrar antigüedad del backup en horas
2. Validación de checksum:
   • Verificar la suma de verificación (checksum) del archivo de backup
   • Confirmar que el backup no está corrupto
   • Resultado: válido o inválido
3. Prueba de restauración parcial:
   • Restaurar una pequeña muestra de datos en entorno aislado
   • Verificar que la restauración completa exitosamente
   • No afecta al sistema de producción
   • Resultado: exitoso o fallido

Criterios de éxito:

• Checksum válido: SÍ
• Restauración parcial exitosa: SÍ
• Antigüedad del backup: < 24 horas

Estado de la prueba:

• PASS: Si checksum válido Y restauración parcial exitosa
• FAIL: Si cualquiera de las verificaciones falla
• ERROR: Si la prueba no puede ejecutarse (genera alerta inmediata)

Acción en caso de fallo:

• Generar alerta inmediata al equipo DevOps
• Escalar a DBA si no se resuelve en 30 minutos
• Investigar causa raíz del fallo de backup

Información registrada:

• Nombre de la prueba: 'backup_integrity'
• Timestamp de ejecución
• Validez del checksum
• Resultado de restauración parcial
• Antigüedad del backup en horas
• Estado final (PASS/FAIL/ERROR)

Prueba 2: Disponibilidad de sistemas de respaldo

PRO-CONT-TEST-001-B: Verificación de sistemas secundarios listos para failover

Sistemas verificados:

Sistema	Propósito	Verificaciones
diagnosis-service-standby	Servicio de diagnóstico IA de respaldo	Salud del servicio, sincronización de datos
database-read-replica	Réplica de lectura de PostgreSQL	Salud del servicio, sincronización de datos
auth-service-backup	Servicio de autenticación de respaldo	Salud del servicio, sincronización de datos

Qué se verifica para cada sistema:

1. Salud del sistema (health check):
   • Verificar que el sistema está ejecutándose
   • Verificar que responde a health checks
   • Verificar que recursos (CPU, memoria, disco) están en rangos normales
   • Resultado: saludable o no saludable
2. Estado de sincronización de datos:
   • Verificar que los datos están actualizados con el sistema primario
   • Medir retraso de replicación (debe ser < 5 segundos)
   • Confirmar que no hay errores de sincronización
   • Resultado: sincronizado o desincronizado
3. Evaluación de disponibilidad:
   • Sistema considerado "listo" si salud OK Y sincronización OK
   • Contar cuántos de los 3 sistemas están listos

Criterios de éxito:

• Sistemas verificados: 3
• Sistemas listos: 3 (100%)
• Todos los sistemas deben estar saludables y sincronizados

Estado de la prueba:

• PASS: Si los 3 sistemas están listos (health OK + sync OK)
• FAIL: Si algún sistema no está listo

Acción en caso de fallo:

• Identificar qué sistema(s) no están listos
• Generar alerta con detalles específicos
• DevOps debe investigar y corregir dentro de 2 horas
• Si no se resuelve, escalar a arquitecto de sistemas

Información registrada:

• Nombre de la prueba: 'failover_readiness'
• Timestamp de ejecución
• Número de sistemas verificados: 3
• Número de sistemas listos
• Detalles por sistema (nombre, salud, sincronización, disponibilidad)
• Estado final (PASS/FAIL)

Nivel 2 - Ejercicios técnicos mensuales

• Objetivo: Validar procedimientos técnicos específicos con equipos
• Duración: 1-2 horas
• Impacto: Mínimo, fuera de horario de servicio cuando sea posible

Nivel 3 - Simulaciones completas semestrales

• Objetivo: Validar plan completo con todos los stakeholders
• Duración: 4-8 horas
• Impacto: Planificado y comunicado con antelación

Procedimientos de testing detallados

Technical Drill: Fallo del servicio de diagnóstico IA

Preparación (1 semana antes)

1. Notificación al equipo: DevOps, Development, QA
2. Preparación del entorno: Copia de seguridad del estado actual
3. Definición del escenario: Fallo específico a simular
4. Criterios de éxito: RTO ≤ 30 min, RPO ≤ 5 min, funcionalidad completa

Ejecución del drill

Paso 1: Simulación del fallo (T+0)

Acciones técnicas de simulación:

Opción A - Fallo completo (recomendado para drill mensual):

• Escalar el deployment del servicio primario de diagnóstico a 0 réplicas
• Esto simula un fallo total del servicio (caída completa)
• Permite validar la detección automática y procedimientos de failover

Opción B - Degradación de rendimiento:

• Reducir límites de memoria del contenedor de diagnóstico a 128Mi
• Esto provoca problemas de rendimiento sin detener el servicio
• Genera alertas de recursos sin causar indisponibilidad total
• Útil para validar umbrales de alertas

Responsable: DevOps Lead
Registro: Documentar en bitácora del drill qué opción se usó y a qué hora

Paso 2: Detección y alerta (T+0 a T+3)

• Verificar que alertas se generan automáticamente
• Confirmar notificaciones al equipo de respuesta
• Validar escalado según procedimientos

Paso 3: Diagnóstico inicial (T+3 a T+8)

• Equipo técnico identifica fallo del servicio
• Evaluación de opciones: reparación vs. failover
• Decisión de activar failover automático

Paso 4: Activación de respaldo (T+8 a T+20)

Acciones técnicas de activación del respaldo:

1. Activar servicio secundario:

   • Escalar el deployment del servicio secundario de diagnóstico a 3 réplicas
   • Tiempo estimado: 30-60 segundos para que los pods estén listos
   • Verificar que los 3 pods reportan estado "Running"

2. Redirigir tráfico al servicio secundario:

   • Modificar el selector del load balancer de diagnóstico
   • Cambiar de apuntar a 'diagnosis-primary' a 'diagnosis-secondary'
   • El cambio es inmediato, pero puede tardar 5-10 segundos en propagarse

3. Verificar conectividad con base de datos:

   • Desde un pod del servicio secundario, hacer health check a la réplica de lectura de BD
   • Confirmar respuesta exitosa (HTTP 200)
   • Si falla, verificar configuración de red y DNS

Responsable: DevOps Engineer
Tiempo objetivo: Completar estos 3 pasos en < 5 minutos
Registro: Anotar tiempo real que tomó cada paso en bitácora del drill

Paso 5: Verificación funcional (T+20 a T+30)

• Ejecutar suite de tests de diagnóstico automatizados
• Validar con imágenes de prueba conocidas
• Confirmar que auditoría y logging funcionan

Criterios de evaluación

Éxito completo (Target):

• RTO ≤ 30 minutos ✅
• RPO = 0 (sin pérdida de datos) ✅
• Funcionalidad completa restaurada ✅
• Todos los procedimientos seguidos ✅

Éxito parcial (Aceptable):

• RTO ≤ 45 minutos ⚠️
• RPO ≤ 5 minutos ⚠️
• Funcionalidad crítica restaurada ⚠️
• Desviaciones menores de procedimiento ⚠️

Fallo (Requiere acción correctiva):

• RTO > 45 minutos ❌
• Pérdida de datos clínicos ❌
• Funcionalidad crítica no disponible ❌
• Procedimientos no seguidos ❌

Table-top Exercise: Gestión de crisis prolongada

Scenario setup

Escenario: Ataque DDoS sostenido + Fallo hardware

Contexto: Miércoles 15:30, hora pico de consultas ambulatorias Situación inicial:

• DDoS ataque detectado a las 15:00
• Medidas de mitigación iniciales han fallado
• A las 15:25 falla servidor principal de base de datos
• 85 profesionales sanitarios conectados
• 23 diagnósticos en proceso

Información adicional disponible durante ejercicio:

• Proveedor cloud reporta "widespread issues" en región
• Cliente importante (Hospital Clínico) pregunta por status
• Medios locales empiezan a reportar "problemas técnicos"
• Es época de gripe, alta demanda de servicios dermatológicos

Participantes y roles

• Crisis Manager (CTO): Toma decisiones estratégicas
• Medical Safety Officer (CMO): Evalúa impacto clínico
• Communications Lead: Gestiona comunicación externa
• Technical Lead (DevOps): Lidera respuesta técnica
• Legal/Compliance: Evalúa obligaciones regulatorias

Desarrollo del ejercicio (90 minutos)

Fase 1: Evaluación inicial (15 min)

• Cada participante recibe briefing de su perspectiva
• Discusión grupal sobre severidad e impacto
• Decisión sobre activación del plan de continuidad

Fase 2: Primeras decisiones (20 min)

• ¿Activar modo degradado inmediatamente?
• ¿Qué comunicar al Hospital Clínico?
• ¿Cuándo notificar a AEMPS/INCIBE?
• Asignación de responsabilidades inmediatas

Fase 3: Complicaciones adicionales (25 min)

• T+30: Respaldo principal también afectado
• T+45: Medio de comunicación llama pidiendo statement
• T+60: Dermatólogo reporta caso urgente de posible melanoma
• Reevaluación de decisiones y estrategia

Fase 4: Resolución y recuperación (20 min)

• T+75: Servicios parcialmente restaurados
• Decisiones sobre comunicación post-incidente
• Planificación de análisis post-mortem
• Evaluación de lecciones aprendidas

Fase 5: Debrief (10 min)

• ¿Qué decisiones fueron correctas?
• ¿Qué información faltó?
• ¿Qué procedimientos necesitan mejora?

Pruebas de componentes específicos

Testing de backups y recuperación

Backup integrity testing (automatizado diario)

PRO-CONT-TEST-002: Verificación automática de integridad de backups

Objetivo: Validar que los backups de la base de datos clínica pueden restaurarse correctamente y contienen datos íntegros.

Frecuencia: Diaria (automática a las 02:00 AM)

Duración: 15-20 minutos

Ubicación de backups: /backups/legit-health/

Log de ejecución: /var/log/backup-test.log

Pasos del procedimiento:

1. Identificación del backup más reciente:
   • Buscar en el directorio de backups el archivo .sql.gz más reciente
   • Si no se encuentra ningún backup: ERROR - Alerta inmediata al equipo DevOps
   • Registrar en log qué archivo de backup se va a verificar
2. Creación de entorno de prueba aislado:
   • Crear base de datos temporal bcp_test_restore
   • Esta DB es solo para testing, completamente aislada de producción
   • Si no se puede crear: ERROR - Problema con servidor de BD, escalar a DBA
   • No afecta a las bases de datos de producción
3. Restauración del backup:
   • Descomprimir y restaurar el backup en la base de datos temporal
   • Si la restauración falla: ERROR - Backup corrupto o incompleto
   • Eliminar DB temporal y registrar fallo
   • Alerta crítica: backup no utilizable para recuperación
4. Verificación de integridad de datos críticos:
   • Contar registros en tablas principales:
     • Pacientes (patients): Número total de pacientes registrados
     • Estudios (patient_studies): Número total de estudios dermatológicos
     • Diagnósticos (diagnostic_results): Número total de resultados de IA
5. Validación de umbrales mínimos:
   • Pacientes: Debe haber ≥ 100 registros
   • Estudios: Debe haber ≥ 1,000 registros
   • Lógica: Si los números son inferiores a estos umbrales, indica:
     • Backup incompleto
     • Restauración parcial
     • Corrupción de datos
   • Si falla validación: ERROR - Backup no confiable
   • Registrar los counts obtenidos en el log
6. Limpieza del entorno de prueba:
   • Eliminar la base de datos temporal bcp_test_restore
   • Liberar recursos del servidor
   • Completar en todos los casos (éxito o error)
7. Registro y reporte de resultados:
   • En caso de éxito:
     • Registrar en log: timestamp, estado EXITOSO, y counts de cada tabla
     • Ejemplo: "2025-01-15 02:18:45: Test de backup EXITOSO - P:15,847 S:124,392 D:98,234"
     • Enviar métricas al sistema de monitorización
     • Actualizar dashboard con último test exitoso
   • En caso de error:
     • Registrar en log: timestamp, tipo de error, detalles
     • Generar alerta crítica al equipo DevOps
     • No actualizar métricas de éxito

Criterios de éxito:

• Backup encontrado: SÍ
• Restauración exitosa: SÍ
• Pacientes ≥ 100: SÍ
• Estudios ≥ 1,000: SÍ
• DB temporal eliminada: SÍ

Métricas reportadas al sistema de monitorización:

• Estado del test: success/failure
• Número de pacientes restaurados
• Número de estudios restaurados
• Número de diagnósticos restaurados

Acciones en caso de fallo:

• Alerta inmediata al equipo DevOps (Slack, PagerDuty)
• Investigar causa raíz dentro de 1 hora
• Si el problema es con backups recientes, verificar:
  • Proceso de generación de backups
  • Espacio en disco
  • Permisos de archivos
  • Integridad del sistema de almacenamiento
• Escalar a DBA si no se resuelve en 2 horas

Responsable: Ejecución automática (cron job), monitoreo por DevOps Team

Full system restore testing (trimestral)

• Objetivo: Validar recuperación completa desde backup
• Entorno: Infraestructura de testing separada
• Duración: 4-6 horas
• Criterios éxito: Sistema completamente funcional, datos íntegros

Testing de failover automático

Database failover testing

PRO-CONT-TEST-003: Test automatizado de failover de base de datos

Objetivo: Validar que el procedimiento de promoción de read replica funciona correctamente y cumple los objetivos de tiempo de recuperación.

Frecuencia: Trimestral (cada 3 meses)

Duración: 15-30 minutos

Entorno: Entorno de pre-producción o ventana de mantenimiento programada

Infraestructura involucrada:

• Base de datos principal: legit-health-prod.cluster-xxx.eu-west-1.rds.amazonaws.com
• Réplica de lectura: legit-health-replica.cluster-yyy.eu-west-1.rds.amazonaws.com
• Región: eu-west-1 (Irlanda)

Procedimiento de ejecución del test:

Fase 1: Validación pre-test (0-2 min)

PRO-CONT-TEST-003-A: Verificación del estado inicial

Qué se verifica:

1. Estado de la base de datos principal:
   • Debe estar en estado "available" (disponible)
   • Si no está disponible: ABORTAR TEST - No se puede continuar sin estado inicial válido
2. Estado de la réplica de lectura:
   • Debe estar en estado "available" (disponible)
   • Si no está disponible: ABORTAR TEST - La réplica debe estar funcional antes del test
3. Lag de replicación:
   • Medir el retraso entre datos en primary vs replica
   • Umbral aceptable: < 1 segundo
   • Si el lag es > 1 segundo: ABORTAR TEST - Indica problema de replicación que debe resolverse primero
   • Ejemplo de lag alto: "Replication lag alto: 5.3s" - Investigar causa antes de continuar

Resultado: "✓ Estado inicial validado correctamente"

Fase 2: Simulación del fallo (2-3 min)

Acciones:

• Simular fallo de la base de datos principal
• En entorno de test: Detener temporalmente la instancia principal usando AWS Console o CLI
• Nota importante: En producción real, esto sería un fallo genuino, no una simulación
• Registro: Anotar timestamp exacto cuando se simula el fallo

---

Fase 3: Activación del failover (3-15 min)

PRO-CONT-TEST-003-B: Promoción de read replica a primary

Pasos técnicos:

1. Iniciar promoción:
   • Registrar timestamp de inicio del failover
   • Ejecutar comando de promoción en AWS RDS
   • Especificar identificador: 'legit-health-replica'
   • La réplica dejará de replicar y se convertirá en instancia primaria independiente
2. Espera de completado:
   • Monitorizar estado de la réplica en AWS
   • Esperar hasta que el estado sea 'available'
   • AWS RDS maneja automáticamente:
     • Finalización de replicación
     • Aplicación de transacciones pendientes
     • Cambio de modo a read-write
     • Actualización de configuración
3. Registro del tiempo:
   • Calcular tiempo total de failover (desde inicio hasta disponibilidad)
   • Objetivo: < 15 minutos
   • Este tiempo incluye todo el proceso de promoción

Resultado esperado: "✓ Read replica promocionada exitosamente"

---

Fase 4: Validación post-failover (15-20 min)

Qué se valida:

1. Nueva instancia primaria funcional:

   • Verificar que la antigua réplica ahora acepta operaciones de escritura
   • Confirmar que no está en modo recovery
   • Validar que endpoints están actualizados

2. Conectividad de aplicaciones:

   • Verificar que servicios pueden conectarse a la nueva primary
   • Probar operaciones de lectura y escritura
   • Validar que autenticación funciona correctamente

---

Fase 5: Generación de informe (20-25 min)

Métricas recolectadas:

• Tiempo total de failover (objetivo: < 15 min)
• Estado inicial (PASS/FAIL)
• Resultado de promoción (SUCCESS/ERROR)
• Conectividad de aplicaciones (OK/FAIL)
• Timestamp de inicio y fin

Informe del test:

• Resumen ejecutivo con resultado global
• Tiempos medidos vs objetivos
• Problemas encontrados (si los hay)
• Recomendaciones de mejora

Ejemplo de salida: "Test completado en 12.4 segundos"

Criterios de éxito:

• Estado inicial válido: SÍ
• Promoción exitosa: SÍ
• Tiempo de failover < 15 min: SÍ
• Conectividad de aplicaciones: SÍ
• Pérdida de datos: NO (RPO = 0)

Documentación post-test:

• Completar R-110-004 (Informe de prueba de continuidad)
• Incluir todos los tiempos medidos
• Registrar lecciones aprendidas
• Actualizar procedimientos si se identifican mejoras

Responsables:

• Ejecución: DBA + DevOps Lead
• Supervisión: CTO o Arquitecto de Sistemas
• Documentación: QA Lead

Métricas y evaluación de pruebas

KPIs de testing de continuidad

• Test Success Rate: % de pruebas que cumplen criterios de éxito
• RTO Achievement: Tiempo real vs. objetivo (30 min target)
• RPO Achievement: Pérdida de datos vs. objetivo (5 min target)
• Procedure Adherence: % procedimientos seguidos correctamente
• Team Response Time: Tiempo hasta activación de equipos
• Communication Effectiveness: Tiempo notificaciones críticas

Dashboard de métricas de BCP testing

PRO-CONT-TEST-004: Generación de informes de métricas de testing BCP

Objetivo: Generar informes periódicos sobre el desempeño de las pruebas del plan de continuidad para identificar tendencias, problemas recurrentes y áreas de mejora.

Fuente de datos: Historial de todas las pruebas BCP ejecutadas (diarias, mensuales, trimestrales, semestrales)

A. Informe trimestral de testing BCP

PRO-CONT-TEST-004-A: Reporte trimestral

Frecuencia: Trimestral (enero, abril, julio, octubre)

Responsable: QA Lead + DevOps Lead

Métricas incluidas en el informe:

Métrica	Descripción	Cálculo
Total de pruebas ejecutadas	Número total de pruebas BCP realizadas en el trimestre	Suma de todas las pruebas (diarias + mensuales + drill específico)
Tasa de éxito	Porcentaje de pruebas que cumplieron todos los criterios de éxito	(Pruebas exitosas ÷ Total pruebas) × 100
RTO promedio alcanzado	Tiempo promedio de recuperación en las pruebas de failover	Promedio de tiempos RTO medidos (objetivo: ≤ 30 min)
Violaciones de RPO	Número de casos donde hubo pérdida de datos superior al objetivo	Contar pruebas con RPO > 5 minutos
Áreas de mejora identificadas	Componentes o procedimientos que requieren optimización	Análisis cualitativo de fallos y retrasos

Ejemplo de informe trimestral:

• Período: Q1 2025 (Enero-Marzo)
• Total de pruebas: 95 (90 diarias + 3 mensuales + 2 drills completos)
• Tasa de éxito: 94.7% (90 de 95 pruebas exitosas)
• RTO promedio: 18.3 minutos (objetivo: ≤ 30 min) ✅
• Violaciones RPO: 1 caso (backup con lag de 8 minutos)
• Áreas de mejora:
  • Tiempo de notificación al equipo (actualmente 4 min, objetivo: 2 min)
  • Documentación de procedimientos de rollback

Distribución del informe: CTO, Management Team, Auditoría Interna

B. Análisis de tendencias de RTO

PRO-CONT-TEST-004-B: Tracking de tendencias de RTO

Objetivo: Monitorizar si los tiempos de recuperación están mejorando, estables o empeorando a lo largo del tiempo.

Análisis mensual de los últimos 12 meses:

Para cada mes se calcula:

• RTO promedio del mes: Promedio de todos los RTO medidos en ese mes
• RTO objetivo: 30 minutos (fijo)
• Varianza: Diferencia entre RTO real y objetivo (positivo = más lento, negativo = más rápido)

Ejemplo de análisis de tendencias:

Mes	RTO Promedio	Objetivo	Varianza	Tendencia
Ene 2025	22.5 min	30 min	-7.5 min	✅ Mejor que objetivo
Feb 2025	18.3 min	30 min	-11.7 min	✅ Mejorando
Mar 2025	25.1 min	30 min	-4.9 min	✅ Dentro de objetivo
Abr 2025	33.2 min	30 min	+3.2 min	⚠️ Por encima de objetivo

Interpretación:

• Tendencia positiva: RTO disminuyendo con el tiempo = Procedimientos mejorando
• Tendencia negativa: RTO aumentando = Investigar causas (complejidad, nuevos componentes, falta de práctica)
• Varianza consistentemente negativa: Sistema muy por encima del mínimo necesario
• Picos ocasionales: Identificar qué prueba específica causó el retraso

Uso del análisis:

• Validar que mejoras implementadas están funcionando
• Detectar degradación temprana antes de que sea crítica
• Justificar inversiones en automatización o mejoras de infraestructura

C. Identificación de patrones de fallos

PRO-CONT-TEST-004-C: Análisis de fallos recurrentes

Objetivo: Identificar qué componentes, momentos o condiciones causan más fallos en las pruebas BCP para priorizar mejoras.

Tipos de análisis realizados:

1. Puntos de fallo comunes:

• Analizar en qué fase del procedimiento ocurren más fallos
• Ejemplos:
  • "60% de fallos ocurren en validación de conectividad de aplicaciones"
  • "Promoción de réplica falla 15% del tiempo por lag de replicación"
  • "Backups corruptos representan 25% de fallos de integridad"

2. Patrones temporales de fallos:

• ¿Hay días de la semana o momentos del día con más fallos?
• Ejemplos:
  • "Pruebas los lunes tienen 2× más fallos (posiblemente por cambios de fin de semana)"
  • "Tests a las 02:00 AM más exitosos que a las 14:00 (menos carga)"

3. Confiabilidad por componente:

• Ranking de componentes por tasa de fallo
• Ejemplos:
  • "Servicio de diagnóstico IA: 98% confiabilidad"
  • "Base de datos PostgreSQL: 99.5% confiabilidad"
  • "Servicio de autenticación: 92% confiabilidad (necesita atención)"

Formato del análisis de patrones:

Análisis de Patrones de Fallos - Q1 2025
=========================================

PRUEBAS FALLIDAS: 5 de 95 (5.3%)

Puntos de Fallo Comunes:
1. Validación de conectividad (3 casos) - 60% de fallos
2. Lag de replicación alto (1 caso) - 20% de fallos
3. Backup corrupto (1 caso) - 20% de fallos

Patrones Temporales:
- Lunes: 3 fallos (mayor incidencia post-fin de semana)
- Resto de semana: 2 fallos distribuidos

Confiabilidad por Componente:
- Diagnosis Service: 100% (0 fallos)
- PostgreSQL DB: 98.9% (1 fallo por lag)
- Auth Service: 96.8% (3 fallos de conectividad)
- Backup System: 98.9% (1 backup corrupto)

RECOMENDACIONES:
1. Prioridad ALTA: Investigar problemas de conectividad Auth Service
2. Prioridad MEDIA: Mejorar monitoreo de replicación DB pre-test
3. Prioridad BAJA: Revisar proceso de backup semanal

Uso del análisis:

• Priorizar inversión en componentes menos confiables
• Ajustar horarios de pruebas para maximizar éxito
• Identificar necesidad de capacitación o mejora de procedimientos
• Justificar refuerzos de infraestructura redundante

Frecuencia del análisis: Trimestral, junto con informe PRO-CONT-TEST-004-A

Responsable: QA Lead con input de DevOps Team

Training y competencia del equipo

Programa de formación en continuidad

Formación inicial (nuevos empleados)

• BCP Overview: 2 horas - Marco general y responsabilidades
• Technical Procedures: 4 horas - Hands-on con procedimientos específicos
• Communication Protocols: 1 hora - Cadena de escalado y notificaciones
• Regulatory Requirements: 2 horas - Obligaciones MDR, FDA, NIS2

Formación recurrente (todo el personal)

• Quarterly Reviews: 1 hora - Actualización de procedimientos
• Annual Refresher: 4 horas - Revisión completa del plan
• Post-Incident Training: Variable - Lecciones de incidentes reales

Certificación de competencia

Requisitos de certificación BCP por rol

Objetivo: Garantizar que el personal clave tiene las competencias necesarias para ejecutar el plan de continuidad de negocio de forma efectiva.

Requisitos por rol

Rol	Requisitos de Certificación	Frecuencia de Renovación
Crisis Manager	• Liderar 2 table-top exercises exitosos • Participar en 1 simulación completa • Aprobar examen teórico (puntuación mínima: 80%) • Demostrar toma de decisiones bajo presión	Anual
Technical Response Team	• Ejecutar 3 technical drills exitosos • Demostrar competencia en herramientas críticas (Kubernetes, AWS, PostgreSQL) • Certificación específica por sistema crítico asignado • Evaluación práctica de procedimientos	Semestral (cada 6 meses)
Communication Team	• Participar en ejercicios de comunicación de crisis • Demostrar capacidad de redacción de comunicados críticos • Conocimiento de contactos regulatorios (AEMPS, AEPD) • Simulación de comunicación con stakeholders	Anual

Detalles de los requisitos:

Crisis Manager:

• Table-top exercises: Debe liderar exitosamente 2 ejercicios de mesa donde se simulan escenarios de crisis complejos. Evaluación basada en:

  • Toma de decisiones apropiadas
  • Coordinación de equipos
  • Comunicación efectiva
  • Gestión de tiempo bajo presión

• Simulación completa: Participar en al menos 1 simulación completa semestral como líder del comité de crisis

• Examen teórico: Evaluación escrita sobre:

  • Procedimientos del plan de continuidad
  • Roles y responsabilidades
  • Criterios de escalado
  • Requisitos regulatorios (ENS, MDR)
  • Puntuación mínima: 80%

Technical Response Team:

• Technical drills: Ejecutar exitosamente 3 ejercicios técnicos que incluyan:
  • Simulación de failover de servicios
  • Restauración de backups
  • Activación de sistemas de respaldo
  • Evaluación: Cumplir RTO/RPO objetivos
• Competencia en herramientas: Demostrar dominio de:
  • Kubernetes (kubectl, gestión de deployments)
  • AWS (RDS, EC2, CloudWatch)
  • PostgreSQL (backup/restore, replicación)
  • Herramientas de monitorización
• Certificación por sistema: Cada miembro debe estar certificado en al menos un sistema crítico:
  • Servicio de diagnóstico IA
  • Base de datos clínica
  • Servicio de autenticación
  • Infraestructura de red

Communication Team:

• Ejercicios de comunicación: Participar en simulaciones donde debe:
  • Redactar comunicados internos bajo presión
  • Comunicar con stakeholders externos
  • Gestionar comunicación en redes sociales durante crisis
  • Coordinar con equipo legal
• Comunicados críticos: Demostrar capacidad de redactar:
  • Notificaciones de incidente a clientes
  • Comunicación regulatoria (AEMPS notificación de indisponibilidad)
  • Comunicación interna al equipo y management
  • Evaluación: Claridad, precisión, tono apropiado
• Contactos regulatorios: Conocer y tener actualizados:
  • AEMPS (Agencia Española de Medicamentos): Notificación de incidentes que afecten dispositivos médicos
  • AEPD (Agencia Española de Protección de Datos): Notificación de brechas de seguridad
  • Contactos de emergencia en cada organización

Proceso de certificación:

1. Formación inicial en procedimientos BCP
2. Participación en número requerido de ejercicios
3. Evaluación formal (teórica y/o práctica)
4. Emisión de certificación con fecha de validez
5. Renovación periódica según frecuencia del rol

Registro de certificaciones: Mantener en R-110-005 (Registro de certificaciones BCP) con:

• Nombre del personal
• Rol asignado
• Fecha de certificación
• Fecha de expiración
• Ejercicios/exámenes completados
• Próxima renovación programada

Responsable del programa de certificación: QA Lead + CTO

Integración con gestión de incidentes reales

Conversión de test a respuesta real

El programa de testing debe estar diseñado para que, si durante una prueba se detecta un incidente real, se pueda convertir inmediatamente la respuesta de "test" a "real".

Sistema de detección durante testing

PRO-CONT-TEST-005: Conversión de test en incidente real

Contexto crítico: Durante la ejecución de un test o simulación del plan de continuidad, pueden descubrirse problemas reales que requieren respuesta inmediata. Este procedimiento define cómo identificar y gestionar esta situación.

Objetivo: Reconocer rápidamente cuando un "test" ha expuesto un incidente real y activar la respuesta de emergencia apropiada sin demora.

Indicadores de incidente real durante un test

Señales de alarma que indican que NO es solo un test:

Indicador	Descripción	Acción Requerida
Pérdida real de datos	Durante el test se detecta pérdida de datos clínicos genuina (no simulada)	🚨 CONVERSIÓN INMEDIATA
Quejas de clientes reales	Usuarios o profesionales sanitarios reportan problemas no relacionados con el test	🚨 CONVERSIÓN INMEDIATA
Fallos genuinos del sistema	Componentes productivos fallan de forma no intencional durante el test	🚨 CONVERSIÓN INMEDIATA
Indicadores de brecha de seguridad	Se detectan signos de acceso no autorizado, vulnerabilidades explotadas, o actividad maliciosa	🚨 CONVERSIÓN INMEDIATA

Ejemplos de escenarios:

Escenario 1 - Pérdida real de datos:

• Situación: Durante test de failover, se descubre que la réplica tiene 2 horas de lag en lugar de segundos
• Implicación: Si se procediera con la promoción, se perderían 2 horas de datos clínicos reales
• Acción: DETENER TEST, activar procedimiento de investigación de replicación

Escenario 2 - Quejas de clientes:

• Situación: Durante test de degradación de servicio, empiezan a llegar tickets de soporte de clientes reales
• Implicación: El "test" está afectando producción real
• Acción: DETENER TEST, restaurar servicio completo, investigar impacto

Escenario 3 - Fallos no intencionados:

• Situación: Al simular fallo del servicio A, inesperadamente el servicio B también falla
• Implicación: Existe un problema real de dependencias no documentado
• Acción: Evaluar impacto, decidir si continuar o convertir en incidente real

Escenario 4 - Brecha de seguridad:

• Situación: Durante test se detectan logs de intentos de acceso no autorizado
• Implicación: Posible ataque o vulnerabilidad activa
• Acción: CONVERSIÓN INMEDIATA, activar respuesta de seguridad

PRO-CONT-TEST-005-A: Procedimiento de conversión test → incidente real

Cuando detectar cualquiera de los indicadores anteriores:

🚨 ALERTA: INCIDENTE REAL DETECTADO DURANTE TEST

Paso 1: Notificación inmediata (0-2 minutos)

Anuncio a todos los participantes del test:

Mensaje tipo:

🚨 ATENCIÓN - CONVERSIÓN TEST → INCIDENTE REAL 🚨

El test BCP programado para [FECHA/HORA] ha detectado un INCIDENTE REAL.

Tipo de incidente: [Pérdida de datos / Fallo genuino / Brecha seguridad / Quejas clientes]

A partir de este momento:
✅ Este NO es un test
✅ Todas las acciones tienen consecuencias reales
✅ Se activan procedimientos de incidente real
✅ Se requiere documentación completa

Crisis Manager: [NOMBRE]
Canal de comunicación: #incident-response (NO #test-bcp)

[TIMESTAMP]

Medios de notificación:

• Anuncio verbal en llamada de coordinación
• Mensaje en canal de Slack correcto (#incident-response en lugar de #test-bcp)
• Notificación a Management (CTO, CEO)
• Alerta a equipos adicionales según tipo de incidente

Paso 2: Activación de procedimientos reales (2-5 minutos)

Cambio de modo operativo:

Aspecto	Durante Test	Durante Incidente Real
Canal de comunicación	#test-bcp	#incident-response
Autoridad de decisión	Test Coordinator	Crisis Manager
Documentación	Notas informales	Bitácora oficial completa
Escalado	No requerido	Según severidad (puede requerir notificación a AEMPS)
Reversión	Fácil/permitida	Solo si segura y documentada
Impacto	Controlado/simulado	Real en producción

Procedimientos a activar según tipo de incidente:

• Pérdida de datos: GP-XXX Procedimiento de recuperación de datos
• Fallo de sistema: OP.CONT Plan de continuidad (versión real, no test)
• Brecha de seguridad: OP.EXP-7 Gestión de incidentes de seguridad + Notificación AEPD si aplica
• Impacto a clientes: Activar comunicación externa + Posible notificación AEMPS

Paso 3: Documentación obligatoria (simultánea con respuesta)

Crear registro R-110-006 (Conversión test a incidente real):

Información a documentar:

1. Contexto del test:
   • Qué test se estaba ejecutando
   • Timestamp exacto de inicio del test
   • Participantes en el test
   • Fase del test en que se detectó el problema
2. Detección del incidente real:
   • Timestamp exacto de detección
   • Quién detectó el problema
   • Qué indicador(es) se observaron
   • Evidencia del problema real (logs, screenshots, reportes)
3. Decisión de conversión:
   • Quién tomó la decisión de convertir a incidente real
   • Timestamp de la decisión
   • Justificación de la conversión
4. Respuesta activada:
   • Procedimientos activados
   • Personal adicional convocado
   • Acciones de contención tomadas
   • Timeline de resolución
5. Análisis post-incidente:
   • Causa raíz (¿problema existía antes del test o causado por el test?)
   • Impacto real (datos, clientes, tiempo)
   • Lecciones aprendidas
   • Mejoras al plan de testing para prevenir situaciones similares

Resultado esperado de la conversión:

✅ Test suspendido de forma ordenada
✅ Respuesta de incidente real activada sin demora
✅ Todos los participantes conscientes del cambio de modo
✅ Documentación completa del evento
✅ Sin confusión entre test y realidad

Regla de oro:

"En caso de duda sobre si es test o real, TRÁTALO COMO REAL"

Es mejor responder a un test como si fuera real (exceso de precaución) que tratar un incidente real como si fuera un test (negligencia crítica).

Responsable de la decisión de conversión:

• Test Coordinator (puede tomar decisión inicial)
• Crisis Manager (confirma y asume control)
• CTO (debe ser notificado inmediatamente)

Revisión post-evento: Todo incidente que comenzó como test debe ser revisado en retrospectiva para:

• Entender por qué el test expuso el problema
• Evaluar si el test debería haberse detectado antes
• Mejorar procedimientos de validación pre-test
• Actualizar plan de continuidad con lecciones aprendidas

Documentación y seguimiento

Registro de pruebas

Cada prueba debe documentarse siguiendo este formato:

Test Report BCP-2024-Q1-003

Información básica

• Fecha: 2024-03-15 16:00 CET
• Tipo: Technical Drill - Database Failover
• Duración: 45 minutos
• Participantes: DevOps Team (4), QA Lead (1), CTO
• Observadores: CMO, Legal Counsel

Escenario ejecutado

Setup inicial

[Descripción del estado del sistema antes del test]

Fallo simulado

Primary database made unavailable through security group rule changes

Procedimiento seguido

1. 16:00 - Fallo simulado aplicado
2. 16:03 - Alertas generadas automáticamente
3. 16:05 - Equipo técnico notificado
4. 16:08 - Diagnóstico inicial completado
5. 16:12 - Decisión de failover tomada
6. 16:15 - Promoción de read replica iniciada
7. 16:20 - Verificación de nueva primary
8. 16:25 - Tests funcionales ejecutados
9. 16:30 - Servicios completamente restaurados

Resultados obtenidos

• RTO Achieved: 30 minutos ✅ (Target: ≤30 min)
• RPO Achieved: 0 segundos ✅ (Target: ≤5 min)
• Funcionalidad: 100% restaurada ✅
• Procedimientos: Seguidos completamente ✅

Issues identificados

1. Minor: Monitorización tardó 3 min en detectar fallo (target: 1 min)
2. Minor: Documentación de failover tenía paso ambiguo
3. Info: Un miembro del equipo no recibió notificación inicial

Acciones correctivas

1. Ajustar umbrales de detección de fallos de DB
2. Clarificar paso 4 del procedimiento de failover
3. Verificar configuración de notificaciones Slack

Próximo test programado

Fecha: 2024-06-15 Tipo: Full Simulation - Multi-component failure Focus: Mejorar coordinación entre equipos

Análisis de tendencias

Reporte anual de BCP testing

Annual BCP Testing Report 2024

Executive Summary

• Tests Executed: 48 (4 per month average)
• Success Rate: 91.7% (44/48 tests successful)
• Average RTO: 28.5 minutes (Target: ≤30 min)
• RPO Violations: 0 (Target: 0)

Key Achievements

✅ All critical scenarios tested successfully ✅ 100% team participation in annual simulation ✅ Zero data loss in any test ✅ Regulatory compliance maintained (MDR, NIS2)

Areas for Improvement

⚠️ Communication drill response times increased 15% ⚠️ Cloud provider escalation process unclear ⚠️ Backup restoration times trending upward

Investment Recommendations

1. Additional cloud region for geographic redundancy
2. Enhanced communication platform with better mobile alerts
3. Automated testing framework expansion
4. Annual third-party BCP audit

Testing Plan Preview

• Increase simulation frequency to monthly
• Add supply chain disruption scenarios
• Integrate AI/ML failure scenarios
• Cross-training program for key personnel

Cumplimiento regulatorio en testing

Requisitos específicos para dispositivos médicos

FDA Requirements

• Documentation: Evidencia de testing regular del plan
• Effectiveness: Demostrar que testing mejora la respuesta real
• Patient Safety: Foco especial en continuidad de servicios clínicos

MDR Requirements

• Risk Management: Testing vinculado con análisis de riesgos
• Post-Market Surveillance: Reporte de fallos encontrados en testing
• Technical Documentation: Resultados de testing en DHF

NIS2 Requirements

• Testing Frequency: Mínimo anual para entidades esenciales
• Scope: Incluir amenazas de ciberseguridad
• Reporting: Notificar gaps significativos a INCIBE

Integración con otros controles ENS

Coordinación con controles relacionados

• OP.EXP.7: Incidentes detectados durante testing
• OP.MON.1: Alertas generadas durante simulaciones
• OP.EXT.1: Validación de SLA de terceros durante crisis simuladas

Herramientas y automatización

Plataforma de testing automatizado

Framework de testing de continuidad

PRO-CONT-TEST-006: Marco de ejecución automatizada de pruebas BCP

Objetivo: Definir cómo se programan, ejecutan y reportan las pruebas automatizadas del plan de continuidad a lo largo del año.

Componentes del framework:

• Escenarios de test: Biblioteca de pruebas definidas (backup integrity, failover readiness, database failover, etc.)
• Motor de ejecución: Sistema que ejecuta las pruebas de forma automatizada
• Módulo de reporting: Generación automática de informes de resultados

---

A. Programación de tests en calendario anual

PRO-CONT-TEST-006-A: Calendario de pruebas automáticas

Método de programación:

El sistema revisa el calendario de pruebas y verifica qué tests están programados para ejecutarse. Para cada test programado:

1. Verificar si el test debe ejecutarse:
   • Comprobar la fecha y hora programada
   • Validar que no haya sido ejecutado recientemente
   • Confirmar que no hay mantenimiento programado que lo impida
2. Encolar el test para ejecución:
   • Si el test debe ejecutarse, añadirlo a la cola de ejecución
   • Asignar prioridad según tipo (crítico, normal, informativo)
   • Programar hora de ejecución (típicamente fuera de horas pico)

Calendario típico de pruebas BCP:

Frecuencia	Prueba	Día/Hora Programada	Duración
Diaria	Backup integrity (PRO-CONT-TEST-001-A)	02:00 AM	15-20 min
Diaria	Failover readiness (PRO-CONT-TEST-001-B)	02:30 AM	10-15 min
Semanal	Full backup verification (PRO-CONT-TEST-002)	Domingo 03:00 AM	30-45 min
Mensual	Database failover test (PRO-CONT-TEST-003)	Primer sábado 22:00	30-45 min
Trimestral	Full BCP drill	Último sábado del trimestre 10:00 AM	4-6 horas
Semestral	Simulación completa	Junio y Diciembre, día laborable	8 horas

Notificaciones de tests programados:

• Tests diarios: No requieren notificación previa (completamente automatizados)
• Tests semanales: Email automático el viernes recordando test del domingo
• Tests mensuales: Notificación 1 semana antes al Technical Response Team
• Tests trimestrales: Notificación 2 semanas antes a todos los participantes
• Simulaciones semestrales: Notificación 1 mes antes con preparativos requeridos

B. Ejecución automatizada de tests

PRO-CONT-TEST-006-B: Procedimiento de ejecución automatizada

Para cada test automatizado, el framework ejecuta:

Fase 1: Validación pre-test

Verificaciones antes de iniciar el test:

• Entorno válido: Confirmar que sistemas están en estado esperado
  • Servicios principales operativos
  • No hay alertas activas críticas
  • Recursos (CPU, memoria, disco) en rangos normales
• Requisitos del test cumplidos:
  • Permisos necesarios disponibles
  • Herramientas de monitorización funcionando
  • Acceso a sistemas de destino confirmado
• Sin conflictos:
  • No hay otros tests ejecutándose
  • No hay mantenimiento programado
  • No hay incidentes activos

Si validación falla: Test se pospone automáticamente y se genera alerta

---

Fase 2: Ejecución de pasos del test

Proceso de ejecución:

1. Registrar inicio del test:
   • Timestamp exacto de inicio
   • Escenario de test siendo ejecutado
   • Condiciones iniciales del sistema
2. Ejecutar cada paso del test:
   • Seguir secuencia definida en el escenario
   • Monitorizar ejecución en tiempo real
   • Capturar logs y métricas
   • Medir tiempo de cada paso
3. Manejar errores durante ejecución:
   • Si un paso falla, decidir si continuar o abortar
   • Registrar error con contexto completo
   • Activar procedimientos de rollback si es necesario
4. Registrar tiempo total de ejecución:
   • Calcular duración desde inicio hasta fin
   • Comparar con tiempo esperado
   • Identificar pasos que tomaron más tiempo del esperado

---

Fase 3: Validación de resultados

Criterios de validación:

El framework evalúa si el test fue exitoso comparando:

• Resultados obtenidos vs Resultados esperados
• Tiempos medidos vs Objetivos (RTO/RPO)
• Estado final del sistema vs Estado esperado

Ejemplo de validación - Test de backup integrity:

Resultado obtenido:
- Backup encontrado: SÍ
- Checksum válido: SÍ
- Restauración parcial: SÍ
- Antigüedad: 8 horas

Resultado esperado:
- Backup encontrado: SÍ
- Checksum válido: SÍ
- Restauración parcial: SÍ
- Antigüedad: < 24 horas

Validación: ✅ ÉXITO (todos los criterios cumplidos)

Resultado de la validación:

• ÉXITO: Todos los criterios cumplidos
• FALLO: Uno o más criterios no cumplidos
• ERROR: Test no pudo completarse por problema técnico

---

Fase 4: Generación automática de informe

PRO-CONT-TEST-006-C: Formato de informes automáticos

Cada ejecución genera un informe que contiene:

1. Identificación del test:
   • Nombre del escenario de test
   • Timestamp de ejecución
   • Duración total
2. Resultados detallados:
   • Estado de cada paso ejecutado
   • Métricas medidas (tiempos, counts, estados)
   • Comparación con valores esperados
3. Veredicto final:
   • ÉXITO / FALLO / ERROR
   • Justificación del resultado
   • RTO/RPO alcanzados (si aplica)
4. Acciones requeridas (si fallo):
   • Descripción del problema detectado
   • Severidad (Crítica, Alta, Media, Baja)
   • Equipo que debe investigar
   • Plazo para resolución

Distribución de informes:

Resultado	Destinatarios	Medio	Timing
ÉXITO (diario)	Dashboard automático	Sistema de métricas	Tiempo real
FALLO (cualquier test)	DevOps Team	Email + Slack	Inmediato
ERROR (test no completable)	DevOps Lead + DBA	Email + SMS	Inmediato
Resumen semanal	CTO + QA Lead	Email	Lunes 09:00 AM
Resumen mensual	Management Team	Email con PDF	Primer día hábil del mes

---

C. Manejo de fallos de test

PRO-CONT-TEST-006-D: Procedimiento cuando un test falla

Cuando un test automatizado falla:

1. Captura completa del contexto:

   • Mensaje de error detallado
   • Logs del sistema en momento del fallo
   • Estado de todos los componentes relevantes
   • Timestamp exacto del fallo

2. Generación de alerta:

   • Severidad automáticamente asignada según tipo de test
   • Notificación a equipo responsable
   • Creación de ticket en sistema de tracking

3. Documentación del fallo:

   • Registrar en base de datos de tests
   • Incluir en informe de fallos del período
   • Preparar información para análisis de patrones

4. Retorno seguro:

   • Marcar test como fallido (no éxito)
   • No proceder con pasos posteriores si test es crítico
   • Asegurar que sistemas quedan en estado estable

Seguimiento post-fallo:

• DevOps investiga causa raíz dentro de 24h (tests diarios) o 1 semana (tests mensuales)
• Corrección implementada y validada
• Re-ejecución del test para confirmar resolución
• Actualización de procedimientos si se identifica mejora

---

Responsables del framework:

• Mantenimiento del framework: DevOps Lead
• Definición de escenarios: QA Lead + CTO
• Revisión de informes: QA Lead (diario/semanal), CTO (mensual)
• Mejora continua: Equipo de Calidad

Herramientas del framework:

• Sistema de scheduling (cron jobs + orchestración)
• Scripts de automatización de tests
• Sistema de monitorización (CloudWatch, Prometheus)
• Plataforma de reporting (dashboards + email)
• Base de datos de resultados históricos

Referencias cruzadas

• OP.CONT.1: Análisis de impacto (base para diseño de tests)
• OP.CONT.2: Plan de continuidad (procedimientos que se testean)
• OP.CONT.4: Medios alternativos (validados en testing)
• OP.EXP.7: Gestión de incidentes (integración con respuesta real)
• T-024-004: Procedimiento de gestión de crisis
• R-TF-013-002: Riesgos de continuidad (validación mediante testing)

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001