OP.CONT.2 Plan de continuidad

Documentos de referencia

• ISO/IEC 27000:
  • 27031:2011 - Guidelines for information and communication technology readiness for business continuity
  • 27002:2013:
    • 17.1.1 - Planning information security continuity
    • 17.1.2 - Implementing information security continuity
    • 17.1.3 - Verify, review and evaluate information security continuity
• NIST SP 800-53 rev4:
  • [CP-1] Contingency Planning Policy and Procedures
  • [CP-2] Contingency Plan
  • [CP-3] Contingency Training
  • [CP-4] Contingency Plan Testing
• 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

185. Se definirá un plan de continuidad que incluya los procedimientos que permitan la recuperación oportuna y efectiva de los servicios de información en caso de interrupción.

Contemplará aspectos como:

• Estrategia de respaldo
• Estrategia de recuperación
• Roles y responsabilidades en situaciones de contingencia
• Procedimientos de comunicación en emergencias
• Procedimientos de coordinación con terceros externos
• Contactos de emergencia

Implementación en la plataforma

Como sistema de categoría ALTA según el ENS (Real Decreto 311/2022), y actuando como PROVEEDOR de servicios de apoyo:

• RTO objetivo ajustado: 4 horas (acorde a categoría ALTA)
• RPO objetivo ajustado: 1 hora (datos en tránsito)
• Rol de proveedor: El servicio sanitario puede continuar sin nuestras herramientas
• Impacto limitado: Nuestra indisponibilidad es perjudicial pero no grave
• Plan proporcionado: Medidas de continuidad acordes al rol de proveedor

Marco del plan de continuidad

El Plan de Continuidad de la plataforma está diseñado para mantener servicios de apoyo al diagnóstico dermatológico durante interrupciones, considerando nuestro rol como PROVEEDOR y no como prestador directo del servicio sanitario.

Objetivos del plan (ajustados a categoría ALTA)

• Objetivo primario: Restaurar servicios de apoyo diagnóstico con RTO ≤ 4 horas
• Objetivo secundario: Minimizar pérdida de datos transitorios con RPO ≤ 1 hora
• Objetivo terciario: Cumplir notificaciones regulatorias dentro de timeframes establecidos
• Objetivo cuaternario: Minimizar impacto económico y reputacional

Alcance de aplicación

• Servicios incluidos: Todos los componentes críticos identificados en OP.CONT.1
• Geografía: Instalaciones principales (Madrid) y centros de respaldo (AWS eu-west-1, eu-central-1)
• Horarios: 24×7×365 para funciones críticas, horario laboral para funciones administrativas
• Stakeholders: Personal médico, técnico, administrativo, pacientes, autoridades regulatorias

Estrategia de continuidad por niveles

Nivel 1 - Servicios principales (RTO ≤ 4 horas - Categoría ALTA)

Diagnóstico dermatológico IA

Servicio: Diagnóstico Dermatológico IA
Código: Diagnostico_IA
Categoría ENS: ALTA - Proveedor de apoyo RTO objetivo: ≤ 4 horas (acorde a categoría ALTA)

Arquitectura de Continuidad del Servicio

El servicio de diagnóstico IA cuenta con tres niveles de estrategia de continuidad para garantizar disponibilidad:

Nivel 1 - Estrategia Primaria (Active-Passive)

Parámetro	Valor	Descripción
Tipo de estrategia	Active-Passive	Infraestructura activa en zona primaria, pasiva en zona secundaria
Ubicaciones	eu-west-1a (Irlanda - AZ A) eu-west-1b (Irlanda - AZ B)	Dos Availability Zones dentro de la misma región AWS
Tipo de failover	Semi-automático	Detección automática de fallo + activación manual confirmada
Tiempo de failover	< 1 hora	Tiempo máximo para cambiar de AZ primaria a secundaria
Estado standby	Passive (Fría)	Infraestructura mínima en standby, se escala al activar

Funcionamiento de la estrategia primaria:

1. Operación normal: Todo el tráfico se dirige a eu-west-1a
2. Detección de fallo: Health checks detectan indisponibilidad en AZ A
3. Alerta automática: Sistema genera alerta al equipo de operaciones
4. Activación manual: Operador confirma failover a eu-west-1b (< 30 min)
5. Provisión de recursos: Instancias EC2 se escalan en AZ B (< 30 min)
6. Conmutación de tráfico: Load Balancer redirige tráfico a AZ B

Justificación Active-Passive: Suficiente para categoría ENS ALTA. Más económico que Active-Active, cumple con RTO de 4 horas.

---

Nivel 2 - Estrategia Secundaria (Warm Standby)

Parámetro	Valor	Descripción
Tipo de estrategia	Warm Standby	Infraestructura mínima funcionando permanentemente
Ubicación	eu-central-1 (Frankfurt)	Región AWS diferente para protección contra fallo regional
Tipo de activación	Manual	Requiere decisión y acción del equipo de operaciones
Tiempo de activación	< 15 minutos	Tiempo para escalar recursos y activar servicio completo
Estado standby	Warm (Templada)	Instancias mínimas ejecutándose (1 EC2 t3.small)

Funcionamiento de la estrategia secundaria:

