Testbetrieb HR‑Software DSGVO: Was das BAG‑Urteil vom 08.05.2025 jetzt konkret verlangt

Der Testbetrieb HR‑Software DSGVO ist möglich – aber nur mit klarer Erforderlichkeitsprüfung, enger Datenliste und einer Betriebsvereinbarung, die in der Praxis gelebt wird. Das Bundesarbeitsgericht hat am 08.05.2025 (8 AZR 209/21) entschieden, dass Echtdaten im Test auf Grundlage von Art. 6 Abs. 1 lit. f) DSGVO zulässig sein könnten, wenn Dummy‑Daten den Testzweck erkennbar nicht erreichen. Zugleich hat es Grenzen aufgezeigt: Schon eine kleine Überschreitung der zulässigen Datenkategorien führte zu 200,00 € immateriellem Schadensersatz zuzüglich Zinsen seit dem 26.05.2018. Wer den Testbetrieb HR‑Software DSGVO plant, sollte deshalb von Anfang an auf Minimalprinzip, nachvollziehbare Begründung und BV‑Disziplin setzen.

Kernaussagen in 60 Sekunden

Kern der Entscheidung ist die Anerkennung, dass ein Testbetrieb HR‑Software DSGVO auf das berechtigte Interesse gestützt werden kann, wenn weniger eingriffsintensive Alternativen – etwa synthetische oder ausreichend realistische Dummy‑Daten – den Testzweck nicht erreichen. Das Gericht hat aber zugleich klar gemacht, dass die Grundsätze aus Art. 5 DSGVO den Rahmen bilden und dass schon kleine Abweichungen von einer vereinbarten Datenliste zu einem (wenn auch geringen) Schadensersatz führen können. Ergänzend betont der EuGH (Urteil vom 19.12.2024, C‑65/23), dass Kollektivvereinbarungen keine Abkürzung darstellen: Auch bei einer Betriebsvereinbarung bleiben Art. 5, Art. 6 und gegebenenfalls Art. 9 DSGVO voll anwendbar; die gerichtliche Kontrolle ist umfassend. Die Vorinstanz LAG Baden‑Württemberg (25.02.2021, 17 Sa 37/20) hatte das Bild teils anders gezeichnet, das BAG hat den Maßstab nachgeschärft und ein wichtiges Signal für die Praxis gesetzt.

Für Unternehmen bedeutet das: Ohne konkrete und schriftlich nachvollziehbare Erforderlichkeitsbegründung gibt es keinen Echtdaten‑Test. Die zulässigen Datenkategorien müssen im Vorfeld eng definiert und im Betrieb strikt eingehalten werden. Dokumentation wird zum praktischen Risikofilter: Warum genügen Dummy‑Daten nicht, welche Felder sind wirklich nötig, welche Schutzmaßnahmen sind aktiviert und wann wird gelöscht? Die schnelle Lehre lautet deshalb, dass selbst kleine Überschreitungen greifbare Folgen haben können. Der Merksatz für den Alltag: Testbetrieb HR‑Software DSGVO funktioniert nur mit Minimalprinzip, sauberer Begründung und gelebter BV‑Disziplin.

Sachverhalt

Die Parteien stritten über die Nutzung von Beschäftigtendaten im Rahmen eines Testbetriebs für eine neue HR‑Software. Die Beklagte, ein deutsches Unternehmen innerhalb eines internationalen Konzerns mit Konzernobergesellschaft in Washington, D.C., plante 2017 die konzernweite Einführung der cloudbasierten Personal‑Informationsmanagementsoftware „Workday“. Um das System zu befüllen und zu testen, lud die Beklagte zwischen dem 24. April und dem 18. Mai 2017 personenbezogene Daten aus ihrer bestehenden Personalverwaltungssoftware auf eine SharePoint‑Seite der Konzernobergesellschaft mit Serverstandort in den USA, um sie von dort nach Workday zu übertragen. Neben typischen Stammdaten wie Name, Vorname, dienstlicher Telefonnummer und dienstlicher E‑Mail wurden auch zahlreiche weitere Angaben übertragen, darunter Vergütungsdaten (Jahres‑ und Monatsgehalt, variable Anteile), die private Wohnanschrift, Geburtsdatum, Familienstand sowie Sozialversicherungsnummer und Steuer‑ID des Klägers. Der Kläger war langjähriger Mitarbeiter und zugleich Vorsitzender des bei der Beklagten gebildeten Betriebsrats.

