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

2.1 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

2.2 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

# Ejemplo de test automatizado diario
class DailyBCPTests:
    def __init__(self):
        self.test_results = []

    def test_backup_integrity(self):
        """Verifica integridad de backups de últimas 24h"""
        try:
            latest_backup = self.get_latest_backup()
            checksum_valid = self.verify_backup_checksum(latest_backup)
            restore_test = self.test_partial_restore(latest_backup)

            result = {
                'test': 'backup_integrity',
                'timestamp': datetime.now(),
                'checksum_valid': checksum_valid,
                'partial_restore_ok': restore_test,
                'backup_age_hours': latest_backup.age_hours(),
                'status': 'PASS' if checksum_valid and restore_test else 'FAIL'
            }

            self.test_results.append(result)
            return result

        except Exception as e:
            self.alert_on_failure('backup_integrity', str(e))
            return {'test': 'backup_integrity', 'status': 'ERROR', 'error': str(e)}

    def test_failover_readiness(self):
        """Verifica que sistemas de respaldo están listos"""
        secondary_systems = [
            'diagnosis-service-standby',
            'database-read-replica',
            'auth-service-backup'
        ]

        readiness_results = []
        for system in secondary_systems:
            health = self.check_system_health(system)
            sync_status = self.check_data_sync(system)

            readiness_results.append({
                'system': system,
                'health_ok': health,
                'sync_current': sync_status,
                'ready': health and sync_status
            })

        all_ready = all(result['ready'] for result in readiness_results)

        result = {
            'test': 'failover_readiness',
            'timestamp': datetime.now(),
            'systems_checked': len(secondary_systems),
            'systems_ready': sum(1 for r in readiness_results if r['ready']),
            'details': readiness_results,
            'status': 'PASS' if all_ready else 'FAIL'
        }

        self.test_results.append(result)
        return result

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

3.1 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)

# Simular fallo del servicio principal de diagnóstico
kubectl scale deployment diagnosis-service-primary --replicas=0

# Simular degradación de performance que cause alertas
kubectl patch deployment diagnosis-service-primary \
  -p '{"spec":{"template":{"spec":{"containers":[{"name":"diagnosis","resources":{"limits":{"memory":"128Mi"}}}]}}}}'

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)

# Activar servicio secundario
kubectl scale deployment diagnosis-service-secondary --replicas=3

# Redirigir tráfico
kubectl patch service diagnosis-lb \
  -p '{"spec":{"selector":{"app":"diagnosis-secondary"}}}'

# Verificar conectividad con base de datos
kubectl exec -it diagnosis-service-secondary-xxx -- \
  curl http://database-read-replica/health

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 ❌

3.2 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

4.1 Testing de backups y recuperación

Backup integrity testing (automatizado diario)

#!/bin/bash
# Script de verificación de integridad de backups

BACKUP_LOCATION="/backups/legit-health"
TEST_DB="bcp_test_restore"
LOG_FILE="/var/log/backup-test.log"

echo "$(date): Iniciando test de integridad de backup" >> $LOG_FILE

