ENISA pone 6 millones sobre la mesa para blindar hospitales: lo relevante no es el dinero, sino cómo se va a comprar

La Comisión Europea y ENISA ya han pasado de la foto al contrato. El 22 de julio de 2026, la agencia anunció la firma de un Contribution Agreement de 6 millones de euros, con una duración de tres años, para desplegar parte del Plan de Acción de la UE sobre ciberseguridad de hospitales y proveedores sanitarios. El mismo día publicó una versión actualizada de sus guías de contratación para la ciberseguridad en hospitales. Y aquí está el dato que de verdad importa: Bruselas ha decidido que una parte del problema no se arregla solo con SOCs, parches o discursos sobre resiliencia, sino metiendo requisitos de seguridad en el momento en que el sector sanitario compra software, servicios cloud, dispositivos y mantenimiento.

No es un matiz menor. Es un cambio de punto de entrada. Durante años, demasiadas organizaciones sanitarias han intentado “asegurar” después lo que compraron mal al principio. Luego llegan el ransomware, la dependencia de un proveedor opaco, los equipos médicos imposibles de parchear y las licitaciones redactadas como si 2026 siguiera siendo 2012. ENISA, esta vez, no está vendiendo una verdad revolucionaria, pero sí está tocando una palanca que el sector lleva demasiado tiempo evitando: la contratación.

La noticia encaja de lleno en NIS2, aunque no sea una medida legislativa nueva. Los hospitales y otros prestadores sanitarios esenciales o importantes están lidiando ya con obligaciones de gestión de riesgos del artículo 21 de la Directiva (UE) 2022/2555 y con el deber de notificación de incidentes del artículo 23. Si compras tecnología sin requisitos mínimos verificables, buena suerte cumpliendo después con gobernanza, cadena de suministro, continuidad, respuesta y seguridad de adquisición, desarrollo y mantenimiento. NIS2 no dice literalmente “redacte usted mejores pliegos”, pero sí obliga a implantar medidas que, en la práctica, empiezan mucho antes de la fase operativa.

La jugada de ENISA tiene otra lectura más política. La UE puede discutir durante meses sobre autonomía estratégica, resiliencia sectorial o “ecosistemas de confianza”, pero al final la seguridad se juega en anexos técnicos, cláusulas contractuales y matrices de evaluación. Es menos épico que un gran reglamento. También es bastante más útil.

Qué ha anunciado exactamente ENISA, sin adornos

Los hechos verificables son estos. ENISA comunicó el 22 de julio de 2026 que ha firmado con la Comisión Europea un acuerdo de contribución por 6 millones de euros y tres años de duración para apoyar la ejecución del EU Action Plan for the cybersecurity of hospitals and healthcare providers, lanzado por la Comisión en 2025. Según la propia agencia, uno de los primeros entregables bajo ese plan es la actualización de las guías de contratación para la ciberseguridad de hospitales y proveedores sanitarios.

El acuerdo financiará, entre otras cosas, la construcción del catálogo de servicios de un futuro mecanismo europeo de apoyo al sector sanitario, descrito por ENISA como un European Cybersecurity Support Centre propuesto. Ese catálogo agrupa acciones en cuatro bloques: preparación, detección, respuesta y gobernanza. Es decir, no solo asistencia reactiva, sino también capacidades previas y estructura de gestión.

Además, las nuevas guías de contratación se han preparado con apoyo del Grupo de Cooperación NIS, del EU Health ISAC y de la Comisión Europea. No es irrelevante. Cuando ENISA publica con ese respaldo, el documento no es ley, pero tampoco es una simple pieza de divulgación. Funciona como señal de convergencia operativa: esto es lo que Bruselas, los Estados miembros y el ecosistema sectorial consideran razonable pedir en una compra sanitaria si no quieres comprar un problema con factura y mantenimiento.

ENISA ha adelantado también que el Plan de Acción, las guías revisadas y la ciberseguridad de dispositivos médicos estarán en la agenda de la 11ª ENISA eHealth Security Conference, prevista en Nicosia el 7 de octubre de 2026. Apunta esa fecha. Si el despliegue del plan empieza a concretarse de verdad, parte de las señales vendrán de ahí: prioridades, servicios del catálogo y expectativas para los operadores sanitarios.