1. Mantenimiento en warm: 1 instancia mínima en Frankfurt con datos sincronizados
2. Decisión de activación: Fallo regional completo en Irlanda O fallo prolongado (>3 horas) en ambas AZ
3. Escalado de recursos: Auto Scaling Group activa instancias adicionales en Frankfurt
4. Sincronización de datos: Verificar replicación de datos desde S3 y RDS
5. Activación del servicio: Cambiar DNS para apuntar a Frankfurt (TTL 5 min)
6. Validación: Verificar funcionalidad completa antes de redirigir usuarios

Justificación Warm Standby: Protección contra fallo de región completa (evento poco probable). Warm standby más económico que Hot standby para categoría ALTA.

Costes de mantenimiento warm:

• 1 instancia t3.small en Frankfurt: ~25 €/mes
• Replicación de datos S3 cross-region: ~10 €/mes
• Total: ~35 €/mes para protección regional

---

Nivel 3 - Modo Degradado (Fallback de Emergencia)

Parámetro	Valor	Descripción
Funcionalidad disponible	Visualización sin IA	Solo acceso a estudios e imágenes previas almacenadas
Tipo de activación	Automática	Si todos los sistemas primarios y secundarios fallan
Limitaciones	Solo consulta de estudios previos	No genera nuevos diagnósticos IA, solo visualización
Componentes activos	Base de datos (read-only) Interfaz de visualización	Sistema simplificado sin inferencia IA
Tiempo de disponibilidad	Inmediato	Sistema de visualización siempre disponible

Funcionalidad en modo degradado:

• ✅ Disponible:
  • Visualización de imágenes dermatológicas previas
  • Consulta de diagnósticos históricos
  • Acceso a informes generados anteriormente
  • Exportación de imágenes y reportes
  • Búsqueda de pacientes y estudios
• ❌ No disponible:
  • Generación de nuevos diagnósticos IA
  • Análisis de nuevas imágenes
  • Scoring de severidad automático
  • Recomendaciones de tratamiento IA
  • Seguimiento automático de evolución

Activación del modo degradado:

• Trigger: Fallo simultáneo de:
  • Región primaria (Irlanda): Ambas AZ
  • Región secundaria (Frankfurt): Warm standby
  • Tiempo transcurrido > 4 horas (superado RTO)

Comunicación a usuarios:

• Banner en interfaz: "Servicio en modo degradado - Solo visualización disponible"
• Email a profesionales sanitarios explicando limitaciones
• Estimación de tiempo de restauración del servicio completo
• Instrucciones para diagnóstico manual alternativo

Duración máxima aceptable en modo degradado: 24 horas (después requiere escalación a AEMPS)

---

Resumen de Estrategias de Continuidad

Nivel	Estrategia	Ubicación	RTO	Tipo de Activación	Funcionalidad
1 - Primaria	Active-Passive	Irlanda (2 AZ)	< 1 hora	Semi-automático	Completa (100%)
2 - Secundaria	Warm Standby	Frankfurt	< 15 min	Manual	Completa (100%)
3 - Degradado	Fallback	Multi-región	Inmediato	Automático	Limitada (~40%)

Protección total: Fallo de zona → Fallo regional → Modo degradado
Probabilidad de fallo completo: < 0.001% anual (tres niveles independientes)

Base de datos clínica

• Estrategia principal: Replicación síncrona PostgreSQL
• Respaldo primario: Read replica con promoción automática
• Respaldo secundario: Point-in-time recovery desde S3
• Respaldo terciario: Backup físico offline (último recurso)

Nivel 2 - Servicios importantes (RTO ≤ 2 horas)

Integración EMR/HIS

• Estrategia principal: Cola de mensajes persistente
• Respaldo primario: Reintento automático con backoff exponencial
• Respaldo secundario: Interfaz manual para casos críticos
• Estrategia de recuperación: Sincronización diferida post-recuperación

Sistema de auditoría

• Estrategia principal: Logging distribuido a múltiples destinos
• Respaldo primario: Buffer local con replicación diferida
• Respaldo secundario: Alertas críticas vía SMS/email

Procedimientos de activación

Detección de incidentes

Monitorización automatizada

Sistema de Detección Automática de Incidentes Críticos

Umbrales de Alerta Configurados:

Métrica	Umbral	Unidad	Descripción	Acción si se supera
Latencia del servicio de diagnóstico	30	segundos	Tiempo de respuesta del servicio IA	Iniciar evaluación de incidente
Errores de conexión a base de datos	5	errores/minuto	Fallos de conexión a PostgreSQL	Verificar salud de BD
Tasa de error del modelo IA	0.1	10%	Porcentaje de inferencias fallidas	Validar estado del modelo

PRO-CONT-MON-001: Evaluación de Salud del Servicio

Objetivo: Monitorizar continuamente las métricas críticas del servicio y detectar automáticamente situaciones que requieran activación del plan de continuidad.

Frecuencia: Continua (cada 60 segundos)

Pasos:

1. Recolectar métricas actuales:
   • Consultar CloudWatch para obtener valores actuales:
     • Latencia promedio del servicio de diagnóstico
     • Número de errores de conexión a BD en último minuto
     • Tasa de error del modelo IA en últimos 5 minutos
   • Timestamp de recolección
