HIPAA-Compliance-Anforderungen: Der umfassende Leitfaden, aktualisiert für die Security-Rule-Änderungen 2025

Der Health Insurance Portability and Accountability Act (HIPAA) legt bundesweite Standards für den Schutz von Patientengesundheitsdaten in den USA fest – für alle Organisationen, die solche Daten erstellen, empfangen, aufbewahren oder übermitteln. HIPAA-Compliance ist keine einfache Checkliste, sondern ein Rahmenwerk aus vier ineinandergreifenden Regelwerken, die Datenschutz, Sicherheit, Verstoßmeldungen und Datenverarbeitung sowohl für die unmittelbar patientenversorgenden „Covered Entities“ als auch für die sie unterstützenden „Business Associates“ regeln.

Zu verstehen, was HIPAA tatsächlich verlangt – nicht nur, dass es existiert – ist der Ausgangspunkt für ein Compliance-Programm, das einer Prüfung durch das Office for Civil Rights (OCR) standhält. Dieser Leitfaden behandelt alle vier Regelwerke, die für 2025 vorgeschlagenen Änderungen der Security Rule, die die umfassendste Überarbeitung seit über einem Jahrzehnt darstellen, die Sanktionsstruktur bei Verstößen sowie die praktischen Umsetzungsanforderungen für jede Vorgabe.

Zusammenfassung

Kernaussage: HIPAA-Compliance erfordert die Erfüllung von vier Regelwerken – Privacy Rule, Security Rule, Breach Notification Rule und Omnibus Rule – in den Bereichen Administration, physische Sicherheit und Technik. Für Covered Entities wie auch Business Associates bedeutet Compliance nicht nur die Umsetzung von Kontrollen, sondern auch den dokumentierten Nachweis, dass diese Kontrollen tatsächlich funktionieren. Sollten die 2025 vorgeschlagenen Änderungen der Security Rule final verabschiedet werden, würden Verschlüsselung, Multi-Faktor-Authentifizierung und Netzwerksegmentierung für alle Covered Entities und Business Associates verpflichtend – und die bisher genutzte Flexibilität der „addressable“ (optionalen) Schutzmaßnahmen entfiele.

Warum das relevant ist: Allein 2024 hat das Office for Civil Rights 63 Durchsetzungsverfahren abgeschlossen, mit Bußgeldern von mehreren zehntausend bis zu mehreren zehn Millionen US-Dollar. Das Gesundheitswesen war das vierzehnte Jahr in Folge die am stärksten von Datenschutzverstößen betroffene Branche. Die Durchsetzungsstrategie des OCR hat sich von reaktiv – als Reaktion auf gemeldete Verstöße – zu proaktiv gewandelt, mit einem aktiven Audit-Programm, das Covered Entities und Business Associates unabhängig davon ins Visier nimmt, ob bereits ein Vorfall aufgetreten ist. Der Maßstab für HIPAA-Compliance ist nicht ein Programm auf Papier, sondern der Nachweis, dass dieses Programm tatsächlich funktioniert, wenn das OCR nachfragt.

Die wichtigsten Erkenntnisse

1. HIPAA gilt gleichermaßen für Covered Entities und Business Associates.

Seit der Omnibus Rule von 2013 unterliegen Business Associates – also Dienstleister, Cloud-Anbieter, Abrechnungsunternehmen und Technologiepartner, die PHI im Auftrag von Covered Entities verarbeiten – denselben HIPAA-Compliance-Anforderungen und demselben Bußgeldrisiko wie die Gesundheitsorganisationen, für die sie tätig sind. Eine Business Associate Agreement (BAA) ist gesetzlich vorgeschrieben, ersetzt aber keine technischen Kontrollen. Eine BAA, die Compliance-Pflichten zuweist, ohne dass die zugrunde liegende Verschlüsselung, Zugriffskontrolle und Protokollierung tatsächlich umgesetzt sind, ist ein Vertragsdokument mit einer nicht durchsetzbaren Sicherheitslage.

2. Die vorgeschlagenen Änderungen der Security Rule 2025 streichen das „Addressable“-Schlupfloch.

