OP.EXT.2 Gestión diaria

☑️Aplicación de la medida

De acuerdo al ANEXO II, 2 Selección de medidas de seguridad, la medida de seguridad OP.EXT.2 Gestión diaria sí aplica dada la categoría de seguridad del sistema.

Documentos de referencia

• ISO/IEC 27000:
  • 27002:2013:
    • 15.2.1 - Monitoring and review of supplier services
    • 15.2.2 - Managing changes to supplier services
• NIST SP 800-53 rev4:
  • [SA-9] External Information System Services
  • [CA-7] Continuous Monitoring
• Otras referencias:
  • FDA Cybersecurity in Medical Devices: Supply Chain Considerations
  • ISO 13485:2016 - Supplier monitoring requirements

Guía de implantación

191. Se establecerán los mecanismos necesarios para la supervisión diaria de los servicios prestados por terceros y el control del cumplimiento de los acuerdos establecidos.

Incluirá al menos:

• Procedimientos de supervisión de los servicios externalizados
• Procedimientos de gestión de incidentes con terceros
• Procedimientos de gestión de cambios en servicios externalizados
• Mecanismos de comunicación y coordinación con proveedores

Implementación en Legit Health Plus

Marco de supervisión diaria

La supervisión diaria de servicios externos críticos para Legit Health Plus requiere monitorización continua, alertas proactivas y respuesta coordinada para mantener la continuidad del servicio de diagnóstico médico.

Dashboard de supervisión de proveedores

PRO-EXT-DAILY-001: Generación de reporte diario de proveedores críticos

Objetivo: Generar diariamente un informe consolidado del estado de todos los proveedores críticos, identificar problemas y recomendar acciones correctivas.

Proveedores críticos monitorizados:

• Infraestructura AWS (aws_infrastructure)
• Seguridad CrowdStrike (crowdstrike_security)
• Certificación Organismo Notificado (notified_body_certification)
• Firma de Cumplimiento Legal (legal_compliance_firm)

Proceso de generación del reporte diario:

1. Inicializar reporte: Crear estructura del reporte con fecha actual y estado general inicial "GREEN"

2. Para cada proveedor crítico:

   • Recopilar métricas: Obtener métricas actuales del proveedor
   • Evaluar estado: Calcular puntuación de salud (health_score) del proveedor basándose en las métricas
   • Registrar estado: Documentar el estado del proveedor en el reporte
   • Generar alertas si necesario:
     • Si health_score < 6.0: Generar alerta de ALTA severidad
     • Si health_score 6.0-7.9: Generar alerta de MEDIA severidad
     • Si health_score ≥ 8.0: No generar alerta
   • Actualizar estado general:
     • Si health_score < 7.0 y estado actual es GREEN: Cambiar a YELLOW
     • Si health_score < 7.0 y estado actual es YELLOW: Cambiar a RED

3. Distribuir reporte: Enviar el reporte diario a los stakeholders correspondientes

Estructura del reporte diario:

Campo	Descripción
Fecha	Fecha de generación del reporte
Estado general	GREEN (todos > 7.0), YELLOW (alguno 6.0-7.0), RED (alguno < 6.0)
Estado por proveedor	Desglose de métricas, health_score y problemas de cada proveedor
Alertas	Lista de alertas generadas con proveedor, severidad, descripción y acción recomendada
Recomendaciones	Acciones sugeridas para mejorar la gestión de proveedores

Recolección de métricas específicas por proveedor:

Para AWS (aws_infrastructure):

• Salud de instancias EC2
• Métricas de rendimiento de RDS
• Disponibilidad de buckets S3
• Latencia de API Gateway
• Detección de anomalías de costos

Para CrowdStrike (crowdstrike_security):

• Métricas específicas de seguridad (detalladas en procedimiento de monitorización de seguridad)

Nota: El sistema debe ejecutar este procedimiento automáticamente cada día a las 08:00 AM y distribuir el reporte a CTO, CISO y CEO

Monitorización continua por categoría

Infraestructura cloud (AWS)

Monitorización diaria de infraestructura AWS:

El sistema debe verificar diariamente los siguientes aspectos de la infraestructura cloud de AWS que soporta el dispositivo médico:

Verificaciones de salud:

Verificación	Objetivo
Estado de instancias EC2	Verificar que todas las instancias pasan los status checks
Conectividad y rendimiento RDS	Confirmar conectividad y rendimiento de base de datos
Disponibilidad de buckets S3	Verificar disponibilidad y acceso a almacenamiento
Salud de distribuciones CloudFront	Confirmar funcionamiento de CDN
Conectividad de red VPC	Verificar conectividad de red privada virtual

Métricas de rendimiento:

Métrica	Umbral de cumplimiento
Latencia de API Gateway	< 2 segundos (percentil 95)
Rendimiento de consultas BD	< 100ms promedio
Utilización de IOPS de almacenamiento	< 80%
Throughput de red	Monitorización de tendencias
Utilización CPU/Memoria	Identificación de tendencias

Monitorización de seguridad:

Aspecto	Descripción
Análisis de logs CloudTrail	Revisar actividad de API para detectar anomalías
Detección de amenazas GuardDuty	Verificar alertas de seguridad
Verificaciones de Config	Confirmar cumplimiento de configuraciones de seguridad
Revisión de cambios de políticas IAM	Revisar modificaciones de permisos
Modificaciones de grupos de seguridad	Detectar cambios en reglas de firewall

Gestión de costos:

Aspecto	Objetivo
Gasto diario vs presupuesto	Identificar desviaciones de presupuesto
Eficiencia de utilización de recursos	Detectar recursos infrautilizados
Optimización de instancias reservadas	Identificar oportunidades de optimización de costos
Identificación de recursos sin uso	Detectar recursos que pueden ser descomisionados

Ciberseguridad (CrowdStrike)

Monitorización diaria de servicios de ciberseguridad:

El sistema debe verificar diariamente los siguientes aspectos del servicio de seguridad proporcionado por CrowdStrike:

Protección de endpoints:

Verificación	Umbral/Objetivo
Estado de salud de agentes	≥ 99% de agentes online
Detecciones y respuestas a amenazas	Verificar todas las detecciones y respuestas
Cumplimiento de políticas	100% de endpoints cumpliendo políticas
Estado de actualizaciones	Versión consistente en todos los endpoints

Inteligencia de amenazas:

Aspecto	Descripción
Nuevos indicadores de amenaza	Revisar indicadores de compromiso recibidos
Resultados de hunting queries	Analizar resultados de búsquedas proactivas de amenazas
Alertas de análisis de comportamiento	Revisar detecciones basadas en comportamiento anómalo
Coincidencias de IOCs personalizados	Verificar matches con indicadores personalizados

Respuesta a incidentes:

Verificación	Objetivo
Estado de incidentes abiertos de seguridad	Revisar y actualizar estado de incidentes
Métricas de tiempo de respuesta	Verificar cumplimiento de tiempos de respuesta
Efectividad de contención	Evaluar éxito de medidas de contención
Estado de recolección de datos forenses	Confirmar captura de evidencia cuando aplique

Procedimientos de escalado y comunicación

Matriz de escalado por severidad

Matriz de escalado de incidentes con proveedores:

Severidad	Definición	Tiempo de respuesta inicial	Rutas de escalado
Severidad 1 (Crítico)	Servicio que afecta la capacidad de diagnóstico de pacientes	15 minutos	• 0 min: Contacto técnico del proveedor + nuestro DevOps Lead • 15 min: Account Manager del proveedor + nuestro CTO • 30 min: Dirección senior del proveedor + nuestro CEO • 60 min: Involucración legal + revisión de contrato
Severidad 2 (Alto)	Degradación de rendimiento >20% o preocupación de seguridad	1 hora	• 0 min: Equipo de soporte del proveedor + nuestro equipo técnico • 4 horas: Dirección del proveedor + nuestra dirección • 24 horas: Revisión de contrato si no resuelto
Severidad 3 (Medio)	Problemas no críticos o impacto menor en rendimiento	4 horas	• 0 min: Canales estándar de soporte • 48 horas: Notificación a dirección si no resuelto

Procedimiento de comunicación con proveedores

PRO-EXT-INCIDENT-001: Iniciación de incidente con proveedor

Objetivo: Establecer comunicación formal con el proveedor ante un incidente, creando casos de soporte en sus sistemas y programando seguimiento.

