Les garanties techniques de la Security Rule et certaines parties de la Privacy Rule sont visibles dans le code : contrôle d’accès, contrôles d’audit, intégrité, authentification, sécurité des transmissions, et manière dont les informations de santé protégées sont utilisées et divulguées.
Le blueprint HIPAA apporte une preuve issue du code pour huit d’entre elles à chaque pull request. À partir de v1.4.0, les signatures de commit et le lien entre chaque fusion et son code renforcent la preuve d’intégrité. Les garanties administratives et physiques restent à votre programme.
Toevan apporte des preuves pour des contrôles ; il ne les certifie jamais et ne prétend pas qu’un référentiel est couvert. Que les preuves suffisent relève du jugement de votre auditeur.
Actif8
Preuve issue du code dès aujourd’hui, scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Preuve issue du code dès aujourd’hui : les règles du blueprint HIPAA vérifient une partie de ce point à chaque pull request.
164.308(a)(4)Gestion de l’accès à l’information
164.308 Garanties administratives
164.312(a)(1)Contrôle d’accès
164.312 Garanties techniques
164.312(b)Contrôles d’audit
164.312 Garanties techniques
164.312(c)(1)Intégrité
164.312 Garanties techniques
Renforcé dans v1.4.0 : signatures de commit et lien entre la fusion et le code.
164.312(d)Authentification de la personne ou entité
164.312 Garanties techniques
164.312(e)(1)Sécurité des transmissions
164.312 Garanties techniques
164.502Utilisations et divulgations des informations de santé protégées : règles générales
Privacy Rule
164.514Autres exigences sur l’utilisation et la divulgation des informations de santé protégées
Privacy Rule
En appui4
Toevan enregistre des preuves connexes, aujourd’hui ou dans v1.4.0, mais l’obligation relève de l’organisation : elle n’est donc jamais comptée comme couverte.
164.308(a)(6)Procédures d’incident de sécurité
164.308 Garanties administratives
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’un processus opérationnel.
164.310(d)(1)Contrôles des appareils et supports
164.310 Garanties physiques
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève de la sécurité physique.
164.404Notification aux personnes
Breach Notification Rule
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève d’une procédure réglementaire.
164.504Utilisations et divulgations : exigences organisationnelles
Privacy Rule
Preuve d’appui dès aujourd’hui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève des contrats et des fournisseurs.
Votre organisation30
Politique, personnes, sécurité physique, contrats, procédure réglementaire, exploitation ou audit externe. Votre organisation en apporte la preuve.
Afficher les 30 contrôles
164.308 Garanties administratives
164.308(a)(1)Processus de gestion de la sécuritéd’un processus opérationnel164.308(a)(2)Responsabilité de sécurité attribuéede la politique de l’organisation164.308(a)(3)Sécurité du personneldes personnes et des RH164.308(a)(5)Sensibilisation et formation à la sécuritédes personnes et des RH164.308(a)(7)Plan de contingenced’un processus opérationnel164.308(a)(8)Évaluationd’une évaluation externe164.308(b)(1)Contrats avec les associés et autres arrangementsdes contrats et des fournisseurs
164.310 Garanties physiques
164.310(a)(1)Contrôles d’accès aux installationsde la sécurité physique164.310(b)Usage des postes de travailde la politique de l’organisation164.310(c)Sécurité des postes de travailde la sécurité physique
164.314 Exigences organisationnelles
164.314(a)(1)Contrats avec les associés ou autres arrangementsdes contrats et des fournisseurs164.314(b)(1)Exigences pour les régimes de santé collectifsdes contrats et des fournisseurs
164.316 Politiques, procédures et exigences de documentation
164.316(a)Politiques et procéduresde la politique de l’organisation164.316(b)(1)Documentation écritede la politique de l’organisation
Breach Notification Rule
164.406Notification aux médiasd’une procédure réglementaire164.408Notification au Secretaryd’une procédure réglementaire164.410Notification par un associéd’une procédure réglementaire164.412Report à la demande des autoritésd’une procédure réglementaire164.414Exigences administratives et charge de la preuved’une procédure réglementaire
Privacy Rule
164.506Utilisations et divulgations pour les soins, le paiement ou les opérations de santéde la politique de l’organisation164.508Utilisations et divulgations soumises à autorisationde la politique de l’organisation164.509Utilisations et divulgations soumises à attestationde la politique de l’organisation164.510Utilisations et divulgations exigeant de laisser la personne accepter ou s’opposerde la politique de l’organisation164.512Utilisations et divulgations sans autorisation ni possibilité d’accepter ou de s’opposerde la politique de l’organisation164.520Avis sur les pratiques de confidentialité des informations de santé protégéesde la politique de l’organisation164.522Droit de demander la protection de la confidentialité des informations de santé protégéesde la politique de l’organisation164.524Accès des personnes à leurs informations de santé protégéesd’un processus opérationnel164.526Rectification des informations de santé protégéesd’un processus opérationnel164.528Relevé des divulgations des informations de santé protégéesde la politique de l’organisation164.530Exigences administrativesde la politique de l’organisation
L’utiliser dans un audit
Lisez les preuves issues du code pour la période
Chaque pull request porte des résultats de code scellés par rapport aux règles du blueprint, rattachés au commit et à la version du jeu de règles en vigueur.
Testez un échantillon
Pour chaque enregistrement échantillonné, vérifiez ses résultats, puis sa signature et sa place dans la chaîne, hors ligne.
toevan audit verify --path evidence-clone --pub-key toevan.pub
Comment chaque fait a été obtenu
Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.
- Recalculé
- Toevan l’a calculé lui-même à partir du code ou de l’historique git.
- Le refaire à partir des mêmes entrées et obtenir le même résultat.
- Rapporté + scellé
- GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
- S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
- Déclaré + scellé
- L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique.
- Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
- Enregistrement Toevan, non scellé
- Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège.
- Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
- Consommé
- Repris de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.
- Vérifier l’enregistrement d’origine de façon indépendante.
- Non capturé
- Aucune source fiable n’était disponible. Toevan ne le déduit pas.
- L’obtenir auprès de l’organisation par d’autres moyens.
Le voir dans un rapport
L’exemple de rapport de preuves de changement montre les preuves telles que votre auditeur les reçoit, chaque fait étant étiqueté.
Ouvrir l’exemple de rapportTestez la correspondance sur un vrai audit.
Apportez un dépôt et un audit à venir. Nous configurons le blueprint et guidons votre auditeur dans la vérification.