Sicherheit, Datenschutz und Compliance

Sicherheit, Datenschutz und Compliance

0:00 Shopify stellt Werkzeuge bereit. Verantwortlich für die Verarbeitung bleibt, wer den Shop betreibt — und das steht so in der Dokumentation, in bemerkenswert klaren Worten. In diesem Modul geht es deshalb weniger um Einstellungen als um Rollen, Prozesse und Nachweise. Wir klären die Rollenverteilung zwischen Händler, Plattform und Apps, sehen uns Einwilligung und Tracking an, gehen eine Löschanfrage bis zum Ende durch — und sprechen über den Notfall, für den es in Shopify weniger Rückwege gibt als anderswo.

Sicherheit, Datenschutz und Compliance

0:29 Vier Kapitel. Zuerst Rollen und Rechtsgrundlagen, also die Frage, wer Verantwortlicher ist und wer Auftragsverarbeiter. Dann Einwilligung und Tracking mit der Customer Privacy API als zentraler Schnittstelle. Danach Kundendaten und Zugriffe, inklusive einer Löschanfrage, die bis zur letzten App durchgespielt wird. Und zum Schluss Notfall und Nachweis.

0:50 In der Übung führen Sie für Steglicht die Analyse durch, die nach einer Kundenanfrage tatsächlich nötig wäre — mit sechs Apps und sieben Beteiligten.

Rollen und Rechtsgrundlagen

0:59 Beginnen wir mit den Rollen. Sie klingen nach Juristerei und entscheiden im Ernstfall darüber, wer erklären muss. Shopify beschreibt die Rollenverteilung eindeutig: Der Händler ist in der Regel der Verantwortliche für die Daten seiner Kundschaft und entscheidet, wie sie behandelt werden. Handelt Shopify als Auftragsverarbeiter, folgt es den Weisungen des Händlers. Das ist die klassische Konstruktion der Datenschutz-Grundverordnung, und sie ist hier sauber benannt.

1:27 Die praktische Konsequenz: Wer entscheidet, verantwortet. Und entscheiden tun Sie — über Zwecke, über Apps, über Aufbewahrung. Die Plattform führt aus, was Sie konfiguriert haben. Vier Aussagen, die man kennen sollte. Shopify bietet Werkzeuge und Informationen zur Prüfung der eigenen Praxis — also Hilfsmittel, keine Garantie.

1:47 Die Nutzung dieser Dienste allein garantiert keine Konformität mit der Datenschutz-Grundverordnung; das steht so da, und es ist eine ehrliche Aussage. Die eigenen Pflichten zu verstehen, bleibt Sache des Händlers. Und bei bestimmten Zusatzdiensten kann Shopify selbst als Verantwortlicher handeln — die Rollenverteilung ist also nicht in Stein gemeißelt, sondern hängt daran, was Sie aktiviert haben.

2:10 Vier Ebenen. Der Händler als Verantwortlicher, der über Zwecke und Mittel entscheidet. Shopify in der Regel als Auftragsverarbeiter nach Weisung. Die Apps, die entweder in eigenem Auftrag oder für den Händler verarbeiten — und genau diese Unterscheidung ist in der Praxis oft unklar. Und die Kundschaft als betroffene Person mit Rechten auf Auskunft und Löschung.

2:32 Das Bild hilft bei einer sehr konkreten Frage: Wenn eine Anfrage kommt, auf welcher Ebene muss etwas passieren? Die Antwort lautet fast immer: auf allen. Der erste Punkt ist der häufigste formale Fehler: Die Rollenverteilung wird angenommen statt vertraglich geklärt. Sie ergibt sich nicht von selbst, sie wird vereinbart.

2:51 Der zweite ist die konkrete Lücke daraus: Für Apps mit Kundendatenzugriff fehlt eine Auftragsverarbeitung — und diese Apps kennen wir aus Modul achtzehn samt ihrer Zugriffsstufen. Der dritte ist eine bequeme Fehlannahme: Verantwortlichkeit wird auf die Plattform geschoben. Und der vierte ist die praktische Folge: Das Verzeichnis der Verarbeitungstätigkeiten kennt die Apps nicht.

Einwilligung und Tracking

3:14 Weiter mit der Einwilligung. Und mit einer technischen Regel, die entscheidet, ob sie überhaupt wirkt. Die Datenschutzeinstellungen legen je Land und Region fest, wie mit Einwilligung umgegangen wird. Bei einem neuen Shop sind automatische Einstellungen aktiv: Der Cookie-Banner wird für Besuche aus Großbritannien und dem Europäischen Wirtschaftsraum eingerichtet — sofern dort Märkte aktiv sind.

3:37 Dieser Nachsatz ist wichtig und verbindet dieses Modul mit Modul vierzehn: Wer einen neuen Markt eröffnet, verändert damit auch, wo der Banner erscheint. Das gehört auf die Rollout-Liste einer Markteröffnung. Vier Punkte, und sie beschreiben eine klare Architektur. Der Shopify-Banner gibt die Einwilligung automatisch an die Customer Privacy API weiter.