2. Evaluar cada métrica contra umbrales:
   • Para cada servicio monitoreado:
     • Comparar valor actual con umbral configurado
     • Si métrica > umbral: Marcar como anomalía detectada
     • Si métrica ≤ umbral: Servicio OK, continuar monitoreo
3. Activar respuesta a incidente (si se detecta anomalía):
   • Ejecutar PRO-CONT-MON-002

Resultado: Estado de salud del servicio (OK / Anomalía detectada)

PRO-CONT-MON-002: Activación de Respuesta a Incidente

Objetivo: Generar incidente y activar el plan de continuidad apropiado según la severidad.

Trigger: Métrica supera umbral configurado

Pasos:

1. Crear registro de incidente:
   • Timestamp: Momento exacto de detección
   • Servicio afectado: diagnosis_service_latency / database_connection_errors / ai_model_error_rate
   • Valor de métrica: Valor actual que superó el umbral
   • Severidad: Calcular según PRO-CONT-MON-003
   • Intento de recuperación automática: Inicialmente NO (false)
2. Calcular severidad del incidente:
   • Ejecutar PRO-CONT-MON-003 para determinar nivel (1-5)
   • Ejemplos:
     • Latencia 35 seg (5 seg sobre umbral) → Severidad 2 (Media)
     • Latencia 60 seg (30 seg sobre umbral) → Severidad 3 (Alta)
     • BD 20 errores/min (15 sobre umbral) → Severidad 4 (Crítica)
3. Decidir activación del plan de continuidad: Si severidad ≥ 3 (Alta o Crítica):
   • ACTIVAR plan de continuidad automáticamente
   • Ejecutar procedimiento correspondiente:
     • Severidad 3 (Alta): Activar estrategia primaria (failover a AZ secundaria)
     • Severidad 4 (Crítica): Activar estrategia secundaria (warm standby Frankfurt)
     • Severidad 5 (Catastrófica): Activar modo degradado
   • Notificar a equipo de crisis
   • Registrar activación en sistema de incidentes Si severidad < 3 (Baja o Media):
   • NO ACTIVAR plan de continuidad
   • Generar alerta para equipo técnico
   • Monitorear evolución cada 30 segundos
   • Si severidad aumenta → Re-evaluar activación
4. Registrar acción tomada:
   • Documentar en sistema de gestión de incidentes
   • Actualizar dashboard de crisis
   • Enviar notificaciones según nivel de escalación

Resultado: Incidente registrado y plan de continuidad activado (si aplica)

PRO-CONT-MON-003: Cálculo de Severidad de Incidente

Objetivo: Determinar nivel de severidad de un incidente basándose en el servicio afectado y la desviación del umbral.

Criterios de Severidad:

Nivel	Nombre	Criterios	Acción Requerida
1	Mínima	Desviación < 20% sobre umbral	Monitoreo continuo
2	Media	Desviación 20-50% sobre umbral	Alerta a equipo técnico
3	Alta	Desviación 50-100% sobre umbral	Activar plan de continuidad
4	Crítica	Desviación > 100% sobre umbral	Activar estrategia secundaria
5	Catastrófica	Múltiples servicios críticos fallando	Activar comité de crisis

Cálculo:

1. Calcular desviación: (Valor actual - Umbral) / Umbral × 100
2. Determinar nivel según tabla
3. Ajustar nivel si múltiples servicios están afectados (+1 nivel)

Ejemplos:

• Latencia 35 seg (umbral 30): (35-30)/30 = 16.6% → Severidad 1 (Mínima)
• Latencia 60 seg (umbral 30): (60-30)/30 = 100% → Severidad 3 (Alta) → ACTIVAR plan
• BD 15 errores/min (umbral 5): (15-5)/5 = 200% → Severidad 4 (Crítica) → ACTIVAR secundaria

Resultado: Nivel de severidad (1-5)

Alertas escalonadas

1. Nivel 1 (0-5 min): Alerta automática a equipo técnico
2. Nivel 2 (5-15 min): Escalado a Responsable del Sistema y Responsable de Seguridad
3. Nivel 3 (15-30 min): Activación del comité de crisis
4. Nivel 4 (30+ min): Notificación a Dirección y Responsable del Servicio

Árbol de decisión para activación

Roles y responsabilidades

Comité de gestión de crisis

Crisis Manager (Responsable del Sistema)

• Responsabilidades primarias:

  • Activación del plan de continuidad
  • Coordinación general de respuesta
  • Comunicación con stakeholders externos
  • Toma de decisiones técnicas críticas

• Autoridad para:

  • Activar gastos excepcionales para recuperación
  • Autorizar cambios temporales en configuración
  • Decidir activación de modo degradado
  • Coordinar con proveedores externos críticos

Medical Safety Officer (Responsable del Servicio delegado)

• Responsabilidades:
  • Evaluación de impacto clínico
  • Comunicación con profesionales sanitarios
  • Decisiones sobre protocolos alternativos
  • Coordinación con autoridades sanitarias

Technical Recovery Lead (DevOps Lead)

