ENISA pone orden en las compras sanitarias: la ciberseguridad ya no se negocia en el anexo del contrato

La ciberseguridad hospitalaria ha pasado años tratándose como un problema técnico. Antivirus, segmentación, copias de seguridad y a correr. ENISA acaba de recordarle al sector algo bastante menos cómodo: el fallo empieza muchas veces antes, cuando compras mal.

Su guía de julio de 2026 sobre procurement para la ciberseguridad de hospitales y proveedores sanitarios no inventa una nueva obligación legal. Hace algo más útil: traduce el caos regulatorio europeo en requisitos de compra, preguntas de due diligence, cláusulas contractuales y controles de gestión del proveedor durante todo el ciclo de vida. Ese detalle importa, porque NIS2 no sanciona intenciones; sanciona fallos de gobierno, de medidas técnicas y organizativas, y de seguridad en la cadena de suministro. Y la cadena de suministro empieza en la licitación, no cuando ya tienes el equipo de radiología conectado a la red clínica.

La guía llega con cifras que quitan las ganas de trivializar el asunto. La Comisión Europea estima que hay más de 500.000 tipos de productos sanitarios y dispositivos de diagnóstico in vitro en el mercado de la UE. El mercado europeo de tecnología médica alcanzó aproximadamente 160.000 millones de euros en 2023. Eso significa una superficie de ataque gigantesca, heterogénea y, en demasiados casos, comprada con contratos pensados para precio, funcionalidad y plazo de entrega, pero no para parcheo, registro de eventos, autenticación robusta o gestión de vulnerabilidades.

Aquí está el giro de fondo: ENISA coloca la contratación como control de ciberseguridad. No como trámite jurídico. Como control.

Tesis editorial

La guía de ENISA acierta en lo esencial: el mayor agujero de seguridad del sector sanitario europeo no es solo tecnológico, sino contractual. Los hospitales llevan años comprando sistemas conectados, servicios cloud, EHR, equipamiento biomédico y soluciones con IA como si la ciberresiliencia fuese una promesa comercial y no una obligación verificable. Esa etapa se ha terminado.

Mi tesis es simple. Si un hospital, una mutua o un proveedor sanitario sigue evaluando a sus terceros con cuestionarios genéricos y cláusulas de “cumplirá con la normativa aplicable”, está comprando riesgo regulatorio a plazos. Y ese riesgo ya no se queda dentro del sector salud. Toca a aseguradoras, bancos que financian equipamiento, plataformas de pago sanitarias, procesadores de datos, proveedores cloud y fabricantes que venden simultáneamente al sistema sanitario y al financiero. DORA va por un carril distinto, sí, pero comparte una idea central con NIS2: el tercero crítico deja de ser una caja negra.

ENISA no publica una guía revolucionaria en lo doctrinal. Publica algo más peligroso para la complacencia: una guía operativa. Eso obliga a pasar de “tenemos política de proveedores” a “enséñame la cláusula sobre tiempos máximos de remediación, SBOM, soporte de parches, logs exportables, notificación de incidentes y dependencia de subprocesadores”. Ahí empiezan las incomodidades de verdad.

Lo relevante no es que ENISA hable de procurement; lo relevante es cómo lo estructura

La guía divide el ciclo de contratación en tres fases: plan, source y manage. Puede parecer obvio. No lo es. La mayoría de fallos graves en compras tecnológicas sanitarias aparecen precisamente porque cada fase la domina un actor distinto: el área clínica pide funcionalidad, compras presiona precio, legal revisa responsabilidad, IT intenta encajar el sistema y seguridad llega tarde a poner pegas. Resultado: el proveedor entra, el contrato firma bonito y el entorno hereda un activo inseguro durante siete o diez años.

ENISA intenta corregir ese patrón con una lógica que merece ser tomada en serio.

Fase de planificación: donde se decide casi todo

La planificación no consiste solo en definir qué se compra. Consiste en clasificar el impacto del activo o servicio sobre la prestación asistencial, los datos personales y la dependencia operativa. Un sistema PACS de radiología, una historia clínica electrónica off the shelf, una plataforma cloud para centro médico privado o un dispositivo conectado no tienen el mismo perfil de riesgo ni el mismo encaje contractual.

