Die technischen Schutzmaßnahmen der Security Rule und Teile der Privacy Rule sind im Code sichtbar: Zugriffskontrolle, Audit-Controls, Integrität, Authentifizierung, Übertragungssicherheit und wie geschützte Gesundheitsdaten genutzt und weitergegeben werden.
Der HIPAA-Blueprint liefert bei jedem Pull Request Code-Nachweise für acht davon. Ab v1.4.0 stärken Commit-Signaturen und die Bindung jedes Merges an seinen Code den Integritätsnachweis. Administrative und physische Schutzmaßnahmen bleiben bei Ihrem Programm.
Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor.
Live8
Code-Nachweis heute, bei jedem Pull Request versiegelt. Immer nur teilweise: Das Control verlangt auch Dinge außerhalb des Codes. Code-Nachweis heute: Regeln im Blueprint HIPAA prüfen einen Teil davon bei jedem Pull Request.
164.308(a)(4)Verwaltung des Informationszugriffs
164.308 Administrative Schutzmaßnahmen
164.312(a)(1)Zugriffskontrolle
164.312 Technische Schutzmaßnahmen
164.312(b)Audit-Controls
164.312 Technische Schutzmaßnahmen
164.312(c)(1)Integrität
164.312 Technische Schutzmaßnahmen
Gestärkt in v1.4.0: Commit-Signaturen und die Bindung des Merges an den Code.
164.312(d)Authentifizierung von Personen oder Stellen
164.312 Technische Schutzmaßnahmen
164.312(e)(1)Übertragungssicherheit
164.312 Technische Schutzmaßnahmen
164.502Nutzung und Weitergabe geschützter Gesundheitsdaten: Allgemeine Regeln
Privacy Rule
164.514Weitere Anforderungen zu Nutzung und Weitergabe geschützter Gesundheitsdaten
Privacy Rule
Unterstützend4
Toevan erfasst verwandte Nachweise, heute oder in v1.4.0, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.
164.308(a)(6)Verfahren bei Sicherheitsvorfällen
164.308 Administrative Schutzmaßnahmen
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft einen betrieblichen Prozess.
164.310(d)(1)Kontrollen für Geräte und Datenträger
164.310 Physische Schutzmaßnahmen
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft die physische Sicherheit.
164.404Benachrichtigung von Betroffenen
Breach Notification Rule
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft ein regulatorisches Verfahren.
164.504Nutzung und Weitergabe: Organisatorische Anforderungen
Privacy Rule
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft Verträge und Lieferanten.
Ihre Organisation30
Richtlinien, Personal, physische Sicherheit, Verträge, regulatorische Verfahren, Betrieb oder externe Prüfung. Diese belegt Ihre Organisation.
Alle 30 Controls anzeigen
164.308 Administrative Schutzmaßnahmen
164.308(a)(1)Prozess für Sicherheitsmanagementeinen betrieblichen Prozess164.308(a)(2)Zugewiesene Sicherheitsverantwortungdie Richtlinien der Organisation164.308(a)(3)Sicherheit der BelegschaftPersonal und HR164.308(a)(5)Sicherheitsbewusstsein und SchulungPersonal und HR164.308(a)(7)Notfallplaneinen betrieblichen Prozess164.308(a)(8)Bewertungeine externe Prüfung164.308(b)(1)Verträge mit Geschäftspartnern und andere VereinbarungenVerträge und Lieferanten
164.310 Physische Schutzmaßnahmen
164.310(a)(1)Zugangskontrollen zu Einrichtungendie physische Sicherheit164.310(b)Nutzung von Arbeitsplätzendie Richtlinien der Organisation164.310(c)Sicherheit von Arbeitsplätzendie physische Sicherheit
164.314 Organisatorische Anforderungen
164.314(a)(1)Verträge mit Geschäftspartnern oder andere VereinbarungenVerträge und Lieferanten164.314(b)(1)Anforderungen an Gruppen-GesundheitspläneVerträge und Lieferanten
164.316 Richtlinien, Verfahren und Dokumentation
164.316(a)Richtlinien und Verfahrendie Richtlinien der Organisation164.316(b)(1)Dokumentationdie Richtlinien der Organisation
Breach Notification Rule
164.406Benachrichtigung der Medienein regulatorisches Verfahren164.408Benachrichtigung des Ministersein regulatorisches Verfahren164.410Benachrichtigung durch einen Geschäftspartnerein regulatorisches Verfahren164.412Aufschub durch Strafverfolgungein regulatorisches Verfahren164.414Administrative Anforderungen und Beweislastein regulatorisches Verfahren
Privacy Rule
164.506Nutzung und Weitergabe für Behandlung, Zahlung oder Gesundheitsbetriebdie Richtlinien der Organisation164.508Nutzung und Weitergabe mit erforderlicher Einwilligungdie Richtlinien der Organisation164.509Nutzung und Weitergabe mit erforderlicher Bestätigungdie Richtlinien der Organisation164.510Nutzung und Weitergabe mit Möglichkeit zu Zustimmung oder Widerspruchdie Richtlinien der Organisation164.512Nutzung und Weitergabe ohne Einwilligung oder Möglichkeit zum Widerspruchdie Richtlinien der Organisation164.520Hinweis zu Datenschutzpraktiken für geschützte Gesundheitsdatendie Richtlinien der Organisation164.522Rechte auf Datenschutzbeschränkung für geschützte Gesundheitsdatendie Richtlinien der Organisation164.524Zugang Betroffener zu geschützten Gesundheitsdateneinen betrieblichen Prozess164.526Berichtigung geschützter Gesundheitsdateneinen betrieblichen Prozess164.528Nachweis über Weitergaben geschützter Gesundheitsdatendie Richtlinien der Organisation164.530Administrative Anforderungendie Richtlinien der Organisation
Im Audit nutzen
Code-Nachweise des Zeitraums lesen
Jeder Pull Request trägt versiegelte Code-Ergebnisse zu den Regeln des Blueprints, festgemacht am Commit und an der geltenden Regelsatz-Version.
Stichprobe testen
Prüfen Sie für jeden gezogenen Eintrag das Ergebnis, dann Signatur und Platz in der Kette offline.
toevan audit verify --path evidence-clone --pub-key toevan.pub
Wie jeder Fakt erhoben wurde
Jeder Fakt in einem Eintrag und einem Bericht trägt eines von sechs Labels, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann.
- Neu berechnet
- Toevan hat es selbst aus Code oder Git-Historie berechnet.
- Mit denselben Eingaben nachvollziehen und dasselbe Ergebnis erhalten.
- Gemeldet + versiegelt
- GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.
- Verlassen Sie sich darauf, soweit Sie GitHub vertrauen. Jede spätere Änderung ist erkennbar.
- Erklärt + versiegelt
- Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.
- Sehen Sie, wer was wann erklärt hat, und jede spätere Änderung.
- Toevan-Eintrag, nicht versiegelt
- In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.
- Behandeln Sie ihn als Aussage von Toevan und fragen Sie die Organisation nach der Freigabe dahinter.
- Übernommen
- Aus dem signierten Eintrag eines anderen Systems übernommen, etwa einer Build-Provenienz, und per Commit oder Digest verknüpft. Geplant.
- Den Originaleintrag unabhängig prüfen.
- Nicht erfasst
- Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.
- Auf anderem Weg bei der Organisation einholen.
Im Bericht ansehen
Der Beispielbericht zeigt den Nachweis so, wie Ihr Auditor ihn erhält, jeder Fakt mit Label.
Beispielbericht öffnenTesten Sie die Zuordnung an einem echten Audit.
Bringen Sie ein Repository und ein anstehendes Audit mit. Wir richten den Blueprint ein und führen Ihren Auditor durch die Prüfung.