Nach der ursprünglichen HIPAA Security Rule wurden Schutzmaßnahmen entweder als „required“ (verpflichtend) oder „addressable“ (adressierbar) eingestuft. Verpflichtende Maßnahmen mussten umgesetzt werden. Adressierbare Maßnahmen mussten umgesetzt werden, sofern eine Covered Entity keine dokumentierte, angemessene Alternative vorweisen konnte. In der Praxis nutzten viele Organisationen diese Einstufung, um Verschlüsselung und andere Kontrollen aufzuschieben. Die 2025 vorgeschlagenen Änderungen streichen diese Unterscheidung vollständig – Verschlüsselung ruhender und übertragener Daten, Multi-Faktor-Authentifizierung, Netzwerksegmentierung und mehrere weitere Schutzmaßnahmen würden für alle Covered Entities und Business Associates verpflichtend, ohne die Möglichkeit dokumentierter Alternativen.

3. Die Risikobewertung ist verpflichtend, nicht optional – und muss aktuell sein.

Die HIPAA Security Rule verlangt von Covered Entities und Business Associates eine genaue und gründliche Bewertung der potenziellen Risiken und Schwachstellen für Vertraulichkeit, Integrität und Verfügbarkeit von ePHI. Das OCR hat in Durchsetzungsverfahren klargestellt, dass eine vor Jahren durchgeführte Risikoanalyse ohne anschließende Aktualisierung diese Anforderung nicht erfüllt. Eine HIPAA-Risikobewertung ist keine einmalige Übung – sie muss regelmäßig überprüft und aktualisiert werden, insbesondere bei wesentlichen betrieblichen oder umgebungsbedingten Veränderungen.

4. Beziehungen zu Business Associates erweitern Ihren Compliance-Radius – und Ihre Haftung.

Jeder Dienstleister, Cloud-Anbieter oder Technologiepartner, der in Ihrem Auftrag auf PHI zugreift, diese speichert oder überträgt, ist ein Business Associate. Deren Sicherheitsversagen wird zu Ihrem Compliance-Risiko. Nach HIPAA müssen Covered Entities technische und vertragliche Schutzmaßnahmen umsetzen, die regeln, wie Business Associates mit PHI umgehen – und diese Maßnahmen müssen operativ durchgesetzt, nicht nur in einer BAA dokumentiert werden. Die 2025 vorgeschlagenen Änderungen verschärfen die Überwachungspflichten gegenüber Business Associates, einschließlich jährlicher Audits und kürzerer Fristen für Vorfallmeldungen.

5. Audit-Protokolle sind verpflichtende Infrastruktur, keine optionale Reporting-Funktion.

Der Audit-Controls-Standard der HIPAA Security Rule (45 C.F.R. § 164.312(b)) verlangt von Covered Entities und Business Associates, Mechanismen zu implementieren, die Aktivitäten in Systemen mit ePHI erfassen und auswerten. Dies sind keine weichen Vorgaben – OCR-Durchsetzungsverfahren nennen regelmäßig unvollständige oder fehlende Audit-Protokollierung als Verstoß gegen die Security Rule. Ein Audit-Trail, der erfasst, wer wann von welchem System aus mit welcher Berechtigung und mit welchem Ergebnis auf PHI zugegriffen hat, dient sowohl der Erkennung von Sicherheitsvorfällen als auch als Nachweis der Compliance im Falle einer Prüfung.

Für wen HIPAA gilt

HIPAA gilt für zwei Arten von Organisationen: Covered Entities und Business Associates.

Covered Entities sind Gesundheitsdienstleister, die Gesundheitsdaten elektronisch übermitteln (Krankenhäuser, Arztpraxen, Kliniken, Apotheken), Krankenversicherer (Versicherungsunternehmen, HMOs, arbeitgebergestützte Gesundheitspläne) sowie Gesundheits-Clearingstellen, die Gesundheitsdaten von einem Format in ein anderes überführen.

Business Associates sind Organisationen, die im Auftrag einer Covered Entity Funktionen oder Tätigkeiten ausführen, bei denen PHI genutzt oder offengelegt wird. Dazu zählen Cloud-Anbieter, die ePHI speichern, Managed-Service-Provider, die IT-Systeme im Gesundheitswesen betreiben, Abrechnungsunternehmen, Transkriptionsdienste, Rechtsberater, Steuerberater sowie jede Technologieplattform, über die PHI fließt. Seit der Omnibus Rule von 2013 tragen Business Associates dasselbe Bußgeldrisiko wie Covered Entities bei Verstößen – der Status als Business Associate schafft keinen Compliance-Puffer.