Por qué la contratación es el punto ciego del sector sanitario

Si uno revisa incidentes en sanidad de los últimos años, aparece un patrón bastante poco glamuroso: no fallan solo los firewalls. Falla la adquisición. Se compran sistemas sin segmentación viable, soluciones remotas con autenticación débil, equipamiento médico con ciclos de soporte absurdos, servicios gestionados sin obligaciones claras de notificación, software que no entrega registros útiles, y contratos donde el proveedor promete “mejores esfuerzos” justo hasta el momento en que ocurre algo serio.

Eso choca de frente con NIS2. El artículo 21.2 obliga a las entidades esenciales e importantes a adoptar medidas de gestión de riesgos que incluyen, entre otras, políticas de análisis de riesgos y seguridad de sistemas; gestión de incidentes; continuidad de negocio y gestión de crisis; seguridad de la cadena de suministro; seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades; políticas y procedimientos para evaluar la eficacia de las medidas de ciberseguridad; prácticas básicas de ciberhigiene y formación; criptografía cuando proceda; recursos humanos y control de acceso; y uso de autenticación multifactor o continua, comunicaciones seguras y sistemas seguros de voz, vídeo y texto cuando proceda.

Fíjate en dos expresiones del artículo 21.2 que suelen pasar por debajo del radar hasta que llega la auditoría o el incidente: “seguridad de la cadena de suministro” y “seguridad en la adquisición, desarrollo y mantenimiento”. Eso es procurement puro y duro. No basta con tener un CISO brillante si compras como si el proveedor fuese, por definición, fiable, transparente y técnicamente impecable. La experiencia dice otra cosa.

En sanidad el problema se agrava por cuatro factores estructurales. Primero, la combinación de sistemas IT clásicos y tecnología operativa o cuasi-OT, incluidos dispositivos médicos, laboratorios, imagen médica y soluciones clínicas con soporte de terceros. Segundo, el peso de la contratación pública, donde cambiar pliegos, criterios de adjudicación y evidencias exigidas cuesta más que redactar una política interna. Tercero, la fragmentación del mercado: hospitales grandes, redes regionales, clínicas privadas, residencias, proveedores especializados, fabricantes, integradores, MSSP y nubes públicas o sectoriales. Cuarto, la consecuencia del fallo. En otros sectores una caída de servicio molesta. En sanidad puede retrasar cirugías, comprometer diagnósticos o desviar ambulancias. El regulador ya no compra la tesis de que esto va solo de confidencialidad de datos. Va también de disponibilidad y seguridad del paciente.

Por eso las guías de ENISA llegan en un momento oportuno. No porque traigan obligaciones nuevas, sino porque aterrizan un problema incómodo: si el hospital no sabe qué pedir, cómo evaluarlo y cómo convertirlo en obligación contractual, el cumplimiento de NIS2 se convierte en teatro documental. Mucho papel. Poca palanca real.

Lo que estas guías intentan corregir

La nota de ENISA describe varios elementos del documento: cubre todas las fases del ciclo de vida de la contratación, establece requisitos de ciberseguridad para proveedores, identifica tipos de servicios y productos donde las consideraciones de ciberseguridad son especialmente importantes, e incluye una checklist práctica de medidas enlazadas con amenazas específicas según el tipo de compra.

Eso último merece atención. El enfoque “amenaza vinculada al tipo de adquisición” es bastante más útil que las colecciones genéricas de controles que luego nadie sabe aplicar. No es lo mismo comprar un EHR, un PACS, un servicio de gestión remota, un dispositivo médico conectado, una pasarela de interoperabilidad, un servicio cloud de analítica clínica o un contrato de mantenimiento de equipamiento biomédico. El riesgo cambia. Las exigencias contractuales también deberían hacerlo.

