Compliance
sanidad
hospitales
NIS2

Ciberseguridad en sanidad: NIS2, RGPD y protección de datos hospitalarios

Ciberseguridad sanidad bajo NIS2: hospitales como entidades esenciales, riesgos específicos, RGPD reforzado, IoT médico y plan de cumplimiento.

Secra8 de junio de 202614 min de lectura

El sector sanitario es entidad esencial bajo la Directiva NIS2 y, por tanto, sometido al régimen más exigente de la norma. Hospitales públicos y privados, clínicas concertadas, laboratorios de diagnóstico y servicios autonómicos de salud manejan datos especialmente protegidos por el artículo 9 del RGPD, dependen de redes complejas de dispositivos médicos conectados (IoMT) que rara vez aceptan parches en caliente y, en los últimos cinco años, han sido objetivo sistemático de campañas de ransomware con impacto directo en la atención al paciente. Esta combinación convierte a sanidad en uno de los sectores con mayor exposición y, paradójicamente, con menor margen de maniobra para detener un servicio que no puede pararse.

Lo esencial sobre ciberseguridad sanitaria bajo NIS2

  • El sector sanitario está incluido en el Anexo I de NIS2 como entidad esencial, con obligaciones reforzadas de gestión de riesgos y notificación de incidentes.
  • Los datos de salud son categoría especial del RGPD (artículo 9), con régimen sancionador agravado y exigencias de minimización y cifrado.
  • El ransomware contra hospitales paraliza atención clínica, no solo procesos administrativos, por lo que la continuidad asistencial es parte del programa de seguridad.
  • El IoMT (Internet of Medical Things), los PACS y los HIS son superficies de ataque heredadas con ciclos de parcheo dependientes del fabricante.
  • Un plan realista de cumplimiento sanitario se planifica a 12 meses: gap analysis, segmentación, MDR sanidad-aware, backup inmutable y runbooks específicos de incidente clínico.

Por qué sanidad es target prioritario

Pocos sectores combinan una dependencia operativa de la tecnología tan absoluta con una tolerancia al downtime tan baja. Un hospital de tamaño medio depende de sistemas informáticos para admisiones, historia clínica, prescripción electrónica, laboratorio, radiología, farmacia, gestión de quirófanos y comunicación entre servicios. Cuando esa capa cae, la consecuencia inmediata no es un retraso administrativo: es la imposibilidad de operar con normalidad, la suspensión de cirugías programadas, la derivación de urgencias y, en casos graves, el riesgo asistencial directo.

A esa dependencia operativa se suma el valor de los datos. Una historia clínica electrónica completa cotiza en mercados criminales por encima de un registro bancario, porque contiene identificadores estables, datos de seguros y trazabilidad personal difícil de invalidar. El atacante sabe que el dato sanitario no caduca como una tarjeta de crédito y que, además, su filtración genera un daño reputacional y legal especialmente elevado para la entidad atacada, lo que refuerza la presión para pagar el rescate.

El tercer factor es la composición tecnológica. Convivencia de servidores modernos, equipos de imagen con sistemas operativos sin soporte, dispositivos conectados de generaciones distintas y software clínico legado que el proveedor mantiene bajo contrato cerrado. Esto produce una superficie heterogénea donde aplicar parches no siempre es posible y donde la segmentación se vuelve el mecanismo principal de defensa.

NIS2 aplicado al sector sanidad España

NIS2 sitúa a la sanidad en el Anexo I como sector de alta criticidad. La transposición española clasifica a los hospitales públicos y privados que superan los umbrales generales (50+ empleados o más de 10 millones de euros de facturación) como entidades esenciales, junto con laboratorios de referencia, fabricantes de dispositivos médicos críticos y servicios autonómicos de salud. La distinción frente al sector privado puro es que la sanidad pública acumula además obligaciones derivadas del Esquema Nacional de Seguridad (ENS), lo que duplica la matriz de cumplimiento sin eximir de ninguna de las dos.

La coordinación de incidentes en sanidad no se resuelve con una única ventanilla. El CSIRT competente (INCIBE-CERT para sector privado, CCN-CERT para AAPP) recibe la notificación NIS2 en 24 y 72 horas. El Ministerio de Sanidad y las consejerías autonómicas reciben información paralela cuando el incidente afecta a la prestación asistencial. La AEPD entra cuando hay tratamiento indebido o brecha de datos de salud. El plan de respuesta tiene que contemplar esta triple comunicación desde el primer minuto, no improvisarla durante la crisis.