Esto encaja de forma directa con NIS2 art. 21, que obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas. Entre esas medidas, el apartado 2 incluye expresamente la seguridad de la cadena de suministro, incluida la seguridad en las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. Traducido al castellano menos solemne: si compras tecnología clínica sin evaluar al proveedor con criterios de seguridad, no estás fallando en procurement; estás fallando en NIS2.

La fase de planificación debería resolver, como mínimo, cinco preguntas que rara vez se resuelven bien:

• Qué funciones clínicas o asistenciales se verían afectadas si el producto falla o queda comprometido.
• Qué datos trata, con qué sensibilidad y bajo qué base de acceso remoto o integración con terceros.
• Qué dependencias externas arrastra: nube, mantenimiento remoto, librerías de terceros, conectividad con fabricante, soporte desde fuera de la UE.
• Qué vida útil real tendrá el activo y durante cuánto tiempo habrá parches y soporte.
• Qué controles son no negociables antes de publicar la licitación o la petición de oferta.

Si estas cuestiones no están cerradas al inicio, la negociación posterior se convierte en una subasta de excepciones.

Fase de selección: el momento en que los cuestionarios dejan de servir

La guía presta mucha atención a la información que debe pedirse al proveedor. Ahí es donde el mercado suele tropezar. Se pide una ISO 27001, una declaración de buenas intenciones, quizá un SOC 2 si hay presupuesto, y se da el expediente por concluido. El problema es que ni ISO 27001 ni una política corporativa te dicen si el equipo médico permite autenticación multifactor para administración remota, si los logs son exportables a tu SIEM, si el fabricante publica avisos de seguridad con CVE, o si el parcheo exige ventana presencial trimestral porque el diseño del producto parece salido de otra década.

ENISA empuja hacia un modelo de selección más granular: requisitos de seguridad por tipo de compra y evidencias concretas del proveedor. Eso debería traducirse en pliegos y RFP con preguntas incómodas, de las buenas:

• Frecuencia de publicación de parches de seguridad y tiempo objetivo de remediación para vulnerabilidades críticas.
• Capacidad de autenticación fuerte y segregación de roles administrativos.
• Arquitectura de conectividad remota y posibilidad de desactivarla o restringirla.
• Disponibilidad de inventario de componentes o SBOM cuando proceda.
• Registro y retención de eventos de seguridad, formato de exportación y compatibilidad con herramientas del cliente.
• Proceso de divulgación coordinada de vulnerabilidades y canal de contacto para incidentes.
• Uso de subencargados o subcontratistas con acceso a datos o a sistemas clínicos.

Esto además conversa de forma muy clara con GDPR. El art. 28 exige que el responsable use solo encargados que ofrezcan garantías suficientes para aplicar medidas técnicas y organizativas apropiadas. El art. 32 habla de seguridad del tratamiento. Y el art. 33 fija la notificación de violaciones de seguridad a la autoridad de control, en general, en un plazo de 72 horas desde que el responsable tiene constancia. Si tu proveedor tarda cinco días en confirmarte un incidente, ya has comprado un problema temporal, no solo técnico.

La lección no es jurídica; es operativa. El SLA de soporte y la cláusula de notificación de incidentes deben diseñarse pensando en ese reloj de 72 horas. Sorprende la cantidad de contratos que no lo hacen.

Fase de gestión: donde el proveedor deja de ser promesa y pasa a ser evidencia

La tercera fase, manage, probablemente es la más subestimada. Una vez adjudicado el contrato, muchas organizaciones relajan controles y convierten la gobernanza del proveedor en reuniones esporádicas y revisiones de KPI centradas en disponibilidad. ENISA plantea algo más serio: monitorización continuada, revisión de cambios, gestión de incidencias, seguimiento de parches, reevaluación de riesgos y tratamiento de finalización o sustitución del servicio.

Esto enlaza con una realidad fea del sector sanitario: buena parte del riesgo no entra por una brecha espectacular, sino por deterioro silencioso. Un equipo que sigue funcionando pero ya no recibe soporte. Un servicio cloud que cambia subprocesador. Un proveedor que amplía acceso remoto. Un dispositivo que integra un componente vulnerable y cuyo fabricante tarda meses en actualizar. Nada muy cinematográfico. Todo muy sancionable si termina afectando a la continuidad asistencial o a datos de salud.

La guía de ENISA es sanitaria, pero el método sirve para DORA casi línea por línea

