Vereinbarung zur Auftragsverarbeitung (AVV)

Präambel

Diese Vereinbarung regelt die Verarbeitung personenbezogener Daten durch den Auftragsverarbeiter im Auftrag des Verantwortlichen im Rahmen der Nutzung der Shopify-Anwendung Etchify.

Verantwortlicher ist der Betreiber des Shopify-Shops („Merchant"), der Etchify installiert.

Auftragsverarbeiter ist:

Zustandekommen

Diese Vereinbarung kommt mit der Installation der Anwendung im Shopify-Shop zustande. Der Merchant erkennt sie im Installationsvorgang an. Eine individuelle Aushandlung findet nicht statt — die Anwendung wird standardisiert über den Shopify App Store bereitgestellt. Wer abweichende Regelungen benötigt, wendet sich vor der Installation an legal@etchify.app.

Diese Vereinbarung geht den Allgemeinen Geschäftsbedingungen vor, soweit sie die Verarbeitung personenbezogener Daten betrifft.

§ 1 Gegenstand, Art und Zweck der Verarbeitung

Gegenstand ist die Bereitstellung eines Produkt-Konfigurators für Gravur- und Druckprodukte innerhalb des Shopify-Shops des Verantwortlichen.

Zweck der Verarbeitung ist ausschließlich die Erbringung dieser Leistung:

• Konfiguration von Produkten (Gravurflächen, Materialien, Formen, Preisaufschläge)
• Speicherung und Auslieferung der vom Endkunden erstellten Gestaltungen
• Übermittlung der Konfiguration an die Bestellung im Shop des Verantwortlichen
• Bereitstellung der Verwaltungsoberfläche für den Verantwortlichen
• Support auf Anfrage des Verantwortlichen

Ausgeschlossen ist jede Nutzung der Daten zu eigenen Zwecken des Auftragsverarbeiters, insbesondere zur Profilbildung, zur Weitergabe an Dritte zu Werbezwecken oder zum Training von KI-Modellen.

Dauer: Die Verarbeitung erfolgt für die Laufzeit der Installation. Sie endet mit der Deinstallation der Anwendung; die Folgen regelt § 9.

§ 2 Art der Daten und Kategorien betroffener Personen

Kategorien betroffener Personen

• Endkunden des Verantwortlichen, die den Konfigurator nutzen oder bestellen
• Mitarbeitende des Verantwortlichen, die die Verwaltungsoberfläche bedienen

Kategorien personenbezogener Daten

Zahlungsdaten werden nicht verarbeitet. Die Abrechnung läuft über Shopify Billing; der Auftragsverarbeiter erhält keine Karten- oder Kontodaten.

§ 3 Weisungsbindung

Der Auftragsverarbeiter verarbeitet personenbezogene Daten ausschließlich auf dokumentierte Weisung des Verantwortlichen. Als Weisung gelten diese Vereinbarung sowie die Konfiguration und Bedienung der Anwendung durch den Verantwortlichen.

Einzelweisungen sind in Textform an legal@etchify.app zu richten.

Hält der Auftragsverarbeiter eine Weisung für rechtswidrig, teilt er dies mit und darf ihre Ausführung aussetzen, bis der Verantwortliche sie bestätigt oder ändert.

Eine Verarbeitung aufgrund einer Rechtspflicht der Union oder eines Mitgliedstaats bleibt zulässig; der Auftragsverarbeiter informiert den Verantwortlichen vorher, sofern das Recht dies nicht verbietet.

§ 4 Vertraulichkeit

Der Auftragsverarbeiter setzt zur Verarbeitung nur Personen ein, die zur Vertraulichkeit verpflichtet sind oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen. Die Verpflichtung besteht über das Ende der Tätigkeit hinaus.

Transparenzhinweis: Der Auftragsverarbeiter ist ein Einzelunternehmen. Zugriff auf Produktivdaten hat ausschließlich der Inhaber. Weitere Personen werden nicht eingesetzt; sollte sich das ändern, gilt Satz 1.

§ 5 Technische und organisatorische Maßnahmen (Art. 32)

Der Auftragsverarbeiter trifft die in der Anlage 2 (TOM) beschriebenen Maßnahmen und hält sie während der Vertragslaufzeit aufrecht.

Die Maßnahmen dürfen fortentwickelt werden, solange das Schutzniveau nicht unterschritten wird. Wesentliche Änderungen werden dokumentiert.

Die Anlage benennt ausdrücklich auch offene Punkte. Der Verantwortliche kann seine Risikoabwägung damit auf einer vollständigen Grundlage treffen.

§ 6 Unterauftragsverarbeiter (Art. 28 Abs. 2 und 4)

Der Verantwortliche erteilt die allgemeine Genehmigung zur Beauftragung der in Anlage 1 genannten Unterauftragsverarbeiter.

Vor Hinzunahme oder Austausch eines Unterauftragsverarbeiters informiert der Auftragsverarbeiter den Verantwortlichen mit einer Frist von 30 Tagen in Textform. Der Verantwortliche kann innerhalb dieser Frist aus wichtigem datenschutzrechtlichem Grund widersprechen. Kann die Änderung dann nicht unterbleiben, ist der Verantwortliche berechtigt, die Nutzung zu beenden.

Der Auftragsverarbeiter verpflichtet jeden Unterauftragsverarbeiter auf ein Schutzniveau, das dieser Vereinbarung entspricht.

§ 7 Betroffenenrechte

Der Auftragsverarbeiter unterstützt den Verantwortlichen mit geeigneten Maßnahmen dabei, Anträge betroffener Personen (Art. 15–22 DSGVO) zu erfüllen.

Wendet sich eine betroffene Person unmittelbar an den Auftragsverarbeiter, leitet er den Antrag unverzüglich an den Verantwortlichen weiter und beantwortet ihn nicht selbst.

Auskunft, Berichtigung, Löschung und Einschränkung sind über die Verwaltungsoberfläche der Anwendung möglich. Ist ein Anliegen darüber nicht abbildbar, unterstützt der Auftragsverarbeiter auf Anfrage.

§ 8 Meldepflichten und Unterstützung (Art. 32–36)

Der Auftragsverarbeiter meldet dem Verantwortlichen unverzüglich, spätestens innerhalb von 24 Stunden ab Kenntnis, jede Verletzung des Schutzes personenbezogener Daten.

Die kurze Frist ist bewusst gewählt: Die Meldefrist des Verantwortlichen gegenüber der Aufsichtsbehörde (72 Stunden, Art. 33 Abs. 1) beginnt mit dieser Meldung.

Die Meldung enthält, soweit bekannt: Art des Vorfalls, betroffene Datenkategorien und ungefähre Zahl betroffener Personen, Zeitpunkt von Eintritt und Entdeckung, wahrscheinliche Folgen sowie ergriffene und geplante Maßnahmen. Eine unvollständige erste Meldung ist zulässig und wird nachgeführt.

Der Auftragsverarbeiter meldet nicht selbst an die Aufsichtsbehörde — das ist Sache des Verantwortlichen.

Auf Anfrage unterstützt der Auftragsverarbeiter bei Datenschutz-Folgenabschätzungen (Art. 35) und vorherigen Konsultationen (Art. 36), soweit die erforderlichen Informationen seiner Sphäre entstammen.

Der interne Ablauf ist in Anlage 3 (Incident-Response-Plan) beschrieben.

§ 9 Löschung und Rückgabe nach Vertragsende

Nach Deinstallation der Anwendung:

Der Verantwortliche kann innerhalb der 30 Tage die sofortige Löschung verlangen (legal@etchify.app) oder einen Export seiner Daten anfordern; der Export erfolgt in einem gängigen, maschinenlesbaren Format.

Gesetzliche Aufbewahrungspflichten bleiben unberührt. Solche Daten werden gesperrt und nicht weiter verarbeitet.

§ 10 Nachweise und Überprüfung

Der Auftragsverarbeiter stellt dem Verantwortlichen auf Anfrage die Informationen zur Verfügung, die zum Nachweis der Einhaltung von Art. 28 erforderlich sind — insbesondere diese Vereinbarung samt Anlagen sowie die aktuelle Fassung der TOM.

Überprüfungen erfolgen vorrangig durch Vorlage dieser Nachweise. Eine Prüfung vor Ort ist mit angemessener Vorankündigung, während der üblichen Geschäftszeiten und ohne unangemessene Betriebsstörung möglich; sie kann durch einen zur Verschwiegenheit verpflichteten Prüfer erfolgen.

Der Auftragsverarbeiter weist darauf hin, dass er keine Zertifizierung (etwa ISO 27001) besitzt und keine behauptet.

§ 11 Ort der Verarbeitung und Drittlandtransfer

Die Verarbeitung erfolgt in der Europäischen Union, soweit nicht in Anlage 1 anders angegeben.

Für die dort genannten Unterauftragsverarbeiter mit Sitz außerhalb der EU besteht eine Transfergrundlage nach Kapitel V DSGVO (EU-US Data Privacy Framework beziehungsweise Standardvertragsklauseln). Die konkrete Grundlage ist je Anbieter in Anlage 1 dokumentiert.

§ 12 Haftung und Schlussbestimmungen

Es gilt Art. 82 DSGVO. Im Übrigen richtet sich die Haftung nach den Allgemeinen Geschäftsbedingungen; eine Beschränkung gilt nicht für Vorsatz und grobe Fahrlässigkeit sowie nicht für Ansprüche betroffener Personen.

Es gilt das Recht der Bundesrepublik Deutschland.

Änderungen bedürfen der Textform. Ist eine Bestimmung unwirksam, bleibt die Vereinbarung im Übrigen wirksam; an die Stelle der unwirksamen Bestimmung tritt die gesetzliche Regelung.

Bei Widersprüchen zwischen dieser Vereinbarung und den AGB geht diese Vereinbarung vor, soweit die Verarbeitung personenbezogener Daten betroffen ist.

Anlagen

Die Anlagen sind Bestandteil dieser Vereinbarung.

Änderungshistorie

Anlage 1 — Genehmigte Unterauftragsverarbeiter (Art. 28 Abs. 4 DSGVO)

Stand: 1. August 2026

Die jeweils aktuelle Fassung der Liste ist unter Aktuelle Sub-Prozessor-Liste abrufbar; die Hinzunahme oder der Austausch eines Unterauftragsverarbeiters wird nach § 6 dieser Vereinbarung mit einer Frist von 30 Tagen in Textform angekündigt.

1. Aktive Unterauftragsverarbeiter (verarbeiten Merchant-/Endkunden-Personendaten)

2. Nicht als externer Unterauftragsverarbeiter geführt (mit Begründung)

2a. Zur Doppelrolle von Shopify

Shopify ist in dieser Konstellation nicht ausschließlich Unterauftragsverarbeiter. Für die Daten, die der Merchant ohnehin in seinem Shop verarbeitet, ist Shopify sein Auftragsverarbeiter — dort besteht bereits ein Vertragsverhältnis zwischen Merchant und Shopify, unabhängig von Etchify.

Etchify listet Shopify hier auf, weil die App aktiv Daten an Shopify zurückschreibt (Metafelder, Produkt-/Variantenkonfiguration) und die Partner-API nutzt. Diese Richtung ist eine Weitergabe durch Etchify und damit anzugeben.

Praktische Folge: Ein Merchant, der Shopify als Unterauftragsverarbeiter „ablehnen" wollte, könnte die App ohnehin nicht nutzen — die Plattform ist Voraussetzung, nicht Wahlmöglichkeit. Das ist in der AVV klarzustellen, damit die Widerspruchs-Regelung nach Art. 28 Abs. 2 nicht ins Leere läuft.

3. Drittland-Transfers (Art. 44 ff. DSGVO)

Supabase, Vercel, Shopify und Resend haben ihren Sitz außerhalb der EU (überwiegend USA).

• Supabase: Die Datenbank selbst liegt gemessen in eu-north-1 (AWS Stockholm). Der Transfer ergibt sich aus dem Anbietersitz und möglichen Support-Zugriffen, nicht aus dem Speicherort.
• Vercel: Edge-Auslieferung global; statische Frontend-Inhalte, dazu Verbindungsdaten der Besucher.
• Resend: Versand nach eigener Angabe über AWS SES in einer EU-Region; Anbietersitz US.
• Shopify: Vertragspartner in der Regel Shopify International Ltd. (Irland), Konzern CA/US.

Transfergrundlage je Anbieter: EU-US Data Privacy Framework (Zertifizierung pro Anbieter prüfen und dokumentieren) bzw. Standardvertragsklauseln + Transfer Impact Assessment. Die konkrete Grundlage gehört pro Anbieter ins Sub-Prozessor-Register — eine pauschale Nennung genügt nicht.

4. Offene Punkte

1. DPA-Nachweise einsammeln: Für Supabase, Vercel, Resend und Shopify je das aktuelle DPA (bzw. die DPF-Zertifizierung) ablegen. Ohne die Belege ist die Anlage eine Behauptung.
2. Upload-Speicherort präzisieren: Design-Uploads liegen im Backend-Dateisystem (shopforge-prod-vps, EU). Falls perspektivisch ein Objektspeicher dazukommt, gehört er hier hinein.
3. PII-Minimierung im Error-Tracking bestätigen (Abschnitt 2), damit die Self-hosted-Einordnung trägt.

5. Änderungs- und Informationspflicht

Ein neuer oder gewechselter Unterauftragsverarbeiter erfordert die vorherige Information der Merchants samt Widerspruchsrecht (Art. 28 Abs. 2). Das Register wird zentral geführt; neu hinzukommende externe Dienste werden automatisiert erkannt, die Anlage wird dann nachgezogen.

Anlage 2 — Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Stand: 1. August 2026

Anlage zur AVV zwischen dem Merchant (Verantwortlicher) und Etchify — Einzelunternehmen Valerian Huber (Auftragsverarbeiter).

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b)

