HIPAA Security Rule en 2026: la regla que muchos creen conocer y pocos han operacionalizado de verdad

La trampa de HIPAA en 2026 no es jurídica. Es operativa. Casi cualquier responsable de compliance en sanidad estadounidense sabe recitar que hay que proteger la electronic protected health information o ePHI. Bastantes menos pueden demostrar, con evidencias auditables, que su análisis de riesgos sigue vivo, que sus contratos con business associates bajan a tierra las salvaguardas técnicas y que sus controles de acceso no dependen de un Excel que nadie quiere mirar.

La última síntesis publicada por la Office for Civil Rights (OCR) del Department of Health and Human Services (HHS) no trae una revolución normativa. Tampoco pretende hacerlo. Resume la Security Rule vigente y recuerda algo incómodo para el sector: el marco actual ya impone salvaguardas administrativas, físicas y técnicas suficientes como para dejar muy poco espacio a la excusa del “no estaba claro”. El texto relevante sigue en 45 CFR Part 160 y Part 164, Subparts A y C, y la OCR remite además a su propuesta de modificación de la regla para reforzar la ciberseguridad de la ePHI. Traducido al castellano llano: la autoridad no está diciendo “quizá deberías madurar”. Está diciendo “llevas años teniendo obligaciones y ahora vamos a mirar más de cerca”.

Para quien trabaja desde Europa, HIPAA a veces se mira como una reliquia sectorial norteamericana. Error. Su arquitectura de controles sigue siendo una referencia práctica para grupos hospitalarios, aseguradoras, healthtech, processors con presencia transatlántica y proveedores de servicios tecnológicos que pisan datos sanitarios de EE. UU. Además, compararla con GDPR, NIS2 o NIST CSF 2.0 ayuda a entender qué pide exactamente y qué no. Spoiler: HIPAA es menos poética que muchos marcos corporativos internos y bastante más concreta cuando toca pedir responsabilidad.

Lo primero: qué cubre HIPAA Security Rule y por qué el matiz importa

La Security Rule protege la ePHI, no toda la información sanitaria sin más. Ese detalle, que parece académico, condiciona el alcance real del programa de cumplimiento. Hablamos de información sanitaria protegida mantenida o transmitida en formato electrónico por una covered entity o un business associate. Las covered entities incluyen, entre otras, proveedores sanitarios que transmiten información de salud en determinadas transacciones normalizadas, planes de salud y health care clearinghouses. Los business associates son terceros que crean, reciben, mantienen o transmiten PHI en nombre de una covered entity. Tras HITECH, la cosa dejó de ir solo de contratos simpáticos: muchas obligaciones de seguridad aplican directamente a esos terceros.

La base regulatoria no es difusa. La estructura está en 45 CFR 164.302 a 164.318. El corazón operativo está en 45 CFR 164.306, que fija los estándares generales de seguridad, y en 45 CFR 164.308, 164.310 y 164.312, donde se despliegan las salvaguardas administrativas, físicas y técnicas. La exigencia documental aparece en 45 CFR 164.316. Si una entidad todavía aborda HIPAA como un ejercicio de “políticas y formación anual”, ya va tarde. La regla exige implementar medidas razonables y apropiadas para asegurar confidencialidad, integridad y disponibilidad de la ePHI, proteger frente a amenazas razonablemente anticipables y frente a usos o divulgaciones no permitidos, y asegurar el cumplimiento interno por parte de la plantilla.

Ese trío clásico —confidencialidad, integridad, disponibilidad— no es casualidad. Es el mismo lenguaje que luego adoptan marcos más modernos. La ironía aquí es que muchas organizaciones presumen hoy de alineación con NIST CSF 2.0, Zero Trust o resiliencia operacional avanzada, pero siguen sin cerrar huecos básicos que HIPAA lleva señalando desde hace dos décadas.

La falsa comodidad de una norma “flexible”

