Testumgebung für den Shop: Änderungen sicher ausrollen

Wer im laufenden Shop eine Vorlage, eine Versandregel oder ein Update ändert, riskiert Bestellungen, die nicht mehr durchlaufen. Eine getrennt betriebene Kopie nimmt dieses Risiko auf, wenn im Test keine echte Bestellung entsteht.

Was Sie vorab brauchen

• eine Liste der anstehenden Änderungen und der betroffenen Wege: Warenkorb, Kasse, Zahlung, Rechnung, Versand
• eine Kopie von Anwendung, Datenbank, Dateien und Konfiguration, die nicht am Live-Shop hängt
• eigene Zugangsdaten für Datenbank, Anwendung und Schnittstellen
• eine Entscheidung, welche Datenfelder der Test braucht, und eine Anonymisierung, die Sie je Datenkopie erneut ausführen
• eine benannte Person für die Freigabe und einen Termin zum Löschen oder Zurücksetzen der Umgebung

Schritt für Schritt: Testumgebung aufsetzen

Schritt 1: Testziel und Testfälle festhalten

Notieren Sie vor dem Aufsetzen, was geprüft wird und wann der Test als bestanden gilt. Der BSI-Baustein OPS.1.1.6 Software-Tests und -Freigaben verlangt, dass die Rahmenbedingungen vorher festgelegt sind und die Testfälle möglichst repräsentativ alle Funktionen abdecken (OPS.1.1.6.A1, Basis-Anforderung). Gehört ein Fehlerfall dazu, etwa ein abgelaufener Gutschein, steht er als Testfall auf dem Blatt.

Der IT-Grundschutz ist ein Standard des BSI und kein Gesetz; er bindet, soweit Gesetz, Aufsicht oder Vertrag auf ihn verweisen (redaktionelle Einordnung). OPS.1.1.6 gilt für Software-Tests jeder Art, also auch für Änderungen an einem Standard-Shopsystem; CON.8 gilt für Entwicklungsvorhaben.

Schritt 2: Eigene Kopie aufsetzen und Zugriff beschränken

Ziehen Sie Anwendung, Datenbank, Dateien und Konfiguration als Kopie in eine eigene Umgebung. Für Entwicklungsvorhaben verlangt der Baustein CON.8 Software-Entwicklung, dass Software getrennt von der Produktionsumgebung getestet wird (CON.8.A7, Basis-Anforderung); OPS.1.1.6.A13 (Standard-Anforderung) sieht einen getrennten Betrieb der Testumgebung vor, ohne eine bestimmte Kopier- oder Installationsarchitektur vorzuschreiben. Richten sich beide Adressen auf dieselbe Installation und arbeiten sie auf denselben produktiven Daten, derselben Konfiguration und Zahlungsanbindung, dann ist das kein getrennter Betrieb.

Vergeben Sie eigene Konten, beschränken Sie den Zugriff auf die testenden Personen und setzen Sie einen Passwortschutz vor die Oberfläche. In Deutschland und Österreich verlangt Art. 32 Abs. 1 DSGVO dem Risiko angemessene Massnahmen; in der Schweiz verlangt Art. 3 Abs. 1 Buchst. a DSV, dass Berechtigte nur auf die für ihre Aufgabe nötigen Personendaten zugreifen. Ein Schweizer Shop kann nach Art. 3 Abs. 2 DSGVO zusätzlich erfasst sein, wenn er Personen in der Union Waren anbietet. Wie Sie Rechte zuteilen, steht in Zugriffe und Rechte im Shop.

Schritt 3: Aussenwirkungen abtrennen

Prüfen Sie jedes System, das aus dem Shop heraus etwas auslöst, und stellen Sie es im Test um:

• Zahlungsdienst: getrennte Sandbox-Zugangsdaten; ohne sie bleibt die Zahlung ungebunden
• E-Mail: Zustellung auf ein Testpostfach umleiten, keine Nachricht an eine Kundenadresse
• Warenwirtschaft und Lager: Testmandant oder Lesekopie, damit Bestände nicht sinken
• Versand und Etiketten: Testzugang des Versanddienstes, keine Abholaufträge
• Buchhaltung: getrennter Rechnungsnummernkreis
• Webanalyse: im Test abschalten
• Passwörter: Testkonten mit neuen Zugangsdaten anlegen

Schritt 4: Daten kopieren und anonymisieren

Arbeiten Sie mit einer Kopie der Datenbank, nicht mit der Produktivdatenbank selbst. OPS.1.1.6 nennt als Gefährdung, dass Tests mit den Originaldaten diese ungewollt verändern oder löschen und dass Unbefugte vertrauliche Daten einsehen. Enthalten die Testdaten personenbezogene Informationen, verlangt OPS.1.1.6.A11 als Grundschutzanforderung mindestens eine Pseudonymisierung und möglichst eine Anonymisierung. Diese Anforderung ersetzt die Rechtsgrundlage nicht: Für echte Kundendaten brauchen Sie in Deutschland und Österreich zusätzlich eine Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO. Ist die Verwendung im Test ein anderer Zweck als der, für den die Daten erhoben wurden, und beruht sie nicht auf der Einwilligung der betroffenen Person oder auf einer Rechtsvorschrift der Union oder der Mitgliedstaaten, die in einer demokratischen Gesellschaft eine notwendige und verhältnismässige Massnahme zum Schutz der in Art. 23 Abs. 1 DSGVO genannten Ziele darstellt, verlangt Art. 6 Abs. 4 DSGVO eine Prüfung der Vereinbarkeit mit dem ursprünglichen Zweck; in der Schweiz gilt daneben Art. 6 Abs. 1 bis 3 DSG (rechtmässige, verhältnismässige und zweckgebundene Bearbeitung). Feld für Feld steht das im nächsten Abschnitt.

Schritt 5: Durchspielen und dokumentieren

Führen Sie die Testfälle so durch, dass der Live-Shop unberührt bleibt (OPS.1.1.6.A2, Basis-Anforderung). Nach einer Änderung an einer bestehenden Komponente sieht OPS.1.1.6.A12 Regressionstests vor: Prüfen Sie danach, ob Versandberechnung, Rabattregeln und Rechnungsstellung unverändert arbeiten. Auswertung und Testergebnisse müssen dokumentiert werden (OPS.1.1.6.A3 und A5). Welche Bestellfälle sich lohnen, beschreibt Testbestellungen vor dem Start.

Schritt 6: Freigeben, ausrollen, zurückrollen

Lassen Sie die Änderung von der fachlich zuständigen Stelle freigeben und halten Sie die Freigabe in einer Freigabeerklärung fest (OPS.1.1.6.A4). Für den Ausrollvorgang muss nach OPS.1.1.3.A1 eine Rückfall-Lösung vorhanden sein; Änderungen müssen geplant, genehmigt und dokumentiert werden. Den Ablauf mit Backup, Migration und Rollback beschreibt Updates und Wartung des Shopsystems.

Schritt 7: Umgebung nach dem Test behandeln

OPS.1.1.6.A13 sieht ein dokumentiertes Verfahren dafür vor, was nach dem Test mit der Umgebung geschieht. Legen Sie fest, ob sie gelöscht oder auf einen festen Stand zurückgesetzt wird. Enthalten die Testdaten Personendaten, gilt die Speicherbegrenzung: In Deutschland und Österreich dürfen sie nach Art. 5 Abs. 1 Buchst. e DSGVO nur so lange identifizierbar bleiben, wie die Zwecke es erfordern; in der Schweiz sind sie nach Art. 6 Abs. 4 DSG zu vernichten oder zu anonymisieren.

Testdaten anonymisieren