1.1 Zutrittskontrolle (physisch)

Keine eigene Hardware. Verarbeitung ausschließlich in Rechenzentren der Auftragnehmer (Hostinger eu-de, AWS eu-north-1 über Supabase, Vercel Edge). Physische Sicherheit obliegt vertraglich diesen Anbietern; Nachweise über deren Zertifizierungen (ISO 27001 o. ä.).

1.2 Zugangskontrolle (System)

• Serverzugang ausschließlich über SSH mit Schlüsselpaar; Passwort-Anmeldung und Root-Login sind deaktiviert — laufend überwacht durch den Wächter host-hardening (Achsen host-ssh-password-auth, host-ssh-root-login).
• Offene Netzwerk-Ports werden fortlaufend erfasst; unerwartete Exposition erzeugt einen Alarm (host-exposed-port).
• Betriebssystem-Sicherheitsupdates werden überwacht (host-security-updates).
• Zugriff auf die Administrationsoberflächen der Auftragnehmer über personengebundene Konten mit Zwei-Faktor-Authentisierung.

1.3 Zugriffskontrolle (Daten)

• Mandantentrennung ist der zentrale Schutz: Jeder Shop ist ein eigener Mandant; die Datenbank erzwingt die Trennung über Row-Level-Security-Richtlinien (Supabase/PostgreSQL). Deren Wirksamkeit prüft der Wächter supabase-advisors laufend gegen die Live-Datenbank.
• Der Anwendungszugriff erfolgt über Shopify-Session-Token (JWT); die Identität des Shops wird serverseitig aufgelöst, nicht aus Client-Angaben übernommen.
• Die maschinelle Schnittstelle (/api/v1/*, auch für den KI-Zugang) arbeitet mit API-Schlüsseln je Shop und agiert ausschließlich im Kontext dieses einen Mandanten.
• Datenbank-Rollen nach Zweck getrennt: die Laufzeitrolle besitzt keine DDL-Rechte; die Sicherungsrolle (alpin_backup) ist eine reine Leserolle ohne Superuser- und ohne Schreibrechte.

1.4 Trennungskontrolle

• Produktiv- und Entwicklungsumgebungen sind auf getrennter Infrastruktur (shopforge-prod-vps gegenüber alpin-dev-vps).
• Test- und Demonstrationsdaten sind in der Anwendung als solche gekennzeichnet und werden von Umsatz-/Betriebskennzahlen getrennt geführt.

1.5 Pseudonymisierung / Datenminimierung

• Für Missbrauchsabwehr werden IP-Adressen gehasht statt im Klartext gespeichert (ip_hash in den Protokolldaten).
• Es werden keine Zahlungsdaten verarbeitet — die Abrechnung läuft über Shopify Billing; Etchify erhält keine Karten- oder Kontodaten.

2. Integrität (Art. 32 Abs. 1 lit. b)

2.1 Weitergabekontrolle

• Transportverschlüsselung TLS für alle Verbindungen; HSTS ist aktiv (max-age=63072000, gemessen 2026-08-01).
• Sicherheits-Kopfzeilen am Auslieferungspunkt: X-Frame-Options: DENY, Content-Security-Policy, X-Content-Type-Options: nosniff.
• Zugangsdaten liegen niemals im Quellcode. Sie werden verschlüsselt verwahrt (sops/age-Depot) und über einen kontrollierten Übergabeweg ausgerollt; ein Wächter meldet Zugangsdaten mit unzureichenden Dateirechten (host-hardening, Achse Secret-Dateien).

2.2 Eingabekontrolle

• Datenbank-Änderungen erfolgen über versionierte Migrationen (fortlaufend nummeriert, 225 Dateien, Stand 2026-08-01) — jede Schemaänderung ist nachvollziehbar.
• Änderungen an der Anwendung laufen über Versionskontrolle mit vollständiger Historie.
• Schreibende Zugriffe der KI-Schnittstelle werden nicht unmittelbar wirksam: Sie werden als Vorschlag gespeichert (pending_ai_mutations) und benötigen die ausdrückliche Bestätigung des Shop-Inhabers in der Oberfläche.

2.3 Missbrauchsabwehr

• Rate-Limiting auf den Authentisierungs- und Schnittstellenpfaden (Flask-Limiter), wobei die Begrenzung bewusst vor der Authentisierung greift, damit auch unauthentisierte Anfragefluten begrenzt sind.
• Vorgeschalteter Angriffsschutz am Netzwerkrand für die selbst gehosteten Komponenten (CrowdSec); die Frontends liegen hinter der Schutzinfrastruktur des Hosting-Anbieters.
• Datei-Uploads werden auf Typ und Größe geprüft; auf mindestens einem Pfad erfolgt eine inhaltsbasierte Prüfung (Magic-Byte-Validierung, Entfernung eingebetteter Metadaten). → Vereinheitlichung offen, siehe Abschnitt 6.

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c)

• Tägliche Datensicherung der Datenbank als eigenständiger, vom Anbieter unabhängiger logischer Auszug; zusätzlich die anbieterseitigen Sicherungen.
• Auslagerung auf ein zweites System (getrennter Host), Aufbewahrung 14 Tage.
• Wöchentlicher Wiederherstellungstest: Die Sicherung wird in eine Wegwerf-Datenbank eingespielt und die Anzahl wiederhergestellter Tabellen und Datensätze gezählt. Ein Test, der die Mindestwerte unterschreitet, gilt als fehlgeschlagen und erzeugt einen Alarm. (Nachweis 2026-08-01: 81 Tabellen, 7.369 Datensätze wiederhergestellt.)
• Überwachung rund um die Uhr: Erreichbarkeitsprüfung im 5-Minuten-Takt (2.029 Prüfungen in sieben Tagen, davon 2.029 erfolgreich). Ausfälle erzeugen Alarm.
• Fehlererfassung über eine selbst betriebene Instanz (kein externer Empfänger).
• Totmann-Prinzip bei den Sicherungen: Bleibt die Bestätigung eines Sicherungslaufs aus, schlägt der Wächter an — ein ausgefallener Sicherungsjob fällt nicht durch Schweigen auf.

4. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d)

• Abhängigkeitsprüfung aller Programmbibliotheken (täglich, mit Bewertung nach tatsächlicher Produktionsrelevanz statt nach Rohzahl).
• Konfigurationsprüfung der Datenbank auf Richtlinien- und Freigabefehler (supabase-advisors).
• Unabhängige Prüfinstanz: Die Anwendung wird durch eine vom Entwicklungsteam getrennte Instanz (Betreiber-Cockpit) gegen einen Katalog von Freigabekriterien geprüft; sicherheits- und datenschutzrelevante Kriterien sind als sperrend gekennzeichnet.
• Befristung von Nachweisen: Prüfergebnisse tragen ein Ablaufdatum und müssen erneuert werden. Ein Nachweis ohne Verfall gilt als Mangel.

5. Auftragskontrolle

• Unterauftragsverarbeiter sind abschließend in der Anlage 1 (Unterauftragsverarbeiter) benannt.
• Das Register wird zentral geführt; ein Wächter erkennt neu hinzukommende externe Dienste, sodass die Anlage nicht unbemerkt veraltet.

6. Offen benannte Lücken (Stand 2026-08-01)

Diese Punkte sind nicht erfüllt und werden bewusst offengelegt:

1. Kein externer Penetrationstest. Begründung: Verhältnismäßigkeit vor Markteintritt. Ersatzweise laufende maschinelle Prüfungen (Abschnitt 4). Wiedervorlage: mit dem ersten echten Umsatz.
2. Upload-Prüfung uneinheitlich. Die inhaltsbasierte Prüfung existiert an einem Pfad; die übrigen prüfen Dateiendung und Größe. Vereinheitlichung ist beauftragt.
3. Keine formale Zertifizierung (ISO 27001, TISAX o. ä.) — weder angestrebt noch behauptet.
4. Löschkonzept ist über die Anbieter- und Sicherungsfristen definiert, aber nicht als eigenes Dokument ausformuliert.
5. E-Mail-Authentisierung ist vollständig eingerichtet (SPF, DKIM, DMARC), die DMARC-Richtlinie steht jedoch auf p=none (Beobachtungsmodus) und damit noch nicht durchsetzend.

7. Änderungshistorie

Anlage 3 — Incident-Response-Plan

Stand: 1. August 2026

Betriebsdokument für den Umgang mit Sicherheitsvorfällen und Verletzungen des Schutzes personenbezogener Daten (Art. 33, 34 DSGVO).

1. Die wichtigste Rollenklarstellung

Etchify ist gegenüber den Merchants Auftragsverarbeiter, nicht Verantwortlicher.

Daraus folgt für den Ernstfall:

Der häufigste Fehler wäre, selbst an die Aufsichtsbehörde zu melden. Das ist nicht unsere Rolle und würde die Zuständigkeiten verwischen. Unsere Pflicht ist die unverzügliche Meldung an den Merchant — ohne die schuldhafte Verzögerung, die seine 72-Stunden-Frist auffrisst.

Betrifft ein Vorfall ausschließlich Daten des eigenen Unternehmens (etwa Zugangsdaten des Betreibers), ist Etchify selbst Verantwortlicher und meldet gegebenenfalls selbst.

2. Was ein meldepflichtiger Vorfall ist

Eine Verletzung liegt vor bei Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten. Konkret für diese Anwendung:

Im Zweifel gilt: melden. Eine überflüssige Meldung an den Merchant kostet Vertrauen nicht — eine unterlassene schon.

3. Ablauf

Stufe 1 — Erkennen (automatisiert)

Die Anzeichen kommen in der Regel nicht von Menschen, sondern von Wächtern:

Zusätzlich: Meldungen von Merchants an support@etchify.app und Hinweise von Shopify.

Stufe 2 — Bewerten (Ziel: 1 Stunde)

Vier Fragen, in dieser Reihenfolge:

1. Sind personenbezogene Daten betroffen? Wenn nein → normale Fehlerbehandlung, hier endet der Plan.
2. Welche Mandanten? Einer, mehrere, alle? Der Merchant muss wissen, ob er betroffen ist.
3. Welche Datenkategorien und wie viele Betroffene ungefähr?
4. Dauert es noch an? Ein laufender Abfluss wird zuerst gestoppt, dann dokumentiert.

Ab dem ersten Moment mitschreiben — Uhrzeit, Beobachtung, Maßnahme. Nicht aus Formalismus: Der Merchant braucht diese Zeitleiste für seine eigene Meldung, und niemand rekonstruiert sie später fehlerfrei aus dem Gedächtnis.

Stufe 3 — Eindämmen

Nach Lage, typischerweise in dieser Reihenfolge:

1. Betroffene Zugangsdaten rotieren (Schlüssel, Token, Datenbank-Zugänge).
2. Betroffenen Pfad abschalten, wenn der Abfluss sonst weiterläuft — eine vorübergehend nicht verfügbare Funktion ist besser als ein fortdauernder Datenabfluss.
3. Beweise sichern, bevor aufgeräumt wird: Protokolle wegkopieren. Wer zuerst repariert, vernichtet die Spur.
4. Bei Datenverlust: Wiederherstellung aus der Sicherung (täglich, wöchentlich getestet).

Stufe 4 — Melden

An den Merchant, unverzüglich — auch wenn das Bild noch unvollständig ist. Eine erste Meldung mit „wir wissen noch nicht alles" ist zulässig und richtig; eine späte vollständige nicht.

Die Meldung enthält (Art. 33 Abs. 3 sinngemäß):

• Art des Vorfalls, betroffene Datenkategorien, ungefähre Zahl der Betroffenen
• Zeitpunkt des Eintritts und der Entdeckung
• wahrscheinliche Folgen
• ergriffene und geplante Maßnahmen
• Kontakt für Rückfragen

Kanal: E-Mail an die im Shopify-Konto hinterlegte Merchant-Adresse; bei mehreren Betroffenen zusätzlich ein Hinweis in der App.

Stufe 5 — Nachbereiten

Innerhalb einer Woche nach Abschluss:

1. Ursachenanalyse — nicht „was ist passiert", sondern „warum hat es niemand vorher bemerkt".
2. Wächter ergänzen, wenn kein Signal existierte. Ein Vorfall, der keinen Alarm auslöste, ist zuerst eine Lücke in der Überwachung.
3. Lehre festhalten im Portfolio-Register, damit der Fall auch andere Apps erreicht.
4. Dieses Dokument aktualisieren, wenn der Ablauf sich als unpraktikabel erwiesen hat.

4. Fristen im Überblick

Die 24 Stunden sind bewusst kürzer als die 72 Stunden des Merchants: Er braucht Vorlauf für seine eigene Meldung. Sein Fristbeginn ist unsere Meldung.

5. Kontakte

Zuständige Aufsichtsbehörde für den Betreiber: Landesdatenschutzbehörde am Unternehmenssitz — relevant nur, wenn Etchify selbst Verantwortlicher ist (Abschnitt 1).

6. Ehrlich benannte Grenzen

1. Keine 24/7-Bereitschaft. Nachts und am Wochenende kann die Entdeckung sich verzögern. Die automatisierten Wächter laufen durchgehend und senden Push-Benachrichtigungen; die Reaktion hängt an einer Person.
2. Nicht geübt. Dieser Plan ist noch nie durchgespielt worden. Ein ungeübter Plan ist im Ernstfall deutlich langsamer als ein geübter. → Abschnitt 7.
3. Keine forensischen Werkzeuge. Bei einem tiefergehenden Vorfall wäre externe Unterstützung nötig; das ist heute nicht vorbereitet.

7. Empfohlene Übung (30 Minuten, nicht launch-sperrend)

Ein Durchgang am Schreibtisch, ohne echte Änderung an der Produktion:

Durchspielen: Wen informiere ich, in welcher Reihenfolge, mit welchem Text — und wie stelle ich fest, welche Merchants betroffen sind? Genau die letzte Frage ist die, die im Ernstfall am längsten dauert und sich vorher am billigsten klären lässt.

8. Änderungshistorie