Organisationen, die keine PHI erstellen, empfangen, aufbewahren oder übermitteln, unterliegen in der Regel nicht HIPAA. Die Schwelle für den Status als Business Associate liegt jedoch niedriger, als die meisten Organisationen annehmen. Ein Cloud-Speicheranbieter, der verschlüsselte PHI hostet – selbst ohne Zugriffsmöglichkeit darauf –, gilt nach HIPAA als Business Associate und muss eine BAA abschließen sowie angemessene Schutzmaßnahmen umsetzen.

Die vier HIPAA-Regelwerke

Die Privacy Rule

Die HIPAA Privacy Rule legt landesweite Standards für den Schutz individuell identifizierbarer Gesundheitsdaten fest – sie definiert, was als Protected Health Information (PHI) gilt, wer diese unter welchen Umständen nutzen oder offenlegen darf und welche Rechte Patienten dabei haben.

PHI umfasst alle Informationen, die sich auf den vergangenen, gegenwärtigen oder zukünftigen Gesundheitszustand einer Person, die Erbringung von Gesundheitsleistungen oder deren Bezahlung beziehen – und die die Person identifizierbar machen. Die 18 HIPAA-Identifikatoren reichen von Namen und Daten bis zu geografischen Angaben und Geräte-Kennungen. Anonymisierte Daten – bei denen alle 18 Identifikatoren nach einer anerkannten Methode entfernt wurden – fallen nicht in den Anwendungsbereich von HIPAA.

Die Privacy Rule erlaubt die Nutzung und Offenlegung von PHI für Behandlung, Abrechnung und den Praxisbetrieb ohne Einwilligung des Patienten. Für die meisten anderen Offenlegungen ist eine Einwilligung erforderlich. Patienten haben das Recht, auf ihre eigenen PHI zuzugreifen, Berichtigungen zu beantragen, eine Übersicht über Offenlegungen zu erhalten und Nutzungsbeschränkungen zu verlangen. Der Minimum-Necessary-Standard verpflichtet Covered Entities und Business Associates, den Zugriff auf PHI auf das für den jeweiligen Zweck notwendige Minimum zu beschränken – eine Anforderung, die gleichermaßen für menschlichen Zugriff wie für den Zugriff durch KI-Systeme gilt.

Eine detaillierte Aufschlüsselung der Minimum-Necessary-Anforderungen und der rollenbasierten Zugriffsumsetzung finden Sie unter HIPAA Minimum Necessary Rule: Der vollständige Compliance-Leitfaden.

Die Security Rule

Die HIPAA Security Rule legt landesweite Standards für den Schutz elektronischer PHI (ePHI) fest – also PHI, die in elektronischer Form erstellt, empfangen, aufbewahrt oder übertragen wird. Sie verpflichtet Covered Entities und Business Associates, administrative, physische und technische Schutzmaßnahmen umzusetzen, die Vertraulichkeit, Integrität und Verfügbarkeit von ePHI gewährleisten.

Administrative Schutzmaßnahmen umfassen Richtlinien, Verfahren und Schulungsprogramme, die regeln, wie eine Organisation die Sicherheit von ePHI verwaltet. Dazu zählen der Sicherheitsmanagementprozess (Risikoanalyse und Risikomanagement), Mitarbeiterschulungen, Zugriffsverwaltung, Notfallplanung und die Überwachung von Business Associates. Die Security Rule verlangt die Benennung eines Sicherheitsbeauftragten, der für die Entwicklung und Umsetzung von Sicherheitsrichtlinien und -verfahren verantwortlich ist.

Physische Schutzmaßnahmen regeln den Zugang zu den physischen Systemen und Einrichtungen, in denen ePHI gespeichert ist. Dazu zählen Zugangskontrollen für Gebäude, Richtlinien für die Arbeitsplatznutzung, physische Sicherung von Arbeitsplätzen sowie Kontrollen für Geräte und Datenträger, die regeln, wie elektronische Medien mit ePHI gehandhabt, transportiert und entsorgt werden.