3:58 Shopify-Cookies direkt zu lesen oder zu verändern, ist ausdrücklich nicht vorgesehen — die API ist der Weg, nicht das Cookie. Ein fremdes Banner muss die Einwilligung über dieselbe API melden. Und ohne diese Meldung wirkt die Entscheidung der Kundschaft nur optisch: Das Banner verschwindet, die Pixel feuern weiter. Das ist der Fehler, den man von außen nicht sieht und der rechtlich am meisten wiegt.

4:23 Drei Wege mit drei Bedingungen. Der Shopify-Cookie-Banner: Regionen prüfen, der Standard deckt Europäischen Wirtschaftsraum und Großbritannien. Eine App eines Drittanbieters: Sie muss über die Customer Privacy API melden — fragen Sie das vor der Installation, nicht danach. Eine eigene Lösung: dieselbe Meldepflicht, zusätzlicher Pflegeaufwand.

4:44 Und die Fußzeile zieht eine wichtige Grenze: Der Shopify-Banner deckt Shopify-eigene Werkzeuge ab, darunter Cookies und Shopify Pixels. Was andere Anbieter mitbringen, deckt er nicht automatisch mit ab. Der erste Punkt ist sichtbar und trotzdem häufig: Zwei Banner sind aktiv, und die Kundschaft entscheidet zweimal. Das wirkt unprofessionell und ist rechtlich unklar.

5:07 Der zweite ist der unsichtbare Fehler aus dem letzten Abschnitt: Das fremde Banner meldet nicht an die API, und die Pixel feuern trotzdem. Der dritte ist ein Wartungsproblem: Die Regionen bleiben auf dem Standard, obwohl neue Märkte dazugekommen sind. Und der vierte ist eine begriffliche Verwechslung mit praktischen Folgen: Marketing-Einwilligung und Cookie-Einwilligung sind zwei verschiedene Dinge.

Kundendaten und Zugriffe

5:30 Jetzt die Rechte der Kundschaft. Und die Frage, wie weit eine Löschung tatsächlich reicht. Shopify stellt Werkzeuge bereit, mit denen sich Kundendaten einsehen, bearbeiten und löschen lassen — damit die Rechte auf Auskunft, Berichtigung und Löschung erfüllt werden können. Die Werkzeuge sind also da. Der Vorgang selbst bleibt aber ein Prozess im Haus, mit Frist und Verantwortlichen.

5:53 Das ist der Unterschied zwischen technischer Möglichkeit und organisatorischer Erfüllung. Eine Löschanfrage ist kein Knopf, sondern eine Abfolge von Prüfungen — und die letzte davon führt aus dem Shop heraus. Fünf Schritte. Prüfen Sie zuerst die Identität der anfragenden Person — sonst löschen Sie auf Zuruf. Prüfen Sie dann, welche Daten aufbewahrungspflichtig sind und bleiben müssen; Rechnungen etwa verschwinden nicht auf Wunsch. Bearbeiten oder löschen Sie die Daten im Shop.

6:22 Gehen Sie dann die Apps durch, die dieselben Daten verarbeitet haben — und genau hier braucht es das App-Inventar aus Modul achtzehn. Und dokumentieren Sie Vorgang, Umfang und Datum. Ohne App-Inventar ist Schritt vier schlicht nicht vollständig durchführbar. Vier Verbindungen zu früheren Modulen. Jedes Mitarbeiterkonto sieht so viele Kundendaten, wie seine Rolle zulässt — das Rollenkonzept aus Modul zwei ist damit auch ein Datenschutzinstrument.

6:49 Apps greifen je nach Stufe auf Namen, Adresse, Telefon und Mail zu, wie in Modul achtzehn gesehen. Zwei-Faktor-Authentifizierung schützt den Zugang zu genau diesen Daten. Und ein ausgeschiedenes Konto ist eine offene Tür zu personenbezogenen Daten. Datenschutz ist hier also kein separates Thema — er ist die Summe der Entscheidungen aus vier anderen Modulen.

7:11 Der erste Punkt ist der, der Löschanfragen unvollständig lässt: Die Löschung im Shop erfolgt, die App behält ihre Kopie. Der zweite ist die Gegenrichtung und ebenso falsch: Aufbewahrungspflichten werden übersehen, und Belege verschwinden, die bleiben müssten. Beides sind Fehler, und man muss beide Seiten prüfen. Der dritte ist ein Dauerthema: Berechtigungen bleiben nach Rollenwechseln unverändert — jemand wechselt die Abteilung und behält die alten Rechte dazu.

7:38 Und der vierte ist ein Nachweisproblem: Die Bearbeitung der Anfrage wird nicht dokumentiert.

Notfall und Nachweis

7:44 Zum Abschluss der Ernstfall. Und die Erinnerung an eine Eigenschaft der Plattform aus Modul zwei. Ein Notfallplan beschreibt, wer was tut, wenn etwas schiefgeht: unberechtigter Zugriff, fehlerhafte Massenänderung, ausgefallene Schnittstelle, kompromittiertes Konto. Vier Szenarien, die alle vorkommen. Der Plan ist schriftlich, kurz und bekannt — sonst ist er nicht vorhanden.

