Ciberseguridad para healthtech: cumplimiento técnico en España (2026)

Tu startup de healthtech tiene una API que recibe datos de pacientes desde la app del usuario, los normaliza con HL7 FHIR y los empuja a una historia clínica electrónica que vive en el hospital cliente. Llevas seis meses iterando con dos hospitales piloto y acabas de cerrar el tercero — uno público, gestionado por una consejería autonómica. Una semana después de firmar, llega el cuestionario: política de seguridad, declaración de aplicabilidad, evidencia de cifrado, esquema de accesos al dato sanitario, plan de continuidad, plantilla del registro de actividades y, en la última pestaña, certificación ENS o documento equivalente.

Y entonces te das cuenta de que el "RGPD básico" que cumplías para SaaS B2B no cubre ni la mitad de lo que te van a pedir cuando el cliente es público y el dato es de salud.

El sector salud en España opera bajo una superposición de marcos: el Reglamento General de Protección de Datos (RGPD) con su régimen reforzado para datos de categoría especial, la LOPDGDD, el Esquema Nacional de Seguridad (ENS) en cuanto entran clientes del sector público, NIS2 si tu actividad cae bajo "entidades esenciales o importantes" del sector sanitario, y la AEMPS si tu producto es un dispositivo médico (incluido software como dispositivo). En este artículo vamos a mapear ese paisaje regulatorio a controles técnicos concretos que puedes implementar en una infraestructura cloud moderna, con la evidencia que te van a pedir en cada auditoría.

No es un artículo de abogados. Es un artículo para CTOs y founders técnicos de healthtech que necesitan saber qué configurar, dónde, y qué guardar como evidencia para no quedarse fuera de procesos de compra públicos ni acumular deuda regulatoria. Para el contexto técnico transversal del Artículo 32, asumimos que ya conoces las medidas técnicas exigidas por el Artículo 32 del RGPD; aquí añadimos lo específico del dato sanitario.

El paisaje regulatorio del healthtech en España

Antes de hablar de controles, conviene tener clara la pila de obligaciones que se acumulan sobre una startup que trata datos de salud en España. Cada capa añade requisitos sin sustituir a la anterior.

RGPD — datos de categoría especial (artículo 9). Los datos relativos a la salud son una categoría especial bajo el artículo 9 del RGPD. Su tratamiento está prohibido por defecto y solo se levanta la prohibición si concurre alguna de las excepciones del 9.2: consentimiento explícito, fines de medicina preventiva o diagnóstico, gestión de sistemas de salud, interés público en salud pública, etc. Esto no es trivia legal: el régimen reforzado se traduce en obligaciones técnicas adicionales (mayor exigencia de cifrado, registros de acceso al dato, evaluaciones de impacto) y en sanciones del tramo alto del artículo 83.5 — hasta 20 millones de euros o el 4 % del volumen de negocio anual global, optándose por la mayor cuantía.

LOPDGDD y Artículo 32 RGPD. La Ley Orgánica 3/2018 desarrolla el RGPD en España. El requisito de "medidas técnicas y organizativas apropiadas al riesgo" del artículo 32 se interpreta de forma estricta cuando el dato es de salud: lo que para un SaaS de productividad es proporcional, para una historia clínica electrónica suele ser insuficiente. La AEPD ha sancionado de forma reiterada a operadores del sector salud por carencias técnicas que en otros sectores pasarían por "buenas prácticas mejorables".

Esquema Nacional de Seguridad — Real Decreto 311/2022. Aplica a las entidades del sector público y, por extensión, a los proveedores que les prestan servicios cuando esos servicios tratan información o sirven al ejercicio de competencias públicas. En la práctica: si vendes a un hospital público, una consejería de sanidad o el Servicio Nacional de Salud, te van a pedir adecuación al ENS de los servicios afectados. El sistema se categoriza (básico, medio, alto) según el impacto, y para la mayoría de servicios que tratan historias clínicas la categorización va a ser media o alta, lo que dispara prácticamente todo el catálogo de medidas del Anexo II.

NIS2. La Directiva (UE) 2022/2555 incluye al sector sanitario entre los sectores de "alta criticidad". Si tu organización supera los umbrales de tamaño te aplican directamente las obligaciones de gestión de riesgos, notificación de incidentes y gobernanza. Para una startup pequeña, NIS2 puede no aplicarte directamente, pero te aplicará en cascada a través de los hospitales y aseguradoras que sí están obligados y que te trasladan los requisitos por contrato.