OCR insiste en que la Security Rule es flexible, escalable y tecnológicamente neutral. Eso es cierto. También es el origen de muchos errores de interpretación. Flexible no significa opcional. Significa que una gran red hospitalaria, un laboratorio especializado y un proveedor SaaS de facturación médica no implementarán exactamente el mismo stack ni la misma profundidad de control, pero sí deben ser capaces de justificar por qué sus medidas son razonables y apropiadas dado su tamaño, complejidad, capacidades y perfil de riesgo.

El estándar general de 45 CFR 164.306(b) obliga a tener en cuenta al menos cuatro factores: el tamaño, complejidad y capacidades de la entidad; su infraestructura técnica, hardware y software; los costes de las medidas de seguridad; y la probabilidad y criticidad de los riesgos a la ePHI. Ese equilibrio ha generado años de lecturas interesadas. Algunas entidades han usado el argumento del coste como si fuese un salvoconducto para seguir con autenticación débil, gestión de parches reactiva o segregación de accesos improvisada. No cuela. El criterio no es “cuesta dinero, luego no”. El criterio es “demuestra que evaluaste el riesgo, valoraste alternativas y elegiste una medida razonable”. Si el riesgo es alto y la alternativa barata ya no existe, la defensa se desmorona sola.

Aquí conviene recordar otra distinción legal que suele malentenderse: la de implementaciones “required” y “addressable”. Bajo HIPAA, “addressable” no equivale a “prescindible”. Significa que la entidad debe evaluar si la especificación es una medida razonable y apropiada en su entorno y, si no la adopta tal cual, documentar por qué y qué medida equivalente usa en su lugar. Ese matiz importa especialmente en materias como cifrado o ciertos controles técnicos. Demasiados equipos oyen “addressable” y traducen “ya veremos”. OCR y los abogados litigantes suelen traducir otra cosa.

El análisis de riesgos no es una fase del proyecto: es el proyecto

Si hubiera que identificar el control más citado, más incumplido y más mal entendido de HIPAA, sería el análisis de riesgos. El requisito está en 45 CFR 164.308(a)(1)(ii)(A): risk analysis. A su lado, 45 CFR 164.308(a)(1)(ii)(B) exige la risk management. No es un formalismo. El análisis de riesgos es la condición de posibilidad del resto del programa. Sin él, no puedes justificar controles de acceso, priorizar remediaciones, segmentar terceros ni defender que tus medidas son proporcionales.

La OCR lleva años martilleando el mismo punto porque sigue encontrando la misma carencia: análisis genéricos, desactualizados o incapaces de mapear dónde reside la ePHI. Y sin inventar datos de enforcement concretos que no estén en la fuente, basta con mirar la lógica regulatoria para entender por qué: una entidad que no sabe qué sistemas contienen ePHI, cómo fluye esa información, quién accede a ella y qué amenazas son plausibles, en realidad no tiene un programa de seguridad. Tiene documentación decorativa.

Un análisis de riesgos serio bajo HIPAA en 2026 debería cubrir, como mínimo, inventario de activos y aplicaciones que crean, reciben, mantienen o transmiten ePHI; flujos de datos internos y externos; accesos privilegiados y remotos; dependencia de terceros y subcontratistas; exposición de copias de seguridad; movilidad de datos entre entornos on-prem y nube; y escenarios de indisponibilidad, no solo de fuga. Aquí es donde muchas entidades sanitarias descubren que su problema principal no es el ransomware como titular, sino la fragilidad cotidiana: cuentas compartidas, integraciones antiguas, herramientas biomédicas sin soporte o soluciones heredadas que nadie se atreve a tocar porque sostienen procesos clínicos críticos.

La comparación con NIST CSF 2.0 resulta útil. HIPAA no obliga a adoptar NIST, pero un programa maduro puede usar el CSF como estructura de gobierno y evidencia, siempre que mantenga la trazabilidad hacia 45 CFR 164.308-312. El error es hacer lo contrario: decir “cumplo NIST, por tanto cumplo HIPAA”. No. NIST puede ayudar a operacionalizar. HIPAA sigue siendo el estándar legal aplicable.

Salvaguardas administrativas: donde se decide si todo lo demás funciona

