Wenn Ihr Bewerbersystem zum Datenleck wird: Kandidatendaten absichern

Ein Datenleck in einer Recruiting-Plattform gehört inzwischen zu den lohnendsten Zielen in Ihrem Stack, denn ein Bewerbermanagementsystem (ATS) bündelt die dichteste Konzentration regulierter personenbezogener Daten, mit der Ihr Unternehmen überhaupt in Berührung kommt: vollständige Namen, Adressen, Gehaltsvorstellungen, Lebensläufe und zunehmend auch amtliche Ausweise, aufgezeichnete Videointerviews und KI-generierte biometrische Daten. Wird ein solches System kompromittiert, erbeuten die Angreifer keine Marketingliste. Sie erhalten ein schlüsselfertiges Set für Identitätsdiebstahl und Deepfakes. Die Lösung lautet nicht „einen Anbieter wählen, der Sicherheit verspricht“. Sie lautet Privacy by Design: weniger erheben, das Verbleibende verschlüsseln, nach festem Zeitplan löschen und das ATS als ein System behandeln, das Ihr Notfallplan tatsächlich abdeckt.

Wenn Sie für den Hiring-Stack verantwortlich sind und Ihr CISO oder Vorstand zu fragen begonnen hat „Könnte uns das Gleiche wie Mercor passieren?“, dann ist dieser Beitrag für Sie. Hier erfahren Sie, was wirklich geschah, warum Recruiting-Plattformen plötzlich ins Visier geraten, welches rechtliche Risiko daraus folgt und welche konkreten Kontrollen Sie von jedem Anbieter einfordern können.

Was bei Mercor passierte (und warum es jedes Hiring-Team beunruhigen sollte)

Ende März 2026 wurde die auf die KI-Branche spezialisierte Recruiting-Plattform Mercor kompromittiert, und rund 4 TB an Daten wurden abgezogen, darunter Sozialversicherungsnummern von Kandidaten, Scans von Pässen und Führerscheinen, biometrische Gesichtsdaten und HD-Videointerviews. Mercor, das Berichten zufolge Auftragnehmer vermittelt, die Modelle für große KI-Labore trainieren, wurde nicht über die eigene Vordertür getroffen. Es wurde über eine Abhängigkeit getroffen.

Der Angriff kam über den Lieferketten-Vorfall bei LiteLLM herein. Ein als TeamPCP geführter Angreifer kompromittierte die PyPI-Veröffentlichungs-Zugangsdaten von LiteLLM und schob zwei mit Schadcode versehene Paketversionen nach, v1.82.7 und v1.82.8. Laut dem Sicherheitsbeitrag von LiteLLM selbst waren die schädlichen Pakete am 24. März 2026 etwa 40 Minuten lang auf PyPI verfügbar, bevor sie in Quarantäne genommen wurden. 40 Minuten reichten aus. Die Schadroutine sammelte Umgebungsvariablen, SSH-Schlüssel, Cloud-Zugangsdaten, Kubernetes-Token und Datenbankpasswörter ein. Die Erpressergruppe Lapsus$ führte Mercor daraufhin um den 31. März auf ihrer Leak-Seite und bot die Daten zur Versteigerung an; Mercor gab den Schaden Anfang April bekannt und bezeichnete sich selbst als „eines von Tausenden betroffenen Unternehmen“.

Die von Lapsus$ beanspruchten Daten gliedern sich grob in rund 939 GB Quellcode, eine 211 GB große Kandidatendatenbank und etwa 3 TB an gespeicherten Dateien (Repello AI; SecurityWeek). Die Kandidatendatenbank enthielt Berichten zufolge Lebensläufe, verifizierte Kontaktdaten und Sozialversicherungsnummern. Wirklich alarmierend waren die gespeicherten Dateien: HD-Videos von Kandidaten, Scans von Ausweisdokumenten und die biometrischen Gesichtsdaten, mit denen Gesichter den Ausweisen zugeordnet werden.