AEMPS y MDR. Si tu software es un producto sanitario bajo el Reglamento (UE) 2017/745 (MDR), entras en el ámbito de la Agencia Española de Medicamentos y Productos Sanitarios. Aplicaciones con propósito diagnóstico, algoritmos de triaje o sistemas de soporte a la decisión clínica suelen calificar. La calificación impone requisitos de gestión de riesgos (ISO 14971), ciclo de vida del software (IEC 62304) y obligaciones de ciberseguridad alineadas con la guía MDCG 2019-16. Si dudas sobre si tu producto califica, consúltalo con asesoría regulatoria especializada — generalizar aquí es peligroso.

Contratos de encargado del tratamiento. Cada hospital, mutua o aseguradora con la que firmes va a exigir un contrato bajo el artículo 28 del RGPD con anexos técnicos detallados. Esos anexos son donde se materializa todo lo anterior: te listan controles concretos y te piden evidencia.

RGPD-S: qué cambia cuando el dato es de salud

El régimen reforzado del artículo 9 no es un "haga lo mismo pero con más cuidado". Modifica obligaciones concretas que se traducen en controles técnicos adicionales.

Base legal documentada por tratamiento. Cada flujo de datos sanitarios necesita una excepción del 9.2 identificada y justificada. El registro de actividades del tratamiento (artículo 30) debe ser preciso: qué dato, qué finalidad, qué excepción del 9.2, qué base legal complementaria del 6.1, qué plazo de conservación.

DPIA prácticamente obligatoria. El artículo 35.3.b del RGPD exige evaluación de impacto cuando se traten categorías especiales a gran escala, y la AEPD considera que el tratamiento sistemático de datos de salud por una plataforma tecnológica entra en ese supuesto en la práctica totalidad de los casos. La sección de medidas técnicas de la DPIA debe rellenarse con evidencia real, no con declaraciones genéricas.

Cifrado más allá de "en reposo y en tránsito". La proporcionalidad del artículo 32 al dato sanitario lleva a exigir cifrado a nivel de campo para datos clínicos especialmente sensibles, separación de claves por entorno y, cuando el cliente es una administración, claves gestionadas por el cliente (CMEK/BYOK).

Trazabilidad del acceso al dato clínico. No basta con saber quién entró a la consola cloud: necesitas saber quién accedió a qué historia clínica, cuándo, y desde dónde. Es el audit log de acceso al dato, uno de los controles más diferencialmente exigidos en healthtech.

Notificación de brechas con umbral más bajo. El artículo 33 exige notificación a la autoridad de control en 72 horas y, según el riesgo, también a los afectados (artículo 34). Cuando el dato comprometido es de salud, el umbral para notificar a los afectados baja casi a cualquier brecha.

El mapa: regulación → control técnico → evidencia

Esta tabla es el núcleo operativo del artículo. Para cada obligación regulatoria significativa, qué control técnico la satisface en una infraestructura cloud típica y qué evidencia presentar en una auditoría o ante un cuestionario de cliente público.

Esta tabla no agota el catálogo. ENS categoría media activa del orden de un centenar de medidas; NIS2 detalla diez familias de gestión de riesgos. Pero cubre la práctica totalidad de lo que aparece en cuestionarios de cliente sanitario y en las DPIAs que la AEPD revisa con más frecuencia. Para el detalle de cómo se mapean estos controles a Anexo A de ISO 27001 sobre cloud, ese artículo cubre la traducción línea por línea.

Controles diferenciales: lo que healthtech añade sobre el RGPD genérico

Los controles que diferencian a un sistema healthtech de un SaaS B2B convencional son menos de los que parece, pero son los que más fallan en auditoría.

1. Audit log a nivel de dato clínico

El log que importa no es CloudTrail. Es un log a nivel de aplicación que registre cada lectura de una historia clínica: identificador del usuario clínico, identificador del paciente, marca temporal, IP/dispositivo, motivo declarado (si tu flujo lo permite) y resultado. Lecturas, no solo escrituras — la mayoría de incidentes de privacidad sanitaria son accesos curiosos a historias de personas conocidas, no exfiltraciones masivas.