• Responsabilidades:
  • Ejecución técnica de procedimientos de recuperación
  • Coordinación con equipos técnicos
  • Monitorización de métricas de recuperación
  • Comunicación técnica con proveedores

Equipos de respuesta especializados

Equipo de Comunicación

• Líder: Marketing/Communication Manager
• Miembros: Legal Counsel, Customer Success
• Responsabilidades:
  • Comunicación externa con clientes
  • Coordinación con medios (si aplica)
  • Actualización de status page público
  • Preparación de comunicados post-incidente

Equipo Técnico de Recuperación

• Líder: DevOps Team Lead
• Miembros: Senior Developers, Infrastructure Engineers
• Responsabilidades:
  • Diagnóstico técnico de fallos
  • Ejecución de procedimientos de recovery
  • Monitorización de sistemas durante recuperación
  • Documentación de acciones tomadas

Procedimientos de recuperación detallados

Recuperación del servicio de diagnóstico IA

Procedimiento automático (failover)

PRO-CONT-REC-001: Failover Automático del Servicio de Diagnóstico

Objetivo: Detectar fallo del servicio primario de diagnóstico IA y activar automáticamente el servicio secundario para minimizar tiempo de interrupción.

Tipo: Procedimiento automatizado (ejecutado por sistema de monitorización)

Frecuencia de verificación: Continua (cada 60 segundos)

Tiempo total de failover: 30-60 segundos

Pasos del Procedimiento Automatizado:

1. Detectar estado del servicio primario:

   • Endpoint verificado: http://diagnosis-primary/health
   • Método: Health check HTTP
   • Timeout: 5 segundos
   • Criterio de fallo: No respuesta O código HTTP != 200 O timeout excedido
   • Si el servicio primario responde correctamente:
     • Registrar verificación exitosa
     • Continuar monitoreo normal
     • FIN del procedimiento
   • Si el servicio primario NO responde (FAIL):
     • Registrar timestamp de detección de fallo
     • Generar log: "[Fecha/Hora]: Fallo detectado en servicio primario"
     • Continuar con activación de secundario

2. Activar servicio secundario:

   • Acción: Modificar configuración de Kubernetes para redirigir tráfico
   • Comando conceptual: Cambiar selector del servicio de diagnosis-primary a diagnosis-secondary
   • Efecto: Todo el tráfico entrante se redirige automáticamente a instancia secundaria
   • Tiempo de ejecución: < 5 segundos
   • Log generado: "[Fecha/Hora]: Activando servicio secundario (failover iniciado)"

3. Esperar estabilización del servicio secundario:

   • Tiempo de espera: 30 segundos
   • Propósito: Permitir que el servicio secundario complete inicialización y esté completamente operativo
   • Durante este tiempo: El tráfico ya está siendo redirigido, pero aún no se verifica salud

4. Verificar estado del servicio secundario:

   • Endpoint verificado: http://diagnosis-secondary/health
   • Método: Health check HTTP
   • Timeout: 5 segundos
   • Criterio de éxito: Respuesta HTTP 200 con body "OK"

5. Evaluar resultado del failover:

   CASO A - Failover exitoso (Servicio secundario responde OK):

   • Registrar log: "[Fecha/Hora]: Failover completado exitosamente"
   • Notificar al equipo técnico:
     • Canal: Email + Slack #incident-response
     • Mensaje: "Failover automático completado - Diagnóstico IA"
     • Prioridad: Media (informativa)
     • Destinatarios: Technical Lead, DevOps Team
     • Contenido:
       • Timestamp de detección de fallo
       • Timestamp de activación secundario
       • Tiempo total de failover
       • Estado actual: Operativo en servicio secundario
   • Actualizar dashboard de estado
   • Registrar evento en sistema de gestión de incidentes
   • Estado final: SERVICIO RESTAURADO en secundario
   • Iniciar análisis post-mortem de fallo primario (PRO-CONT-REC-002)

   CASO B - Failover fallido (Servicio secundario NO responde):

   • Registrar log: "[Fecha/Hora]: ERROR - Failover falló, activando procedimiento manual"
   • Enviar alerta crítica:
     • Canal: Email + SMS + Llamada telefónica automática
     • Mensaje: "Failover automático FALLÓ - Intervención manual requerida"
     • Prioridad: CRÍTICA
     • Destinatarios:
       • Crisis Manager (Responsable del Sistema)
       • Technical Lead
       • DevOps Team Lead
       • Equipo de guardia
     • Contenido:
       • Timestamp de detección de fallo primario
       • Timestamp de intento de failover
       • Confirmación: Servicio secundario tampoco responde
       • ACCIÓN REQUERIDA: Ejecutar procedimiento manual de recuperación
   • Activar procedimiento manual: PRO-CONT-REC-003
   • Actualizar dashboard con estado CRÍTICO
   • Estado final: SERVICIO INTERRUMPIDO - Ambos nodos fallaron

Resultado: Servicio restaurado en secundario (éxito) O escalación a procedimiento manual (fallo)

---

Escenarios de Activación:

Escenario 1 - Fallo de zona de disponibilidad:

• Servicio primario en eu-west-1a falla
• Failover automático a eu-west-1b
• Tiempo de interrupción: 30-60 segundos
• Éxito esperado: >99%