Aunque la publicación está orientada a hospitales y proveedores sanitarios, su arquitectura es extraordinariamente familiar para cualquier entidad financiera que lleve dos años peleándose con DORA. No porque las obligaciones sean idénticas, sino porque la lógica regulatoria converge: identificar funciones críticas, mapear dependencias ICT, evaluar riesgo del tercero antes de contratar, reforzar condiciones contractuales, supervisar durante la relación y preparar salida o sustitución.

DORA, en su capítulo V sobre gestión del riesgo de terceros prestadores de servicios de TIC, va justo por ahí. El art. 28 obliga a un marco sólido y exhaustivo para gestionar el riesgo de terceros de TIC como parte integrante del marco de gestión del riesgo de TIC de la entidad financiera. El art. 30 detalla elementos contractuales clave, desde descripciones claras de funciones y ubicaciones hasta disponibilidad, integridad, confidencialidad, acceso, recuperación, asistencia en incidentes y derechos de terminación.

La ironía es bastante europea: el sector salud llega ahora, con ENISA, a una conclusión operativa que el sector financiero ya conoce a golpe de DORA. La compra tecnológica ya no puede separarse del control de riesgo operacional. La diferencia es que en salud el impacto puede ser literalmente clínico.

Para grupos aseguradores con negocio de salud, mutuas, plataformas de pagos sanitarios o entidades financieras que financian o integran servicios de salud digital, esto abre una cuestión nada menor: no basta con tener una metodología DORA para terceros financieros si parte del ecosistema sanitario conectado queda fuera del mismo nivel de exigencia. Los incidentes no respetan organigramas.

Impacto regulatorio cruzado

La guía de ENISA no tiene fuerza vinculante por sí sola; el propio documento recuerda que representa las interpretaciones de ENISA y no crea una obligación regulatoria autónoma. Pero funciona como lo que en compliance de verdad importa: una referencia pública, especializada y difícil de ignorar cuando llegue el regulador, el auditor, el perito o el demandante.

Veamos el cruce regulatorio relevante.

NIS2: la compra insegura puede convertirse en incumplimiento sistémico

NIS2, Directiva (UE) 2022/2555, es el ancla principal. El art. 21 no se limita a pedir controles internos; incorpora gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, evaluación de eficacia de medidas y formación básica en ciberhigiene. Para entidades sanitarias esenciales e importantes, la contratación es una pieza natural de ese deber de diligencia. Si el proveedor no acredita seguridad suficiente, la entidad no puede refugiarse en que la tecnología “cumplía funcionalmente”.

Además, NIS2 impone notificaciones escalonadas de incidentes significativos: alerta temprana en 24 horas, notificación de incidente en 72 horas y, en principio, informe final en un mes. Ese calendario hace indispensable que los contratos obliguen al proveedor a escalar sospechas, indicadores de compromiso, indisponibilidades y afectaciones a servicios críticos con una velocidad mayor que la exigida al regulado. Si esperas a que el tercero confirme internamente, ya llegas tarde.

GDPR: los datos de salud no perdonan contratos vagos

En sanidad, hablamos además de categorías especiales de datos bajo GDPR art. 9. Eso vuelve especialmente delicado cualquier acceso remoto, mantenimiento, alojamiento cloud, soporte por terceros o analítica avanzada. La selección del proveedor encaja con GDPR art. 28; la seguridad de diseño y por defecto, con arts. 25 y 32; y la notificación de brechas, con arts. 33 y 34.

La guía de ENISA es valiosa aquí porque aterriza el eterno problema del art. 28: cómo saber si el encargado ofrece “garantías suficientes”. La respuesta ya no puede ser una casilla genérica de cumplimiento. Tiene que ser evidencia sobre arquitectura, procesos de parcheo, control de accesos, cifrado, trazabilidad, segregación y gestión de subencargados.

AI Act: si compras IA clínica o IA asistida, compra también gobernanza

ENISA dedica un apartado específico a productos habilitados por IA y servicios asistidos por IA. Muy oportuno. En 2026, la fiebre por incorporar IA en clasificación clínica, priorización, asistentes de documentación, imagen médica o soporte a operaciones administrativas sigue corriendo más rápido que la gobernanza. Mala combinación.

Si el sistema entra en las categorías de alto riesgo del AI Act, la conversación ya no va solo de ciberseguridad tradicional. Va de calidad de datos, supervisión humana, trazabilidad, gestión del riesgo, exactitud, robustez y ciberseguridad del sistema. Las compras sanitarias deberían exigir al proveedor documentación técnica, límites de uso, métricas de rendimiento relevantes, gestión de sesgos donde aplique, mecanismos de supervisión humana y control de cambios del modelo.