En un proceso de compra maduro, la ciberseguridad no entra solo como anexo estándar. Debería aparecer, al menos, en seis momentos muy concretos del expediente:

Antes de licitar, en la definición de la necesidad: qué activos toca la solución, qué criticidad clínica tiene, qué dependencias genera y qué escenarios de indisponibilidad son tolerables. Si esa clasificación falla al inicio, todo lo demás se deforma.

En el pliego técnico: requisitos medibles sobre autenticación, gestión de vulnerabilidades, cifrado, registros, segmentación, soporte, hardening, copias, recuperación, interfaces, SBOM cuando proceda, acceso remoto y responsabilidades compartidas. “Cumplirá estándares de mercado” no sirve para casi nada.

En los criterios de adjudicación: no basta pedir, hay que puntuar. Si el precio concentra casi toda la valoración y la seguridad cuenta con una coletilla decorativa, el mensaje al mercado es cristalino. Ganará el más barato con mejor departamento comercial.

En la due diligence del proveedor: historial de incidentes, subcontratación, dependencias críticas, certificaciones relevantes, capacidad de respuesta y claridad sobre ciclo de vida del producto. No es lo mismo un proveedor con procesos robustos que uno que subcontrata medio servicio y no lo documenta hasta que algo estalla.

En el contrato y el SLA: tiempos de notificación, derecho de auditoría, obligaciones de parcheado, divulgación de vulnerabilidades, cooperación forense, retención y acceso a logs, reversibilidad, salida ordenada, localización de datos si aplica y gestión de subencargados o subprocesadores. Aquí suele morir la ambición del pliego.

Después de la adjudicación, en el seguimiento: verificación de evidencias, revisión periódica, pruebas, KPI/KRI y gatillos de escalado. El contrato no se “cumple” solo porque se firme. Ojalá.

Si la guía de ENISA consigue que incluso una parte de los hospitales mueva estas seis piezas, su impacto práctico será mucho mayor que el de muchas publicaciones regulatorias más vistosas y bastante menos accionables.

La conexión real con NIS2: no es un documento voluntario inocuo

Conviene decirlo claramente. Las guías de ENISA no son directamente vinculantes como una directiva transpuesta o un reglamento. Pero tratarlas como lectura opcional de verano sería un error de principiante.

NIS2 obliga a los Estados miembros a garantizar que las entidades esenciales e importantes adopten medidas apropiadas y proporcionadas para gestionar riesgos. El artículo 21 no impone una lista de tecnologías; impone resultados de gestión y control. En esa lógica, las autoridades nacionales van a mirar cada vez más cómo las organizaciones materializan la seguridad de cadena de suministro y la seguridad en la adquisición. Si ENISA publica una guía detallada, elaborada con apoyo del Grupo de Cooperación NIS y la Comisión, es razonable pensar que su contenido funcionará como referencia interpretativa de “buenas prácticas esperables”. No sustituye a la ley, pero ayuda a concretar qué significa cumplirla sin hacer malabares semánticos.

Hay otra derivada: la gobernanza de dirección. NIS2 endurece la responsabilidad de los órganos de dirección en el artículo 20, que les obliga a aprobar y supervisar las medidas de gestión de riesgos y a seguir formación. En la práctica, esto eleva la contratación de tecnología crítica del departamento de compras al nivel de asunto de dirección. Si una entidad sanitaria compra un sistema clave sin exigir requisitos básicos y eso contribuye a un incidente serio, cada vez será más difícil defender que se trató de una mera cuestión operativa sin relevancia de gobierno.

Y luego está el artículo 23 sobre notificación de incidentes. El famoso reloj no espera a que el proveedor responda con calma. NIS2 exige, entre otros hitos, una alerta temprana sin dilación indebida y en todo caso en 24 horas desde que la entidad tenga conocimiento del incidente significativo; una notificación del incidente en 72 horas; y un informe final en el plazo de un mes. Si el contrato con el proveedor no obliga a reportar, preservar evidencias, facilitar logs o cooperar técnicamente en tiempos compatibles con esos plazos, la entidad queda en posición de debilidad. Dicho de otra forma: si compras mal, notificas peor.

