HIPAA: cuándo obliga a una empresa española

HIPAA obliga a una empresa española cuando trata información sanitaria por cuenta de un cliente estadounidense. No es cuestión de territorio: entras como business associate y las salvaguardas te alcanzan a ti, no solo al hospital.
Te ha llegado un business associate agreement para firmar
El correo suele llegar con el contrato principal cerrado y un anexo de veinte páginas en inglés al final. Dentro hay obligaciones de seguridad, plazos de notificación y un derecho de auditoría a favor del cliente. No se negocia casi nunca. Se firma o no hay contrato.
Ese anexo es el business associate agreement, y es lo que mete a una empresa de Zaragoza o de Valencia dentro de un régimen sanitario estadounidense. Antes de firmarlo conviene saber qué parte de lo que promete ya está hecha, porque el cliente lo va a comprobar y suele hacerlo con una lista de preguntas técnicas.
Cuándo alcanza HIPAA a una empresa española
HIPAA alcanza a una empresa española cuando presta un servicio a una entidad cubierta de Estados Unidos, esto es un hospital, una aseguradora o un proveedor sanitario, y en ese servicio trata información de pacientes. El servidor puede estar en Madrid. No cambia nada.
Pasa más de lo que parece. Una empresa de software clínico, un laboratorio de análisis, un servicio de transcripción médica o un proveedor de alojamiento acaban firmando el anexo casi siempre. Y la cadena no termina ahí: el 45 CFR 160.103 define como business associate también al subcontratista «que crea, recibe, mantiene o transmite información sanitaria protegida por cuenta del business associate». La obligación baja por la cadena de proveedores hasta el último.
El contrato no es lo único que te obliga
La creencia más extendida es que HIPAA obliga a través del contrato y que lo que el anexo no pida no hace falta. El texto de la norma dice otra cosa. La subparte C del 45 CFR 164 arranca cada bloque de salvaguardas con la misma fórmula, «A covered entity or business associate must», así que las obligaciones son directas y no reflejas.
La diferencia se nota en la práctica. Un anexo mal redactado no rebaja lo que la norma pide, y el cliente lo sabe. Por eso la diligencia previa pregunta por controles concretos y por fechas, no por la firma del anexo.
Qué pide la Security Rule
La Security Rule organiza las salvaguardas en tres bloques, y dentro de cada estándar hay especificaciones de implementación marcadas como Required o Addressable.
- › Administrativas: análisis de riesgo, gestión de accesos, formación del personal y plan de contingencia.
- › Físicas: control de acceso a las instalaciones y a los equipos donde vive la información.
- › Técnicas: control de acceso, registros de auditoría, integridad, autenticación y seguridad de la transmisión.
Las cinco salvaguardas técnicas del 45 CFR 164.312 son las que se comprueban una a una en una auditoría. De las cinco, los registros de auditoría son los que más veces encontramos a medias: hay logs del inicio de sesión y no del acceso al dato, y nadie los revisa. Un registro que nadie mira solo ocupa disco.

Direccionable no quiere decir opcional
Una especificación direccionable no se puede saltar sin más. El 45 CFR 164.306(d) obliga a evaluarla, y si se decide no implantarla, a documentar por qué no es razonable en ese entorno y qué medida equivalente se pone en su lugar. Esa documentación forma parte del expediente que se enseña.
Lo dice el propio Department of Health and Human Services sin rodeos. En la propuesta de reforma de la Security Rule que publicó en el Registro Federal el 6 de enero de 2025 escribe que «none of the implementation specifications were optional» y que lo direccionable solo daba a cada entidad la posibilidad de decidir si esa medida concreta era razonable y apropiada para ella. El plazo de comentarios se cerró el 7 de marzo de 2025.
Merece la pena comprobar en qué versión de la norma estás antes de dar por buena una lista de medidas descargada de cualquier sitio. El HHS justifica el endurecimiento con una cifra suya: en esa misma propuesta afirma que el coste de una brecha de datos sanitarios ha subido más de un 50 % desde 2020 y ronda los 10,1 millones de dólares de media, por encima de cualquier otro sector.
El análisis de riesgo es lo primero que te van a pedir
El análisis de riesgo del 45 CFR 164.308(a)(1)(ii)(A) está marcado como Required y sostiene todo lo demás. Hay que identificar dónde vive la información sanitaria, qué amenazas la afectan, con qué probabilidad e impacto, y qué medida se adopta para cada una.
La norma espera que se revise cuando cambia el sistema, y no una vez al año por calendario. Un sistema con despliegues semanales cambia todas las semanas. Un análisis fechado hace dos años, con un inventario que ya no coincide con lo que hay desplegado, es el hallazgo más fácil de levantar en una revisión de cliente. Lo levantan siempre.

