Artículo

Ciberseguridad en la sanidad: protección de los datos de los pacientes, continuidad de la atención médica y resiliencia del sistema de salud

La digitalización de la medicina ha cambiado la propia naturaleza del ciberriesgo. Los historiales médicos electrónicos, los sistemas de información de laboratorio, la telemedicina, las recetas…

Autores:

Artem Honcharenko, PhD: presidente de la International Technology Transfer Association (ITTA), experto en transformación digital, inteligencia artificial, innovación tecnológica y transferencia internacional de tecnología, director del Instituto de Veteranos «Architecture of Resilience» de la KNUBA

Mykhailo Vasianovych, CEO de SmartGT, experto en transformación digital e IA, investigador científico sénior del Instituto Nacional de Desarrollo Regional, director de la organización benéfica «Fundación Benéfica NAMIR», coordinador de la incubadora de IA del CVU.

Andrii Stanko, PhD, profesor titular del Departamento de Tecnologías Integradas por Ordenador de la Universidad Técnica Nacional de Ternópil Iván Puluj. Docente del Centro de Tecnologías de la Información de la TNTU

Ciberseguridad en la sanidad: protección del paciente y de los datos médicos; una enfermera junto a un paciente en la habitación, un escudo con candado e iconos de historiales, nubes, bases de datos y equipos

La digitalización de la medicina ha cambiado la propia naturaleza del ciberriesgo. Los historiales médicos electrónicos, los sistemas de información de laboratorio, la telemedicina, las recetas digitales, los dispositivos médicos, los servicios en la nube, los sistemas de liquidación de seguros y los registros nacionales aportan ventajas considerables a los pacientes, pero al mismo tiempo convierten la infraestructura informática en parte del proceso de prestación de la asistencia sanitaria. Por ello, la ciberseguridad en la sanidad ya no es solo una cuestión de confidencialidad. Es una cuestión de seguridad del paciente, continuidad del tratamiento, integridad de las decisiones clínicas y resiliencia del sistema de salud pública. El Departamento de Salud y Servicios Humanos de EE. UU. formula expresamente el principio: la ciberseguridad es seguridad del paciente. [1]

El artículo del portal PRAVO.UA «Ciberseguridad en la sanidad: cómo proteger los datos de los pacientes en la era de la digitalización» se centra en tres propiedades básicas de la información protegida: confidencialidad, integridad y disponibilidad. Desempeñan un papel especial el factor humano, el control de acceso, la formación del personal y el régimen jurídico de la información médica. En el caso de Ucrania, estas tesis se ven confirmadas por la Ley «De Protección de Datos Personales», la legislación sobre protección de la información y ciberseguridad, las normas del Sistema Electrónico de Salud eHealth (ESOZ) y la reforma de 2025 del sistema nacional de respuesta a ciberincidentes. [2]

La práctica mundial demuestra que la consecuencia más peligrosa de un ataque contra la sanidad suele ser no el robo de un archivo en sí, sino la pérdida de operatividad del sistema. El ciberataque del ransomware WannaCry en mayo de 2017 provocó la cancelación de miles de citas en el Servicio Nacional de Salud del Reino Unido. El ataque contra el Servicio de Salud de Irlanda en 2021 comenzó con un correo de phishing y acabó en una desconexión masiva de sistemas.

El ciberataque contra la empresa Change Healthcare en 2024 alteró los flujos de recetas y pagos en buena parte del sistema sanitario estadounidense. El ataque contra el laboratorio británico Synnovis provocó el retraso de más de 11 000 citas ambulatorias y procedimientos programados. [3]

Las filtraciones también pueden alcanzar una escala sistémica. La empresa Anthem informó de casi 79 millones de afectados; la red sanitaria pública de Singapur SingHealth, de casi 1,5 millones; la compañía sanitaria australiana Medibank, de unos 9,7 millones; y el Departamento de Salud y Servicios Humanos de EE. UU. registraba, a julio de 2025, alrededor de 192,7 millones de personas cuya información se vio afectada por el incidente de Change Healthcare. [4]

El modelo regulatorio también está cambiando. En la UE, la directiva NIS2 (Directiva de la UE sobre seguridad de las redes y sistemas de información) traslada la ciberseguridad de la «función de TI» al ámbito de la responsabilidad directiva, exige la gestión de riesgos y una notificación escalonada de los incidentes significativos. El Reglamento General de Protección de Datos de la UE (RGPD) regula por separado las violaciones de la seguridad de los datos personales; el reglamento sobre el Espacio Europeo de Datos de Salud (EHDS) añade un nuevo nivel de normas para los datos médicos electrónicos y los sistemas de historiales médicos electrónicos (EHR). [5]

En el Reino Unido, el Servicio Nacional de Salud (NHS) está pasando a una evaluación mediante el Kit de herramientas de seguridad y protección de datos (DSPT), alineado con el Marco de evaluación de la ciberseguridad (CAF) del Centro Nacional de Ciberseguridad del Reino Unido (NCSC). [6]

EE. UU. combina las normas obligatorias de la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA), a saber, la Regla de Seguridad y la Regla de Notificación de Violaciones de Seguridad, con los Objetivos de ciberseguridad voluntarios para el sector de la salud y la salud pública (HPH CPGs). [7] Japón, Israel, Australia y Singapur muestran modelos diferentes, pero cada vez más similares: normas sectoriales, gestión obligatoria de riesgos, notificación a las autoridades públicas, formación del personal y mayor responsabilidad de la dirección. [8]

La conclusión clave para un centro sanitario: es imposible construir una ciberresiliencia suficiente solo con un antivirus, un centro de operaciones de seguridad (SOC) o una política de confidencialidad. Se requiere un trabajo simultáneo, como mínimo, en seis planos: gobernanza, gestión de identidades y accesos, segmentación y redundancia, protección de los dispositivos médicos y de los proveedores, respuesta a incidentes y continuidad del negocio, y formación permanente de las personas.

Para Ucrania esto es especialmente importante debido a un doble contexto: la digitalización a gran escala de los servicios médicos y la guerra. El CERT-UA informó expresamente en abril de 2026 de un grupo de ciberamenazas entre cuyos objetivos figuraban hospitales. [9] Por ello, la ciberresiliencia de un centro sanitario debe considerarse parte de la seguridad clínica, la resiliencia civil y la seguridad nacional.

Qué significa la ciberseguridad en la sanidad y por qué sus riesgos son especiales

Los tres pilares de la protección de los datos médicos: confidencialidad, integridad, disponibilidad

Es importante empezar no por la tecnología, sino por el estatuto jurídico de los datos médicos: la medicina digital trabaja con una de las categorías de información más sensibles sobre una persona y, por tanto, la ciberprotección debe garantizar el ejercicio del derecho del paciente a la confidencialidad. [10]

Filtración de datos médicos: un atacante frente a monitores que muestran fichas de pacientes, análisis e imágenes

En sentido práctico, la ciberseguridad en la sanidad es el conjunto de medidas de gestión, jurídicas, organizativas, técnicas, clínicas y formativas que garantizan:

PropiedadQué significa para la medicinaEjemplo de vulneración peligrosa
ConfidencialidadLa información médica solo la ven las personas autorizadasPublicación de diagnósticos o de datos psiquiátricos o reproductivos
IntegridadLos registros, las prescripciones y los resultados de las pruebas no han sido modificados sin autorizaciónAlteración de una alergia, de un resultado de laboratorio o de la dosis de un fármaco
DisponibilidadLos datos y los sistemas están a disposición del médico cuando los necesita para prestar la asistenciaEl ransomware bloquea el historial médico electrónico, el laboratorio o el sistema de recetas
AutenticidadEl sistema establece con fiabilidad quién realiza una acciónUna cuenta robada de un médico se utiliza para acceder al historial médico electrónico
TrazabilidadSe puede determinar quién, cuándo y qué consultó o modificóLa ausencia de registros imposibilita el análisis forense digital
ResilienciaLa atención médica continúa incluso con la pérdida de una parte de los sistemas de TIEl hospital pasa a procedimientos probados

Precisamente la disponibilidad distingue a la medicina de muchos otros sectores. En un banco, la indisponibilidad del sistema supone un retraso en un pago; en un hospital puede significar la imposibilidad de ver con rapidez los resultados de un análisis, realizar una prueba diagnóstica, confirmar el grupo sanguíneo, obtener el historial de alergias u organizar debidamente una intervención quirúrgica. La experiencia del Servicio Nacional de Salud del Reino Unido (NHS), del Servicio de Salud de Irlanda (HSE), de la empresa estadounidense Change Healthcare (operador de procesamiento de pagos médicos y reclamaciones de seguros) y del proveedor británico de servicios de laboratorio Synnovis demuestra que los ciberataques pueden traducirse directamente en una alteración operativa de la prestación de la asistencia sanitaria. [11]

