Migration von Sterling, Checkr oder HireRight zu einer EU-nativen Lösung: Der vollständige Workflow

Verwandte Artikel

• Indicium vs. Sterling/Checkr/HireRight

• Validato/Certn-Vergleich

• DPO-Checkliste

• 60-Tage-Plan

Schrems II hat US-basierten Background-Check-Anbietern den DACH-Markt grundlegend verändert. Wer 2026 noch mit Sterling, Checkr oder HireRight arbeitet, trägt ein Compliance-Risiko, das in einem BaFin-Audit, einer Datenschutzaufsichts-Prüfung oder einem EU-AI-Act-Konformitäts-Check nicht mehr verteidigbar ist. Wer migriert, stößt auf fünf typische Stolpersteine — und auf einen klar strukturierten Weg drumherum.

1. Warum jetzt migrieren? Vier strukturelle Gründe

Die Migrationsentscheidung ist selten eine Frage des Preises. Sie ist eine Frage der Rechtsverteidigungs-Fähigkeit. Wer im Audit nicht erklären kann, warum personenbezogene Bewerber-Daten in Atlanta, Denver oder San Francisco verarbeitet werden, hat den Audit-Punkt bereits verloren.

1.1 Schrems II und die Folgeentscheidungen

Der EuGH-Beschluss C-311/18 vom 16. Juli 2020 hat den Privacy-Shield gekippt und die Standardvertragsklauseln (SCC) nur noch unter Bedingungen erlaubt. Das EU-US Data Privacy Framework vom 10. Juli 2023 hat zwar einen neuen Übermittlungsweg geschaffen — aber die FISA Section 702 bleibt unverändert. Background-Check-Anbieter, die Daten nach US-Cloud-Regionen replizieren, müssen jeder Übermittlung eine Transfer-Impact-Assessment (TIA) beilegen.

• Risiko 1 — TIA-Lücke: Die meisten DACH-Kunden von Sterling oder HireRight haben nie eine vollständige TIA dokumentiert. Im Audit ist das ein Art. 44 DSGVO-Verstoß mit Bußgeldrahmen bis 4 % vom Konzernumsatz.

• Risiko 2 — FISA-Anfrage ohne Information: US-Anbieter dürfen Sie über eine FISA-Anfrage nicht informieren. Sie wissen also nicht, ob Bewerber-Daten bereits durch US-Behörden eingesehen wurden.

• Risiko 3 — Wegfall des EU-US-Frameworks: Schrems III ist als Verfahren bereits in Vorbereitung. Wer heute neu auf US-Tools setzt, kalkuliert mit einer 24-bis-36-Monats-Halbwertszeit der Rechtsgrundlage.

• Risiko 4 — Vorvertragliches Aufsichtsrisiko: Die BaFin erwartet seit der MaRisk-Novelle 2024, dass Auslagerungen an Drittstaaten-Dienstleister gesondert dokumentiert sind — auch für rein operative HR-Prozesse, sobald Geschäftsleiter geprüft werden.

1.2 Fehlende DACH-Tiefe der US-Anbieter

US-Tools sind auf SSN-basierte Identifikation, County-Court-Records und FCRA-konforme Adverse-Action-Letters optimiert. Die deutsche, österreichische und schweizerische Realität ist eine andere:

• Bundeszentralregister: Das BZR-Führungszeugnis kann aus regulatorischen Gründen nicht durch Dritte abgerufen werden — der Bewerber muss es selbst beantragen. US-Tools haben dafür keinen sauberen Workflow.

• Schuldnerverzeichnis: Die vollstreckungsbezogene Schuldnerregister-Abfrage nach § 882f ZPO erfordert ein berechtigtes Interesse und gerichtliche Antragsformulare — kein Standard-API-Zugriff.

• Insolvenzbekanntmachungen: Das Portal insolvenzbekanntmachungen.de wird von US-Anbietern oft gar nicht oder nur durch Web-Scraping abgedeckt — beides nicht revisionsfest.

• Handelsregister: Geschäftsleiter-Background-Checks erfordern HRA/HRB-Auszüge, Gesellschafterlisten und UBO-Verifikation nach GwG § 18. US-Tools liefern hier maximal eine LexisNexis-Zusammenfassung.