8:07 Besonders das Wort bekannt verdient Aufmerksamkeit: Ein Plan, den nur die Person kennt, die ihn geschrieben hat, hilft genau dann nicht, wenn diese Person nicht erreichbar ist. Und das ist erfahrungsgemäß der Normalfall im Ernstfall. Vier Einschränkungen, die man vorher kennen muss. Konfigurationsänderungen wirken sofort und tragen keine Versionshistorie — das war die zentrale Erkenntnis aus Modul zwei.

8:31 Ein veröffentlichtes Theme lässt sich nur zurückholen, wenn das alte noch existiert; deshalb löscht man es nicht. Massenänderungen über Bulk Editor oder Import lassen sich nicht pauschal rückgängig machen. Und daraus folgt der einzige verlässliche Rückweg: die vorherige Dokumentation des Zustands. Das ist unbequem und es ist die Wahrheit über diese Plattform.

8:53 Vier Zeilen mit Takt und Verantwortung — und genau diese beiden Spalten machen den Unterschied. Mitarbeiterkonten und Rollen: vierteljährlich, durch die Shopverantwortung. Installierte Apps und ihre Zugriffsstufen: ebenfalls vierteljährlich. Die Datenschutzeinstellungen je Region: immer dann, wenn ein neuer Markt dazukommt — das ist ereignisgesteuert, nicht terminiert.

9:16 Und der Notfallplan samt Erreichbarkeiten: halbjährlich, durch die Geschäftsführung. Vier Termine im Jahr, die zusammen vielleicht zwei Stunden kosten. Das ist der gesamte Aufwand. Der erste Punkt hat etwas Tragikomisches und passiert wirklich: Der Notfallplan liegt in einem Dokument, das nur im Shop erreichbar ist — und der Shop ist gerade das Problem.

9:38 Der zweite ist das übliche Schicksal wiederkehrender Termine: Prüfungen werden terminiert und jedes Quartal verschoben. Der dritte ist ein Nachweisproblem: Nach einem Vorfall wird behoben, aber nichts dokumentiert — und beim nächsten Mal beginnt die Analyse von vorn. Und der vierte ist der, der im Ernstfall Zeit kostet: Niemand hat festgelegt, wer entscheiden darf.

Übung

9:59 Jetzt kommt eine Anfrage — und Sie stellen fest, wie viele Stellen Sie dafür kennen müssen. Bei Steglicht arbeiten sieben Parteien im Shop, sechs Apps sind installiert, zwei Märkte sind aktiv. Und jetzt fordert eine Kundin Auskunft und Löschung ihrer Daten. Niemand weiß auf Anhieb, welche App welche Daten sieht. Das ist eine realistische Ausgangslage und sie ist unangenehm — genau deshalb ist sie die Übung.

10:23 Denn die Frist läuft ab dem Eingang der Anfrage, nicht ab dem Zeitpunkt, an dem Sie herausgefunden haben, wo überall Daten liegen. Das Lernziel: Datenflüsse und Zugriffe im Shop vollständig erfassen und die Lücke zwischen Löschung im Shop und Löschung insgesamt erkennen. Diese Lücke ist der Kern. Erfolgreich sind Sie, wenn für alle sechs Apps Zugriffsstufe, Zweck und Datenverbleib erfasst sind, die Berechtigungen der sieben Parteien geprüft wurden und die Löschanfrage bis zum letzten verarbeitenden System durchgespielt ist.

10:54 Bis zum letzten — nicht bis zum Shop. Wer früh fertig ist, ergänzt den Prüftakt je Gegenstand, also die Tabelle aus Kapitel vier. Listen Sie zuerst die Datenarten auf, die im Shop entstehen — Bestelldaten, Kontaktdaten, Zahlungsdaten, Verhaltensdaten. Erfassen Sie je App Zugriffsstufe, Zweck und Vereinbarung. Prüfen Sie die Berechtigungen der sieben Parteien gegen ihre tatsächlichen Aufgaben. Spielen Sie dann die Löschanfrage Schritt für Schritt durch.

11:20 Und benennen Sie die Lücken mit Verantwortlichen und Terminen. Der vierte Schritt ist der, der die Arbeit der ersten drei prüft — wenn Sie irgendwo ins Stocken geraten, fehlt dort eine Information. Der erste Punkt ist der Umfangsfehler, vor dem dieses Modul warnt: Die Analyse endet im Shop, und die Apps bleiben unbetrachtet.

11:40 Der zweite ist ein Denkfehler: Aufbewahrungspflichten werden gegen die Löschung ausgespielt statt geprüft — es ist kein Entweder-oder, sondern eine Abgrenzung je Datenart. Der dritte ist Bequemlichkeit an heikler Stelle: Die Zugriffsstufe der Apps wird geschätzt statt nachgesehen. Und der vierte macht die ganze Analyse folgenlos: Am Ende stehen Lücken, aber keine Termine. Eine Lücke ohne Termin ist eine Notiz.