Regulierung · 24. September 2026

Testdaten nach SAP TDMS: Was Behörden bei der S/4HANA-Migration klären müssen

Wer SAP-Verfahren auf S/4HANA umstellt, braucht für Tests eine neue Lösung für Testdaten. Der bisher verbreitete SAP Test Data Migration Server, kurz TDMS, ist für S/4HANA nicht vorgesehen, und die Standardwartung der SAP Business Suite endet Ende 2027. Die Frage, womit Testdaten künftig erzeugt werden, ist dabei die kleinere. Die größere lautet: Wie weist eine Behörde nach, dass ihre Testdaten datenschutzkonform sind?

Was sich ändert

TDMS wurde in vielen Häusern genutzt, um schlanke Testsysteme aus Produktivdaten aufzubauen und sensible Inhalte dabei zu verfremden. Das Werkzeug gehört zur Welt der SAP Business Suite 7. SAP hat für deren Kernanwendungen die Standardwartung bis Ende 2027 zugesagt, danach ist optional eine erweiterte Wartung bis Ende 2030 möglich.

Für den Einsatz unter S/4HANA gibt es nach Angaben aus der SAP-Community keine Standardunterstützung und keine Produktplanung für On-Premise-Systeme. Wer migriert, muss das Thema Testdaten also neu aufsetzen. Das ist lästig, aber auch eine Gelegenheit: Viele Testdatenverfahren sind über Jahre gewachsen und wurden nie grundsätzlich auf den Prüfstand gestellt.

Testdaten sind personenbezogene Daten, solange nichts anderes feststeht

Die Datenschutz-Grundverordnung macht keinen Unterschied zwischen Produktiv- und Testumgebung. Personenbezogen sind alle Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen, und zwar unabhängig davon, in welchem System sie liegen.

Entscheidend ist die Unterscheidung zwischen zwei Verfahren, die im Alltag oft gleichgesetzt werden:

• Pseudonymisierung ersetzt identifizierende Merkmale, etwa Namen durch Kennziffern. Für die Behörde, die den Schlüssel zur Zuordnung besitzt, bleiben pseudonymisierte Testdaten personenbezogen. Die DSGVO gilt weiter in vollem Umfang.
• Anonymisierung entfernt den Personenbezug so, dass er nicht mehr oder nur mit unverhältnismäßigem Aufwand wiederhergestellt werden kann. Erst dann fallen die Daten aus dem Anwendungsbereich der DSGVO.

Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit hat dazu eine Kurzposition veröffentlicht und macht darin unmissverständlich klar:

„Software-Entwicklung und -Tests sind keine Ausnahmebereiche."

Zwei weitere Hinweise daraus sind für die Praxis wichtig: Die Anonymisierung ist selbst ein Verarbeitungsvorgang, der eine Rechtsgrundlage braucht. Und es gibt kein technisches Patentrezept, das eine sichere Anonymisierung garantiert.

Was das IT-Grundschutz-Kompendium verlangt

Auch das BSI regelt den Umgang mit Testdaten ausdrücklich. Im Baustein OPS.1.1.6 „Software-Tests und -Freigaben" legt die Anforderung A11 fest: Werden Produktivdaten mit schützenswerten Informationen für Tests verwendet, müssen sie angemessen geschützt werden. Enthalten sie personenbezogene Informationen, müssen sie mindestens pseudonymisiert und nach Möglichkeit vollständig anonymisiert werden. Lässt sich aus den Testdaten ein Personenbezug ableiten, sind der Datenschutzbeauftragte und unter Umständen die Personalvertretung hinzuzuziehen.

Der Hinweis auf die Personalvertretung verdient Aufmerksamkeit. Wer sie erst spät einbindet, riskiert Verzögerungen genau dann, wenn der Migrationszeitplan ohnehin eng ist.

Ebenso wichtig ist Anforderung A5 desselben Bausteins: Die durchgeführten Testfälle und die Testergebnisse müssen dokumentiert werden.

Die richtige Reihenfolge: erst ohne Echtdaten

Die BfDI beschreibt in ihrer Kurzposition eine Prüffolge, die sich als Leitlinie für jedes Testdatenkonzept eignet:

1. Künstliche Testdaten zuerst. Die Testfälle ergeben sich aus den Anforderungen an die Software. Dafür sind in der Regel keine Daten aus konkreten Fällen nötig. Grenzfälle wie ein Alter unter null oder über hundert Jahren, besonders lange oder ungewöhnliche Namen lassen sich ohnehin nur künstlich sinnvoll abbilden.
2. Anonymisierte Daten, wo künstliche nicht ausreichen. Etwa wenn realistische Verteilungen oder Mengen für Last- und Performancetests gebraucht werden.
3. Pseudonymisierte Echtdaten nur als letzter Schritt. Und nur, wenn alle anderen Möglichkeiten ausgeschöpft sind. Dann gelten die Vorgaben der DSGVO vollständig.

Ein einmal erstellter künstlicher Testdatenbestand lässt sich für weitere Tests wiederverwenden. Das spart bei jedem künftigen Release Aufwand und senkt das Risiko dauerhaft.

Worauf es bei der Beschaffung einer Nachfolgelösung ankommt

Wer eine Nachfolgelösung für TDMS beschafft, sollte die Anforderungen produktneutral und prüfbar formulieren. Die folgenden Punkte haben sich bewährt:

• Kompatibilität mit dem eingesetzten S/4HANA-Release und den geplanten Folgereleases
• Transparente Verfahren: Welche Daten werden anonymisiert, welche pseudonymisiert, und nach welchen Regeln
• Konsistenz über Tabellen und Systeme hinweg, damit verfremdete Daten fachlich stimmig bleiben und Tests aussagekräftig sind
• Wiederholbarkeit: Derselbe Datenstand muss für Regressionstests reproduzierbar sein
• Protokollierung: Welche Regeln wurden wann auf welchen Datenbestand angewendet
• Betrieb im eigenen Rechenzentrum und keine Übermittlung von Produktivdaten an Dritte
• Rollen- und Berechtigungskonzept für interne und externe Beteiligte

Der Teil, den man leicht übersieht: der Nachweis

Ein Werkzeug zur Maskierung erzeugt Testdaten. Den Nachweis, dass richtig getestet wurde, erzeugt es nicht. Genau danach fragen aber Datenschutzbeauftragte, Revision und Rechnungsprüfung.

Die DSGVO verpflichtet den Verantwortlichen nicht nur zur Einhaltung der Grundsätze, sondern ausdrücklich dazu, diese Einhaltung nachweisen zu können. Zusammen mit der Dokumentationspflicht aus dem IT-Grundschutz ergibt sich daraus eine Kette, die lückenlos sein muss:

• Welche Anforderung wurde mit welchem Testfall geprüft?
• Mit welchem Datenstand wurde der Test ausgeführt, und war dieser anonymisiert oder pseudonymisiert?
• Wer hat das Ergebnis geprüft und freigegeben, und wann?

Testdatenmanagement und Testmanagement gehören deshalb zusammen. Datengetriebene Testfälle, die Übergabe von Testdaten bei der Ausführung und revisionssicher protokollierte Freigaben mit Person, Zeitpunkt und Inhalt schließen genau diese Lücke. Wer das bei der Migration gleich mitdenkt, beantwortet die Nachweisfrage einmal richtig, statt sie bei jedem Release neu zu rekonstruieren.

Was Behörden jetzt tun sollten

1. Bestand erheben: Wo werden heute TDMS, Systemkopien oder manuelle Testdatenbestände genutzt?
2. Datenschutzbeauftragten und Personalvertretung früh einbinden, nicht erst kurz vor dem Testbeginn.
3. Ein Testdatenkonzept nach der Prüffolge der BfDI aufstellen: künstlich vor anonymisiert vor pseudonymisiert.
4. Anforderungen an eine Nachfolgelösung produktneutral festlegen, bevor der Markt gesichtet wird.
5. Die Nachweisführung von Beginn an mitplanen, damit sie nicht zum Engpass der Abnahme wird.

Die Umstellung auf S/4HANA ist für viele Häuser ohnehin ein mehrjähriges Vorhaben. Das Testdatenthema früh zu klären, kostet wenig und erspart später Rückfragen, die sich unter Zeitdruck schwer beantworten lassen.

Dieser Beitrag ordnet die Rechtslage ein und ersetzt keine Rechtsberatung. SAP, SAP S/4HANA und SAP TDMS sind Marken der SAP SE.