HIPAA Security Rule — salvaguardas técnicas para sistemas que contienen ePHI (45 CFR Part 164, Subpart C)
Esta página se genera a partir de la tabla de requisitos que el motor de AiSSAY incluye para este marco. Cuando el motor produce un paquete de evidencias, cada fila de abajo recibe un estado calculado a partir de los propios registros del operador en ese momento. Esta página muestra la tabla, no los resultados de nadie.
Correspondencia informativa preparada con las propias herramientas del operador. No es un dictamen jurídico, ni una certificación, ni sustituye el asesoramiento de un abogado. Organiza los registros del operador en relación con los requisitos citados; determinar si esos registros cumplen los requisitos corresponde al operador, a su asesor jurídico y al examinador.
Esta vista refleja la norma en vigor. La actualización de la Security Rule propuesta en diciembre de 2024 no era definitiva en septiembre de 2026. El contrato de socio comercial, el análisis de riesgos y la formación del personal corresponden a la entidad cubierta. Los registros se quedan en los propios equipos de la entidad cubierta; no guardamos ninguna copia.
La tabla de requisitos
9 filas: 6 de mecanismo, 1 organizativa, 1 carencia señalada, 1 calculada
| Requisito | Mecanismo, obligación o carencia | Tipo |
|---|---|---|
| 164.312(a)(1) — control de acceso: solo las personas o el software autorizados acceden a la ePHI | DELEGADO cuando el almacén está sellado por su gestor de claves (el proveedor kms): quien sea rechazado por su gestor de claves no podrá abrir el almacén en absoluto, y cada apertura aparece en el propio registro de auditoría de su gestor de claves. El almacén en sí no tiene autenticación, roles ni permisos y no rechaza ninguna lectura: una vez que se desenvuelve una clave, el proceso que la tiene puede leer todos los registros. Con cualquier otro proveedor, NO IMPLEMENTADO: los permisos de archivos del sistema operativo son el único control de acceso. El estado se calcula a partir del proveedor que declara este almacén, no se da por supuesto. | calculado |
| 164.312(a)(2)(iv) — cifrado y descifrado de la ePHI (addressable) | cada registro cifrado en reposo con su propia clave (AES-256-GCM); la clave del almacén puede retirarse y sustituirse mediante una ceremonia registrada | mecanismo |
| 164.312(b) — controles de auditoría: registrar y examinar la actividad en los sistemas que contienen ePHI | cada lectura, exportación, retención y eliminación se registra en un registro de accesos encadenado por hashes; cada ejecución de un agente se registra paso a paso | mecanismo |
| 164.312(c)(1) — integridad: proteger la ePHI contra la alteración o destrucción indebidas | cada registro sellado en una cadena de hashes con anclaje externo; la verificación nombra cualquier registro alterado; la eliminación deja una marca de borrado | mecanismo |
| 164.312(d) — autenticación de personas o entidades | se calcula a partir de la política de lectura que declara el almacén: con una política en vigor, el almacén rechaza cualquier lectura que no pueda atribuir a una clave, y el rechazo queda registrado. Lo que verifica es la clave, no la persona: quién tiene esa clave lo establece el alta que usted haga, y el estado lo indica. | mecanismo |
| 164.308(a)(1)(ii)(D) — revisar periódicamente la actividad de los sistemas de información | organizativo: la revisión corresponde a la entidad cubierta. El registro de accesos, los hallazgos y las ejecuciones marcadas son lo que esa revisión lee. | organizativo |
| 164.308(a)(6)(ii) — identificar los incidentes de seguridad, responder a ellos y documentarlos | las instrucciones inyectadas se buscan y se plantean como hallazgos en el registro; una captura interrumpida se sella como un registro explícito de carencia; la verificación del anclaje detecta una cadena reescrita o bifurcada. La respuesta y su documentación corresponden a la entidad cubierta. | mecanismo |
| 164.316(b)(2)(i) — conservar la documentación exigida durante seis años | fechas de conservación por registro (siete años por defecto); la eliminación antes de esa fecha se rechaza salvo que conste una autorización excepcional registrada; la retención legal bloquea la eliminación por completo | mecanismo |
| Uso de esta herramienta — evaluación independiente de sus controles | NO IMPLEMENTADO. Todavía no existe ninguna prueba de penetración, ninguna revisión de la criptografía por terceros ni ningún informe independiente sobre los controles de este software. Quien utilice estos registros como evidencia debe evaluar la herramienta por sí mismo, y esta fila lo dice en primer lugar. | carencia señalada |
Cómo se obtiene un estado
- Acreditado
- se ejecutó una comprobación determinista sobre sus registros y los recuentos respaldan la fila. Un almacén que no contiene registros pertinentes figura como no acreditado: una afirmación verdadera, no un aprobado. Vacío nunca cuenta como limpio.
- Delegado
- el mecanismo lo hace cumplir un sistema en el que usted ya confía: un almacén sellado por su propio gestor de claves le delega a este el control de acceso, y el paquete indica que el registro que lo hace cumplir es el de su gestor de claves, no el nuestro. El paquete nombra el endpoint en el que se contactó con el gestor de claves. Un endpoint de AWS distinto del predeterminado de AWS para la región figura como delegado a ese endpoint, con una solicitud para que usted confirme que es su servicio de gestión de claves. Un backend —AWS KMS— se ha ejecutado contra el servicio real de AWS KMS; ningún otro backend lo ha hecho.
- Punto de integración de prueba
- sellado por un backend de prueba dentro del proceso —un stub, o un sustituto del cliente de AWS— y el estado indica cuál. Ningún gestor de claves controla el acceso. El punto de integración está construido y probado, y el paquete se niega a llamar a eso delegación.
- Parcialmente acreditado
- el mecanismo está construido y algunas de sus ejecuciones llevan su evidencia, pero no todas, normalmente porque se sellaron antes de que existiera el mecanismo. El paquete indica cuántas ejecuciones hay en cada grupo y nunca cuenta como aprobadas las que faltan.
- Organizativo
- el requisito es un procedimiento que solo pueden llevar a cabo personas. El paquete lo señala como responsabilidad suya en lugar de disfrazar una política de mecanismo.
- Carencia señalada
- el paquete no puede acreditarlo —o bien el mecanismo no está construido, o bien ningún software puede aportarlo— y dice cuál de los dos casos es. La carencia se imprime, porque un revisor debería leerla aquí y no descubrirla después.
Ningún estado se introduce a mano: cada estado se recalcula a partir del almacén cada vez que se produce un paquete, el texto de los requisitos y de los mecanismos se redacta y revisa como parte del motor, y la evidencia sobre dependencias procede de nuestro análisis de cada versión. Un mecanismo que falla nunca puede interpretarse como evidencia de que el control funciona.
Las filas marcadas como “calculado” son las de control de acceso. Su estado se calcula a partir del proveedor que declara su almacén: una carencia salvo que su gestor de claves selle el almacén, “punto de integración de prueba” con un backend stub o sustituto, y “delegado” solo con uno real. Hoy nunca pueden figurar como acreditadas, y marcarlas como un mecanismo construido las exageraría.