Escenario 2 - Fallo de instancia específica:

• Pod de Kubernetes en primario crash
• Failover a pod secundario
• Tiempo de interrupción: 30-45 segundos
• Éxito esperado: >95%

Escenario 3 - Fallo regional completo (poco probable):

• Toda región eu-west-1 inaccesible
• Failover automático falla (ambos nodos en misma región)
• Activa alerta crítica
• Requiere activación manual de warm standby en Frankfurt
• Tiempo de interrupción: 15-30 minutos

Métricas del Procedimiento:

Métrica	Objetivo	Medición
Tiempo detección fallo	< 60 segundos	Intervalo de health checks
Tiempo de failover	< 60 segundos	Desde detección hasta secundario OK
Tasa de éxito failover	> 95%	Medido mensualmente
False positives	< 1%	Failovers innecesarios

Revisión y Mejora:

• Test de failover: Mensual (simulado)
• Análisis de fallos: Cada incidente real
• Actualización de umbrales: Trimestral
• Responsable: DevOps Team Lead

Procedimiento manual (recuperación completa)

1. Evaluación inicial (0-5 min):
   • Verificar estado de todos los componentes
   • Identificar causa raíz del fallo
   • Determinar estrategia de recuperación más apropiada
2. Activación de respaldo (5-20 min):
   • Activar instancia de respaldo en región secundaria
   • Redirigir tráfico DNS a nueva instancia
   • Verificar conectividad con base de datos
3. Verificación funcional (20-30 min):
   • Ejecutar tests de diagnóstico automatizados
   • Validar con caso de prueba médico conocido
   • Confirmar logging y auditoría funcionando

Recuperación de base de datos clínica

Promoción de read replica

PRO-DB-FAIL-001: Promoción de réplica de lectura a instancia primaria

Objetivo: Promover la réplica de lectura (standby) a instancia primaria en caso de fallo confirmado de la base de datos principal.

Precondición crítica: EJECUTAR SOLO cuando se haya confirmado que la instancia primaria ha fallado y no puede recuperarse en tiempo aceptable (< 15 minutos).

Pasos del procedimiento:

1. Promoción de la réplica (0-2 min):
   • Ejecutar el comando de promoción en la instancia standby
   • La réplica deja de replicar y comienza a aceptar operaciones de escritura
   • Tiempo estimado: 30-60 segundos
   • Responsable: DBA o DevOps Lead
2. Verificación del estado (2-3 min):
   • Confirmar que la nueva instancia ya no está en modo recuperación
   • Resultado esperado: La instancia debe indicar que ya no está en recovery mode
   • Si sigue en recovery, DETENER el procedimiento e investigar
   • Responsable: DBA
3. Creación de nueva réplica (3-10 min):
   • Crear una nueva read replica desde la nueva instancia primaria
   • Importante: Requiere intervención manual en AWS RDS Console
   • Seleccionar la nueva primaria como fuente
   • Configurar en availability zone diferente
   • Responsable: DevOps Lead con permisos RDS
4. Verificación de integridad de datos críticos (10-12 min):
   • Verificar estudios de pacientes: Contar registros creados en últimas 24 horas
   • Verificar resultados diagnósticos: Contar registros creados en última hora
   • Comparar con valores esperados según tráfico histórico
   • Si hay discrepancias significativas (> 5%), escalar a Medical Safety Officer
   • Responsable: DBA + Medical Safety Officer
5. Registro del evento (12-15 min):
   • Registrar el evento de failover en la tabla de eventos del sistema
   • Tipo de evento: 'database_failover'
   • Incluir timestamp exacto y descripción
   • Este registro permite auditoría y cumplimiento ENS
   • Responsable: DBA

Resultado esperado: Base de datos operativa con nueva instancia primaria, nueva réplica configurada, integridad de datos verificada, y evento registrado para auditoría.

Tiempo total del procedimiento: 12-15 minutos

Documentación post-incidente: Completar R-110-003 (Informe de incidente de continuidad) dentro de las 48 horas siguientes al evento.

Estrategias de comunicación en crisis

Comunicación interna

Matriz de comunicación inmediata

Tiempo	Audiencia	Canal	Responsable	Contenido
0-5 min	Equipo técnico	Slack #incidents	DevOps Lead	"Incidente detectado, iniciando diagnóstico"
5-15 min	Management	Email + SMS	Responsable del Sistema	"Resumen situación, ETA resolución"
15-30 min	Todo el equipo	Email	Crisis Manager	"Status update, acciones en curso"
30+ min	Board/Investors	Llamada telefónica	Dirección	"Briefing completo, impacto, próximos pasos"

Plantillas de comunicación

Template: Notificación Inicial de Incidente

Para: Equipo de Respuesta De: Crisis Manager Asunto: [CRÍTICO] Incidente en la plataforma - Activación Plan Continuidad

Resumen

• Tiempo de detección: [HH:MM]
• Servicios afectados: [Lista]
• Impacto estimado: [Alto/Medio/Bajo]
• ETA resolución: [HH:MM]

Acciones inmediatas

1. [Acción 1 - Responsable]
2. [Acción 2 - Responsable]
3. [Acción 3 - Responsable]