Am 3. Juli 2017 schlossen die Beklagte und der Betriebsrat eine „Duldungs‑Betriebsvereinbarung über die Einführung von Workday“. Diese BV regelte ausdrücklich nur den vorläufigen Betrieb zu Testzwecken, untersagte eine Nutzung für operative HR‑Prozesse und sah vor, dass vor einem Produktiveinsatz eine gesonderte Betriebsvereinbarung zu schließen ist. In der Anlage 2 zur Duldungs‑BV wurde ein abschließender Datenkatalog für die testweise Nutzung festgelegt: Personalnummer, Nachname, Vorname, Eintrittsdatum, Eintrittsdatum im Konzern, Arbeitsort, Gesellschaft/Firma sowie geschäftliche Telefonnummer und geschäftliche E‑Mail‑Adresse. Die Wirkungen der Duldungs‑BV wurden mehrfach verlängert und endeten erst mit Abschluss einer endgültigen Betriebsvereinbarung im Januar 2019.

Der Kläger machte geltend, die Verarbeitung seiner Echtdaten in Workday sei – jedenfalls ab dem 25. Mai 2018 – nicht erforderlich gewesen; für die beabsichtigten Tests hätten synthetische („Dummy‑“)Daten ausgereicht. Außerdem habe die Beklagte über den in der Duldungs‑BV genannten Datenkatalog hinaus zusätzliche Kategorien wie private Kontaktdaten, Vertrags‑ und Vergütungsdetails sowie Sozialversicherungsnummer und Steuer‑ID übertragen. Zunächst hatte der Kläger auch Verstöße im Zusammenhang mit der Übermittlung auf die US‑SharePoint‑Seite und der Auftragsverarbeitung behauptet. Im Verlauf des Revisionsverfahrens beschränkte er sein Begehren jedoch ausdrücklich auf den Vorwurf der „überschießenden“ Datenverarbeitung, also auf die Verarbeitung von Daten, die von der Duldungs‑BV nicht erfasst waren.

Die Beklagte bestritt einen Rechtsverstoß und sah den Testbetrieb als zulässig an. Arbeitsgericht und Landesarbeitsgericht wiesen den immateriellen Schadensersatzanspruch zunächst ab. Das Bundesarbeitsgericht setzte das Verfahren aus und legte Fragen zur Auslegung von Art. 88 DSGVO dem EuGH vor. Nach der EuGH‑Entscheidung vom 19. Dezember 2024 (C‑65/23) entschied das BAG am 8. Mai 2025: Ein Test mit Echtdaten kann zwar grundsätzlich auf ein berechtigtes Interesse gestützt sein, wenn Dummy‑Daten den Testzweck nicht erreichen. Im konkreten Fall war jedoch die Verarbeitung der über den BV‑Katalog hinausgehenden Daten rechtswidrig. Das Gericht sprach dem Kläger 200,00 € immateriellen Schadensersatz zuzüglich Zinsen seit dem 26. Mai 2018 zu.

Rechtlicher Rahmen & Einordnung

1) Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse

Die Rechtsgrundlage kann das berechtigte Interesse des Arbeitgebers sein, neue oder geänderte Systeme vor dem Produktiveinsatz belastbar zu prüfen. Dieses Interesse trägt jedoch nur, wenn die Erforderlichkeit sorgfältig belegt ist. Solange Dummy‑Daten denselben Zweck erreichen, haben Echtdaten Pause. Notwendig werden sie erst, wenn objektiv nachvollziehbare Gründe vorliegen, etwa komplexe Rollen‑ und Rechtekonzepte, abhängige Workflows über mehrere Module, Integrationen in Drittsysteme oder realistische Fehlerszenarien, die sich mit synthetischen Daten nicht zuverlässig nachstellen lassen.