La Security Rule dedica a las salvaguardas administrativas un peso que muchos equipos técnicos infravaloran. Están en 45 CFR 164.308 y ahí se juega buena parte del partido. No porque sean abstractas, sino porque bajan a obligaciones muy concretas.

La primera es la gestión de seguridad, con análisis y gestión del riesgo. Ya está dicho. La segunda, en 45 CFR 164.308(a)(2), exige identificar a un security official responsable de desarrollar e implementar las políticas y procedimientos de seguridad. Parece obvio. No lo es. En demasiadas organizaciones sanitarias la responsabilidad se reparte entre TI, compliance, legal, operaciones clínicas y proveedores externos de forma tan difusa que, llegado un incidente, nadie manda y todos “coordinan”. Mala idea. HIPAA quiere un responsable identificable.

Luego viene la seguridad del personal en 45 CFR 164.308(a)(3). Esto no es solo alta y baja de usuarios. Incluye autorizar y supervisar el acceso a ePHI conforme al rol, y resolver procedimientos de terminación de acceso. Si tu hospital tarda días en desactivar cuentas tras una salida o cambia a personal temporal entre unidades con privilegios heredados, no tienes un problema de “IAM mejorable”; tienes un problema regulatorio y de riesgo real.

45 CFR 164.308(a)(4) aborda el acceso a la información. Pide políticas y procedimientos para autorizar el acceso a ePHI. Aquí el principio de mínimo privilegio debería ser la regla, aunque HIPAA no use esa etiqueta moderna en todos los pasajes. La cuestión práctica es otra: ¿tu modelo de roles responde al trabajo clínico real o a organigramas teóricos? Porque los excesos de acceso rara vez nacen del malismo puro. Nacen de diseños vagos, excepciones perpetuas y sistemas que no permiten granularidad sin dolor operativo.

Las obligaciones de concienciación y formación en 45 CFR 164.308(a)(5) tampoco son el típico módulo soporífero de 20 minutos. Deben incluir formación apropiada para todos los miembros de la fuerza laboral, y pueden desplegarse con elementos como recordatorios periódicos, protección frente a software malicioso, control de contraseñas y gestión del inicio de sesión. Si una organización sufre campañas de phishing recurrentes y responde con “hemos hecho la formación anual”, el regulador puede considerar que la medida no era eficaz para el riesgo conocido.

La parte de procedimientos ante incidentes, en 45 CFR 164.308(a)(6), es crítica y conecta directamente con el Breach Notification Rule. HIPAA exige identificar y responder a incidentes de seguridad conocidos o sospechados, mitigar en la medida de lo posible los efectos dañinos y documentar incidentes y resultados. No exige solo reacción. Exige trazabilidad. En lenguaje ejecutivo: si detectas un acceso anómalo a ePHI, necesitas poder mostrar quién lo vio, cuándo escaló, qué contención se aplicó, qué impacto se evaluó y cómo se cerró la incidencia.

El plan de contingencia de 45 CFR 164.308(a)(7) es probablemente uno de los bloques más subestimados. Incluye plan de respaldo de datos, plan de recuperación ante desastres, modo de operación de emergencia, pruebas y revisión de los procedimientos, y evaluación de la criticidad de aplicaciones y datos. Esto se parece mucho más a resiliencia operacional de lo que algunos creen. La salud no puede permitirse entender la seguridad solo como prevención de brechas de confidencialidad. La disponibilidad de la ePHI y de los sistemas que la soportan tiene impacto clínico. Y en 2026, con el historial del sector frente a ransomware y fallos de proveedores, esa conversación ya no admite romanticismo tecnológico.

Completa el bloque administrativo la evaluación periódica en 45 CFR 164.308(a)(8), que obliga a realizar evaluaciones técnicas y no técnicas ante cambios ambientales u operativos que afecten a la seguridad de la ePHI. Dicho sin rodeos: una evaluación de hace dos años no sirve si has migrado cargas a la nube, has integrado un nuevo EHR, has abierto acceso remoto a terceros o has desplegado IA clínica con conectores a datos protegidos.

Los terceros ya no son una nota al pie