1.3 Das Sprach- und Auslegungs-Problem

Ein Treffer in einer deutschen Verurteilung wegen Untreue nach § 266 StGB ist juristisch nicht das gleiche wie ein US-fraud-Eintrag. Die Klassifikation ist relevant für die Eignung von Geschäftsleitern nach § 25c KWG. Wer hier einen Übersetzungs-Layer dazwischen hat, der nicht von einem deutschen Volljuristen kalibriert wurde, riskiert sowohl False Positives (qualifizierter Bewerber wird abgelehnt) als auch False Negatives (regulatorisch nicht tragbarer Bewerber wird durchgewunken).

1.4 AVV-Schwächen der US-Standardverträge

Die typische Data Processing Addendum eines US-Anbieters enthält selten die in Art. 28 DSGVO verlangten Mindestinhalte in DACH-konformer Tiefe. Insbesondere fehlen:

• ⚠️ Spezifische Sub-Prozessor-Liste mit Standorten und Übermittlungsgrundlagen

• ⚠️ TOMs nach Art. 32 DSGVO in deutschsprachiger, audittauglicher Form

• ⚠️ Löschfristen-Matrix mit Bezug zu deutschen Aufbewahrungspflichten (§ 257 HGB, § 147 AO)

• ⚠️ Audit-Rechte mit Vor-Ort-Klausel — viele US-AVVs erlauben nur SOC-2-Berichte als Surrogat

2. Der Migrations-Workflow in fünf Phasen

Eine saubere Migration dauert je nach Bestandsvolumen 6 bis 14 Wochen. Sie muss als Compliance-kontinuierlicher Übergang geplant werden — nicht als Big-Bang.

Phase 1: Vertrags-Analyse und Termination Notice

1. Kündigungsfrist prüfen: Sterling-Standardverträge haben oft 90 Tage Kündigungsfrist zum Quartalsende. HireRight-Master-Service-Agreements binden teilweise auf 24 Monate mit Auto-Renewal.

2. Ordentliche Kündigung schriftlich einreichen — per Einschreiben an die im AVV genannte Adresse, nicht per Tool-Chat.

3. Datenherausgabe-Anspruch geltend machen: Auf Basis von Art. 20 DSGVO (Datenportabilität für die betroffenen Personen) und Ihrer vertraglichen Rückgaberechte.

4. Löschbestätigung schriftlich einfordern: Inklusive Sub-Prozessor-Bestätigungen — dies ist der häufigste Punkt, an dem Migrationen später bei Audits aufschlagen.

5. Übergangs-AVV vereinbaren: Falls in Phase 3 ein Side-by-Side-Pilot läuft, muss der Altanbieter eine Verarbeitungsgrundlage bis Cut-over haben.

Phase 2: Datenexport aus dem Bestandstool

Der Export ist die unterschätzteste Phase. 80 % der Migrationen verlieren hier Zeit, weil Bestandstools keine vollständigen Audit-Trails ausliefern.

• Stammdaten: Bewerber-IDs, Vor- und Nachname, Geburtsdatum, beauftragende Abteilung, Auftrags-Zeitstempel.

• Einwilligungs-Records: Zeitstempel, IP, akzeptierte Klauselversion, Wortlaut der Einwilligung — als signiertes PDF, nicht als CSV.

• Prüfberichte: Vollständige Reports inklusive Treffer-Klassifikation, Quellen, Prüfern, Eskalations-Hinweisen.

• Entscheidungs-Logs: Wer hat wann auf Basis welchen Reports entschieden? Diese Information ist für § 26 BDSG und für arbeitsgerichtliche Verteidigung essentiell.

• Sub-Prozessor-Spuren: Welche externen Datenquellen wurden konkret abgefragt? Dieser Punkt fehlt in 90 % der US-Tool-Exports.

Phase 3: Side-by-Side-Pilot mit Kohorte

Vor dem Cut-over wird eine Kohorte von 20 Kandidaten parallel durch Alt- und Neu-System geprüft. Ziel: Treffer-Konsistenz validieren und Lücken identifizieren.

Eine Kohorte von 20 ist klein genug, um operativ tragbar zu sein, und groß genug, um statistisch belastbare Konsistenz-Aussagen zu treffen. Mindestens 18 von 20 Reports sollten in den Kern-Aussagen übereinstimmen — Abweichungen werden manuell aufgearbeitet.