„Allerdings stellt sich hier die überschießende Datenverarbeitung im Ergebnis schon deshalb als nicht erforderlich iSv. Art. 6
Abs. 1 Unterabs. 1 Buchst. f DSGVO dar, weil sie über die Erlaubnis in der BV Duldung hinausgeht“

_{(BAG, Urteil vom 08.05.2025, Az.: 8 AZR 209/21)}

2) Art. 5 DSGVO – Grundsätze

Die Grundsätze liefern die Leitplanken. Datenminimierung bedeutet, nur die Felder zu verarbeiten, die für den konkreten Testfall zwingend sind. Zweckbindung heißt, dass die Daten ausschließlich dem Testzweck dienen und nicht in operative HR‑Prozesse hineinwirken. Speicherbegrenzung verlangt einen klaren Löschstichtag, idealerweise automatisiert und nachweisbar. Integrität und Vertraulichkeit werden über angemessene TOMs gesichert – von Verschlüsselung und Rollenmodellen über Pseudonymisierung bis hin zu belastbarem Logging.

3) Art. 88 DSGVO i. V. m. § 26 BDSG – Kollektivvereinbarungen

Eine Betriebsvereinbarung kann den Testbetrieb präzise rahmen, sie senkt die DSGVO aber nicht ab. Gerichte prüfen vollumfänglich, ob Zweck, Datenliste, Zugriffsregeln, Berichtspflichten, Verbote (etwa von Leistungs‑/Verhaltenskontrollen) und Löschung mit den Grundsätzen harmonieren. Je klarer und abschließender die BV formuliert ist, desto besser lässt sich der Testbetrieb steuern – und desto geringer ist das Risiko von Ausreißern.

4) Art. 82 DSGVO – immaterieller Schadensersatz

Ein Bagatellfilter existiert nicht. Erforderlich ist ein Verstoß, ein (auch geringer) Schaden und Kausalität. Überschreitungen der BV, unklare Erforderlichkeit oder Defizite bei Löschung und TOMs sind in der Praxis die größten Risikotreiber. Der zugesprochene Betrag im entschiedenen Fall war klein, die Botschaft ist groß: Jeder Verstoß kann Folgen haben.

Praxis: So setzen Sie den Testbetrieb sauber um

In der Umsetzung bewährt sich ein schlanker, aber konsequenter Ablauf. Am Anfang steht die präzise Beschreibung des Use‑Cases: Welche Funktionen, Rollen, Schnittstellen und Reports werden geprüft und aus welchem Grund? Darauf folgt eine nüchterne Alternativenprüfung. Hier wird festgehalten, mit welchen Dummy‑ oder synthetischen Daten sich das Ziel erreichen ließe und warum das im konkreten Fall nicht genügt. Gute Gründe sind historisierte personenbezogene Abhängigkeiten, die sich nicht glaubhaft simulieren lassen, oder die Notwendigkeit, echte Fehlerbilder aus Altdaten zu reproduzieren. Bequemlichkeit, fehlende Tools oder Zeitdruck reichen nicht.

Sodann wird ein abschließender Datenkatalog definiert, der nur jene Felder enthält, die für die Testfälle zwingend sind. Typisch und oft ausreichend sind

• Personalnummer
• Name
• Eintrittsdatum
• Standort
• Gesellschaft
• geschäftliche Kontaktdaten.

Privatadressen, Steuer‑ID, Sozialversicherungsnummer, Vergütungsdetails sowie besondere Kategorien personenbezogener Daten gehören in der Regel nicht hinein. Die Betriebsvereinbarung