La aportación de HITECH sigue siendo decisiva en 2026 porque endureció la posición de los business associates. Antes, muchos terceros se escondían detrás del contrato. Ahora las salvaguardas de la Security Rule aplican directamente a ellos en la medida prevista por la ley y la reglamentación. Eso cambia la conversación con proveedores de nube, facturación, analítica, almacenamiento, transcripción, soporte de aplicaciones clínicas y un largo etcétera.

El contrato de business associate no es un fetiche documental. Debe reflejar obligaciones reales sobre uso, divulgación, salvaguardas, subcontratación, notificación y terminación. Pero el contrato, por sí solo, no sustituye la diligencia debida. Si el tercero aloja o procesa ePHI, la entidad regulada debería poder responder preguntas muy concretas: qué controles de acceso aplica, cómo segrega entornos, qué cifrado usa en tránsito y en reposo, cómo gestiona logs, qué plazos contractuales maneja para notificar incidentes, si subcontrata a otros business associates, qué pruebas de continuidad realiza y cómo destruye o devuelve datos al cierre.

Aquí hay un paralelismo evidente con DORA art. 28 y siguientes sobre riesgo de terceros TIC o con GDPR art. 28 sobre encargados del tratamiento. La diferencia es sectorial y jurídica, pero la lección práctica es casi idéntica: si tu control sobre terceros termina en la firma del contrato, no controlas gran cosa. Y en salud, esa ilusión sale especialmente cara porque la cadena de suministro tecnológica suele ser más vieja, más heterogénea y más clínica de lo que el área jurídica imagina.

Salvaguardas físicas: el capítulo que muchos creen del siglo pasado hasta que llega el incidente

Las salvaguardas físicas de 45 CFR 164.310 suelen parecer menos glamourosas que la autenticación multifactor o la microsegmentación. Luego llega un robo de portátiles, un acceso no autorizado a un área restringida, un desmantelamiento chapucero de equipos o una impresora multifunción con datos persistentes, y la nostalgia se pasa rápido.

HIPAA exige políticas para limitar el acceso físico a sistemas e instalaciones y, al mismo tiempo, asegurar que el personal autorizado pueda acceder cuando sea necesario. Incluye controles sobre uso de estaciones de trabajo, seguridad de estaciones de trabajo y gestión de dispositivos y soportes. Esa última parte abarca recepción y retirada de hardware y medios electrónicos que contengan ePHI, reutilización, rendición de cuentas y copia de seguridad antes de mover equipos cuando proceda.

En un hospital moderno esto se traduce en problemas muy concretos: terminales de enfermería visibles desde zonas de paso, dispositivos biomédicos conectados con sistemas operativos heredados, carros clínicos compartidos, puestos abiertos por urgencias operativas y almacenes técnicos con disciplina mejorable. El regulador no espera perfección clínica imposible. Espera controles razonables, documentados y mantenidos. Si una entidad tiene inventario pobre de dispositivos que tratan ePHI, no podrá demostrar ni seguridad física ni continuidad ni respuesta a incidentes. Todo está conectado, por mucho que la organización siga gestionándolo en silos.

Salvaguardas técnicas: control de acceso, auditoría, integridad, autenticación y transmisión

El núcleo técnico está en 45 CFR 164.312. Aquí ya no caben muchas metáforas.

Primero, control de acceso en 45 CFR 164.312(a)(1). HIPAA exige políticas y procedimientos para permitir acceso solo a personas o software autorizados. Entre las especificaciones de implementación figuran el identificador único de usuario, el procedimiento de acceso de emergencia, la desconexión automática y el cifrado y descifrado como medida addressable. Si una entidad sigue con cuentas genéricas o compartidas para acceder a ePHI, tiene un problema frontal con la trazabilidad. Y si el acceso de emergencia existe solo de nombre, el día del incidente clínico se convertirá en una improvisación con consecuencias legales y asistenciales.