Los datos médicos tienen un ciclo de vida largo. Una tarjeta bancaria puede reemitirse, pero las características genéticas, el historial de enfermedades, un diagnóstico psiquiátrico o el hecho de haber recibido un determinado tratamiento no pueden «sustituirse». Precisamente por ello, el RGPD europeo (Reglamento General de Protección de Datos de la UE) clasifica los datos de salud entre las categorías especiales de datos personales y establece para su tratamiento un régimen jurídico reforzado. [12]

La medicina presenta un abanico de vulnerabilidades extraordinariamente amplio. En un hospital típico funcionan simultáneamente diversos sistemas de información médica: el historial médico electrónico (EHR) y el sistema de información hospitalaria (HIS), el sistema de archivo de imágenes médicas (PACS), sistemas especializados que automatizan el trabajo del laboratorio (LIS) y de radiología (RIS), sistemas de farmacia, contabilidad, sistemas de control de acceso, correo electrónico, red privada virtual (VPN), red inalámbrica Wi-Fi, servidores, servicios en la nube, portales de pacientes, cientos o miles de estaciones de trabajo, así como dispositivos médicos conectados a la red. Por ello, la vulneración de un solo componente débil o de un contratista puede abrir potencialmente el camino hacia sistemas más críticos. Por eso el Departamento de Salud y Servicios Humanos de EE. UU. (HHS) incluye en sus Objetivos de ciberseguridad en la atención sanitaria requisitos específicos sobre autenticación multifactor, separación de las cuentas privilegiadas, gestión de vulnerabilidades, así como respuesta a los riesgos e incidentes relacionados con terceros. [13]

La cadena de suministro forma parte del riesgo clínico. Change Healthcare y Synnovis demostraron que la vulneración de un solo nodo de servicio puede afectar a un gran número de organizaciones médicas independientes. Change Healthcare garantizaba procesos transaccionales críticos entre aseguradoras, farmacias y proveedores de servicios médicos, y Synnovis prestaba servicios de laboratorio a varias organizaciones del NHS. [14]

El factor humano sigue siendo crítico: el phishing, las contraseñas, los errores del personal y la necesidad de desarrollar una cibercultura. La práctica lo confirma.

El riesgo para la salud pública es distinto del riesgo de un hospital concreto. Un ciberataque contra los registros de vacunación, las redes de laboratorios, la vigilancia epidemiológica, los sistemas de notificación de enfermedades infecciosas o el intercambio nacional de datos médicos puede empeorar la calidad de los datos que el Estado utiliza para evaluar las amenazas. Precisamente el vínculo entre los datos electrónicos de salud y las posibles amenazas para la salud y las futuras pandemias está incorporado expresamente a la lógica del Espacio Europeo de Datos de Salud (EHDS). [17]

En Europa, el problema tiene carácter sistémico. ENISA (Agencia de la Unión Europea para la Ciberseguridad), al analizar 215 incidentes de conocimiento público en el sector sanitario entre enero de 2021 y marzo de 2023, constató que el ransomware representaba el 54% de los casos estudiados; el 53% de los incidentes afectaba a los profesionales sanitarios y el 42%, concretamente, a los hospitales. [18] En los materiales más recientes de ENISA sobre 2024, el ransomware representaba aproximadamente el 45% de los incidentes relacionados con la salud, y las filtraciones de datos, cerca del 28%. [19]

Las categorías más destacadas de ciberincidentes en el sector sanitario europeo

Datos de ENISA; se muestran las dos categorías mayores, por lo que los valores no deben interpretarse como una distribución completa y mutuamente excluyente de todos los tipos de incidentes. [19]

El contexto ucraniano. Los materiales oficiales del Sistema Electrónico de Salud eHealth (ESOZ) describen la separación de los datos personales y médicos, la autenticación y la autorización controladas, el uso de la firma electrónica cualificada (FEC) y de la autenticación de dos factores, la restricción del acceso y un sistema integral de protección de la información. El Servicio Nacional de Salud de Ucrania (NHSU) es el titular de la base de datos central de eHealth, y la empresa estatal «Salud Electrónica» garantiza su administración. [20]

Tras los cambios de 2025, la legislación ucraniana formalizó además el sistema nacional de respuesta a ciberincidentes, el sistema de intercambio de información y el papel de la ciberprotección de la infraestructura crítica de información. [21] El CERT-UA, adscrito al Servicio Estatal de Comunicaciones Especiales, recibe las notificaciones de incidentes, los investiga, ayuda a eliminar sus consecuencias y coordina el intercambio de información sobre ciberamenazas. [9]

Esto significa que, para la medicina ucraniana, el modelo de «proteger la base de datos de pacientes» ya resulta insuficiente. Es necesario proteger simultáneamente los datos, el proceso de tratamiento, los procedimientos de reserva y la capacidad del centro para seguir funcionando durante un ataque.

Grandes ciberincidentes médicos: qué ocurrió realmente y qué enseñaron

Cómo una debilidad se convierte en crisis: correo de phishing, pérdida de acceso, propagación, fallo clínico

El material más valioso para construir la ciberresiliencia no es una lista de «ataques espeluznantes», sino el análisis de qué barreras de protección concretas fallaron y qué ocurrió con los procesos clínicos tras la vulneración.

Un hospital bajo ciberamenaza: una ambulancia junto al área de urgencias y una señal de alarma
Ciberincidentes sistémicos seleccionados en la sanidad

Cronología resumida

IncidenteEscalaMétodo / debilidad claveConsecuencia para la medicinaReacción regulatoria y recuperación
Anthem, EE. UU., 2015Casi 79 millones de personasSerie de ciberataques externos; se hace especial hincapié en la insuficiente gestión y control de los riesgosUna de las mayores filtraciones de datos médicos de su épocaEn 2018, Anthem accedió a pagar $16 millones, con un plan de medidas correctoras [22]
WannaCry, NHS de Inglaterra, 201780 de 236 fideicomisos hospitalarios resultaron afectados o sufrieron sus efectos; otros 603 centros de atención primaria y otras organizaciones del NHS resultaron infectadosEl ransomware aprovechó sistemas Windows vulnerables sin actualizar; la Oficina Nacional de Auditoría del Reino Unido (NAO) señaló que la instalación de actualizaciones y la configuración adecuada de los cortafuegos habrían podido reducir considerablemente el impactoEl NHS registró 6 912 primeras citas canceladas y estimó el número total de citas canceladas en más de 19 000; en cinco localidades, los pacientes tuvieron que desplazarse más lejos para recibir atención urgente.La NAO y el NHS llevaron a cabo revisiones exhaustivas; no se confirmó ningún robo de datos de pacientes.
[23]
SingHealth, Singapur, 2018Casi 1,5 millones de pacientes; en 159 mil de ellos, además, se sustrajeron los registros ambulatorios de dispensación de medicamentosProbable phishing → desplazamiento lateral encubierto por la red → vulneración de las cuentas de los administradores → acceso a la base de datos a través de CitrixGran filtración de alcance nacional; además, se consultaron de forma deliberada los datos del primer ministroSe creó una comisión de investigación; se corrigieron las vulnerabilidades, se separaron las estaciones de trabajo de internet y se informó ampliamente a los pacientes; la comisión emitió 16 recomendaciones sistémicas. [24]
HSE, Irlanda, 2021Vulneración a gran escala del servicio nacional de salud; posteriormente se notificó a unas 90 mil personas acerca de la información sustraídaCorreo de phishing en marzo → software malicioso → ransomware Conti en mayoDesconexión de una parte considerable de los sistemas de TI, procesos manualesNo se pagó el rescate; el HSE realizó un análisis independiente posterior al incidente y una investigación forense de los datos de varios años, y reforzó la protección informática y la formación de su personal. [25]
Medibank, Australia, 2022Unos 9,7 millones de clientes actuales y antiguosSegún los materiales de la Oficina del Comisionado de Información de Australia (OAIC), las credenciales de un contratista llegaron al perfil de su navegador; a continuación se produjeron una intrusión no autorizada, la extracción de datos y una escalada insuficiente de las alertasSe publicaron datos personales y datos de reclamaciones de salud; riesgo de robo de identidad, extorsión y daño psicológicoEn 2024, la OAIC inició un procedimiento para imponer una sanción civil ante el Tribunal Federal; la Policía Federal Australiana (AFP) y la Dirección de Señales de Australia (ASD) llevaron a cabo una investigación penal. [26]
Change Healthcare, EE. UU., 2024El HHS registró posteriormente a unos 192,7 millones de personas afectadasCredenciales vulneradas → acceso remoto al portal de Citrix sin autenticación multifactor → desplazamiento lateral encubierto por la red → extracción no autorizada de datos → ransomware ALPHV/BlackCatSe alteró el procesamiento de las reclamaciones de farmacia y de seguros médicos y los pagos a los proveedores; problemas de flujo de caja en los proveedores de servicios médicosSistemas aislados; la infraestructura se reconstruyó en gran medida desde cero; la Oficina de Derechos Civiles del HHS (OCR) abrió una investigación; el HHS y los Centros de Servicios de Medicare y Medicaid (CMS) adoptaron medidas para apoyar la continuidad de la atención médica. [27]
Synnovis, Reino Unido, 2024Se retrasaron más de 11 000 citas ambulatorias y programadasRansomware + robo de datosSe redujo drásticamente la capacidad de realizar pruebas de laboratorioLos delincuentes hicieron públicos los datos; Synnovis recurrió a las fuerzas del orden y obtuvo una orden judicial; los servicios se restablecieron por completo en diciembre de 2024. [28]
Mapa del mundo con los focos de ciberincidentes en el ámbito sanitario