Próxima actualización

[HH:MM] o ante cambios significativos

Crisis Manager: [Nombre y contacto]

Comunicación externa

Comunicación con clientes (hospitales/clínicas)

• Canal primario: Email directo a administradores técnicos
• Canal secundario: Actualización en portal de cliente
• Canal terciario: Llamadas telefónicas para clientes críticos

Status page público

Ejemplo de mensaje de incidente crítico:

Interrupción del Servicio de Diagnóstico

Detectado: 2024-01-15 14:30 CET
Estado: Investigando - Trabajos de recuperación en curso
Impacto: Servicio de diagnóstico no disponible
Próxima actualización: 15:00 CET

Estado de servicios:

• 🔴 Diagnóstico IA - No disponible
• 🟢 Consulta de estudios previos - Operativo
• 🟡 Integración EMR - Funcionamiento limitado

Procedimientos de coordinación con terceros

Proveedores de servicios críticos

Amazon Web Services (AWS)

• Contacto: Enterprise Support (24×7)
• Escalado: Technical Account Manager
• SLA: Respuesta < 1 hora para Severidad Alta
• Procedimiento:
  1. Apertura de caso crítico en AWS Console
  2. Llamada telefónica a soporte enterprise
  3. Escalado a TAM si no hay respuesta en 15 min
  4. Escalado a AWS Account Manager si persiste el problema

Microsoft Azure (servicios híbridos)

• Contacto: Premier Support
• Escalado: Customer Success Account Manager
• Procedimiento similar a AWS con tiempos equivalentes

Partners tecnológicos

Conectividad a Internet (descentralizada)

• Modelo: Cada empleado utiliza su propia conexión a Internet doméstica (modelo de teletrabajo)
• No existe un único proveedor de conectividad corporativo
• Fallback: En caso de fallo del ISP doméstico, cada empleado puede utilizar su conexión de datos móvil como hotspot
• Escalado: El empleado contacta directamente con su proveedor de Internet; si la incidencia persiste, se coordina con el Responsable del Sistema para soluciones alternativas

WatchGuard (EPDR)

• Contacto: deu.cloud.watchguard.com (portal de soporte)
• Especialización: Respuesta a incidentes de seguridad en endpoints
• Escalado: Equipo de soporte de WatchGuard

Wazuh (Cloud SIEM)

• Contacto: console.cloud.wazuh.com (portal de soporte)
• Especialización: Correlación de eventos de seguridad, detección de amenazas
• Escalado: Soporte Wazuh Cloud

Contactos de emergencia

Contactos internos críticos

Equipo de Gestión de Crisis - Contactos de Emergencia

Rol	Nombre	Posición	Teléfono	Email	Contacto Backup
Crisis Manager	[Nombre]	Responsable del Sistema	+34 XXX XXX XXX	[email]	[Backup]
Medical Safety Officer	[Nombre]	Responsable del Servicio	+34 XXX XXX XXX	[email]	Dr. Clinical Safety Officer
Technical Lead	DevOps Team Lead	DevOps Manager	+34 XXX XXX XXX	[email]	Senior Developer

Responsabilidades por Rol:

Crisis Manager (Responsable del Sistema):

• Coordinación general de respuesta al incidente
• Toma de decisiones técnicas críticas
• Activación del plan de continuidad
• Comunicación con stakeholders externos
• Autorización de gastos excepcionales
• Interfaz con autoridades regulatorias

Disponibilidad: 24/7 durante crisis activa
Tiempo de respuesta esperado: < 15 minutos

Medical Safety Officer (Responsable del Servicio):

• Evaluación de impacto clínico del incidente
• Decisiones sobre notificación a autoridades sanitarias
• Comunicación con profesionales sanitarios afectados
• Evaluación de riesgo para pacientes
• Coordinación con departamentos clínicos de hospitales

Disponibilidad: 24/7 durante crisis activa
Tiempo de respuesta esperado: < 30 minutos

Technical Lead (DevOps):

• Ejecución técnica de procedimientos de recuperación
• Activación de estrategias de failover
• Monitorización de métricas técnicas
• Coordinación con equipo de desarrollo
• Gestión de infraestructura cloud

Disponibilidad: 24/7 (rotación de guardia)
Tiempo de respuesta esperado: < 10 minutos

Protocolo de Escalación:

1. Detección automática de incidente → Alerta inmediata a Technical Lead
2. Si severidad ≥ 3 → Notificar a Crisis Manager (15 min)
3. Si impacto clínico confirmado → Notificar a Medical Safety Officer (30 min)
4. Si backup no disponible → Escalar a siguiente nivel jerárquico

Información de Contacto de Backup:

• Backup Crisis Manager: [Nombre] (Responsable del Servicio) - [email]
• Backup Medical Safety Officer: Dr. Clinical Safety Officer - [contacto en registro interno]
• Backup Technical Lead: Senior Developer - [contacto en registro interno]

Actualización de Contactos:

• Frecuencia de revisión: Trimestral
• Responsable: Crisis Manager
• Verificación: Test de comunicación mensual
• Registro: R-TF-024-005 (Directorio de contactos de emergencia)

Contactos regulatorios y autoridades

