Das Hinweisgeberschutzgesetz (HinSchG) schützt seit Juli 2023 auch Personen, die Cybersecurity-Verstöße in Unternehmen melden. Für die Praxis heißt das: Wenn ein IT-Sicherheitshinweis einen Verstoß im Sinne von § 2 HinSchG betrifft, brauchen Unternehmen nicht nur einen sicheren Meldeweg, sondern auch ein Verfahren, das Vertraulichkeit, zügige Rückmeldung und Schutz vor Repressalien organisiert.
Für viele Unternehmen ist der wichtigste Punkt sofort klarzustellen: Das HinSchG ist kein allgemeines Gesetz für jede beliebige Sicherheitslücke und auch kein Ersatz für ein Vulnerability-Disclosure-Programm. Es schützt Hinweisgeber bei Meldungen über Verstöße im gesetzlichen Anwendungsbereich. Gerade in der Cybersecurity überschneiden sich dabei strafbare Handlungen, Datenschutzverstöße, Verstöße gegen IT-Sicherheitsvorgaben und interne Governance-Defizite. Wer diese Schnittstelle sauber organisiert, reduziert Rechtsrisiken und verbessert zugleich die Reaktionsfähigkeit bei Sicherheitsproblemen.
Wenn Sie die operativen Schnittstellen zu Responsible Disclosure vertiefen möchten, lesen Sie ergänzend unseren Beitrag zu Vulnerability Disclosure in Deutschland. Für die Einordnung von strukturierten Programmen ist außerdem der Leitfaden zu Bug-Bounty-Programmen in Deutschland relevant. Wie saubere Dokumentation später haftungsentlastend wirken kann, zeigen wir im Beitrag zum Schulungsnachweis und Haftungsschutz.
Was ist das HinSchG und warum ist es für Cybersecurity relevant?
Das HinSchG ist für Cybersecurity relevant, weil es Hinweisgeber schützt, die im beruflichen Zusammenhang Informationen über bestimmte Rechtsverstöße melden. Nach § 1 HinSchG sind nicht nur Beschäftigte im engen arbeitsrechtlichen Sinn erfasst, sondern allgemein natürliche Personen, die im Zusammenhang mit ihrer beruflichen Tätigkeit oder im Vorfeld einer solchen Tätigkeit Informationen über Verstöße erlangt haben.
Für die Cybersecurity-Praxis ist der sachliche Anwendungsbereich nach § 2 HinSchG entscheidend. Er erfasst erstens strafbewehrte Verstöße, zweitens bestimmte bußgeldbewehrte Verstöße und drittens eine Reihe konkret benannter Rechtsgebiete. Dort finden sich für IT-nahe Fälle vor allem Datenschutz, Schutz der Privatsphäre in der elektronischen Kommunikation und bestimmte Vorgaben zur Sicherheit in der Informationstechnik. Hinzu kommt: Auch ein Cybersecurity-Hinweis auf eine strafbare Handlung, etwa Ausspähen von Daten, Sabotage, Betrug, Untreue oder Manipulation von Protokollen, kann unter das HinSchG fallen, weil § 2 Abs. 1 Nr. 1 strafbewehrte Verstöße erfasst.
Wichtig ist die Präzision. Nicht jede unsaubere Konfiguration, jeder veraltete Patchstand und jede theoretische Schwachstelle ist automatisch ein HinSchG-Fall. Das Gesetz schützt Meldungen über Verstöße oder begründete Verdachtsmomente, nicht jede technische Unzulänglichkeit als solche. In der Praxis wird ein Cybersecurity-Sachverhalt vor allem dann HinSchG-relevant, wenn ein Rechtsverstoß naheliegt oder wenn die Schwachstelle unmittelbar in einen geregelten Pflichtbereich hineinreicht, etwa Datenschutz, Informationssicherheit regulierter Einrichtungen oder die Verschleierung eines Vorfalls.
Genau deshalb sollten Unternehmen Cybersecurity-Meldungen nicht nur dem SOC oder der IT zuordnen. Ein Vorfall kann zugleich technisch, arbeitsrechtlich, datenschutzrechtlich und whistleblowing-relevant sein. Diese Mehrfachperspektive wird für die Geschäftsführung noch wichtiger, wenn KI-Systeme oder automatisierte Entscheidungen involviert sind. Dort lohnt auch der Blick auf unseren Beitrag zur Geschäftsführerhaftung nach KI-Verordnung, weil Governance-Lücken selten isoliert auftreten.
Meldestelle einrichten — Pflicht ab 50 Mitarbeitenden
Private Beschäftigungsgeber mit in der Regel mindestens 50 Beschäftigten müssen eine interne Meldestelle einrichten und betreiben. Die Grundpflicht folgt aus § 12 Abs. 1 HinSchG; für Unternehmen mit 50 bis 249 Beschäftigten galt die Übergangsfrist nach § 42 Abs. 1 HinSchG nur bis zum 17. Dezember 2023.
Für die IT-Sicherheitsorganisation ist diese Schwelle deshalb relevant, weil ab 50 Mitarbeitenden nicht mehr nur eine informelle E-Mail-Adresse oder ein allgemeines Ticketsystem genügt. Die interne Meldestelle ist ein rechtlich strukturierter Kanal. Nach dem HinSchG müssen Meldungen schriftlich und mündlich möglich sein; außerdem muss auf Ersuchen ein persönliches Treffen innerhalb einer angemessenen Zeit ermöglicht werden. Unternehmen brauchen also einen Meldeprozess, der auch für sensible IT-Hinweise funktioniert, ohne Hinweisgeber auf offene Teamkanäle oder Vorgesetzte zu verweisen.
Ebenso wichtig ist die Vertraulichkeit. § 8 HinSchG schützt die Identität der hinweisgebenden Person, der von einer Meldung betroffenen Personen und weiterer in der Norm genannter Personen. Für Cybersecurity-Fälle bedeutet das organisatorisch mehr als bloße Verschwiegenheit: Zugriffe auf Meldungen sollten rollenbasiert begrenzt, Logging und Weitergaben dokumentiert und Auswertungen so gestaltet werden, dass sich Hinweisgeber nicht faktisch aus Metadaten oder kleinen Verteilerkreisen identifizieren lassen.
Die Fristen sind kurz. Interne Meldestellen müssen den Eingang einer Meldung grundsätzlich spätestens nach sieben Tagen bestätigen und der hinweisgebenden Person innerhalb von drei Monaten eine Rückmeldung über geplante oder bereits ergriffene Folgemaßnahmen geben. Unternehmen, die diese Fristen nicht in ihre Incident- und Compliance-Prozesse integrieren, riskieren nicht nur organisatorische Defizite, sondern auch den Verlust von Vertrauen in den Meldekanal.
Für Cybersecurity empfiehlt sich daher eine klare Trennung zwischen Meldestelle und technischer Bearbeitung. Die Meldestelle nimmt den Hinweis vertraulich entgegen, prüft die HinSchG-Relevanz, dokumentiert Fristen und steuert die Kommunikation. Die technische Prüfung der Schwachstelle, der Logdaten oder des Systems kann dann in einem separaten, need-to-know-basierten Prozess erfolgen. So bleibt der Schutzkanal intakt, ohne die Sicherheitsanalyse zu blockieren.
IT-Sicherheitsverstöße als meldepflichtige Sachverhalte
IT-Sicherheitsverstöße können meldepflichtige Sachverhalte sein, wenn sie in den Anwendungsbereich des § 2 HinSchG fallen. Am häufigsten betrifft das in der Praxis drei Gruppen: strafbare Handlungen, Datenschutz- und Kommunikationsverstöße sowie Verstöße gegen spezielle IT-Sicherheitsvorgaben.
Die erste Gruppe sind strafbewehrte Sachverhalte. Dazu gehören etwa unbefugte Zugriffe auf Daten, Manipulationen, Sabotagehandlungen, Erpressung, verdeckte Passwortweitergaben, absichtliche Umgehung von Schutzmaßnahmen oder die Verschleierung eines Vorfalls. Wenn Beschäftigte oder Dienstleister solche Handlungen bemerken und im beruflichen Kontext melden, ist die HinSchG-Relevanz regelmäßig naheliegend.
Die zweite Gruppe betrifft Datenschutz und elektronische Kommunikation. § 2 Abs. 1 Nr. 3 Buchst. o und p HinSchG nennt ausdrücklich den Schutz der Privatsphäre in der elektronischen Kommunikation und den Schutz personenbezogener Daten im Anwendungsbereich der DSGVO. Eine offenstehende Datenbank, ein unzulässiger Zugriff auf Kundendaten, eine unsichere Protokollierung von Zugängen oder die Nichtmeldung eines gravierenden Datenschutzvorfalls können deshalb durchaus HinSchG-relevant sein, wenn sie als Verstoß oder begründeter Verdacht geschildert werden.
Die dritte Gruppe betrifft regulierte IT-Sicherheitsvorgaben. § 2 Abs. 1 Nr. 3 Buchst. q HinSchG bezieht bestimmte Vorgaben zur Sicherheit in der Informationstechnik im Sinne des BSI-Gesetzes ein. Das ist nicht jeder Handwerksbetrieb und nicht jedes SaaS-Unternehmen, aber für besonders wichtige und wichtige Einrichtungen kann diese Norm direkte Relevanz entfalten. Für betroffene Unternehmen entsteht daraus eine doppelte Aufgabe: Sie müssen technische Sicherheitsanforderungen erfüllen und zugleich einen geschützten Meldeweg für Verstöße gegen diese Anforderungen bereitstellen.
Praktisch sollten Unternehmen ihre Beispiele klar benennen. Meldewürdig können unter anderem sein:
| Cybersecurity-Sachverhalt | Mögliche HinSchG-Relevanz | Zuständigkeit im Unternehmen |
|---|---|---|
| Unbefugter Zugriff auf Kundendaten | strafbarer und datenschutzrechtlicher Verstoß | Meldestelle, Datenschutz, IT-Security |
| Bewusst unterlassene Schließung einer bekannten kritischen Lücke | möglicher Verstoß gegen Organisations- und Schutzpflichten | Meldestelle, IT, Compliance |
| Manipulation von Logfiles nach einem Angriff | möglicher strafbarer Verstoß und Vertuschung | Meldestelle, IT-Forensik, Recht |
| Unsicherer externer Zugriff auf Systeme regulierter Einrichtung | möglicher Verstoß gegen IT-Sicherheitsvorgaben | Meldestelle, IT-Security, Compliance |
| Allgemeine Produktschwäche ohne Rechtsverstoß | nicht automatisch HinSchG-Fall | Produkt, Security, ggf. Disclosure-Prozess |
Die Abgrenzung zu gewöhnlichem Incident Reporting bleibt dabei wichtig. Ein Phishing-Versuch, der sofort im Security-Tool landet, ist noch kein Whistleblowing-Sachverhalt. Wird aber intern systematisch ignoriert, manipuliert oder vertuscht, kann daraus sehr wohl ein HinSchG-Fall werden.
Schutz für Hinweisgeber bei Cybersecurity-Meldungen
Das HinSchG schützt Hinweisgeber bei Cybersecurity-Meldungen, wenn die Voraussetzungen des § 33 HinSchG erfüllt sind. Die meldende Person muss intern oder extern melden oder unter den gesetzlichen Voraussetzungen offenlegen, sie muss hinreichenden Grund zur Annahme haben, dass ihre Informationen zutreffen, und der gemeldete Sachverhalt muss in den Anwendungsbereich des Gesetzes fallen oder aus Sicht der Person plausibel darunter fallen.
Für Unternehmen ist besonders wichtig, dass der Schutz nicht erst nach gerichtlicher Bestätigung eines Verstoßes einsetzt. Es genügt keine freie Behauptung, aber auch kein bereits bewiesenes Delikt. Entscheidend ist, dass zum Zeitpunkt der Meldung nachvollziehbare Gründe für die Annahme bestanden, dass die Information wahr und rechtlich relevant ist. Gerade in Cybersecurity-Fällen, in denen technische Untersuchungen Zeit brauchen, ist dieser Maßstab praxisnah.
§ 35 HinSchG regelt den Ausschluss der Verantwortlichkeit in einem wichtigen, aber oft missverstandenen Umfang. Hinweisgeber sollen für die Beschaffung von oder den Zugriff auf Informationen, die sie melden oder offenlegen, nicht verantwortlich gemacht werden, sofern die Beschaffung oder der Zugriff nicht als solcher eine eigenständige Straftat darstellt. Genau an diesem Halbsatz hängt die rechtliche Brisanz vieler Security-Fälle: Das HinSchG schützt nicht jede Form aktiver Sicherheitsforschung, wenn der Weg zur Information selbst strafbar war.
Hinzu kommt das Repressalienverbot des § 36 HinSchG. Kündigungen, Versetzungen, schlechtere Beurteilungen, Entzug von Projekten, informelle Karriereblockaden oder Drohungen wegen einer berechtigten IT-Sicherheitsmeldung sind verboten. Besonders stark ist die Beweislastumkehr: Macht die hinweisgebende Person geltend, eine berufliche Benachteiligung wegen der Meldung erlitten zu haben, wird vermutet, dass es sich um eine Repressalie handelt. Das Unternehmen muss dann beweisen, dass die Maßnahme auf hinreichend gerechtfertigten Gründen beruhte.
Für Cybersecurity-Teams ist das relevant, weil Konflikte häufig verdeckt verlaufen. Ein Security Engineer, der auf eine unzulässige Fernwartung, ein hartcodiertes Passwort oder eine vertuschte Datenpanne hinweist, muss sich darauf verlassen können, dass der Hinweis nicht in ein Personalproblem umgedeutet wird. Wer hier nur auf technische Klärung setzt und den arbeitsrechtlichen Schutz vergisst, baut keinen wirksamen Meldekanal.
Spannungsfeld — §202c StGB (Hackerparagraph) vs. HinSchG
Das Spannungsfeld zwischen § 202c StGB und dem HinSchG besteht darin, dass das HinSchG Hinweisgeber schützt, strafrechtliche Grenzen aber nicht aufhebt. § 202c StGB stellt das Vorbereiten des Ausspähens und Abfangens von Daten unter Strafe, insbesondere wenn Passwörter, Sicherungscodes oder Programme beschafft, hergestellt oder zugänglich gemacht werden, deren Zweck die Begehung solcher Taten ist.
Für Security-Verantwortliche ist die praktische Folge unangenehm, aber klar: Das HinSchG ist kein Freibrief für aktives Testen, Reverse Engineering oder den Einsatz von Tools außerhalb einer belastbaren Berechtigungslage. § 35 Abs. 1 HinSchG hilft nur, soweit die Beschaffung der Information oder der Zugriff nicht selbst eine eigenständige Straftat darstellt. Wer also beim Aufdecken einer Schwachstelle aktiv Grenzen überschreitet, kann sich nicht ohne Weiteres auf das Hinweisgeberrecht berufen.
Das erklärt auch, warum Vulnerability Disclosure und Whistleblowing sauber getrennt werden sollten. Ein Vulnerability-Disclosure-Prozess regelt, wie Sicherheitslücken technisch und koordiniert an Hersteller oder Betreiber gemeldet werden, typischerweise mit Safe-Harbor-Regeln, Kontaktpunkten, Fristen und klaren Regeln zur erlaubten Prüfung. Das HinSchG regelt dagegen den Schutz von Personen, die Verstöße melden. Beides kann sich überschneiden, ist aber weder dogmatisch noch operativ dasselbe.
Für Unternehmen lautet die sichere Schlussfolgerung daher nicht, externe Forschung zu blockieren, sondern Zuständigkeiten zu ordnen. Ein veröffentlichter Disclosure-Prozess senkt die Eskalationswahrscheinlichkeit. Eine interne Meldestelle nach HinSchG schützt Personen im beruflichen Kontext. Beide Instrumente zusammen reduzieren Unsicherheit besser als der Versuch, jeden Fall in nur einen Kanal zu pressen.
Fall Modern Solution — Was Unternehmen daraus lernen
Der Fall Modern Solution zeigt, wie schnell eine Sicherheitsmeldung in Deutschland in ein Strafverfahren kippen kann. Nach den öffentlich berichteten Informationen entdeckte ein Programmierer 2021 im Umfeld eines Kundenprojekts bei dem E-Commerce-Dienstleister Modern Solution eine Sicherheitslücke, über die aufgrund eines im Klartext hinterlegten Passworts auf umfangreiche Kundendaten zugegriffen werden konnte.
Berichten zufolge meldete der Entdecker die Schwachstelle, wurde anschließend aber strafrechtlich verfolgt. Das Amtsgericht Jülich verurteilte ihn Anfang 2024 nach der Berichterstattung von heise und ComputerBase zu einer Geldstrafe von 3.000 Euro. In den Berichten ist von bis zu 700.000 betroffenen Datensätzen die Rede. Für die Debatte ist weniger jedes technische Detail entscheidend als die strukturelle Lehre: Selbst ein Responsible-Disclosure-Versuch schützt in Deutschland nicht automatisch vor strafrechtlichen Risiken.
Für das HinSchG ist der Fall lehrreich, weil er die Grenze des § 35 HinSchG sichtbar macht. Selbst wenn jemand subjektiv Missstände aufdecken will, bleibt die Frage, ob der Weg zur Information bereits als eigenständige Straftat gewertet werden kann. Dann greift der Verantwortlichkeitsausschluss des Hinweisgeberrechts gerade nicht vollständig. Aus dieser Konstellation ergibt sich die Notwendigkeit, technische Meldewege und rechtliche Schutzmechanismen getrennt, aber abgestimmt zu gestalten.
Unternehmen sollten aus Modern Solution vier Dinge lernen:
- Sicherheitskontakte müssen leicht auffindbar und professionell besetzt sein.
- Interne Meldestellen dürfen technische Hinweise nicht reflexhaft als illoyal behandeln.
- Disclosure- und Whistleblowing-Prozesse brauchen klare Zuständigkeitsgrenzen.
- Rechtsabteilung, Compliance und IT-Security müssen Eskalationen gemeinsam bewerten.
Wer diese Lehren ignoriert, erreicht das Gegenteil von Sicherheit. Forschende, Dienstleister und eigene Beschäftigte werden Hinweise dann entweder gar nicht mehr melden oder zu spät und unstrukturiert nach außen tragen. Beides erhöht das Risiko für Vorfälle, Reputationsschäden und Eskalationen mit Behörden.
Best Practices — Meldewege für IT-Sicherheitsprobleme
Die beste Praxis ist ein zweigleisiges Modell aus HinSchG-Meldestelle und technischem Disclosure-Prozess. So lassen sich geschützte Hinweise über Rechtsverstöße einerseits und koordinierte Schwachstellenmeldungen andererseits rechtssicher und effizient bearbeiten.
Ein belastbares Modell sieht so aus:
| Kanal | Zweck | Geeignet für | Mindestanforderung |
|---|---|---|---|
| Interne Meldestelle nach HinSchG | Hinweise auf Verstöße und Repressalien | Beschäftigte, Bewerber, Dienstleister im beruflichen Kontext | Vertraulichkeit, schriftlich und mündlich, 7-Tage-Bestätigung, 3-Monats-Rückmeldung |
| Technischer Security-Kontakt | Meldung von Schwachstellen und Sicherheitsvorfällen | interne und externe Melder | klare Kontaktadresse, Triage, Ticketing, Zuständigkeit |
| Veröffentlichtes Vulnerability-Disclosure-Programm | koordinierte Offenlegung | Sicherheitsforscher, Hersteller, Kunden | Scope, Safe-Harbor-Regeln, Reaktionsfristen, Eskalationsweg |
| Externe Meldestelle | rechtlich geschützter Ausweichkanal | Hinweisgeber bei fehlendem Vertrauen intern | Information über Zuständigkeit und Voraussetzungen |
Operativ sollten Unternehmen fünf Standards umsetzen. Erstens braucht die Meldestelle ein Cybersecurity-Routing, damit Hinweise mit möglichem Rechtsbezug nicht im Support versanden. Zweitens müssen Security, Datenschutz und Compliance definieren, wann ein technischer Fund zugleich ein HinSchG-Sachverhalt ist. Drittens sollten Melder transparent informiert werden, welcher Kanal wofür gedacht ist. Viertens ist eine dokumentierte Entscheidungsmatrix sinnvoll, um zwischen Security Incident, Datenschutzvorfall, Whistleblowing und Disclosure zu unterscheiden. Fünftens brauchen Führungskräfte eine klare Anweisung, dass Vergeltungsmaßnahmen wegen berechtigter Sicherheitsmeldungen unzulässig sind.
Wer diese Prozesslinie noch nicht sauber dokumentiert hat, sollte parallel Schulung und Nachweisstruktur mitdenken. Gerade im Streitfall zählt nicht nur, ob ein Kanal theoretisch existierte, sondern ob Mitarbeitende wussten, wie sie ihn sicher nutzen. Dazu passt erneut der Beitrag zum Schulungsnachweis und Haftungsschutz.
Häufig gestellte Fragen (FAQ)
Müssen IT-Sicherheitslücken intern gemeldet werden?
IT-Sicherheitslücken sollten intern gemeldet werden, aber nicht jede Lücke ist automatisch ein HinSchG-Fall. Das Gesetz wird relevant, wenn die Meldung einen Verstoß im Sinne von § 2 HinSchG betrifft oder der Melder dies plausibel annehmen durfte. Für Unternehmen bleibt ein interner Security-Meldeweg dennoch unabhängig davon Pflicht guter Governance.
Schützt das HinSchG auch externe Security-Researcher?
Das HinSchG kann auch externe Personen im beruflichen Kontext erfassen, schützt aber nicht pauschal jede Form externer Sicherheitsforschung. Maßgeblich sind §§ 1 und 33 HinSchG sowie die Frage, ob der gemeldete Sachverhalt unter § 2 fällt und ob der Weg zur Information selbst legal war. Genau hier bleibt das Spannungsfeld zu § 202c StGB bestehen.
Was ist der Unterschied zwischen HinSchG und Vulnerability Disclosure?
Das HinSchG ist ein Schutzregime für Hinweisgeber. Vulnerability Disclosure ist ein Prozessregime für den Umgang mit Schwachstellenmeldungen. Unternehmen brauchen in der Regel beides: einen rechtlich geschützten Meldekanal für Verstöße und einen technisch belastbaren Prozess für koordinierte Schwachstellenbehebung.
Ab wann gilt die Meldestellen-Pflicht?
Für private Beschäftigungsgeber mit 50 bis 249 Beschäftigten gilt die Pflicht zur internen Meldestelle seit dem 17. Dezember 2023. Unternehmen mit mindestens 250 Beschäftigten mussten bereits früher handeln, weil das HinSchG am 2. Juli 2023 in Kraft trat und die Übergangsregel des § 42 nur für die Gruppe 50 bis 249 galt.
Wie richtet man einen sicheren Meldekanal für IT-Hinweise ein?
Ein sicherer Meldekanal für IT-Hinweise kombiniert Vertraulichkeit, klare Zuständigkeit und eine Trennung von Meldeannahme und technischer Untersuchung. Unternehmen sollten schriftliche und mündliche Meldungen ermöglichen, Fristen nach dem HinSchG einhalten, eine begrenzte Zahl berechtigter Bearbeiter festlegen und parallel einen technischen Security-Kontakt oder ein Disclosure-Programm veröffentlichen.
CTA: Meldewege, Schulung und Governance jetzt sauber verzahnen
Wenn Ihr Unternehmen KI-, Compliance- und Cybersecurity-Risiken nicht getrennt nebeneinander, sondern in einer belastbaren Governance-Linie organisieren will, ist eine dokumentierte Schulung der schnellste Einstieg. Unser EU AI Act Kurs hilft Ihnen, Rollen, Verantwortlichkeiten, Nachweise und Kommunikationswege strukturiert aufzusetzen, damit Meldepflichten später nicht erst im Krisenfall improvisiert werden.
Wenn Sie vorab typische Praxisfragen sortieren möchten, vertiefen Sie anschließend die Beiträge zu Vulnerability Disclosure in Deutschland, Bug-Bounty-Programmen in Deutschland, Schulungsnachweis und Haftungsschutz und zur Geschäftsführerhaftung nach KI-Verordnung.