OP.CONT.2 Plan de continuidad

☑️Aplicación de la medida

De acuerdo al ANEXO II, 2 Selección de medidas de seguridad, la medida de seguridad OP.CONT.2 Plan de continuidad 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.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 Legit Health Plus

Como sistema de categoría MEDIA 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 MEDIA)
• RPO objetivo ajustado: 1 hora (datos en tránsito)
• No somos críticos: 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 Legit Health Plus 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.

1.1 Objetivos del plan (ajustados a categoría MEDIA)

• 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

1.2 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

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

Diagnóstico dermatológico IA

• Estrategia principal: Cluster activo-activo multi-AZ
• Respaldo primario: Failover automático a segunda AZ
• Respaldo secundario: Activación manual en región secundaria
• Respaldo terciario: Servicio degradado sin IA (solo visualización)

Servicio: Diagnostico_IA
Categoria_ENS: "MEDIA - Proveedor"
Estrategia_Primaria:
  Tipo: "Active-Passive" # Suficiente para categoría MEDIA
  Localizacion: ["eu-west-1a", "eu-west-1b"]
  Failover: "Semi-automático < 1 hora"

Estrategia_Secundaria:
  Tipo: "Warm Standby"
  Localizacion: "eu-central-1"
  Activacion: "Manual < 15 minutos"

Modo_Degradado:
  Funcionalidad: "Visualización sin IA"
  Activacion: "Automática si falla todo"
  Limitaciones: "Solo consulta de estudios previos"

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)

2.2 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

3.1 Detección de incidentes

Monitorización automatizada

# Sistema de detección de incidentes críticos
class IncidentDetection:
    def __init__(self):
        self.thresholds = {
            'diagnosis_service_latency': 30,  # segundos
            'database_connection_errors': 5,   # por minuto
            'ai_model_error_rate': 0.1        # 10%
        }

    def evaluate_service_health(self):
        metrics = self.collect_metrics()

        for service, threshold in self.thresholds.items():
            if metrics[service] > threshold:
                self.trigger_incident_response(service, metrics[service])

    def trigger_incident_response(self, service, metric_value):
        incident = {
            'timestamp': datetime.now(),
            'service': service,
            'severity': self.calculate_severity(service, metric_value),
            'auto_recovery_attempted': False
        }

        # Activación automática del plan de continuidad
        if incident['severity'] >= 3:
            self.activate_continuity_plan(incident)

Alertas escalonadas

1. Nivel 1 (0-5 min): Alerta automática a equipo técnico
2. Nivel 2 (5-15 min): Escalado a CTO y ISO
3. Nivel 3 (15-30 min): Activación del comité de crisis
4. Nivel 4 (30+ min): Notificación a CEO y CMO

3.2 Árbol de decisión para activación

Roles y responsabilidades

4.1 Comité de gestión de crisis

Crisis Manager (CTO)

