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: Cyberhygiene und Schulungen (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 und VM 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 — was § 30 BSIG verlangt

§ 30 Abs. 2 Nr. 7 BSIG verlangt „Konzepte und Verfahren zur Cyberhygiene sowie Schulungen im Bereich der Sicherheit von Netz- und Informationssystemen". Die NIS2-Richtlinie konkretisiert das in Art. 21 Abs. 2(g): Schulungen müssen die Belegschaft in die Lage versetzen, „Cyberangriffe zu erkennen, zu vermeiden und ihre Auswirkungen zu minimieren".

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 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 bis fünf kurze Module à 4 bis 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)

• Repeat-Klick-Rate: Klicken Mitarbeitende wiederholt nach Schulungsfeedback? (Indikator für strukturelles Risiko in einzelnen Teams)

Wichtig zu wissen: In Deutschland sind Phishing-Simulationen mitbestimmungspflichtig nach § 87 Abs. 1 Nr. 6 BetrVG. Eine saubere Betriebsvereinbarung mit Anonymisierung, 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

• Schulungsnachweise individuell (anonymisiert oder pseudonymisiert)

• 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: Sicherheit beim Erwerb, der Entwicklung und Wartung von Netz- und Informationssystemen. Hier liegt das Patch-Management, die Schwachstellen-Behandlung und die sichere Konfiguration.

• Punkt 10: Multi-Faktor-Authentifizierung und gesicherte Sprach-, Video- und Textverbindungen. 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, nicht punktuelle Prüfungen. Externe (Internet-exponierte) Systeme: täglich. Interne Systeme: wöchentlich. Medizinische Geräte: in herstellerfreigegebenen Fenstern, oft monatlich. Wer einmal im Jahr scannt, erfüllt nicht den Stand der Technik.

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 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. Verizon Data Breach Investigations Report 2024: 68 Prozent aller Vorfälle hatten einen menschlichen Faktor — meistens Phishing oder Credential-Diebstahl. Awareness ohne VM 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. Verizon DBIR 2024 zeigte einen 180-Prozent-Anstieg an Vulnerability-Exploitation als Initialvektor; im 2025-Bericht wuchs der Anteil um weitere 34 Prozent auf 20 Prozent aller Breaches. VM ohne Awareness bedeutet: Kein erfolgreicher Phishing-Klick öffnet die Tür — aber Web-Server-Schwachstellen oder VPN-Lücken sind direkt ausnutzbar.

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 VM-Daten vorlegen kann, ebenfalls nicht.

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

Operative Synergie. Awareness und VM teilen sich Daten: Wer in der Phishing-Simulation klickt, sitzt oft an einem System mit nicht installierten Patches. Wer Schwachstellen meldet, war vorher in einer Awareness-Schulung. 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 und VM die ersten Bereiche, die geprüft werden — weil sie operativ greifbare Artefakte produzieren. Typische Fragen:

Awareness:

• 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.

• Was passiert mit Mitarbeitenden, die wiederholt Phishing-Tests fehlschlagen? Eskalations-Konzept zeigen.

• 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 persönliche Haftung der Geschäftsleitung.

Was beide Bereiche teilen: Sie funktionieren nur als kontinuierlicher Dauerbetrieb, nicht als Projekt mit Anfang und Ende. Awareness ohne monatliche Phishing-Simulation und quartalsweise Spotlights verpufft. VM 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 24/7-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 Managed Services an: Sie liefern den kontinuierlichen Betrieb, ohne dass die Einrichtung selbst Spezialist:innen beschäftigen muss.

Bei Entropy CS bieten wir Managed Awareness-Training und Managed Vulnerability Management speziell für das Gesundheitswesen — klinikspezifische Phishing-Szenarien, monatliche Kadenz, NIS2-konforme Dokumentation und Reporting für Geschäftsleitung und Audit. Unser kostenloses Risk Assessment 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.