Las salvaguardas técnicas de la Security Rule y partes de la Privacy Rule son visibles en el código: control de acceso, controles de auditoría, integridad, autenticación, seguridad de la transmisión y cómo se usa y divulga la información de salud protegida.
El blueprint de HIPAA aporta evidencia de código para ocho de ellas en cada pull request. Desde v1.4.0, las firmas de commits y el vínculo de cada fusión con su código refuerzan la evidencia de integridad. Las salvaguardas administrativas y físicas quedan en su programa.
Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor.
Activo8
Evidencia de código hoy, sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Evidencia de código hoy: las reglas del blueprint HIPAA comprueban parte de esto en cada pull request.
164.308(a)(4)Gestión del acceso a la información
164.308 Salvaguardas administrativas
164.312(a)(1)Control de acceso
164.312 Salvaguardas técnicas
164.312(b)Controles de auditoría
164.312 Salvaguardas técnicas
164.312(c)(1)Integridad
164.312 Salvaguardas técnicas
Reforzado en v1.4.0: las firmas de commits y el vínculo de la fusión con el código.
164.312(d)Autenticación de personas o entidades
164.312 Salvaguardas técnicas
164.312(e)(1)Seguridad de la transmisión
164.312 Salvaguardas técnicas
164.502Usos y divulgaciones de información de salud protegida: reglas generales
Privacy Rule
164.514Otros requisitos sobre usos y divulgaciones de información de salud protegida
Privacy Rule
De apoyo4
Toevan registra evidencia relacionada, hoy o en v1.4.0, pero la obligación es organizativa, así que nunca cuenta como cubierta.
164.308(a)(6)Procedimientos ante incidentes de seguridad
164.308 Salvaguardas administrativas
Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es un proceso operativo.
164.310(d)(1)Controles de dispositivos y soportes
164.310 Salvaguardas físicas
Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es seguridad física.
164.404Notificación a las personas
Breach Notification Rule
Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es un trámite regulatorio.
164.504Usos y divulgaciones: requisitos organizativos
Privacy Rule
Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es contratos y proveedores.
Su organización30
Política, personas, seguridad física, contratos, trámites regulatorios, operaciones o auditoría externa. Su organización aporta la evidencia.
Mostrar los 30 controles
164.308 Salvaguardas administrativas
164.308(a)(1)Proceso de gestión de la seguridadun proceso operativo164.308(a)(2)Responsabilidad de seguridad asignadauna política de la organización164.308(a)(3)Seguridad del personalun asunto de personas y RR. HH.164.308(a)(5)Concienciación y formación en seguridadun asunto de personas y RR. HH.164.308(a)(7)Plan de contingenciaun proceso operativo164.308(a)(8)Evaluaciónuna evaluación externa164.308(b)(1)Contratos con asociados comerciales y otros acuerdoscontratos y proveedores
164.310 Salvaguardas físicas
164.310(a)(1)Controles de acceso a instalacionesseguridad física164.310(b)Uso de estaciones de trabajouna política de la organización164.310(c)Seguridad de estaciones de trabajoseguridad física
164.314 Requisitos organizativos
164.314(a)(1)Contratos con asociados comerciales u otros acuerdoscontratos y proveedores164.314(b)(1)Requisitos para planes de salud colectivoscontratos y proveedores
164.316 Políticas, procedimientos y requisitos de documentación
164.316(a)Políticas y procedimientosuna política de la organización164.316(b)(1)Documentaciónuna política de la organización
Breach Notification Rule
164.406Notificación a los mediosun trámite regulatorio164.408Notificación al Secretarioun trámite regulatorio164.410Notificación por un asociado comercialun trámite regulatorio164.412Retraso por orden de las fuerzas de seguridadun trámite regulatorio164.414Requisitos administrativos y carga de la pruebaun trámite regulatorio
Privacy Rule
164.506Usos y divulgaciones para tratamiento, pago u operaciones sanitariasuna política de la organización164.508Usos y divulgaciones que requieren autorizaciónuna política de la organización164.509Usos y divulgaciones que requieren una declaraciónuna política de la organización164.510Usos y divulgaciones que requieren dar oportunidad de aceptar u oponerseuna política de la organización164.512Usos y divulgaciones que no requieren autorización ni oportunidad de aceptar u oponerseuna política de la organización164.520Aviso de prácticas de privacidad de la información de salud protegidauna política de la organización164.522Derechos a solicitar protección de la privacidad de la información de salud protegidauna política de la organización164.524Acceso de las personas a su información de salud protegidaun proceso operativo164.526Modificación de la información de salud protegidaun proceso operativo164.528Contabilidad de las divulgaciones de información de salud protegidauna política de la organización164.530Requisitos administrativosuna política de la organización
Cómo usarlo en una auditoría
Lea la evidencia de código del periodo
Cada pull request lleva resultados de código sellados frente a las reglas del blueprint, fijados al commit y a la versión del conjunto de reglas vigente.
Pruebe una muestra
Para cada registro muestreado, compruebe sus resultados y luego verifique su firma y su lugar en la cadena sin conexión.
toevan audit verify --path evidence-clone --pub-key toevan.pub
Cómo se obtuvo cada dato
Cada dato de un registro y de un informe lleva una de seis etiquetas, para que su auditor sepa hasta qué punto puede fiarse.
- Recalculado
- Toevan lo calculó a partir del propio código o del historial de git.
- Repítalo con las mismas entradas y obtenga el mismo resultado.
- Informado + sellado
- GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
- Fíese de ello tanto como se fía de GitHub. Cualquier cambio posterior es detectable.
- Declarado + sellado
- La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
- Vea quién declaró qué, cuándo, y cada cambio posterior.
- Registro de Toevan, sin sellar
- Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.
- Trátelo como una declaración de Toevan y pida a la organización la aprobación que hay detrás.
- Consumido
- Tomado del registro firmado de otro sistema, como la procedencia de una compilación, y enlazado por commit o digest. Planificado.
- Compruebe el registro original de forma independiente.
- No capturado
- No había una fuente fiable. Toevan no lo infiere.
- Obténgalo de la organización por otros medios.
Véalo en un informe
El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada dato rotulado.
Abrir el informe de muestraPonga a prueba el mapeo en una auditoría real.
Traiga un repositorio y una auditoría próxima. Configuraremos el blueprint y guiaremos a su auditor por la verificación.