Awareness-Training und Vulnerability Management: Was § 30 BSIG operativ verlangt

§ 30 BSIG ist das normative Rückgrat von NIS2 - zehn Pflichtbereiche, die jede betroffene Einrichtung umsetzen muss. Vom Risikoregister über Lieferkettensicherheit bis zur Multi-Faktor-Authentifizierung. Der Großteil dieser zehn Punkte bleibt für Geschäftsführungen und IT-Leitungen abstrakt: Was bedeutet „Risikoanalyse" konkret? Wie tief muss „Lieferkettensicherheit" gehen?

Zwei Pflichten sind anders. Sie sind operativ unmittelbar greifbar, sie produzieren wöchentlich messbare Daten und sie bilden die Schnittstelle, an der Cybersicherheit auf den Klinikalltag trifft: Schulungen und Sensibilisierung (Punkt 7) und Sicherheit beim Erwerb, der Entwicklung und Wartung (Punkt 5). In der Praxis übersetzt sich das in zwei zentrale Disziplinen: Awareness-Training und Vulnerability Management.

Dieser Guide zeigt, was § 30 BSIG für diese beiden Bereiche operativ verlangt - und was eine NIS2-konforme Umsetzung in einer Klinik, einem MVZ oder einem Pharma-Unternehmen praktisch bedeutet. Nicht als abstrakte Compliance-Diskussion, sondern als konkretes Drehbuch.

Drei Vorbemerkungen. Erstens: Awareness-Training und Vuln. Management sind nicht zwei unabhängige Pflichten, sondern zwei Hälften derselben Aufgabe. Mensch und Maschine sind die zwei großen Angriffsflächen - wer nur eine absichert, hat das Problem nicht gelöst. Zweitens: Beide Bereiche sind im Audit-Fall die ersten, die geprüft werden, weil sie über greifbare Artefakte verfügen (Schulungsnachweise, Scan-Reports). Drittens: NIS2 hat den Maßstab verschärft - ein einmaliges E-Learning oder ein jährlicher Schwachstellen-Scan reichen nicht mehr aus.

Awareness-Training - was § 30 BSIG verlangt

§ 30 Abs. 2 Nr. 7 BSIG verlangt „grundlegende Schulungen und Sensibilisierungsmaßnahmen im Bereich der Sicherheit in der Informationstechnik". Die NIS2-Richtlinie formuliert das in Art. 21 Abs. 2 Buchst. g als grundlegende Verfahren der Cyberhygiene und Schulungen im Bereich der Cybersicherheit.

Das klingt allgemein - und wird häufig zu allgemein interpretiert. In der Praxis fragen BSI-Auditor:innen, Wirtschaftsprüfer:innen und Cyber-Versicherer nach konkreten Belegen:

• Wer wurde wann geschult, mit welchem Inhalt, in welcher Dauer?

• Wie wird der Lerneffekt gemessen?

• Welche Anpassungen werden bei steigenden Klick-Raten getroffen?

• Wie werden neue Mitarbeitende ins System aufgenommen?

• Wie wird die Geschäftsführung selbst geschult (Pflicht nach § 38 BSIG)?

Was nicht reicht. Ein einmaliges 30-Minuten-Pflichtvideo beim Onboarding mit Häkchen-Bestätigung. Das war 2018 noch Standard, ist 2026 weder regulatorisch noch praktisch ausreichend. Der typische Phishing-Klick von gestern lernt aus Quizfragen von heute nicht - er lernt aus konkreten, realistischen Simulationen, die im Klinikalltag stattfinden.

Was reicht. Eine Kombination aus drei Komponenten:

1. Jährlicher Kernkurs mit konsistentem Inhalt (Phishing-Erkennung, Passwort-Hygiene, Datenschutz, Meldewege) und dokumentierter Teilnahme.

2. Regelmäßige Phishing-Simulationen (typisch monatlich), die reale Angriffsmuster aus dem Gesundheitssektor abbilden - gefälschte KIS-Mails, fingierte Dienstplan-Änderungen, falsche eRezept-Notifikationen.

