HIPAA
Análisis de riesgos bajo HIPAA: el control que más sanciones genera por incumplir
18 min lectura
Imagen generada por IAEl problema no suele ser que una entidad sanitaria carezca de políticas de seguridad. El problema es que, cuando llega una inspección o se produce una brecha, no puede demostrar que sus controles nacieron de un análisis real del riesgo.
Ahí aparece el requisito de 45 CFR 164.308(a)(1), la norma administrativa de la Security Rule de HIPAA que obliga a las entidades cubiertas y a los business associates a implantar un proceso de gestión de riesgos. Su primer paso, 45 CFR 164.308(a)(1)(ii)(A), exige realizar una evaluación precisa y exhaustiva de los riesgos y vulnerabilidades para la confidencialidad, integridad y disponibilidad de la información sanitaria electrónica protegida, la conocida ePHI.
La frase parece razonable. En la práctica, es uno de los puntos donde más expedientes de la Office for Civil Rights (OCR) encuentran grietas: análisis incompletos, inventarios que no cuadran, sistemas olvidados, proveedores fuera del perímetro y riesgos que aparecen en un documento, pero no en el presupuesto ni en el plan de controles.
La trampa está en interpretar el análisis de riesgos como un entregable. No lo es. Es la explicación que conecta los activos con las amenazas, las amenazas con las consecuencias y las consecuencias con decisiones concretas. Sin esa cadena, una política de seguridad es poco más que literatura corporativa con membrete.
Qué exige realmente 45 CFR 164.308(a)(1)
La Security Rule no prescribe una herramienta concreta, una metodología única ni una puntuación universal de riesgo. Sí exige un resultado defendible. El texto de 45 CFR 164.308(a)(1)(ii)(A) utiliza cuatro conceptos que deben aparecer en el trabajo operativo:
- Confidencialidad: impedir que personas o sistemas no autorizados accedan a la ePHI.
- Integridad: evitar alteraciones o destrucciones indebidas de la información.
- Disponibilidad: asegurar que la información esté accesible para los usuarios autorizados cuando la necesiten.
- Información sanitaria electrónica protegida: la ePHI creada, recibida, mantenida o transmitida electrónicamente por la entidad cubierta o el business associate.
El análisis no se limita a localizar una base de datos. Debe abarcar dónde se crea, recibe, mantiene o transmite la ePHI; qué personas, aplicaciones y proveedores pueden acceder a ella; qué amenazas son plausibles; qué vulnerabilidades permiten que esas amenazas tengan éxito; y qué impacto tendría el incidente.
La norma también exige que el proceso sea preciso y exhaustivo. Esa exigencia importa porque deja poco margen para el análisis de escaparate. Un inventario de aplicaciones críticas que no incluye una plataforma de telemedicina, un repositorio de imágenes o una cuenta administrativa de un proveedor no es una evaluación parcial: es una evaluación defectuosa.
El apartado 45 CFR 164.308(a)(1)(ii)(B) completa el mecanismo. Tras identificar los riesgos, la entidad debe implantar medidas de seguridad suficientes para reducirlos a un nivel razonable y apropiado. HIPAA no exige riesgo cero. Exige que la organización conozca el riesgo, decida cómo tratarlo y pueda explicar por qué la decisión es razonable.
Ese matiz es importante para un CISO europeo. Un control ausente no demuestra automáticamente una infracción si la entidad ha documentado una valoración sólida, ha aceptado formalmente un riesgo residual y ha implantado medidas compensatorias. En cambio, un control aparentemente sofisticado puede ser difícil de defender si nadie puede explicar qué riesgo pretendía reducir.
Por qué el análisis acaba apareciendo en los expedientes de OCR
Las investigaciones de OCR suelen empezar por una queja, una brecha notificada o una revisión de cumplimiento. La agencia no examina únicamente si se filtraron datos. También pregunta si la entidad tenía un proceso razonable para anticipar el incidente y si actuó conforme a sus propias conclusiones.
Cuando el análisis no existe, está desactualizado o excluye sistemas relevantes, la organización pierde una de sus defensas más importantes. Ya no puede decir que el incidente fue una sorpresa completa. El regulador puede preguntar, con bastante lógica: si el sistema contenía ePHI, ¿por qué no apareció en el inventario? Si el proveedor tenía acceso remoto, ¿dónde se evaluó ese acceso? Si el ransomware paralizó la operación, ¿qué análisis justificaba el objetivo de recuperación y la estrategia de copias?
La propia OCR ha publicado durante años guías y materiales de apoyo para explicar que el análisis debe cubrir todos los sistemas y ubicaciones donde se maneja ePHI. La guía de evaluación de riesgos de HHS, publicada en 2010, no convierte el proceso en una auditoría técnica cerrada. Ofrece, en cambio, preguntas que siguen siendo incómodamente útiles: qué datos existen, quién accede a ellos, qué amenazas pueden afectarles, qué controles están implantados y qué áreas presentan vulnerabilidades.
La repetición de este patrón en acciones de cumplimiento revela algo menos espectacular que una nueva vulnerabilidad, pero más importante: muchas entidades compran controles antes de saber qué problema quieren resolver. Después intentan adaptar el análisis al producto adquirido. Es el orden inverso.
Que el análisis de riesgos aparezca con frecuencia en acuerdos y resoluciones no significa que sea posible afirmar, sin una estadística oficial homogénea, que es literalmente el incumplimiento que más sanciones genera. La conclusión defendible es otra: se trata de un requisito transversal. Cuando falla, contamina la evaluación de controles administrativos, físicos y técnicos, porque todos ellos deberían derivarse del conocimiento del riesgo.
El documento anual que no sirve para gran cosa
Uno de los errores más habituales consiste en confundir periodicidad con calidad. Una entidad prepara una evaluación cada año, la presenta al comité de riesgos y la archiva. El informe contiene una matriz de colores, varias amenazas genéricas y una puntuación media. La organización marca el control como cumplido.
Después cambia el proveedor de historia clínica, migra cargas a la nube, incorpora autenticación sin contraseña, abre un nuevo canal de telemedicina o integra un laboratorio externo. El documento permanece intacto.
HIPAA no dice que el análisis deba elaborarse exactamente una vez al año. El requisito es un proceso continuo de gestión del riesgo. Una revisión anual puede ser una buena práctica interna, pero no sustituye a una reevaluación cuando cambia el entorno tecnológico, el tratamiento de datos, la amenaza o la estructura empresarial.
La frecuencia correcta depende del perfil de riesgo. Una red hospitalaria con múltiples adquisiciones, dispositivos conectados, proveedores clínicos y migraciones constantes necesita activar revisiones por evento, no esperar al aniversario del informe. Una organización pequeña con un entorno más estable puede utilizar ciclos menos frecuentes, siempre que documente el criterio y capture los cambios relevantes.
La diferencia entre un proceso vivo y un informe ritual puede verse en los metadatos. Un análisis útil incorpora la fecha del último cambio de arquitectura, la relación de sistemas afectados, el propietario del riesgo, la decisión adoptada y la fecha de revisión. Un análisis decorativo contiene una fecha de aprobación y poco más.
El inventario de ePHI es el punto de ruptura
Un análisis no puede ser mejor que el inventario que lo alimenta. Y el inventario de ePHI rara vez coincide con el catálogo oficial de aplicaciones.
La información puede aparecer en el sistema principal de registros, pero también en exportaciones temporales, colas de integración, buzones compartidos, dispositivos de diagnóstico, plataformas de soporte, herramientas de videoconferencia, copias de seguridad, hojas de cálculo, registros de auditoría y cuentas de proveedores. En muchos entornos, el dato no desaparece cuando se elimina del sistema de origen: sobrevive en una copia, en un índice de búsqueda o en un archivo descargado por un tercero.
Un inventario defendible debe vincular al menos cuatro capas:
- Datos: categorías de ePHI, volumen aproximado, sensibilidad y periodo de conservación.
- Procesos: admisión, diagnóstico, facturación, investigación, soporte, telemedicina y cualquier flujo que cree o transmita información.
- Tecnología: aplicaciones, bases de datos, APIs, endpoints, redes, dispositivos médicos y servicios cloud.
- Intervinientes: empleados, profesionales externos, business associates, subcontratistas y cuentas privilegiadas.
La prueba práctica no es preguntar al responsable de privacidad si existe un inventario. Es seleccionar un paciente, seguir el recorrido de sus datos y comprobar cuántos sistemas, proveedores y copias aparecen en el trayecto. Si el flujo real no coincide con el diagrama aprobado, el análisis tiene un problema de alcance.
Este ejercicio también ayuda a separar HIPAA de un simple programa de protección de datos. La Privacy Rule regula usos y divulgaciones de información sanitaria protegida. La Security Rule se centra en la ePHI y en salvaguardas administrativas, físicas y técnicas. Un registro puede estar correctamente clasificado desde la perspectiva de privacidad y, aun así, carecer de controles suficientes de autenticación, logging, segmentación o recuperación.
La amenaza no es una lista de palabras
Otro defecto frecuente es copiar amenazas de una plantilla: malware, phishing, error humano, amenaza interna, desastre natural. La lista puede ser correcta y no aportar casi nada.
El análisis debe conectar la amenaza con una vía de explotación concreta. “Ransomware” no explica el riesgo. “Un atacante obtiene credenciales de un usuario de facturación mediante phishing, accede al repositorio de reclamaciones a través de una VPN sin autenticación multifactor, cifra los archivos y exfiltra una copia antes de la extorsión” sí permite evaluar controles.
La descripción operativa permite preguntar por medidas verificables: ¿hay MFA para el acceso remoto?, ¿se separan las cuentas administrativas?, ¿el repositorio está segmentado?, ¿se detecta una descarga masiva?, ¿las copias están aisladas?, ¿se ha probado la restauración?, ¿qué proveedor puede abrir una sesión de soporte?
El análisis debe contemplar amenazas externas e internas, intencionadas y accidentales. También debe incluir fallos de disponibilidad que no sean un ciberataque: caída de un proveedor cloud, error de configuración, fallo eléctrico, pérdida de conectividad o indisponibilidad de un centro de datos.
La disponibilidad recibe menos atención que la confidencialidad porque no produce siempre una “fuga” visible. En un hospital, sin embargo, que un sistema crítico no esté operativo puede afectar al tratamiento, la atención y la continuidad de los servicios. Por eso 45 CFR 164.308(a)(7) exige un plan de contingencia, mientras que 45 CFR 164.312(a)(2)(ii) contempla el mecanismo de emergencia para obtener acceso a la ePHI cuando sea necesario.
El análisis debe terminar en decisiones, no en colores
Una matriz de riesgo puede ser útil, pero el color rojo no remedia una vulnerabilidad. El análisis debe desembocar en un plan de gestión de riesgos conforme a 45 CFR 164.308(a)(1)(ii)(B).
Para cada riesgo relevante, el responsable debería poder mostrar cuatro decisiones:
- Tratamiento: mitigar, transferir, evitar o aceptar.
- Control: medida concreta, responsable y fecha prevista.
- Riesgo residual: qué exposición permanece tras aplicar el control.
- Gobernanza: quién acepta ese riesgo y bajo qué autoridad.
La aceptación de riesgo no debe convertirse en un eufemismo para “no hay presupuesto”. Si la entidad decide mantener un sistema legado sin parchear, necesita documentar la razón, la exposición, los controles compensatorios y la fecha de revisión. Puede ser una decisión razonable durante una migración. Es mucho más difícil defenderla si lleva cuatro años renovándose automáticamente.
La gestión de riesgos también debe conectarse con el presupuesto. Si el análisis identifica que la recuperación de una aplicación crítica requiere siete días, pero el negocio necesita restablecerla en ocho horas, no existe un problema de redacción. Existe una decisión empresarial pendiente: arquitectura redundante, recuperación priorizada, sustitución del sistema o aceptación formal de la interrupción.
El CISO no debería firmar en solitario estas decisiones. La dirección y los propietarios del proceso deben entender el impacto. 45 CFR 164.308(a)(2) exige asignar responsabilidad de seguridad; 45 CFR 164.308(a)(5) aborda la seguridad del personal; y 45 CFR 164.308(a)(6) exige procedimientos para responder y reportar incidentes. El análisis de riesgos debe alimentar esas funciones, no vivir separado en una carpeta de compliance.
La evidencia que OCR puede pedir
Una entidad puede haber ejecutado un análisis razonable y, sin embargo, perder credibilidad por no conservar pruebas suficientes. La documentación no es una formalidad añadida al control: es la forma de demostrar que el control existió.
45 CFR 164.316(b)(1) exige mantener las políticas, procedimientos, acciones, actividades y evaluaciones requeridas por la Security Rule durante el periodo aplicable. 45 CFR 164.316(b)(2) establece, como regla general, un periodo de conservación de seis años desde la fecha de creación o desde la fecha en que dejó de estar vigente la documentación, la que sea posterior.
Para una auditoría o una investigación, el expediente debería permitir reconstruir el razonamiento. No basta con entregar el informe final. Conviene conservar:
- el alcance aprobado y el inventario utilizado;
- diagramas de flujo de ePHI y dependencias de terceros;
- entrevistas con propietarios de sistemas y procesos;
- evidencias técnicas, como configuraciones, resultados de escaneos, revisiones de acceso y pruebas de restauración;
- la metodología de valoración y sus criterios;
- el registro de riesgos y las decisiones de tratamiento;
- la aprobación de los riesgos residuales;
- las revisiones posteriores a incidentes, cambios materiales o nuevas adquisiciones.
Hay una diferencia sustancial entre conservar documentos y conservar trazabilidad. Un informe firmado demuestra que alguien aprobó algo. Un conjunto de evidencias enlazadas demuestra qué se examinó, qué se encontró, qué se decidió y si la decisión se ejecutó.
Los terceros son parte del análisis, aunque el contrato diga otra cosa
El business associate no es una nota al pie. Si un proveedor crea, recibe, mantiene o transmite ePHI en nombre de una entidad cubierta, entra en el perímetro contractual y operativo de HIPAA. 45 CFR 164.308(b) regula las garantías de los socios comerciales y 45 CFR 164.314(a) aborda las obligaciones contractuales asociadas.
Un acuerdo de business associate no sustituye al análisis de riesgos. El contrato puede exigir salvaguardas, notificación de incidentes, cooperación y devolución o destrucción de datos. No demuestra que el proveedor tenga MFA, segregación de entornos, pruebas de recuperación o controles sobre subcontratistas.
La evaluación debe mirar el servicio concreto. Un proveedor que solo aloja una aplicación no presenta el mismo riesgo que uno que administra identidades, opera una mesa de soporte con acceso privilegiado o procesa copias completas de historias clínicas. La criticidad depende del acceso, del volumen, de la concentración y de la capacidad de la entidad para sustituirlo.
También hay que revisar el cuarto nivel de la cadena. Muchos proveedores utilizan servicios cloud, operadores de soporte o plataformas de analítica. Si la entidad no sabe quién puede acceder a la ePHI desde esos servicios, su análisis contiene un agujero de visibilidad que ningún anexo contractual arregla.
Para los responsables europeos, este punto conecta directamente con GDPR art. 28, que exige garantías suficientes del encargado y regulación de subencargados, y con GDPR art. 32, que obliga a aplicar medidas técnicas y organizativas apropiadas. En entidades financieras, el paralelismo con DORA art. 28 sobre gestión del riesgo de terceros proveedores de servicios TIC es evidente: el contrato es una pieza de control, no una prueba de que el riesgo esté gestionado.
Qué cambia para un CISO europeo que opera con HIPAA
HIPAA no se aplica por ser una norma estadounidense o por aparecer una palabra como “healthcare” en el contrato. La obligación depende del papel de la organización y de la información tratada. Una empresa europea puede quedar expuesta si actúa como business associate para una entidad cubierta estadounidense o presta servicios que manejen ePHI en su nombre.
En ese caso, el CISO debe evitar dos errores simétricos. El primero es asumir que el cumplimiento del GDPR cubre automáticamente HIPAA. El segundo es crear un programa HIPAA completamente separado, con controles duplicados, métricas distintas y dos inventarios que describen el mismo entorno.
La convergencia es posible, pero requiere mapear requisitos. GDPR art. 32 proporciona un marco basado en el riesgo para seguridad del tratamiento; GDPR art. 33 fija, para el responsable, la notificación de una violación a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que tiene constancia; GDPR art. 35 regula las evaluaciones de impacto cuando el tratamiento probablemente entrañe un alto riesgo. Ninguno de esos artículos sustituye literalmente a 45 CFR 164.308(a)(1), pero juntos pueden alimentar el mismo proceso de inventario, valoración y tratamiento.
La diferencia operativa más relevante está en el objeto y en la evidencia. HIPAA centra la Security Rule en la ePHI y en salvaguardas administrativas, físicas y técnicas. GDPR exige valorar el tratamiento de datos personales en un sentido más amplio, incluidos principios, bases jurídicas, derechos y transferencias. Un registro de actividades conforme al GDPR art. 30 ayuda, pero no es por sí solo un análisis de vulnerabilidades.
Las entidades financieras europeas tienen además una capa distinta cuando manejan datos sanitarios en seguros, prestaciones o servicios de salud corporativa. DORA, aplicable desde el 17 de enero de 2025, exige un marco de gestión del riesgo TIC en sus arts. 5 a 16, con pruebas de resiliencia digital en los arts. 24 a 27 y requisitos sobre terceros TIC en los arts. 28 a 30. El principio es familiar: identificar activos, dependencias, escenarios de interrupción y capacidad de recuperación. La cobertura jurídica no es idéntica, pero el trabajo técnico puede y debe reutilizarse.
La propuesta de reforma de la Security Rule y el mensaje que deja
El 27 de diciembre de 2024, HHS publicó una propuesta de modificación de la HIPAA Security Rule. La propuesta planteaba reforzar y hacer más prescriptivos varios controles, entre ellos el análisis de riesgos, la revisión de la tecnología y los activos, la autenticación, la respuesta a incidentes y la recuperación.
El detalle regulatorio puede cambiar antes de una regla final, por lo que no conviene tratar cada elemento de la propuesta como obligación vigente. El mensaje de supervisión, sin embargo, es claro: HHS lleva años viendo que el lenguaje flexible de “razable y apropiado” se utiliza para justificar programas que no soportan una inspección técnica seria.
Para los equipos de seguridad, la respuesta no debería consistir en esperar a la versión definitiva y después correr a adaptar plantillas. Si el análisis actual no identifica activos, amenazas, vulnerabilidades, controles, riesgo residual y responsables, ya existe una debilidad bajo el texto vigente. La reforma puede elevar la precisión exigida; no inventa la necesidad de conocer el entorno.
Cómo probar que el análisis funciona
La calidad del análisis se puede comprobar con pruebas sencillas, siempre que se hagan sobre el entorno real y no sobre una presentación preparada para la auditoría.
Primero, selecciona una aplicación que procese ePHI y pide su recorrido completo: origen de los datos, usuarios, interfaces, almacenamiento, copias, proveedores y salida del sistema. Después compara ese recorrido con el inventario y con el análisis aprobado.
Segundo, toma uno de los riesgos altos y sigue la cadena hasta el control. Si el riesgo es el robo de credenciales privilegiadas, debería existir una relación verificable con MFA, gestión de cuentas, revisión de privilegios, monitorización y respuesta. Si la única evidencia es una política de contraseñas, el tratamiento no está a la altura del escenario.
Tercero, revisa un riesgo aceptado por la dirección. Pregunta qué cambió desde la aceptación, qué controles compensatorios existen y cuándo se revisará. Los riesgos residuales envejecen mal: una aceptación razonable en 2022 puede ser indefendible tras una migración cloud o un cambio de proveedor.
Cuarto, prueba la disponibilidad. No basta con verificar que se ejecutan copias. 45 CFR 164.308(a)(7) exige procedimientos de contingencia, y la evidencia relevante es si la organización puede recuperar la información y mantener las funciones críticas dentro de los objetivos que ha definido. Una copia que nunca se restaura es una esperanza automatizada.
Quinto, comprueba el vínculo con incidentes. Cuando se produce una alerta o una brecha, el equipo debería poder actualizar el análisis de riesgos con los hechos aprendidos. Un incidente que no modifica ningún riesgo, ningún control ni ninguna prioridad presupuestaria merece una explicación.
La línea roja: analizar no es aceptar cualquier cosa
La flexibilidad de HIPAA permite adaptar los controles al tamaño, complejidad y capacidades de la organización. No permite convertir la falta de recursos en una excepción permanente. “Somos pequeños” puede explicar una arquitectura sencilla, una externalización o controles proporcionales. No explica que nadie conozca dónde está la ePHI.
Tampoco basta con invocar un estándar externo. NIST CSF 2.0, publicado en febrero de 2024, puede proporcionar una estructura útil para gobernar, identificar, proteger, detectar, responder y recuperar. NIST SP 800-30 puede ayudar a organizar evaluaciones de riesgo. ISO 27001 puede aportar un sistema de gestión. Ninguno de ellos demuestra por sí solo el cumplimiento de 45 CFR 164.308(a)(1). La herramienta es un medio; la evidencia debe responder al requisito de HIPAA.
La pregunta que debería hacerse el comité de dirección no es “¿tenemos un análisis de riesgos?”. Es más incómoda y más útil: “¿Qué decisión concreta tomamos gracias a ese análisis y qué riesgo seguimos aceptando?”. Si la respuesta no incluye sistemas, escenarios, controles, propietarios y fechas de revisión, la entidad probablemente tiene un documento, no un proceso.
Conclusión: el control que delata la madurez del programa
El análisis de riesgos bajo HIPAA no es el capítulo introductorio del programa de seguridad. Es su prueba de coherencia.
Si el inventario es fiable, los riesgos están conectados con controles, los proveedores aparecen en el mapa, las decisiones de aceptación tienen dueño y las pruebas de recuperación se ejecutan, la organización puede defender su criterio incluso cuando un control no sea perfecto. Si el análisis es genérico, antiguo o desconectado del presupuesto, cualquier investigación empezará por ahí y probablemente no terminará ahí.
Para un CISO europeo, la lección es doble. HIPAA exige una disciplina específica sobre ePHI, pero el método es reconocible: saber qué se protege, entender cómo puede fallar, decidir cuánto riesgo se acepta y demostrar que la decisión se revisa. GDPR, DORA, NIS2 y NIST pueden compartir parte de la ingeniería de control. No comparten automáticamente la prueba jurídica.
La sanción no suele empezar con una sofisticada cuestión doctrinal. Empieza con una pregunta bastante básica: “enséñeme cómo sabía usted que ese riesgo existía”. La respuesta debe estar en los datos, no en una diapositiva.