• 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 (CMO 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

4.2 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

5.1 Recuperación del servicio de diagnóstico IA

Procedimiento automático (failover)

#!/bin/bash
# Script automático de failover del servicio de diagnóstico

# Detección de fallo del servicio primario
PRIMARY_HEALTH=$(curl -sf http://diagnosis-primary/health || echo "FAIL")

if [ "$PRIMARY_HEALTH" == "FAIL" ]; then
    echo "$(date): Fallo detectado en servicio primario"

    # 2. Activación de servicio secundario
    kubectl patch service diagnosis-service -p '{"spec":{"selector":{"app":"diagnosis-secondary"}}}'

    # 3. Verificación de activación
    sleep 30
    SECONDARY_HEALTH=$(curl -sf http://diagnosis-secondary/health)

    if [ "$SECONDARY_HEALTH" == "OK" ]; then
        echo "$(date): Failover completado exitosamente"
        # Notificar al equipo
        send_alert "Failover automático completado - Diagnóstico IA"
    else
        echo "$(date): ERROR - Failover falló, activando procedimiento manual"
        send_critical_alert "Failover automático FALLÓ - Intervención manual requerida"
    fi
fi

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

5.2 Recuperación de base de datos clínica

Promoción de read replica

-- Procedimiento de promoción de read replica
-- EJECUTAR SOLO EN CASO DE FALLO PRIMARIO CONFIRMADO

-- 1. Detener replicación en standby
SELECT pg_promote();

-- 2. Verificar estado de nueva instancia primaria
SELECT pg_is_in_recovery(); -- Debe retornar false

-- 3. Crear nueva read replica desde nueva primaria
-- (Requiere intervención manual en AWS RDS Console)

-- 4. Verificar integridad de datos críticos
SELECT COUNT(*) FROM patient_studies WHERE created_at > NOW() - INTERVAL '24 hours';
SELECT COUNT(*) FROM diagnostic_results WHERE created_at > NOW() - INTERVAL '1 hour';

-- 5. Notificar éxito de promoción
INSERT INTO system_events (event_type, description, timestamp)
VALUES ('database_failover', 'Read replica promoted to primary', NOW());

Estrategias de comunicación en crisis

6.1 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	CTO	"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	CEO	"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 Legit Health Plus - 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]

6.2 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

<!-- Template de status page durante incidente -->
<div class="incident-banner critical">
  <h2>Interrupción del Servicio de Diagnóstico</h2>
  <p><strong>Detectado:</strong> 2024-01-15 14:30 CET</p>
  <p><strong>Estado:</strong> Investigando - Trabajos de recuperación en curso</p>
  <p><strong>Impacto:</strong> Servicio de diagnóstico no disponible</p>
  <p><strong>Próxima actualización:</strong> 15:00 CET</p>
</div>

<div class="service-status">
  <ul>
    <li class="status-critical">Diagnóstico IA - No disponible</li>
    <li class="status-operational">Consulta de estudios previos - Operativo</li>
    <li class="status-degraded">Integración EMR - Funcionamiento limitado</li>
  </ul>
</div>

Procedimientos de coordinación con terceros

7.1 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

7.2 Partners tecnológicos

Proveedor de conectividad (Movistar/Vodafone)

• Contacto primario: NOC 24×7
• Escalado: Account Manager
• SLA: Diagnóstico < 30 min, resolución < 4 horas
• Backup: Activación automática 4G/5G si falla línea principal

Proveedor de ciberseguridad (CrowdStrike/SentinelOne)

• Contacto: SOC 24×7
• Especialización: Respuesta a incidentes de seguridad
• Escalado: Incident Response Team

Contactos de emergencia

8.1 Contactos internos críticos

Crisis_Manager:
  Nombre: "Taig Mac Carthy"
  Rol: "CTO"
  Telefono: "+34 XXX XXX XXX"
  Email: "taig@legit.health"
  Backup: "Alfonso Medina (CMO)"

Medical_Safety_Officer:
  Nombre: "Dr. Alfonso Medina"
  Rol: "CMO"
  Telefono: "+34 XXX XXX XXX"
  Email: "alfonso@legit.health"
  Backup: "Dr. Clinical Safety Officer"

Technical_Lead:
  Nombre: "DevOps Team Lead"
  Telefono: "+34 XXX XXX XXX"
  Email: "devops@legit.health"
  Backup: "Senior Developer"

8.2 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

9.1 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

9.2 Dashboard de crisis

# Dashboard de métricas críticas durante incidente
class CrisisDashboard:
    def __init__(self):
        self.start_time = None
        self.services = ['diagnosis', 'database', 'auth', 'integration']

    def incident_metrics(self):
        return {
            'downtime_minutes': self.calculate_downtime(),
            'services_affected': self.count_affected_services(),
            'estimated_clinical_impact': self.estimate_clinical_impact(),
            'recovery_progress': self.calculate_recovery_percentage(),
            'next_escalation_due': self.next_escalation_time()
        }

    def generate_status_report(self):
        metrics = self.incident_metrics()
        return f"""
        === CRISIS STATUS REPORT ===
        Downtime: {metrics['downtime_minutes']} minutes
        Services Affected: {metrics['services_affected']}/{len(self.services)}
        Clinical Impact: {metrics['estimated_clinical_impact']} consultations delayed
        Recovery Progress: {metrics['recovery_progress']}%
        Next Update Due: {metrics['next_escalation_due']}
        """

Modo de operación degradado

10.1 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

10.2 Procedimientos de operación degradada

## Protocolo de Operación Degradada

### Para profesionales sanitarios:

1. **Acceso al sistema**: Usar URL de emergencia https://emergency.legit.health
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

11.1 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

11.2 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, JD-004
• Approver: JD-001