• beschreibt den Zweck („einmaliger Test zur Funktions‑ und Belastungsprüfung“),
• setzt einen klaren Zeitraum mit Enddatum,
• regelt Rollen und Rechte,
• untersagt Leistungs‑ und Verhaltenskontrollen,
• beschränkt Reporting auf die Funktionsprüfung und

verpflichtet auf starke technische und organisatorische Maßnahmen. Dazu zählen

• Verschlüsselung in Transit und at Rest,
• Mandantentrennung,
• Export‑Sperren,
• Wasserzeichen beim Datenexport,
• revisionssicheres Audit‑Logging,
• eine SIEM‑Anbindung,
• regelmäßige Rechte‑Reviews und
• ein Vier‑Augen‑Prinzip für privilegierte Administrationsvorgänge.

Zentral ist die Löschung: Sie erfolgt fristgebunden, automatisiert und nachvollziehbar – inklusive Backups – und wird protokolliert.

Typische Fehlerquellen lassen sich vermeiden, wenn die Datenliste als harte Leitplanke verstanden wird: Zusätzliche Felder werden nicht „kurz mitgenommen“. Testreports bleiben Testreports und werden nicht für operative HR‑Entscheidungen umgedeutet. Löschtermine sind fix, automatisiert und protokolliert. Und Logging heißt nicht nur „im Tool aktiviert“, sondern beweissicher konzipiert, mit Exportverboten und Auswertungsmöglichkeiten im Sicherheitsmonitoring.

„Die Verarbeitung personenbezogener Daten, um eine neue Personalverwaltungs-Software zu testen, kann nach Art. 6 Abs. 1 Unterabs. 1 Buchst. f DSGVO zur Wahrung der berechtigten Interessen des Arbeitgebers gerechtfertigt sein, sofern entpersonalisierte „Dummy-Daten“ zur Erreichung des Testzwecks nicht ausreichen.„

_{(BAG, Urteil vom 08.05.2025, Az.: 8 AZR 209/21)}

Blueprint: Betriebsvereinbarung „Testbetrieb HR‑Software“

Ein praxistauglicher Blueprint ist schnell beschrieben. Er beginnt mit Zweck und Zeitraum: ein einmaliger, klar abgegrenzter Testbetrieb HR‑Software DSGVO zur Evaluation von Workflows und Funktionen, mit einem konkreten Beginn, einem ebenso konkreten Ende und ohne Nachwirkung, sodass ein Go‑Live nur auf Basis einer neuen Vereinbarung möglich ist.

Herzstück ist ein abschließender Datenkatalog mit wenigen Feldern wie Personalnummer, Name, Vorname, Eintrittsdatum (ggf. auch konzernweit), Arbeitsort, Gesellschaft sowie geschäftliche E‑Mail und Telefonnummer. Explizit ausgeschlossen bleiben Privatanschrift, Staatsangehörigkeit, Familienstand, Steuer‑ und Sozialversicherungsnummer, Vergütungsdetails sowie Gesundheits‑ oder Religionsdaten. Die Rollen und Zugriffe sind rollenbasiert organisiert; privilegierte Administration erfolgt im Vier‑Augen‑Prinzip. Der Betriebsrat erhält Einsichts‑ und Kontrollrechte und wird geschult. Verarbeitungsgrenzen stellen klar, dass die Daten ausschließlich Testzwecken dienen, dass keine operativen HR‑Prozesse stattfinden, dass Leistungs‑ und Verhaltenskontrollen tabu sind und dass Reporting ausschließlich der Funktionsprüfung dient. Technische und organisatorische Maßnahmen sichern den Rahmen: Verschlüsselung, Mandantentrennung, Export‑Sperren, Wasserzeichen, revisionssicheres Audit‑Logging mit SIEM‑Anbindung sowie regelmäßige Rechte‑Reviews. Die Löschung erfolgt spätestens T+30 nach Testende, umfasst auch Backups und wird über ein Löschprotokoll nachgewiesen. Information und Schulung runden den Blueprint ab, und eine klare Schlussklausel verweist im Konfliktfall auf die Einigungsstelle und bestätigt das Ende ohne Nachwirkung. Ein kleiner, aber wirksamer Tipp: Benennen Sie die Vereinbarung ausdrücklich „Testbetrieb HR‑Software DSGVO“. Der Zweck springt dann ins Auge und verhindert Missverständnisse.