La sanidad no solo tiene NIS2 encima: también GDPR, dispositivos médicos y un puñado de dependencias incómodas

Reducir todo esto a NIS2 sería cómodo, pero incompleto. El sector sanitario vive en una intersección regulatoria bastante congestionada.

El GDPR sigue siendo central porque la mayoría de los incidentes en sanidad combinan disponibilidad y datos personales de categorías especiales. Si un ataque compromete datos de salud, el artículo 33 exige notificar a la autoridad de control en 72 horas, salvo que sea improbable que exista riesgo para los derechos y libertades de las personas físicas. El artículo 34 obliga, en ciertos casos, a comunicar a los afectados sin dilación indebida. La sincronización entre NIS2 y GDPR no siempre es elegante: distintos umbrales, distintos canales, distintas lógicas. Si además el proveedor procesa datos y no tiene definidos los flujos de reporte, el caos viene de serie. Por eso procurement vuelve a aparecer. Los contratos de encargo del tratamiento bajo el artículo 28 GDPR no pueden vivir en un universo paralelo al contrato técnico y de seguridad.

Luego están los dispositivos médicos. ENISA menciona expresamente que la ciberseguridad de dispositivos médicos estará en la agenda de octubre. Tiene sentido. Muchos hospitales arrastran equipamiento con sistemas heredados, ventanas de mantenimiento estrechas y ecosistemas de proveedor cerrados. El Reglamento (UE) 2017/745 sobre productos sanitarios elevó exigencias generales de seguridad y funcionamiento, y el debate europeo sobre ciberseguridad en productos conectados ha ganado músculo con el Cyber Resilience Act. Aunque su aplicación plena se despliega por fases, el mensaje para fabricantes y compradores es nítido: la ciberseguridad ya no es un “extra” voluntario del producto conectado. Si compras un dispositivo o software sanitario que no puede gestionarse razonablemente frente a vulnerabilidades, el problema no es solo técnico. Empieza a ser regulatorio y, en ciertos contextos, comercialmente tóxico.

La tercera capa es la dependencia de terceros. Hospitales y proveedores sanitarios externalizan cada vez más: alojamiento, conectividad, monitorización, mantenimiento, soporte de fabricantes, telemedicina, interoperabilidad, analítica, identidad, copias, correo, PACS, RIS, ERP, incluso operación parcial de infraestructuras. NIS2 empuja a gestionar cadena de suministro; las guías de ENISA intentan convertir eso en preguntas concretas al mercado. Qué subcontratas usa el proveedor, qué soporte garantiza, cómo aísla entornos, qué ventanas de parcheado ofrece, cómo maneja credenciales privilegiadas, qué ocurre si deja de dar servicio, cuánto tarda en notificar un incidente, qué logs entrega, cómo prueba la restauración. Esto no es obsesión burocrática. Es supervivencia operativa con esteroides jurídicos.

Qué deberían hacer ahora los hospitales y proveedores sanitarios

La tentación natural tras un anuncio así es descargar la guía, archivar el PDF y prometer una revisión “cuando haya tiempo”. Mala idea. Para muchas organizaciones sanitarias, 2026 ya no permite el lujo de separar cumplimiento, compras y operación como si fueran departamentos que se hablan por correo una vez al trimestre.

El primer movimiento sensato es mapear la contratación crítica contra las exigencias de NIS2 artículo 21. No hablo de revisar toda compra menor, sino de identificar qué adquisiciones y renovaciones afectan a funciones clínicas, disponibilidad de sistemas, acceso privilegiado, datos de salud, conectividad externa, soporte remoto o integración con terceros. Si tu entidad renueva este año mantenimiento biomédico, EHR, backup, red, IAM, PACS, telemedicina, servicio cloud o monitorización, ahí está el frente.