Die Lehre lautet nicht „LiteLLM war schlecht“. LiteLLM ist weit verbreitet; Wiz fand es in 36 % der analysierten Cloud-Umgebungen vor (Wiz). Die Lehre lautet: Der Schadensradius Ihrer Kandidatendaten umfasst auch die Lieferanten Ihrer Lieferanten, und der sensibelste Datenberg, den Sie besitzen, liegt womöglich in einem System, an das niemand in Ihrem Sicherheitsteam denkt.

Warum Recruiting-Plattformen jetzt zu den Hauptzielen gehören

Recruiting-Plattformen sind lohnende Ziele, weil der Hiring-Funnel mehr sensible Daten erhebt als nahezu jedes andere Backoffice-System, dabei aber selten in das Sicherheitsprogramm eines Unternehmens einbezogen wird. Überlegen Sie, was bei einer einzigen Einstellung durch ein ATS fließt: vollständiger Name, Wohnadresse, Telefon, E-Mail, vollständiger Berufsverlauf, Gehaltsvorstellungen, ein Lebenslauf, Referenzen und in vielen modernen Stacks ein aufgezeichnetes Videointerview, ein amtlicher Ausweis für die Prüfung der Arbeitserlaubnis sowie KI-generierte Transkripte oder Bewertungen. Das ist ein reichhaltigeres Profil, als es die meisten CRMs, Abrechnungssysteme oder internen Wikis enthalten.

Zwei strukturelle Verschiebungen haben das in den letzten Jahren verschärft.

KI-Hiring-Tools erheben standardmäßig biometrienahe Daten. Videointerviews, Stimmanalysen und der Abgleich von Gesicht und Ausweis sind heute gängige Funktionen. Jede davon verwandelt einen Schritt im Auswahlprozess in einen dauerhaften biometrischen Datensatz.

KI-Gateways und Proxy-Dienste bündeln Zugangsdaten. Tools wie LiteLLM sitzen vor den Modell-APIs und sammeln API-Schlüssel und Cloud-Zugangsdaten an. Jede Plattform, die ein solches Tool einsetzt, erbt dessen vorgelagertes Lieferkettenrisiko — genau dieser Weg führte in Mercor hinein.

Bringen Sie beides zusammen, erhalten Sie ein System, das Kronjuwelen-Daten enthält, durch KI-Funktionen aufgebläht ist, über Abhängigkeiten angreifbar wird und fast nie im Notfallplan auftaucht. Die Angreifer haben das früher bemerkt als die meisten Hiring-Teams.

Die Daten, die Sie nicht zurücksetzen können

Der Grund, warum ein Recruiting-Datenleck schlimmer ist als ein typisches PII-Leck, ist einfach: Biometrische Merkmale lassen sich nicht zurücksetzen. Eine Analyse des Mercor-Datenlecks brachte es auf den Punkt: „Für Ihr Gesicht gibt es keinen ‚Zurücksetzen‘-Knopf“ (IQ Source).

Ein gestohlenes Passwort ist in Sekunden neu vergeben. Eine geleakte Kreditkarte wird gesperrt und neu ausgestellt. Ein gestohlener Gesichtsscan samt Stimmaufnahme ist hingegen dauerhaft — und genau das Rohmaterial, das es braucht, um überzeugende Deepfakes zu erzeugen. Im Fall von Mercor bedeutet das, dass sich Angreifer als Auftragnehmer ausgeben können, die Zugang zu KI-Laboren haben — eine Kette von Folgen, die jede E-Mail zum Zurücksetzen des Passworts überdauert. Aufgezeichnete Videointerviews und KI-Stimmtranskripte gehören in dieselbe Kategorie. Sie sind biometrienah, nach einem Leak praktisch unumkehrbar, und die meisten Unternehmen speichern sie gänzlich ohne Aufbewahrungs- oder Löschrichtlinie.