Para hospitales concertados, la realidad práctica es que el contratante público va a exigir contractualmente, vía pliego o adenda, el mismo nivel de medidas que aplica a la AAPP. Esto significa que aunque la entidad sea formalmente privada, su programa de seguridad debe diseñarse considerando NIS2 y ENS simultáneamente.

Marco normativo

La capa principal es la Directiva NIS2 (UE) 2022/2555 y su transposición española. El artículo 21 fija las diez áreas mínimas de medidas técnicas y organizativas que toda entidad esencial debe implantar, con responsabilidad personal del consejo de administración.

La segunda capa es el RGPD y la Ley Orgánica de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD). Los datos de salud son categoría especial conforme al artículo 9 del RGPD, con prohibición general de tratamiento salvo bases legitimadoras tasadas (consentimiento explícito, asistencia sanitaria, investigación con salvaguardas) y un régimen sancionador donde los importes máximos llegan al 4% del volumen de negocio anual mundial.

Para sanidad pública aplica además el Esquema Nacional de Seguridad en su versión vigente, que obliga a categorizar sistemas, declarar conformidad y someter los sistemas categoría ALTA a auditoría bienal. La interoperabilidad clínica añade exigencias técnicas de estándares como HL7 v2, HL7 FHIR e IHE, que aunque no son normas de seguridad en sentido estricto, definen cómo se intercambian datos sensibles entre sistemas y, por tanto, son parte del análisis de riesgos.

Cierran el cuadro los reglamentos europeos de dispositivos médicos (MDR 2017/745 e IVDR 2017/746), que ya incorporan requisitos específicos de ciberseguridad para fabricantes, y la regulación sectorial autonómica sobre historia clínica.

Riesgos específicos del sector

El mapa de amenazas sanitario no se solapa con el de banca o industria. Las categorías que aparecen de forma recurrente en auditorías e incidentes reportados son las siguientes.

Ransomware dirigido. Grupos como Conti y afiliados de LockBit han atacado hospitales europeos de forma reiterada en los últimos años. El patrón habitual combina acceso inicial por phishing o credenciales filtradas en infostealers, escalada lateral en redes planas, exfiltración previa de bases de datos clínicas y cifrado masivo coordinado con extorsión doble.

IoMT sin parchear. Bombas de infusión, monitores de paciente, ecógrafos, sistemas de anestesia, equipos de imagen y robots quirúrgicos llevan firmware específico del fabricante con ciclos de actualización dependientes de certificación regulatoria. Muchos siguen operando sobre sistemas operativos sin soporte porque cambiar el sistema base requiere recertificación clínica completa.

PACS y HIS expuestos. Los sistemas de archivo y comunicación de imagen médica (PACS) y los sistemas de información hospitalaria (HIS) son piezas críticas que en muchos hospitales han crecido por agregación, con accesos remotos para radiólogos externos, interfaces antiguas y permisos de servicio amplios. Su exposición indebida es un patrón documentado de hallazgos en auditorías.

Phishing dirigido a personal sanitario. La presión asistencial, los turnos rotatorios y la heterogeneidad de plataformas (correo corporativo, mensajería clínica, portales de proveedores) hacen al personal sanitario especialmente vulnerable a campañas dirigidas que simulan comunicaciones de la dirección, proveedores de equipamiento o autoridades sanitarias.

Insider risk. La historia clínica es accesible a un número alto de profesionales por necesidad asistencial, lo que dificulta detectar accesos indebidos. El control de acceso por mínima necesidad y la auditoría de accesos a historia clínica son controles imprescindibles pero a menudo infraimplantados.

Supply chain. La cadena incluye proveedores cloud de historia clínica, integradores de PACS, fabricantes de IoMT, soporte remoto externo y servicios de telemedicina. La incidencia en cualquiera de estos eslabones se propaga al hospital.

Dispositivos médicos legacy sin update path. Equipos en producción durante quince o veinte años que el fabricante ya no parchea pero que siguen siendo críticos para diagnóstico. La única defensa razonable suele ser aislamiento de red y monitorización pasiva.

Casos reales documentados

El sector cuenta con varios incidentes públicos que han marcado las prioridades del programa de seguridad sanitario en los últimos años.

El ataque contra el Health Service Executive (HSE) de Irlanda en 2021 dejó al sistema sanitario nacional sin sistemas informáticos durante varios días, con vuelta forzada a procedimientos manuales en todos los hospitales del país. La recuperación completa se prolongó durante meses y obligó a revisar a fondo los planes de continuidad asistencial en el resto de Europa.

En 2023, el Hospital Clínic de Barcelona sufrió un incidente de ransomware que afectó a sistemas críticos y derivó en cancelación de cirugías no urgentes, suspensión de consultas programadas y desviación de pacientes a otros centros. La gestión pública del caso ofreció lecciones sobre comunicación a la ciudadanía y coordinación entre el centro, el sistema autonómico de salud y los CSIRT competentes.