El segundo paso es confrontar los pliegos y contratos actuales con preguntas incómodas. Exigen MFA para accesos remotos de proveedor. Fijan plazos de notificación alineados con NIS2 y, si hay datos personales, compatibles con GDPR. Permiten auditoría o al menos revisión de evidencias. Definen soporte y ciclo de parcheado. Obligan a documentar subcontratación. Aseguran entrega de logs útiles. Prevén salida ordenada y portabilidad. Si la respuesta es “más o menos” o “depende del proveedor”, lo que tienes es deuda contractual.

El tercer paso consiste en unir equipos que suelen trabajar demasiado separados. Compras, jurídico, CISO, responsables de protección de datos, biomédica, IT clínica y negocio asistencial. No hace falta montar un comité con nombre grandilocuente; hace falta que alguien decida quién valida requisitos, quién aprueba excepciones y quién firma riesgos residuales. En sanidad, las excepciones llegan siempre con un argumento irresistible: urgencia asistencial, compatibilidad clínica, continuidad del paciente. Algunas son legítimas. Otras se convierten en un agujero de control con bata blanca.

El cuarto paso es aplicar proporcionalidad sin caer en el autoengaño. No todos los proveedores merecen el mismo nivel de escrutinio, pero la criticidad debe definirse por impacto real, no por comodidad. Un proveedor pequeño con acceso remoto persistente a sistemas de laboratorio puede ser más delicado que un gran suministrador sin acceso sensible. Aquí la clasificación de riesgos por tipo de compra, que ENISA enfatiza, puede servir como vacuna contra la pereza organizativa.

El quinto paso es preparar evidencia. Porque esto acabará en supervisión, auditoría, incidente o las tres cosas. Guardar matrices de evaluación, decisiones de adjudicación, excepciones aprobadas, anexos de seguridad, pruebas de cumplimiento y revisiones periódicas no es burocracia ornamental. Es lo que permitirá demostrar que la entidad sí intentó gestionar el riesgo de forma estructurada.

Qué cambia para los proveedores: vender a sanidad europea será menos informal

Si trabajas del lado proveedor, el mensaje tampoco admite mucha poesía. La compra pública y privada en sanidad europea se va a endurecer, y no solo por precio o interoperabilidad. Las preguntas de ciberseguridad van a ser más específicas, más frecuentes y menos negociables.

Eso implica varias cosas. Una, los proveedores tendrán que responder mejor sobre su propia cadena de suministro. Dos, las afirmaciones de marketing sobre seguridad valdrán poco sin evidencia operativa: certificaciones, procesos de vulnerabilidades, tiempos de parcheado, arquitectura de acceso remoto, logging, resiliencia, pruebas y política de subcontratación. Tres, quien venda servicios gestionados o soporte remoto deberá acostumbrarse a plazos de notificación contractuales mucho más agresivos. Cuatro, los fabricantes de tecnologías sanitarias conectadas tendrán más presión para justificar soporte prolongado, diseño seguro y coordinación de vulnerabilidades.

También cambia la conversación comercial. Hasta ahora, en demasiadas licitaciones, seguridad era una casilla de cumplimiento que se “resolvía” con un cuestionario estándar y un PDF corporativo. Eso se está acabando. Cuando los compradores empiecen a usar guías como la de ENISA para exigir controles vinculados a amenazas concretas, la respuesta genérica dejará de servir. Y el proveedor que no tenga gobierno interno para responder rápido, con precisión y con trazabilidad, empezará a perder oportunidades por razones perfectamente previsibles.

La ironía es evidente: durante años parte del mercado ha pedido a los compradores que “confíen” en la madurez del proveedor. Ahora toca demostrarla cláusula a cláusula.

El ángulo español: por qué esto no es una noticia lejana de Bruselas

Para España, la relevancia es directa aunque el anuncio no mencione un país concreto. El sector sanitario español combina grandes servicios regionales de salud, contratación pública compleja, fuerte dependencia tecnológica, presión presupuestaria y una exposición creciente a ransomware y disrupción operativa. Además, la transposición y aplicación práctica de NIS2 está forzando a muchas entidades a convertir principios abstractos en controles exigibles. Las compras son uno de los pocos lugares donde se puede intervenir antes de que el riesgo se materialice.