Segundo, los controles de auditoría en 45 CFR 164.312(b). La regla exige hardware, software y procedimientos para registrar y examinar la actividad en sistemas que contienen o usan ePHI. Este punto se vuelve explosivo cuando una organización descubre que genera logs, sí, pero no los revisa, no los correlaciona o no puede retenerlos el tiempo suficiente para una investigación. Registrar sin examinar sirve de poco. Es como instalar una alarma y guardar las notificaciones en una carpeta de correo que nadie abre.

Tercero, integridad en 45 CFR 164.312(c)(1). Deben existir políticas y procedimientos para proteger la ePHI frente a alteración o destrucción indebida. Esto abarca desde controles sobre edición y versionado hasta mecanismos de validación, supervisión de cambios y defensa frente a corrupción de datos. En sanidad, la integridad no es un concepto elegante para auditorías. Un dato clínico alterado, incompleto o incoherente puede afectar a decisiones asistenciales. Hay pocas formas más directas de conectar ciberseguridad con seguridad del paciente.

Cuarto, autenticación de persona o entidad en 45 CFR 164.312(d). La regla exige verificar que quien solicita acceso es quien dice ser. HIPAA no nombra MFA en ese texto histórico, pero en 2026 cuesta defender seriamente que la autenticación fuerte no es una medida razonable para accesos remotos, privilegios elevados o sistemas críticos con ePHI. De hecho, buena parte de la presión regulatoria moderna —y de la OCR en su narrativa reciente— apunta precisamente hacia el abandono de controles mínimos que hace años parecían aceptables.

Quinto, seguridad de transmisión en 45 CFR 164.312(e)(1). Se exige proteger la ePHI frente a acceso no autorizado cuando se transmite por una red electrónica. Las especificaciones mencionan controles de integridad y cifrado como medidas addressable. Otra vez: addressable no es opcional. Si una entidad transmite ePHI por canales donde el cifrado es técnicamente factible y común, la carga de justificar su ausencia roza lo temerario.

La documentación no es burocracia: es defensa

45 CFR 164.316 obliga a documentar políticas y procedimientos exigidos por la Security Rule, conservar esa documentación durante seis años desde su creación o su última fecha de vigencia, ponerla a disposición de quienes deban implementarla y revisarla periódicamente cuando cambien los procesos o el entorno. Seis años. Ese número importa. No para archivistas, sino para cualquier organización que pretenda sobrevivir a una investigación, una auditoría interna, una demanda o una compra por parte de un inversor que haga due diligence de verdad.

La documentación útil bajo HIPAA no es un PDF bonito con logotipo corporativo. Son versiones controladas, evidencias de aprobación, registros de revisiones, matrices de responsabilidad, actas de evaluación de riesgos, resultados de pruebas de contingencia, evidencias de formación, reportes de revisión de accesos, tickets de remediación, inventarios de activos y contratos de business associate alineados con el flujo real de datos. Si no existe o no se encuentra en horas, a efectos prácticos existe bastante poco.

Este punto conecta con algo que en Europa se entiende bien por experiencia con DORA, NIS2 o ISO 27001: el regulador no evalúa solo si haces cosas. Evalúa si puedes probarlas. En HIPAA, esa cultura probatoria es tan central como el control técnico.

Cómo encaja la Security Rule con Privacy Rule y Breach Notification Rule

La OCR recuerda que la Security Rule no vive sola. Complementa la Privacy Rule y la Breach Notification Rule. Esto tiene consecuencias prácticas que a menudo se gestionan mal por separación organizativa. El equipo de privacidad mira usos y divulgaciones permitidos; el equipo de seguridad mira controles; el equipo jurídico aparece cuando ya hay incidente. Esa fragmentación encarece y ralentiza la respuesta.

Cuando un incidente afecta a ePHI, la pregunta no es solo “qué sistema ha fallado”. También es “ha habido adquisición, acceso, uso o divulgación no permitidos?”, “existe compromiso de seguridad?”, “qué umbrales de notificación aplican?” y “qué documentación sustenta la evaluación?”. En el entorno HIPAA, la respuesta regulatoria al incidente exige un puente sólido entre seguridad, privacidad y legal. Si no existe, la organización puede gestionar razonablemente bien la contención técnica y hacerlo fatal en la calificación jurídica y en la notificación.