Qué pasa cuando hay una brecha, y por qué el cifrado cambia la respuesta
La Breach Notification Rule da 60 días naturales como máximo desde el descubrimiento para notificar a los afectados. El 45 CFR 164.404 aclara que el reloj empieza el primer día en que la entidad conoció la brecha o habría debido conocerla actuando con diligencia razonable. Al HHS se le notifica a la vez si afecta a 500 personas o más; por debajo de 500, en un registro anual que se envía dentro de los 60 días siguientes al cierre del año.
El cifrado cambia la respuesta entera, y esta es la parte que más rentabilidad tiene. La regla solo se dispara con unsecured protected health information, que el 45 CFR 164.402 define como la que no ha quedado «inutilizable, ilegible o indescifrable» mediante una tecnología reconocida por el Secretario. Información cifrada conforme a esa guía no genera una notificación. Por eso el cifrado en reposo, que en la lista figura como direccionable, se paga solo.

RGPD y HIPAA a la vez: qué trabajo se aprovecha y qué no
Si entre los pacientes hay europeos, el RGPD obliga igual y no queda desplazado por HIPAA. Los datos de salud son categoría especial del artículo 9, y la notificación de brechas del artículo 33 corre por su cuenta, con su plazo y su autoridad. Contamos qué hacer en esas primeras 72 horas en otro artículo, porque el calendario es distinto del estadounidense y los dos pueden correr a la vez.
| Qué | RGPD | HIPAA |
|---|---|---|
| Qué activa la obligación | Tratar datos de personas que están en la UE | Prestar servicio a una entidad cubierta de Estados Unidos |
| Plazo de notificación de brecha | 72 horas a la autoridad de control (artículo 33) | 60 días naturales a los afectados (45 CFR 164.404) |
| A quién se avisa primero | A la autoridad de control, y a los afectados si el riesgo es alto | A los afectados, y al HHS a la vez si son 500 o más |
| Documento del que se parte | Registro de actividades de tratamiento | Análisis de riesgo del 45 CFR 164.308(a)(1)(ii)(A) |
| Quién supervisa | La AEPD en España | La Office for Civil Rights del HHS |
El trabajo técnico se aprovecha casi entero. Control de acceso, cifrado, registro y revisión de logs y gestión de vulnerabilidades sirven para los dos regímenes. Lo que no se aprovecha es el papel. Un registro de actividades de tratamiento no es un análisis de riesgo de la Security Rule, y presentarlo como si lo fuera es la forma más rápida de que la diligencia previa se alargue un mes.
Qué no merece la pena que pagues todavía
No hay certificación HIPAA. En el 45 CFR no existe un procedimiento de certificación ni un organismo que emita un sello, así que lo que se vende con ese nombre es la atestación de una consultora privada y vale lo que valga para tu cliente. Pregúntale qué acepta antes de pagarla. Muchas veces responde que le basta con el análisis de riesgo y un informe técnico reciente.
Tampoco hace falta montar un sistema de gestión completo porque haya entrado un contrato. Si ese mismo cliente pide además un informe SOC 2, entonces sí conviene sentarse a decidir el marco antes de gastar dos veces en lo mismo.
Qué enseñas en la diligencia previa
Lo que pide un cliente estadounidense antes de firmar es corto y se repite bastante de un cliente a otro.
- › El análisis de riesgo, con su fecha y el inventario de sistemas que usó.
- › La política de accesos y quién tiene acceso hoy a datos de pacientes.
- › El informe técnico más reciente sobre el sistema que trata la información, con la fecha de la prueba.
- › Qué está cifrado, en tránsito y en reposo, y con qué.
De esa lista, la prueba técnica es la única que no se redacta en una tarde. En Pentesting Team esa prueba es un pentesting de aplicaciones web manual contra OWASP WSTG, parte de 1.140 €, lleva de una a tres semanas y se entrega con cada hallazgo acompañado de su evidencia y de los pasos para reproducirlo, más el retest a los seis meses incluido. Tu equipo puede comprobarlo sin llamarnos, y eso es lo que el cliente quiere leer.
Si la información también viaja por correo, y casi siempre viaja, la auditoría de Microsoft 365 parte de 450 € y revisa el MFA, el acceso condicional y los permisos concedidos a aplicaciones de terceros. La gama completa va de 450 € a 1.520 € según el tipo de auditoría. El informe se acompaña de la presentación que usamos para explicar los resultados a dirección, que suele ser quien firma el contrato al otro lado. Sobre qué debe traer ese documento, escribimos lo que tiene que incluir un informe de pentesting.
El lunes por la mañana, antes de contestar al anexo, mira dos fechas: la del último análisis de riesgo y la de la última prueba técnica sobre el sistema que trata datos de pacientes. Si alguna pasa del año, esa es la primera que te va a pedir el cliente, y la que más tarda en conseguirse.
Fuentes
Cómo lo abordamos
Los servicios con los que resolvemos lo que cuenta este artículo:
- ›Pentesting de aplicaciones web · Pentesting manual de tu aplicación web contra OWASP WSTG: la lógica de negocio rota y los accesos que no deberían existir.
- ›Auditoría de infraestructura interna · Pentesting desde dentro de tu red, como quien ya ha entrado: movimiento lateral, escalada de privilegios y hasta dónde se llega en el dominio.
- ›Auditoría de Microsoft 365 · Auditoría de tu tenant de Microsoft 365 contra los CIS Benchmarks: MFA, acceso condicional y los permisos concedidos a aplicaciones de terceros.