3. Microlearning-Spotlights mehrmals pro Jahr zu aktuellen Themen (Cloud-Phishing, MFA-Bypass, KI-generierte Mails, sektorale Bedrohungen).

Diese Dreikombination dokumentiert sich quasi selbst: Schulungssystem-Logs für Punkt 1, Phishing-Plattform-Reports für Punkt 2, Spotlight-Teilnahme für Punkt 3. Aufbereitet zum Audit-Bericht - fertig.

Wichtig: Awareness ist nicht Aufgabe der IT, sondern der Personalentwicklung. Die IT liefert die Plattform, aber Inhalt, Frequenz und Tonalität gehören in HR-Hand. Andernfalls wird aus Awareness sehr schnell technisches Compliance-Theater, das die Belegschaft als Bevormundung erlebt.

Awareness-Training in der operativen Umsetzung

Wie sieht das in der Praxis aus? Vier Komponenten, die zusammen eine NIS2-konforme Awareness-Architektur ergeben:

Format: Microlearning statt Frontalbeschallung. Ein 60-Minuten-Webinar einmal im Jahr, auf dem niemand zuhört, ist kein Schulungsbeleg - es ist eine Compliance-Fiktion. Bewährt hat sich: vier kurze Module à etwa 5 Minuten, am Endgerät absolvierbar, mit kleinem Wissens-Check pro Modul. Die Belegschaft kann das in Wartephasen oder Pausen einbauen - die Akzeptanz ist deutlich höher als bei Pflichttermin-Formaten.

Frequenz: jährlicher Kernkurs plus drei Spotlights pro Jahr. Der Kernkurs deckt die Grundlagen ab (Phishing, Passwort, Datenschutz, Meldeweg). Die Spotlights ergänzen das Programm mit drei kurzen Auffrischungen - ein bis zwei Minuten, in den Quartalen ohne Kernkurs, ohne Wiederholung des Vorjahres. Damit greift die Schulungspflicht das ganze Jahr über, nicht nur einmal im Januar.

Zielgruppen: differenziert, nicht One-Size-Fits-All. Pflege, ärztlicher Dienst, Verwaltung, IT und Geschäftsführung haben unterschiedliche Angriffsvektoren und unterschiedlichen Lernbedarf. Pflegepersonal braucht Beispiele aus dem Stationsalltag (gefälschte KIS-Warnungen, fingierte Dienstplan-Änderungen). Die Verwaltung braucht CEO-Fraud-Szenarien und Rechnungs-Manipulation. Die IT braucht Privileged-Account-Risiken. Die Geschäftsführung braucht Whaling-Beispiele plus regulatorische Übersicht.

Phishing-Simulation als Wirksamkeits-Messung. Schulung ohne nachgelagerte Messung ist Schulung ins Blaue. Phishing-Simulationen sind die einzige Methode, die belastbar zeigt, ob Schulungsinhalte angekommen sind. Die zentralen Kennzahlen:

• Klick-Rate: Wer klickt auf simulierte Phishing-Links? (Erwartete Entwicklung: 25 bis 35 % Baseline → unter 10 % nach 12 Monaten)

• Meldequote: Wer meldet verdächtige Mails aktiv? (Erwartete Entwicklung: unter 5 % Baseline → über 30 % nach 12 Monaten)

• Trend je Bereich: Sinkt die Klickrate in Bereichen, die bereits Schulungsfeedback erhalten haben? (Indikator für strukturelles Risiko in einzelnen Teams - ausschließlich aggregiert)

Wichtig zu wissen: In Deutschland sind Phishing-Simulationen mitbestimmungspflichtig nach § 87 Abs. 1 Nr. 6 BetrVG. Eine saubere Betriebsvereinbarung mit ausschließlich aggregierter Auswertung, Zwecksetzung und Nutzungsverbot für Personalmaßnahmen ist Voraussetzung für den Start.

Dokumentation für den Audit-Fall. Konkrete Artefakte, die in der ISMS-Akte liegen müssen:

• Liste der durchgeführten Schulungen mit Datum, Inhalt, Dauer, Teilnehmenden

• Individuelle Teilnahmenachweise der Schulungen (Teilnahme, Modul, Datum)

• Quartalsweise Auswertung der Phishing-Simulationen mit Trend

• Jährliche Auswertung der Awareness-Programmwirksamkeit

• Schulungsnachweis der Geschäftsführung nach § 38 BSIG (mit Agenda und Teilnahmeliste)

Vulnerability Management - was § 30 BSIG verlangt

Vulnerability Management ist in § 30 BSIG nicht als eigene Pflicht benannt. Es ist verteilt auf zwei Punkte:

• Punkt 5: Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, einschließlich Management und Offenlegung von Schwachstellen. Hier liegt das Patch-Management, die Schwachstellen-Behandlung und die sichere Konfiguration.

• Punkt 10: Multi-Faktor-Authentifizierung und gesicherte Sprach-, Video- und Textkommunikation. Hier landen MFA-Hygiene und gesicherte Fernzugriffe - beide eng verzahnt mit Vulnerability Management.

Was die Norm offenlässt: Frequenz, Tiefe, SLAs. NIS2 verzichtet bewusst auf detaillierte Vorgaben zugunsten von „Stand der Technik". Das ist regulatorisch elegant - aber operativ verwirrend, weil „Stand der Technik" kein Auditkriterium ist, das man abhaken kann.

In der Praxis hat sich folgende Übersetzung etabliert:

Asset-Inventar als Pflicht-Basis. Vulnerability Management ohne Asset-Inventar ist blind. Wer nicht weiß, welche Geräte im Netz hängen - Server, Workstations, medizinische Geräte, IoT, mobile Endgeräte - kann keine Schwachstellen suchen. Ein vollständiges Asset-Inventar mit Kategorisierung (Typ, OS, Patch-Stand, Standort, Verantwortlicher) ist die erste Pflichtleistung.

Scanning-Frequenz. Stand der Technik ist kontinuierliches Scanning für IT-Infrastruktur, nicht punktuelle Prüfungen. Externe (Internet-exponierte) Systeme: täglich. Interne Systeme: wöchentlich. Wer einmal im Jahr scannt, erfüllt nicht den Stand der Technik. Medizinische Geräte werden hingegen nicht aktiv gescannt - gängige Praxis ist passive Netzwerk-Discovery in Kombination mit CVE-Abgleich und SBOM-Analyse, weil aktive Scans auf IoMT-Geräten zu Ausfällen im klinischen Betrieb führen können.

Authentifiziertes Scanning. Nicht alle Schwachstellen sieht man von außen. Authentifiziertes Scanning - das heißt: mit gültigen Login-Credentials auf den Zielsystemen - deckt Konfigurationsschwächen, veraltete Bibliotheken, lokale Patch-Stände und Default-Credentials auf. Unauthentifiziertes Scanning sieht nur die Außenseite und unterschätzt das reale Risiko regelmäßig.

Klinisch gewichtete Priorisierung. Ein CVSS-Score von 9,8 auf einer Bürodrucker-Webschnittstelle ist weniger kritisch als ein CVSS 7,2 im PACS-Server. Die generische CVSS-Bewertung muss klinisch kontextualisiert werden - Patientennähe, Versorgungskritikalität, Ausweichmöglichkeiten. Andernfalls patchen IT-Teams die spektakulären, aber unkritischen Lücken zuerst und die mittelgroßen, aber versorgungskritischen zuletzt.

Remediation-SLAs. Stand der Technik schreibt nicht „alles sofort patchen", sondern „Risiko-priorisierte Behandlung mit SLAs". Üblich in NIS2-konformen Setups: kritische Schwachstellen (CVSS ≥ 9, exploitable, exposed) binnen 7 bis 14 Tagen, hohe Schwachstellen binnen 30 Tagen, mittlere binnen 90. Wer dokumentiert nicht patcht, dokumentiert kompensierende Maßnahmen - zusätzliche Netzsegmentierung, intensiviertes Monitoring, eingeschränkter Zugriff.

