Du testest mit echten Kundendaten. Und das ist eine tickende Zeitbombe.

Letzte Woche hat mir ein Geschäftsführer aus Korschenbroich stolz seine neue Auftragsmanagement-Software gezeigt. Alles sah gut aus. Dann habe ich gefragt, woher die Daten im Testsystem kommen. Seine Antwort: Das sind unsere echten Kundendaten, dann sehen wir direkt, ob alles passt.

Er war nicht der Erste, der mir das sagt. Tatsächlich erlebe ich das bei fast jedem zweiten KMU, das ich berate. Die Produktionsdatenbank wird einfach kopiert und ins Testsystem geschoben. Oder noch schlimmer: Es wird direkt in der echten Datenbank getestet. Weil es schneller geht. Weil niemand Testdaten anlegen will. Weil es ja intern ist.

Das Problem ist: Es ist nicht intern. Es ist ein echtes Risiko. Für deine Kunden, für dein Unternehmen und im schlimmsten Fall für deine persönliche Haftung als Geschäftsführer. Und die meisten merken es erst, wenn etwas passiert.

Warum alle echte Daten zum Testen nutzen

Die Gründe sind immer die gleichen. Echte Daten sind einfach da. Niemand muss sie erfinden, generieren oder pflegen. Du kopierst die Datenbank, startest das Testsystem und hast sofort realistische Inhalte. Das fühlt sich effizient an.

Dazu kommt: Testdaten zu erstellen ist Arbeit. Du brauchst plausible Namen, Adressen, Bestellhistorien, Rechnungsnummern. Das kostet Zeit. Und wenn der Chef sagt, die neue Funktion muss bis Freitag stehen, dann fällt die Erstellung von Testdaten als Erstes weg. Man nimmt halt die echten.

Außerdem gibt es ein psychologisches Argument. Entwickler und Tester wollen mit realistischen Daten arbeiten. Wenn im Testsystem nur Max Mustermann und Test GmbH stehen, fühlt sich das nicht echt an. Man vertraut den Ergebnissen weniger. Also greift man zu dem, was echt ist. Und genau da fängt das Problem an.

Was passiert, wenn Testdaten echte Kundendaten sind

Stell dir vor, ein Praktikant testet eine neue Funktion in eurem System. Er löst versehentlich einen Massenversand aus. 3.000 Kunden bekommen eine Test-E-Mail mit dem Betreff Hallo das ist ein Test 123. Klingt lustig. Ist es nicht. Genau das ist einem Unternehmen in Düsseldorf passiert, und der Imageschaden war erheblich.

Oder ein anderes Szenario: Dein Entwickler exportiert die Testdatenbank auf seinen Laptop, um abends zuhause weiterzuarbeiten. Der Laptop wird gestohlen. Auf der Festplatte liegen Namen, Adressen, Telefonnummern, vielleicht sogar Bankverbindungen von echten Kunden. Das ist ein meldepflichtiger Datenschutzvorfall nach DSGVO.

Das sind keine theoretischen Horrorszenarien. Das passiert regelmäßig. Der Unterschied ist nur: Große Unternehmen haben Krisenteams und PR-Abteilungen. Wenn dir als Fünf-Mann-Betrieb so etwas passiert, kann das existenzbedrohend sein. Bußgelder, Vertrauensverlust, Kunden die abspringen. Und das alles, weil niemand sich die Mühe gemacht hat, Testdaten zu erstellen.

Die DSGVO kennt kein Aber wir testen doch nur

Viele Unternehmer denken, die Datenschutzgrundverordnung gilt nur für den Produktivbetrieb. Also für Newsletter, Onlineshops und Kundendatenbanken, die im echten Betrieb laufen. Das ist falsch. Die DSGVO gilt für jede Verarbeitung personenbezogener Daten. Und eine Kopie in ein Testsystem ist eine Verarbeitung.

Artikel 5 der DSGVO verlangt Zweckbindung. Deine Kunden haben dir ihre Daten gegeben, damit du Aufträge abwickelst oder Rechnungen schreibst. Nicht, damit ein Praktikant damit testet, ob der CSV-Export funktioniert. Es gibt keinen stillschweigend mitgemeinten Testzweck.

Im Ernstfall musst du als Geschäftsführer nachweisen können, dass du technische und organisatorische Maßnahmen getroffen hast, um Daten zu schützen. Wenn dann rauskommt, dass echte Kundendaten unverschlüsselt in einer Testumgebung lagen, auf die fünf Leute ohne besondere Zugangskontrolle Zugriff hatten, dann wird es teuer. Bußgelder können bis zu 20 Millionen Euro oder 4 Prozent des Jahresumsatzes betragen. Für KMUs sind die Strafen natürlich niedriger, aber selbst 10.000 oder 50.000 Euro tun richtig weh.

Was gute Testdaten ausmacht

Gute Testdaten sind realistisch, aber nicht echt. Sie sehen aus wie echte Kundendaten. Sie haben plausible Namen, echte Postleitzahlen, sinnvolle Bestellmengen. Aber sie gehören keiner realen Person. Niemand wird benachteiligt, wenn sie geleakt werden.

Ein guter Testdatensatz deckt außerdem Sonderfälle ab. Kunden mit Doppelnamen. Adressen mit Sonderzeichen. Bestellungen mit Negativbeträgen. Genau die Fälle, die in echten Daten selten vorkommen, aber im Betrieb Fehler auslösen. Echte Daten sind in dieser Hinsicht sogar schlechter als gute Testdaten, weil sie diese Randfälle nicht systematisch abdecken.