Anthem mostró el precio de perder la confidencialidad. La OCR del HHS calificó el incidente como la mayor filtración de datos hasta ese momento y en 2018 alcanzó un acuerdo con Anthem por $16 millones, añadiendo un amplio plan de medidas correctoras. [22] Es un precedente importante: el regulador evalúa no solo el hecho de la intrusión, sino también si eran adecuados el análisis de riesgos, la gestión de accesos y las medidas de control de seguridad.

WannaCry mostró el precio de la deuda técnica. Según las conclusiones de la Oficina Nacional de Auditoría del Reino Unido, las organizaciones afectadas utilizaban sistemas Windows sin las actualizaciones instaladas o sistemas cuyo soporte había finalizado; las medidas básicas de instalación de actualizaciones y de gestión de los cortafuegos habrían podido evitar una parte considerable de las infecciones. Al mismo tiempo, las autoridades oficiales no constataron el robo de datos de pacientes: el riesgo clínico surgió ante todo por la indisponibilidad de los sistemas. [23]

SingHealth mostró el peligro de una escalada tardía. El acceso inicial se obtuvo, con toda probabilidad, ya en agosto de 2017 mediante phishing. Posteriormente, el atacante se desplazó durante meses por la red, vulnerando dispositivos finales, servidores y cuentas de administradores. El personal de TI advirtió anomalías ya en junio de 2018, pero la alta dirección y la Agencia de Ciberseguridad de Singapur (CSA) fueron informadas mucho más tarde. [29] La comisión vinculó expresamente el problema con la insuficiente concienciación en materia de ciberseguridad, la falta de formación y de recursos, así como con una escalada deficiente. [30]

El HSE mostró hasta qué punto puede alargarse el periodo posterior al incidente. El correo de phishing se recibió en marzo de 2021 y el ransomware se activó en mayo. Años después del ataque, el HSE seguía realizando labores de seguimiento y de notificación a las personas cuyos documentos habían sido copiados ilegalmente. [31] La respuesta a incidentes en la sanidad no termina en el momento en que «los servidores vuelven a funcionar»: a continuación prosiguen el análisis forense digital, la determinación del alcance de la filtración de datos, la notificación a los pacientes, los procesos judiciales, el seguimiento, el análisis de las lecciones aprendidas y la reconstrucción de las medidas de control.

Medibank mostró los riesgos de la cadena de suministro y de la protección de las credenciales. En los materiales del regulador australiano se describe la vulneración de las credenciales vinculadas a un empleado de un contratista de TI y las alertas de los sistemas de seguridad que no se gestionaron debidamente. La Oficina del Comisionado de Información de Australia (OAIC) sostiene que Medibank no adoptó medidas suficientes para proteger los datos sensibles de 9,7 millones de personas; el asunto fue remitido al Tribunal Federal de Australia. [32]

Change Healthcare es, posiblemente, la lección más elocuente sobre la autenticación multifactor. En el testimonio del director general de UnitedHealth Group ante el Comité de Finanzas del Senado de EE. UU. se señala que los atacantes utilizaron credenciales vulneradas para acceder a un portal de Citrix que no tenía autenticación multifactor; tras la intrusión se desplazaron por la red, exfiltraron datos y nueve días después lanzaron el ransomware. [33] La recuperación exigió sustituir miles de portátiles, cambiar las credenciales y reconstruir la red del centro de procesamiento de datos y los servicios clave. [34] Hasta el 26 de abril de 2024, UnitedHealth Group informó de más de $6,5 mil millones en pagos anticipados y asistencia sin intereses a los proveedores de servicios médicos para sostener su liquidez. [35]

Synnovis mostró el riesgo sistémico de la externalización. No resultó afectado un hospital concreto, sino un proveedor de servicios de laboratorio. La consecuencia fue la caída de la capacidad de laboratorio de varias organizaciones del Servicio Nacional de Salud del Reino Unido a la vez y más de 11 mil citas y procedimientos aplazados. [36] Es un argumento a favor de que el plan de continuidad de la actividad del hospital incluya no solo su propio centro de procesamiento de datos, sino también el fallo de un proveedor externo crítico.

De estos casos se desprende una regularidad fundamental: un resultado catastrófico rara vez se explica por una única «técnica de hackeo genial». Con más frecuencia es una cadena de debilidades corrientes: phishing → vulneración de credenciales → ausencia de autenticación multifactor → privilegios excesivos → segmentación insuficiente → escalada tardía → una copia de seguridad que no se había verificado → ausencia de un plan para prestar asistencia médica cuando los sistemas de información no están disponibles.

Cómo se organiza la ciberseguridad sanitaria en las distintas jurisdicciones

Para una comparación adicional, además de la UE, el Reino Unido, EE. UU., Japón e Israel, se han elegido Australia y Singapur. Australia resulta interesante por la combinación de una ley general de protección de la privacidad (Privacy Act), la notificación obligatoria de las filtraciones de datos y un régimen de protección de las infraestructuras críticas; Singapur, por su elevado nivel de digitalización, su política cibernética centralizada y un apoyo financiero muy concreto a la ciberseguridad en la atención sanitaria.

Ucrania: protección de los hospitales, las bases de datos y las personas; un paisaje de Kiev, el contorno del país y un escudo con candado

Unión Europea. Aquí actúan simultáneamente varios niveles de regulación. El RGPD protege los datos personales y reconoce los datos de salud como categoría especial; los artículos sobre la seguridad del tratamiento y la notificación de violaciones de seguridad conforman el nivel de protección de la privacidad en la ciberseguridad. En caso de filtración de datos personales, el responsable del tratamiento, por regla general, lo notifica a la autoridad de control en el plazo de 72 horas si la filtración puede suponer un riesgo para los derechos y libertades de las personas; en caso de riesgo elevado puede surgir la obligación de informar también a los propios interesados.

NIS2 incluye el sector sanitario como sector de alta criticidad y exige medidas de gestión de los riesgos de ciberseguridad. Para los incidentes significativos se prevé un modelo escalonado: alerta temprana en un plazo de 24 horas, notificación del incidente en un plazo de 72 horas e informe final, por regla general, a más tardar un mes después. Para las entidades esenciales, la directiva exige que las multas administrativas máximas previstas en la legislación nacional sean, como mínimo, de €10 millones o del 2% del volumen de negocios anual mundial. NIS2 se aplica a través de las leyes nacionales de los Estados miembros, por lo que las autoridades competentes y los detalles de procedimiento varían. [38]

El Reglamento 2025/327 sobre el Espacio Europeo de Datos de Salud (EHDS) crea un nivel adicional: normas de acceso de los ciudadanos a los datos electrónicos de salud, de uso transfronterizo a través de la plataforma MyHealth@EU, de uso secundario a través de los organismos de acceso a los datos de salud, así como requisitos para los sistemas de historiales médicos electrónicos (EHR). El reglamento se adoptó en 2025 y se implanta de forma gradual, por lo que en 2026 resulta más correcto entenderlo como un marco transformador en despliegue, y no como un sistema ya completado de golpe. [39]

La UE también ha adoptado un Plan de Acción específico sobre ciberseguridad de los hospitales y los centros sanitarios. La Comisión Europea prevé un centro especializado de apoyo, mecanismos de alerta temprana, formación y la posibilidad de conceder cibervales a los centros sanitarios más pequeños. En julio de 2026, ENISA informó de un acuerdo trienal con la Comisión sobre una contribución de €6 millones para apoyar la ejecución de esta línea de actuación. [40] La más amplia Ley de Cibersolidaridad, que entró en vigor en 2025, crea el Sistema Europeo de Alerta de Ciberseguridad y la Reserva de Ciberseguridad de la UE para responder a los incidentes de gran magnitud. [41]