Vulnerability Management in der operativen Umsetzung

In der praktischen Umsetzung ergeben sich vier kritische Komponenten:

Asset-Discovery kontinuierlich, nicht punktuell. Klinik-Netze ändern sich täglich. Neue medizinische Geräte werden angeschlossen, Wartungspersonal bringt Notebooks mit, Cloud-Workloads kommen und gehen. Klassisches Inventar-Excel ist 24 Stunden nach Erstellung veraltet. Stand der Technik: agentbasiertes Asset-Tracking plus Netzwerk-Discovery, kombiniert.

Medizinprodukte als Sonderfall (IEC 80001-1). Im klinischen Umfeld gilt eine Besonderheit: Patches an Medizinprodukten unterliegen der MDR und können das Konformitätsverfahren des Herstellers betreffen. Ein eigenmächtiger Sicherheits-Patch durch die Klinik-IT kann technisch eine Veränderung des Medizinprodukts bedeuten - mit haftungsrechtlichen Folgen. Lösung: Patch-Anforderungen an den Hersteller dokumentieren, Antwortzeiten messen, kompensierende Maßnahmen (Netzwerksegmentierung, Monitoring) bei Patch-Verzögerung implementieren.

Authentifiziertes Scanning der kritischen Systeme. KIS, PACS, LIS, Active Directory, Backup-Systeme - die Kerninfrastruktur muss authentifiziert gescannt werden, nicht nur von außen. Häufige Findings in Klinik-Setups:

• Veraltete Bibliotheken in Java- und Python-basierten Anwendungen (Log4Shell-Klasse)

• Fehlende Patches auf Workstations, weil Updates nur in Wartungsfenstern laufen

• Default-Credentials auf medizinischen Geräten („admin/admin", „service/service")

• Ungesicherte Wartungsschnittstellen (Telnet, alte SMB-Versionen)

• Inkonsistente Berechtigungen in Active Directory

Remediation mit SLA und Eskalation. Jede kritische Schwachstelle bekommt einen Verantwortlichen, einen SLA und einen Eskalationspfad. Wenn der Hersteller binnen 14 Tagen keinen Patch liefert, eskaliert die Klinik zu kompensierenden Maßnahmen - zusätzliche Netzwerksegmentierung, intensiviertes Monitoring, gegebenenfalls zeitweise Außerbetriebnahme des betroffenen Systems.

Dokumentation für den Audit-Fall. Konkrete Artefakte:

• Asset-Inventar mit Patch-Stand und Verantwortlichen

• Wöchentliche Scan-Reports mit Diff zum Vormonat

• Quartalsweise Trend-Reports nach Versorgungsbereich

• Liste offener Schwachstellen mit Risiko-Bewertung, SLA und kompensierenden Maßnahmen

• Hersteller-Korrespondenz zu Medizinprodukte-Patches

• Jährlicher Penetrationstest oder externe Validierung

Die Trennung zwischen „wir scannen" und „wir managen Schwachstellen" ist dabei essenziell. Der Scan ist die einfachere Hälfte. Die schwerere Hälfte ist die Begleitung von der Erkennung zur Schließung - und die Dokumentation, dass nicht alles behoben werden kann, aber alles bewertet wurde.

Awareness-Training und Vulnerability Management als Doppelhebel

Warum nicht nur eines von beiden? Weil Mensch und Maschine zwei strukturell verschiedene Angriffsflächen sind, die sich nicht gegenseitig kompensieren.

Der Mensch ist der Initial-Vektor. Laut ENISA Threat Landscape 2025 beginnen rund 60 Prozent der beobachteten Angriffe in der EU mit Phishing - per Mail, Telefon oder manipulierter Werbung. Awareness-Training ohne Vuln. Management bedeutet: Mitarbeitende erkennen Phishing-Mails, aber wenn ein Angreifer trotzdem reinkommt, findet er ein ungepatchtes System, in dem er sich frei bewegen kann.