DSFA‑Light

Die DSFA‑Light konzentriert sich auf das Wesentliche. Sie beschreibt zunächst den Zweck, also die Prüfung von HR‑Workflows, Rollen, Schnittstellen und typischen Integrationen wie Payroll‑Export, Zeitwirtschaft oder Bewerberimport. Danach bewertet sie die Alternativen und erklärt, weshalb Dummy‑ oder synthetische Daten für die vorgesehenen Tests nicht genügen – etwa wegen komplexer personenbezogener Parametrik, modulübergreifender Abhängigkeiten oder weil reale Fehlerbilder aus Altdaten nachgestellt werden müssen. Der Datenkatalog folgt dem Blueprint und ist abschließend formuliert.

Im Abschnitt zu Empfängern und Standorten legt die DSFA‑Light fest, dass die Verarbeitung in einer internen EU/EWR‑Testumgebung erfolgt; Drittlandzugriffe werden nur zugelassen, wenn sie ausnahmsweise zwingend sind und vertraglich sowie technisch (SCC, Transfer‑Impact, zusätzliche Maßnahmen) abgesichert werden – idealerweise vermeiden Sie sie im Test vollständig. Die TOMs werden konkret benannt: starke Verschlüsselung, gehärtete Systeme, Just‑in‑Time‑ und Privileged‑Access‑Kontrollen, Deaktivierung aller Produktiv‑Integrationen, Export‑Sperren, vollständige Protokollierung aller Exporte und Downloads sowie regelmäßige Review‑Meetings. Eine klare Zeitachse strukturiert das Projekt mit Vorbereitungen bis T‑30, Start bei T‑0 und Löschung einschließlich Nachweis bis T+30. Go/No‑Go‑Kriterien machen die Entscheidung greifbar: Go bei belegter Erforderlichkeit, geschlossenem Datenkatalog und umgesetzten Maßnahmen; No‑Go bei unklarer Erforderlichkeit, offenem Katalog, fehlender Löschautomatik oder ungesicherten Drittlandübermittlungen. Der Löschtermin wird verbindlich als T+30 festgelegt und umfasst auch Backups; der Nachweis geht an DSB und Betriebsrat.

Beweisführung, die hält…

Beweissicherheit entsteht, wenn Dokumentation nicht als lästige Pflicht, sondern als Projektbestandteil verstanden wird. Die Unterlagen beantworten jederzeit, wer beteiligt ist, was genau getestet wird, wann Freigaben erfolgt sind, wo die Umgebung liegt und wie die Verarbeitung abgesichert wird. Dazu gehören eine saubere Beschreibung der Testfälle und aktivierten Module, eine klare Felderliste, die Definition zulässiger Reports und Exporte, ein Zeitplan mit Freigaben und Schaltprotokollen, Angaben zu Mandanten und Regionen, ein vollständiges Audit‑Logging aller Exporte sowie der abschließende Lösch‑Report. Ein laufender Abgleich mit der Betriebsvereinbarung stellt sicher, dass nur die zulässigen Felder genutzt werden und die Grundsätze aus Art. 5 durchgängig eingehalten sind. So sinkt nicht nur das rechtliche, sondern auch das operative Risiko.

Mythen vs. Fakten