Y ahora la parte que interesa a banca y seguros. Muchos grupos financieros están adoptando IA para suscripción, fraude, atención al cliente, triaje documental y automatización de siniestros. El riesgo de repetir el error sanitario es alto: contratar plataformas de IA con cláusulas bonitas y controles vagos. Las preguntas que ENISA empuja en salud son exportables casi sin tocar a seguros y banca: qué datos usa el modelo, quién puede reutilizarlos, dónde se entrena, qué subproveedores intervienen, cómo se registran prompts y salidas sensibles, qué pasa si el modelo deriva decisiones erróneas, y cómo se desactiva una funcionalidad sin tumbar toda la operación.

Los controles mínimos recomendables para IA en banca y seguros deberían incluir, como poco, evaluación de riesgo previa por caso de uso, inventario de modelos y terceros, prohibición contractual de reutilización no autorizada de datos confidenciales, registro y monitorización de interacciones de alto impacto, validación independiente, revisión de sesgos y mecanismos de reversión manual. Nada glamuroso. Todo necesario.

Cyber Resilience Act y reglamentación de producto: el fabricante ya no debería escurrirse tan fácil

La lógica de la guía también se apoya en la evolución del marco europeo de ciberseguridad de producto. Cuando compras dispositivos o software con elementos digitales, el mercado se mueve hacia mayores obligaciones del fabricante en diseño seguro, gestión de vulnerabilidades y actualizaciones. Eso no elimina la responsabilidad del comprador, pero mejora una cosa esencial: ya no resulta tan defendible vender productos conectados con prácticas de seguridad mediocres y esconderlo en letra pequeña.

Para hospitales, esto debería traducirse en una negociación más exigente sobre ciclo de soporte, publicación de vulnerabilidades y responsabilidades de actualización. Si el proveedor se resiste a concretar plazos de parcheo o a describir su proceso de gestión de vulnerabilidades, no está protegiendo secretos industriales; probablemente está protegiendo su libertad para tardar demasiado.

DORA: no aplica al hospital, pero sí a gran parte del ecosistema que le rodea

DORA no regula a los hospitales, salvo casos muy indirectos, pero sí a entidades financieras y a muchos prestadores TIC que comparten cartera de clientes entre salud y finanzas. Ese solapamiento tiene una consecuencia práctica: los proveedores maduros acabarán estandarizando cláusulas y evidencias para responder a ambos mundos. Los inmaduros intentarán vender “compliance packs” genéricos. Conviene distinguirlos rápido.

El comprador inteligente puede aprovechar este momento para elevar su listón contractual usando categorías ya asentadas en DORA: subcontratación en cascada, derechos de auditoría e inspección, cooperación en incidentes, localización de datos y tratamiento de concentración de riesgos. No porque la guía de ENISA lo exija palabra por palabra, sino porque el riesgo subyacente es el mismo.

Lo que un hospital debería convertir ya en cláusulas contractuales

La gran utilidad de la guía es que deja de hablar en abstracto. Si se toma en serio, debería rediseñar plantillas de pliegos, RFP, anexos técnicos y contratos marco. No basta con pedir “cumplimiento de NIS2 y GDPR”. Esa fórmula sirve para quedar bien en comité y poco más.

Estas son las áreas donde el lenguaje contractual debe volverse concreto.

Notificación y cooperación en incidentes

Si la entidad regulada tiene relojes de 24 y 72 horas bajo NIS2 y de 72 horas bajo GDPR art. 33, el proveedor debe notificar sin dilación indebida y, en la práctica, en horas, no en días. El contrato debería fijar:

• Plazo máximo de notificación inicial desde la detección o sospecha razonable.
• Canal 24/7, puntos de contacto nominativos y escalado ejecutivo.
• Contenido mínimo de la notificación: sistemas afectados, impacto funcional, afectación de datos, IoC, medidas de contención y previsión de recuperación.
• Obligación de cooperación en análisis forense, comunicaciones regulatorias y preservación de evidencias.

Si el proveedor solo se compromete a avisar “sin demora injustificada”, te está vendiendo ambigüedad con envoltorio jurídico.

Parcheo, vulnerabilidades y fin de soporte

Buena parte del equipamiento clínico convive con ciclos de vida largos y ventanas de mantenimiento complejas. Precisamente por eso el contrato debe forzar visibilidad:

• Clasificación de vulnerabilidades y tiempos objetivos de remediación.
• Proceso de comunicación de CVE relevantes al cliente.
• Calendario de soporte de seguridad y fecha de fin de vida.
• Medidas compensatorias cuando un parche no pueda aplicarse de inmediato por razones clínicas o regulatorias.

Si el proveedor no puede comprometer nada concreto, el comprador debería pedir precio acorde al riesgo o, mejor aún, buscar otro proveedor. Sí, ya sé que en ciertos nichos clínicos eso no siempre es viable. Justamente por eso hay que documentar el riesgo residual y elevarlo a dirección.

Acceso remoto y privilegios

El mantenimiento remoto de dispositivos y plataformas sanitarias es uno de esos secretos a voces que solo parecen escandalosos después del incidente. El contrato debería definir cuándo puede usarse, con qué autenticación, con qué registro, desde qué ubicaciones, con qué preaviso y con qué capacidad del cliente para revocar o limitar acceso. También debería prohibir cuentas compartidas y exigir trazabilidad individualizada.

A estas alturas de 2026, seguir aceptando accesos administrativos genéricos por comodidad operativa no es pragmatismo. Es nostalgia por una era en la que nadie auditaba nada.

Subprocesadores, transferencias y localización

En cloud sanitario, las dependencias en cascada son la norma. El cliente necesita saber qué terceros intervienen en alojamiento, soporte, monitorización, backup, análisis y asistencia remota. GDPR art. 28 ya exige autorización previa específica o general para subencargados. La guía de ENISA empuja en la misma dirección con una óptica de cadena de suministro. El contrato debe imponer transparencia, derecho de objeción donde proceda, notificación de cambios relevantes y garantías para transferencias internacionales si existen.

Salida, portabilidad y borrado

La resiliencia también consiste en poder salir. Si un servicio cloud clínico falla o el proveedor incumple, migrar datos y configuraciones sin dejar residuos inseguros es parte del control. DORA lo formula con nitidez para finanzas; salud debería copiar la disciplina. Hace falta cláusula de reversibilidad, formato de exportación, asistencia de transición, borrado certificado y tratamiento de copias de seguridad remanentes.

El verdadero problema: compras, seguridad y clínicos siguen hablando idiomas distintos

El valor de la guía se pierde si cada área la interpreta a su manera. El director de compras leerá “checklist”. El CISO leerá “controles”. El DPO leerá “encargados y brechas”. El responsable clínico querrá que el equipo funcione sin retrasos. Todos tienen parte de razón. Ninguno puede gobernar esto solo.

La respuesta sensata es gobernanza transversal previa a la compra. No un comité decorativo, sino una decisión documentada sobre riesgo aceptable, criterios de adjudicación y excepciones autorizadas. Si una solución clínica crítica no puede cumplir un control de seguridad, alguien con nivel suficiente debe firmar la aceptación del riesgo con conocimiento de impacto asistencial, regulatorio y económico. Nada de esconder la excepción en un anexo técnico que nadie relee.

Esto también tiene una derivada presupuestaria incómoda. Durante años, muchas compras sanitarias compararon ofertas sin internalizar costes de segmentación, hardening, integración con IAM, SIEM, EDR o gestión de vulnerabilidades. Así cualquiera sale barato. ENISA, sin decirlo de forma tan cruda, obliga a recalcular el TCO real de la seguridad. El proveedor aparentemente más económico puede salir carísimo si exige controles compensatorios permanentes o genera dependencia opaca.

Los tres casos de uso de ENISA dicen más de lo que parece

El documento incorpora tres escenarios: compra de equipamiento de radiología en un gran hospital, adquisición de servicios cloud por un centro médico privado y adquisición de un sistema de historia clínica electrónica estándar por un médico generalista. La selección no es casual.

Radiología representa el viejo problema del dispositivo caro, clínicamente crítico y tecnológicamente complejo, donde el fabricante ha disfrutado durante años de una posición dominante en mantenimiento, conectividad y actualizaciones. Cloud representa el salto a dependencias externas, elasticidad y subcontratación en cascada. EHR estándar representa la realidad de organizaciones pequeñas con menos músculo negociador y menos capacidad técnica interna.