Canales de comunicación por proveedor:

Proveedor	Canal primario	Emergencia	Contacto de cuenta/técnico
AWS	Portal de soporte enterprise	+1-206-266-4064	aws-tam@amazon.com
CrowdStrike	Portal de soporte	1-855-840-9073	tech-support@crowdstrike.com

Proceso de iniciación de incidente:

1. Preparar datos del incidente:

   • Timestamp actual
   • Identificador del proveedor
   • Severidad (Crítico/Alto/Medio)
   • Descripción detallada del problema
   • Información de contacto del proveedor
   • Generar ID de incidente interno

2. Crear caso en sistema del proveedor:

   • Para AWS: Crear caso de soporte con los datos del incidente
   • Para CrowdStrike: Crear ticket de soporte técnico
   • Recibir ID de caso del proveedor

3. Notificar internamente: Alertar al equipo interno con los detalles del incidente y el ID de caso del proveedor

4. Programar seguimiento automático: Establecer recordatorios de seguimiento según la severidad

5. Registrar resultado:

   • ID de incidente interno
   • ID de caso del proveedor
   • Estado: iniciado

PRO-EXT-INCIDENT-001-A: Creación de caso AWS específico

Objetivo: Crear un caso de soporte en AWS Enterprise Support enfatizando el contexto de dispositivo médico.

Pasos para crear caso AWS:

1. Preparar título del caso: Formato "Medical Device Critical Issue - [primeras 50 palabras de descripción]"

2. Determinar código de servicio:

   • Si menciona EC2: usar código amazon-ec2
   • Si no: usar código general-info

3. Determinar severidad AWS:

   • Severidad_1 interna → "critical" en AWS
   • Severidad_2 interna → "high" en AWS
   • Severidad_3 interna → "normal" en AWS

4. Componer mensaje del caso incluyendo:

   • Encabezado: "Legit Health Plus Medical Device Emergency"
   • ID de incidente interno
   • Severidad
   • Descripción completa del problema
   • Contexto médico:
     • "This issue affects our Class IIa medical device providing dermatological diagnosis"
     • "Patient safety may be impacted if not resolved quickly"
   • Tiempo de respuesta requerido (según severidad)
   • Contactos técnicos y médicos:
     • Técnico: devops@legit.health
     • Médico: CMO alfonso@legit.health

5. Enviar caso a AWS: Crear el caso con todos los datos especificados

6. Obtener ID de caso: Guardar el ID de caso retornado por AWS para seguimiento

Gestión de cambios en servicios externos

Proceso de notificación de cambios

Requisitos de notificación de cambios por proveedores:

Cambios críticos:

Requisito	Detalle
Aviso previo	Mínimo 90 días de antelación
Evaluación de impacto	Evaluación detallada de impacto requerida
Plan de mitigación	Obligatorio
Procedimiento de rollback	Debe estar documentado

Cambios estándar:

Requisito	Detalle
Aviso previo	30 días de antelación
Evaluación de impacto	Evaluación básica de impacto
Coordinación de ventana de cambio	Coordinación de horarios requerida

Cambios de emergencia:

Requisito	Detalle
Notificación	Inmediata
Evaluación de impacto post-cambio	Requerida después de implementar el cambio
Proceso de aprobación expedito	Proceso acelerado de aprobación

Flujo de aprobación de cambios:

Revisión técnica:

Aspecto	Responsable
Evaluación del equipo DevOps	DevOps Team
Evaluación de impacto en seguridad	Security Team
Análisis de impacto en rendimiento	Technical Team

Revisión médica:

Aspecto	Responsable
Aprobación CMO para impacto clínico	CMO (Chief Medical Officer)
Evaluación de seguridad del paciente	Medical Safety Team
Revisión de cumplimiento regulatorio	Regulatory Compliance Team

Aprobación de dirección:

Aspecto	Responsable
Sign-off del CTO para cambios técnicos	CTO
Aprobación del CEO para cambios de alto riesgo	CEO

Tracking de cambios de proveedores

PRO-EXT-CHANGE-001: Procesamiento de notificación de cambio de proveedor

