Requisitos de Cumplimiento HIPAA: La Guía Completa, Actualizada con los Cambios a la Regla de Seguridad de 2025
La Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA, por sus siglas en inglés) establece los estándares federales para proteger la información de salud de los pacientes en todas las organizaciones que la crean, reciben, mantienen o transmiten. El cumplimiento de HIPAA no es una simple lista de verificación: es un marco compuesto por cuatro reglas interrelacionadas que regulan la privacidad, la seguridad, la notificación de brechas y el tratamiento de datos, tanto para las entidades cubiertas que atienden directamente a los pacientes como para los socios comerciales que las respaldan.
Entender qué exige realmente HIPAA —no solo que existe— es el punto de partida para construir un programa de cumplimiento capaz de resistir el escrutinio de la OCR. Esta guía cubre las cuatro reglas, las actualizaciones propuestas para la Regla de Seguridad en 2025 —que representan la revisión más significativa en más de una década—, la estructura de sanciones por incumplimiento y lo que las organizaciones deben implementar para satisfacer cada requisito en la práctica.
Resumen Ejecutivo
Idea principal: El cumplimiento de HIPAA requiere satisfacer cuatro reglas —Privacidad, Seguridad, Notificación de Brechas y Ómnibus— en los ámbitos administrativo, físico y técnico. Tanto para entidades cubiertas como para socios comerciales, cumplir no significa solo implementar controles, sino mantener evidencia documentada de que esos controles funcionan. Si se finalizan, las enmiendas propuestas a la Regla de Seguridad 2025 harán obligatorios el cifrado, la autenticación multifactor y la segmentación de red para todas las entidades cubiertas y socios comerciales, eliminando la flexibilidad de las medidas “direccionables” en la que muchas organizaciones se apoyaban históricamente.
Por qué te debería importar: Solo en 2024, la Oficina de Derechos Civiles (OCR) resolvió 63 acciones de cumplimiento, con sanciones que oscilaron entre decenas de miles y decenas de millones de dólares. Por decimocuarto año consecutivo, el sector salud fue la industria con más filtraciones de datos. La postura de la OCR ha pasado de ser reactiva —responder a reportes de brechas— a ser proactiva, con un programa activo de auditorías dirigido a entidades cubiertas y socios comerciales, haya o no ocurrido una filtración. El estándar de cumplimiento de HIPAA no consiste en tener un programa sobre el papel, sino en poder demostrar que funciona cuando la OCR lo solicita.
Puntos Clave
1. HIPAA se aplica por igual a entidades cubiertas y socios comerciales.
Desde la Regla Ómnibus de 2013, los socios comerciales —los proveedores, servicios en la nube, empresas de facturación y socios tecnológicos que manejan PHI en nombre de las entidades cubiertas— enfrentan los mismos requisitos de cumplimiento de HIPAA y la misma exposición a sanciones que las organizaciones de salud a las que sirven. La ley exige un Acuerdo de Socio Comercial (BAA), pero este no sustituye a los controles técnicos. Un BAA que asigna obligaciones de cumplimiento sin el cifrado, los controles de acceso y el registro de auditoría que las respalden es solo un documento contractual con una postura de seguridad inaplicable.
2. Las enmiendas propuestas a la Regla de Seguridad 2025 eliminan la válvula de escape de las medidas “direccionables”.
Bajo la Regla de Seguridad original de HIPAA, las salvaguardas se clasificaban como “obligatorias” o “direccionables”. Las obligatorias debían implementarse sin excepción. Las direccionables debían implementarse, salvo que la entidad cubierta pudiera documentar una alternativa razonable. En la práctica, muchas organizaciones usaron esta clasificación para posponer el cifrado y otros controles. Las enmiendas propuestas en 2025 eliminan por completo esta distinción, haciendo obligatorios el cifrado en reposo y en tránsito, la autenticación multifactor, la segmentación de red y varias otras salvaguardas para todas las entidades cubiertas y socios comerciales, sin posibilidad de documentar alternativas.
3. La evaluación de riesgos es obligatoria, no opcional, y debe estar actualizada.
La Regla de Seguridad de HIPAA exige que las entidades cubiertas y los socios comerciales realicen una evaluación precisa y exhaustiva de los riesgos y vulnerabilidades potenciales para la confidencialidad, integridad y disponibilidad de la ePHI. La OCR ha sido explícita en sus acciones de cumplimiento: un análisis de riesgos realizado años atrás y nunca actualizado no satisface este requisito. Una evaluación de riesgos de HIPAA no es un ejercicio único: debe revisarse y actualizarse periódicamente, y siempre que se produzcan cambios operativos o del entorno significativos.
4. Las relaciones con socios comerciales amplían tu perímetro de cumplimiento —y tu responsabilidad—.
Todo proveedor, servicio en la nube o socio tecnológico que accede, almacena o transmite PHI en tu nombre es un socio comercial. Sus fallos de seguridad se convierten en tu exposición al incumplimiento. Bajo HIPAA, las entidades cubiertas deben implementar salvaguardas técnicas y contractuales que regulen cómo los socios comerciales manejan la PHI, y esas salvaguardas deben aplicarse operativamente, no limitarse a quedar documentadas en un BAA. Las enmiendas propuestas en 2025 refuerzan los requisitos de supervisión de socios comerciales, incluyendo auditorías anuales y plazos más estrictos para la notificación de incidentes.
5. Los registros de auditoría son infraestructura obligatoria, no funciones de reporte opcionales.
El estándar de Controles de Auditoría de la Regla de Seguridad de HIPAA (45 C.F.R. § 164.312(b)) exige que las entidades cubiertas y los socios comerciales implementen mecanismos para registrar y examinar la actividad en los sistemas que contienen ePHI. No son requisitos flexibles: las acciones de cumplimiento de la OCR citan con frecuencia registros de auditoría incompletos o inexistentes como violaciones de la Regla de Seguridad. Un registro de auditoría que capture quién accedió a la PHI, cuándo, desde qué sistema, bajo qué autorización y con qué resultado es tanto el mecanismo de detección de incidentes de seguridad como la evidencia que demuestra el cumplimiento cuando llega una auditoría.
A Quién se Aplica HIPAA
HIPAA se aplica a dos categorías de organizaciones: entidades cubiertas y socios comerciales.
Las entidades cubiertas son proveedores de salud que transmiten información de salud electrónicamente (hospitales, consultorios médicos, clínicas, farmacias), planes de salud (aseguradoras, HMO, planes de salud patrocinados por empleadores) y cámaras de compensación de salud que procesan información de salud de un formato a otro.
Los socios comerciales son organizaciones que realizan funciones o actividades en nombre de una entidad cubierta que implican el uso o la divulgación de PHI. Esto incluye proveedores de servicios en la nube que almacenan ePHI, proveedores de servicios administrados que gestionan sistemas de TI de salud, empresas de facturación, servicios de transcripción, asesores legales, contadores y cualquier plataforma tecnológica por la que fluya PHI. Desde la Regla Ómnibus de 2013, los socios comerciales enfrentan la misma exposición a sanciones que las entidades cubiertas por infracciones: la designación de socio comercial no crea un colchón de protección frente al cumplimiento.
Las organizaciones que no crean, reciben, mantienen ni transmiten PHI generalmente no están sujetas a HIPAA. Pero el umbral para ser considerado socio comercial es más bajo de lo que la mayoría de las organizaciones asume. Un proveedor de almacenamiento en la nube que aloja PHI cifrada —incluso sin capacidad de acceder a ella— es un socio comercial bajo HIPAA y debe firmar un BAA e implementar las salvaguardas adecuadas.
Las Cuatro Reglas de HIPAA
La Regla de Privacidad
La Regla de Privacidad de HIPAA establece estándares nacionales para proteger la información de salud individualmente identificable, definiendo qué constituye Información de Salud Protegida (PHI), quién puede usarla o divulgarla, bajo qué circunstancias y con qué derechos para el paciente.
La PHI es cualquier información relacionada con la condición de salud pasada, presente o futura de una persona, la prestación de atención médica o el pago de la atención médica, y que pueda identificar a esa persona. Los 18 identificadores de HIPAA abarcan desde nombres y fechas hasta datos geográficos e identificadores de dispositivos. Los datos desidentificados —a los que se les han eliminado los 18 identificadores mediante un método aprobado— quedan fuera del alcance de HIPAA.
La Regla de Privacidad permite el uso y la divulgación de PHI para tratamiento, pago y operaciones de atención médica sin autorización del paciente. Exige autorización para la mayoría de las demás divulgaciones. Los pacientes tienen derecho a acceder a su propia PHI, solicitar modificaciones, recibir un registro de las divulgaciones realizadas y solicitar restricciones de uso. El estándar de Mínimo Necesario exige que las entidades cubiertas y los socios comerciales limiten el acceso a la PHI al mínimo necesario para cada propósito específico, un requisito que se aplica por igual al acceso humano y al acceso de sistemas de IA.
Para un desglose detallado de los requisitos de Mínimo Necesario y la implementación de accesos basados en roles, consulta Regla de Mínimo Necesario de HIPAA: Guía Completa de Cumplimiento.
La Regla de Seguridad
La Regla de Seguridad de HIPAA establece estándares nacionales para proteger la PHI electrónica (ePHI) —la PHI que se crea, recibe, mantiene o transmite en formato electrónico—. Exige que las entidades cubiertas y los socios comerciales implementen salvaguardas administrativas, físicas y técnicas que garanticen la confidencialidad, integridad y disponibilidad de la ePHI.
Las salvaguardas administrativas son las políticas, procedimientos y programas de capacitación que rigen cómo una organización gestiona la seguridad de la ePHI. Incluyen el proceso de gestión de seguridad (análisis y gestión de riesgos), la capacitación del personal, la gestión de accesos, la planificación de contingencias y la supervisión de socios comerciales. La Regla de Seguridad exige designar un Oficial de Seguridad responsable de desarrollar e implementar las políticas y procedimientos de seguridad.
Las salvaguardas físicas regulan el acceso a los sistemas y instalaciones físicas donde reside la ePHI. Incluyen controles de acceso a las instalaciones, políticas de uso de estaciones de trabajo, seguridad de las estaciones de trabajo y controles de dispositivos y medios que abarcan cómo se maneja, traslada y desecha el material electrónico que contiene ePHI.
Las salvaguardas técnicas son los controles basados en tecnología que protegen la ePHI y regulan el acceso a ella. Incluyen controles de acceso (identificación única de usuario, cierre de sesión automático, cifrado y descifrado), controles de auditoría, controles de integridad (que garantizan que la ePHI no se altere ni destruya indebidamente) y seguridad en la transmisión (protección de la ePHI transmitida por redes de comunicación electrónica).
Para el detalle completo de las salvaguardas técnicas, consulta Requisitos de la Regla de Seguridad de HIPAA y Actualizaciones 2025.
La Regla de Notificación de Brechas
La Regla de Notificación de Brechas de HIPAA exige que las entidades cubiertas notifiquen a las personas afectadas, al HHS y, en algunos casos, a los medios de comunicación, tras una filtración de PHI sin proteger. Los socios comerciales deben notificar a la entidad cubierta sin demora injustificada y a más tardar 60 días después de descubrir la filtración.
El plazo de notificación para las entidades cubiertas es estricto: las personas afectadas deben ser notificadas sin demora injustificada y a más tardar 60 días después del descubrimiento. Las filtraciones que afectan a 500 o más personas en un mismo estado o jurisdicción también requieren notificación a medios de comunicación relevantes. Todas las filtraciones deben reportarse al HHS: las que afectan a 500 o más personas deben reportarse dentro de los 60 días posteriores al descubrimiento; las de menor tamaño pueden reportarse anualmente.
La PHI que estaba cifrada en el momento de una filtración —y cuyas claves de cifrado permanecieron seguras— califica para el puerto seguro (“safe harbor”) de la Regla de Notificación de Brechas. Los datos cifrados se consideran “inutilizables, ilegibles o indescifrables” y no activan los requisitos de notificación. Este puerto seguro es una de las razones operativamente más significativas para implementar el cifrado: una filtración de PHI correctamente cifrada no constituye una brecha reportable bajo HIPAA. Para el análisis completo del puerto seguro por cifrado, consulta Cifrado AES-256 para HIPAA: Guía del Puerto Seguro ante Brechas.
La Regla Ómnibus
La Regla Ómnibus de 2013 introdujo varios cambios estructurales en HIPAA que siguen vigentes. El más significativo fue extender las obligaciones plenas de cumplimiento de HIPAA y la exposición a sanciones a los socios comerciales y sus subcontratistas, cerrando el vacío de responsabilidad que antes permitía a los proveedores intermedios operar bajo requisitos menos estrictos. También reforzó los derechos de los pacientes (incluido el derecho a solicitar copias de la ePHI contenida en registros de salud electrónicos), limitó el uso de PHI con fines de marketing y prohibió la venta de PHI sin autorización del paciente.
Las Enmiendas Propuestas a la Regla de Seguridad 2025
En enero de 2025, el HHS propuso la revisión más significativa de la Regla de Seguridad de HIPAA desde su publicación original. Las enmiendas propuestas responden al aumento de filtraciones de datos y ataques de ransomware en el sector salud, que expusieron las brechas creadas por la implementación inconsistente de la clasificación “direccionable” de la regla original.
El cambio central: las enmiendas propuestas eliminan la distinción entre especificaciones de implementación “obligatorias” y “direccionables”. Bajo la regla enmendada, las siguientes salvaguardas serían obligatorias para todas las entidades cubiertas y socios comerciales, sin posibilidad de documentar alternativas:
Cifrado de ePHI en reposo y en tránsito. Tanto el cifrado en reposo (que abarca la ePHI almacenada en bases de datos, sistemas de archivos y medios de respaldo) como el cifrado en tránsito (que abarca la ePHI transmitida por cualquier red electrónica) serían obligatorios. Las enmiendas propuestas hacen referencia a estándares de cifrado validados por FIPS, convirtiendo de hecho a los módulos criptográficos validados bajo FIPS 140-3 en el estándar de implementación exigido.
Autenticación multifactor. La MFA sería obligatoria para todo acceso a sistemas que contengan ePHI. La autenticación de un solo factor basada en contraseñas ya no satisfaría los requisitos de la Regla de Seguridad.
Segmentación de red. Las entidades cubiertas y los socios comerciales estarían obligados a implementar controles de red que aíslen los sistemas que contienen ePHI de otros segmentos de la red, limitando el movimiento lateral en caso de una filtración.
Inventarios anuales de activos tecnológicos. Las organizaciones estarían obligadas a mantener inventarios actualizados de todos los activos tecnológicos que acceden, almacenan o transmiten ePHI, un requisito fundamental para una evaluación de riesgos y una respuesta a incidentes precisas.
Análisis de riesgos documentado con requisitos de alcance específicos. Las enmiendas propuestas hacen más específico el requisito de análisis de riesgos, definiendo qué debe incluir y exigiendo a las organizaciones documentar los riesgos identificados, su probabilidad e impacto, y los controles implementados para abordarlos.
Planes escritos de respuesta a incidentes y recuperación ante desastres con capacidad de restauración en 72 horas. Las organizaciones estarían obligadas a mantener planes documentados para responder a incidentes de seguridad y restaurar sistemas dentro de las 72 horas posteriores a una interrupción.
Auditorías anuales de cumplimiento y supervisión reforzada de proveedores. Las enmiendas propuestas refuerzan los requisitos de supervisión de socios comerciales, incluyendo disposiciones contractuales para la verificación anual del cumplimiento.
Hasta julio de 2026, estas enmiendas siguen en forma de propuesta: el proceso formal de elaboración normativa continúa en curso. Las organizaciones no deberían esperar a la publicación final para comenzar a implementarlas. Los cambios propuestos reflejan la postura de aplicación de la OCR independientemente de su estatus formal, y la legislación HISAA de 2025, presentada por los senadores Wyden y Warner, impondría requisitos aún más estrictos si se aprueba. Para conocer el estado actual de estas propuestas, consulta Requisitos de la Regla de Seguridad de HIPAA y Actualizaciones 2025.
Sanciones y Aplicación de HIPAA
Las infracciones de HIPAA conllevan sanciones civiles y penales que se escalan según la gravedad y la intencionalidad del incumplimiento.
Las sanciones civiles se escalan según el conocimiento y la culpabilidad. Las organizaciones que desconocían la infracción enfrentan un mínimo de 100 dólares por incidente. Las infracciones con causa razonable pero sin negligencia intencional conllevan un mínimo de 1,000 dólares por incidente. La negligencia intencional que se corrige conlleva un mínimo de 10,000 dólares por incidente. La negligencia intencional que no se corrige conlleva un mínimo de 50,000 dólares por incidente. Los topes anuales por categoría de infracción son de 25,000 dólares para el nivel más bajo y de 1.5 millones de dólares para el más alto, aunque la OCR ha interpretado este tope por año calendario y por tipo de infracción, lo que significa que el incumplimiento sostenido durante varios años multiplica significativamente la exposición.
Las sanciones penales se aplican a infracciones cometidas con conocimiento y son procesadas por el Departamento de Justicia. Obtener o divulgar PHI a sabiendas en violación de HIPAA conlleva multas de hasta 50,000 dólares y hasta un año de prisión. Las infracciones cometidas bajo pretextos falsos elevan el límite a 100,000 dólares y cinco años. Las infracciones con intención de vender, transferir o usar PHI para obtener una ventaja comercial o beneficio personal conllevan multas de hasta 250,000 dólares y hasta diez años de prisión.
Las acciones de cumplimiento de la OCR han abarcado cada vez más a organizaciones de todo el espectro del sector salud, no solo grandes sistemas de salud, sino también consultorios médicos, planes de salud y socios comerciales. Los Planes de Acción Correctiva que acompañan los acuerdos suelen imponer obligaciones de monitoreo de varios años y mejoras obligatorias al programa de cumplimiento que se extienden mucho más allá de la sanción inicial.
Cómo Construir una Arquitectura Técnica Compatible con HIPAA
Los requisitos de salvaguardas técnicas de la Regla de Seguridad se traducen en un conjunto específico de capacidades de plataforma que las entidades cubiertas y los socios comerciales deben implementar. La brecha entre contar con herramientas individuales que satisfacen requisitos individuales y contar con una arquitectura unificada que los satisface todos simultáneamente es donde la mayoría de las organizaciones acumulan riesgo de incumplimiento.
Cifrado en todos los canales. La ePHI se mueve por más canales de los que la mayoría de las organizaciones contabilizan: correo electrónico, uso compartido de archivos, transferencia gestionada de archivos, formularios web, integraciones de API y, cada vez más, sistemas de IA que acceden a datos clínicos. Cada canal debe implementar cifrado AES-256 en reposo y TLS 1.2 como mínimo (con TLS 1.3 preferido) en tránsito. Los canales que cifran algunos flujos de PHI pero no otros generan brechas en el puerto seguro: una filtración de PHI sin cifrar a través de un canal desprotegido activa la notificación de brecha, sin importar qué tan bien protegidos estén los demás canales. Para una lista de verificación de registros de auditoría, consulta Registros de Auditoría de HIPAA: Requisitos Completos.
Controles de acceso que aplican el Mínimo Necesario. Los controles de acceso técnicos deben limitar el acceso a la ePHI al mínimo necesario para cada propósito específico. El control de acceso basado en roles (RBAC) establece qué personal puede acceder a qué categorías de PHI. El control de acceso basado en atributos (ABAC) aplica políticas dinámicas y sensibles al contexto que hacen cumplir el Mínimo Necesario a nivel de operación, no solo a nivel de cuenta. La identificación única de usuario, la terminación automática de sesión y los procedimientos de acceso de emergencia son requisitos adicionales de salvaguarda técnica.
Registro de auditoría inmutable en todos los sistemas que manejan ePHI. Los registros de auditoría deben capturar cada evento de acceso: quién accedió a qué PHI, cuándo, desde qué sistema, bajo qué autorización y qué acción realizó. Los registros deben almacenarse en un formato que no pueda alterarse después de generado. Las organizaciones con registros fragmentados entre sistemas de correo electrónico, plataformas de uso compartido de archivos, módulos de auditoría de EHR e infraestructura de red no pueden producir un registro de auditoría coherente para una revisión de la OCR, razón por la cual el registro consolidado y multicanal es un requisito práctico de cumplimiento, no solo una buena práctica.
Gobernanza técnica de socios comerciales. La ley exige un BAA. La Regla de Seguridad exige controles técnicos que regulen a qué PHI pueden acceder los socios comerciales, que registren su acceso en el mismo rastro de auditoría que el de los usuarios internos, y que revoquen el acceso cuando finaliza la relación. La obligación de cumplimiento sigue a los datos: la PHI que reside en el entorno de un socio comercial sigue siendo responsabilidad de cumplimiento de la entidad cubierta.
Para el marco completo de implementación en cinco pasos, consulta 5 Pasos para Lograr el Cumplimiento de HIPAA.
Cómo Apoya Kiteworks al Cumplimiento de HIPAA
Kiteworks está diseñado para los requisitos de gobernanza de datos que HIPAA impone a las entidades cubiertas y los socios comerciales que manejan ePHI a través de múltiples canales de intercambio.
En materia de cifrado: Kiteworks aplica cifrado AES-256 tanto a nivel de archivo como a nivel de disco —doble cifrado— con módulos criptográficos validados bajo FIPS 140-3. Las claves de cifrado son propiedad del cliente, lo que significa que Kiteworks no tiene, técnicamente, la capacidad de descifrar los datos del cliente. La ePHI transmitida a través de cualquier canal de Kiteworks —correo electrónico seguro, uso compartido seguro de archivos, transferencia gestionada de archivos, SFTP o formularios seguros de datos— está protegida con TLS 1.2 como mínimo, con TLS 1.3 disponible. La PHI correctamente cifrada en la plataforma Kiteworks califica para el puerto seguro de notificación de brechas de HIPAA.
En materia de controles de acceso: Kiteworks aplica tanto políticas RBAC como ABAC a través de un Motor de Políticas de Datos unificado. El acceso se rige por archivo, por carpeta y por usuario, con aplicación del Mínimo Necesario a nivel de operación. Los destinatarios externos (socios comerciales, socios de referencia, pacientes que acceden a sus propios registros) son autenticados antes de otorgarles acceso. El acceso puede revocarse después del hecho. El acceso de solo visualización SafeVIEW permite compartir PHI para su revisión sin que salga del entorno de Kiteworks.
En materia de registros de auditoría: cada evento de acceso en cada canal de Kiteworks queda registrado en un único rastro de auditoría consolidado e inmutable. El registro captura quién accedió a qué, cuándo, desde qué sistema, bajo qué autorización y qué acción realizó, abarcando correo electrónico, uso compartido de archivos, MFT, SFTP, formularios seguros y acceso de datos por IA. El rastro de auditoría está integrado con SIEM y disponible en vistas de reporte de cumplimiento específicas de HIPAA. Esta es la infraestructura de auditoría que satisface el estándar de Controles de Auditoría de la Regla de Seguridad y respalda investigaciones de brechas defendibles ante la OCR.
En materia de cumplimiento de socios comerciales: Kiteworks firma Acuerdos de Socio Comercial en calidad de socio comercial y cuenta con Autorización FedRAMP Moderate, una postura de seguridad evaluada de forma independiente y monitoreada continuamente que ofrece a las entidades cubiertas una base documentable para la debida diligencia de socios comerciales más allá del BAA contractual.
Para requisitos específicos de HIPAA relacionados con IA, incluyendo cómo se aplican las enmiendas de la Regla de Seguridad 2025 a los agentes de IA que acceden a ePHI, consulta Agentes de IA y HIPAA: Resolviendo el Desafío del Acceso a PHI.
Para ver cómo Kiteworks se aplica a tu entorno específico de cumplimiento de HIPAA, agenda una demostración personalizada.
Preguntas Frecuentes
El cumplimiento de HIPAA requiere satisfacer cuatro reglas. La Regla de Privacidad regula quién puede usar y divulgar PHI, los derechos del paciente y el estándar de Mínimo Necesario para limitar el acceso a la PHI. La Regla de Seguridad exige salvaguardas administrativas, físicas y técnicas para la PHI electrónica, incluyendo evaluación de riesgos, controles de acceso, cifrado y registros de auditoría. La Regla de Notificación de Brechas exige que las entidades cubiertas notifiquen a las personas afectadas, al HHS y, en algunos casos, a los medios de comunicación dentro de los 60 días posteriores al descubrimiento de una filtración de PHI sin proteger. La Regla Ómnibus extendió las obligaciones plenas de cumplimiento y la exposición a sanciones a los socios comerciales y sus subcontratistas. Tanto las entidades cubiertas como los socios comerciales deben satisfacer las cuatro reglas.
Las enmiendas propuestas en 2025 representan la revisión más significativa de la Regla de Seguridad de HIPAA desde su publicación original. El cambio central es eliminar la distinción entre especificaciones de implementación “obligatorias” y “direccionables”, haciendo obligatorios el cifrado de ePHI en reposo y en tránsito, la autenticación multifactor y la segmentación de red para todas las entidades cubiertas y socios comerciales, sin posibilidad de documentar alternativas. Las enmiendas propuestas también añaden requisitos de inventarios anuales de activos tecnológicos, documentación más específica del análisis de riesgos, planes escritos de respuesta a incidentes y recuperación ante desastres con capacidad de restauración del sistema en 72 horas, y una supervisión reforzada de socios comerciales. Hasta julio de 2026, las enmiendas siguen en forma de propuesta, pero las organizaciones deberían tratar los requisitos propuestos como el estándar de cumplimiento actual, dada la postura de aplicación de la OCR.
Un Acuerdo de Socio Comercial (BAA) es un contrato exigido por HIPAA entre una entidad cubierta y cualquier proveedor o tercero —un socio comercial— que crea, recibe, mantiene o transmite PHI en nombre de la entidad cubierta. El BAA debe especificar los usos permitidos de la PHI, exigir que el socio comercial implemente salvaguardas adecuadas, establecer la notificación obligatoria de brechas y otorgar a la entidad cubierta derechos de auditoría. Desde la Regla Ómnibus de 2013, los socios comerciales enfrentan la misma exposición a sanciones que las entidades cubiertas por infracciones ocurridas en sus entornos: el BAA no transfiere la responsabilidad, sino que documenta obligaciones compartidas. Un BAA sin controles técnicos subyacentes es un documento contractual sin una postura de seguridad operativa.
Bajo la Regla de Seguridad original de HIPAA, el cifrado se clasificaba como una especificación de implementación “direccionable”, lo que significaba que las entidades cubiertas debían implementarlo, salvo que pudieran documentar una alternativa razonable y adecuada. En la práctica, la carga de documentación por no cifrar la ePHI, sumada a la pérdida de la protección del puerto seguro de notificación de brechas para la PHI sin cifrar, convirtió al no cifrado en un riesgo de cumplimiento más que en una alternativa legítima. Las enmiendas propuestas en 2025 eliminan por completo esta ambigüedad, haciendo obligatorio el cifrado de la ePHI en reposo y en tránsito. Las acciones de cumplimiento de la OCR han citado sistemáticamente las fallas de cifrado como violaciones de la Regla de Seguridad, independientemente de la clasificación “direccionable”. El cifrado validado bajo FIPS 140-3 es el estándar federal vigente.
El puerto seguro de la Regla de Notificación de Brechas de HIPAA se aplica cuando la PHI filtrada estaba cifrada en el momento de la brecha y las claves de cifrado no también se vieron comprometidas. Según las directrices del HHS, los datos cifrados se consideran “inutilizables, ilegibles o indescifrables”, y una filtración de PHI correctamente cifrada no activa los requisitos de notificación de HIPAA hacia las personas, los medios de comunicación o el HHS. Este puerto seguro es una de las razones operativamente más significativas para implementar cifrado validado por FIPS en todos los canales que manejan ePHI. Que las claves de cifrado sean propiedad del cliente refuerza las reclamaciones de puerto seguro, ya que incluso una filtración en un proveedor en la nube no compromete la PHI descifrable, porque el proveedor nunca tuvo las claves necesarias para descifrarla.