Para lectores habituados al GDPR, el paralelismo con el art. 32 sobre seguridad y el art. 33 sobre notificación de violaciones de datos personales es evidente, aunque los marcos no sean idénticos. La moraleja operativa sí se parece: la gobernanza del incidente importa tanto como el IOC inicial.

La propuesta de modificación de OCR: señal regulatoria, no ruido

La propia página de HHS deja claro que su resumen aborda la regla actualmente en vigor y remite a la Notice of Proposed Rulemaking sobre modificaciones para reforzar la ciberseguridad de la ePHI. Esa referencia es más relevante de lo que parece. No porque el resumen cambie la ley hoy, sino porque la OCR está marcando dirección. Cuando un regulador repite ciertas carencias y plantea modernizar el texto, el mensaje para el mercado es bastante transparente: lo que ayer era una expectativa de buena práctica mañana puede leerse con mucho menos margen interpretativo.

Sin entrar a afirmar requisitos finales que no estén cerrados, la lógica regulatoria es clara. La autoridad quiere acercar la regla a un paisaje de amenazas donde ransomware, acceso remoto, dependencia de terceros, servicios en nube e identidad se han convertido en vectores centrales. Quien espere a la versión final para empezar a madurar autenticación fuerte, segmentación, inventario, monitorización, restauración probada de copias y gobierno de terceros está repitiendo un clásico del compliance moderno: confundir plazo legal con tiempo real de implementación.

Y no, no basta con decir que el marco actual ya era flexible. Precisamente porque lo era, muchas organizaciones lo estiraron hasta volverlo irreconocible.

Qué deberían revisar ahora las entidades reguladas y sus proveedores

Si una entidad sanitaria o un business associate quiere saber si su programa HIPAA aguanta una mirada seria en 2026, hay una prueba simple: intenta recorrer el ciclo completo de la ePHI y pedir evidencia en cada punto. Dónde nace el dato, dónde se almacena, quién lo toca, cómo se cifra, qué logs quedan, cómo se respaldan los sistemas, cuánto tarda en revocarse un acceso, qué proveedor interviene, cómo se prueba la recuperación y quién decide en una emergencia.

Las respuestas robustas suelen compartir varios rasgos. Tienen un inventario realista, no imaginario. Distinguen claramente sistemas críticos y no críticos. Vinculan riesgos a propietarios concretos. Revisan accesos periódicamente con base en roles clínicos y operativos. Mantienen contratos de business associate actualizados con subcontratación controlada. Ejecutan pruebas de restauración, no solo validan que “hay backup”. Correlacionan eventos de seguridad y los elevan con criterios definidos. Y, detalle no menor, saben retirar tecnología obsoleta o aislarla cuando no puede retirarse.

Las respuestas débiles suenan distintas. “Eso lo lleva el proveedor”. “Tenemos una política, no sé cuándo se revisó”. “Los logs están, pero no sé quién los mira”. “Ciframos parte”. “MFA está en algunos accesos”. “El análisis de riesgos se hizo para la auditoría”. Si te reconoces en dos o tres de esas frases, ya sabes dónde está el problema.

Checklist de evidencias para auditoría

En este tema sí tiene sentido una lista, porque hablamos de obligaciones auditables y de documentación que conviene poder exhibir sin teatro. Si una organización regulada por HIPAA tuviera que preparar hoy mismo un examen interno serio, estas evidencias deberían estar localizables:

• Último análisis de riesgos de ePHI y registro de remediaciones asociado, con fecha, alcance, metodología y responsables, en línea con 45 CFR 164.308(a)(1)(ii)(A)-(B).
• Nombramiento formal del security official y descripción de responsabilidades, conforme a 45 CFR 164.308(a)(2).
• Matriz de accesos por rol, altas, bajas y revisiones periódicas de privilegios, vinculada a 45 CFR 164.308(a)(3)-(4) y 45 CFR 164.312(a).
• Plan de formación y evidencias de ejecución, incluyendo campañas o recordatorios de seguridad, según 45 CFR 164.308(a)(5).
• Procedimiento de gestión de incidentes y expedientes de incidentes cerrados con cronología, impacto, contención y lecciones aprendidas, conforme a 45 CFR 164.308(a)(6).
• Plan de contingencia, pruebas de restauración y resultados de ejercicios, en línea con 45 CFR 164.308(a)(7).
• Evaluaciones periódicas técnicas y no técnicas tras cambios relevantes, según 45 CFR 164.308(a)(8).
• Inventario de dispositivos y soportes que contienen ePHI, con evidencias de disposición segura y reutilización controlada, conforme a 45 CFR 164.310(d).
• Configuración de logs, retención y revisiones de auditoría para sistemas con ePHI, en relación con 45 CFR 164.312(b).
• Controles de autenticación, accesos de emergencia y evidencia de mecanismos de cifrado o su justificación documentada, vinculados a 45 CFR 164.312(a), (d) y (e).
• Contratos de business associate vigentes, inventario de terceros con acceso a ePHI y evaluación de sus controles.
• Repositorio documental con políticas y procedimientos versionados y conservados durante seis años, conforme a 45 CFR 164.316(b).

Una observación que suele doler: tener la política sin la evidencia de ejecución es casi tan malo como no tenerla. A veces peor, porque demuestra que la organización sabía qué debía hacer y aun así no lo hizo.

Qué puede aprender Europa de HIPAA, y qué no

HIPAA no es exportable tal cual al marco europeo. Es sectorial, estadounidense y centrado en información sanitaria protegida dentro de unas categorías jurídicas muy concretas. Pero sí ofrece lecciones útiles.

La primera es que la especialización sectorial importa. Mientras GDPR aborda datos personales de forma horizontal, HIPAA aterriza exigencias de seguridad en un sector donde disponibilidad, trazabilidad y continuidad tienen consecuencias clínicas. Europa se ha movido en esa dirección con NIS2 para sectores esenciales e importantes y con DORA para finanzas, pero sanidad sigue necesitando, en muchos Estados, más traducción operativa de alto detalle y menos retórica de principios.

La segunda es que la documentación bien atada da al regulador una palanca formidable. HIPAA exige conservar documentación seis años. En la práctica, esto disciplina programas que de otro modo serían mucho más declarativos. Quien trabaja en cumplimiento sabe que los marcos se vuelven reales cuando obligan a evidenciar decisiones, excepciones y revisiones.

La tercera lección es más incómoda. La neutralidad tecnológica funciona mientras el regulador mantiene presión interpretativa suficiente. Si no, el mercado rellena los huecos con mínimos perezosos. La OCR parece bastante consciente de ese problema, de ahí su impulso modernizador.

Lo que Europa no debería copiar es la confianza en que un marco flexible, por sí mismo, forzará madurez homogénea. No lo ha hecho en EE. UU. y tampoco lo hace aquí. La flexibilidad es útil. El autoengaño también se vuelve flexible. Muchísimo.

La cuestión decisiva para 2026

La pregunta no es si tu organización “cumple HIPAA” en abstracto. Esa formulación ya huele a presentación comercial. La pregunta útil es otra: si mañana OCR pide ver cómo proteges la ePHI en un flujo concreto, desde la captura hasta la recuperación en emergencia, ¿puedes enseñarlo sin improvisar?

Si la respuesta es sí, probablemente tu programa no sea perfecto, pero está vivo. Si la respuesta depende de reunir a cinco áreas, pedir favores a dos proveedores y rezar para que alguien encuentre la versión correcta de la política, tienes un problema mucho más serio que una brecha potencial de auditoría.

La Security Rule sigue vigente, sigue siendo menos opcional de lo que algunos departamentos quisieran y sigue dialogando bastante bien con los problemas reales de ciberseguridad y continuidad en sanidad. Eso, por cierto, es lo más llamativo del resumen de HHS OCR: no necesita inventarse nada nuevo para recordar al sector que los deberes esenciales llevan escritos desde hace años.

Y ese es precisamente el problema.