Ese tercer caso merece atención especial. NIS2 eleva obligaciones también para entidades importantes que no son gigantes. El pequeño proveedor sanitario no puede replicar la vendor management office de un gran grupo hospitalario. Pero sí puede usar la lógica de ENISA para establecer mínimos no negociables, plantillas simplificadas y apoyarse en compras conjuntas o marcos sectoriales. El regulador puede admitir proporcionalidad. Lo que no admitirá eternamente es la ausencia de método.

Qué deberían hacer ahora CISOs, compliance y asesoría jurídica

No hace falta redescubrir la rueda. Hace falta dejar de firmar contratos como si la seguridad pudiera resolverse después. Un enfoque útil en 2026 pasa por revisar cuatro piezas muy concretas.

La primera es el inventario de tipologías de compra. ENISA incluye un anexo de tipos de procurement en salud y una checklist priorizable. Esa taxonomía sirve para dejar de tratar igual un software administrativo, un dispositivo médico conectado, un EHR o un servicio cloud. Cada categoría debe tener un paquete mínimo de requisitos, preguntas y aprobadores internos.

La segunda es el rediseño del vendor due diligence. Si tu cuestionario de terceros cabe en dos páginas y sirve igual para limpieza, software y mantenimiento de equipos clínicos, no tienes un proceso de seguridad; tienes una tradición administrativa. Hay que modular preguntas por criticidad, conectividad, acceso a datos y dependencia operacional.

La tercera es la cirugía contractual. Plantillas, anexos de seguridad, DPAs, condiciones de soporte y cláusulas de terminación deben alinearse con NIS2 art. 21, GDPR arts. 28, 32 y 33, y, cuando el grupo comparta prácticas con entidades financieras, con la disciplina de DORA arts. 28 a 30. La ventaja es obvia: menos fricción improvisada en negociación y más consistencia probatoria si llega inspección.

La cuarta es la evidencia de gestión continua. No basta con diligencia precontractual. Hace falta registro de excepciones, seguimiento de hallazgos, calendario de reevaluación y métricas que vayan más allá de disponibilidad. ¿Cuántos proveedores críticos tienen soporte activo? ¿Cuántos notifican vulnerabilidades con trazabilidad? ¿Cuántos mantienen acceso remoto permanente? ¿Cuántos han cambiado subprocesador este año? Si no puedes contestar, tampoco podrás defender tu gobierno del riesgo.

La parte incómoda para los proveedores

La guía de ENISA también es un aviso para fabricantes, integradores y prestadores cloud que trabajan con sanidad. El mercado europeo se está moviendo hacia una exigencia probatoria mayor. Ya no bastará con marketing de “seguridad por diseño” ni con una certificación colgada en la web. Los compradores más maduros van a pedir compromisos sobre procesos internos, tiempos, arquitectura y responsabilidad compartida.

Eso implica costes, sí. Pero también seleccionará mejor a los proveedores serios. El que tenga un proceso de gestión de vulnerabilidades coherente, soporte de seguridad claro, registro robusto, transparencia sobre subproveedores y capacidad de cooperación en incidentes debería poder demostrarlo. El que no, seguirá apelando a formulaciones vaporosas. Ya sabemos cuál de los dos perfiles acaba complicando la vida del cliente cuando algo sale mal.

Perspectiva: una guía no cambia el mercado sola, pero sí cambia la conversación con el regulador

Conviene no exagerar. La guía de ENISA no crea nuevas sanciones ni sustituye el texto de NIS2, GDPR o la normativa de producto sanitario. Tampoco resolverá por sí sola la asimetría entre grandes fabricantes y pequeños compradores. Pero sí cambia algo muy relevante: el estándar de diligencia esperable.

Cuando una agencia de la UE publica en julio de 2026 una guía detallada, con fases de procurement, medidas por etapa, atención a IA, escenarios prácticos y un anexo de checklists, la excusa de “no había criterios sectoriales claros” pierde fuerza. Mucha fuerza.

Y eso tiene una consecuencia jurídica y de supervisión nada menor. A partir de ahora, cuando un hospital sufra un incidente vinculado a un proveedor, la discusión no será solo si existía una política general de seguridad. Será si la entidad tradujo el riesgo en requisitos de compra, diligencia previa, cláusulas exigibles y seguimiento continuado. Si no lo hizo, no podrá decir que nadie le había dado una hoja bastante nítida.

La ciberseguridad sanitaria europea lleva tiempo hablando de resiliencia. ENISA acaba de meter la palabra donde más duele: en compras. Y, francamente, ya iba siendo hora.