Autoridades sanitarias

• AEMPS (Agencia Española de Medicamentos y Productos Sanitarios)
  • Teléfono: +34 918 225 000
  • Email: sgps@aemps.es
  • Notificación requerida: Incidentes graves > 24h

Organismos de ciberseguridad

• INCIBE (Instituto Nacional de Ciberseguridad)
  • Teléfono: +34 917 042 222
  • Email: incidencias@incibe.es
  • Notificación NIS2: Incidentes significativos < 24h

Métricas y monitorización durante crisis

KPIs críticos durante recuperación

• RTO Achievement: Tiempo real vs. objetivo de recuperación
• Data Loss: RPO real vs. objetivo (debe ser 0 para datos clínicos)
• Service Availability: % disponibilidad por servicio
• User Impact: Número de profesionales sanitarios afectados
• Clinical Impact: Número de diagnósticos diferidos

Dashboard de crisis

Dashboard de Métricas Críticas Durante Incidente

Servicios Monitoreados:

• Diagnosis (Servicio de diagnóstico IA)
• Database (Base de datos clínica)
• Auth (Sistema de autenticación)
• Integration (Integración con EMR/HIS)

Métricas Capturadas en Tiempo Real:

Métrica	Descripción	Cálculo	Uso
Downtime (Tiempo de caída)	Minutos transcurridos desde inicio del incidente	Timestamp actual - Timestamp inicio	Comparar con RTO objetivo
Services Affected (Servicios afectados)	Número de servicios críticos inoperativos	Contar servicios con estado != OPERATIONAL	Evaluar severidad del incidente
Estimated Clinical Impact (Impacto clínico estimado)	Número de consultas dermatológicas diferidas	(Downtime en horas) × 10 consultas/hora	Justificar decisiones de recuperación
Recovery Progress (Progreso de recuperación)	Porcentaje de servicios restaurados	(Servicios OK / Total servicios) × 100	Comunicar avance a stakeholders
Next Escalation Due (Próxima escalación)	Timestamp para siguiente actualización	Última actualización + Intervalo configurado	Mantener comunicación regular

PRO-CONT-DASH-001: Generación de Métricas de Incidente

Objetivo: Calcular métricas clave del incidente en tiempo real para toma de decisiones y comunicación.

Frecuencia: Cada 5 minutos durante incidente activo

Pasos:

1. Calcular tiempo de caída (downtime):
   • Obtener timestamp de inicio del incidente
   • Calcular diferencia con timestamp actual
   • Convertir a minutos
   • Ejemplo: Inicio: 10:00, Actual: 10:45 → Downtime: 45 minutos
2. Contar servicios afectados:
   • Para cada servicio en lista monitoreada (diagnosis, database, auth, integration):
     • Verificar estado actual (health check)
     • Si estado != OPERATIONAL: Incrementar contador
   • Ejemplo: Database DOWN, Auth DOWN → 2 de 4 servicios afectados
3. Estimar impacto clínico:
   • Calcular: (Downtime en minutos ÷ 60) × 10 consultas/hora
   • Redondear a entero
   • Ejemplo: 45 min → (45÷60) × 10 = 7.5 → 8 consultas diferidas
4. Calcular progreso de recuperación:
   • Contar servicios operacionales
   • Calcular: (Servicios OK ÷ Total servicios) × 100
   • Ejemplo: 2 OK de 4 total → (2÷4) × 100 = 50% recuperado
5. Determinar próxima escalación:
   • Obtener timestamp de última actualización
   • Sumar intervalo configurado (15 minutos para severidad alta)
   • Ejemplo: Última: 10:30, Intervalo: 15 min → Próxima: 10:45

Resultado: Diccionario con todas las métricas calculadas

---

PRO-CONT-DASH-002: Generación de Reporte de Estado de Crisis

Objetivo: Generar reporte estructurado del estado actual del incidente para comunicación interna y externa.

Trigger: Automático cada 15 minutos O manual bajo demanda

Formato del Reporte:

=== CRISIS STATUS REPORT ===
Downtime: [X] minutes
Services Affected: [N]/4
Clinical Impact: [Y] consultations delayed
Recovery Progress: [Z]%
Next Update Due: [HH:MM]

Pasos:

1. Obtener métricas actuales:
   • Ejecutar PRO-CONT-DASH-001
   • Capturar todos los valores calculados
2. Formatear reporte:
   • Aplicar plantilla de reporte de crisis
   • Insertar valores de métricas:
     • Downtime: Minutos de interrupción
     • Services Affected: Fracción de servicios afectados (ej: 2/4)
     • Clinical Impact: Número de consultas diferidas
     • Recovery Progress: Porcentaje de recuperación
     • Next Update Due: Timestamp de próxima actualización
3. Distribuir reporte:
   • Enviar por email a comité de crisis
   • Publicar en canal de Slack #incident-response
   • Actualizar status page público
   • Registrar en sistema de tickets

Resultado: Reporte formateado listo para distribución

Ejemplo de Reporte Real:

=== CRISIS STATUS REPORT ===
Downtime: 45 minutes
Services Affected: 2/4
Clinical Impact: 8 consultations delayed
Recovery Progress: 50%
Next Update Due: 10:45

