Hinweisgebersystem im Finanzinstitut: Daten, die der Anbieter nicht sieht
Die Compliance-Abteilung eines Finanzinstituts bewertet einen Anbieter nach einer einzigen Frage: Was passiert, wenn der Anbieter gehackt wird oder ein Herausgabeverlangen einer fremden Behörde erhält? Die Antwort „nichts, weil er keinen Schlüssel hat“ ist die einzige, die keine weitere Diskussion erfordert.
Situation
Die Compliance-Abteilung einer Bank bewertet Anbieter nach einem einzigen Kriterium: Was passiert, wenn der Anbieter gehackt wird oder eine Anordnung einer ausländischen Behörde erhält? Meldungen hinweisgebender Personen sind die sensibelsten Daten in der Organisation.
So funktioniert es
Nach dem Einschalten des Ende-zu-Ende-Modus werden Inhalt und Identität mit einem Schlüssel verschlüsselt, der beim Kunden bleibt; der Betreiber kann sie also selbst mit vollem Zugriff auf die Datenbank nicht lesen. Ein persönlicher Notfallcode schützt vor einem vergessenen Passwort, und wenn die Organisation alle Schlüssel verliert, kann niemand die Inhalte wiederherstellen. Die Daten verlassen die Europäische Union nicht, und jeder Vorgang hinterlässt eine Spur im Protokoll.
- E2E-Verschlüsselung
- Audit-Protokoll
- Gesetzeskonformität
In diesem Szenario 4
Was das Gesetz in dieser Situation sagt
Rechtsträger, die im Bereich der Finanzdienstleistungen, Finanzprodukte und Finanzmärkte sowie der Verhinderung von Geldwäsche tätig sind, sind unabhängig von der Personenzahl zu einem Verfahren für interne Meldungen verpflichtet (Art. 23 Abs. 3 des polnischen Hinweisgeberschutzgesetzes, Gesetz vom 14. Juni 2024 über den Schutz von Hinweisgebern). Das Gesetz überlagert hier frühere sektorale Pflichten: die Verfahren zur anonymen Meldung von Verstößen aus dem polnischen Bankengesetz (Prawo bankowe), dem Gesetz über den Handel mit Finanzinstrumenten, dem AML-Gesetz und den EU-Verordnungen. Ein einziger Meldekanal sollte alle diese Regelungsregime bedienen, mit Einordnung der Meldung durch die fallbearbeitende Person.
Ein Finanzinstitut steht zudem unter der Aufsicht der KNF (polnische Finanzaufsicht), die im Rahmen ihrer Prüfungen die Verfahren zur Meldung von Verstößen bewertet, und unterliegt als Verantwortlicher für Daten mit besonderem Risiko den Anforderungen an das Outsourcing und der DORA-Verordnung im Bereich der IKT-Dienstleistungen.
Worauf bei der Einführung zu achten ist
- Szenario Einbruch beim Anbieter. Wenn der Inhalt der Meldungen und die Identität der hinweisgebenden Personen mit einem Schlüssel verschlüsselt sind, den ausschließlich das Institut besitzt, bedeutet ein Datenabfluss aus der Datenbank des Anbieters den Abfluss von Chiffretext. Das ändert die Einstufung des Vorfalls und die Meldepflichten.
- Szenario Herausgabeverlangen. Ein Anbieter, der keinen Schlüssel hat, hat nichts herauszugeben. Das Verlangen geht an das Institut, das mit der eigenen Rechtsabteilung entscheidet.
- Schlüssel auf Seiten des Instituts. Im Ende-zu-Ende-Modus hat der Betreiber weder einen Schlüssel noch einen Wiederherstellungsmechanismus. Jede ermächtigte Person hat einen persönlichen Notfallcode für den Fall eines vergessenen Passworts, und der Schlüsselwechsel nach dem Ausscheiden einer Mitarbeiterin oder eines Mitarbeiters hat ein 48-Stunden-Fenster mit Abbruchmöglichkeit. Verliert das Institut alle Schlüssel, kann niemand die Inhalte wiederherstellen; das Verfahren zur Aufbewahrung der Codes muss bei der Einführung festgelegt werden.
- Standort und Unterauftragsverarbeiter. Daten ausschließlich in der Europäischen Union, ein Verzeichnis der Unterauftragsverarbeiter mit Standort und Übermittlungsgrundlage, ein Auftragsverarbeitungsvertrag (AVV), der der Datenschutz-Folgenabschätzung (DSFA) und der Outsourcing-Dokumentation beigefügt werden kann.
- Das Audit-Protokoll als Beweis, nicht als Server-Log: wer, wann, was, mit einer Unveränderbarkeit, die sich gegenüber dem Prüfer nachweisen lässt.
Funktionen, die den Unterschied machen
- Ende-zu-Ende-Verschlüsselung mit dem Schlüssel des Kunden, ohne Schlüssel und ohne Wiederherstellungsmechanismus auf Seiten des Betreibers (Vertraulichkeit); der Modus ist im Auftragsverarbeitungsvertrag, Punkt 3 beschrieben.
- Daten ausschließlich in der EU: Warschau und Frankfurt, Backups im EWR (Sicherheit).
- Unveränderbares Audit-Protokoll und Export für die Prüfung (Compliance).
- RBAC pro Formular und Fall: Compliance, interne Revision und HR sehen nur ihre eigenen Kategorien.
- Integrationen: Webhooks und API ausschließlich mit Metadaten für GRC-Systeme, ohne Meldungsinhalte (Einführung und Integrationen).
- Öffentliches Verzeichnis der Unterauftragsverarbeiter mit Benachrichtigung über Änderungen 14 Tage im Voraus (Unterauftragsverarbeiter).
Häufige Fragen
Ist der Betreiber des Systems Auftragsverarbeiter, obwohl er die Daten nicht lesen kann?
Ja. Er verarbeitet Chiffretext und Metadaten im Auftrag des Instituts, daher ist ein Auftragsverarbeitungsvertrag (AVV) verpflichtend. Der Unterschied besteht darin, dass sich das Risiko auf Seiten des Betreibers auf Daten beschränkt, die er nicht lesen kann, was bei der Folgenabschätzung und bei der Einstufung eines möglichen Vorfalls von Bedeutung ist.
Wie behandelt der Meldekanal Meldungen nach dem Bankengesetz und nach dem AML-Gesetz?
Als getrennte Kategorien im selben Meldungsregister, mit Berechtigungen für die jeweils zuständigen Personen. Die Einordnung der Meldung erfolgt nach dem Eingang, und Fristen und Audit-Protokoll funktionieren unabhängig von der Rechtsgrundlage gleich.
Mehr dazu im Artikel DSGVO bei Hinweisgebermeldungen.
Vom Verfahren zum funktionierenden Meldekanal
sygnadesk berechnet die Fristen, führt das Register und schützt die Identität der hinweisgebenden Person so, wie wir es in der Wissensdatenbank beschreiben. Sehen Sie, wie das in Ihrer Organisation aussieht.