Reino Unido. En el ámbito sanitario de Inglaterra, la autoridad competente con arreglo al Reglamento sobre redes y sistemas de información de 2018 (NIS Regulations) es el Departamento de Salud y Asistencia Social (DHSC); la guía sectorial oficial prevé obligaciones de seguridad, de notificación de incidentes y de ejecución normativa con posibles multas de hasta £17 millones. [42] Paralelamente, el UK GDPR (la versión británica del Reglamento General de Protección de Datos) exige notificar a la Oficina del Comisionado de Información (ICO) las filtraciones de datos que deban notificarse, por regla general en un plazo de 72 horas, y, en caso de riesgo elevado, informar también a las personas afectadas sin dilación indebida. [43]

Reviste especial importancia la evolución de la gobernanza corporativa en el NHS. En las directrices de 2026, NHS England señala que las organizaciones que prestan directamente asistencia médica deben someterse a la evaluación mediante el Kit de herramientas de seguridad y protección de datos (DSPT), alineado con el Marco de evaluación de la ciberseguridad (CAF) del NCSC. La supervisión por parte del consejo y de la dirección debe abarcar la gestión de los ciberriesgos, la protección frente a ataques y filtraciones de datos, la detección de amenazas, la minimización de las consecuencias, así como el uso adecuado y el intercambio de los datos. [6] Esto desplaza la ciberseguridad de la «responsabilidad del responsable de TI» a la responsabilidad a nivel del consejo de administración.

EE. UU. La Regla de Seguridad de la HIPAA (la ley estadounidense de protección de la información médica) exige a las organizaciones sujetas a la HIPAA y a sus socios comerciales proteger la información de salud protegida en formato electrónico (ePHI) mediante medidas administrativas, físicas y técnicas, y garantizar su confidencialidad, integridad y disponibilidad. [44]

La Regla de Notificación de Violaciones de Seguridad de la HIPAA utiliza un modelo de plazos distinto del del RGPD. Una filtración que afecte a 500 o más personas debe notificarse al Secretario de Salud y Servicios Humanos sin demora injustificada y, a más tardar, 60 días naturales después de su detección; en el caso de las filtraciones menores se admite una notificación anual agregada en el plazo establecido. Las notificaciones individuales también deben enviarse sin demora injustificada y, a más tardar, 60 días después. [45]

Paralelamente, el HHS ha elaborado los Objetivos de ciberseguridad para el sector de la salud y la salud pública: una base sectorial voluntaria construida sobre las prácticas HICP (Prácticas de ciberseguridad en la atención sanitaria), NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.) y CISA (Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU.). Entre las prioridades figuran: las vulnerabilidades de los sistemas, la seguridad del correo electrónico, la autenticación multifactor (MFA), el cifrado, las credenciales únicas, la separación de las cuentas privilegiadas, la segmentación de la red, los planes de respuesta a incidentes y los riesgos de terceros. [13]

Tras el incidente de Change Healthcare, el debate federal se intensificó considerablemente, pero es importante no confundir las normas vigentes con las propuestas de reforma. Por ejemplo, la CISA, en sus materiales actuales sobre la Ley de Notificación de Incidentes Cibernéticos en Infraestructuras Críticas (CIRCIA), señaló que las obligaciones de las organizaciones a las que se aplicará solo surtirán efecto una vez que entre en vigor la regla definitiva; por tanto, los plazos propuestos por la CIRCIA no deben interpretarse automáticamente como una obligación universal ya vigente para cada hospital. [46]

Japón. El principal regulador en el ámbito de la protección de la privacidad es la Comisión de Protección de la Información Personal (PPC), y la ley básica es la Ley de Protección de la Información Personal (APPI). [47] El Ministerio de Sanidad, Trabajo y Bienestar (MHLW) dispone de un sistema propio y desarrollado de directrices de ciberseguridad en la atención sanitaria. En 2026, el MHLW siguió publicando avisos de seguridad, listas de verificación, directrices para los sistemas de información médica y programas de formación, y manteniendo un canal de notificación de ciberincidentes. El Ministerio pide expresamente a los centros médicos que le informen con prontitud de los ciberataques o de las sospechas de ellos. [48]

Si se produce una filtración o existe la probabilidad de que se produzca una filtración de datos personales, en particular de datos de salud, surge además la obligación de informar a la PPC. La PPC exige una notificación inicial inmediata; si se sospecha de actos malintencionados, el informe final debe presentarse en un plazo de 60 días desde la detección. Entre los ejemplos de sucesos que deben notificarse que la PPC cita expresamente figuran el acceso no autorizado y el ransomware. [49]

El modelo japonés resulta interesante también por su financiación: el MHLW dispone de programas específicos de evaluación de la seguridad de las organizaciones médicas, de formación y de asesoramiento y, a través de los mecanismos gubernamentales de apoyo a las pequeñas y medianas empresas y a las TI, puede subvencionar la implantación de determinados servicios de ciberseguridad. [50]

Israel. Aquí la protección de los datos de salud se apoya en la Ley de Protección de la Privacidad y en el Reglamento de Protección de la Privacidad (Seguridad de los Datos) de 2017. El reglamento diferencia los requisitos según el nivel de seguridad de la base de datos y abarca la política de seguridad, el inventario de activos, la evaluación de riesgos, la protección física, el control de acceso, la autenticación, el registro de eventos, la documentación de incidentes, la externalización, las copias de seguridad y las auditorías. En caso de incidente grave de seguridad, para las bases de datos correspondientes rige la obligación de informar sin demora al Registrador de Bases de Datos. [51]

La Enmienda 13 a la Ley de Protección de la Privacidad entró en vigor el 14 de agosto de 2025 y amplió de forma considerable las facultades de ejecución, las sanciones económicas y la obligación de designar a un responsable de protección de datos (DPO) para determinadas categorías de organizaciones; las directrices oficiales israelíes citan expresamente entre dichas entidades a los hospitales y a las cajas hospitalarias. [52]

En el plano de la ciberseguridad, la política cibernética estatal la coordina la Dirección Nacional de Ciberseguridad de Israel (INCD); en 2025 se publicó una Estrategia Nacional de Ciberseguridad actualizada, con un horizonte de ejecución de tres años. [53] En marzo de 2026, el Ministerio de Sanidad exigió además a las organizaciones médicas que elevaran el nivel de alerta cibernética, revisaran los servicios accesibles desde el exterior y reforzaran la supervisión y la gestión de riesgos. [54]

Australia. La Ley de Privacidad y el esquema de notificación obligatoria de filtraciones de datos (NDB) abarcan, en particular, a los proveedores privados de servicios médicos. Si es probable que una filtración cause un daño grave, la organización debe notificarlo a la OAIC y a las personas afectadas; la evaluación de una presunta filtración debe realizarse en un plazo de 30 días. [55]

A los hospitales de importancia crítica se les aplica además la Ley de Seguridad de las Infraestructuras Críticas (SOCI): un ciberincidente crítico con un impacto significativo en la disponibilidad debe notificarse a la Dirección de Señales de Australia y al Centro Australiano de Ciberseguridad (ASD/ACSC) en un plazo de 12 horas, y cualquier otro ciberincidente con el impacto correspondiente, en un plazo de 72 horas. [56]

Singapur. La Ley de Protección de Datos Personales (PDPA) exige notificar a la Comisión de Protección de Datos Personales (PDPC) toda filtración que deba notificarse a más tardar tres días naturales después de haberlo constatado; se informa a las personas si es probable que la filtración les cause un daño significativo. Se considera significativa por su escala, en particular, la filtración que afecte a 500 o más personas. [58]

La Ley de Ciberseguridad abarca la infraestructura crítica de información (CII), en particular el sector sanitario. [59] En 2026, la Agencia de Ciberseguridad de Singapur (CSA) siguió reforzando el Código de Prácticas para la CII, con mayor énfasis en la supervisión por parte del consejo de administración, el marco de ciberresiliencia, las pruebas y la búsqueda de amenazas. [60]

El Ministerio de Sanidad de Singapur (MOH) también ha actualizado los Requisitos básicos de ciberseguridad y seguridad de los datos para los centros sanitarios y ha organizado formación y apoyo dirigidos, en particular, a las clínicas pequeñas. [61] Es importante que el apoyo tiene también una dimensión financiera: en 2026, el MOH informó de una subvención NEHR Connect de hasta $45 millones a cuatro años; para las pequeñas y medianas empresas también se prevé la cofinanciación de asesoramiento en ciberseguridad prestado por proveedores certificados por la CSA y programas específicos para cortafuegos y herramientas de protección contra el software malicioso. [62]