Technische Schutzmaßnahmen sind technologiebasierte Kontrollen, die ePHI schützen und den Zugriff darauf steuern. Dazu zählen Zugriffskontrollen (eindeutige Nutzeridentifikation, automatische Abmeldung, Ver- und Entschlüsselung), Audit-Kontrollen, Integritätskontrollen (Schutz vor unzulässiger Änderung oder Zerstörung von ePHI) sowie Übertragungssicherheit (Schutz von ePHI bei der Übertragung über elektronische Kommunikationsnetze).

Ausführliche Details zu den technischen Schutzmaßnahmen finden Sie unter HIPAA Security Rule: Anforderungen und Updates 2025.

Die Breach Notification Rule

Die HIPAA Breach Notification Rule verpflichtet Covered Entities, betroffene Personen, das HHS und in bestimmten Fällen die Medien nach einem Verstoß gegen ungesicherte PHI zu benachrichtigen. Business Associates müssen die Covered Entity ohne unangemessene Verzögerung, spätestens jedoch innerhalb von 60 Tagen nach Entdeckung eines Vorfalls, informieren.

Der Meldeplan für Covered Entities ist strikt geregelt: Betroffene Personen müssen ohne unangemessene Verzögerung, spätestens jedoch innerhalb von 60 Tagen nach Entdeckung, informiert werden. Betrifft ein Vorfall 500 oder mehr Personen in einem einzelnen Bundesstaat oder einer Rechtsordnung, ist zusätzlich eine Meldung an relevante Medien erforderlich. Alle Vorfälle müssen dem HHS gemeldet werden – Vorfälle mit 500 oder mehr Betroffenen innerhalb von 60 Tagen nach Entdeckung, kleinere Vorfälle können jährlich gesammelt gemeldet werden.

PHI, die zum Zeitpunkt eines Vorfalls verschlüsselt war – und deren Schlüssel sicher blieben –, fällt unter die Safe-Harbor-Regelung der Breach Notification Rule. Verschlüsselte Daten gelten als „unbrauchbar, unlesbar oder unentzifferbar“ und lösen keine Meldepflicht aus. Diese Safe-Harbor-Regelung ist einer der praktisch bedeutsamsten Gründe, Verschlüsselung umzusetzen: Ein Vorfall bei ordnungsgemäß verschlüsselter PHI stellt keinen meldepflichtigen HIPAA-Verstoß dar. Die vollständige Analyse der Verschlüsselungs-Safe-Harbor-Regelung finden Sie unter AES-256-Verschlüsselung für HIPAA: Der Breach-Safe-Harbor-Leitfaden.

Die Omnibus Rule

Die Omnibus Rule von 2013 brachte mehrere strukturelle Änderungen an HIPAA mit sich, die bis heute gelten. Am bedeutsamsten war die Ausweitung der vollständigen HIPAA-Compliance-Pflichten und des Bußgeldrisikos auf Business Associates und deren Subunternehmer – wodurch die Haftungslücke geschlossen wurde, die es nachgelagerten Dienstleistern zuvor ermöglichte, unter weniger strengen Anforderungen zu agieren. Zudem wurden die Patientenrechte gestärkt (einschließlich des Rechts, Kopien elektronisch gespeicherter PHI aus elektronischen Patientenakten anzufordern), die Nutzung von PHI zu Marketingzwecken eingeschränkt und der Verkauf von PHI ohne Einwilligung des Patienten untersagt.

Die vorgeschlagenen Änderungen der Security Rule 2025

Im Januar 2025 hat das HHS die bedeutendste Überarbeitung der HIPAA Security Rule seit ihrer ursprünglichen Veröffentlichung vorgeschlagen. Die vorgeschlagenen Änderungen reagieren auf die stark gestiegene Zahl von Datenschutzverstößen und Ransomware-Angriffen im Gesundheitswesen, die die Lücken offengelegt haben, die durch die uneinheitliche Umsetzung der „addressable“-Einstufung der ursprünglichen Regel entstanden sind.

Die zentrale Änderung: Die vorgeschlagenen Änderungen streichen die Unterscheidung zwischen „required“ (verpflichtend) und „addressable“ (adressierbar) vollständig. Nach der geänderten Regel würden folgende Schutzmaßnahmen für alle Covered Entities und Business Associates verpflichtend – ohne die Möglichkeit dokumentierter Alternativen:

Verschlüsselung von ePHI im Ruhezustand und bei der Übertragung. Sowohl die Verschlüsselung ruhender Daten (gespeicherte ePHI in Datenbanken, Dateisystemen und Backup-Medien) als auch die Verschlüsselung während der Übertragung (ePHI, die über ein elektronisches Netzwerk übermittelt wird) würden verpflichtend. Die vorgeschlagenen Änderungen verweisen auf FIPS-validierte Verschlüsselungsstandards – wodurch FIPS-140-3-validierte kryptografische Module faktisch zum verbindlichen Umsetzungsstandard würden.

Multi-Faktor-Authentifizierung. MFA wäre für jeden Zugriff auf Systeme mit ePHI erforderlich. Eine reine passwortbasierte Einzelfaktor-Authentifizierung würde die Anforderungen der Security Rule nicht mehr erfüllen.

Netzwerksegmentierung. Covered Entities und Business Associates müssten Netzwerkkontrollen implementieren, die Systeme mit ePHI von anderen Netzwerksegmenten isolieren – um eine seitliche Ausbreitung im Falle eines Sicherheitsvorfalls zu begrenzen.

Jährliche Inventarisierung technischer Assets. Organisationen müssten aktuelle Inventare aller Technologie-Assets führen, die auf ePHI zugreifen, sie speichern oder übertragen – eine grundlegende Voraussetzung für eine präzise Risikobewertung und Vorfallreaktion.

Dokumentierte Risikoanalyse mit klar definiertem Umfang. Die vorgeschlagenen Änderungen konkretisieren die Anforderungen an die Risikoanalyse und legen fest, was diese enthalten muss – einschließlich der Dokumentation identifizierter Risiken, ihrer Wahrscheinlichkeit und Auswirkung sowie der zu ihrer Behebung umgesetzten Kontrollen.

Schriftliche Notfall- und Wiederherstellungspläne mit einer 72-Stunden-Wiederherstellungsfähigkeit. Organisationen müssten dokumentierte Pläne für die Reaktion auf Sicherheitsvorfälle vorhalten und in der Lage sein, Systeme innerhalb von 72 Stunden nach einer Störung wiederherzustellen.

Jährliche Compliance-Audits und verstärkte Anbieterüberwachung. Die vorgeschlagenen Änderungen verschärfen die Überwachungspflichten gegenüber Business Associates, einschließlich vertraglicher Regelungen zur jährlichen Compliance-Überprüfung.

Stand Juli 2026 befinden sich diese Änderungen weiterhin im Entwurfsstadium – das formale Gesetzgebungsverfahren läuft noch. Organisationen sollten mit der Umsetzung jedoch nicht bis zur endgültigen Veröffentlichung warten. Die vorgeschlagenen Änderungen spiegeln die Durchsetzungspraxis des OCR unabhängig von ihrem formalen Status wider, und das 2025 von den Senatoren Wyden und Warner eingebrachte HISAA-Gesetz würde im Falle seiner Verabschiedung noch strengere Anforderungen mit sich bringen. Den aktuellen Stand dieser Vorschläge finden Sie unter HIPAA Security Rule: Anforderungen und Updates 2025.

HIPAA-Sanktionen und Durchsetzung

Verstöße gegen HIPAA ziehen zivil- und strafrechtliche Sanktionen nach sich, deren Höhe sich nach Schwere und Vorsätzlichkeit des Verstoßes richtet.

Zivilrechtliche Bußgelder sind nach Kenntnisstand und Verschulden gestaffelt. Organisationen, die von einem Verstoß nichts wussten, müssen mit mindestens 100 US-Dollar pro Vorfall rechnen. Verstöße mit angemessenem Grund, aber ohne vorsätzliche Vernachlässigung, ziehen mindestens 1.000 US-Dollar pro Vorfall nach sich. Vorsätzliche Vernachlässigung, die behoben wird, kostet mindestens 10.000 US-Dollar pro Vorfall. Vorsätzliche Vernachlässigung, die nicht behoben wird, kostet mindestens 50.000 US-Dollar pro Vorfall. Die jährlichen Höchstgrenzen je Verstoßkategorie liegen bei 25.000 US-Dollar für die niedrigste und 1,5 Millionen US-Dollar für die höchste Stufe – wobei das OCR diese Obergrenze pro Kalenderjahr und Verstoßart auslegt, sodass sich das Risiko bei mehrjähriger Nichteinhaltung deutlich vervielfacht.