Der verbreitete Mythos, mit einer Betriebsvereinbarung sei alles erlaubt, hält der Realität nicht stand. Eine BV schafft Sichtbarkeit, Grenzen und Kontrolle, aber keine Immunität gegenüber der DSGVO. Ebenso falsch ist die Annahme, im Test dürfe man mehr, weil es „nur Test“ sei; der Test ist ein eigener Zweck und unterliegt denselben Grundsätzen. Wer 200 Euro Schadensersatz als Peanuts abtut, verkennt das Signal: Jeder Verstoß kostet – rechtlich und reputativ. Und schließlich sind Dummy‑Daten zwar oft ausreichend und sollten der Standard sein, aber nicht immer; in den wenigen Ausnahmen braucht es eine tragfähige, vorher dokumentierte Begründung.

Mini‑Case aus der Praxis

Ein internationaler Konzern prüfte eine große HR‑Suite konzernweit. Eine Duldungs‑BV legte Zweck und eine enge Datenliste fest. Im Projektverlauf wurden jedoch zusätzliche Felder aktiviert, die über die Vereinbarung hinausgingen, teils aus Tempo, teils aus Feature‑Neugier, teils aus fehlender Kontrolle. Juristisch machte das einen kleinen, aber echten Unterschied: Der Verstoß war gering, der Schadensersatz ebenfalls, die Lehre deutlich. Hätte das Team die Datenliste als harte Leitplanke behandelt, die Umgebungen strikt isoliert und die Löschung automatisiert, hätte sich das Risiko spürbar reduziert.

30‑Tage‑Plan

Der 30‑Tage‑Plan folgt einem einfachen Rhythmus. In Woche 1 klären Sie Ziele, Module, Schnittstellen und definierst, welche Dummy‑Optionen es gibt und warum sie im Zweifel nicht reichen. Gleichzeitig entsteht ein erster Datenkatalog und eine Liste der technischen Maßnahmen. In Woche 2 wird die Betriebsvereinbarung finalisiert, die Interessenabwägung nach Art. 6 Abs. 1 lit. f) DSGVO dokumentiert und die DSFA‑Light gestartet; parallel richten Sie Mandant, Verschlüsselung, Export‑Sperren und Logging ein. In Woche 3 informieren Sie die Belegschaft im Intranet, schulen das Testteam und den Betriebsrat, holen die formale Freigabe ein und starten erst dann den Testbetrieb HR‑Software DSGVO. In Woche 4 machen Sie einen Abgleich der tatsächlichen Verarbeitung mit dem, was in der Betriebsvereinbarung (BV) erlaubt ist. Sie prüfen also, ob im Test genau die Zwecke verfolgt, nur die freigegebenen Datenfelder genutzt, nur die vorgesehenen Personen mit den richtigen Rechten zugegriffen, keine unzulässigen Reports/Exporte erstellt und die Löschfrist eingehalten wurde. Am Testende stoßen Sie unmittelbar nach Testende die Löschung an, berücksichtigen Backups und übergeben Lösch‑Report, Log‑Auszüge und ein Abschluss‑Memo an Datenschutzbeauftragten und Betriebsrat.

Fazit

Der Testbetrieb HR‑Software DSGVO ist kein No‑Go, aber ein eng geführtes Vorhaben. Die Kombination aus Art. 6 Abs. 1 lit. f DSGVO, den Grundsätzen aus Art. 5 und einer präzisen, gelebten Betriebsvereinbarung trägt, sofern Dummy‑Daten tatsächlich nicht ausreichen. Wer die Erforderlichkeit schlüssig dokumentiert, den Datenkatalog strikt beachtet, technische Maßnahmen ernst nimmt und die Löschung beweisbar umsetzt, reduziert das Risiko in der Sache und in der Außenwirkung deutlich. Als interne Vertiefung bietet sich ein Praxisleitfaden zum immateriellen Schadensersatz nach Art. 82 DSGVO an; als externe Referenz eignen sich das EuGH‑Urteil vom 19.12.2024 (C‑65/23) und das BAG‑Urteil vom 08.05.2025 (8 AZR 209/21), die die Leitplanken für Testbetriebe mit Echtdaten präzise abstecken.