Eine Risikobewertung für ISO 27001, SOC 2 und HIPAA

Die Risikobewertung ist der Punkt, an dem drei der gängigsten Frameworks beginnen. ISO 27001 baut alles darauf auf (Klausel 6.1.2). SOC 2 widmet einen Abschnitt seiner Common Criteria dieser Aufgabe (CC3.1 bis CC3.4). Die HIPAA Security Rule macht die Risikoanalyse zur ersten verpflichtenden Implementierungsspezifikation (§164.308(a)(1)(ii)(A)), und sie ist das erste Dokument, das HHS-Ermittler anfordern. Viele Organisationen führen drei durch. Eine genügt.

Was jedes Framework prüft

• ISO 27001 verlangt eine definierte, wiederholbare Methode mit Akzeptanzkriterien; Risiken für Vertraulichkeit, Integrität und Verfügbarkeit, die identifiziert wurden; Risikoeigentümer; Analyse von Eintrittswahrscheinlichkeit und Auswirkung; sowie eine Verknüpfung mit der Risikobehandlung und der Erklärung zur Anwendbarkeit (Statement of Applicability).
• SOC 2 verlangt, dass Ziele klar genug festgelegt sind, um Risiken zu identifizieren (CC3.1), Risiken über die gesamte Einheit hinweg identifiziert und analysiert werden (CC3.2), Betrugsrisiken berücksichtigt werden (CC3.3) und Änderungen bewertet werden (CC3.4).
• HIPAA verlangt eine genaue und umfassende Bewertung der Risiken und Schwachstellen für ePHI, unabhängig davon, wo sie erstellt, empfangen, gespeichert oder übertragen werden; die Bewertung muss aktuell gehalten und durch Risikomanagement umgesetzt werden (§164.308(a)(1)(ii)(B)).

In unseren Daten sind diese Anforderungen direkt miteinander verknüpft:

Framework	Risikobewertung	Verknüpfung
NIST CSF 2.0	ID.RA-03ID.RA-04ID.RA-05ID.RA-06	Themendefinition
ISO 27001	Clause 6.1.2Clause 6.1.3	Crosswalk
CIS v8.1	—	Keine Zuordnung in unseren Daten
SOC 2	CC3.2CC3.4CC3.3	Redaktionell
PCI DSS	12.3.1	Crosswalk
CMMC	RA.L2-3.11.1	Crosswalk
800-53	RA-3RA-7	Crosswalk
HIPAA	§164.308(a)(1)(ii)(A)	Crosswalk
GDPR	Art.35(1)Art.35(7)	Redaktionell
NIS2	2.1	Crosswalk
Essential Eight	—	Keine Zuordnung in unseren Daten

Vollständige Details und die Begründung für jede Verknüpfung: Risikobewertung über Frameworks hinweg →

Eine Bewertung für alle drei gestalten

1. Auf vollständige Abdeckung ausrichten: den ISMS-Geltungsbereich, das SOC-2-System und jeden Standort von ePHI. Festhalten, welche Assets unter welches Framework fallen.
2. Eine Methode verwenden: asset- oder szenariobasiert, mit einer Skala für Eintrittswahrscheinlichkeit und Auswirkung, Akzeptanzkriterien und Eigentümern. Die Anforderungen der ISO an eine dokumentierte, wiederholbare Methode sind die strengsten, also sollten Sie diese erfüllen.
3. Frameworkspezifische Prüffragen ergänzen: Betrugsrisiko (SOC 2 CC3.3), ePHI-spezifische Bedrohungen und Schwachstellen (HIPAA) sowie rechtliche und vertragliche Risiken.
4. Jedes Risiko mit der Behandlung verknüpfen: gewählte Maßnahmen, Restrisiko, Akzeptanz durch den Eigentümer. Diese eine Tabelle speist die ISO-Erklärung zur Anwendbarkeit, die Kontrollaktivitäten von SOC 2 und das Risikomanagement nach HIPAA.

Ergebnisse, die alle drei Auditoren überzeugen

• Die Methode, genehmigt.
• Ein Risikoregister mit Eigentümern, Bewertungen und Behandlungsentscheidungen.
• Ein Risikobehandlungsplan mit Terminen.
• Akzeptanz des Restrisikos durch die Eigentümer.
• Nachweis einer Überprüfung mindestens jährlich und nach wesentlichen Änderungen.

Ein einfaches Format für das Risikoregister

Eine Zeile pro Risiko funktioniert für alle drei Frameworks:

Feld	Beispiel
Risiko	Ransomware verschlüsselt die Produktionsdatenbank
Assets	Produktionsdatenbank, Backups, ePHI-Speicher
Frameworks	ISO 27001, SOC 2, HIPAA
Eintrittswahrscheinlichkeit und Auswirkung	Möglich, schwerwiegend
Bestehende Maßnahmen	MFA, EDR, nächtliche Backups
Behandlung	Backups isolieren; Wiederherstellungen vierteljährlich testen
Eigentümer	Leiter Infrastruktur
Restrisiko und Akzeptanz	Mittel, akzeptiert vom CTO
Überprüfungsdatum	Nächstes Quartal

Die Spalte Frameworks ist der Kniff: Sie ermöglicht es, mit einem einzigen Register drei Auditoren zu bedienen, ohne drei Tabellenkalkulationen.

Kernaussagen

• Eine Methode und ein Register können ISO 27001, SOC 2 und HIPAA gleichzeitig erfüllen.
• Frameworkspezifische Prüffragen ergänzen: Betrugsrisiko und ePHI-Standorte.
• Mindestens jährlich und nach wesentlichen Änderungen überprüfen.

Häufige Befunde

• Generische Risiken („Hacker“, „Datenpanne“) ohne Bezug zu konkreten Assets oder Maßnahmen.
• Keine Eigentümer, oder das Sicherheitsteam ist Eigentümer jedes Risikos.
• ePHI-Standorte übersehen: Exporte, Backups, E-Mail, Testsysteme.
• Veraltet: einmal für das erste Audit bewertet und danach nie wieder.

Mehr dazu, wie diese Frameworks zusammenhängen, finden Sie im Vergleich ISO 27001 vs. HIPAA und im Thema Risk Assessment. Die Lückenanalyse zeigt jede Zuordnung zwischen zwei beliebigen Frameworks.

Fragen

Entspricht die HIPAA-Risikoanalyse einer Risikobewertung nach ISO 27001?

Sie überschneiden sich stark. HIPAA verlangt eine genaue und umfassende Bewertung der Risiken für Vertraulichkeit, Integrität und Verfügbarkeit von ePHI; eine Risikobewertung nach ISO 27001, die ePHI im Geltungsbereich erfasst und die HIPAA-spezifischen Elemente dokumentiert, kann beide erfüllen.

Wie oft muss eine Risikobewertung durchgeführt werden?

ISO 27001 verlangt Risikobewertungen in geplanten Abständen und nach wesentlichen Änderungen. SOC-2-Auditoren erwarten typischerweise eine Risikobewertung mindestens jährlich. HIPAA verlangt, dass die Risikoanalyse aktuell gehalten wird.

Sollte die Risikobewertung qualitativ oder quantitativ sein?

Beides funktioniert für alle drei Frameworks, solange die Methode definiert ist, konsistent angewendet wird und vergleichbare Ergebnisse liefert. Die meisten Organisationen beginnen qualitativ und ergänzen Zahlen dort, wo Entscheidungen sie brauchen.