La responsabilidad financiera con arreglo a la PDPA también es considerable: para las organizaciones con un volumen de negocios anual en Singapur superior a $10 millones, la multa económica máxima puede alcanzar el 10% del volumen de negocios correspondiente; para las organizaciones más pequeñas rige un límite legal alternativo. [63]

Tabla comparativa

Parte 1. Autoridades, marco jurídico y plazos de notificación

JurisdicciónAutoridades clavePrincipales leyes y estándaresNotificación de incidentes y filtraciones
UEENISA, autoridades nacionales NIS y equipos de respuesta (CSIRT), autoridades de protección de datos, autoridades sanitariasGDPR; NIS2; EHDSNIS2: alerta temprana, 24 h; notificación, 72 h; informe final, ≈1 mes; RGPD: filtración de datos personales, ≈72 h
Reino UnidoDHSC, NHS England, NCSC, ICOReglamento NIS; UK GDPR; DSPT / CAF del NCSCICO: 72 h para una filtración de datos que deba notificarse; informes sectoriales con arreglo a NIS, según los umbrales establecidos
EE. UU.HHS / OCR, ASPR, CISA, FBI, NISTHIPAA: Regla de Seguridad y Regla de Notificación de Violaciones; HICP; HPH CPGs; NIST CSF≥500 personas: al HHS a más tardar en 60 días; a las personas afectadas, hasta 60 días
JapónPPC, MHLW, NCO / IPA / JPCERTAPPI; Directrices del MHLW sobre seguridad de los sistemas de información médicaNotificación inicial inmediata; en caso de filtración malintencionada, informe final en un máximo de 60 días; el MHLW pide notificar de inmediato los ciberincidentes
IsraelAutoridad de protección de la privacidad, INCD, Ministerio de SanidadLey de Protección de la Privacidad; Reglamento de Seguridad de los Datos; Enmienda 13Incidente grave de seguridad: notificación inmediata al regulador conforme al régimen correspondiente
AustraliaOAIC, ASD / ACSC, CISCLey de Privacidad / esquema NDB; Ley SOCINDB: a las personas afectadas y a la OAIC; hospitales críticos: 12 h si hay un impacto sustancial en la disponibilidad, 72 h en los demás ciberincidentes
SingapurPDPC, CSA, MOHPDPA; Ley de Ciberseguridad; Requisitos básicos del MOH sobre ciberseguridad y seguridad de los datosPDPC: hasta 3 días naturales después de constatar que la filtración debe notificarse

Parte 2. Sanciones, estrategia, financiación y formación

JurisdicciónPosibles sancionesEstrategia y gobernanzaFinanciación y apoyoFormación
UERGPD: hasta €20 millones / 4% del volumen de negocios; NIS2 para entidades esenciales: máximos nacionales de al menos €10 millones / 2%Plan de Acción de la UE sobre ciberseguridad de los hospitales; EHDSApoyo de ENISA; contribución de la Comisión Europea de €6 millones; posibles cibervales; mecanismos de la Ley de CibersolidaridadENISA + programas nacionales [64]
Reino UnidoCon arreglo a NIS: hasta £17 millones; UK GDPR: régimen de ejecución independienteCiberestrategia para la sanidad y la asistencia social; supervisión a nivel del consejo de administraciónCiberprogramas centrales del NHS + presupuestos localesDSPT, directrices del NCSC / NHS, ejercicios de simulación [65]
EE. UU.Multas civiles y acuerdos transaccionales con arreglo a la HIPAA; planes de medidas correctorasGestión sectorial de riesgos del HHS + ecosistema CISA / NISTProgramas federales de preparación y apoyo; recursos gratuitos del HHS; apoyo tras incidentes de gran magnitudHHS Cyber Gateway, HICP, formación con arreglo a los CPG [66]
JapónMecanismos regulatorios y penales de la APPILa sanidad es un ámbito de infraestructura críticaEvaluación por parte del MHLW; subvenciones para TI y ciberprotecciónProgramas por funciones del MHLW + servicio de asistencia en incidentes [67]
IsraelSanciones económicas reforzadas desde 2025 + disposiciones penalesEstrategia Nacional de Ciberseguridad 2025Ciberprogramas nacionales y sectorialesRecomendaciones de la INCD / del Ministerio de Sanidad, preparación sectorial [68]
AustraliaHasta A$50 millones / 3× el beneficio / 30% del volumen de negocios, según la fórmulaMarco de protección de las infraestructuras críticasCiberprogramas gubernamentales; asistencia del ACSCDirectrices y ejercicios de simulación del ACSC [69]
SingapurPDPA: hasta el 10% del volumen de negocios en Singapur para las organizaciones grandesEstrategia de Ciberseguridad 2026; gestión de la infraestructura crítica de información (CII)Subvención NEHR Connect de hasta S$45 millones a 4 años; apoyo a las pequeñas y medianas empresasFormación del MOH / CSA, plantillas, asesoramiento [70]

La comparación muestra una tendencia importante: los regímenes modernos ya no consideran la ciberseguridad un problema meramente técnico. En todos los modelos desarrollados aparecen cuatro elementos comunes: responsabilidad de la dirección, gestión obligatoria de riesgos, notificación rápida al Estado y capacidad de recuperación verificable. [71]

Un modelo práctico de ciberresiliencia para un centro sanitario

Ciberresiliencia del hospital: cuatro niveles: prevención, detección, continuidad, recuperación

Un programa de ciberseguridad de calidad debe empezar no con la compra de un producto, sino con la respuesta a la pregunta: ¿qué procesos clínicos no pueden detenerse y de qué activos digitales dependen?

Elementos de un sistema médico protegido: una carpeta protegida, un historial médico, una base de datos, un equipo, la telemedicina y una protección verificada

Un modelo de gobernanza típico puede tener este aspecto:

Modelo típico de gobernanza de la ciberresiliencia de un centro sanitario

Principio clave: el responsable de la seguridad de la información (CISO) no puede responder en solitario de un riesgo que puede paralizar el quirófano, el laboratorio o el servicio de urgencias. El propietario de dicho riesgo debe ser la dirección de la organización, y la dirección clínica debe participar en las pruebas de los planes de continuidad de la actividad y de recuperación ante desastres. Precisamente por ello, el NHS subraya en 2026 la supervisión por parte del consejo y de la dirección de los ciberriesgos y de la recuperación. [6]

El mínimo técnico. La primera prioridad debe ser la seguridad de las cuentas: autenticación multifactor (MFA) para el acceso remoto, los administradores, los servicios en la nube y el historial médico electrónico; cuentas privilegiadas independientes; derechos de acceso mínimos necesarios; desactivación rápida de las cuentas de los empleados que se han marchado; renuncia a las cuentas compartidas siempre que sea posible desde el punto de vista clínico. El incidente de Change Healthcare es, en la práctica, una confirmación de manual del riesgo que supone un portal de acceso remoto sin MFA. [33] El HHS incluye la MFA, las credenciales únicas y la separación de las cuentas privilegiadas entre los Objetivos de ciberseguridad para el sector de la salud. [13]

El segundo nivel es el inventario de activos y la gestión de vulnerabilidades. Un centro sanitario debe conocer no solo el número de ordenadores, sino el propietario de cada activo crítico, el sistema operativo, el firmware, la versión del software, la accesibilidad desde internet, el estado de soporte por parte del proveedor, la criticidad clínica, el método de copia de seguridad y el tiempo de inactividad admisible. La lección de WannaCry consiste precisamente en que los sistemas sin soporte y sin actualizaciones convirtieron una debilidad tecnológica conocida en un problema sistémico de la sanidad. [23]

El tercero es la segmentación de la red. Los sistemas clínicos, la infraestructura informática administrativa, el internet de las cosas médico y las tecnologías operativas, la red Wi-Fi de invitados, la infraestructura de copias de seguridad y el entorno de gestión del acceso privilegiado no deben formar una única red plana. Esto no garantiza la protección frente a una intrusión, pero dificulta considerablemente el desplazamiento lateral por la red, una fase que fue importante tanto en SingHealth como en Change Healthcare. [72]

El cuarto es la copia de seguridad como capacidad real, y no como una casilla formal marcada. Se necesitan, como mínimo, copias lógicamente aisladas o inmutables de los datos críticos, control de acceso a los sistemas de copia de seguridad y pruebas periódicas de restauración. En el caso del historial médico electrónico, no solo debe probarse la restauración de un archivo, sino un escenario: «¿Podemos restaurar el sistema clínico dentro del tiempo objetivo de recuperación (RTO) y del punto objetivo de recuperación de datos (RPO) acordados y verificar la integridad de los registros?»