Phase 4: Cut-over mit Compliance-Continuity-Plan

Der Cut-over ist nicht ein Datum — er ist ein kontrollierter Übergang über 2–4 Wochen.

1. Stichtag definieren: Ab T0 werden alle Neuaufträge im Neusystem bearbeitet.

2. Laufende Prüfungen weiterführen: Aufträge, die im Altsystem bereits gestartet sind, bleiben dort bis zum Abschluss. Ein paralleler Wechsel mitten im Prozess gefährdet die Verwertbarkeit.

3. Eskalationsfälle priorisieren: Treffer-Reports mit offener Bewerber-Anhörung dürfen nicht migriert werden, bis die Anhörung abgeschlossen ist.

4. HR-Schulung in Woche 1: Recruiter, Compliance und Legal werden gemeinsam geschult — mit einem realen Test-Case und einem Trockenlauf eines Treffer-Workflows.

5. Dual-Reporting in Woche 2–3: Beide Tools sind aktiv, neue Aufträge nur im Neusystem.

6. Altsystem-Abschaltung: Erst wenn alle laufenden Prüfungen geschlossen, alle Audit-Trails exportiert und die Löschbestätigung des Altanbieters schriftlich vorliegt.

Phase 5: Audit-Dokumentation-Übergabe

Die Migrations-Dokumentation selbst wird Teil des permanenten Audit-Trails. Sie muss 5 Jahre aufbewahrt werden — analog zu den ursprünglichen Prüfberichten.

• ✅ Migrations-Beschluss mit Begründung der Rechtsgrundlage

• ✅ Datenschutz-Folgenabschätzung (DSFA) für den Anbieterwechsel — aktualisiert

• ✅ Übergabeprotokoll mit Zeugen aus HR, Compliance und Legal

• ✅ Löschbestätigung des Altanbieters mit Sub-Prozessor-Liste

• ✅ Side-by-Side-Vergleichsbericht mit Konsistenz-Quote der Kohorte

• ✅ Neuer AVV mit allen Anhängen, signiert und datiert

3. Compliance-Continuity in der Migrationsphase

Eine Migration darf zu keinem Zeitpunkt eine Compliance-Lücke öffnen. Das bedeutet konkret: An jedem Tag der Migration muss erkennbar sein, welches Tool für welche Bewerber gilt und welche Rechtsgrundlage greift. Diese Continuity-Logik ist die anspruchsvollste Disziplin der Migration und verlangt drei harte Regeln.

• Regel 1 — Kein Tool-Wechsel mitten im Verfahren: Ein Bewerber, dessen Prüfung im Altsystem gestartet ist, wird dort zu Ende geführt. Punkt.

• Regel 2 — Doppel-Einwilligung in der Pilotphase: Bewerber, die in beiden Systemen geprüft werden, erhalten zwei klar getrennte Einwilligungen mit jeweiligem Verantwortlichen.

• Regel 3 — Continuity-Log: Eine zentrale Tabelle dokumentiert pro Bewerber: Auftrags-Datum, Tool, AVV-Version, abschließendes Tool. Diese Tabelle ist Teil der späteren Audit-Übergabe.

4. Die fünf Stolpersteine — und wie man drumherum kommt

4.1 Laufende Prüfungen während der Migration

Ein Bewerber, dessen BZR-Anfrage am Tag des Cut-over noch nicht zurück ist, darf nicht in ein neues System überführt werden. Lösung: Auftrag im Altsystem zu Ende führen, Endbericht exportieren, im Neusystem als Legacy-Eintrag archivieren.

4.2 AVV-Termination-Klauseln mit Auto-Renewal

⛔ Kündigungsfristen werden routinemäßig verpasst. Lösung: Alle aktuellen Verträge in einer Vendor-Termination-Matrix abbilden, mit 120-Tage-Vorlauf-Trigger. Nicht erst beim Migrations-Beschluss.

4.3 DSFA-Update wird vergessen

Die DSFA nach Art. 35 DSGVO muss bei einem Anbieterwechsel aktualisiert werden. Wer das vergisst, hat im Audit eine vermeidbare Lücke. Der DSB muss formal eingebunden, das Update unterzeichnet und mit Datum archiviert werden.