Durante 2024 se han reportado nuevos incidentes en centros sanitarios catalanes y otras comunidades autónomas, con afectación variable pero con un patrón común: vector inicial por credenciales o phishing, propagación lateral y impacto operativo directo sobre la atención.

Estos casos no se citan para glamorizar a los atacantes ni para ofrecer detalles técnicos accionables, sino para fijar que el riesgo es real, recurrente y que el sector dispone de evidencia pública suficiente para justificar inversión preventiva.

Plan de cumplimiento sanidad 12 meses

Un programa realista para llevar a un hospital de tamaño medio a un estado defendible frente a NIS2 y RGPD se planifica a doce meses.

Meses 1 a 2: aplicabilidad y gap analysis. Determinación formal de obligaciones (NIS2, ENS si aplica, RGPD reforzado), mapeo del artículo 21 contra controles existentes, identificación de servicios asistenciales críticos y priorización de brechas. Designación formal del responsable de seguridad y del comité de gobierno con representación clínica.

Meses 2 a 4: inventario IoMT y descubrimiento de superficie. Inventario completo de dispositivos médicos conectados, sistemas clínicos, integraciones con proveedores externos y accesos remotos. Sin inventario fiable, ningún control posterior es defendible.

Meses 3 a 6: segmentación IT, OT e IoMT. Diseño e implantación de microsegmentación por VLAN o equivalente, separando ofimática, sistemas clínicos (HIS, PACS), dispositivos IoMT, redes wifi de pacientes y servicios de proveedores externos. Esta es la palanca técnica de mayor impacto en sanidad.

Meses 4 a 8: detección y respuesta. Despliegue de EDR en endpoints clínicos y administrativos, integración con MDR si la entidad no dispone de SOC propio 24x7, definición de casos de uso específicos del sector (acceso anómalo a HCE, exfiltración desde PACS, comportamiento atípico en IoMT).

Meses 5 a 9: backup inmutable y continuidad. Estrategia 3-2-1-1-0 con copia inmutable y air gap, pruebas reales de restauración de sistemas clínicos críticos, RTO/RPO por servicio asistencial. Documentación de procedimientos de funcionamiento en modo degradado para cada servicio (papel, formularios manuales, comunicación interna alternativa).

Meses 8 a 12: IR runbooks, formación y simulacro. Runbooks específicos de incidente clínico (cifrado de HIS, indisponibilidad de PACS, compromiso de IoMT), simulacro de notificación NIS2 24h/72h con CSIRT competente, formación del consejo y campaña interna de awareness sanitario.

Controles técnicos prioritarios sanidad

La selección de controles para sanidad debe priorizar los que mantienen la operación clínica cuando todo lo demás falla.

  • Backup inmutable 3-2-1-1-0 con air gap. Tres copias, dos medios distintos, una externa, una inmutable u offline, cero errores en la última verificación. Restauración probada con datos reales, no solo en laboratorio.
  • EDR y threat hunting 24x7. EDR en endpoints clínicos y administrativos, con detección de comportamiento. Si la organización no tiene SOC propio, contratación de servicio MDR con experiencia sanitaria documentada.
  • Microsegmentación clínica. HIS, PACS, IoMT, ofimática y wifi de pacientes en VLAN independientes con políticas explícitas de tráfico permitido. Movimiento lateral contenido por diseño.
  • MFA en accesos administrativos y clínicos remotos. Doble factor obligatorio para administradores, radiólogos remotos, soporte de proveedores y cualquier acceso desde fuera de la red interna. Sin excepciones documentadas con caducidad.
  • Patch management de dispositivos médicos. Ventanas de actualización coordinadas con el calendario clínico, validación previa con el fabricante para no invalidar la certificación FDA o el marcado CE, registro auditable de cada cambio.
  • DLP outbound y monitorización de exfiltración. Detección de salidas masivas de datos clínicos, alertas sobre transferencias a destinos no autorizados, integración con el SIEM o el servicio MDR.
  • Awareness rotativo. Formación inicial obligatoria, campañas trimestrales adaptadas al rol (médicos, enfermería, administración, dirección) y simulacros de phishing con métrica de mejora.

Continuidad asistencial post-incidente

La diferencia entre un incidente bien gestionado y una crisis sanitaria está en la preparación para operar sin sistemas. Esta capa, propia del sector, no se cubre con controles técnicos genéricos.