El quinto son las herramientas de detección y respuesta en los dispositivos finales (EDR), el sistema de gestión de eventos de seguridad (SIEM), el registro de eventos y la configuración de la detección de amenazas. Es necesario correlacionar los registros del acceso remoto, de los sistemas de gestión de cuentas, del historial médico electrónico, de Active Directory, del cortafuegos, de la VPN, de los servicios en la nube y de las acciones de los usuarios privilegiados. SingHealth demuestra que algunos especialistas técnicos pueden ver anomalías, pero sin correlación y sin un modelo de escalada correcto la organización no las articula en una imagen única del ataque. [73]

El sexto es la seguridad de los productos sanitarios. Para cada dispositivo conectado a la red es necesario conocer al proveedor, el plazo de soporte y de fin del ciclo de vida, las actualizaciones disponibles, las dependencias de red, el método de autenticación, el mecanismo de asistencia remota y las consecuencias clínicas de su indisponibilidad. Si el dispositivo no puede actualizarse por restricciones de certificación o del proveedor, el riesgo se compensa con segmentación, una lista de programas permitidos, supervisión de la red, acceso remoto limitado y un plan de sustitución.

El séptimo es la seguridad de terceros. El contrato con un laboratorio, un proveedor de nube, un proveedor de un sistema de información hospitalario o médico, un servicio de telemedicina o un centro externo de operaciones de seguridad (SOC) debe contener, en lugar de un abstracto «garantiza la seguridad de la información», requisitos concretos: autenticación multifactor; cifrado; registro de eventos; notificación de incidentes; cooperación durante la investigación forense; corrección de vulnerabilidades; control de los subcontratistas; copias de seguridad; RTO/RPO; conservación de pruebas; derecho de auditoría; eliminación segura de datos; plan de salida del contrato. Las consecuencias de los incidentes de Change Healthcare y Synnovis demuestran que la dependencia operativa debe considerarse una ciberdependencia. [74]

El mínimo organizativo. Cada servicio clínico crítico debe contar con un plan escrito de trabajo durante la inactividad de los sistemas. No «TI restablecerá el sistema», sino de forma concreta: cómo registramos a un paciente nuevo sin el sistema de información hospitalario; cómo comprobamos el historial de medicación; cómo solicitamos las pruebas de laboratorio; cómo recibimos los resultados; cómo documentamos la administración de fármacos; qué ocurre con las imágenes médicas; cómo, tras la recuperación, volvemos a incorporar los registros en papel al historial médico electrónico; cómo evitamos la duplicación y los errores en la transferencia de datos.

El mínimo jurídico. El centro sanitario debe disponer de un registro de datos y de un mapa jurídico: qué categorías de datos se tratan, quién es el titular, el responsable o el encargado de los datos o el sujeto correspondiente con arreglo al derecho nacional, qué terceros tienen acceso, con qué base jurídica, dónde se almacenan los datos físicamente y en qué jurisdicción, cuáles son los plazos de conservación, cuáles son los requisitos de notificación de filtraciones y quién tiene derecho a decidir sobre la notificación al regulador y a los pacientes.

Para Ucrania es importante vincular esto con el régimen de eHealth (ESOZ), la Ley «De Protección de Datos Personales», las normas sobre secreto médico, la legislación sobre sistemas de información y comunicación y el nuevo sistema de respuesta a ciberincidentes. [75]

El mínimo formativo. Un curso anual de concienciación en ciberseguridad no basta por sí solo. Se recomienda dividir la formación por funciones:

GrupoQué debe practicar
Todos los empleadosReconocimiento del phishing, del robo de credenciales y de las solicitudes sospechosas de autenticación multifactor; tratamiento de los datos de los pacientes; notificación rápida de los incidentes
Médicos / enfermerasProcedimientos de trabajo durante la inactividad de los sistemas, acceso seguro al historial médico electrónico, dispositivos portátiles, procesos de trabajo de emergencia
Especialistas de TIProtección de las configuraciones, instalación de actualizaciones, copias de seguridad, segmentación, registros, herramientas EDR, análisis forense digital
Administradores de sistemasGestión del acceso privilegiado (PAM), cuentas privilegiadas, procedimientos de acceso de emergencia
DirecciónToma de decisiones durante un ataque de ransomware, comunicaciones, riesgos jurídicos, priorización de los servicios
Juristas / responsable de protección de datosEvaluación de la filtración, notificación al regulador y a los pacientes, conservación de pruebas
Departamento de comprasRequisitos de seguridad de terceros en los contratos, acuerdo de nivel de servicio (SLA), notificación de incidentes, condiciones de salida del contrato

Este enfoque por funciones se corresponde con las líneas que desarrollan el HHS, el NHS y el MHLW. [76]

Plan de acción tras un ciberincidente

Respuesta a un ciberincidente: los primeros minutos, las primeras horas, el primer día, la recuperación

Las primeras horas tras un ataque son el momento en que una decisión errónea puede aumentar tanto el daño clínico como el jurídico. El plan de respuesta a incidentes de un centro sanitario debe estar aprobado de antemano, probado y alineado con el plan de continuidad de la actividad.

Horizonte temporalAcciones principales
Los primeros minutosDesignar al responsable de la respuesta al incidente; confirmar el impacto en los procesos clínicos; aislar los activos vulnerados; no destruir pruebas; cuando sea necesario, pasar a los procedimientos de trabajo durante la inactividad
Hasta unas pocas horasImplicar a los especialistas de TI y al servicio de seguridad, a la dirección clínica, a los juristas y al responsable de protección de datos, a la dirección y al servicio de comunicaciones; determinar el vector de ataque; bloquear las credenciales vulneradas; recopilar las pruebas digitales volátiles y los registros
Las primeras 24 horasDeterminar el alcance del incidente, el volumen de datos expuestos, los sistemas afectados y los servicios críticos; verificar las copias de seguridad; notificar al CERT/CSIRT y a los reguladores si surge tal obligación; organizar procesos clínicos alternativos
24–72 horasContinuar la contención y la eliminación de la amenaza; realizar la evaluación jurídica de la filtración; enviar las notificaciones obligatorias; preparar un comunicado público verificado; iniciar una recuperación controlada
Los días siguientesRestablecer los sistemas prioritarios en un entorno limpio; cambiar las credenciales y las claves; reforzar la supervisión; verificar la integridad de los datos; trabajar con los pacientes, los proveedores y las fuerzas del orden
Tras la estabilizaciónRealizar un análisis independiente posterior al incidente y un análisis de causas raíz; subsanar las deficiencias de las medidas de control; preparar un informe para la dirección; actualizar el registro de riesgos; repetir el ejercicio de mesa

La experiencia de la UE con NIS2 muestra especialmente bien por qué no se puede esperar a tener el «cuadro forense completo» antes de empezar a notificar: el sistema prevé una alerta temprana en un plazo de 24 horas, después una notificación en un plazo de 72 horas y solo más tarde el informe final. [77] Una lógica análoga existe en Australia para la infraestructura crítica: 12 horas para los incidentes más graves que afectan a la disponibilidad. [56]

Para Ucrania, la interacción con el CERT-UA debe preverse en el plan con antelación. El equipo recibe oficialmente las notificaciones, lleva a cabo la investigación y presta ayuda para eliminar las consecuencias. [9]

Qué no debe hacerse durante un ataque de ransomware: apagar caóticamente todo el equipo sin coordinación; borrar los registros; contactar por cuenta propia con los atacantes desde cuentas personales; indicar públicamente la causa o la magnitud antes de que lo confirme el análisis forense; restablecer los sistemas en una red vulnerada; conectar las copias de seguridad a un entorno donde aún no se ha eliminado la persistencia del atacante; considerar el pago del rescate como sustituto de la recuperación.

Los casos del HSE y de Change Healthcare muestran dos decisiones distintas sobre el rescate: el HSE no pagó el rescate, mientras que el director general de UnitedHealth Group confirmó que él mismo tomó la decisión de pagar en Change Healthcare. [78] De ello no se deduce una regla universal de «nunca» o «siempre» pagar. La decisión depende de la posición de las fuerzas del orden, del régimen de sanciones, de las consecuencias clínicas, de la posibilidad de recuperación, del seguro y de la evaluación jurídica. Pero la recepción de una exigencia de rescate no debe ser la primera vez que la dirección debate esta política.

Plantillas breves de políticas y procedimientos

Plantilla de política de gestión de accesos

Una médica trabaja con el historial médico electrónico de un paciente en un ordenador protegido

Objetivo: garantizar el acceso a la información médica exclusivamente de conformidad con las competencias profesionales y clínicas.

Regla: todos los usuarios disponen de cuentas personales. La autenticación multifactor (MFA) es obligatoria para el acceso remoto, las cuentas privilegiadas y otros sistemas críticos determinados. Los derechos se conceden conforme a los principios de los derechos de acceso mínimos necesarios y del acceso basado en funciones.