Interpretación:

• 45 minutos: Estamos cerca del umbral de severidad alta (60 min)
• 2/4 servicios: Database y Auth afectados, Diagnosis y Integration OK
• 8 consultas diferidas: Impacto moderado, no crítico
• 50% recuperado: Mitad del camino hacia recuperación completa
• Próxima actualización 10:45: Equipo espera actualización en 15 minutos

Uso del Dashboard:

• Crisis Manager: Evaluar necesidad de activar estrategia secundaria
• Medical Safety Officer: Decidir si notificar a AEMPS (>240 min requiere notificación)
• Technical Lead: Priorizar servicios para recuperación
• Stakeholders: Entender progreso y impacto sin necesidad de detalles técnicos

Modo de operación degradado

Servicios mínimos garantizados

Cuando la recuperación completa no es posible, se activa el modo degradado que garantiza:

Acceso de solo lectura a estudios previos

• Consulta de diagnósticos históricos
• Visualización de imágenes almacenadas
• Acceso a informes generados previamente
• Funcionalidad de búsqueda básica

Captura de nuevas imágenes (sin diagnóstico IA)

• Upload de nuevas imágenes dermatológicas
• Almacenamiento temporal para procesamiento posterior
• Metadatos básicos (paciente, fecha, localización anatómica)
• Cola de procesamiento para cuando se restaure el servicio

Procedimientos de operación degradada

Protocolo de Operación Degradada

Para profesionales sanitarios:

1. Acceso al sistema: Usar URL de emergencia del sistema
2. Nuevos casos:
   • Capturar imágenes normalmente
   • Añadir notas clínicas detalladas
   • Marcar casos urgentes para priorización
3. Diagnósticos pendientes:
   • Revisar cola de casos pendientes
   • Usar experiencia clínica para casos urgentes
   • Documentar decisiones para revisión posterior

Comunicación con pacientes:

"Debido a mantenimiento técnico, el análisis automático no está disponible temporalmente. Su dermatólogo revisará las imágenes manualmente para garantizar el mismo nivel de atención médica."

Procedimientos post-recuperación

Verificación completa del sistema

Lista de verificación técnica

• Todos los servicios principales operativos
• Bases de datos sincronizadas correctamente
• Modelos de IA funcionando con precisión esperada
• Integraciones externas restablecidas
• Sistemas de monitorización activos
• Backups funcionando correctamente

Lista de verificación clínica

• Casos pendientes procesados y revisados
• Diagnósticos generados durante modo degradado validados
• Comunicación enviada a profesionales sanitarios
• Métricas de calidad diagnóstica verificadas
• No hay pérdida de datos clínicos

Análisis post-incidente

Reunión de lessons learned

• Participantes: Todo el equipo de respuesta + Management
• Timing: Dentro de 48h del fin del incidente
• Duración: 2 horas máximo
• Resultado: Plan de mejoras concreto con timelines

Documentación obligatoria

Post-Incident Report - [Incident ID]

Resumen Ejecutivo

• Duración total: [X] horas y [Y] minutos
• Servicios afectados: [Lista]
• Usuarios impactados: [Número] profesionales sanitarios
• Causa raíz: [Descripción técnica]

Timeline detallado

[Cronología minuto a minuto de eventos y acciones]

Impacto de negocio

• Clínico: [X] diagnósticos diferidos
• Económico: €[X] estimado
• Reputacional: [Evaluación]

Análisis de respuesta

Qué funcionó bien:

1. [Item 1]
2. [Item 2]

Qué debe mejorar:

1. [Item 1 con acción correctiva]
2. [Item 2 con responsable y fecha]

Plan de prevención

• Mejoras técnicas: [Lista con prioridad]
• Mejoras de proceso: [Lista con timelines]
• Formación adicional: [Para quién y cuándo]

Integración con otros controles ENS

Relación con otros controles operacionales

• OP.EXP.7: Gestión de incidentes - Escalado automático a procedimientos de continuidad
• OP.MON.1: Detección de intrusión - Alertas que pueden activar plan de continuidad
• OP.EXT.1: SLA con terceros - Definición de tiempos de respuesta en crisis

Integración con marco de ciberseguridad

• Threat Models: Respuesta específica a amenazas identificadas
• Risk Register: Mitigación activa de riesgos de continuidad
• Incident Response: Coordinación entre respuesta a incidentes y continuidad

Validación y testing del plan

Referenciado en OP.CONT.3, pero con énfasis en:

• Simulacros trimestrales: Diferentes escenarios de fallo
• Tabletop exercises: Para decisiones de management
• Technical drills: Para equipos de respuesta
• End-to-end testing: Validación completa anual

Referencias cruzadas

• OP.CONT.1: Análisis de impacto (base para este plan)
• OP.CONT.3: Pruebas periódicas del plan
• OP.CONT.4: Medios alternativos específicos
• T-024-004: Procedimiento de gestión de incidentes
• R-TF-013-002: Registro de riesgos de continuidad
• GP-013: Marco de ciberseguridad

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 Design & Development Manager, JD-004 Quality Manager & Person Responsible for Regulatory Compliance (PRRC)
• Approver: JD-001 General Manager

ㅤ