NIS2 en hospitales plantea una tensión real que no aparece en los textos de la directiva: la ciberseguridad no puede pausar la asistencia. Un hospital no puede desconectar un sistema de monitorización de pacientes para aplicar un parche, ni puede permitir que la respuesta a un incidente deje sin datos al servicio de urgencias. Y sin embargo, la Directiva (UE) 2022/2555 obliga al sector sanitario a adoptar medidas de ciberseguridad proporcionales, documentadas y auditables.
La pregunta no es si cumplir, es cómo hacerlo de forma que refuerce la operación en lugar de cargarla. Los hospitales y centros sanitarios que consiguen integrar NIS2 en su operativa real son los que tratan la seguridad como una función clínica más: continua, priorizada por riesgo al paciente y con responsables claros. Esta guía explica cómo llegar ahí.
Estado de la transposición en España: lo que necesitas saber hoy
Nota legal importante (mayo 2026): Que la transposición esté pendiente no exime de riesgos reputacionales, contractuales ni operativos. El INCIBE-CERT ya designado como CSIRT de referencia para el sector privado, y el CCN-CERT para el sector público, coinciden en que las medidas técnicas que exige la directiva requieren meses de implementación y no conviene esperar a la publicación en el BOE.
Por qué el sector sanitario es esencial bajo NIS2
La Directiva NIS2 clasifica el sector sanitario en su Anexo I como sector de alta criticidad, con las obligaciones más exigentes: supervisión activa por la autoridad competente, plazos estrictos de notificación de incidentes y sanciones elevadas en caso de incumplimiento grave. El razonamiento es directo: una interrupción de los sistemas de un hospital puede tener consecuencias sobre la vida de los pacientes, no solo sobre datos o reputación.
Quién queda cubierto, y en qué categoría
La directiva distingue entre entidades esenciales y entidades importantes, con umbrales de tamaño específicos según confirma el propio INCIBE-CERT:
- Entidades esenciales: grandes empresas del Anexo I con más de 250 empleados y más de 50 millones de euros de volumen de negocio anual. Sujetas a supervisión proactiva y sanciones máximas.
- Entidades importantes: medianas empresas del Anexo I con más de 50 empleados y más de 10 millones de euros de volumen de negocio anual. Sujetas a supervisión reactiva y sanciones algo menores.
Un hospital comarcal de 180 camas puede ser entidad importante, no esencial, lo que tiene implicaciones distintas en el régimen de supervisión y en los plazos de implementación. La distinción importa: no asumas la categoría sin analizarla.
Además, la autoridad competente de cada Estado miembro puede clasificar como esencial o importante a cualquier proveedor cuyo fallo pueda provocar consecuencias significativas para la seguridad y salud pública, independientemente del tamaño. Un centro pequeño que sea el único proveedor de un servicio crítico en su territorio no puede asumir que queda automáticamente fuera.
Quedan cubiertos bajo este epígrafe:
- Hospitales públicos y privados con internamiento
- Centros de atención especializada con sistemas de soporte vital digital
- Laboratorios de diagnóstico conectados a sistemas de historia clínica
- Redes de centros de salud con infraestructura TIC centralizada
- Plataformas de telemedicina e historia clínica electrónica con impacto en continuidad asistencial
El riesgo específico del hospital: cuando el dato clínico y la vida del paciente comparten red
El entorno tecnológico de un hospital moderno no se parece al de una empresa convencional. Conviven sistemas de historia clínica electrónica, equipos médicos conectados (monitores, bombas de infusión, ventiladores, sistemas de imagen diagnóstica), redes de comunicación clínica, plataformas de laboratorio y sistemas administrativos, muchas veces con distintos proveedores, ciclos de vida diferentes y niveles de seguridad heterogéneos.
Esta complejidad crea tres riesgos particulares:
Impacto directo sobre la atención al paciente. Un ataque de ransomware que cifre el HIS (Hospital Information System) no solo bloquea datos: puede forzar el desvío de ambulancias, cancelar cirugías programadas y obligar a revertir a procesos manuales que generan errores. Lo hemos visto en incidentes reales en Europa en los últimos años.
Superficie de ataque extensa y heterogénea. Los dispositivos médicos conectados (IoMT) no siempre tienen capacidad de recibir actualizaciones de seguridad. Muchos corren sistemas operativos sin soporte activo porque la certificación del fabricante no contempla actualizaciones frecuentes. Eso crea una superficie permanente de exposición.
Datos de salud como objetivo de alto valor. Los registros médicos valen en el mercado negro más que los datos financieros. Los hospitales son objetivo prioritario de actores maliciosos que combinan exfiltración de datos con interrupción de servicio para maximizar la presión de extorsión.
El RGPD ya imponía obligaciones sobre el tratamiento de datos de salud como categoría especial. NIS2 añade la capa de seguridad de redes y sistemas. Y desde marzo de 2025 existe un tercer marco relevante: el Reglamento (UE) 2025/327 del Espacio Europeo de Datos de Salud (EHDS), en vigor desde el 26 de marzo de 2025 con aplicación progresiva hasta 2031. Los tres marcos deben gestionarse de forma coordinada, no como silos paralelos.
Lo que NIS2 exige concretamente al hospital
El artículo 21 de la Directiva (UE) 2022/2555 establece las medidas mínimas de gestión de riesgos que toda entidad obligada debe adoptar. Traducidas al entorno hospitalario:
Políticas de seguridad de la información y análisis de riesgos. El hospital necesita un marco documentado que contemple análisis periódico de riesgos específicos del entorno sanitario: no solo infraestructura TI corporativa, sino también sistemas clínicos, dispositivos IoMT y accesos de terceros. Los equipos médicos conectados deben figurar en el inventario de activos con su perfil de riesgo.
Gestión de incidentes. Procedimientos de detección, clasificación, contención y recuperación adaptados a la realidad clínica. Clasificar un incidente en urgencias mientras hay pacientes críticos es diferente a hacerlo en una empresa de servicios: los procedimientos deben reflejarlo. El plan de respuesta ante brechas de datos debe coordinarse con los protocolos de continuidad asistencial.
Continuidad y recuperación. Planes de backup y recuperación para sistemas críticos clínicos, con procedimientos de operación manual testados regularmente. No basta con tener copias de seguridad: el personal debe saber operar sin sistemas digitales durante una ventana de tiempo definida.
Seguridad de la cadena de suministro. Los proveedores de software clínico, mantenimiento de equipos médicos, servicios de imagen en la nube y soporte remoto de dispositivos son vectores de riesgo documentados en NIS2. El hospital debe evaluar y gestionar los riesgos que cada uno introduce.
Control de accesos y autenticación multifactor (MFA). Para accesos privilegiados, gestión de identidades para personal propio y externo, y control de accesos a sistemas clínicos con trazabilidad. Esto incluye los accesos de ingenieros de mantenimiento de equipos médicos: uno de los vectores más frecuentemente explotados.
Formación del personal. El artículo 20 de la directiva exige que el órgano de dirección apruebe las medidas y reciba formación en ciberseguridad. En hospitales, esto se extiende al personal clínico: la ingeniería social dirigida a enfermería o médicos es el vector de entrada más común en entornos sanitarios. La formación bonificada a través de FUNDAE puede reducir el coste de este componente.
Notificación de incidentes. El régimen de tres fases aplica a incidentes con impacto significativo en la prestación del servicio. En el sector sanitario, el umbral de «significativo» suele alcanzarse antes que en otros sectores.
La responsabilidad del órgano de dirección: cifras que importan
El artículo 20 de la Directiva (UE) 2022/2555 establece responsabilidad directa del órgano de dirección. El anteproyecto de ley español prevé:
- Multas de hasta 500.000 euros por responsabilidad personal de directivos en casos de incumplimiento grave.
- Inhabilitación temporal para el ejercicio del cargo.
Para un comité de dirección médica o un consejo de administración hospitalario, esto significa que delegar toda la ciberseguridad al responsable de TI sin participación ejecutiva efectiva ya no es suficiente desde un punto de vista normativo. El órgano de gobierno debe ser capaz de explicar qué decisiones tomó, con qué información y cuándo las revisó.
Gestión y notificación de incidentes: los plazos que no admiten improvisación
| Fase | Plazo | Contenido mínimo |
|---|---|---|
| Alerta temprana | 24 horas | Si se sospecha origen malicioso y posible impacto transfronterizo |
| Notificación de incidente | 72 horas | Evaluación inicial del impacto, indicadores de compromiso, medidas adoptadas |
| Informe final | 1 mes | Descripción detallada, causa raíz, impacto real y lecciones aprendidas |
Fuente: INCIBE-CERT. NIS2: lo que necesitas saber
Los plazos corren desde que la entidad tiene conocimiento del incidente, no desde que está completamente analizado. En el sector sanitario, si el incidente implica además una brecha de datos de salud, aplican simultáneamente los plazos NIS2 y los del RGPD ante la AEPD. La respuesta debe estar coordinada desde el primer momento.
Lo que no puede improvisarse: la clasificación interna de incidentes, la cadena de decisión desde el NOC o SOC hasta dirección médica, y los procedimientos de comunicación con reguladores.
Cómo construir el programa NIS2 sin detener la asistencia
La trampa habitual es plantearse el cumplimiento NIS2 como un proyecto TI paralelo a la operación clínica. Ese enfoque produce documentación que nadie en planta reconoce y medidas que no sobreviven al primer turno de guardia. El enfoque que funciona es distinto:
Integrar ciberseguridad en los procesos clínicos existentes. Los protocolos de actuación ante fallos de sistemas digitales ya existen en la mayoría de hospitales. El punto de partida es ampliar esos protocolos para incluir la dimensión de ciberseguridad, no crear un universo paralelo de procedimientos.
Priorizar por riesgo al paciente, no por madurez tecnológica. La primera pregunta no es «¿qué sistema tiene más vulnerabilidades técnicas?» sino «¿qué fallo de sistema puede poner en riesgo la vida de un paciente en las próximas dos horas?». El análisis de riesgos NIS2 en hospitales debe tener esa lógica: continuidad asistencial primero.
Fases de implantación compatibles con la operación. Los cambios técnicos en sistemas clínicos críticos deben planificarse con el mismo rigor que un mantenimiento programado: ventanas fuera de picos de actividad, planes de rollback y coordinación con los servicios clínicos afectados.
Responsables con autoridad real. En hospitales, el CISO o responsable de seguridad TI raramente tiene autoridad directa sobre sistemas clínicos. La estructura de gobierno NIS2 necesita un comité interdisciplinar con representación de dirección médica, enfermería, TI y jurídico. Sin esa estructura, las decisiones de seguridad se bloquean en fronteras departamentales.
Formación continua y realista para el personal clínico. No cursos genéricos de contraseñas: formación específica sobre los ataques dirigidos al sector sanitario, con ejemplos de ingeniería social adaptados al contexto clínico.
Dispositivos médicos conectados (IoMT): el punto ciego habitual
Los equipos médicos conectados son el mayor desafío técnico de NIS2 en hospitales. Las reglas que funcionan en entornos IT corporativos, parche inmediato, sustitución de equipos sin soporte, actualización continua, no aplican igual a un monitor de UCI o a un sistema de imagen diagnóstica.
El problema: muchos dispositivos médicos corren software certificado por el fabricante que no puede modificarse sin perder la certificación o la garantía. Algunos corren sistemas operativos sin soporte activo. El fabricante puede tardar meses en publicar una actualización de seguridad. Y desconectar el equipo para mantenimiento requiere coordinación clínica que no siempre es posible.
La respuesta NIS2-compatible: la directiva no exige parchear lo que no puede parchearse, exige documentar la decisión y los controles compensatorios. Para dispositivos IoMT con vulnerabilidades conocidas no parcheables, el enfoque correcto combina:
- Segmentación de red que aísle el dispositivo de rutas de ataque conocidas.
- Monitorización de tráfico anómalo desde y hacia el dispositivo.
- Registro de riesgo residual aceptado con propietario, fecha de revisión y controles compensatorios documentados.
- Proceso de sustitución planificado cuando el dispositivo llegue a fin de vida útil.
El marco IEC 62443, desarrollado por la International Electrotechnical Commission para ciberseguridad en sistemas de automatización y control industrial, proporciona controles específicos para entornos de automatización clínica que ISO/IEC 27001 no detalla para este contexto.
Proveedores y cadena de suministro: el riesgo que viene de fuera
Los hospitales concentran muchos proveedores con acceso a sistemas críticos: integradores de HIS, empresas de mantenimiento de equipos médicos, laboratorios de diagnóstico externalizados, empresas de radiología, proveedores de telemedicina y servicios cloud de historia clínica.
NIS2 exige que el hospital evalúe y gestione el riesgo que cada proveedor introduce. Proceso mínimo:
- Clasificar proveedores por criticidad: ¿tiene acceso a sistemas que afectan la continuidad asistencial?, ¿puede acceder a datos de salud?, ¿tiene acceso remoto permanente?
- Revisar condiciones de acceso: los accesos remotos de mantenimiento deben estar documentados, limitados en tiempo, registrados y protegidos con MFA.
- Incluir cláusulas de seguridad en contratos: derecho de auditoría, obligación de notificación de incidentes que afecten al hospital, requisitos mínimos de seguridad del proveedor.
- Revisar periódicamente: la revisión anual de proveedores críticos debe quedar documentada.
RGPD, NIS2 y EHDS en el hospital: tres marcos que deben hablar entre sí
El sector sanitario tiene una triple obligación regulatoria que debe gestionarse de forma coordinada:
RGPD: protección de datos de salud como categoría especial (artículo 9). Evaluaciones de impacto (EIPD) para tratamientos de alto riesgo. Notificación de brechas a la AEPD en 72 horas.
NIS2: seguridad de redes y sistemas. Gestión de riesgos proporcional y documentada. Notificación de incidentes con impacto significativo en el servicio en 24h/72h/1 mes.
EHDS, Reglamento (UE) 2025/327: marco para el intercambio seguro de datos de salud electrónicos en la UE. En vigor desde el 26 de marzo de 2025 con aplicación progresiva: obligaciones generales desde marzo de 2027, otras específicas desde 2029 y 2031. Impone requisitos de interoperabilidad y seguridad a los sistemas de historia clínica electrónica (HCE) y a los proveedores de tecnología sanitaria.
Los puntos de solapamiento más relevantes entre NIS2 y RGPD:
- Análisis de riesgos: tanto la EIPD (RGPD) como el análisis de riesgos NIS2 exigen evaluaciones documentadas. Integrarlas evita duplicar esfuerzo y produce evidencias más sólidas.
- Notificación de brechas: un incidente que afecte sistemas clínicos puede activar simultáneamente la obligación NIS2 (impacto en servicio) y la obligación RGPD (brecha de datos de salud). La respuesta debe ser coordinada desde el primer minuto.
- Gestión de proveedores: los encargados del tratamiento bajo RGPD y los proveedores críticos bajo NIS2 se solapan frecuentemente. Los contratos deben cubrir ambas dimensiones.
Certificaciones útiles para hospitales bajo NIS2
ISO/IEC 27001 proporciona el SGSI base: análisis de riesgos, controles documentados, ciclo de mejora continua y gestión de incidentes estructurada. Para un hospital que necesita demostrar cumplimiento NIS2, es la certificación con mayor reconocimiento ante supervisores europeos.
ISO/IEC 27701 extiende el SGSI con el sistema de gestión de privacidad (PIMS), especialmente relevante para hospitales dado el volumen de datos de salud que tratan y la necesidad de alinear NIS2 con el RGPD y el EHDS en un único programa.
ENS (Esquema Nacional de Seguridad) aplica cuando el hospital tiene relación contractual con administraciones públicas, lo que ocurre en la mayoría de hospitales del SNS y en muchos concertados. El CCN ha desarrollado el Perfil de Cumplimiento Específico PCE-NIS2 (Guía CCN-STIC 892) que alinea ENS con los requisitos NIS2 para el sector sanitario.
IEC 62443 aporta controles específicos para sistemas de automatización y control industrial que ISO 27001 no detalla para entornos de automatización clínica e IoMT. Combinar ambos marcos es la estructura más robusta para hospitales con infraestructura mixta.
Lo que puede salir mal: sanciones y riesgos reales
Sanciones económicas:
- Entidades esenciales: hasta 10 millones de euros o el 2 % del volumen de negocio global anual, lo que sea mayor.
- Entidades importantes: hasta 7 millones de euros o el 1,4 % del volumen de negocio global anual.
- Responsabilidad personal de directivos: hasta 500.000 euros e inhabilitación temporal para el ejercicio del cargo (anteproyecto de ley español).
Más allá de la multa:
- Suspensión temporal de la autorización para operar servicios regulados.
- Exposición reputacional ante pacientes, aseguradoras y financiadores.
- Riesgo operativo real: los centros que no gestionan activamente sus riesgos de ciberseguridad son más vulnerables a ataques cuyo impacto puede ser directamente grave para los pacientes.
Qué ofrece Privalex en proyectos NIS2 para hospitales
Privalex acompaña a hospitales y entidades sanitarias en el diseño e implantación de programas NIS2 que son operativos desde el primer día, no solo documentalmente correctos. Nuestro enfoque integra ISO/IEC 27001, ISO/IEC 27701, ENS y los requisitos específicos del entorno clínico, incluyendo dispositivos IoMT, accesos de proveedores y coordinación con los procesos asistenciales.
Trabajamos con el equipo jurídico, el DPO, el responsable de seguridad TI y la dirección médica para crear un programa que la organización pueda sostener internamente, no uno que requiera consultoría permanente para mantenerse en pie.
Si queréis empezar con una evaluación de brechas NIS2 adaptada al entorno sanitario, acceded a la valoración de riesgo gratuita. Para alinear alcance y prioridades con la dirección del centro, reservad una sesión estratégica.
Preguntas Frecuentes
No necesariamente. Los hospitales del Anexo I de la Directiva NIS2 son entidades esenciales si superan los 250 empleados y 50 millones de euros de volumen de negocio anual. Los que superan 50 empleados y 10 millones de euros pero no llegan a esos umbrales son entidades importantes, con régimen de supervisión y sanciones distintos. Además, la autoridad competente puede clasificar como esencial o importante a cualquier centro cuya interrupción genere impacto significativo en la salud pública, independientemente del tamaño. Consulta la guía del INCIBE-CERT sobre NIS2 en salud.
La Directiva NIS2 no exige parchear lo que no puede parchearse por razones de certificación: exige documentar la decisión y los controles compensatorios. Para dispositivos IoMT con vulnerabilidades conocidas el enfoque correcto combina: segmentación de red que aísle el dispositivo de rutas de ataque conocidas, monitorización de tráfico anómalo, registro de riesgo residual aceptado con propietario y fecha de revisión, y un plan de sustitución planificado cuando el equipo llegue a fin de vida. El marco IEC 62443 aporta controles específicos para este tipo de entornos.
Cuando el incidente tiene impacto significativo en la prestación del servicio asistencial. La alerta temprana se envía en 24 horas al INCIBE-CERT (sector privado) o al CCN-CERT (sector público), la notificación formal en 72 horas y el informe final en un mes. Los plazos corren desde que la entidad tiene conocimiento del incidente, no desde que está completamente analizado. En el sector sanitario el umbral de «significativo» suele alcanzarse antes que en otros sectores porque el impacto puede afectar directamente la atención al paciente. Si el incidente implica además una brecha de datos de salud, también aplican simultáneamente los plazos del RGPD ante la AEPD.
Los tres marcos comparten territorio en los hospitales. El enfoque más eficiente integra los análisis de riesgo (EIPD bajo RGPD y análisis de riesgos NIS2) en un proceso único con coordinación entre el DPO y el responsable de seguridad TI. Los contratos con proveedores deben cubrir simultáneamente las obligaciones de encargado del tratamiento (RGPD), proveedor crítico (NIS2) y las futuras obligaciones de interoperabilidad del EHDS, Reglamento (UE) 2025/327, cuyas obligaciones generales aplicarán desde marzo de 2027. Un incidente que afecte sistemas clínicos puede activar las tres obligaciones de notificación simultáneamente: la respuesta debe estar coordinada desde el primer minuto.
ISO/IEC 27001 cubre aproximadamente el 65-70 % del camino hacia NIS2: gestión de riesgos, controles documentados y gestión de incidentes. Los huecos típicos son la notificación 24h/72h, la gestión formal de cadena de suministro y la formación específica del consejo. En el entorno sanitario conviene complementarlo con ISO/IEC 27701 para la dimensión de privacidad y el EHDS, con el ENS si el hospital tiene relación con administraciones públicas, y con IEC 62443 para dispositivos IoMT y entornos de automatización clínica.
Las entidades esenciales pueden enfrentar multas de hasta 10 millones de euros o el 2 % del volumen de negocio global anual. Las entidades importantes hasta 7 millones de euros o el 1,4 %. El anteproyecto de ley español prevé además responsabilidad personal de directivos con multas de hasta 500.000 euros e inhabilitación temporal para el ejercicio del cargo. Para hospitales, el riesgo más inmediato no es la multa sino la exposición operativa: los centros que no han gestionado activamente sus riesgos de ciberseguridad son más vulnerables a ataques cuyo impacto puede ser directamente grave para los pacientes.