Strafrechtliche Sanktionen gelten für wissentliche Verstöße und werden vom Justizministerium verfolgt. Die wissentliche Beschaffung oder Offenlegung von PHI unter Verstoß gegen HIPAA kann mit Geldstrafen bis zu 50.000 US-Dollar und bis zu einem Jahr Haft geahndet werden. Verstöße unter falschem Vorwand erhöhen die Höchststrafe auf 100.000 US-Dollar und fünf Jahre Haft. Verstöße mit der Absicht, PHI zu verkaufen, weiterzugeben oder für kommerzielle Vorteile oder persönlichen Gewinn zu nutzen, können mit Geldstrafen bis zu 250.000 US-Dollar und bis zu zehn Jahren Haft geahndet werden.

Die Durchsetzungsmaßnahmen des OCR richten sich zunehmend gegen das gesamte Spektrum des Gesundheitswesens – nicht nur gegen große Gesundheitssysteme, sondern auch gegen Arztpraxen, Krankenversicherer und Business Associates. Corrective Action Plans, die Vergleichen beigefügt werden, bringen in der Regel mehrjährige Überwachungspflichten und verpflichtende Verbesserungen des Compliance-Programms mit sich, die weit über das ursprüngliche Bußgeld hinausgehen.

Aufbau einer HIPAA-konformen technischen Architektur

Die technischen Anforderungen der Security Rule übersetzen sich in konkrete Plattformfähigkeiten, die Covered Entities und Business Associates umsetzen müssen. Die Lücke zwischen einzelnen Tools, die einzelne Anforderungen erfüllen, und einer einheitlichen Architektur, die alle Anforderungen gleichzeitig erfüllt, ist der Punkt, an dem die meisten Organisationen Compliance-Risiken anhäufen.

Verschlüsselung über alle Kanäle hinweg. ePHI bewegt sich durch mehr Kanäle, als die meisten Organisationen berücksichtigen: E-Mail, Dateifreigabe, Managed File Transfer, Webformulare, API-Integrationen und zunehmend KI-Systeme, die auf klinische Daten zugreifen. Jeder Kanal muss AES-256-Verschlüsselung im Ruhezustand und mindestens TLS 1.2 (TLS 1.3 bevorzugt) bei der Übertragung implementieren. Kanäle, die einen Teil der PHI-Flüsse verschlüsseln, andere aber nicht, erzeugen Lücken in der Safe-Harbor-Regelung – ein Vorfall bei unverschlüsselter PHI über einen unverschlüsselten Kanal löst eine Meldepflicht aus, unabhängig davon, wie gut andere Kanäle geschützt sind. Eine Checkliste für Audit-Trails finden Sie unter HIPAA-Audit-Protokolle: Die vollständigen Anforderungen.

Zugriffskontrollen zur Durchsetzung des Minimum-Necessary-Prinzips. Technische Zugriffskontrollen müssen den Zugriff auf PHI auf das für den jeweiligen Zweck notwendige Minimum beschränken. Rollenbasierte Zugriffskontrolle (RBAC) legt fest, welche Mitarbeiter auf welche PHI-Kategorien zugreifen können. Attributbasierte Zugriffskontrolle (ABAC) wendet dynamische, kontextabhängige Richtlinien an, die das Minimum-Necessary-Prinzip auf Vorgangsebene durchsetzen – nicht nur auf Kontoebene. Eindeutige Nutzeridentifikation, automatische Sitzungsbeendigung und Notfallzugriffsverfahren sind weitere technische Schutzmaßnahmen.

Unveränderliche Audit-Protokollierung über alle ePHI-berührenden Systeme hinweg. Audit-Protokolle müssen jedes Zugriffsereignis erfassen – wer wann von welchem System aus mit welcher Berechtigung auf welche PHI zugegriffen und welche Aktion durchgeführt hat. Protokolle müssen in einem Format gespeichert werden, das nachträglich nicht verändert werden kann. Organisationen mit fragmentierter Protokollierung über E-Mail-Systeme, Dateifreigabeplattformen, EHR-Audit-Module und Netzwerkinfrastruktur hinweg können dem OCR keinen schlüssigen Audit-Trail vorlegen – weshalb konsolidierte, kanalübergreifende Protokollierung eine praktische Compliance-Anforderung ist, nicht nur eine Best Practice.