Ob ein Datensatz personenbezogen ist, entscheidet über die Regeln. Pseudonymisierte Daten bleiben personenbezogen, solange sich die Zuordnung zu einer Person mit vertretbarem Aufwand herstellen lässt (Art. 4 Nr. 5 DSGVO, Erwägungsgrund 26); die bloss getrennte Aufbewahrung der Zuordnungstabelle macht sie nicht anonym. Erst wenn eine Identifizierung nach allgemeinem Ermessen nicht mehr wahrscheinlich ist, greifen die Datenschutzgrundsätze nicht mehr (Erwägungsgrund 26 der Verordnung); synthetische Datensätze ohne Bezug zu einer realen Person sind dann keine personenbezogenen Daten. Ob ein erfundener Datensatz diese Schwelle erreicht, ist Teil der Prüfung und keine Zusage. Die Tabelle zeigt eine Aufteilung für einen Shop mit Kundenkonten (Beispiel):

Datenfeld	Ins Testsystem?	Vorgehen im Beispiel
Vor- und Nachname	nur ersetzt	erfundene Namen einsetzen
E-Mail-Adresse	nur ersetzt	auf eine Domäne umschreiben, die Ihnen gehört (Beispiel: kunde-1042@test.example)
Anschrift und Telefonnummer	nur ersetzt	erfundene Anschriften, Telefonnummer leer lassen
Bestell- und Rechnungsnummer	nur geprüft	beibehalten, wenn Format und Nummernkreis geprüft werden und die Nummer allein keinen Kundenbezug herstellt
Bestellpositionen, Mengen, Beträge	nur geprüft	übernehmen, wenn sich die Angaben nicht über Name, Kennung, Bestellnummer oder Anschrift einer Person zuordnen lassen
Zahlungsdaten und Kartennummern	nein	nicht kopieren; im Test die Sandbox des Zahlungsdienstes nutzen
Passwort-Hashes und Sitzungen	nein	Testkonten mit neuen Zugangsdaten anlegen
Freitext: Bestellnotiz, Reklamation, Chat	nur geprüft	nach Namen, Anschrift, Telefonnummer und Kennungen durchsuchen
Rechnungs-PDFs und E-Mail-Anhänge	nein	im Test neu erzeugen statt kopieren

So laufen die Anonymisierungsschritte ab:

1. Felder inventarisieren: alle Tabellen, Dateien und Anhänge auflisten, in denen Personendaten stehen können.
2. Zweck prüfen: für jedes Feld entscheiden, ob der Test es braucht; was er nicht braucht, wird nicht übernommen (Art. 5 Abs. 1 Buchst. c DSGVO; in der Schweiz Art. 6 Abs. 2 DSG). Auch die Voreinstellung soll auf das nötige Mindestmass beschränken (Art. 25 Abs. 2 DSGVO; Art. 7 Abs. 3 DSG).
3. Ersetzen statt löschen, wo das Format geprüft wird: Bestellnummern und Datumsangaben bleiben, Personenangaben werden durch erfundene Werte ersetzt; bei den Bestelldaten prüfen Sie, ob die Angaben ohne die ersetzten Personenfelder noch einer Person zugeordnet werden können.
4. Zuordnung trennen: Pseudonymisierte Daten bleiben personenbezogen, auch wenn die Zuordnungstabelle gesondert aufbewahrt wird (Art. 4 Nr. 5 DSGVO). Legen Sie diese Tabelle ausserhalb des Testsystems ab und schützen Sie sie; eine Anonymisierung erreichen Sie damit nicht.
5. Vollständig anonymisieren, wo es geht: Für anonyme Informationen gelten die Datenschutzgrundsätze nicht (Erwägungsgrund 26); prüfen Sie je Tabelle, ob eine Identifizierung mit vertretbarem Aufwand noch möglich ist (Art. 25 Abs. 1 DSGVO).
6. Freitext und Anhänge nachziehen: Notizen, Chats und gescannte Belege enthalten Angaben, die kein Ersetzungsschema erfasst; durchsuchen Sie sie nach E-Mail-Adressen, Telefonnummern und Bankverbindungen.
7. Protokolle, Sicherungen, Stichprobe: Auch Protokolle und Sicherungen enthalten die Testdaten und gehören in das Löschkonzept; ziehen Sie am Ende Stichproben über Tabellen und Felder.
8. Nachfragen: Wenn von den Testdaten ein Personenbezug abgeleitet werden könnte, sind nach OPS.1.1.6.A11 der Datenschutzbeauftragte und gegebenenfalls die Personalvertretung hinzuzuziehen.