4.4 Sub-Prozessor-Liste wird nicht neu freigegeben

Manche Konzern-AVVs verlangen eine Konzernrechtsabteilung-Freigabe jeder neuen Sub-Prozessor-Konstellation. Wenn das Neusystem andere Subs hat (z.B. Cloud-Anbieter in Frankfurt statt Dublin), muss diese Freigabe vor Cut-over vorliegen.

4.5 Bewerber-Kommunikation in der Übergangsphase

Bewerber, die in Phase 3 in beiden Systemen geprüft werden, müssen darüber informiert werden — sonst liegt ein Art. 13 DSGVO-Informationsverstoß vor. Lösung: Pilot-Kohorte erhält eine separate, klare Information über die Doppelprüfung und die Datennutzung.

5. Kosten-Realität: Was eine Migration tatsächlich kostet

Die direkte Tool-Lizenz ist der kleinste Kostenblock. Die Total-Cost-of-Migration verteilt sich anders, als CFOs sie typischerweise budgetieren:

• Interne Personenstunden: 60–120 Stunden HR + Compliance + Legal über alle fünf Phasen — der größte Block.

• Externer Datenschutzberater: Für die DSFA-Aktualisierung und ggf. den DPO-Sign-off — kalkuliert mit 4.000–12.000 € je nach Reife der internen DSFA-Struktur.

• Doppel-Lizenz im Pilotzeitraum: 4–8 Wochen parallele Lizenzgebühren, oft 10–20 % der Jahreslizenz.

• Schulung und Change Management: 2–3 Trainings für Recruiter und HR Business Partner.

6. Was im neuen Vertrag stehen muss

Die Verhandlung des neuen AVV ist der Hebel, an dem ein Großteil der späteren Audit-Sicherheit entsteht. Acht Klauseln, die nicht fehlen dürfen:

• 1. Datenstandort-Garantie: Alle Verarbeitung in EU/EWR oder Schweiz, kein Drittlandtransfer ohne explizite Zustimmung.

• 2. Sub-Prozessor-Veto: Recht auf Widerspruch bei Sub-Prozessor-Wechsel innerhalb von 30 Tagen.

• 3. Audit-Recht: Vor-Ort-Audit oder qualifizierter Drittauditor — nicht nur SOC-2-Bericht.

• 4. Löschverpflichtung mit Frist: Maximal 30 Tage nach Vertragsende, mit schriftlicher Bestätigung inklusive Sub-Prozessoren.

• 5. Datenexport-Klausel: Vollständiger Export aller Daten in offenem Format (CSV + signierte PDFs) auf Anforderung — kein Vendor-Lock-in.

• 6. Aufsichtsbehörden-Kooperation: Sofort-Information bei Auskunftsersuchen durch Behörden, soweit gesetzlich zulässig.

• 7. Haftungsregelung: Konzernweite Haftung für Verletzungen, kein Cap unter dem dreifachen Jahreshonorar.

• 8. AGB-Änderungs-Sperre: Einseitige Änderungen der TOMs, der Sub-Prozessoren oder des Datenstandorts nur mit Sonderkündigungsrecht.

Was gilt in der Schweiz, Österreich und EU-weit?

Schweiz: revDSG und FINMA-Outsourcing-Rundschreiben

Das revidierte Bundesgesetz über den Datenschutz (revDSG) vom 1. September 2023 hat die Schweiz dem EU-Niveau weitgehend angenähert. Wer aus der Schweiz auf US-Anbieter migriert, hat zusätzlich die FINMA-Anforderungen an Outsourcing nach Rundschreiben 2018/3 zu beachten.

Konkret bedeutet das: Auslagerungen wesentlicher Funktionen — und Background-Checks für Geschäftsleiter beaufsichtigter Institute fallen darunter — müssen der FINMA angezeigt werden. Eine Migration löst diese Anzeigepflicht erneut aus. Die Anzeige umfasst Risikobeurteilung, Vertragsdokumente, Wesentlichkeits-Einschätzung.

Datenstandort Schweiz ist für Schweizer Banken und Versicherer de facto Standard — nicht weil das revDSG es verlangt, sondern weil das Bankgeheimnis nach Art. 47 BankG bei Drittstaaten-Verarbeitung erheblich erschwert wird.