Die Maschine ist der Verstärker. Das Ausnutzen von Schwachstellen ist laut ENISA mit 21,3 Prozent der zweithäufigste Einstiegsweg. Das BSI zählt im Lagebericht 2025 im Schnitt 119 neue Schwachstellen pro Tag - rund 24 Prozent mehr als im Vorjahr. Vuln. Management ohne Awareness-Training bedeutet: Die Systeme sind gepatcht, aber ein einziger Phishing-Klick liefert dem Angreifer gültige Zugangsdaten - und damit einen Weg an jeder Schwachstellen-Behandlung vorbei.

Beide bedienen die § 32 BSIG-Vorbereitung. Im Vorfall-Fall fragen BSI-Auditor:innen sowohl nach Schulungsnachweisen als auch nach Schwachstellen-Behandlungs-Reports. Wer beim Vorfall keine Awareness-Dokumentation vorlegen kann, hat im Bußgeldverfahren keinen Schutzschirm - wer keine Daten aus dem Vulnerability Management vorlegen kann, ebenfalls nicht.

Verbindung zu § 38 BSIG-Geschäftsführer­haftung. Die Haftung der Geschäftsleitung gegenüber der eigenen Einrichtung wird im Streitfall nicht über abstrakte Strategien beurteilt, sondern über konkrete operative Belege. Awareness-Training und Vuln. Management sind die zwei Bereiche, die die meisten Belege produzieren - saubere Reports zeigen Aufsichtspflicht erfüllt, fehlende Reports zeigen Pflichtverletzung.

Operative Synergie. Awareness-Training und Vuln. Management ergänzen sich in der Auswertung: Aggregierte Klickraten je Bereich und offene Schwachstellen je Bereich zeigen gemeinsam, wo das Risiko am größten ist. Die beiden Disziplinen ergänzen sich nicht nur regulatorisch, sondern operativ - wenn sie als Gesamtsystem aufgesetzt sind, nicht als zwei isolierte Projekte.

Was im Audit gefragt wird

Im BSI-Audit oder bei einer Wirtschaftsprüfer-Prüfung zu NIS2 sind Awareness-Training und Vuln. Management die ersten Bereiche, die geprüft werden - weil sie operativ greifbare Artefakte produzieren. Typische Fragen:

Awareness-Training:

• Wer wurde im letzten Jahr geschult? Liste mit Datum und Inhalt vorlegen.

• Wie messen Sie die Wirksamkeit Ihrer Schulungen? Phishing-Simulations-Reports der letzten 12 Monate vorlegen.

• Wie ist die Geschäftsleitung selbst geschult? Schulungsprotokoll mit Agenda und Teilnehmerliste vorlegen.

• Wie reagieren Sie auf Bereiche mit dauerhaft hoher Klickrate? Konzept für gezielte, freiwillige Zusatzschulungen zeigen - ohne Einzelauswertung.

• Wie werden neue Mitarbeitende ins Awareness-System aufgenommen? Onboarding-Prozess dokumentieren.

Vulnerability Management:

• Liegt ein Asset-Inventar vor? Vollständig, aktuell?

• Wann fand der letzte Scan statt? Authentifiziert oder unauthentifiziert?

• Wie werden Schwachstellen priorisiert? Liste der aktuell offenen kritischen Findings vorlegen.

• Wie ist die SLA-Treue? Trend der letzten zwölf Monate.

• Wie werden Medizinprodukte behandelt? Hersteller-Korrespondenz vorlegen.

• Wann fand der letzte Penetrationstest statt? Bericht und Remediation-Status.

Drei Punkte führen typisch zu Audit-Findings:

1. Schulungen ohne Wirksamkeits-Messung. Wer Inhalte ausspielt, aber keine Phishing-Simulation laufen hat, kann keine Belege für Effektivität liefern.

2. Asset-Inventar lückenhaft. Vergessene medizinische Geräte, mobile Endgeräte ohne Erfassung, Cloud-Workloads außerhalb der Inventar-Logik.