Objetivo: Procesar, evaluar y aprobar cambios notificados por proveedores, asegurando que no afecten negativamente al servicio médico ni a la seguridad del paciente.

Proceso de procesamiento de cambios:

1. Crear registro de cambio:

   • Generar ID único de cambio
   • Registrar proveedor, tipo de cambio, descripción
   • Documentar fecha propuesta de implementación
   • Estado inicial: "pendiente"

2. Evaluar impacto del cambio: Ejecutar análisis de impacto (ver PRO-EXT-CHANGE-001-A)

3. Determinar nivel de impacto: Clasificar como HIGH, MEDIUM o LOW

4. Iniciar flujo de aprobación según impacto:

   • Si impacto HIGH o afecta seguridad del paciente: Iniciar aprobación de alto impacto (requiere CMO, CTO, CEO)
   • Si impacto MEDIUM o LOW: Iniciar aprobación estándar (requiere equipo técnico)

5. Guardar registro: Almacenar el registro del cambio en base de datos de cambios

PRO-EXT-CHANGE-001-A: Evaluación de impacto de cambio

Objetivo: Analizar un cambio propuesto por un proveedor para determinar su nivel de impacto en nuestros servicios y seguridad del paciente.

Factores de impacto a evaluar:

Factor	Indicadores clave en descripción
Afecta servicio de diagnóstico	Palabras clave: database, api, compute, network
Afecta datos de pacientes	Palabras clave: storage, backup, data, patient
Afecta seguridad	Palabras clave: encryption, security, authentication
Afecta cumplimiento	Palabras clave: compliance, certification, audit, regulatory
Requiere downtime	Palabras clave: downtime, maintenance window, outage

Proceso de evaluación:

1. Analizar descripción del cambio: Buscar palabras clave relevantes en la descripción (convertida a minúsculas)

2. Identificar factores afectados:

   • Si contiene palabras clave de diagnóstico → Marcar "afecta servicio de diagnóstico"
   • Si contiene palabras clave de seguridad → Marcar "afecta seguridad"
   • Evaluar cada factor según las palabras clave

3. Calcular nivel de impacto:

   • HIGH: 3 o más factores afectados
   • MEDIUM: 1-2 factores afectados
   • LOW: 0 factores afectados

4. Determinar impacto en seguridad del paciente:

   • Si afecta servicio de diagnóstico O afecta datos de pacientes → Sí
   • Si no → No

5. Generar recomendaciones: Crear lista de acciones recomendadas según los factores identificados

Resultado de la evaluación:

• Nivel de impacto (HIGH/MEDIUM/LOW)
• Factores afectados (detalle booleano de cada factor)
• Afecta seguridad del paciente (Sí/No)
• Recomendaciones específicas para mitigar riesgos

Reportes y métricas diarias

Dashboard ejecutivo de proveedores

KPIs diarios del dashboard ejecutivo:

Salud general de proveedores:

Estado	Criterio
Verde	95%+ de proveedores cumpliendo SLA
Amarillo	85-94% de proveedores cumpliendo SLA
Rojo	<85% de proveedores cumpliendo SLA

Estado de servicios críticos:

Servicio	Objetivo
Uptime de infraestructura	99.99% objetivo
Efectividad del servicio de seguridad	>90%
Estado de cumplimiento	100% objetivo

Impacto financiero:

Métrica	Descripción
Créditos de SLA ganados este mes	Créditos acumulados por incumplimientos
Variación de costos vs presupuesto	Desviación del gasto planificado
ROI de relaciones con proveedores	Retorno de inversión de servicios externalizados

Tendencias semanales:

Tendencia	Descripción
Rendimiento de proveedores	Evolución del cumplimiento de SLAs
Volumen de incidentes por proveedor	Cantidad y tendencia de incidentes
Mejoras en tiempos de respuesta	Evolución de métricas de respuesta
Nuevos riesgos u oportunidades identificadas	Riesgos emergentes y oportunidades de mejora

Generación automatizada de reportes

PRO-EXT-REPORT-001: Generación de resumen ejecutivo diario

Objetivo: Generar automáticamente cada día un resumen ejecutivo del estado de proveedores para stakeholders de dirección.

Proceso de generación del resumen:

1. Calcular estado general de proveedores: Determinar el estado agregado (GREEN/YELLOW/RED) basándose en el cumplimiento de SLAs

2. Identificar incidencias críticas: Detectar y listar problemas críticos que requieren atención inmediata de dirección

3. Calcular desempeño de SLAs: Evaluar el cumplimiento de acuerdos de nivel de servicio de cada proveedor

4. Calcular impacto en costos: Determinar créditos ganados por incumplimientos y desviaciones presupuestarias

5. Obtener cambios próximos: Listar cambios de proveedores programados para los próximos días

6. Generar recomendaciones: Crear lista de acciones recomendadas para mejorar la gestión de proveedores

7. Formatear reporte HTML: Convertir el resumen en formato HTML visualmente atractivo

8. Enviar por email: Distribuir el reporte por email a stakeholders ejecutivos (CTO, CEO, CISO), ajustando urgencia según el estado general

9. Actualizar dashboard en tiempo real: Refrescar el dashboard ejecutivo con la información actualizada

Contenido del resumen ejecutivo:

Sección	Contenido
Fecha	Fecha del reporte
Estado general	Indicador visual del estado agregado de proveedores
Incidencias críticas	Lista de problemas que requieren atención inmediata
Desempeño de SLAs	Métricas de cumplimiento por proveedor
Impacto en costos	Créditos ganados y variaciones presupuestarias
Cambios próximos	Calendario de cambios programados por proveedores
Recomendaciones	Acciones sugeridas para dirección

Distribución: El reporte se genera automáticamente cada día a las 08:00 AM y se envía a la lista de distribución ejecutiva

Integración con gestión de incidentes

Workflow de incidentes con proveedores

Flujo de gestión de incidentes con proveedores:

1. Detección de problema del proveedor

↓

2. Evaluación de severidad → Determinar si es Crítico, Alto o Medio/Bajo

3a. Si es CRÍTICO:

• Escalado inmediato
• Activar gestión de crisis
• Involucrar contactos de emergencia del proveedor
• Notificar stakeholders internos
• Evaluar impacto en seguridad del paciente
  • Si hay riesgo para paciente: Activar respuesta de emergencia médica
  • Si no hay riesgo: Continuar con resolución técnica

3b. Si es ALTO:

• Escalado estándar
• Crear caso de soporte con proveedor
• Monitorizar progreso
• ¿Resuelto dentro del SLA?
  • No: Escalar a dirección
  • Sí: Documentar y cerrar

3c. Si es MEDIO/BAJO:

• Proceso de soporte normal
• Usar canales estándar de soporte

Decisiones clave en el flujo:

Punto de decisión	Criterio	Acción según resultado
Evaluación de severidad	Impacto en servicio de diagnóstico	Crítico → Gestión de crisis Alto → Escalado estándar Bajo → Soporte normal
¿Riesgo para seguridad del paciente?	¿Afecta capacidad diagnóstica o datos de pacientes?	Sí → Emergencia médica No → Resolución técnica
¿Resuelto en SLA?	¿Se cumplió el tiempo de resolución acordado?	No → Escalar a dirección Sí → Cerrar incidente

Métricas de rendimiento

KPIs de gestión diaria

KPIs de gestión diaria de proveedores:

Capacidad de respuesta:

KPI	Objetivo
Tiempo promedio de respuesta del proveedor	< 15 min (crítico)
Tasa de resolución en primer contacto	> 60%
Tasa de escalado	< 10% del total de incidentes

Calidad:

KPI	Objetivo
Tasa de cumplimiento de SLA	> 98%
Satisfacción con gestión de proveedores	> 4.5/5
Tasa de identificación proactiva de problemas	> 70%

Eficiencia:

KPI	Objetivo
Costo por incidente gestionado	Tendencia descendente
Tiempo dedicado a gestión de proveedores	< 20% del tiempo IT
Tasa de automatización de tareas rutinarias	> 80%

Referencias cruzadas

• OP.EXT.1: SLA y contratos base para gestión diaria
• OP.EXT.3: Protección de cadena de suministro
• OP.EXP.7: Integración con gestión de incidentes interno
• OP.MON.2: Métricas de proveedores integradas en sistema general
• T-024-008: Procedimiento de gestión diaria de terceros

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