1CREATE TABLE clinical_access_log (
2id            BIGSERIAL PRIMARY KEY,
3occurred_at   TIMESTAMPTZ NOT NULL,
4actor_user_id UUID NOT NULL,
5actor_role    TEXT NOT NULL,            -- medico_tratante, enfermeria, admin, soporte
6patient_id    UUID NOT NULL,
7resource_type TEXT NOT NULL,            -- historia, episodio, prescripcion, imagen
8resource_id   UUID NOT NULL,
9action        TEXT NOT NULL,            -- read, update, export, print
10source_ip     INET,
11request_id    UUID NOT NULL,            -- correlación con application logs
12reason_code   TEXT                      -- opcional: justificación del acceso
13);
14
15-- Inmutable a nivel de aplicación: solo INSERT, sin UPDATE/DELETE.
16-- A nivel de base de datos: REVOKE UPDATE, DELETE ON clinical_access_log FROM app_user;
17-- Replicado en almacenamiento append-only (S3 Object Lock o equivalente) para retención larga.

Este log es la primera prueba que pide cualquier auditor sanitario y la primera que pide la AEPD ante una reclamación de un paciente sobre acceso indebido. Si no lo tienes, no puedes ni confirmar ni desmentir el incidente.

2. Separación estricta entre entornos y pseudonimización

El error sancionado de forma reiterada es el mismo: equipos de desarrollo accediendo a datos clínicos reales en staging "para reproducir un bug". Está prohibido. El dato clínico solo vive en producción; cualquier entorno inferior usa datos pseudonimizados o sintéticos.

Pseudonimización efectiva implica que la re-identificación sea computacionalmente desproporcionada: no basta con sustituir nombres por hashes derivados del propio nombre. Usa identificadores aleatorios persistentes (UUID nuevo por persona, mapping en producción) y, para texto libre como notas clínicas, anonimización por NER médico antes de exportar.

3. Identidad federada y gestión de claves

Los hospitales y administraciones sanitarias casi nunca aceptan que sus profesionales se den de alta con usuario y contraseña en tu plataforma: te van a pedir SSO contra su proveedor de identidad (SAML 2.0 contra ADFS, OIDC contra Entra ID, o integración con la pasarela de identidad sanitaria autonómica). Diséñalo desde el principio — añadir SSO federado a una aplicación que asumió usuarios locales es una refactorización de meses.

En paralelo, los pliegos de cliente público cada vez con más frecuencia exigen claves gestionadas por el cliente (BYOK/CMEK): la administración aporta la clave maestra y, si la revoca, los datos quedan inaccesibles incluso para ti. Es un requisito serio de diseño que conviene anticipar.

4. Localización del dato

Aunque el RGPD no obliga a almacenamiento en la UE para datos de salud, los pliegos de cliente público suelen exigir que el dato resida en la UE o en España. Documenta la región de cada servicio cloud, evita servicios que solo existen en regiones no-UE para datos sensibles, y ten claros los flujos transfronterizos de subencargados (un proveedor de email con servidores en EE. UU. recibiendo notificaciones con dato clínico es una transferencia internacional).

ENS para healthtech: cuándo entra en juego

Si vendes solo a sector privado, ENS no te aplica directamente. En el momento en que entra el primer cliente público — un hospital del sistema, una mutua, una consejería autonómica — empieza a aplicarte por arrastre contractual: el pliego suele incluir alguna variante de "el adjudicatario garantizará que los servicios contratados cumplen el Esquema Nacional de Seguridad en la categoría correspondiente". Ahí tienes dos opciones.

Certificación ENS te abre todos los pliegos pero exige meses de adecuación y coste no trivial — suele no ser proporcional para una startup con un primer piloto público. Adecuación demostrable consiste en documentar que los servicios afectados cumplen las medidas exigidas, mantener la evidencia continua y entregarla cuando el cliente la pide; funciona para pilotos y primeros despliegues, deja de funcionar cuando el pliego exige certificación formal.

Lo que no es opcional es entender que ENS y RGPD no son sustitutivos: son acumulativos. Las medidas técnicas se solapan en muchos puntos (cifrado, accesos, logs), pero ENS añade requisitos de gobernanza, segregación funcional y trazabilidad que el RGPD no detalla con el mismo nivel.

NIS2: aplicabilidad por arrastre

NIS2 entra en juego en healthtech por dos vías. La directa: si tu organización supera los umbrales de tamaño y prestas servicios sanitarios o eres parte relevante de la cadena de suministro, te aplican las obligaciones de gestión de riesgos (artículo 21) y notificación de incidentes (artículo 23). Para la mayoría de startups en fase temprana, este caso no aplica todavía.