Technische Governance für Business Associates. Eine BAA ist gesetzlich vorgeschrieben. Technische Kontrollen, die regeln, auf welche PHI Business Associates zugreifen können, deren Zugriffe im selben Audit-Trail wie interne Nutzer protokollieren und den Zugriff bei Beendigung der Beziehung widerrufen, sind durch die Security Rule vorgeschrieben. Die Compliance-Pflicht folgt den Daten – PHI in der Umgebung eines Business Associate bleibt weiterhin in der Compliance-Verantwortung der Covered Entity.

Das vollständige fünfstufige Umsetzungs-Framework finden Sie unter 5 Schritte zur HIPAA-Compliance.

Wie Kiteworks HIPAA-Compliance unterstützt

Kiteworks wurde für genau die Datengovernance-Anforderungen entwickelt, die HIPAA Covered Entities und Business Associates auferlegt, die ePHI über mehrere Austauschkanäle hinweg verarbeiten.

Zur Verschlüsselung: Kiteworks wendet AES-256-Verschlüsselung sowohl auf Datei- als auch auf Festplattenebene an – eine doppelte Verschlüsselung – mit FIPS-140-3-validierten kryptografischen Modulen. Kundeneigene Verschlüsselungsschlüssel bedeuten, dass Kiteworks technisch nicht in der Lage ist, Kundendaten zu entschlüsseln. ePHI, die über einen beliebigen Kiteworks-Kanal übertragen wird – sichere E-Mail, sichere Dateifreigabe, Managed File Transfer, SFTP oder sichere Datenformulare – ist mindestens durch TLS 1.2 geschützt, TLS 1.3 ist verfügbar. Ordnungsgemäß verschlüsselte PHI auf der Kiteworks-Plattform fällt unter die Safe-Harbor-Regelung der HIPAA-Meldepflicht.

Zu den Zugriffskontrollen: Kiteworks setzt sowohl RBAC- als auch ABAC-Richtlinien über eine einheitliche Data-Policy-Engine durch. Der Zugriff wird pro Datei, pro Ordner und pro Nutzer gesteuert – mit Durchsetzung des Minimum-Necessary-Prinzips auf Vorgangsebene. Externe Empfänger (Business Associates, Überweisungspartner, Patienten, die auf ihre eigenen Akten zugreifen) werden vor der Zugriffsgewährung authentifiziert. Der Zugriff kann nachträglich widerrufen werden. Mit SafeVIEW kann PHI ausschließlich zur Ansicht freigegeben werden, ohne die Kiteworks-Umgebung zu verlassen.

Zur Audit-Protokollierung: Jedes Zugriffsereignis über jeden Kiteworks-Kanal hinweg wird in einem einzigen, konsolidierten, unveränderlichen Audit-Trail protokolliert. Das Protokoll erfasst, wer wann von welchem System aus mit welcher Berechtigung auf was zugegriffen und welche Aktion durchgeführt hat – über E-Mail, Dateifreigabe, MFT, SFTP, sichere Formulare und KI-Datenzugriffe hinweg. Der Audit-Trail ist SIEM-integriert und in HIPAA-spezifischen Compliance-Reporting-Ansichten verfügbar. Dies ist die Audit-Infrastruktur, die den Audit-Controls-Standard der Security Rule erfüllt und eine gegenüber dem OCR verteidigungsfähige Untersuchung von Sicherheitsvorfällen unterstützt.

Zur Compliance von Business Associates: Kiteworks unterzeichnet Business Associate Agreements als Business Associate und verfügt über die FedRAMP-Moderate-Autorisierung – eine unabhängig geprüfte, kontinuierlich überwachte Sicherheitslage, die Covered Entities eine dokumentierbare Grundlage für die Sorgfaltsprüfung von Business Associates bietet, die über die vertragliche BAA hinausgeht.

Für KI-spezifische HIPAA-Anforderungen, einschließlich der Frage, wie die 2025 vorgeschlagenen Änderungen der Security Rule auf KI-Agenten mit Zugriff auf ePHI anzuwenden sind, siehe KI-Agenten und HIPAA: Die PHI-Zugriffsherausforderung lösen.

Um zu erfahren, wie Kiteworks auf Ihre spezifische HIPAA-Compliance-Umgebung angewendet werden kann, vereinbaren Sie eine individuelle Demo.