Außerdem sollten Testdaten reproduzierbar sein. Das heißt: Du kannst sie jederzeit in den Ausgangszustand zurücksetzen. Wenn ein Test die Daten verändert, setzt du sie einfach zurück. Mit echten Daten geht das nicht so einfach, weil du nie sicher bist, ob du nicht versehentlich den Produktivbestand verändert hast.

Wie du ohne großen Aufwand Testdaten erstellst

Es gibt mehrere Wege, und keiner davon ist so aufwendig, wie die meisten denken. Der einfachste: Du nimmst deine echten Daten und anonymisierst sie. Das bedeutet, du ersetzt alle personenbezogenen Felder durch zufällige Werte. Aus Hans Müller, Poststraße 5, Neuss wird Peter Schneider, Bergweg 12, Musterstadt. Die Struktur bleibt gleich, aber der Personenbezug ist weg.

Es gibt kostenlose Tools, die genau das machen. Faker ist eine Bibliothek, die es für fast jede Programmiersprache gibt. Sie generiert realistische Namen, Adressen, E-Mails, Telefonnummern, IBAN-Nummern und vieles mehr. Dein Entwickler braucht dafür vielleicht zwei bis drei Stunden, um ein Skript zu schreiben, das eure Testdatenbank befüllt.

Eine andere Möglichkeit: Du legst Testdaten manuell an, aber einmal richtig. Mit einem klaren Plan. Zehn Privatkunden, zehn Geschäftskunden, fünf mit Sonderstatus, fünf mit offenen Reklamationen. Wenn du das einmal sauber machst, hast du einen Goldstandard, den du über Jahre nutzen kannst. Und dein Team testet endlich unter kontrollierten Bedingungen.

Anonymisierung ist nicht gleich Anonymisierung

Ein häufiger Fehler: Unternehmen ersetzen den Namen, lassen aber die E-Mail-Adresse stehen. Oder sie ändern die Adresse, aber die Kundennummer ist immer noch die echte. Damit lässt sich der Datensatz im Zweifelsfall zurückverfolgen. Das ist dann Pseudonymisierung, nicht Anonymisierung. Und Pseudonymisierung unterliegt weiterhin der DSGVO.

Richtige Anonymisierung bedeutet: Es gibt keinen Weg zurück zur echten Person. Kein Feld, keine Kombination von Feldern darf eine Identifikation ermöglichen. Wenn dein Testkunde in PLZ 41460 wohnt, 1987 geboren ist und drei Bestellungen über Spezialmaschinen hat, ist er vielleicht trotzdem identifizierbar. Auch ohne Namen.

Deshalb empfehle ich in der Praxis meistens, komplett synthetische Daten zu generieren statt echte Daten zu anonymisieren. Das ist sauberer, sicherer und in den meisten Fällen genauso schnell. Du brauchst keine aufwendige Anonymisierungspipeline. Du brauchst ein Skript, das dir frische Daten erzeugt. Das kann sogar ein KI-Tool übernehmen, wenn du ihm sagst, wie deine Datenstruktur aussieht.

Testdaten als Teil deiner Unternehmenskultur

Das eigentliche Problem ist nicht technisch. Es ist organisatorisch. In den meisten KMUs gibt es keine Regel, die besagt: Echte Kundendaten haben in Testsystemen nichts zu suchen. Es gibt keine Richtlinie, kein kurzes Dokument, keinen Satz im Onboarding-Handbuch. Also macht jeder, was am schnellsten geht.

Ich empfehle jedem Unternehmen, mit dem ich arbeite, eine einfache Regel aufzuschreiben: Keine Echtdaten in Testumgebungen. Punkt. Das muss nicht lang sein. Ein halber Absatz reicht. Aber es muss existieren und kommuniziert werden. Jeder Entwickler, jeder Dienstleister, jeder neue Mitarbeiter muss das wissen.

Wenn du das mit einem ordentlichen Testdaten-Skript kombinierst, hast du in einem Nachmittag das Problem gelöst. Für immer. Du reduzierst dein Haftungsrisiko, du schützt deine Kunden und du schaffst eine professionelle Arbeitsumgebung. Das klingt nach viel. Aber es ist ein Nachmittag Arbeit, der dir Jahre an Ärger erspart.

Was du morgen früh tun kannst

Erstens: Frag dein Team oder deinen IT-Dienstleister, ob irgendwo echte Kundendaten zum Testen genutzt werden. Die Antwort wird dich wahrscheinlich überraschen. Nicht böse gemeint, das ist in fast jedem Unternehmen so, das ich bisher beraten habe. Von Neuss bis Köln, von Handwerksbetrieb bis Onlinehändler.

Zweitens: Lass dir zeigen, welche Systeme betroffen sind. Testserver, Entwickler-Laptops, lokale Datenbanken. Oft gibt es mehr Kopien als gedacht. Jeder Entwickler hat vielleicht seinen eigenen Abzug der Produktivdatenbank. Das sind potenzielle Datenlecks, die auf Festplatten schlummern.

Drittens: Beauftrage jemanden, ein Testdaten-Skript zu erstellen. Das kann dein interner Entwickler sein oder ein Freelancer. Der Aufwand liegt typischerweise bei vier bis acht Stunden, je nach Komplexität deiner Datenstruktur. Danach hast du saubere Testdaten auf Knopfdruck. Und du schläfst nachts besser.