La indirecta es la que sí afecta a casi todas: tus clientes hospitalarios, mutuas y aseguradoras de salud sí están sometidos a NIS2 y la directiva les exige gestionar la ciberseguridad de su cadena de suministro. Esa exigencia se traslada a tus contratos como cláusulas de seguridad ampliadas, derechos de auditoría, obligaciones de notificación de incidentes en plazos cortos (24-72 horas) y, en algunos casos, evaluaciones anuales por terceros. El control técnico que más diferencia introduce NIS2 sobre lo que ya cubre el RGPD es la detección y notificación temprana: necesitas instrumentación que detecte indicadores de compromiso en horas y un runbook que arranque sin reuniones improvisadas a las tres de la madrugada de un domingo.

Errores que vemos en cuestionarios de cliente sanitario

Cuando un equipo de healthtech recibe el primer cuestionario serio de un cliente del sistema sanitario, hay un patrón de carencias que se repite. Si te ves reflejado en alguno, es momento de abordarlo antes de que el comprador te lo señale.

Audit log que solo registra escrituras. El cliente quiere saber quién leyó la historia de un paciente concreto el martes pasado a las 11:42. Si tu log solo guarda updates, no tienes respuesta. Empieza registrando lecturas con el schema de la sección anterior — es el cambio de mayor impacto regulatorio por menos código.

MFA opcional para usuarios clínicos. "Lo dejamos opcional para no entorpecer el flujo asistencial." No funciona — MFA obligatorio para todo lo que toque dato clínico, sin excepciones. Si la usabilidad sufre, invierte en factores no disruptivos (passkeys, certificado del dispositivo del hospital), no en eliminar el segundo factor.

Subencargados sin DPA o con DPA genérico. El proveedor de email transaccional, la plataforma de observabilidad, el proveedor de IA al que mandas notas clínicas para resumir: todos son subencargados. Cada uno necesita DPA alineado al artículo 28 y, para datos de salud, mención específica al régimen de categoría especial.

Política de retención inexistente. El RGPD exige plazo de conservación documentado y el sector salud tiene plazos legales largos (la Ley de Autonomía del Paciente fija mínimos para historias clínicas). Sin una política que diferencie por tipo de dato, el cuestionario te pilla.

Pentest sin foco sanitario. Un pentest genérico cumple el papel formal, pero el cuestionario sanitario suele pedir pruebas que cubran los flujos clínicos y las integraciones HL7/FHIR. Si tu último pentest se centró en el panel de administración y olvidó la API que recibe ADT, el informe se queda corto.

Cómo te ayuda Vulnerabbit

La parte de este checklist que más rápido se queda obsoleta sin instrumentación continua es la visibilidad del estado de los controles: configuraciones que se relajan en una migración, servicios que se despliegan sin pasar por los baselines, dependencias que acumulan CVEs entre auditorías, subdominios que aparecen en un PoC y se quedan publicados.

La solución de Vulnerabbit para healthtech cubre ese hueco: descubrimiento continuo de superficie expuesta, detección de configuraciones cloud que se desvían de baseline, escaneo de aplicación con foco en los patrones que más fallan en auditorías sanitarias (autorización por paciente, exposición de dato clínico en endpoints internos, cabeceras de seguridad en interfaces clínicas) y exportación de evidencia compatible con cuestionarios de cliente público y con la sección técnica de tus DPIAs. El objetivo es que el próximo cuestionario sanitario deje de ser un sprint regulatorio y pase a ser una exportación desde la plataforma de healthtech.

Conclusión

El cumplimiento técnico en healthtech no es un proyecto que se cierra con la primera certificación. Es un estado permanente de evidencia: configuraciones correctas que se mantienen, audit logs que se generan sin huecos, pruebas periódicas que se documentan, incidentes que se detectan y notifican en plazo. La regulación en España añade capas — RGPD reforzado por el artículo 9, ENS por arrastre del cliente público, NIS2 por arrastre de la cadena de suministro sanitaria, AEMPS si tu producto es dispositivo médico — pero todas ellas convergen en los mismos controles técnicos básicos aplicados con más rigor.

Si estás empezando, prioriza tres cosas en este orden: separa entornos y elimina cualquier dato clínico real fuera de producción, implementa el audit log a nivel de acceso al dato clínico, y documenta tu inventario de subencargados con sus DPAs. Con eso resuelves el 70% de los cuestionarios que recibirás del primer cliente serio. El resto se construye encima.

¿Necesitas demostrar cumplimiento sanitario sin reconstruir evidencia cada cuestionario?

La plataforma de seguridad para healthtech de Vulnerabbit automatiza la generación de evidencia técnica continua que los cuestionarios sanitarios y las auditorías ENS exigen — sin trabajo manual cada trimestre.

Lanzar escaneo gratuito → · Ver /solutions/healthtech →