Schweizer Mittelständler ohne FINMA-Aufsicht haben mehr Flexibilität, sollten aber dieselbe TIA-Logik anwenden wie EU-Unternehmen — die Schweiz hat eigene Schrems-II-äquivalente Rechtsprechung in Vorbereitung.

Österreich: DSG-Novelle und FMA-Aufsichtspraxis

Das österreichische Datenschutzgesetz (DSG) ergänzt die DSGVO und enthält in § 11 DSG spezielle Regelungen zur Datenübermittlung. Die österreichische Datenschutzbehörde (DSB) hat in ihrer Aufsichtspraxis den US-Datentransfer in mehreren Verfahren 2022–2024 bereits als unzulässig eingestuft, insbesondere bei Google Analytics — die Logik überträgt sich auf Background-Check-Tools.

Die FMA als österreichisches Pendant zur BaFin/FINMA hat in ihrem Rundschreiben zu IT-Auslagerungen klare Vorgaben für Background-Check-Auslagerungen bei Banken, Versicherern und Wertpapierfirmen. Migration von US-Tools zu EU-Anbietern wird hier zunehmend nicht nur empfohlen, sondern in der Aufsichts-Praxis erwartet.

Österreichische Unternehmen profitieren bei der Migration zudem von der engen Abstimmung zwischen DSB und Arbeitsinspektorat — bei Background-Checks mit Bezug zum Arbeitsverfassungsgesetz sind sowohl datenschutz- als auch betriebsverfassungsrechtliche Fragen geklärt zu beantworten.

EU-weit: DORA, NIS2 und der AI Act

Die DORA-Verordnung (EU) 2022/2554 ist seit 17. Januar 2025 anwendbar und verpflichtet Finanzunternehmen zu detailliertem ICT-Drittparteien-Management. Background-Check-Anbieter fallen darunter, sobald sie als kritische ICT-Drittparteien qualifiziert werden — was bei Geschäftsleiter-Prüfungen regelmäßig der Fall ist.

NIS2 (EU) 2022/2555 verschärft die Lieferketten-Sorgfaltspflichten. Wer einen US-Anbieter ohne EU-Niederlassung nutzt, muss diese Lücke in der Lieferketten-Resilienz dokumentieren — oder eben migrieren.

Der EU AI Act (Verordnung 2024/1689) klassifiziert HR-Entscheidungssysteme, die auf Background-Checks aufsetzen, als Hochrisiko-KI nach Anhang III Nr. 4, sobald algorithmische Vorauswahl stattfindet. Wer einen US-Anbieter mit ML-Komponente nutzt, muss zusätzlich die Konformitätsbewertung nach Art. 43 AI Act durchlaufen — bei US-Anbietern mit US-Trainingsdaten praktisch nicht stemmbar.

7. Migration als strategische Chance, nicht als Kostenfaktor

Wer eine Tool-Migration nur als Kostenposition rechnet, übersieht den eigentlichen Hebel. Eine sauber durchgeführte Migration ist gleichzeitig ein Compliance-Reset: Die DSFA wird auf den aktuellen Stand gebracht, der AVV wird verhandelt, die Prozesse werden geschult, und die Audit-Trail-Logik wird konsolidiert. Drei Punkte, die im Migrations-Projektplan explizit auftauchen sollten:

• ✅ DSFA-Refresh: Statt nur die DSFA für den neuen Anbieter zu aktualisieren, eine vollständige Neu-Beurteilung des Background-Check-Prozesses durchführen.

• ✅ Schulungs-Update: Recruiter und Compliance-Team werden ohnehin neu geschult — diese Gelegenheit nutzen für eine Auffrischung der § 26 BDSG- und MaRisk-AT-9-Inhalte.

• ✅ Vendor-Management-Reform: Die Termination-Matrix der laufenden Migration ist die Basis für ein konsistentes Vendor-Lifecycle-Management aller Drittanbieter.

Buche eine Demo — wir zeigen Ihnen den vollständigen Migrations-Workflow live, inklusive Side-by-Side-Vergleich Ihres aktuellen Tools mit Indicium auf einer realen Test-Kohorte. 30 Minuten, ohne Verpflichtung.