Der Fehler ist reproduzierbar, aber nur mit echten Daten. Ein Konto, eine bestimmte Buchungshistorie, ein Sonderfall, den niemand nachbauen kann. Der Entwickler fragt, ob er den Datensatz für zwei Tage in die Testumgebung ziehen darf.
Die Antwort lautet ja. Sie lautet aber nur dann ja, wenn vier Dinge gleichzeitig zutreffen, und die vierte kennen die wenigsten.
Dieser Artikel zeigt, was in einer Nichtproduktionsumgebung stehen darf, wo diese Regel tatsächlich geschrieben steht, warum die drei erlaubten Verfahren nicht dasselbe bedeuten und an welcher Stelle Ihr Testkonzept vom ISTQB-Glossar abweicht. Alle Zitate sind am veröffentlichten Rechtstext geprüft.
Inhaltsverzeichnis
- Was in der Nichtproduktionsumgebung stehen darf, und wo das wirklich geregelt ist
- Anonymisiert, pseudonymisiert, randomisiert: drei Verfahren ohne Rangfolge
- Die Ausnahme für Echtdaten und ihre vier Bedingungen
- Warum die Umgebung die Prüfgröße ist und nicht der Datensatz
- Wenn die Testumgebung beim Dienstleister steht
- Synthetische Testdaten: zulässig, aber nicht das genannte Mittel
- Für wen sich der Aufwand nicht lohnt
- Vier Irrtümer, die in Prüfungen auffallen
- Einwände, die wir im Gespräch hören
- Die ersten Schritte
- Fazit
- Häufige Fragen zu Testdaten und DORA
Was in der Nichtproduktionsumgebung stehen darf, und wo das wirklich geregelt ist
Fast jeder Beitrag zu diesem Thema beginnt mit dem Satz, DORA verlange anonymisierte Testdaten. Wir haben den Verordnungstext daraufhin geprüft, mit zwei voneinander unabhängigen Suchverfahren über alle 337.745 Zeichen.
| Begriff | Treffer in der Verordnung (EU) 2022/2554 |
|---|---|
| Testdaten | 0 |
| Testumgebung | 0 |
| Produktionsdaten | 0 |
| pseudonymisiert | 0 |
| anonymisiert | 4, sämtlich zu Vorfallsmeldung und Sanktionsveröffentlichung |
Zur Kontrolle: Die Zeichenfolge „test" kommt 133 mal vor, der Text war also vollständig geladen. DORA selbst sagt zu Testdaten nichts.
Die Regel steht in der Delegierten Verordnung (EU) 2024/1774, einem der zehn technischen Regulierungsstandards zu DORA, dort in Artikel 16 Absatz 5:
„in Nichtproduktionsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert werden"
Ergänzt um Buchstabe b, der in Übersichten meist fehlt: Finanzunternehmen müssen zusätzlich „die Integrität und Vertraulichkeit von Daten in Nichtproduktionsumgebungen schützen". Maskierte Daten sind also nicht automatisch unkritische Daten.
Die Fundstelle wird im Markt uneinheitlich zugeordnet. Wir haben drei verbreitete Beiträge geprüft: Einer schreibt die Regel DORA selbst zu und zitiert zusätzlich den Entwurf des Regulierungsstandards. Einer stellt ausdrücklich fest, DORA nehme auf Testdaten keinen Bezug. Einer nennt den Regulierungsstandard, ohne die Bedingungen aufzuzählen. Wer die Fundstelle sauber angibt, zitiert die veröffentlichte Fassung und nicht den Entwurf.
Anonymisiert, pseudonymisiert, randomisiert: drei Verfahren ohne Rangfolge
Der Text nennt drei Verfahren, verbunden mit „oder", ohne Reihenfolge und ohne Vorzug. Daraus lässt sich keine Pflicht zur Vollanonymisierung ableiten. Pseudonymisierung genügt dem Wortlaut, obwohl sie datenschutzrechtlich schwächer ist. Wer strenger vorgeht, tut das wegen der Datenschutz-Grundverordnung, nicht wegen dieses Artikels.
Das klingt nach einer Erleichterung und ist in Wahrheit die gefährlichste Stelle des ganzen Themas. Denn die drei Wörter bedeuten Unterschiedliches, und in Testkonzepten werden sie regelmäßig als Synonyme verwendet.
Wo Ihr Testkonzept und das ISTQB-Glossar auseinandergehen
Das ISTQB-Glossar definiert Anonymisierung so:
„Der irreversible Prozess, bei dem Daten entfernt oder so verändert werden, dass Personen nicht mehr identifiziert werden können."
Das Wort irreversibel ist der Kern. Ein Verfahren, das sich mit einem Schlüssel zurückdrehen lässt, ist nach dieser Definition keine Anonymisierung, sondern Pseudonymisierung. Und Datenmaskierung ist im Glossar ein noch schwächerer Begriff, dort als Übersetzung von data obfuscation geführt:
„Transformation von Daten, die es den Menschen schwer macht, die Originaldaten zu erkennen."
Erschwertes Erkennen ist etwas anderes als Nichtidentifizierbarkeit. Die Gegenüberstellung:
| Begriff | Kern der Definition | Umkehrbar | Im Regulierungsstandard genannt |
|---|---|---|---|
| Anonymisierung | irreversibel, Personen nicht mehr identifizierbar (ISTQB) | nein | ja |
| Pseudonymisierung | Zuordnung nur mit zusätzlicher Information möglich | ja, mit Schlüssel | ja |
| Randomisierung | Werte durch Zufallswerte ersetzt | nein | ja |
| Datenmaskierung | erschwert das Erkennen der Originaldaten (ISTQB) | je nach Verfahren | nein |
Die praktische Konsequenz: Wenn in Ihrem Testkonzept „anonymisierte Testdaten" steht und das Verfahren tatsächlich ein Schlüsseltausch mit hinterlegter Zuordnungstabelle ist, dann stimmt die Beschreibung nicht mit der Umsetzung überein. Regelkonform ist es trotzdem, denn Pseudonymisierung ist ausdrücklich erlaubt. Angreifbar ist nur die falsche Bezeichnung. Der Aufwand zur Behebung ist ein geänderter Satz im Konzept, der Schaden bei einer Prüfung deutlich größer.
„Datenmaskierung" als Sammelbegriff im Konzept zu führen, ist aus demselben Grund unglücklich. Der Rechtstext kennt den Begriff nicht. Wer maskiert, sollte im Konzept sagen, welches der drei genannten Verfahren dabei herauskommt.
Die Ausnahme für Echtdaten und ihre vier Bedingungen
Zurück zum Entwickler mit dem nicht nachbaubaren Fehler. Absatz 6 erlaubt echte Produktionsdaten:
„Abweichend von Absatz 5 kann das in Absatz 2 genannte Verfahren vorsehen, dass Produktionsdaten nur für bestimmte Testanlässe, für begrenzte Zeiträume und nach Genehmigung durch die betreffende Funktion sowie nach Meldung solcher Anlässe an die IKT-Risikomanagement-Funktion gespeichert werden."
Vier Bedingungen, und sie gelten kumulativ:
| # | Bedingung | Was das praktisch heißt |
|---|---|---|
| 1 | bestimmter Testanlass | Ein benannter Fall, keine Dauergenehmigung für „Fehleranalyse" |
| 2 | begrenzter Zeitraum | Ein Enddatum im Antrag und ein Löschvorgang, der stattfindet |
| 3 | Genehmigung durch die betreffende Funktion | Eine benannte Rolle, dokumentiert, nicht die Zustimmung per Zuruf |
| 4 | Meldung an die IKT-Risikomanagement-Funktion | Ein Meldeweg, der existiert und benutzt wird |
Die vierte Bedingung ist die, an der aus einer technischen Maßnahme ein nachweispflichtiger Prozess wird. Genehmigung und Meldung sind nicht dasselbe. Die Genehmigung entscheidet, die Meldung informiert eine zweite Stelle, die den Vorgang später aggregiert betrachten kann. Wer nur genehmigt, erfüllt drei von vier Bedingungen und damit keine.
Flankierend regelt Artikel 8 desselben Standards den umgekehrten Fall, nämlich Tests in der Produktionsumgebung. Solche Fälle sind „eindeutig zu identifizieren, zu begründen und zeitlich zu begrenzen" und von der betreffenden Funktion im Einklang mit Artikel 16 Absatz 6 zu genehmigen.
Warum die Umgebung die Prüfgröße ist und nicht der Datensatz
Die Regel greift an der Nichtproduktionsumgebung, nicht am einzelnen Datensatz. Das verschiebt die Prüffrage. Nicht: Sind diese Daten maskiert. Sondern: Welche Umgebungen existieren, welche davon gelten als Nichtproduktion, und wer hat dort Zugriff.
In der Praxis fällt das an denselben Stellen auf:
- Die vergessene Umgebung. Eine Schulungsumgebung, eine Demoinstanz für den Vertrieb, eine Sandbox für einen Dienstleister. Sie sind Nichtproduktion und fallen unter die Regel, tauchen aber in keiner Übersicht auf.
- Der lokale Auszug. Ein Datenabzug auf dem Rechner eines Entwicklers ist keine Umgebung im Sinne der Landschaftsdokumentation, praktisch aber genau das, was die Regel verhindern soll.
- Die Sicherung der Testumgebung. Sie erbt den Inhalt und wird bei der Maskierung regelmäßig übersehen.
- Protokolle und Fehlerberichte. Ein Stacktrace mit Nutzdaten transportiert Produktionsdaten in ein Ticketsystem, das niemand als Testumgebung führt.
Deshalb ist die erste sinnvolle Handlung kein Werkzeugvergleich, sondern eine vollständige Liste der Umgebungen mit einer Spalte für die Einstufung. Erst danach lohnt die Frage nach dem Verfahren.
Wenn die Testumgebung beim Dienstleister steht
Nicht jede Nichtproduktionsumgebung steht im eigenen Rechenzentrum. Sie wird betrieben, gehostet oder mit Daten befüllt von einem IKT-Drittdienstleister, und die Frage, wer für die Maskierung geradesteht, wird dann zur Vertragsfrage.
Die Pflicht wandert nicht mit dem Betrieb mit. Artikel 16 Absatz 5 richtet sich an das Finanzunternehmen. Wer den Betrieb vergibt, vergibt nicht die Verantwortung. Was sich verlagert, ist nur die Frage, wie man die Einhaltung überhaupt noch feststellen kann, und dafür hält DORA in Kapitel V eigene Vorgaben bereit.
Artikel 30 Absatz 2 Buchstabe b verlangt, dass der Vertrag festhält:
„die Standorte […], an denen die vertraglich vereinbarten oder an Unterauftragnehmer vergebenen Funktionen und IKT-Dienstleistungen bereitzustellen sind und an denen Daten verarbeitet werden sollen, einschließlich des Speicherorts, sowie die Auflage für den IKT-Drittdienstleister, das Finanzunternehmen vorab zu benachrichtigen, wenn er eine Änderung dieser Standorte beabsichtigt"
Für Testdaten ist das die entscheidende Klausel, und sie wird meist übersehen. Der Speicherort der Testumgebung gehört in den Vertrag, und eine Verlagerung ist vorab anzuzeigen. Wer eine Testinstanz im Rahmen einer Cloud-Migration in eine andere Region schiebt, löst damit eine Anzeigepflicht aus, nicht nur einen Betriebsvorgang. Buchstabe c ergänzt Bestimmungen über Vertraulichkeit „in Bezug auf den Datenschutz, einschließlich des Schutzes personenbezogener Daten".
Unterstützt die ausgelagerte Leistung eine kritische oder wichtige Funktion, kommt Artikel 30 Absatz 3 Buchstabe e Ziffer i hinzu. Er ist der eigentliche Hebel:
„uneingeschränkte Zugangs-, Inspektions- und Auditrechte des Finanzunternehmens oder eines beauftragten Dritten und der zuständigen Behörde sowie das Recht auf Anfertigung von Kopien einschlägiger Unterlagen vor Ort"
Zwei Wörter darin lohnen die Aufmerksamkeit. Uneingeschränkt heißt, dass eine Beschränkung im Kleingedruckten oder in einer Umsetzungsrichtlinie den Anspruch nicht aushöhlen darf. Und ein beauftragter Dritter heißt, dass Sie das Prüfungsrecht nicht selbst ausüben müssen. Wer im eigenen Haus niemanden hat, der ein Maskierungsverfahren fachlich beurteilen kann, darf jemanden damit beauftragen.
Daraus werden drei Fragen, die vor der Vertragsverlängerung auf den Tisch gehören:
- Steht der Speicherort der Nichtproduktionsumgebung im Vertrag, und ist die Anzeigepflicht bei Verlagerung vereinbart?
- Ist vereinbart, welches der drei Verfahren der Dienstleister anwendet, und wer den Lauf auslöst?
- Ist das Inspektionsrecht so formuliert, dass es die Testumgebung einschließt und dass ein beauftragter Dritter es ausüben darf?
Eine Abgrenzung, damit die Erwartung stimmt: Die Vertragsgestaltung selbst ist Sache Ihrer Rechtsabteilung und Ihres Auslagerungsmanagements. Was wir übernehmen können, ist die fachliche Seite der dritten Frage, also die Prüfung, ob das vereinbarte Verfahren im Betrieb tatsächlich das leistet, was im Vertrag steht.
Synthetische Testdaten: zulässig, aber nicht das genannte Mittel
Synthetische Testdaten kommen im Rechtstext nicht vor. Weder in DORA noch im Regulierungsstandard. Genannt sind ausschließlich abgeleitete Produktionsdaten, also anonymisiert, pseudonymisiert oder randomisiert.
Das heißt nicht, dass synthetische Daten unzulässig wären. Es heißt, dass niemand sie verlangt, und dass eine Argumentation, man erfülle die Regel durch Synthese, an der Formulierung vorbeigeht. Wer vollständig synthetisch arbeitet, hat schlicht keine Produktionsdaten in der Nichtproduktionsumgebung und damit den Anwendungsfall der Regel gar nicht.
Erzeugt ist nicht gleich erzeugt: die Trennlinie des BfDI
An dieser Stelle lohnt ein Blick über den Regulierungsstandard hinaus, denn die Datenschutzseite zieht eine Linie, die in der Diskussion über Testdaten fast immer fehlt. Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit hat im Mai 2025 eine Kurzposition zu personenbezogenen Daten bei Software-Entwicklung und Tests veröffentlicht. Dort heißt es zu vollsynthetischen Daten:
„Solche voll synthetischen Daten werden ohne jeden Personenbezug erzeugt, zum Beispiel nach bestimmten Regeln oder (statistischen) Mustern. Eine Ableitung aus (vorhandenen) personenbezogenen Daten findet nicht statt."
Genau an dieser Stelle steht eine Fußnote, und sie ist der entscheidende Satz für jeden, der über den Einsatz von KI-Modellen zur Datenerzeugung nachdenkt:
„Fälle in denen aus personenbezogenen Daten zum Beispiel mittels KI, KI-Training oder anderen Technologien Testdaten abgeleitet werden sollen, werden hier nicht behandelt."
Das trennt zwei Dinge, die im Alltag gern denselben Namen tragen. Wer Daten nach Regeln erzeugt, etwa gültige Kontonummern nach Prüfziffernverfahren und Beträge aus einer definierten Verteilung, arbeitet ohne jeden Personenbezug. Wer dagegen ein Modell auf dem Produktionsbestand trainiert und daraus Datensätze zieht, hat abgeleitete Daten erzeugt. Für den zweiten Fall trifft die Aufsicht in diesem Papier ausdrücklich keine Aussage.
Der praktische Schluss ist unbequem, aber klar: Ein modellerzeugter Bestand ist nicht automatisch aus dem Anwendungsbereich draußen. Entweder er ist erfolgreich anonymisiert, dann ist er von Absatz 5 gedeckt und die Anonymität ist nachzuweisen. Oder er ist es nicht, dann liegen personenbezogene Daten in der Nichtproduktionsumgebung. Ein dritter Weg lässt sich aus den Texten nicht ableiten.
Der BfDI benennt in derselben Kurzposition auch, worauf zu prüfen ist, und trifft damit den Kern des Problems:
„Der Prozess der Generierung und der erzeugte Testdatenbestand sind angemessen zu prüfen, insbesondere darauf, ob personenbezogene Daten (unbeabsichtigt) enthalten sind. Diese können zum Beispiel durch sogenanntes ‚Overfitting' eines Modells … in die Ergebnismenge gelangen."
Wer also mit modellerzeugten Testdaten arbeitet, tauscht eine Maskierungsaufgabe gegen eine Nachweisaufgabe. Das kann sich lohnen, aber es ist eine Verschiebung und keine Erledigung.
Die ehrliche Abwägung: Synthetische Daten lösen das Datenschutzproblem vollständig und das Testproblem nur teilweise. Sie enthalten die Sonderfälle nicht, die in gewachsenen Beständen stecken, und genau diese Sonderfälle finden Fehler. Deshalb ist die verbreitete Praxis eine Mischung, und deshalb existiert Absatz 6 überhaupt.
Für wen sich der Aufwand nicht lohnt
Sie arbeiten bereits vollständig synthetisch. Dann greift die Regel nicht, und ein Maskierungsprojekt löst ein Problem, das Sie nicht haben. Was bleibt, ist die Dokumentation dieses Umstands.
Ihre Umgebungslandschaft ist nicht erfasst. Dann ist das Werkzeug die falsche erste Investition. Ohne Liste der Umgebungen maskieren Sie das, was Sie kennen, und übersehen das, worauf es ankommt.
Sie sind Kleinstunternehmen im Sinne der Verordnung. Die Testpflichten aus Artikel 24 nehmen Sie ausdrücklich aus, und der Regulierungsstandard sieht einen vereinfachten Rahmen vor. Prüfen Sie zuerst, welcher Rahmen für Sie gilt.
Vier Irrtümer, die in Prüfungen auffallen
„DORA verlangt anonymisierte Testdaten"
Nicht im Verordnungstext, dort kommen die Begriffe Testdaten und Produktionsdaten kein einziges Mal vor. Die Regel steht im technischen Regulierungsstandard, der Delegierten Verordnung (EU) 2024/1774. Inhaltlich liegt die Aussage fast richtig, die Fundstelle ist falsch, und das fällt genau dann auf, wenn jemand nachschlägt.
„Wir müssen vollständig anonymisieren"
Der Text nennt drei gleichrangige Verfahren. Pseudonymisierung ist ausdrücklich erlaubt. Wer aus Vorsicht vollanonymisiert, verliert oft die referenzielle Integrität und damit die Testbarkeit ganzer Abläufe, ohne dass die Regel das verlangt hätte.
„Genehmigt ist gemeldet"
Absatz 6 nennt Genehmigung und Meldung als zwei getrennte Bedingungen. Eine Freigabe im Ticket ersetzt den Meldeweg an die Funktion für das IKT-Risikomanagement nicht.
„Maskiert ist unkritisch"
Absatz 5 Buchstabe b verlangt ausdrücklich den Schutz von Integrität und Vertraulichkeit in Nichtproduktionsumgebungen. Zugriffsrechte, Protokollierung und Aufbewahrung gelten dort weiter, auch für maskierte Bestände.
Einwände, die wir im Gespräch hören
„Ohne Echtdaten finden wir die Fehler nicht, um die es geht." Das stimmt für einen Teil der Fälle, und genau dafür existiert die Ausnahme. Der Unterschied zwischen zulässig und unzulässig ist nicht der Datenzugriff, sondern ob die vier Bedingungen dokumentiert erfüllt sind.
„Unser Maskierungswerkzeug ist zertifiziert, damit sind wir durch." Das Werkzeug erzeugt das Ergebnis, den Nachweis erzeugt der Prozess. Geprüft wird, welche Umgebungen einbezogen sind, wer den Lauf auslöst und was mit den Ausnahmefällen passiert.
„Das ist doch Datenschutz, nicht Testing." Beides. Die Datenschutz-Grundverordnung regelt die Zulässigkeit der Verarbeitung, der Regulierungsstandard regelt, was in einer Nichtproduktionsumgebung stehen darf. Die Umsetzung fällt in beiden Fällen im Testbetrieb an.
Die ersten Schritte
- Umgebungen listen und einstufen. Jede Umgebung mit einer Spalte Produktion oder Nichtproduktion. Schulung, Demo, Sandbox und Sicherungen ausdrücklich mit aufnehmen.
- Verfahren je Umgebung benennen. Für jede Nichtproduktionsumgebung eines der drei genannten Verfahren zuordnen, mit dem Wort, das der Rechtstext benutzt.
- Begriffe im Testkonzept angleichen. Prüfen, ob „anonymisiert" dort steht, wo tatsächlich pseudonymisiert wird. Ein Satz Aufwand, ein Prüfungsbefund weniger.
- Den Ausnahmeprozess aufsetzen. Antrag mit Anlass und Enddatum, benannte genehmigende Rolle, und ein Meldeweg an die Funktion für das IKT-Risikomanagement.
- Löschung nachweisbar machen. Ein Enddatum ohne belegten Löschvorgang ist keine zeitliche Begrenzung.
- Nebenwege prüfen. Protokolle, Fehlerberichte und lokale Auszüge auf Produktionsdaten durchsehen.
Fazit
Die Testdatenregel im DORA-Rahmen ist kürzer, als ihr Ruf vermuten lässt: zwei Absätze in Artikel 16 eines technischen Regulierungsstandards. Der Aufwand liegt nicht im Verstehen, sondern in zwei unscheinbaren Details. Die drei erlaubten Verfahren sind nicht dasselbe, und die Ausnahme hat vier Bedingungen statt drei.
Wer beides sauber im Testkonzept abbildet, hat die Prüfungsfrage vorweggenommen. Wer den vollständigen Rahmen sucht, findet ihn in unserem Beitrag zum Testen der digitalen operationalen Resilienz nach DORA. Die weiteren Anforderungen an Banken und Versicherer haben wir auf der Seite für Finanzdienstleister und Versicherer zusammengefasst, und wer Testdaten werkzeuggestützt bereitstellt, findet einen Praxisbericht unter Testdatenmanagement mit XDM.
Testdatenkonzept prüfen lassen
In einem Gespräch von 60 Minuten gleichen wir Ihr Testdatenkonzept gegen Artikel 16 ab und benennen die Stellen, an denen Bezeichnung und Umsetzung auseinandergehen. Ohne Vorbereitung Ihrerseits. Termin anfragen.
Häufige Fragen zu Testdaten und DORA
Verlangt DORA anonymisierte Testdaten?
Nicht im Verordnungstext selbst. In der Verordnung (EU) 2022/2554 kommen die Begriffe Testdaten, Testumgebung und Produktionsdaten kein einziges Mal vor. Die Regel steht in der Delegierten Verordnung (EU) 2024/1774, Artikel 16 Absatz 5: In Nichtproduktionsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert werden.
Reicht Pseudonymisierung für Testdaten nach DORA aus?
Ja. Artikel 16 Absatz 5 des Regulierungsstandards nennt anonymisiert, pseudonymisiert und randomisiert als gleichrangige Verfahren, verbunden mit „oder" und ohne Rangfolge. Eine Pflicht zur Vollanonymisierung lässt sich daraus nicht ableiten. Strengere Anforderungen können sich aus der Datenschutz-Grundverordnung ergeben.
Wann dürfen echte Produktionsdaten in der Testumgebung verwendet werden?
Nur wenn vier Bedingungen zugleich erfüllt sind: ein bestimmter Testanlass, ein begrenzter Zeitraum, die Genehmigung durch die betreffende Funktion und die Meldung des Anlasses an die IKT-Risikomanagement-Funktion. Die vierte Bedingung wird häufig mit der Genehmigung verwechselt, sie ist ein eigener Schritt.
Was ist der Unterschied zwischen Anonymisierung und Pseudonymisierung?
Anonymisierung ist nach ISTQB-Glossar ein irreversibler Prozess, bei dem Personen nicht mehr identifiziert werden können. Pseudonymisierung erlaubt die Zuordnung weiterhin, sofern zusätzliche Informationen vorliegen, etwa eine Zuordnungstabelle. Beide Verfahren sind im Regulierungsstandard zulässig, sie sind aber nicht dasselbe und sollten im Testkonzept nicht synonym verwendet werden.
Sind synthetische Testdaten nach DORA vorgeschrieben?
Nein. Synthetische Testdaten kommen weder in DORA noch im technischen Regulierungsstandard vor. Genannt sind ausschließlich abgeleitete Produktionsdaten. Synthetische Daten sind zulässig und oft sinnvoll, sie sind aber nicht das im Rechtstext benannte Mittel.
Gilt die Regel auch für Schulungs- und Demoumgebungen?
Ja. Die Regel knüpft an die Nichtproduktionsumgebung an, nicht an den Zweck der Umgebung. Schulungsumgebungen, Demoinstanzen, Sandkästen für Dienstleister und Sicherungen von Testumgebungen fallen darunter und werden in der Praxis am häufigsten übersehen.
Wer prüft die Einhaltung der Testdatenregel?
Zuständig ist die Aufsichtsbehörde, in Deutschland die BaFin. Geprüft wird nicht das Maskierungswerkzeug, sondern das Verfahren nach Artikel 16 Absatz 2: welche Umgebungen einbezogen sind, welches Verfahren je Umgebung gilt und wie die Ausnahmefälle genehmigt, gemeldet und beendet werden.