Das ist das Kernargument für Datensparsamkeit im Hiring. Die Daten, die Sie nie erhoben haben, können nicht leaken. Die Daten, die Sie planmäßig gelöscht haben, können im nächsten Datendump nicht auftauchen. Jedes Videointerview, das Sie „für alle Fälle“ behalten, ist eine dauerhafte Belastung, die in irgendeinem fremden S3-Bucket schlummert.

Der rechtliche Schadensradius

Ein Datenleck mit Kandidatendaten ist nicht nur ein Sicherheitsvorfall; es zieht aufsichtsrechtliche Konsequenzen und Klagen nach sich, und die Rechnungen kommen schnell. Bereits in der ersten Aprilwoche 2026 wurden mindestens vier Sammelklagen gegen Mercor eingereicht, die meisten beim U.S. District Court for the Northern District of California; spätere Berichte beziffern die Zahl auf fünf bis sechs (HR Dive; ComplianceHub). Eine Klage schlägt eine landesweite Sammelklage im Namen von mehr als 40.000 Betroffenen vor, mit Ansprüchen wegen Fahrlässigkeit, Verletzung eines stillschweigenden Vertrags, Eingriffs in die Privatsphäre und Verstoßes gegen Kaliforniens Unfair Competition Law. Eine separate Klage in Texas benennt nachgelagerte Subunternehmer und macht aus einem Drittparteien-Problem ein Viertparteien-Problem.

Die geltenden Aufsichtsregime erhöhen den Einsatz zusätzlich:

Quellen: National Law Review; evidenced.app.

Über all diese Regime hinweg zeigt sich dasselbe Muster: Die Aufsichtsbehörden belohnen Datensparsamkeit, dokumentierte Aufbewahrung, Einwilligung und die Fähigkeit, auf Anfrage zu löschen. Das sind nicht bloß Compliance-Häkchen. Es sind genau die Kontrollen, die ein Datenleck verkleinern.

So schützen Sie Kandidatendaten in einem ATS: die Checkliste

Um Kandidatendaten in einem ATS zu schützen, setzen Sie auf Privacy by Design: erheben Sie das Minimum, verschlüsseln Sie auf Spaltenebene, setzen Sie Aufbewahrungs-Voreinstellungen, die Daten planmäßig löschen, protokollieren Sie Zugriffe, prüfen Sie die Subunternehmer Ihres Anbieters, kommen Sie Löschanfragen nach und nehmen Sie das ATS in Ihren Notfallplan auf. Hier die Kurzfassung, die Sie einem Anbieter oder Ihrem eigenen Team in die Hand geben können:

1. Erhebung minimieren. Sammeln Sie keine Sozialversicherungsnummern, vollständigen amtlichen Ausweise oder Videoaufzeichnungen, sofern eine bestimmte Phase sie nicht wirklich erfordert. Am günstigsten zu schützen sind die Daten, die Sie nie erhoben haben.
2. PII auf Spaltenebene verschlüsseln. Sensible Felder sollten in der Anwendungsschicht ruhend verschlüsselt sein — nicht nur mit dem vagen Versprechen einer „verschlüsselten Festplatte“.
3. Aufbewahrungs-Voreinstellungen setzen. Jeder Kandidatendatensatz, jedes Video und jedes Transkript braucht eine Lösch-Voreinstellung, die in Monaten bemessen ist, nicht in „für immer“.
4. Zugriffe protokollieren. Wer wann welchen Lebenslauf bzw. welche CV eingesehen hat, sollte ein nachvollziehbarer Eintrag sein.
5. Anbieter und deren Anbieter prüfen. Fragen Sie, welche Abhängigkeiten und KI-Gateways hinter Ihrem ATS stehen. Mercors Schadensradius lief über ein Paket, das die meisten im Team nie direkt gewählt hatten.
6. Löschung auf Anfrage umsetzen. DSGVO und CCPA geben Kandidaten das Recht auf Vergessenwerden; Ihr Stack muss es sauber über Video, Transkripte und abgeleitete Daten hinweg ausführen.
7. Das ATS in den Notfallplan aufnehmen. Ein System, das Sozialversicherungsnummern, Pässe und biometrische Videos enthält, ist ein Kronjuwelen-Asset und gehört in den Geltungsbereich, nicht in den toten Winkel.

