Konzernstruktur und Background Checks: Konsistenz über Tochtergesellschaften
Für internationale Konzerne ist die Frage nicht, ob Background Checks stattfinden, sondern wie sie konzernweit so orchestriert werden, dass die Gruppe einheitlich auftritt und gleichzeitig jede lokale Tochter ihre regulatorischen Pflichten erfüllt. Wer diese Balance verfehlt, erntet zwei Probleme gleichzeitig: inkonsistente Screening-Standards zwischen Töchtern und lokale Aufsichtsbeanstandungen, weil die zentrale Policy an nationalen Spezifika vorbeigeht. Dieser Beitrag zeigt, wie Konzerne Background-Check-Prozesse harmonisieren, ohne lokale Compliance zu verletzen.
Die Kernfrage: Wer ist verantwortlich?
Jedes Background-Check-Programm in einer Konzernstruktur beginnt mit einer datenschutzrechtlichen Grundsatzentscheidung. Die DSGVO kennt drei Rollen: den Verantwortlichen (Art. 4 Nr. 7 DSGVO), den gemeinsam Verantwortlichen (Art. 26 DSGVO) und den Auftragsverarbeiter (Art. 28 DSGVO). Welche Konstellation zwischen Muttergesellschaft, Tochter und Group Compliance zutrifft, bestimmt Haftung, Vertragswerk und operative Prozesse.
Die Tochter als eigenständiger Verantwortlicher
Der Regelfall: Die Tochtergesellschaft schließt den Arbeitsvertrag, verarbeitet die Bewerberdaten für eigene Zwecke und ist Verantwortlicher im Sinne der DSGVO. Die Mutter erbringt hier allenfalls Support-Leistungen. Diese Konstellation ist sauber, erzeugt aber das Harmonisierungsproblem: Wenn jede Tochter für sich selbst entscheidet, driften Standards auseinander.
Gemeinsame Verantwortung nach Art. 26 DSGVO
Wenn Mutter und Tochter gemeinsam über Zweck und Mittel der Verarbeitung entscheiden – etwa weil die Gruppe eine verbindliche Screening-Policy vorgibt und zentrale Systeme betreibt – entsteht gemeinsame Verantwortung. Das verlangt eine Vereinbarung nach Art. 26 DSGVO, in der die Pflichten transparent abgegrenzt sind, insbesondere zu Betroffenenrechten. Betroffene können ihre Rechte gegenüber jeder Stelle geltend machen (Art. 26 Abs. 3 DSGVO) – ein oft unterschätztes Risiko.
Auftragsverarbeitung innerhalb des Konzerns
Stellt die Muttergesellschaft der Tochter lediglich ein technisches System oder ein Shared-Service-Team bereit, ohne eigene Zwecke zu verfolgen, liegt klassische Auftragsverarbeitung vor. Dann ist ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO zwischen Mutter und Tochter erforderlich. Das sogenannte „Konzernprivileg" existiert in der DSGVO nicht – auch konzerninterne Datenflüsse benötigen eine Rechtsgrundlage und – bei Auftragsverarbeitung – einen AVV.
Internationale Datenflüsse: Binding Corporate Rules
Sobald Bewerberdaten über Ländergrenzen fließen – insbesondere in Drittländer außerhalb des EWR – wird Kapitel V DSGVO relevant. Standardvertragsklauseln (SCC) sind der häufigste Weg, für multinationale Konzerne aber oft nicht die beste Wahl. Binding Corporate Rules (BCR) nach Art. 47 DSGVO sind verbindliche interne Datenschutzregeln, die von der zuständigen Aufsichtsbehörde genehmigt werden und konzernweite Datentransfers legitimieren.
BCR sind aufwendig zu etablieren – Genehmigungsverfahren dauern typischerweise 18 bis 24 Monate – haben aber drei strategische Vorteile:
Einmal genehmigt, decken sie alle konzerninternen Transfers ab, ohne dass für jedes Rechtsverhältnis separat SCC abgeschlossen werden müssen.
Sie signalisieren Regulatoren ein hohes Compliance-Niveau und reduzieren das Risiko bei Audits.
Sie schaffen intern eine verbindliche Governance-Architektur, die über Datenschutz hinaus wirkt.
Für Konzerne mit Tochtergesellschaften in UK, USA oder APAC sind BCR in der Regel die tragfähigere Lösung als ein Flickenteppich aus SCC.
Konzern-weite Policies vs. länderspezifische Compliance
Die operative Kernherausforderung: Eine zentrale Policy muss einheitliche Mindeststandards setzen, darf aber nicht so eng sein, dass sie lokale Pflichten ignoriert oder lokale Verbote verletzt. Dies gilt insbesondere im regulierten Sektor.
Was gilt in der Schweiz, Österreich und EU-weit?
Deutschland: § 25c KWG und BaFin-Anforderungen
Das deutsche Kreditwesengesetz verpflichtet Institute in § 25c KWG zu einer umfassenden Prüfung der Zuverlässigkeit und fachlichen Eignung von Geschäftsleitern und Schlüsselfunktionen. Die BaFin konkretisiert dies in ihren Merkblättern zu Geschäftsleitern und Verwaltungs- bzw. Aufsichtsorganen. Tochter-Banken in Deutschland müssen dies unabhängig davon umsetzen, was auf Konzernebene gilt. Die zentrale Policy muss den BaFin-Standard als Mindestniveau für DE-Töchter spiegeln.
Schweiz: Art. 3 BankG und FINMA-Gewährsprüfung
In der Schweiz regelt Art. 3 Abs. 2 lit. c BankG die Gewährsprüfung für Bewilligungsträger. Die FINMA erwartet eine dokumentierte Prüfung der Gewähr für einwandfreie Geschäftstätigkeit bei Personen in leitender Stellung. Das Schweizer Datenschutzgesetz (revDSG, in Kraft seit 1. September 2023) unterscheidet sich in Details von der DSGVO – etwa bei Pflichtangaben in Datenschutzerklärungen und bei den Betroffenenrechten – ist aber in der Grundarchitektur kompatibel. Konzerne können DSGVO-Standards als Baseline übernehmen und Schweizer Spezifika ergänzen; umgekehrt genügt ein rein DSGVO-konformer Prozess nicht automatisch den Schweizer Anforderungen.
Österreich: § 5 BWG und FMA-Anforderungen
Das österreichische Bankwesengesetz verlangt in § 5 Abs. 1 Z 6 ff. BWG die Zuverlässigkeit und fachliche Eignung der Geschäftsleiter. Die FMA prüft in der sogenannten Fit-&-Proper-Prüfung. Österreich folgt EU-Harmonisierung (EBA-Leitlinien), setzt aber eigene Formanforderungen. In der Praxis sind DE- und AT-Anforderungen hochgradig ähnlich – aber nicht identisch. Eine gemeinsame „DACH-Policy" ist nur dann sinnvoll, wenn sie die nationalen Unterschiede explizit adressiert, statt sie zu nivellieren.
EU-weit: EBA-Leitlinien und CRD VI
Auf EU-Ebene harmonisieren die EBA-Leitlinien zu Fit & Proper (EBA/GL/2021/06, gemeinsam mit ESMA) die Anforderungen an die Eignungsprüfung im Finanzsektor. CRD VI (Richtlinie (EU) 2024/1619) schärft die Anforderungen weiter und verlangt stärkere Dokumentation der Eignungsprüfung auf Gruppenebene. Für nicht-regulierte Branchen gelten diese Standards nicht direkt, sind aber de facto ein Benchmark für anspruchsvolle Screening-Programme.
Architekturbeispiel: Deutsche Holding mit CH-, AT- und EU-Töchtern
Ein typisches Szenario: Eine deutsche Holding hält Töchter in der Schweiz, Österreich, Frankreich und den Niederlanden. Für ein harmonisiertes Background-Check-Programm empfiehlt sich folgende Architektur:
Group-Level Policy (zentral, Deutsch und Englisch): definiert Screening-Kategorien, Risikoklassen, Mindeststandards, Data-Retention-Regeln und Eskalationspfade.
Lokale Annexe (pro Jurisdiktion): konkretisieren Screening-Umfang, zulässige Auskunftsquellen, Einwilligungstexte und nationale Aufsichtsanforderungen.
Zentrale technische Plattform: ein konzernweit genutztes Screening-System, betrieben von der Holding oder einem Group-Service-Entity – mit AVV an alle Töchter, ggf. unter BCR.
Datenhoheit lokal: Rohdaten (Auskünfte, Dokumente) werden grundsätzlich im Land der Tochter gespeichert; nur aggregierte Entscheidungen und Audit-Metadaten fließen zentral zusammen.
Konsolidiertes Reporting für Group Audits
BaFin, FMA und FINMA prüfen nicht nur einzelne Institute, sondern zunehmend Gruppen. Ein Group Chief Compliance Officer braucht für Aufsichtsgespräche konsolidierte Evidenz: Wie viele Screenings wurden pro Quartal durchgeführt? Welcher Anteil schlug an? Wie wurden Findings eskaliert und abgeschlossen? Welche Töchter weichen vom Gruppenstandard ab – und warum?
Diese Evidenz lässt sich nur generieren, wenn das System bereits im Design auf konsolidiertes Reporting ausgelegt ist. Nachträglich aus Einzelsystemen zu aggregieren ist fehleranfällig und in einem Audit kaum belastbar.
Matrix: Zentrale vs. lokale Datenhaltung
Datenkategorie | Haltung | Begründung |
|---|---|---|
Screening-Policies und Risikoklassen | Zentral | Konzernweite Verbindlichkeit, Versionierung |
Einwilligungstexte (national) | Lokal | Sprache, nationales Recht, DSG/DSGVO-Spezifika |
Rohauskünfte (Führungszeugnis, Sanktionslisten) | Lokal | Datenhoheit, Löschfristen nach nationalem Recht |
Screening-Entscheidungen (Go/No-Go) | Zentral (aggregiert) | Audit-Trail, Group-Reporting |
Audit-Logs und Zugriffsprotokolle | Zentral | Forensische Integrität, Aufsichtsanfragen |
Personenbezogene Bewerberdaten | Lokal | Löschpflichten, Betroffenenrechte, Arbeitsrecht |
Harmonisierung der Screening-Tiefe – risikobasiert, nicht einheitlich
Ein verbreiteter Fehler in Konzernen: der Reflex, alle Töchter auf dasselbe Screening-Niveau zu zwingen. Das ist weder effizient noch rechtlich zulässig. Die DSGVO verlangt in Art. 5 Abs. 1 lit. c Datenminimierung; Screening-Tiefe muss zum tatsächlichen Risiko der Position passen. Eine Praktikantin in einer Vertriebstochter durchläuft nicht denselben Check wie ein designierter Geschäftsleiter einer BaFin-regulierten Bank-Tochter.
Die Lösung: eine konzernweite Risikomatrix mit drei bis fünf Stufen (z.B. Basic, Standard, Enhanced, Senior Executive, Regulated Function), kombiniert mit lokalen Pflichtmodulen. So bleibt die Logik gruppenweit einheitlich, während die konkrete Umsetzung lokal stimmt.
CSRD-Reporting auf Gruppenebene
Die Corporate Sustainability Reporting Directive (CSRD, Richtlinie (EU) 2022/2464) verlangt von großen Unternehmen ab den Geschäftsjahren 2024 bzw. 2025 eine erweiterte Nachhaltigkeitsberichterstattung nach den ESRS. Im „S1 – Own workforce"-Standard sind Governance-Prozesse rund um Mitarbeitende offenlegungspflichtig, inklusive der Prozesse zur Identitäts- und Integritätsprüfung bei der Einstellung.
Background-Check-Programme werden damit zum CSRD-Thema. Ein konsolidiertes, auditierbares Screening-Programm liefert die Datengrundlage für die Berichtspflichten; ein fragmentiertes Programm zwingt zu teurer Nacherhebung.
Governance-Empfehlung für Group CCOs
Für den Group Chief Compliance Officer lassen sich die Erkenntnisse in fünf konkrete Maßnahmen übersetzen:
Rollen klären: Für jede Tochter dokumentieren, ob sie eigenständiger Verantwortlicher, gemeinsam Verantwortlicher oder Auftragsverarbeiter ist – und die passenden Verträge schließen.
BCR-Prüfung: Bei Tochtergesellschaften in Drittländern oder bei zentral betriebenen Plattformen prüfen, ob Binding Corporate Rules gegenüber einem SCC-Flickenteppich der tragfähigere Weg sind.
Zwei-Ebenen-Policy: Gruppen-Policy mit Mindeststandards plus lokale Annexe je Jurisdiktion – niemals eine nivellierte „One-size-fits-all"-Policy.
Konsolidierungsarchitektur: Technische Plattform von Anfang an so designen, dass lokale Datenhoheit und zentrales Reporting kein Widerspruch sind.
CSRD-Readiness: Screening-Prozesse im Hinblick auf ESRS-S1-Offenlegungspflichten dokumentieren, nicht erst bei der ersten Berichterstattung.
Konzerne, die diese Punkte früh ordnen, reduzieren Auditrisiken, sparen Integrationskosten bei M&A und können neue Töchter schneller an Konzernstandards andocken. Wer das aufschiebt, zahlt später mit Mehraufwand – oder mit Feststellungen im Aufsichtsbericht.
Typische Fehler in Konzern-Rollouts – und wie man sie vermeidet
In der Praxis wiederholen sich vier Fehler bei konzernweiten Background-Check-Programmen mit hoher Frequenz. Wer sie kennt, vermeidet einen Großteil der Nacharbeit.
Fehler 1: Rollenklärung erst nach Systemauswahl. Viele Konzerne wählen zuerst eine Screening-Plattform und klären erst danach die datenschutzrechtliche Rollenverteilung. Das Ergebnis sind Systeme, deren Mandantentrennung, Zugriffsrechte und Datenflüsse nicht zum tatsächlichen Verantwortlichkeitsmodell passen. Reihenfolge richtig: erst Rollen, dann Vertragswerk, dann System.
Fehler 2: Gruppenpolicy ohne lokale Validierung. Eine am Konzernhauptsitz geschriebene Policy wird ohne Rücksprache mit lokalen Compliance-Verantwortlichen ausgerollt. Spätestens der erste Aufsichtsdialog in der Schweiz oder Österreich legt offen, dass nationale Spezifika – Schweizer DSG-Pflichten, österreichische FMA-Formulare, deutsche BZR-Regeln – nicht korrekt adressiert sind. Gegenmittel: Policy-Entwurf zirkuliert vor Verabschiedung durch alle lokalen Legal- und Compliance-Funktionen, Abzeichnung dokumentiert.
Fehler 3: Technische Plattform ohne Mandantenfähigkeit. Plattformen, die lokale Datenhoheit erst durch organisatorische Zugriffsregeln statt durch technische Mandantentrennung herstellen, halten einem ernsthaften Audit selten stand. Gesucht ist eine Architektur, in der jede Tochter ihre eigene logische Instanz mit eigenen Schlüsseln, eigener Datenresidenz und granularer Zugriffskontrolle erhält – zentrale Aggregation nur auf Metadatenebene.
Fehler 4: Keine Kommunikation an Bewerber und Mitarbeitende. Wer konzernweit Screening einführt, ohne transparent zu kommunizieren, riskiert arbeits- und betriebsverfassungsrechtliche Konflikte. In Deutschland verlangt § 87 Abs. 1 Nr. 6 BetrVG die Mitbestimmung des Betriebsrats bei der Einführung technischer Einrichtungen, die das Verhalten oder die Leistung der Arbeitnehmer überwachen können. Frühzeitige Einbindung von Arbeitnehmervertretungen spart später langwierige Verfahren.
Fazit
Harmonisierte Background Checks im Konzern sind kein IT-Projekt, sondern ein Governance-Projekt mit IT-Komponenten. Die entscheidenden Weichen werden in der Rollenklärung, der Zwei-Ebenen-Policy und dem konzernweiten Trust-Framework gestellt – nicht in der Systemauswahl. Wer die regulatorischen Unterschiede zwischen DE, CH, AT und EU als Designparameter akzeptiert, statt sie zu ignorieren, baut ein Programm, das sowohl gruppenweit steuerbar als auch lokal auditfest ist.
Sie planen ein konzernweites Background-Check-Programm oder wollen ein bestehendes konsolidieren? Buche eine Demo und wir zeigen Ihnen, wie Indicium die Balance zwischen Gruppenstandard und lokaler Compliance technisch abbildet.
Weiterlesen — verwandte Artikel
Nabil El Berr
