In Ausschreibungen, Policies und Vendor-Demos fallen zwei Begriffe oft durcheinander: interner Meldekanal und interne Meldestelle. Sie hängen zusammen — sind aber nicht dasselbe.
Wer sie vermengt, trifft schlechte Kauf- und Organisationsentscheidungen: Entweder wird Software wie eine Behörde behandelt, oder eine organisatorische Funktion wird auf ein Formular reduziert.
Dieser Artikel klärt die Begriffe für deutsche Käufer und Compliance-Teams. Er ist keine Rechtsberatung. Ob und wie Ihre Organisation Meldekanal und Meldestelle ausgestalten muss, hängt vom Hinweisgeberschutzgesetz (HinSchG), interner Governance und ggf. rechtlicher Prüfung ab.
Kurzdefinitionen
| Begriff | Was er meint | Typische Frage |
|---|---|---|
| Interner Meldekanal | Der Weg bzw. das Werkzeug, über das Hinweise eingehen und oft auch der Dialog geführt wird | „Wie wird gemeldet?“ |
| Interne Meldestelle | Die organisatorische Funktion, die Meldungen entgegennimmt, steuert und bearbeitet | „Wer ist verantwortlich?“ |
| Hinweisgebersystem | Oft Oberbegriff für Programm + Prozesse + Tooling | „Wie betreiben wir das Ganze?“ |
| Hinweisgeber-Software | Produktkategorie zur technischen Unterstützung | „Welches Tool kaufen wir?“ |
Im Glossar der Produktsprache gilt: Meldekanal = Channel/Tool, Meldestelle = organisatorische Pflicht/Funktion.
Der Meldekanal: Weg und Werkzeug
Der interne Meldekanal ist die Eingangs- und Kommunikationsinfrastruktur. In der Praxis erwarten Käufer häufig:
- einen geschützten schriftlichen Weg zur Abgabe
- klare Trennung vom allgemeinen E-Mail-Postfach
- Unterstützung von Vertraulichkeit und — je nach Modell — anonymer Meldung
- Möglichkeit zur Nachverfolgung / Zwei-Wege-Kommunikation
- Anbindung an Fallbearbeitung
Technisch ist das die Domäne von Hinweisgeber-Software. Der Meldekanal beantwortet: Wie und worüber wird gemeldet?
Die Meldestelle: Organisation und Verantwortung
Die interne Meldestelle ist keine URL. Sie ist die Funktion, die:
- Meldungen entgegennimmt
- Zuständigkeiten und Konfliktvermeidung organisiert
- Bearbeitung und Nachverfolgung steuert
- mit Policy, Schulung und Eskalation verbunden ist
- gegenüber der Organisation Verantwortung trägt
Software kann die Meldestelle entlasten und dokumentieren. Sie ersetzt sie nicht. Ein Vendor ist keine Meldestelle — ebenso wenig wie ein Ticketsystem eine Compliance-Funktion ist.
Warum die Verwechslung teuer wird
Fehler 1: „Wir kaufen eine Meldestelle“
Dann landen rechtliche Erwartungen im RFP („Vendor muss HinSchG erfüllen“), obwohl der Vendor nur Software liefert. Ergebnis: Scheinsicherheit und schwache interne Ownership.
Fehler 2: „Wir haben eine Meldestelle, also reicht Outlook“
Dann existiert Verantwortung auf dem Papier, aber der Kanal fehlt an Anonymität, Zugriffssteuerung, Dialog und Prüfpfad. Ergebnis: Medienbrüche und Vertrauensverlust.
Fehler 3: Begriff „Hinweisgebersystem“ als Alleskleber
Manchmal meint das Wort die Software, manchmal das gesamte Programm. In Beschaffung und Policy sollten Sie präzise sagen, was gemeint ist.
Praktisches Zusammenspiel
Ein belastbares Setup kombiniert beides:
- Organisation benennt und befähigt die Meldestelle (intern und/oder mit externer Unterstützung).
- Policy beschreibt, was gemeldet werden kann, wie Vertraulichkeit/Anonymität gilt und wie Retaliation adressiert wird.
- Software stellt den Meldekanal, die Kommunikation und das Fallmanagement bereit.
- Betrieb verbindet Fristen, Zugriffe, Schulung und Reporting.
Ohne Schritt 1–2 wird Software zum leeren Kanal. Ohne Schritt 3 wird die Meldestelle zum Engpass mit schwachen Nachweisen.
Vertiefung zum Kaufkontext: HinSchG: Was Software-Käufer prüfen sollten und Hinweisgebersystem auswählen.
Was in Lastenhefte gehört — getrennt formuliert
Zur Meldestelle (Organisation):
- Wer ist benannt / erreichbar?
- Wie werden Interessenkonflikte gelöst?
- Welche Eskalationswege gibt es?
- Welche Schulung und Unabhängigkeit sind vorgesehen?
Zum Meldekanal (Software):
- Wie funktioniert Intake?
- Wie funktioniert anonyme/vertrauliche Kommunikation?
- Wie greifen Rollen und Rechte?
- Wie sieht Fallmanagement und Prüfpfad aus?
- Wo liegen Daten, wer sind Subprozessoren?
Diese Trennung macht Angebote vergleichbar und Verantwortlichkeiten klar.
Externe Unterstützung — ohne Begriffschaos
Manche Organisationen binden externe Ombudspersonen oder Provider ein. Auch dann bleibt die Unterscheidung sinnvoll:
- Extern kann Teil der Meldestellen-Funktion oder ihrer Unterstützung sein.
- Software bleibt der Kanal und oft das Fallwerkzeug.
- Die Organisation behält Governance-Verantwortung.
Ob ein Modell für Sie passt, ist keine Feature-Frage des Vendors, sondern eine Organisations- und ggf. Rechtsfrage.
Sprache in Nutzerkommunikation
Für Mitarbeitende zählt Klarheit:
- „So melden Sie“ = Meldekanal
- „Wer bearbeitet“ = Meldestelle / verantwortliche Funktion
- „Was passiert danach“ = Prozess + Fallbearbeitung
Wenn die Website „anonyme Meldestelle“ sagt und ein Formular meint, entstehen Erwartungsbrüche. Besser: präzise Begriffe, ehrliche Grenzen.
Rolle der Software — und was sie nicht ist
Hinweisgeber-Software wie Disclosurely hilft Organisationen, einen internen Meldekanal zu betreiben und Fälle zu managen. Sie ist:
- kein Ersatz für die Meldestelle
- keine Rechtsberatung
- keine behördliche Zulassung
- keine Garantie für „compliant“
Meiden Sie Anbieterversprechen wie „staatlich zertifiziert“, „behördlich genehmigt“, „garantiert compliant“ oder „offiziell zugelassen“.
Beispiele aus der Praxis (anonymisiert)
Beispiel 1: Ein Mittelständler benennt Compliance als Meldestelle, nutzt aber ein gemeinsames Funktionspostfach. Ergebnis: Vertretungen unsicher, Zugriff zu breit, keine anonyme Rückfrage. Hier fehlt der Meldekanal — nicht die Benennung.
Beispiel 2: Ein Konzern kauft eine Plattform und erklärt den Vendor zur „Meldestelle“. Intern fühlt sich niemand verantwortlich. Ergebnis: Fristen und Eskalation unklar. Hier fehlt die Meldestelle — trotz Software.
Beispiel 3: Eine Gruppe betreibt Software zentral, lokale Teams haben keine Rechte und keine Sprache. Mitarbeitende melden lokal informell. Ergebnis: Schattenkanäle. Hier passen Kanal und Meldestellen-Organisation nicht zusammen.
Checkliste für Policy-Formulierungen
Formulieren Sie in Richtlinien getrennt:
- Meldewege: Welche Kanäle gibt es (Software, ggf. weitere Wege)?
- Zuständigkeit: Wer ist Meldestelle / wer vertritt?
- Vertraulichkeit/Anonymität: Was wird zugesichert — und was nicht?
- Nachverfolgung: Wie wird kommuniziert und dokumentiert?
- Schutz vor Benachteiligung: Organisatorische Haltung und Meldewege bei Konflikten
- Abgrenzung: Was gehört in HR-Beschwerdewege statt in den Hinweisgeberkanal?
Policy-Sprache sollte Softwarefunktionen nicht überversprechen.
Beschaffungsformulierung, die Klarheit schafft
Statt: „Lieferant stellt eine HinSchG-Meldestelle bereit.“
Besser: „Lieferant stellt Hinweisgeber-Software zur Unterstützung unseres internen Meldekanals bereit, inkl. anonymer/vertraulicher Meldung gemäß Spezifikation, Zwei-Wege-Kommunikation, Fallmanagement und Prüfpfad. Die organisatorische Meldestelle verbleibt bei der Organisation bzw. bei von ihr benannten Stellen.“
Diese eine Umformulierung verhindert Monate falscher Erwartungen.
Schulung: zwei Zielgruppen, zwei Curricula
- Meldestelle / Fallbearbeiter: Rechte, Dialog, Dokumentation, Interessenkonflikte, Eskalation
- Mitarbeitende: Wie melden, was erwarten, was anonym/vertraulich bedeutet, wo Hilfe liegt
Ein Tool-Rollout ohne diese zwei Schulungslinien erzeugt Scheinkompliance.
Kurzfazit
Meldekanal = wie gemeldet wird (Weg/Tool). Meldestelle = wer verantwortlich bearbeitet (Organisation). Ein Hinweisgebersystem braucht beides — und gute Software verbindet den Kanal mit der Fallarbeit der Meldestelle, ohne die Verantwortung zu übernehmen. Formulieren Sie Ausschreibung, Policy und interne Rollen entsprechend getrennt.