# 1. Obtener backup más reciente
LATEST_BACKUP=$(ls -t $BACKUP_LOCATION/*.sql.gz | head -1)

if [ -z "$LATEST_BACKUP" ]; then
    echo "ERROR: No se encontraron backups" >> $LOG_FILE
    exit 1
fi

# 2. Crear base de datos temporal para testing
createdb $TEST_DB
if [ $? -ne 0 ]; then
    echo "ERROR: No se pudo crear DB de test" >> $LOG_FILE
    exit 1
fi

# 3. Restaurar backup en DB temporal
zcat $LATEST_BACKUP | psql $TEST_DB
if [ $? -ne 0 ]; then
    echo "ERROR: Fallo al restaurar backup" >> $LOG_FILE
    dropdb $TEST_DB
    exit 1
fi

# 4. Verificar integridad de datos críticos
PATIENT_COUNT=$(psql -t -c "SELECT COUNT(*) FROM patients;" $TEST_DB)
STUDY_COUNT=$(psql -t -c "SELECT COUNT(*) FROM patient_studies;" $TEST_DB)
DIAGNOSIS_COUNT=$(psql -t -c "SELECT COUNT(*) FROM diagnostic_results;" $TEST_DB)

# 5. Validar números razonables (no cero, no extremos)
if [ $PATIENT_COUNT -lt 100 ] || [ $STUDY_COUNT -lt 1000 ]; then
    echo "ERROR: Counts de datos sospechosos" >> $LOG_FILE
    echo "Patients: $PATIENT_COUNT, Studies: $STUDY_COUNT" >> $LOG_FILE
    dropdb $TEST_DB
    exit 1
fi

# 6. Cleanup
dropdb $TEST_DB

echo "$(date): Test de backup EXITOSO - P:$PATIENT_COUNT S:$STUDY_COUNT D:$DIAGNOSIS_COUNT" >> $LOG_FILE

# 7. Reportar éxito al sistema de monitorización
curl -X POST http://monitoring/api/metrics \
  -d "backup_test_status=success&patients=$PATIENT_COUNT&studies=$STUDY_COUNT"

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

4.2 Testing de failover automático

Database failover testing

# Test automatizado de failover de base de datos
class DatabaseFailoverTest:
    def __init__(self):
        self.primary_db = "legit-health-prod.cluster-xxx.eu-west-1.rds.amazonaws.com"
        self.replica_db = "legit-health-replica.cluster-yyy.eu-west-1.rds.amazonaws.com"
        self.test_results = {}

    def execute_failover_test(self):
        """Ejecuta test completo de failover de base de datos"""
        print("Iniciando test de failover de base de datos...")

        # 1. Pre-test validation
        self.validate_initial_state()

        # 2. Simulate primary failure
        print("Simulando fallo de base datos principal...")
        self.simulate_primary_failure()

        # 3. Trigger failover
        print("Iniciando promoción de read replica...")
        start_time = time.time()
        self.promote_read_replica()

        # 4. Validate new primary
        self.validate_new_primary()
        failover_time = time.time() - start_time

        # 5. Test application connectivity
        self.test_application_connectivity()

        # 6. Generate report
        self.generate_test_report(failover_time)

        print(f"Test completado en {failover_time:.1f} segundos")
        return self.test_results

    def validate_initial_state(self):
        """Verifica que sistemas están en estado normal antes del test"""
        primary_status = self.check_db_status(self.primary_db)
        replica_status = self.check_db_status(self.replica_db)

        assert primary_status == "available", "Primary DB no disponible"
        assert replica_status == "available", "Replica DB no disponible"

        # Verificar lag de replicación < 1 segundo
        replication_lag = self.get_replication_lag()
        assert replication_lag < 1.0, f"Replication lag alto: {replication_lag}s"

        print("✓ Estado inicial validado correctamente")

    def simulate_primary_failure(self):
        """Simula fallo de base datos principal"""
        # En entorno de test, detener temporalmente primary
        # En prod, esto sería un fallo real
        pass  # Implementación específica del entorno

    def promote_read_replica(self):
        """Promociona read replica a primary"""
        import boto3

        rds_client = boto3.client('rds', region_name='eu-west-1')

        response = rds_client.promote_read_replica(
            DBInstanceIdentifier='legit-health-replica'
        )

        # Esperar hasta que promoción complete
        waiter = rds_client.get_waiter('db_instance_available')
        waiter.wait(DBInstanceIdentifier='legit-health-replica')

        print("✓ Read replica promocionada exitosamente")

Métricas y evaluación de pruebas

5.1 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

5.2 Dashboard de métricas de BCP testing

class BCPTestingMetrics:
    def __init__(self):
        self.test_history = self.load_test_history()

    def generate_quarterly_report(self):
        """Genera reporte trimestral de testing BCP"""
        quarter_tests = self.get_quarter_tests()

        metrics = {
            'total_tests_executed': len(quarter_tests),
            'success_rate': self.calculate_success_rate(quarter_tests),
            'avg_rto_achieved': self.calculate_avg_rto(quarter_tests),
            'rpo_violations': self.count_rpo_violations(quarter_tests),
            'improvement_areas': self.identify_improvement_areas(quarter_tests)
        }

        return self.format_quarterly_report(metrics)

    def track_rto_trends(self):
        """Analiza tendencia de RTO a lo largo del tiempo"""
        monthly_rto = []

        for month in self.get_last_12_months():
            month_tests = self.get_tests_by_month(month)
            if month_tests:
                avg_rto = sum(test.rto_minutes for test in month_tests) / len(month_tests)
                monthly_rto.append({
                    'month': month,
                    'avg_rto': avg_rto,
                    'target_rto': 30,
                    'variance': avg_rto - 30
                })

        return monthly_rto

    def identify_failure_patterns(self):
        """Identifica patrones en fallos de testing"""
        failed_tests = [test for test in self.test_history if not test.success]

        failure_analysis = {
            'common_failure_points': self.analyze_failure_points(failed_tests),
            'time_patterns': self.analyze_failure_timing(failed_tests),
            'component_reliability': self.analyze_component_failures(failed_tests)
        }

        return failure_analysis

Training y competencia del equipo

6.1 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

6.2 Certificación de competencia

Requisitos_Certificacion_BCP:
  Crisis_Manager:
    - Liderar 2 table-top exercises exitosos
    - Participar en 1 simulación completa
    - Aprobar examen teórico (80% mínimo)
    - Renovación anual

  Technical_Response_Team:
    - Ejecutar 3 technical drills exitosos
    - Demostrar competencia en herramientas
    - Certificación específica por sistema crítico
    - Renovación semestral

  Communication_Team:
    - Participar en ejercicios de comunicación
    - Demostrar redacción de comunicados críticos
    - Conocimiento de contactos regulatorios
    - Renovación anual

Integración con gestión de incidentes reales

7.1 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
class TestToRealIncidentConverter:
    def __init__(self, test_session):
        self.test_session = test_session
        self.real_incident_indicators = [
            'actual_data_loss_detected',
            'real_customer_complaints',
            'genuine_system_failures',
            'security_breach_indicators'
        ]

    def evaluate_test_reality(self):
        """Evalúa si el 'test' es realmente un incidente"""
        for indicator in self.real_incident_indicators:
            if self.detect_indicator(indicator):
                return self.convert_to_real_incident()

        return "test_continues"

    def convert_to_real_incident(self):
        """Convierte test en respuesta a incidente real"""
        print("🚨 REAL INCIDENT DETECTED DURING TEST")
        print("🔄 Convirtiendo test en respuesta real...")

        # 1. Notificar a todos los participantes
        self.notify_test_to_real_conversion()

        # 2. Activar procedimientos reales de incidente
        self.activate_real_incident_response()

        # 3. Documentar para análisis posterior
        self.document_test_to_real_conversion()

        return "real_incident_activated"

Documentación y seguimiento

8.1 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

8.2 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

## 2025 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

9.1 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

11.1 Plataforma de testing automatizado

# Framework de testing de continuidad
class BCPTestingFramework:
    def __init__(self):
        self.test_scenarios = self.load_test_scenarios()
        self.execution_engine = TestExecutionEngine()
        self.reporting_module = TestReportingModule()

    def schedule_tests(self):
        """Programa tests basado en calendario anual"""
        for test in self.get_scheduled_tests():
            if test.is_due():
                self.execution_engine.queue_test(test)

    def execute_automated_test(self, test_scenario):
        """Ejecuta test automatizado con monitorización"""
        try:
            # Pre-test validation
            self.validate_test_environment(test_scenario)

            # Execute test steps
            start_time = time.time()
            results = self.execution_engine.run(test_scenario)
            execution_time = time.time() - start_time

            # Validate results
            success = self.validate_test_results(results, test_scenario)

            # Generate report
            self.reporting_module.generate_report({
                'scenario': test_scenario,
                'results': results,
                'execution_time': execution_time,
                'success': success
            })

            return success

        except Exception as e:
            self.handle_test_failure(test_scenario, str(e))
            return False

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