Ihr ATS gehört in Ihren Notfallplan

Die mit Abstand häufigste Lücke ist struktureller Natur: Notfallpläne decken die „produktive“ Infrastruktur ab und klammern das Hiring-System stillschweigend aus — obwohl das ATS oft die sensibelsten Daten des Unternehmens enthält. Ein moderner CSIRT-Geltungsbereich schließt ausdrücklich die Systeme mit den sensibelsten Daten sowie die Rechts- und HR-Funktionen ein, die für die Meldung eines Datenlecks nötig sind (FIRST CSIRT Services Framework). Ein ATS, das Sozialversicherungsnummern, Pässe und biometrische Videos enthält, ist genau ein solches System.

Das ATS als Sicherheitsfläche zu behandeln bedeutet drei konkrete Dinge. Erstens taucht es in Ihrem Asset-Inventar und Ihren Datenflusskarten auf, mit ausgewiesener Datenklassifizierung. Zweitens wird das Risiko seines Anbieters und seiner Subunternehmer im selben Rhythmus geprüft wie der Rest Ihrer Lieferkette. Drittens stehen, wenn ein Vorfall eintritt, jene Personen, die beantworten können „Welche Kandidatendaten lagen darin, und wen müssen wir benachrichtigen?“, bereits auf der Liste des Reaktionsteams — und improvisieren nicht erst. Die meisten Unternehmen führen Hiring und Sicherheit als zwei voneinander getrennte Welten. Die Mercor-Klagen sind das, was passiert, wenn die Nahtstelle zwischen beiden genau dort liegt, wo die Daten gespeichert sind.

Wie Kit das angeht

Kit ist eine kombinierte Hiring- und Sicherheitsplattform, und die Versäumnisse bei Mercor lassen sich auf Kontrollen abbilden, die Kit bereits umsetzt — deshalb ist dies ein Argument über die Sicherheitshaltung und kein Marketing-Argument. Nichts davon macht irgendeinen Anbieter immun gegen Datenlecks, Lieferkettenangriffe können jeden treffen, aber die richtigen Voreinstellungen verkleinern sowohl den Schadensradius als auch das aufsichtsrechtliche Risiko, wenn etwas schiefgeht.

• Verschlüsselung von Kandidaten-PII auf Spaltenebene. Kit verschlüsselt die sensibelsten Kandidatenfelder ruhend mit Active Record Encryption. E-Mail-Adressen werden deterministisch verschlüsselt, damit sie für die Deduplizierung abfragbar bleiben, während Felder ohne Abfragebedarf nicht-deterministisch verschlüsselt werden. Die Lehre „PII verschlüsselt speichern, nicht im Klartext“, konkret umgesetzt.
• Aufbewahrung als erstklassige Einstellung. Die Einwilligung von Kandidaten trägt ein konfigurierbares Aufbewahrungsfenster mit einer sinnvollen, in Monaten bemessenen Voreinstellung, und die Einwilligung selbst lässt sich erneuern, verweigern und ablaufen — statt sie unbefristet zu speichern. Daten, die Sie planmäßig löschen, können im nächsten Datendump nicht auftauchen.
• Disziplinierter Umgang mit Video und Transkripten. Aufgezeichnete Interviews und KI-Transkripte werden als das behandelt, was sie sind: biometrienahe, aufbewahrungsgebundene Assets — mit protokolliertem Zugriff auf Kandidaten-CVs für einen Prüfpfad.
• Mandantentrennung und belegbare Löschung. Kandidatendaten sind pro Konto abgegrenzt, und Soft-Delete plus Zugriffsprotokollierung stützen das „Recht auf Löschung“, das DSGVO und CCPA verlangen.
• Ein eingebauter CSIRT-Bereich. Weil Kit ein vollständiges Modul für Schwachstellenoffenlegung und Vorfallreaktion direkt neben dem Hiring mitliefert, kann dieselbe Reaktionsdisziplin, die für die Produktion gilt, auch das ATS abdecken. Die beiden Welten, die Mercor getrennt hielt, sind hier eine einzige Fläche.