3. Patch-SLA reine Theorie. Auf dem Papier 14-Tage-SLA, in der Praxis 90-Tage-Realität ohne dokumentierte kompensierende Maßnahmen.

Diese Punkte werden nicht aus Bösheit gefunden - sie sind die häufigsten realen Schwachstellen.

Häufige Fehler

„Wir haben ja eine Awareness-Plattform." Lizenzbesitz ist nicht Awareness-Programm. Wer eine Plattform hat, sie aber nicht systematisch betreibt, hat das Compliance-Risiko nicht gelöst.

„Vulnerability Management macht der MSSP." Häufige Annahme, oft falsch. Viele Managed-Service-Verträge decken nur Detection ab, nicht Remediation. Klärung im Vertrag: Wer scannt, wer priorisiert, wer schließt, wer dokumentiert?

„Awareness ist eine Pflichtübung." Belegschaften erkennen das innerhalb von Wochen. Wer Awareness als formale Compliance-Aufgabe behandelt, bekommt formale Compliance - keine Verhaltensänderung.

„Patches blockieren den Klinikbetrieb." Manchmal stimmt das. Aber dann gilt: Risiko-Bewertung, kompensierende Maßnahmen, Dokumentation. Nicht: Patch ignorieren und hoffen.

„Wir wollen keinen Audit-Theater-Aufwand." Nachvollziehbar - und falsch. Ohne Dokumentation gibt es im Vorfall-Fall weder Versicherungsschutz noch Verteidigungslinie gegen § 38 BSIG-Haftung.

„Geschäftsführer-Schulung machen wir nächstes Jahr." § 38 BSIG ist nicht aufgeschoben - die Pflicht greift seit 6. Dezember 2025. Wer noch keine Schulung dokumentiert hat, ist im Vorfall-Fall ohne Nachweis.

Fazit

Awareness-Training und Vulnerability Management sind die zwei Hälften einer operativen NIS2-Umsetzung, die im Audit-Fall zuerst sichtbar werden. § 30 BSIG verlangt sie, Art. 21 NIS2 konkretisiert sie, § 38 BSIG verschärft die Verantwortlichkeit über die Haftung der Geschäftsleitung gegenüber der eigenen Einrichtung.

Was beide Bereiche teilen: Sie funktionieren nur als kontinuierlicher Dauerbetrieb, nicht als Projekt mit Anfang und Ende. Awareness-Training ohne monatliche Phishing-Simulation und quartalsweise Spotlights verpufft. Vuln. Management ohne wöchentliches Scanning und SLA-Tracking ist Compliance-Theater.

Was beide Bereiche teilen: Sie produzieren Daten, die im Audit-Fall die wichtigsten Belege sind. Wer die Daten hat, ist regulatorisch aufgestellt. Wer sie nicht hat, ist im Bußgeldverfahren ohne Schutzschirm.

Was beide Bereiche teilen: Sie sind in der internen Umsetzung anspruchsvoll, weil sie laufenden Betrieb erfordern. Eine Klinik mit drei IT-Mitarbeitenden kann ein kontinuierliches Vulnerability Management neben dem Tagesgeschäft selten stemmen - und ein systematisches Awareness-Programm mit differenzierten Zielgruppen, monatlichen Kampagnen und Geschäftsleitungs-Reporting noch seltener. Genau hier setzen externe Services an: Sie liefern den kontinuierlichen Betrieb, ohne dass die Einrichtung selbst Spezialist:innen beschäftigen muss.

Bei Entropy CS bieten wir Awareness-Training und Vulnerability Management für Gesundheitswesen, Versorger und Industrie - branchenspezifische Phishing-Szenarien, monatliche Kadenz, NIS2-konforme Dokumentation und Reporting für Geschäftsleitung und Audit. Unser kostenloser Risk Check dauert 30 Minuten und liefert eine ehrliche Bewertung Ihres aktuellen Reifegrads in beiden Bereichen - inklusive konkreter Prioritäten für die nächsten 12 Monate. Für den ersten Pflichtbereich - die Risikoanalyse selbst - gibt es unser Cyber Risk Assessment.