Revisión: los derechos se revisan tras un cambio de puesto y de forma periódica; tras la extinción de la relación laboral o contractual, el acceso se revoca de inmediato.

Acceso de emergencia: el acceso que elude las reglas habituales («romper el cristal») se permite únicamente por necesidad clínica, se registra automáticamente y está sujeto a una revisión posterior.

El enfoque se corresponde con los Objetivos de ciberseguridad del HHS (CPGs) y con los principios de acceso controlado que se aplican en eHealth (ESOZ). [79]

Plantilla de procedimiento de notificación de un incidente sospechoso

Cualquier empleado que advierta un inicio de sesión inusual en el sistema, phishing, un mensaje de ransomware, un acceso no autorizado, la pérdida de un dispositivo o un comportamiento anómalo de un sistema clínico no lleva a cabo una investigación por su cuenta, sino que informa de inmediato al servicio de asistencia o al centro de operaciones de seguridad (SOC) a través del canal designado.

La notificación debe contener: la hora, el sistema o dispositivo, una breve descripción, una captura de pantalla (si es posible) y las acciones del usuario previas al suceso.

El equipo de respuesta a incidentes determina el nivel de gravedad, el impacto en los procesos clínicos y la necesidad de escalar a la dirección, al responsable de protección de datos, a los juristas, al CERT o al regulador.

El problema de la escalada tardía es una de las lecciones centrales de SingHealth. [73]

Plantilla de cláusula contractual sobre la seguridad de terceros

El proveedor aplica la autenticación multifactor al acceso remoto y privilegiado, lleva un registro de los eventos de seguridad, mantiene un proceso de gestión de vulnerabilidades, cifra los datos sensibles durante la transmisión y el almacenamiento, mantiene una capacidad probada de copia de seguridad y recuperación e informa al cliente de un incidente de seguridad confirmado o razonablemente sospechado a más tardar X horas después de su detección.

El proveedor conserva las pruebas digitales, colabora en la investigación del incidente, informa de los subcontratistas implicados y no cambia el lugar ni la jurisdicción del tratamiento de los datos de salud sin el procedimiento previsto en el contrato.

Conviene fijar en el contrato un plazo más corto que el plazo regulatorio externo; de lo contrario, el centro sanitario puede materialmente no llegar a tiempo para cumplir su propia obligación de notificación.

Plantilla de política de copia de seguridad y recuperación

Para cada sistema clínico crítico se establecen el tiempo objetivo de recuperación (RTO) y el punto objetivo de recuperación de datos (RPO).

Al menos una copia de seguridad debe estar protegida contra su modificación o eliminación con el uso de credenciales de trabajo.

La prueba de restauración se realiza conforme a un calendario aprobado.

Los resultados de la prueba de restauración se documentan y se comunican al propietario del sistema.

Una copia de seguridad se considera apta solo tras una restauración confirmada y una verificación de la integridad.

Plantilla de procedimiento de trabajo durante la inactividad causada por un ataque de ransomware

En caso de pérdida de acceso al historial médico electrónico, el responsable clínico competente declara el paso al modo de trabajo durante la inactividad.

Se utilizan formularios en papel o locales preparados con antelación para la identificación de los pacientes, la administración de medicamentos, las solicitudes de laboratorio, las imágenes médicas y los registros clínicos.

Tras la recuperación, los datos se trasladan al historial médico electrónico mediante un procedimiento de doble control, con el fin de minimizar la duplicación y los errores de transferencia.

La recuperación de los sistemas de TI y la recuperación de los procesos clínicos son flujos de trabajo independientes que sincroniza el responsable de la respuesta al incidente.

Lista de verificación de preparación del centro sanitario y conclusiones estratégicas

A continuación se presenta una herramienta práctica de autoevaluación. Una respuesta «no» no significa automáticamente un fallo crítico, pero el conjunto de respuestas «no» dentro de una misma categoría apunta a un riesgo sistémico.

Formación del personal en ciberhigiene: una médica explica a las enfermeras el esquema de protección de datos
Pregunta de controlSí / Parcialmente / No
¿El director del centro o el consejo recibe periódicamente un informe sobre los ciberriesgos?☐
¿Se han designado responsables de la seguridad de la información (CISO) y de la protección de los datos personales (DPO)?☐
¿Existe un registro actualizado de todos los activos de TI críticos y de los productos sanitarios?☐
¿Se han determinado para cada servicio clínico crítico sus dependencias de TI?☐
¿Está activada la autenticación multifactor (MFA) para la VPN, el acceso remoto, los servicios en la nube y las cuentas privilegiadas?☐
¿Los administradores utilizan cuentas privilegiadas independientes?☐
¿Se han eliminado las cuentas compartidas o se controlan estrictamente?☐
¿Existe un procedimiento para revocar el acceso inmediatamente tras una baja o un cambio de puesto?☐
¿Se analizan periódicamente en busca de vulnerabilidades los recursos accesibles desde internet?☐
¿Se ha fijado un plazo garantizado de instalación para las actualizaciones críticas?☐
¿Se conocen los sistemas sin soporte y disponen de un plan de sustitución o de segmentación?☐
¿Están segmentadas las redes clínica, administrativa, de invitados, de productos sanitarios y de copias de seguridad?☐
¿Las herramientas EDR o una supervisión análoga de los dispositivos finales abarcan los servidores y los PC críticos?☐
¿El registro centralizado de eventos abarca las cuentas, la VPN, Active Directory, el historial médico electrónico, el cortafuegos y los servicios en la nube?☐
¿Los registros están protegidos frente a su eliminación por una cuenta de administrador ordinaria?☐
¿Existen copias de seguridad aisladas o inmutables de los sistemas críticos?☐
¿Se ha realizado una prueba de restauración real en los últimos 12 meses?☐
¿Se han definido y probado el RTO/RPO para el historial médico electrónico y para los sistemas de información de laboratorio, de radiología y hospitalario?☐
¿Puede el servicio de urgencias funcionar sin el historial médico electrónico?☐
¿Dispone el laboratorio de un procedimiento de trabajo sin el sistema de información de laboratorio?☐
¿Existe un proceso en papel o fuera de línea para la prescripción y la administración de medicamentos?☐
¿Existe un plan de conciliación de los registros en papel tras la recuperación de los sistemas?☐
¿Están obligados los proveedores críticos a notificar con rapidez los incidentes?☐
¿Los contratos incluyen requisitos de seguridad, copias de seguridad, auditoría, investigación forense y salida del contrato?☐
¿Se conocen todos los subcontratistas y los lugares de almacenamiento de los datos de los pacientes en la nube?☐
¿Se ha actualizado el plan de respuesta a incidentes a lo largo del año?☐
¿Se dispone de contactos actualizados del CERT/CSIRT, del regulador, de las fuerzas del orden y del asegurador?☐
¿Se ha realizado a lo largo del año una formación sobre un ataque de ransomware?☐
¿Se ha implicado en la formación al director, a la dirección clínica, a los juristas y al servicio de comunicaciones?☐
¿El personal recibe periódicamente formación sobre phishing y ciberseguridad?☐
¿Conocen los empleados un único canal sencillo al que notificar un incidente?☐
¿Existe una matriz jurídica de los plazos de notificación de filtraciones y ciberincidentes?☐
¿Existe una plantilla aprobada de notificación a los pacientes?☐
¿Existe una política independiente de toma de decisiones sobre el rescate y la extorsión?☐
¿Se realiza un análisis de las lecciones aprendidas tras los incidentes y las situaciones «al límite»?☐

En la práctica, el resultado puede valorarse así: 90–100% de «Sí»: un programa maduro que, no obstante, requiere pruebas permanentes; 70–89%: una base aceptable con carencias concretas; 50–69%: una vulnerabilidad operativa sustancial; menos del 50%: la prioridad debe ser no adquirir una nueva plataforma tecnológica, sino construir una gobernanza básica y la capacidad de recuperación. No es una escala regulatoria, sino una herramienta de gestión para el análisis interno de carencias.

Para un centro ucraniano, conviene distribuir las primeras inversiones en el siguiente orden: seguridad de las cuentas y MFA → inventario de activos → copia de seguridad y recuperación → gestión de actualizaciones y vulnerabilidades → segmentación de la red → registro de eventos y detección de amenazas → respuesta a incidentes → procedimientos clínicos para los periodos de inactividad → seguridad de los proveedores → capacidades ampliadas del centro de operaciones de seguridad (SOC). Este orden se corresponde con la naturaleza de las debilidades que se manifestaron realmente en WannaCry, SingHealth, el HSE, Medibank y Change Healthcare. [80]