La utilidad de la guía de ENISA para hospitales españoles puede ser doble. Primero, como referencia técnica para redactar o revisar pliegos con un lenguaje más afinado. Segundo, como defensa institucional frente a inercias internas. Cuando un área clínica o de compras presione para simplificar requisitos “porque el mercado no lo acepta”, contar con una guía europea sectorial respaldada por el Grupo de Cooperación NIS da una base bastante más sólida que una preferencia del CISO.

Hay además un punto poco cómodo, pero real. En contratación pública, pedir mal sale caro y corregirlo tarda. Por eso la fase de preparación del expediente es estratégica. Si un servicio de salud o un hospital licita en 2026 sin incorporar exigencias mínimas sobre acceso remoto, respuesta a incidentes, ciclo de soporte o auditoría de proveedor, puede quedar atado durante años a un contrato difícil de enderezar. Luego vendrá la supervisión, y nadie querrá explicar que la cadena de suministro falló porque el pliego parecía redactado antes de que existieran los atacantes.

Lo que aún falta por ver

El anuncio de ENISA es un primer paso, no una solución cerrada. Quedan varias incógnitas relevantes.

La primera es el nivel de granularidad útil del catálogo de servicios del futuro mecanismo de apoyo. Si baja poco al terreno, servirá como marco conceptual más. Si ofrece herramientas prácticas reutilizables, modelos de requisitos, criterios de priorización y apoyo táctico, puede marcar diferencia.

La segunda es la adopción nacional. El Grupo de Cooperación NIS puede facilitar convergencia, pero la realidad de implementación dependerá de autoridades nacionales, sistemas sanitarios y práctica de contratación. No todos los Estados miembros moverán igual de rápido ni con la misma ambición.

La tercera es la interacción con otras piezas regulatorias y técnicas, en particular dispositivos médicos y requisitos de productos conectados. Muchos de los dolores reales del sector no están en el software administrativo, sino en la frontera entre clínica, ingeniería biomédica y proveedor.

La cuarta es la medición de impacto. Hoy sabemos el presupuesto, la duración del acuerdo y el primer entregable. Aún no sabemos qué métricas usará la UE para decidir si el plan mejora la resiliencia de verdad. Número de guías publicadas no basta. Harían falta indicadores sobre adopción de requisitos, tiempos de detección, respuesta, restauración, nivel de preparación y capacidad de coordinación sectorial.

La quinta, y no menor, es la tensión presupuestaria. Exigir más seguridad en la compra suele elevar el coste inicial o, al menos, desplaza el debate desde precio unitario a coste total de riesgo. En un sector sometido a presión financiera, esa conversación será áspera. Pero ya es tarde para fingir que lo barato sale barato. En sanidad, a menudo solo sale barato hasta el primer incidente serio.

El verdadero mensaje del regulador: la resiliencia empieza antes del incidente

ENISA no ha anunciado un reglamento nuevo ni una varita mágica. Ha hecho algo menos espectacular y bastante más serio: meter la ciberseguridad en la ingeniería de compra del sector sanitario y respaldarlo con financiación, aunque moderada, y con la promesa de un mecanismo europeo de apoyo. En 2026, eso importa más de lo que parece.

La lección de fondo es simple. Si un hospital quiere cumplir NIS2 artículo 21, responder a incidentes bajo el artículo 23, cuadrar GDPR artículos 33 y 34 cuando toque y sobrevivir a una dependencia creciente de terceros, no puede seguir tratando procurement como una formalidad administrativa que se arregla con un anexo genérico de seguridad. La resiliencia no empieza en el SOC. Empieza cuando decides qué compras, a quién, con qué evidencias y bajo qué condiciones.

Quien entienda esto a tiempo tendrá una ventaja operativa y regulatoria muy real. Quien no, seguirá descubriendo la misma verdad por la vía cara: durante un incidente, con el proveedor al otro lado, el reloj regulatorio corriendo y media organización preguntando por qué nadie pidió eso en el contrato.

La buena noticia es que ya hay una guía. La mala es la de siempre: ahora toca usarla.