Checkliste: Umgebung einrichten

• Eine Kopie von Anwendung, Datenbank, Dateien und Konfiguration liegt in einer eigenen Umgebung.
• Die Umgebung hat eine eigene Adresse mit Passwortschutz und ist nicht öffentlich erreichbar.
• Datenbank und Schnittstellen haben eigene Zugangsdaten und Schlüssel.
• Zahlungsdienst und E-Mail-Versand sind getrennt: Sandbox-Zugangsdaten, Testpostfach.
• Warenwirtschaft, Versand, Buchhaltung und Webanalyse laufen im Testmodus oder sind abgeschaltet.
• Testfälle mit Fehlerfällen sind aufgeschrieben, Freigabe und Rückfall sind geregelt.
• Alle Felder mit möglichem Personenbezug sind inventarisiert, Namen und Kontaktdaten ersetzt.
• Für echte Kundendaten sind in Deutschland und Österreich die Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO und, soweit die Testnutzung ein anderer Zweck ist und nicht auf Einwilligung oder einer Rechtsvorschrift beruht, die in einer demokratischen Gesellschaft eine notwendige und verhältnismässige Massnahme zum Schutz der in Art. 23 Abs. 1 DSGVO genannten Ziele darstellt, die Vereinbarkeit nach Art. 6 Abs. 4 DSGVO geprüft und dokumentiert.
• Termin und Verantwortliche für Löschen oder Zurücksetzen sind festgelegt.

So prüfen Sie das Ergebnis

1. Der Live-Shop hat sich nicht verändert: keine neue Bestellung, kein gesunkener Bestand.
2. Aus dem Test ist keine Nachricht an eine Kundenadresse und keine Zahlung über einen echten Zahlungsweg gelaufen.
3. Die Testfälle aus Schritt 1 sind vollständig durchlaufen und dokumentiert.
4. Kein Testkonto trägt noch ein produktives Passwort.
5. Der Rückweg ist vorbereitet: Backup erstellt, Zurückspielen geübt, siehe Backup und Wiederherstellung.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Eine Testbestellung erscheint in der echten Warenwirtschaft	Schnittstelle zeigt noch auf den Produktionsendpunkt	Endpunkt prüfen, Testbestellung stornieren, Bestand abgleichen
Eine Kundin oder ein Kunde erhält eine Testnachricht	Mailversand ist nicht umgeleitet	Versand umleiten; prüfen, ob der Vorgang zu melden ist (Datenpanne im Onlineshop)
Im Testsystem stehen noch echte Namen	Ersetzung war unvollständig, etwa in Freitext oder Anhängen	Suchmuster erweitern, Testsystem neu aufsetzen
Die Umgebung ist von aussen erreichbar	Zugriffsschutz fehlt oder ist zu weit gefasst	Zugriff auf die testenden Personen beschränken

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn Sie keine getrennt betriebene Umgebung bereitstellen können oder personenbezogene Testdaten nicht zuverlässig anonymisieren. Läuft die Testumgebung bei einer Agentur oder einem Hoster und werden dort personenbezogene Daten verarbeitet, ist das eine Verarbeitung im Auftrag: In Deutschland und Österreich braucht sie einen Vertrag nach Art. 28 Abs. 3 DSGVO, in der Schweiz eine Regelung nach Art. 9 DSG. Klären Sie vor dem ersten Test, wer fachlich freigibt (OPS.1.1.6.A4).