Cada servicio asistencial debe disponer de procedimientos downtime documentados y conocidos por el personal: cómo prescribir en papel, cómo coordinar laboratorio sin sistema, cómo gestionar admisiones manualmente, cómo notificar a familias y pacientes. Estos procedimientos deben actualizarse cuando cambia la organización clínica, no archivarse para nunca consultarse.

La comunicación con pacientes y ciudadanía durante un incidente público es parte del plan. Mensajes preaprobados por dirección y servicio jurídico, canales habilitados, coordinación con la consejería de sanidad y con el gabinete de comunicación. Improvisar la comunicación durante una crisis amplifica el daño reputacional.

A nivel institucional, la coordinación con la consejería autonómica, el Ministerio de Sanidad, el CSIRT competente y la AEPD debe estar definida con datos de contacto operativos, no genéricos. La notificación NIS2 en 24 horas y la actualización en 72 horas requieren información estructurada que no puede recopilarse de cero el día del incidente.

Preguntas frecuentes

¿Un hospital pequeño o clínica pyme está obligado por NIS2?

Depende de los umbrales. NIS2 se aplica con carácter general a entidades con 50 o más empleados o más de 10 millones de euros de facturación dentro de los sectores incluidos en los anexos. Los hospitales de tamaño medio y grande, las clínicas con varias sedes y los grandes laboratorios privados encajan habitualmente como entidades esenciales. Una clínica pyme aislada puede quedar fuera del ámbito directo, pero suele acabar dentro por vía contractual cuando trabaja para una entidad obligada o para la AAPP.

¿Cómo se ausculta la ciberseguridad de los dispositivos IoMT?

Mediante descubrimiento pasivo de red, plataformas especializadas en visibilidad de dispositivos médicos, inventario contrastado con el servicio de electromedicina y revisión documental de firmware con el fabricante. El escaneo activo intrusivo está desaconsejado sobre dispositivos clínicos en producción porque puede provocar mal funcionamiento del equipo.

¿Se puede pagar el rescate en un incidente de ransomware sanitario?

La recomendación oficial de INCIBE-CERT, Europol y de la mayoría de autoridades es no pagar. El pago no garantiza recuperación, financia operaciones criminales y expone a sanciones si el receptor está bajo lista de sanciones internacionales. Cuando la presión asistencial llega al límite, la decisión escala a dirección y servicio jurídico, pero el plan de respuesta nunca debe construirse asumiendo que el pago es una opción válida.

¿Qué pasa con los datos exfiltrados antes del cifrado?

La exfiltración previa al cifrado convierte el incidente en una doble brecha: indisponibilidad de servicio y violación de seguridad de datos personales. Esto activa simultáneamente las obligaciones de notificación NIS2 al CSIRT y las del RGPD a la AEPD y, en su caso, a las personas afectadas, con plazos y contenidos distintos. La gestión coordinada de ambas comunicaciones es parte del runbook.

¿Mi proveedor cloud de salud está obligado por NIS2?

Los proveedores de servicios cloud que prestan a entidades esenciales suelen quedar a su vez dentro del ámbito como entidades importantes o esenciales según su tamaño y servicio. Con independencia de su obligación directa, el hospital tiene que exigir contractualmente medidas equivalentes a las suyas (cláusulas de seguridad, auditoría, notificación de incidentes, ubicación y tratamiento de datos) bajo el paraguas del artículo 21 letra d.

¿Cómo se comparan las multas RGPD y las de NIS2?

El RGPD prevé multas de hasta 20 millones de euros o el 4% del volumen de negocio anual mundial. NIS2 prevé multas de hasta 10 millones de euros o el 2% del volumen de negocio anual mundial para entidades esenciales, además de responsabilidad personal de la dirección. Ambos regímenes son acumulables cuando un mismo incidente vulnera obligaciones distintas, por lo que el cálculo de impacto debe considerar la suma.

Recursos relacionados

Ciberseguridad sanidad con Secra

En Secra acompañamos a hospitales, clínicas y servicios autonómicos de salud en programas de cumplimiento NIS2, RGPD y ENS con metodología específica para el sector. Auditoría sanidad-aware con alcance sobre IoMT, PACS y HIS, gap analysis frente al artículo 21 con criterios aplicables a entornos clínicos, diseño de segmentación y controles operativos compatibles con la actividad asistencial, threat hunting con casos de uso sanitarios y soporte en notificación coordinada a CSIRT, AEPD y autoridades autonómicas.

Si necesitas evaluar el estado de tu organización o planificar el roadmap de cumplimiento, contacta con nuestro equipo y revisamos contigo el alcance adecuado.

Sobre el autor

Equipo de Secra Solutions

Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.

Compartir artículo