Wie man die Reaktionsseite hiervon aufbaut, haben wir in So richten Sie ein Programm zur Schwachstellenoffenlegung ein behandelt, und den Compliance-Druck, der nun auf kleinen Teams lastet, in der Offenlegungsfrist des EU Cyber Resilience Act. Dieser Beitrag ist die Kandidatendaten-Schicht, die unter beiden liegt.

FAQ

Ist mein Bewerbermanagementsystem ein Risiko für ein Datenleck?

Ja, standardmäßig ist es eines Ihrer riskantesten Systeme, weil es regulierte PII (Namen, Adressen, Sozialversicherungsnummern, amtliche Ausweise, Gehaltsdaten) und zunehmend biometrische Daten aus Videointerviews bündelt — und dabei selten in Sicherheitsprogramme einbezogen wird. Das Risiko lässt sich senken: minimieren Sie, was Sie erheben, verschlüsseln Sie es, setzen Sie Aufbewahrungsgrenzen und nehmen Sie das ATS in den Geltungsbereich Ihres Notfallplans auf. Das Mercor-Datenleck hat gezeigt, dass die Daten da sind — ganz gleich, ob Sie sie schützen oder nicht.

Welche Kandidatendaten sind bei einem Datenleck am gefährlichsten?

Biometrische und Identitätsdaten: Gesichtsscans, Stimmaufnahmen, Videointerviews und Bilder amtlicher Ausweise. Anders als ein Passwort oder eine Kreditkarte lassen sie sich nicht zurücksetzen oder neu ausstellen, und sie sind das Rohmaterial für Deepfakes und Identitätsdiebstahl. Auch Sozialversicherungsnummern sind hochbrisant. Die sicherste Haltung ist, diese Daten gar nicht erst zu erheben, sofern eine bestimmte Phase sie nicht erfordert — und sie dann nach einem festen Zeitplan zu löschen.

Wie lange sollte ein ATS Kandidatendaten aufbewahren?

Lange genug, um den Zweck der Einstellung zu erfüllen und rechtliche Pflichten einzuhalten, dann löschen. Nach der DSGVO benötigen Sie eine definierte, dokumentierte Aufbewahrungsfrist statt einer unbefristeten Speicherung, und viele Teams setzen für abgelehnte Bewerber standardmäßig rund zwei Jahre mit einer klaren Löschfrist an. Videointerviews und Transkripte verdienen das engste Fenster, da sie die am schwersten zu rechtfertigenden Daten sind. Die Aufbewahrung sollte eine konfigurierte Voreinstellung sein, kein manuelles Aufräumen, das niemand durchführt.

Das Fazit

Das Mercor-Datenleck ist der Lehrbuchfall dafür, dass das ATS selbst zum Datenleck wird: 4 TB gehen über eine Abhängigkeit verloren, darunter genau die eine Datenkategorie — Ihr Gesicht und Ihre Stimme —, die niemand jemals zurücksetzen kann. Die belastbare Antwort besteht nicht darin, einen Anbieter zu kaufen, der Sicherheit verspricht. Sie besteht in Privacy by Design als überprüfbarer Haltung: weniger erheben, auf Spaltenebene verschlüsseln, Aufbewahrungs-Voreinstellungen setzen, die planmäßig löschen, Zugriffe protokollieren, die Anbieter Ihrer Anbieter prüfen und das Hiring-System in den Notfallplan holen, in den es immer schon gehörte.

Wenn Sie Ihren Hiring-Stack prüfen und Datensparsamkeit, Verschlüsselung, Aufbewahrung und Vorfallreaktions-Disziplin von Anfang an eingebaut haben möchten, testen Sie Kit kostenlos und richten Sie noch heute einen Hiring-Prozess nach Privacy-by-Design ein.