Para un hospital pequeño, esto no significa que deba crear un gran SOC propio. Una parte de las funciones puede adquirirse como servicio gestionado, pero el riesgo y la responsabilidad no pueden externalizarse. La dirección, en cualquier caso, debe saber qué datos y sistemas son críticos, quién puede cortar el acceso al atacante, quién restablecerá el historial médico electrónico, cuánto tiempo llevará y cómo trabajarán los médicos hasta la recuperación.

Para el sistema público de salud se necesita un nivel adicional: inteligencia sectorial de amenazas, medidas básicas de protección unificadas, proveedores certificados y verificados, notificación centralizada, financiación de la ciberprotección de los hospitales pequeños, ejercicios conjuntos entre centros, mecanismos de reserva para los laboratorios y para el sistema electrónico de salud, así como una coordinación nacional de la respuesta a incidentes. Es en esta dirección en la que avanzan la UE, el NHS, Japón y Singapur. [81]

Para Ucrania resultaría especialmente prometedor un modelo en el que el nivel básico mínimo de ciberseguridad de los centros médicos esté vinculado no solo a la protección de los datos personales, sino también a la capacidad de prestar asistencia en caso de fallo de los sistemas digitales. En la práctica, esto significa acercar tres disciplinas tradicionalmente separadas:

ciberseguridad + seguridad del paciente + continuidad de la actividad = ciberresiliencia de la sanidad.

Esta es la principal lección de la última década. Los sistemas más maduros ya no se plantean la pregunta: «¿Será atacado nuestro hospital?» Planifican cómo impedir la propagación del ataque, cómo seguir tratando a los pacientes durante el incidente y cómo recuperarse sin perder la confianza ni la integridad de los datos médicos.

Para Ucrania, este enfoque se ve reforzado además por el riesgo bélico. El CERT-UA ya registró en 2026 campañas entre cuyos objetivos figuraban hospitales, mientras que la medicina digital depende cada vez más de eHealth (ESOZ) y de sistemas de información interconectados. [82] Por tanto, la ciberresiliencia del sistema médico debe considerarse al mismo nivel que la resiliencia energética, de las comunicaciones y de otras infraestructuras críticas.

Nuestros proyectos

Proyectos para veteranos

  • veterano.info: proyecto informativo para los veteranos y sus familias del Clúster de Veteranos de Ucrania y del Instituto de Veteranos.
  • veterano.media: medio del Clúster de Veteranos de Ucrania: noticias, historias y orientación práctica para los veteranos y sus familias.
  • veterano.army: agencia de personal para empresas: seleccionamos veteranos aptos para trabajar según las necesidades de la empresa: producción, almacén, logística, oficina.
  • veterano.bio: confirmación digital de la condición de veterano y traducción de documentos: perfil protegido, certificado multilingüe.
  • veterano.digital: «Ventanilla Única», una recepción digital para el veterano en el ámbito de la educación: solicitud por cualquier medio conveniente, itinerario educativo personalizado.

Proyectos asociados del ecosistema

Soluciones listas de SmartGT

  • Smart CMS: CMS gratuito y seguro con IA integrada para contenidos, complementos adaptados a sus tareas y un cómodo editor de bloques.
  • Smart LMS: plataformas de formación llave en mano: cursos, pruebas, tareas, certificados y venta de acceso; cada escuela con su propio dominio y marca, todas desde un único panel.
  • BOT-panel: gestión de bots de Telegram con IA en un único panel: envíos masivos, contactos, control de jornada, aprobación de documentos, evaluación de la calidad de la comunicación.
  • Smart Audit: revisión gratuita del sitio web en 3 minutos: seguridad, visibilidad en buscadores, velocidad, preparación para los agentes de IA; sin registro.
  • Smart 360: ERP y CRM para empresas: clientes y operaciones en el embudo, nomenclatura y listas de precios, almacén, documentos y contratos en un único sistema.
  • Smart Window: la ventanilla única del directivo: cómo está organizado el panel y qué se ve en él.

Fuentes

Ucrania

  1. Olha Danchenko. «Ciberseguridad en la sanidad: cómo proteger los datos de los pacientes en la era de la digitalización», PRAVO.UA, 16 de septiembre de 2026. [15]
  2. Verjovna Rada de Ucrania. Ley de Ucrania «De Protección de Datos Personales», versión vigente. [83]
  3. Verjovna Rada de Ucrania. Ley n.º 4336-IX de 27 de marzo de 2025 sobre la protección de la información y la ciberprotección de los recursos de información estatales y de la infraestructura crítica de información. [21]
  4. ESOZ / empresa estatal «Salud Electrónica». Materiales oficiales sobre la protección de los datos personales y médicos en la base de datos central de eHealth. [20]
  5. CERT-UA [9]

Unión Europea

  1. European Union. Directive 2022/2555 — NIS2 Directive. [77]
  2. European Union. Regulation 2016/679 — General Data Protection Regulation. [12]
  3. European Union. Regulation 2025/327 — European Health Data Space. [39]
  4. ENISA. Checking-up on Health: Ransomware Accounts for 54% of Cybersecurity Threats, 2023. [18]
  5. ENISA. [19]
  6. European Commission. Cybersecurity in healthcare, 2026. [84]
  7. ENISA, 2026. [85]
  8. European Commission / UE. Cyber Solidarity Act y European Cybersecurity Reserve. [41]

Reino Unido

  1. National Audit Office. Investigation: WannaCry cyber attack and the NHS, 2017. [23]
  2. NHS England. Board and executive assurance: cyber security risk, 2026. [6]
  3. UK Department of Health and Social Care. The Network and Information Systems Regulations 2018: guide for the health sector in England. [42]
  4. Information Commissioner’s Office. Guidance on personal data breach reporting under UK GDPR. [43]
  5. NHS England. Synnovis cyber incident. [28]
  6. ICO. Statement concerning the Synnovis cyber attack. [86]

EE. UU.

  1. U.S. HHS Office for Civil Rights. HIPAA Security Rule materials. [44]
  2. U.S. HHS. HIPAA Breach Notification Rule, 2026 reporting instructions. [45]
  3. HHS Cyber Gateway. Healthcare and Public Health Cybersecurity Performance Goals. [87]
  4. HHS OCR. Anthem pays OCR $16 Million in record HIPAA settlement following largest health data breach in history, 2018. [22]
  5. HHS OCR. Change Healthcare Cybersecurity Incident Frequently Asked Questions. [88]
  6. Andrew Witty / UnitedHealth Group. Testimony before the U.S. Senate Finance Committee: Change Healthcare cyberattack. [89]
  7. UnitedHealth Group. Updates restoration Change Healthcare. [90]
  8. U.S. Department of Justice. ALPHV/BlackCat ransomware operations. [91]

Irlanda

  1. Health Service Executive. Conti cyber attack on the HSE — Independent Post Incident Review. [92]
  2. HSE. [31]

Japón

  1. Personal Information Protection Commission of Japan. APPI — laws and policies. [47]
  2. PPC Japan. Reporting personal-data leaks, unauthorized access ransomware. [49]
  3. Ministry of Health, Labour and Welfare. Portal cybersecurity measures for medical institutions, guidance, checklists, training, reporting, procedures. [48]
  4. MHLW. Cybersecurity support and assessment programme for medical institutions. [93]

Israel

  1. Israel Privacy Protection Authority. Guidance on Privacy Protection Regulations (Data Security) 2017. [51]
  2. Israel Privacy Protection Authority. Amendment 13 to the Privacy Protection Law, effective from August 2025, updated guidance, 2026. [52]
  3. Israel National Cyber Directorate. National Cybersecurity Strategy 2025. [53]
  4. Israel Ministry of Health. Cybersecurity directions to health organisations, 2026. [54]

Australia

  1. Office of the Australian Information Commissioner. Notifiable Data Breaches scheme guidance. [55]
  2. OAIC. OAIC takes civil penalty action against Medibank, 2024. [94]
  3. OAIC. Regulatory guidance on current maximum Privacy Act civil penalties. [57]
  4. Australian Cyber Security Centre / cyber.gov.au. Mandatory reporting under the Security of Critical Infrastructure Act, including critical hospital assets. [56]
  5. Australian Federal Police. Official investigation materials concerning the Medibank attack. [95]

Singapur

  1. Personal Data Protection Commission. Data breach notification requirements. [58]
  2. PDPC. Updated PDPA enforcement regime and financial penalty limits. [63]
  3. Cyber Security Agency of Singapore. Cybersecurity Act and Critical Information Infrastructure requirements. [96]
  4. Singapore Ministry of Health. Healthcare Cyber Security and Data Security Essentials, training and support measures, 2026. [61]
  5. Singapore Ministry of Health. Funding measures including NEHR Connect Grant and cybersecurity support for providers, 2026. [62]
  6. Committee of Inquiry into the Cyber Attack on Singapore Health Services Patient Database. Official public report, 10 January 2019. [97]