Deutschland hat die EU-Hinweisgeberrichtlinie mit dem Hinweisgeberschutzgesetz (HinSchG) umgesetzt. Für Software-Käufer ändert das die Ausgangslage: Es geht nicht mehr um die abstrakte Frage „gilt die Richtlinie?“, sondern um die praktische Frage „welche Software hilft uns, einen internen Meldekanal glaubwürdig zu betreiben?“
Dieser Artikel nimmt bewusst die Einkaufs- und Betriebsbrille ein. Er ist keine Rechtsberatung und trifft keine Aussage darüber, ob Ihre Organisation im Einzelfall verpflichtet ist oder welche Auslegung greift. Disclosurely ist Software — kein Rechtsprodukt, keine Behörde, keine Compliance-Garantie.
Warum Käufer HinSchG und Software trennen müssen
Anbieter werben gern mit Labels wie „HinSchG-konform“ oder „EU-compliant“. Für die Beschaffung sind solche Labels schwach, wenn sie nicht in Funktionen übersetzt werden.
Rechtlicher Rahmen und Softwareleistung sind zwei Ebenen:
| Ebene | Typische Fragen |
|---|---|
| Recht / Organisation | Wer ist verpflichtet? Wer ist Meldestelle? Welche Policy gilt? Wie werden Fristen und Schutz sichergestellt? |
| Software | Kann der Meldekanal sicher betrieben werden? Wie laufen Intake, Dialog, Fall, Zugriff und Nachweis? |
Software kann die zweite Ebene stark unterstützen. Die erste bleibt bei der Organisation — und ggf. bei Anwältinnen und Anwälten.
Der Software-relevante Kern des Kontexts
Unabhängig von Einzelfallfragen erwarten die meisten Käufer in Deutschland, dass ein System mindestens Folgendes operationalisieren hilft:
- Sicherer interner Meldekanal — nicht der allgemeine Posteingang
- Vertrauliche Bearbeitung mit begrenztem Zugriff
- Nachverfolgung inkl. Möglichkeit zur Kommunikation mit der meldenden Person
- Dokumentation des Fallverlaufs für interne Nachweise
- Klare Rollen zwischen Meldestelle, weiteren Prüfern und Admins
Das ist der Kaufraster. Ob und wie Anonymität auszugestalten ist, gehört in Policy und Rechtsprüfung — die Software sollte den gewählten Modus aber technisch tragen können.
Mehr zu Produktkategorie und Funktionen: EU-nahe Hinweisgeber-Software und Whistleblowing-Software.
Meldekanal vs. Meldestelle — der häufigste Begriffsfehler
Viele Ausschreibungen verlangen „eine Meldestelle als Software“. Das vermengt zwei Dinge:
- Interner Meldekanal: Weg/Tool für die Abgabe von Meldungen
- Interne Meldestelle: Organisatorische Funktion / Verantwortlichkeit
Kaufen Sie Software für den Kanal und die Fallunterstützung. Benennen und organisieren Sie die Meldestelle intern (oder mit externer Unterstützung). Details: Interner Meldekanal vs. interne Meldestelle.
Prüfliste für Software-Käufer (HinSchG-Kontext)
1. Intake und Erreichbarkeit
- Geschützter schriftlicher Meldeweg
- Klare Trennung von allgemeinen Ticketsystemen
- Möglichkeit, Hinweise strukturiert aufzunehmen
- Optional: Unterstützung weiterer Modalitäten, falls Ihr Betriebsmodell das vorsieht
2. Vertraulichkeit und Anonymität
- Rollenbasierter Zugriff
- Optionen für anonyme und/oder vertrauliche Meldung
- Anonyme Zwei-Wege-Kommunikation, wenn Anonymität Teil Ihres Modells ist
- Keine erzwungenen Identitätswege, die dem Policy-Versprechen widersprechen
3. Fristen und Nachverfolgung
Software „erfüllt“ keine Fristen von allein. Sie kann aber:
- Eingang und Bearbeitungsstatus sichtbar machen
- Erinnerungen und Workflow-Schritte unterstützen
- den Dialog mit der meldenden Person dokumentieren
Fragen Sie in der Demo: Wie steuern wir Follow-up, ohne den Fall zu verlieren?
4. Fallmanagement und Nachweise
- Zuweisung an Fallbearbeiter
- Statusmodell
- Anhänge / Dokumentation
- nachvollziehbarer Prüfpfad
- Export- oder Berichtsoptionen für Revision und Management
5. Sicherheit und Datenschutz (DSGVO)
- Verschlüsselung und Zugriffsschutz
- Hosting und Subprozessoren
- Auftragsverarbeitung und Lösch-/Retention-Unterstützung (konfigurierbar)
- klare Admin-Grenzen
Sicherheit vertiefen: Sicherheitskriterien.
6. Mehrere Einheiten und EU-Gruppen
Wenn Deutschland nur ein Standort unter vielen ist:
- getrennte Zugriffe je Gesellschaft möglich?
- mehrsprachige Meldeoberflächen?
- zentrales Oversight ohne unnötige Inhaltsweitergabe?
Siehe: Hinweisgebersysteme für mehrere EU-Standorte.
Warnsignale in Anbieterkommunikation
Meiden oder hinterfragen Sie Formulierungen wie:
- „staatlich zertifiziert“
- „behördlich genehmigt“
- „garantiert compliant“
- „offiziell zugelassen“
- „rechtsverbindlich HinSchG-konform ohne Ihr Zutun“
Seriöse Anbieter beschreiben Funktionen, Sicherheitsmaßnahmen und Betriebsoptionen — und machen klar, dass Compliance bei der Organisation liegt.
Was in die Ausschreibung / das Lastenheft gehört
Statt „muss HinSchG-compliant sein“ besser:
- Anonyme und/oder vertrauliche Meldung gemäß unserem Betriebsmodell
- Sichere Zwei-Wege-Kommunikation mit der meldenden Person
- Fallmanagement mit Status, Zuweisung, Anhängen
- Prüfpfad / Audit-Trail für interne Nachweise
- Rollen- und Rechtekonzept inkl. Konfliktvermeidung
- Dokumentation zu Hosting, AV-Vertrag, Subprozessoren
- Einführungszeit und Verantwortlichkeiten (was liefert Vendor, was Organisation)
Auswahlmethodik: Hinweisgebersystem richtig auswählen.
Rolle von Disclosurely
Disclosurely stellt Hinweisgeber-Software bereit, mit der Organisationen einen internen Meldekanal betreiben und Fälle strukturiert bearbeiten können — inklusive anonymer Aufnahme, Kommunikation, Fallmanagement und Prüfpfad.
Wir geben keine Rechtsberatung und behaupten keine behördliche Freigabe. Für Käufer im HinSchG-Kontext ist das Angebot ein Betriebsmittel, kein Ersatz für Policy, Schulung und rechtliche Prüfung.
Vom Rechtsrahmen zum Betriebs-Backlog
Ein praxistauglicher Weg für Käufer:
- Kontext sammeln: HinSchG / EU-Richtlinie als Rahmen, interne Policy als Soll-Zustand.
- Betriebsmodell skizzieren: Wer nimmt entgegen, wer prüft, wer entscheidet, wer berichtet?
- Software-Backlog ableiten: Intake, Dialog, Rechte, Fall, Nachweis, Sprachen, Einheiten.
- Markt vergleichen: Demos gegen das Backlog, nicht gegen Broschüren.
- RestRisiken benennen: Was Software nicht löst (Rechtsfragen, Kultur, Schulung) bleibt auf der Organisationsliste.
So vermeiden Sie, dass „Legal schreibt Requirements“ und „IT kauft Features“ aneinander vorbeilaufen.
Dokumentation, die Einkauf und Legal gemeinsam brauchen
Bitten Sie Anbieter früh um Unterlagen, die Beschaffung und Datenschutz prüfen können:
- Sicherheits- und Architekturübersicht
- Liste der Subprozessoren
- AV-Vertragsmuster / TOMs
- Rollen- und Rechtekonzept
- Angaben zu Export, Löschung und Retention-Unterstützung
- klarer Scope der Leistungen (was ist Software, was ist Service)
Fehlen diese Unterlagen, ist „EU-ready“ nur Rhetorik.
Interne Stakeholder und ihre unterschiedlichen Kaufkriterien
| Stakeholder | Typische Priorität |
|---|---|
| Compliance / Meldestelle | Bedienbarkeit, Dialog, Fallklarheit |
| Legal | Vertraulichkeit, Nachweis, klare Vendor-Grenzen |
| Security | Zugriffe, Verschlüsselung, Logging, Hosting |
| IT | SSO, Admin-Aufwand, Integrationen |
| Procurement | Preis, Vertrag, Exit, Vergleichbarkeit |
| Geschäftsleitung | Risiko, Reputation, Umsetzbarkeit |
Ein Anbieter, der nur eine dieser Gruppen überzeugt, scheitert später im Betrieb.
Deutschland in internationalen Gruppenprogrammen
Wenn die deutsche Gesellschaft Teil eines EU-weiten Rollouts ist, prüfen Sie zusätzlich:
- Sind deutsche Texte und Nutzerhinweise vorhanden?
- Kann die lokale Meldestelle unabhängig arbeiten?
- Wird der deutsche Kanal nicht hinter einer rein zentralen Hotline unsichtbar?
- Sind Reporting-Wege so gebaut, dass Group Oversight nicht unnötig Fallinhalte streut?
Mehr dazu: Hinweisgebersysteme für mehrere EU-Standorte.
Kurzfazit
HinSchG und EU-Hinweisgeberrichtlinie erklären, warum viele Organisationen in Deutschland interne Meldewege ernst nehmen. Für den Softwarekauf zählen konkrete Betriebsfähigkeiten: Kanal, Vertraulichkeit/Anonymität, Dialog, Fall, Sicherheit und Nachweis. Trennen Sie organisatorische Pflicht von Produktfunktion — und kaufen Sie das Werkzeug, nicht das Label.