Vertrag über die Auftragsverarbeitung (AVV)

nach Art. 28 DSGVO — für die Shopify-App Kartuu

Vertragsparteien

Verantwortlicher

Der Händler, der Kartuu in seinem Shopify-Shop installiert. Er entscheidet über Zwecke und Mittel der Verarbeitung der Daten, die in seinem Shop anfallen.

Der Händler wird gegenüber dem Auftragsverarbeiter durch zwei Angaben identifiziert, die beide beim Vertragsschluss nach § 0 festgehalten werden:

1. seine myshopify-Domain — sie bezeichnet den Shop eindeutig und stammt aus dem von Shopify signierten Sitzungsnachweis, ist also nicht frei behauptbar;
2. eine E-Mail-Adresse als Kontaktadresse, die der Händler im Zustimmungsschritt selbst angibt (Pflichtfeld, § 2a Nr. 4).

Damit sind Name und Kontaktdaten des Verantwortlichen im Sinne von Art. 30 Abs. 2 lit. a DSGVO führbar. Die vollständigen Firmendaten (Firmierung, Anschrift, Vertretung) erhebt KYTH nicht selbst; sie ergeben sich aus dem Shopify-Konto des Händlers und werden bei Bedarf über die genannte Kontaktadresse erfragt.

Auftragsverarbeiter

KYTH. Systems UG (haftungsbeschränkt) Prof.-Mederer-Straße 4 92348 Berg Deutschland

Datenschutzbeauftragter: Ein Datenschutzbeauftragter ist nicht bestellt. Nach § 38 BDSG besteht dazu bei der derzeitigen Unternehmensgröße keine Pflicht. Zuständige Anlaufstelle für Datenschutzfragen ist datenschutz@kyth.systems; das ist kein Datenschutzbeauftragter im Sinne von Art. 37 DSGVO.

Im Folgenden „KYTH“.

§ 0 Zustandekommen des Vertrages

0.1 Zustimmung im Installationsablauf

Dieser Vertrag kommt dadurch zustande, dass der Händler ihm im Installationsablauf der App zustimmt. Der Ablauf ist folgender:

1. Der Händler öffnet Kartuu in seinem Shopify-Adminbereich und löst das Verbinden aus.
2. Liegt für die aktuelle Fassung keine Zustimmung vor, führt die App den Vorgang nicht aus, sondern zeigt den Zustimmungsschritt: Verweise auf diesen Vertrag, auf die Datenschutzerklärung und auf den Nutzungsvertrag, ein Feld für die Kontaktadresse (Pflichtfeld) und ein Zustimmungshäkchen, das nicht vorbelegt ist.
3. Erst wenn der Händler beides ausfüllt, wird der Vorgang ausgeführt.

Ohne Zustimmung geschieht nichts. Vor der Zustimmung wird weder ein Datensatz zum Shop angelegt noch ein Zugangstoken bei Shopify abgeholt. Die Prüfung, ob eine Zustimmung zur aktuellen Fassung vorliegt, steht vor jedem Schreibzugriff und vor jedem Aufruf bei Shopify.

Eine Ausnahme liegt außerhalb des Einflusses von KYTH. Bei der von Shopify verwalteten Installation ist die App bereits installiert und sind die Webhooks bereits abonniert, bevor der Händler die eingebettete Seite überhaupt zum ersten Mal öffnet. Klickt er den Zustimmungsschritt weg und deinstalliert wieder, sendet Shopify gleichwohl app/uninstalled; verkauft er in der Zwischenzeit etwas, sendet Shopify auch orders/paid. Diese signierten Webhooks nimmt KYTH entgegen: Die Shop-Domain wird zum Suchhash verrechnet, in der Datenbank nachgeschlagen und — wenn kein Shop zu ihr gehört — für 14 Tage im Anwendungsprotokoll vermerkt. Ein Datensatz zum Shop entsteht dabei nicht, und auch keine Gutscheinzeile: Ohne Shop-Datensatz gibt es keinen Mandanten, in dem eine entstehen könnte, und der Inhalt der Bestellung wird nach der Signaturprüfung nicht weiter ausgewertet. Gespeichert wird lediglich die technische Webhook-Kennung im Duplikatschutz. Diese Verarbeitung findet also ohne geschlossenen Vertrag statt, und sie steht deshalb als eigener Fall in Anlage 1 Abschnitt A. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse daran, einen von Shopify verpflichtend abonnierten Webhook signaturgeprüft entgegenzunehmen und einen unbekannten Shop nicht lautlos zu verschlucken —, ergänzend Art. 6 Abs. 1 lit. c DSGVO, soweit die Entgegennahme der Datenschutz-Webhooks der Erfüllung der Pflichten aus Art. 12 ff. DSGVO dient.

Eine gesonderte Unterschrift ist nicht erforderlich (Art. 28 Abs. 9 DSGVO lässt das elektronische Format ausdrücklich zu).

0.2 Nachweis

KYTH hält den Vertragsschluss in der Datenbank fest — drei Angaben, entweder alle oder keine:

Die Fassungskennung setzt ausschließlich der Server; eine vom Browser mitgeschickte Angabe bleibt wirkungslos.

Der Nachweis überdauert eine Deinstallation. Installiert der Händler die App innerhalb der Frist nach § 9.3 Nr. 1 erneut, muss er nicht erneut zustimmen — seine Zustimmung zu genau dieser Fassung liegt vor. Mit der Löschung des Shops verschwindet auch der Nachweis.

Verlauf: Neben der zuletzt erteilten Zustimmung an der Shop-Zeile hält die Tabelle zustimmungen jede erteilte Zustimmung fest — ausschließlich anhängend und ohne UPDATE: Ein geschriebener Nachweis lässt sich nicht mehr ändern. Gelöscht wird er zusammen mit dem Shop (§ 9). So bleibt der Nachweis einer älteren Zustimmung erhalten, wenn eine Fassung erhöht wird. Ein Eintrag trägt Shop-Zuordnung, Fassungskennung und Zeitpunkt; eine personenbezogene Angabe steht nicht darin.

0.3 Geltende Fassung und Änderungen

Der Vertrag gilt in der Fassung, deren Kennung beim Zustimmen festgehalten wurde. Ändert KYTH den Text inhaltlich, erhöht KYTH die Fassungskennung; beim nächsten Öffnen der App wird der Händler erneut um Zustimmung gebeten. Eine reine Berichtigung von Schreibfehlern führt nicht zu einer neuen Kennung.

Unabhängig davon informiert KYTH den Händler über eine Änderung dieses Vertrages mindestens 30 Tage vor dem Wirksamwerden in Textform an die nach § 2a Nr. 4 hinterlegte Kontaktadresse. Widerspricht der Händler nicht innerhalb von 30 Tagen ab Zugang der Mitteilung in Textform, gilt die neue Fassung als angenommen; widerspricht er, kann jede Partei die Nutzung der App beenden — der Händler durch Deinstallation.

0.4 Veröffentlichung

Alle drei Dokumente liefert die App unter https://kartuu.kyth.systems/rechtliches/ aus (/rechtliches/auftragsverarbeitung, /rechtliches/datenschutz und /rechtliches/nutzungsvertrag), ohne Anmeldung und aus derselben Quelle, aus der die Fassungskennung stammt. Unabhängig davon stellt KYTH sie auf Anfrage an datenschutz@kyth.systems bereit.

§ 1 Gegenstand, Dauer, Art und Zweck der Verarbeitung

1.1 Gegenstand

KYTH stellt dem Händler die Shopify-App Kartuu zur Verfügung. Kartuu ist dafür bestimmt, aus Bestellungen des Händler-Shops personalisierte Geschenkgutscheine als PDF zu erzeugen und zuzustellen.

Umgesetzt ist:

1. Die Gestaltung der Gutscheinkarte im Adminbereich: Der Händler gestaltet die Karte, tippt Probeangaben ein und bekommt eine Vorschau und ein PDF zurück. Die Probeangaben werden nicht gespeichert; gespeichert wird eine Gestaltung nur, wenn der Händler sie als Entwurf sichert.
2. Die Einrichtung des Gutscheinprodukts im Shop des Händlers, auf seinen Klick hin.
3. Die Kartenvorschau auf der Produktseite, wenn der Händler den Kartuu-Block dort platziert (Anlage 1 Abschnitt B).
4. Der Bestellablauf: Kartuu ist auf den Webhook orders/paid abonniert. Aus einer bezahlten Bestellung mit einer Gutscheinposition entsteht je gekauftem Stück eine Zeile in der Datenbank — mit den Angaben, die der Kunde im Bestellformular gemacht hat (Empfängername, E-Mail-Adresse des Beschenkten, Absendername, Grußtext, gewünschter Versandtermin), mit der Shopify-Kundennummer des Käufers und mit einem von Kartuu erzeugten Gutscheincode. Bei einem Wertgutschein legt Kartuu damit über die Admin-API eine echte Shopify-Geschenkkarte an. Anschließend wird die Karte gerendert. Als Gutscheinposition gilt nur eine Position, deren Produkt der Händler in Kartuu als Gutscheinprodukt eingerichtet hat. Tragen andere Produkte Kartuu-Angaben, entsteht die Zeile im Zustand „Produkt prüfen“ — ohne Code, ohne Geschenkkarte und ohne Abruflink —, bis der Händler sie in der Bestellübersicht freigibt oder verwirft. Unmittelbar bevor ein Gutschein ausgestellt wird, fragt Kartuu bei Shopify den Storno- und Zahlungsstand der Bestellung ab; ist sie storniert, ganz erstattet oder die Zahlung aufgehoben, entsteht kein Gutschein.
5. Der Kartuu-Block auf der Danke- und Bestellstatusseite, wenn der Händler ihn platziert: Er zeigt der kaufenden Person den Stand ihrer Gutscheine und, nach erfolgreicher Prüfung, die Abruflinks (Anlage 1 Abschnitt B).

Die Zustellung ist umgesetzt — über den Mailserver DES HÄNDLERS. Der Händler hinterlegt in der App unter „Administration" seinen eigenen SMTP-Zugang; Kartuu liefert die Mail über diesen Zugang ein. Sie trägt das gerenderte PDF im Anhang und einen Abruflink. Hat die kaufende Person einen Wunschtermin gewählt, hält Kartuu die Mail bis dahin zurück; der Händler kann sie in der Bestellübersicht mit „Jetzt senden“ vorziehen. Hinterlegt der Händler nichts, verschickt Kartuu für ihn nichts: Der Gutschein wird erzeugt, ist abrufbar und herunterladbar, und der Händler übergibt ihn selbst.

KYTH ist an dieser Stelle kein Verarbeiter. Die Mail an den Beschenkten geht nicht über einen Versandweg von KYTH und nicht über einen Unterauftragsverarbeiter von KYTH, sondern über den Mailanbieter, den der Händler selbst gewählt und selbst beauftragt hat. Ein eigenes oder gemeinsames Mailkonto für alle Händler hat Kartuu nicht.

Das gerenderte PDF wird nicht gespeichert; es entsteht bei jedem Versand neu. Was Kartuu heute tatsächlich verarbeitet, ist abschließend in Anlage 1 aufgeführt.

Bildmotive. Der Händler kann Bildmotive hochladen — sein Logo, sein Produktfoto —, damit eine Kartenvorlage sie zeichnen kann. Diese Bilder werden dauerhaft aufbewahrt: die Bytes in der Bildablage (§ 3.4), die Angaben darüber (Schlüssel, Typ, Maße, Größe, Prüfsumme) in einer Tabelle der Datenbank. Anlage 1 Abschnitt A führt sie mit Zweck, Rechtsgrundlage und Löschung; die Prüfung beim Hochladen steht in Anlage 2 Abschnitt 2.6.

Erweitert sich der Funktionsumfang, wird dieser Vertrag angepasst und dem Händler in der neuen Fassung vorgelegt (§ 0.3).

1.2 Art der Verarbeitung

Erheben, Erfassen, Speichern, Verwenden, Abfragen, Verschlüsseln, Übermitteln an den in § 6 genannten Empfängerkreis, Löschen und Einschränken der Verarbeitung — jeweils im Umfang der Anlage 1.

1.3 Zweck der Verarbeitung

Ausschließlich:

1. Installation und Betrieb der App im Shop des Händlers: Zuordnung des Shops, Beschaffung und Erneuerung der Shopify-Zugangstoken, Authentifizierung von Aufrufen aus der eingebetteten Oberfläche.
2. Erfüllung der von Shopify vorgeschriebenen Datenschutz-Webhooks (Auskunft, Löschung einer Person, Löschung eines Shops).
3. Nachweis über Zugriffe auf geschützte Kundendaten (Protokoll über Zugriffe auf geschützte Kundendaten): Auflage aus der Shopify-Freigabe für geschützte Kundendaten und eigene Rechenschaftsfähigkeit nach Art. 5 Abs. 2 DSGVO. Art. 5 Abs. 2 DSGVO ist dabei der Zweck, nicht die Rechtsgrundlage; zur Rechtsgrundlage siehe Abschnitt 5.1 der Datenschutzerklärung.
4. Feststellung des Abonnementstands des Händler-Shops bei Shopify und dessen Durchsetzung an drei Stellen: dem Einrichten des Gutscheinprodukts, dem Korrekturabzug und der Zustellsperre — ohne aktives Abonnement hält der automatische Versand an, und die fertigen Gutscheine bleiben liegen, bis wieder ein Tarif läuft. Die Erzeugung eines bezahlten Gutscheins ist ausdrücklich nicht verriegelt: Die Geschenkkarte entsteht, und der Händler kann die Karte herunterladen und selbst übergeben. Die Tarife verwaltet Shopify; KYTH liest dort, ob ein aktives Abonnement besteht, wie der Tarif heißt, ob es ein Testabonnement ist und bis wann der laufende Abrechnungszeitraum reicht. Die ersten drei Angaben werden zwischengespeichert, das Ende des Abrechnungszeitraums wird nur angezeigt.
5. Erzeugung der Gutscheinkarte als Vorschau und als PDF aus Angaben, die der Händler im Adminbereich selbst eingibt — ohne Speicherung der Probeangaben und ohne Zugriff auf Bestell- oder Kundendaten des Shops; gespeichert werden nur Entwürfe, die der Händler ausdrücklich sichert.
6. Aufbewahrung der vom Händler hochgeladenen Bildmotive, damit eine Kartenvorlage sie zeichnen kann.
7. Einrichtung des Gutscheinprodukts im Shop des Händlers auf dessen Klick hin, und Festhalten, welches Produkt das ist. Ohne diese Angabe ließe sich eine Gutscheinbestellung, die über einen Express-Bezahlweg hereinkommt, nicht als solche erkennen.
8. Abwicklung einer bezahlten Gutscheinbestellung in diesen Schritten: a) die bezahlte Bestellung entgegennehmen und je gekauftem Stück einen Datensatz anlegen; b) die Angaben des Kunden zur beschenkten Person übernehmen und verschlüsselt ablegen; c) bei einem Wertgutschein einen Gutscheincode erzeugen, ihn verschlüsselt speichern und damit bei Shopify eine Geschenkkarte anlegen; d) die Karte rendern und den Vorgang als abgeschlossen vermerken; e) den fertigen Gutschein zustellen, und zwar über den Mailzugang des Händlers (§ 1.1). Hat der Händler keinen hinterlegt, wird nichts zugestellt — der Gutschein bleibt abrufbar und herunterladbar, und der Händler übergibt ihn selbst; f) der kaufenden Person im Kartuu-Block den Stand und die Abruflinks ihrer Gutscheine zeigen.
9. Kartenvorschau auf der Produktseite des Shops, ohne Speicherung.
10. Betriebsdiagnose und Sicherheit in dem in Anlage 1 beschriebenen, sehr engen Umfang.

Eine Verarbeitung zu eigenen Zwecken von KYTH — insbesondere zu Werbung, Profiling, Weiterverkauf, Training von Modellen oder Auswertung über Händler hinweg — findet nicht statt.

1.4 Dauer

Die Verarbeitung beginnt mit der Zustimmung nach § 0 und dem darauf folgenden Verbinden der App. Der Vertrag läuft auf unbestimmte Zeit, solange die App installiert ist.

Der Vertrag endet, ohne dass es einer Kündigung bedarf, mit der Deinstallation der App. Für Daten, die zu diesem Zeitpunkt noch vorhanden sind, gelten die Pflichten dieses Vertrages bis zu deren Löschung nach § 9 fort.

Höchstdauer. Die in der Datenbank verbliebenen Daten werden spätestens 30 Tage nach der Deinstallation gelöscht — im Regelfall früher, nämlich mit dem Webhook shop/redact, den Shopify regelmäßig 48 Stunden nach der Deinstallation sendet. Bleibt dieser Webhook aus, greift der Aufräumlauf nach § 9.3 Nr. 1. In den Sicherungen bestehen gelöschte Daten fort, bis die dortigen Fristen ablaufen (§ 9.3 Nr. 2).

§ 2 Art der personenbezogenen Daten und Kategorien betroffener Personen

2.1 Kategorien betroffener Personen

2.2 Art der Daten

Abschließend aufgeführt in Anlage 1. In Kurzform:

• Gespeichert werden zum Shop: die myshopify-Domain des Shops im Klartext, ein nicht umkehrbarer HMAC-Hash derselben Domain als Suchindex, der Shopify-Access-Token und der Shopify-Refresh-Token (beide verschlüsselt), die Kontaktadresse des Händlers (verschlüsselt), Zeitpunkt und Fassungskennung seiner Zustimmung, der zuletzt bei Shopify gelesene Abonnementstand, ein eingelöster Aktionscode mit Zeitpunkt, technische Zeitstempel und der Berechtigungsumfang (Scopes), Einträge im Protokoll über Zugriffe auf geschützte Kundendaten, technische Kennungen eingehender Webhooks, die vom Händler hochgeladenen Bildmotive — deren Bytes in der Bildablage, deren Schlüssel, MIME-Typ, Größe, Maße und Prüfsumme in einer Tabelle der Datenbank —, vom Händler gesicherte Entwürfe seiner Kartengestaltung, der von ihm hinterlegte Mailzugang (Benutzername und Passwort verschlüsselt), die gewählte Sprache der Gutscheine sowie die Angaben zu seinem Gutscheinprodukt (Art, Shopify-Produktkennung, Handle, gewählte Vorlage, Zeitpunkt des Anlegens).
• Gespeichert werden je gekauftem Gutschein: Name und E-Mail-Adresse des Käufers, Empfängername, E-Mail-Adresse des Beschenkten, Absendername, Grußtext und der Gutscheincode, sämtlich verschlüsselt; ein Abruf- Token, ebenfalls verschlüsselt; nicht umkehrbare Suchwerte über Gutscheincode, Abruf-Token, Empfänger- und Käuferadresse; die Shopify-Kundennummer des Käufers im Klartext; Bestellkennung, Positionskennung und die laufende Nummer des Stücks; die Art des Gutscheins, die Kennung der Kartenvorlage und ein eingefrorenes Abbild dieser Vorlage mit Platzhaltern statt Werten; Nennwert und Währung, der gedruckte Betrag als Text, der Shopname und ein Gültigkeitsdatum; die Kennung der Shopify-Geschenkkarte; Zustand, Zeitpunkt des letzten Zustandswechsels, Fehlerzähler und Fehlergrund als kurze eigene Kennung; eine offene Frage an den Händler nach einer Erstattung (welche Frage, wie viele Stücke noch zu entscheiden sind, seit wann); der gewünschte Versandtermin; der Kopf der Bestellung (Bestellnummer, Zeitpunkt, Gesamtbetrag mit Währung, Zahlungsart, Verkaufskanal); der Rabatt, mit dem das Stück gekauft wurde (Betrag mit Währung, Code oder Titel des Rabatts und ob er der ganzen Bestellung galt); sowie die Schlüssel der Bildmotive, die in dieser Karte stecken.
• Nur flüchtig im Arbeitsspeicher berührt und nirgends abgelegt: der Shopify-Sitzungstoken des eingeloggten Händler-Nutzers, Kundennummer und E-Mail-Adresse aus den Datenschutz-Webhooks, der übrige Inhalt einer eingehenden Bestellung, die Probeangaben, die der Händler bei der Gestaltung eintippt (Empfänger- und Absendername, Grußtext, Gutscheincode, Betrag, Shopname, Gültigkeitsdatum), die Angaben aus dem Kartuu-Block und der Kartenvorschau im Shop (Anlage 1 Abschnitt B) sowie jedes erzeugte PDF — auch das aus einer Bestellung.
• Nicht gespeichert: Anschriften, Telefonnummern und Zahlungsdaten der Kundschaft des Händlers und der Bestellinhalt jenseits der Gutscheinpositionen und des oben genannten Bestellkopfs. Der Guthabenstand einer Shopify-Geschenkkarte wird gelesen, aber nicht gespeichert: Fragt der Händler in der Bestellübersicht nach dem Einlösestand oder ruft er den Export auf, holt Kartuu ihn bei Shopify und reicht ihn durch. Beim Storno fragt Kartuu ihn vor dem Entwerten ab: Eine schon angebrochene Karte wird nicht ohne Entscheidung des Händlers entwertet.

Zu den Bildmotiven: Was ein hochgeladenes Bild zeigt und welche Aufnahmedaten darin stehen, bestimmt der Händler. Ein Bild kann Personen abbilden, und die eingebetteten Aufnahmedaten (EXIF) eines Mobiltelefons können einen Standort tragen. KYTH prüft das Bild auf Format, Maße und Ungefährlichkeit (Anlage 2 Abschnitt 2.6) und wertet den Inhalt nicht aus.

Die Aufnahmedaten fallen beim Hochladen weg, und zwar aus jedem Bild. Misst die längere Kante mehr als 2000 Pixel, wird das Motiv auf diese Kante heruntergerechnet und dabei neu kodiert; die Ausrichtung wird dabei in die Pixel übernommen. Ist das Bild kleiner, verwirft Kartuu nur die Teile der Datei, in denen Aufnahmedaten stehen, und kodiert nicht neu — die Bildpunkte bleiben unverändert, und die Ausrichtung bleibt als einzige Angabe stehen, damit ein hochkant aufgenommenes Foto nicht auf der Seite liegt. Aufnahmezeitpunkt, Gerät und Standort fallen in beiden Fällen vollständig weg. Bilder, die vor dem 23.09.2026 hochgeladen wurden, sind auf dieselbe Weise bereinigt.

Wer ein Motiv abrufen kann. Eine allgemein lesbare Adresse der Bildablage gibt es nicht. Der Händler erhält seine Bilder im Adminbereich nach Prüfung seiner Sitzung. Außerhalb davon wird ein Motiv nur über eine signierte Adresse ausgeliefert, die an den Shop und den Schlüssel gebunden ist und nach ein bis zwei Stunden ungültig wird: in der Vorschau im Adminbereich und — wenn Motiv oder Logo zur Gestaltung eines Gutscheinprodukts gehören — an jede Person, die dessen Produktseite mit der Kartenvorschau aufruft. Diese Person kann die Bilddatei so herunterladen, wie sie gespeichert ist — ohne Aufnahmedaten. Was ein Händler von sich aus in ein Bild hineinlädt, verantwortet er.

2.3 Erteilte Berechtigungen und ihre Ausübung

Dieser Abschnitt trennt zwei Dinge: was KYTH darf und was KYTH tut.

Was der Händler erteilt. In der Shopify-App-Konfiguration sind angefordert:

Was KYTH weiterhin nicht tut. Über die Admin-API fragt Kartuu kein Kundendatenfeld ab — keine Anschrift, keine Telefonnummer, keine Zahlungsdaten. Die personenbezogenen Bestelldaten kommen ausschließlich aus dem Webhook, den Shopify zustellt. Eine Bestellung wird sehr wohl abgefragt, aber nur in ihrer Lage: Beim Freigeben fragt Kartuu zu der Bestellung, aus der der Gutschein stammt, die Erfüllungsaufträge und die offenen Mengen ab, um die Gutscheinposition als erfüllt melden zu können. Übertragen wird dabei die Bestellkennung; zurück kommen Kennungen, Zustände und Stückzahlen — kein Kundendatenfeld. Unmittelbar bevor ein Gutschein ausgestellt wird, fragt Kartuu außerdem, ob die Bestellung storniert ist und wie ihr Zahlungsstand lautet; übertragen wird wieder allein die Bestellkennung. Die vollständige Liste der fünfundzwanzig Aufrufe an die Admin-API steht in § 3.4.

Herkunft der Daten. Personenbezogene Daten erreichen Kartuu auf diesen Wegen:

1. Aus dem Shop des Händlers — über den Bestellwebhook. Diese Daten werden gespeichert (Anlage 1 Abschnitt A). Für sie ist der Händler Verantwortlicher und KYTH Auftragsverarbeiter; die Weisung dazu ist dieser Vertrag samt der Einrichtung des Gutscheinprodukts.
2. Aus der Eingabe des Händlers bei der Gestaltung — Probeangaben werden nicht gespeichert (Anlage 1 Abschnitt B); gesicherte Entwürfe werden gespeichert (Anlage 1 Abschnitt A).
3. Aus einem Upload des Händlers — die Bilder werden gespeichert (Anlage 1 Abschnitt A).
4. Aus dem Browser der kaufenden oder besuchenden Person — über den Kartuu-Block und die Kartenvorschau im Shop. Diese Angaben werden nicht gespeichert (Anlage 1 Abschnitt B).

Wenn sich das ändert. Vor jeder Erweiterung, die den Kreis der verarbeiteten Daten verändert, wird dieser Vertrag in neuer Fassung vorgelegt und die Fassungskennung erhöht — der Händler wird dann erneut um Zustimmung gebeten (§ 0.3, § 11 Nr. 6).

2.4 Besondere Datenkategorien

Daten besonderer Kategorien nach Art. 9 DSGVO und Daten nach Art. 10 DSGVO sind nicht Gegenstand der Verarbeitung. KYTH wird sie auch künftig nicht anfordern.

§ 2a Pflichten und Rechte des Verantwortlichen

Art. 28 Abs. 3 Satz 1 DSGVO verlangt, dass ein Auftragsverarbeitungsvertrag auch die Pflichten und Rechte des Verantwortlichen festlegt. Das geschieht hier.

1. Rechtmäßigkeit der Verarbeitung. Der Händler ist allein dafür verantwortlich, dass die von ihm angewiesene Verarbeitung rechtmäßig ist und dass eine Rechtsgrundlage nach Art. 6 DSGVO vorliegt. Er entscheidet über Zwecke und Mittel. KYTH prüft die Rechtsgrundlage nicht und kann sie nicht prüfen.
2. Informationspflichten. Die Informationspflichten nach Art. 13 und Art. 14 DSGVO gegenüber der Kundschaft des Händlers und gegenüber Beschenkten treffen den Händler. Beschenkte geben ihre Daten typischerweise nicht selbst, sondern die schenkende Person gibt sie — dafür gilt Art. 14 DSGVO.
3. Weisungen. Der Händler ist berechtigt und verpflichtet, Weisungen nach § 3 zu erteilen; seine Weisungen müssen rechtmäßig sein. Er benennt KYTH die Personen, die für ihn weisungsberechtigt sind, und hält diese Angabe aktuell. Benennt er niemanden, gelten die vertretungsberechtigten Organe des Händlers als weisungsberechtigt.
4. Kontaktadresse. Der Händler gibt beim Zustimmungsschritt nach § 0 eine E-Mail-Adresse an, unter der KYTH ihn erreichen kann. Die Angabe ist Pflicht; ohne sie wird die App nicht verbunden. An diese Adresse gehen die Mitteilungen nach § 0.3, § 6.6 und § 8.2. Hat der Händler einen Mailzugang hinterlegt, schickt Kartuu über diesen Zugang außerdem höchstens einmal täglich einen Hinweis an diese Adresse, wenn Bestellungen seine Aufmerksamkeit brauchen; der Hinweis nennt nur Anzahlen und einen Link in die App, keine Namen, Adressen, Codes oder Beträge. Der Händler hält die Adresse aktuell und teilt eine Änderung in Textform an datenschutz@kyth.systems mit. In der App lässt sie sich beim Zustimmungsschritt ändern: Steigt die Fassung dieser Texte, fragt Kartuu erneut und zeigt dabei die hinterlegte Adresse zur Bearbeitung an; der eingetragene Wert wird gespeichert. Einen eigenen Bildschirm dafür gibt es nicht. Wird die Adresse unzustellbar, kann KYTH den Händler nicht mehr unmittelbar erreichen — auch nicht bei einer Verletzung des Schutzes personenbezogener Daten, für deren Meldung dem Händler nach Art. 33 Abs. 1 DSGVO nur 72 Stunden bleiben. Die Aktualität liegt deshalb in seinem eigenen Interesse.
5. Nachweise und Prüfungen. Der Händler hat die Rechte auf Nachweise und Überprüfungen nach § 10.
6. Meldung von Datenpannen. Die Meldung einer Verletzung des Schutzes personenbezogener Daten an die Aufsichtsbehörde (Art. 33 DSGVO) und die Benachrichtigung der betroffenen Personen (Art. 34 DSGVO) obliegen dem Händler. KYTH unterstützt ihn dabei nach § 8.2.
7. Eigene Kontrolle. Der Händler überzeugt sich vor Beginn der Verarbeitung und danach regelmäßig von den technischen und organisatorischen Maßnahmen nach Anlage 2. Anlage 2 benennt in Abschnitt 7 ausdrücklich die bekannten Lücken.

Zum Umgang mit der Kontaktadresse. KYTH speichert sie verschlüsselt, verwendet sie ausschließlich für die in Nummer 4 genannten Mitteilungen und Hinweise und für die Weiterleitung von Anfragen betroffener Personen nach § 7.1, gibt sie nicht weiter und wirbt darüber nicht. Sie wird mit der Shop-Zeile gelöscht (§ 9).

§ 3 Verarbeitung nur auf dokumentierte Weisung

3.1 Grundsatz

KYTH verarbeitet personenbezogene Daten ausschließlich auf dokumentierte Weisung des Händlers. Das gilt auch für die Übermittlung in ein Drittland.

3.2 Was als Weisung gilt

Weisungen sind:

1. dieser Vertrag einschließlich seiner Anlagen — er ist die Grunderklärung der Weisungen; die Zustimmung nach § 0 ist die Erteilung dieser Grunderklärung,
2. die Installation der App und die Erteilung der Berechtigungen im Shopify-Adminbereich,
3. Einstellungen und Handlungen des Händlers in der App — insbesondere das Hochladen eines Bildmotivs, das Sichern eines Entwurfs, das Einrichten des Gutscheinprodukts, das Hinterlegen des Mailzugangs, die Wahl der Sprache, das Ändern oder Ergänzen von Kartenangaben und das Freigeben eines Gutscheins. Probeangaben für eine Vorschau gelten nur für diesen einen Renderlauf und werden nicht gespeichert,
4. Einzelweisungen in Textform an datenschutz@kyth.systems.

Mündlich erteilte Weisungen bestätigt der Händler unverzüglich in Textform. KYTH dokumentiert Einzelweisungen und bewahrt sie für die Dauer des Vertrages auf.

3.3 Grenzen der Weisung

KYTH informiert den Händler unverzüglich, wenn eine Weisung nach Auffassung von KYTH gegen die DSGVO oder gegen andere Datenschutzvorschriften verstößt. KYTH darf die Ausführung einer solchen Weisung aussetzen, bis der Händler sie bestätigt oder ändert.

Ist KYTH gesetzlich zu einer Verarbeitung verpflichtet, teilt KYTH dem Händler die rechtliche Anforderung vor der Verarbeitung mit, sofern das Gesetz die Mitteilung nicht wegen eines wichtigen öffentlichen Interesses verbietet.

3.4 Verarbeitungsort und Drittlandtransfer

Die Verarbeitung durch KYTH selbst findet in Deutschland statt: Anwendung und Datenbank laufen auf einem einzigen virtuellen Server bei der IONOS SE am Standort Berlin. Die täglichen Datenbanksicherungen liegen im Objektspeicher der IONOS in der Region eu-central-3, ebenfalls Berlin. Die vom Händler hochgeladenen Bildmotive liegen auf dem Server selbst — in einer Dateiablage auf einem dauerhaften Datenträger. Siehe § 6.3. Es gibt keine weitere Verarbeitungsumgebung. Der Objektspeicher begründet keinen Drittlandbezug.

Übermittlungen an Stellen außerhalb von KYTH ergeben sich ausschließlich aus dem in § 6 genannten Kreis:

• Shopify: Kartuu ruft ausgehend drei fremde Endpunkte auf. Zwei liegen beim Händler-Shop selbst: der Token-Endpunkt (https://{shop-domain}/admin/oauth/access_token) und die Admin-API (https://{shop-domain}/admin/api/{version}/graphql.json). Der dritte ist der Speicherort, den Shopify für das Hochladen eines Produktbilds benennt — er wird je Upload frisch mitgeteilt und liegt nicht beim Shop des Händlers. Übertragen werden dabei die Zugangsdaten der App und der jeweilige Token, beim dritten die Bilddaten selbst. Über die Admin-API laufen fünfundzwanzig verschiedene Aufrufe, und sie tragen Unterschiedliches:

Bestell- und Kundendaten werden über die Admin-API nicht abgefragt; sie kommen eingehend über den Webhook orders/paid, den Shopify zustellt. Shopify ist zugleich die Plattform, auf der der Shop des Händlers ohnehin betrieben wird; der Händler unterhält hierzu ein eigenes Vertragsverhältnis mit Shopify. Vertragspartner für Händler im Europäischen Wirtschaftsraum ist regelmäßig die Shopify International Ltd. mit Sitz in Irland; eine Verarbeitung durch verbundene Unternehmen außerhalb des EWR, insbesondere die Shopify Inc. in Kanada, ist nicht ausgeschlossen.

Weisung. Mit Abschluss dieses Vertrages weist der Händler KYTH an, den Token-Endpunkt und die Admin-API seines eigenen Shops bei Shopify aufzurufen und die eingehenden Webhooks von Shopify entgegenzunehmen, auch soweit dabei eine Übermittlung an Shopify-Stellen außerhalb des EWR stattfindet (Art. 28 Abs. 3 lit. a DSGVO). Ohne diesen Datenfluss lässt sich die App nicht betreiben.

Kanada. Für Kanada besteht ein Angemessenheitsbeschluss der Europäischen Kommission (Entscheidung 2002/2/EG) für privatwirtschaftliche Organisationen, die dem kanadischen Datenschutzgesetz PIPEDA unterliegen.

Übrige Drittländer, insbesondere die USA: Standardvertragsklauseln. Shopify bezieht in sein Data Processing Addendum in der Fassung vom 07.07.2026 die EU-Standardvertragsklauseln ein — die Klauseln aus dem Durchführungsbeschluss (EU) 2021/914 der Europäischen Kommission vom 4. Juni 2021. Auf sie stützen sich Übermittlungen an Shopify-Stellen außerhalb des Europäischen Wirtschaftsraums, also auch an Stellen in den USA. Das Addendum ist unter https://www.shopify.com/legal/dpa öffentlich abrufbar; eine Kopie der Klauseln erhält der Händler auf Anfrage an datenschutz@kyth.systems (Art. 13 Abs. 1 lit. f DSGVO). Dieselbe Grundlage steht in Abschnitt 8 der Datenschutzerklärung.

• Mailserver des Händlers. Hat der Händler einen E-Mail-Versand eingerichtet, baut Kartuu eine SMTP-Verbindung zu dem Mailserver auf, den er hinterlegt hat, meldet sich dort mit seinem Benutzernamen und Passwort an und liefert die Mails ein: die Mail an die beschenkte Person mit deren E-Mail-Adresse, Empfänger- und Absendername, dem Shopnamen, dem Abruflink samt Gültigkeitsdatum und dem Gutschein als PDF (Grußtext, Betrag, Gutscheincode); auf Klick des Händlers eine Testmail an seine Antwortadresse; höchstens einmal täglich den Hinweis nach § 2a Nr. 4 an seine Kontaktadresse. Der Mailserver ist der des Händlers und dessen eigener Auftragsverarbeiter (§ 6.4). Wo er betrieben wird und ob dabei ein Drittland berührt ist, bestimmt der Händler mit der Wahl seines Mailanbieters. Weisung. Mit dem Hinterlegen des Mailzugangs weist der Händler KYTH an, diese Verbindung aufzubauen (§ 3.2 Nr. 3).

• Cloudflare: keine Übermittlung. Die DNS-Zone kyth.systems wird bei Cloudflare geführt. Für Kartuu ist Cloudflare damit ausschließlich autoritativer DNS-Dienst; die App-Namen lösen unmittelbar auf die IP-Adresse des Servers in Berlin auf, der Datenverkehr läuft nicht über Cloudflare. Cloudflare erhält weder Händler- noch Kundendaten und ist deshalb kein Unterauftragsverarbeiter dieses Vertrages. Siehe § 6.4.

Andere Übermittlungen in Drittländer finden nicht statt. Insbesondere liegen die Sicherungen in Deutschland (§ 6.3).

§ 4 Vertraulichkeit der eingesetzten Personen

KYTH setzt zur Verarbeitung nur Personen ein, die zur Vertraulichkeit verpflichtet sind oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO). Die Verpflichtung wirkt über das Ende der Tätigkeit hinaus.

KYTH stellt sicher, dass diese Personen personenbezogene Daten ausschließlich auf Weisung des Händlers verarbeiten und mit den für sie maßgeblichen Datenschutzvorgaben vertraut sind.

Der Kreis der Zugriffsberechtigten. Zugriff auf die Produktionsumgebung — Server, Coolify, Datenbank und das Shopify Partner Dashboard — haben ausschließlich die beiden Geschäftsführer von KYTH, Stefan Grasse und Stephan Wittmann.

Darüber hinaus hat niemand Zugriff. Es gibt keine Beschäftigten, keine freie Mitarbeit und keine Dienstleister mit Zugang zur Produktionsumgebung. Die Unterauftragsverarbeiter aus § 6.3 sind davon nicht berührt: Sie stellen Infrastruktur und haben keinen Zugriff auf die Anwendung.

Verschwiegenheit. Art. 28 Abs. 3 lit. b DSGVO verlangt eine Verpflichtung zur Vertraulichkeit oder eine angemessene gesetzliche Verschwiegenheitspflicht. Für die Geschäftsführer folgt die Verschwiegenheitspflicht aus ihrer organschaftlichen Treuepflicht (§ 43 GmbHG, für die UG über § 5a Abs. 1 GmbHG). Erhält eine weitere Person Zugriff, wird sie vorher schriftlich zur Vertraulichkeit verpflichtet.

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

KYTH trifft die in Anlage 2 beschriebenen technischen und organisatorischen Maßnahmen. Anlage 2 enthält ausschließlich umgesetzte Maßnahmen und benennt in einem eigenen Abschnitt die bekannten Lücken.

Die Maßnahmen unterliegen dem technischen Fortschritt. KYTH darf sie anpassen, solange das Schutzniveau nicht unterschritten wird. Wesentliche Änderungen werden dokumentiert und dem Händler auf Anfrage mitgeteilt.

KYTH verfügt über keine Datenschutz- oder Sicherheitszertifizierung (weder ISO/IEC 27001 noch SOC 2 noch eine Zertifizierung nach Art. 42 DSGVO) und behauptet auch keine. Anlage 2 ist eine Selbstauskunft, kein Prüfbericht.

§ 6 Unterauftragsverarbeiter

6.1 Zustimmung

Der Händler stimmt mit Abschluss dieses Vertrages der Beauftragung der unter 6.3 genannten Unterauftragsverarbeiter zu (allgemeine schriftliche Genehmigung nach Art. 28 Abs. 2 Satz 2 DSGVO).

6.2 Bedingungen

KYTH verpflichtet jeden Unterauftragsverarbeiter vertraglich auf Datenschutzpflichten, die den Pflichten aus diesem Vertrag entsprechen, insbesondere auf hinreichende Garantien nach Art. 28 Abs. 4 DSGVO. Kommt der Unterauftragsverarbeiter seinen Datenschutzpflichten nicht nach, haftet KYTH gegenüber dem Händler für dessen Einhaltung nach Maßgabe von Art. 28 Abs. 4 Satz 2 DSGVO.

Mit der IONOS gilt deren Vereinbarung zur Auftragsverarbeitung (siehe unten).

6.3 Liste der Unterauftragsverarbeiter

Zu den Verträgen nach Art. 28 Abs. 4 DSGVO:

IONOS. Es gilt die „Vereinbarung zur Auftragsverarbeitung nach Art. 28 Abs. 3 DSGVO" der IONOS, Version 1.2, Stand 06/2023, öffentlich abrufbar unter https://www.ionos.de/terms-gtc/avv/. KYTH hält eine Ausfertigung in seinen Vertragsunterlagen. Nach ihrem § 1.1 umfasst sie „alle Tätigkeiten, die der Auftragnehmer zur Erfüllung des Auftrags erbringt und die eine Auftragsverarbeitung darstellen", und erfasst damit Server und Objektspeicher, soweit beide unter demselben Hauptvertrag bezogen werden.

Den Objektspeicher stellt die IONOS Cloud GmbH (AG Montabaur, HRB 31110); die Anbieterkennzeichnung des Dienstes unter s3.eu-central-3.ionoscloud.com nennt sie. Server, Datenbank und Sicherungen laufen bei der IONOS SE (HRB 24498). Beide sind unter derselben Anschrift erreichbar; welche Gesellschaft im Einzelfall Vertragspartnerin ist, ergibt sich aus dem jeweiligen Vertrag.

Shopify ist kein Unterauftragsverarbeiter, sondern eigener Auftragsverarbeiter des Händlers; siehe 6.4.

6.4 Weitere Empfänger, die keine Unterauftragsverarbeiter sind

Der Vollständigkeit halber, weil ein Datenfluss oder eine Beteiligung besteht:

• Shopify International Limited, The Sidings, 4th Floor, Grand Canal Quay, Dublin D02 E7K8, Irland (Vertragspartnerin für Händler im EWR), verbunden mit Shopify Inc., 151 O'Connor Street, Ground floor, Ottawa, Ontario K2P 2L8, Kanada — eigener Auftragsverarbeiter des Händlers, nicht Unterauftragsverarbeiter von KYTH.

Was tatsächlich fließt: Plattform: Bezug und Erneuerung der Zugangstoken über den Token-Endpunkt des Shops; fünfundzwanzig Aufrufe an die Admin-API des Shops (§ 3.4); das Übertragen des Produktbilds; das Setzen des Versandmerkers (§ 3.4); Zustellung der eingehenden Webhooks an Kartuu, darunter die bezahlten Bestellungen; Weiterleitung der Anfragen aus dem Shop an Kartuu (Kartenvorschau auf der Produktseite, Kartuu-Block auf Danke- und Bestellstatusseite); Verwaltung und Abrechnung der App-Tarife

Welche Daten: Zugangsdaten der App, Sitzungstoken bzw. Refresh-Token, Access-Token, Shop-Domain, der Gutscheincode, der Nennwert und gegebenenfalls das Ablaufdatum beim Anlegen einer Geschenkkarte, die Angaben des Gutscheinprodukts, das Produktbild und der Versandmerker (ob ein E-Mail-Versand eingerichtet ist, ja oder nein). Die Kundennummer des Käufers geht dabei nicht mit. Empfängername, Empfängeradresse und Grußtext gehen nicht an Shopify zurück; sie kommen von dort und bleiben verschlüsselt bei KYTH

Einordnung. Eine Unterauftragsverarbeitung setzt voraus, dass KYTH den Dienstleister beauftragt. Hier hat der Händler Shopify beauftragt — Shopify betreibt seinen Shop. Wenn Kartuu eine Geschenkkarte über die Admin-API anlegt, schreibt es Daten in den Shop des Händlers, und Shopify verarbeitet sie dort als dessen Auftragsverarbeiter, unter dessen eigenem Vertrag.

Belegt ist das an zwei Stellen:

• Shopifys Data Processing Addendum (Fassung vom 07.07.2026, https://www.shopify.com/legal/dpa) benennt seine Parteien selbst: „by and between You (or »Merchant«), and the Shopify Contracting Entity" und weiter: „You shall act as a Data Controller and Shopify shall act as a Data Processor with respect to the processing of Your Customer Personal Data." KYTH ist dort nicht Partei.
• Das Shopify Partner Program Agreement (Stand 27.02.2026, https://www.shopify.com/partners/terms) — der Vertrag, der KYTH bindet — enthält kein Data Processing Addendum. Es beschränkt in 9.14.2 die Verwendung der Händlerdaten durch den Partner („Partner will only use or store such information for the purpose of providing the Partner's services to the Merchant"), begründet aber keine Auftragsverarbeitung Shopifys für KYTH.

Getrennt davon zu sehen ist die Abrechnung der App-Tarife. Dort ist KYTH selbst Kunde von Shopify; das ist eine eigene Vertragsbeziehung von KYTH und keine Verarbeitung im Auftrag des Händlers.

• Der Mailserver des Händlers — nur wenn der Händler einen E-Mail-Versand eingerichtet hat. Eigener Auftragsverarbeiter des Händlers, nicht Unterauftragsverarbeiter von KYTH: Den Mailanbieter wählt und beauftragt der Händler selbst; KYTH liefert lediglich über den Zugang ein, den er hinterlegt. Was dorthin fließt, steht in § 3.4.
• Cloudflare (Cloudflare, Inc., San Francisco, USA; in der EU Cloudflare Germany GmbH, München) — autoritativer DNS-Dienst für die Zone kyth.systems, mehr nicht. Die Namen der App lösen unmittelbar auf die IP-Adresse des Servers in Berlin auf. Der Datenverkehr zwischen dem Browser des Händlers und Kartuu läuft nicht über Cloudflare; ein Proxy-Modus ist für die App nicht eingeschaltet. Cloudflare beantwortet lediglich Namensauflösungen und verarbeitet dabei weder Verbindungs- noch Inhaltsdaten der Händler oder ihrer Kundschaft. Cloudflare ist deshalb kein Unterauftragsverarbeiter dieses Vertrages, und es entsteht über Cloudflare kein Drittlandbezug.

Anders liegt es bei der Unternehmenswebsite von KYTH unter kyth.systems und www.kyth.systems: Diese Namen laufen im Proxy-Modus, dort verarbeitet Cloudflare Verbindungsdaten. Das betrifft Kartuu nicht und ist Gegenstand der Datenschutzerklärung jener Website, nicht dieses Vertrages.

Eine Umstellung der App auf den Proxy-Modus machte Cloudflare zum Unterauftragsverarbeiter; sie erfolgt erst, nachdem die Liste unter 6.3 ergänzt und der Händler nach 6.6 informiert wurde. - GitHub, Inc. (San Francisco, USA; Tochter der Microsoft Corporation) — privates Quellcode-Repository und Bereitstellungsschlüssel. GitHub verarbeitet keine Händler-, Kunden- oder Gutscheindaten. Zugangsgeheimnisse liegen ausschließlich in der Bereitstellungsumgebung und sind von Repository und Container-Abbild ausgeschlossen. - cdn.shopify.com — die eingebettete Oberfläche lädt die Shopify-Bibliothek „App Bridge“ direkt vom Shopify-CDN. Dieser Aufruf erfolgt aus dem Browser des Händlers, nicht vom Server von KYTH. Übertragen werden dabei die Verbindungsdaten des Händler-Browsers (IP-Adresse, Browserkennung) und die Herkunftsangabe. Übertragen werden keine Kunden-, Bestell- oder Gutscheindaten und kein Token; das einzige mitgegebene Attribut ist die öffentliche Anwendungskennung. Die Herkunftsangabe ist durch die Richtlinie Referrer-Policy: strict-origin-when-cross-origin auf https://kartuu.kyth.systems beschränkt, der Parameter ?shop= wird also nicht mitübertragen. Empfänger ist Shopify — dieselbe Stelle, die die umgebende Adminoberfläche ausliefert. Ein zusätzlicher Empfängerkreis entsteht dadurch nicht.

6.5 Ausdrücklich nicht beteiligt

Gesucht und nicht vorhanden: kein Versanddienstleister für E-Mail, kein externer Schrift- oder Symboldienst, kein Analyse- oder Tag-Dienst, kein externer Fehlererfassungsdienst. Die einzige HTTP-Bibliothek im Anwendungscode wird an drei Stellen verwendet: Zwei sprechen den Händler-Shop an — den Token-Endpunkt und die Admin-API —, die dritte lädt das Produktbild an den Speicherort, den Shopify dafür benennt (§ 3.4). Daneben verbindet sich die Anwendung über SMTP mit dem Mailserver, den der Händler hinterlegt hat (§ 3.4, § 6.4).

Objektspeicher wird ausschließlich bei IONOS für die Datenbanksicherungen benutzt (6.3). Mit ihm spricht die Anwendung nicht; die Übertragung dorthin besorgt ein eigenes Sicherungsskript auf dem Server, das den Abzug verschlüsselt, bevor er den Server verlässt (§ 9.3 Nr. 2).

6.6 Änderungen und Widerspruchsrecht

KYTH informiert den Händler über die beabsichtigte Hinzuziehung eines weiteren oder den Austausch eines bestehenden Unterauftragsverarbeiters mindestens 30 Tage vorher in Textform an die vom Händler nach § 2a Nr. 4 hinterlegte Kontaktadresse. Ist diese Adresse unzustellbar geworden, erfolgt die Information zusätzlich durch Veröffentlichung unter https://kartuu.kyth.systems/rechtliches/auftragsverarbeitung; die Frist läuft dann ab der Veröffentlichung.

Der Händler kann der Änderung innerhalb von 30 Tagen ab Zugang der Mitteilung aus einem sachlichen, datenschutzbezogenen Grund in Textform widersprechen. Einigen sich die Parteien nicht, kann der Händler die Nutzung der App beenden, indem er sie deinstalliert; die Löschung richtet sich dann nach § 9. Widerspricht der Händler nicht, gilt die Änderung als genehmigt.

Erfordert eine Änderung wegen einer unmittelbaren Gefahr für die Sicherheit oder Verfügbarkeit ein sofortiges Handeln, informiert KYTH den Händler gleichzeitig mit der Maßnahme, spätestens innerhalb von 24 Stunden. Der Händler kann der Maßnahme innerhalb von 14 Tagen ab Zugang der Mitteilung widersprechen. Im Fall des Widerspruchs beendet KYTH die Einbindung des Unterauftragsverarbeiters unverzüglich, oder der Händler kann den Vertrag mit sofortiger Wirkung beenden; die Löschung richtet sich dann nach § 9. Das Einspruchsrecht nach Art. 28 Abs. 2 Satz 2 DSGVO bleibt damit erhalten.

§ 7 Unterstützung bei den Rechten betroffener Personen

7.1 Grundsatz

Anträge betroffener Personen richten sich an den Händler als Verantwortlichen. Wendet sich eine betroffene Person unmittelbar an KYTH, leitet KYTH den Antrag unverzüglich an den Händler weiter und beantwortet ihn nicht selbst.

KYTH unterstützt den Händler mit geeigneten technischen und organisatorischen Maßnahmen dabei, seiner Pflicht zur Beantwortung nachzukommen (Art. 12 bis 23 DSGVO), soweit dem Händler das nicht bereits über seinen eigenen Shopify-Zugang möglich ist.

7.2 Was technisch bereitsteht

Kartuu ist an die von Shopify vorgeschriebenen Datenschutz-Webhooks angebunden:

Grenze bei beschenkten Personen. Shopifys customers/redact und customers/data_request tragen Kundenkennung und Adresse genau einer Person — der Person, die Shopify kennt. Eine beschenkte Person hat nicht bestellt und taucht dort nicht auf; ihre Zeilen werden über diese Webhooks nur dann getroffen, wenn ihre Adresse dieselbe ist. Der Suchweg über die Adresse ist gebaut, ein Auslöser für eine dritte Person nicht. Verlangt eine beschenkte Person Auskunft oder Löschung, führt KYTH sie auf Weisung des Händlers von Hand aus (§ 7.1). Das steht auch in Anlage 2 Abschnitt 7.

Kaufende Personen ohne Kundennummer. Bei einem Gastkauf fehlt die Kundennummer. Auch die Adresse der kaufenden Person trägt deshalb einen nicht umkehrbaren Suchwert, und die beiden Webhooks finden ihre Angaben darüber. Gutscheine, die vor dem 23.09.2026 angelegt wurden, bekommen diesen Suchwert vom täglichen Aufräumlauf nachgetragen, solange ihre Adresse noch gespeichert ist.

7.3 Berichtigung, Einschränkung, Übertragbarkeit

Zu den technischen Daten des Shops (Shop-Domain, Token, Zeitstempel) gibt es keine Angaben, die inhaltlich unrichtig sein könnten und die der Händler nicht selbst über Shopify korrigieren kann. Verlangt der Händler eine Einschränkung der Verarbeitung, setzt KYTH sie nach Absprache um; das praktisch wirksame Mittel ist die Deinstallation der App.

Anders liegt es bei den Angaben zu einer bestellten Karte. Empfängername, Empfängeradresse, Absendername und Grußtext können unrichtig sein — sie stammen aus einem Formular, das ein Kunde ausgefüllt hat. Der Händler kann sie in der App berichtigen, solange der Gutschein noch nicht ausgestellt ist. In der Bestellübersicht trägt jedes Stück im Zustand „vorbereitet" den Knopf „Angaben ändern"; fehlen die Angaben ganz, heißt derselbe Knopf „Angaben ergänzen". Er öffnet ein Formular über alle vier Felder, und gespeichert werden alle vier gemeinsam — auch das, das der Händler absichtlich geleert hat. Die Adresse wird dabei verschlüsselt abgelegt und ihr Suchwert neu geschrieben, damit ein späteres Löschverlangen die Zeile weiterhin findet.

Nach dem Ausstellen nicht mehr. Ist die Karte gerendert, gilt der Gutschein als geliefert und wird nicht mehr umgeschrieben. Verlangt jemand darüber hinaus eine Berichtigung, genügt eine Nachricht in Textform an datenschutz@kyth.systems; KYTH führt sie von Hand aus. Der Weg, der dem Händler dafür selbst offensteht, ist ein neu ausgestelltes Stück.

Die Zustelladresse ist davon ausgenommen. Sie steht nicht auf der Karte, sondern ist allein das Ziel des Versands. Sie lässt sich deshalb auch nach dem Ausstellen ändern — über „An andere Adresse senden" auf dem Bildschirm „Zustellung" —, ohne dass sich das Dokument um ein Zeichen ändert.

Ausnahme: die hochgeladenen Bildmotive. Für sie gibt es in der App keine Löschmöglichkeit — weder für ein einzelnes Bild noch für alle. Verlangt der Händler die Entfernung eines Motivs, etwa weil darauf eine Person zu sehen ist, die widersprochen hat, genügt eine Nachricht in Textform an datenschutz@kyth.systems; KYTH entfernt das Objekt und seine Zeile von Hand und bestätigt das. Bis eine Löschfunktion in der App besteht, ist das der einzige Weg.

7.4 Aufwand

Die Unterstützung nach diesem Paragraphen erbringt KYTH unentgeltlich, im Rahmen dessen, was Art. 28 Abs. 3 lit. e DSGVO verlangt. Eine Vergütung für darüber hinausgehenden Aufwand ist nicht vereinbart und wird nicht verlangt.

§ 8 Unterstützung bei Sicherheit, Datenpannen und Datenschutz-Folgenabschätzung

8.1 Sicherheit der Verarbeitung (Art. 32 DSGVO)

KYTH unterhält die in Anlage 2 beschriebenen Maßnahmen und überprüft sie anlassbezogen, insbesondere bei jeder Erweiterung des Funktionsumfangs.

8.2 Verletzungen des Schutzes personenbezogener Daten (Art. 33, 34 DSGVO)

KYTH meldet dem Händler jede Verletzung des Schutzes personenbezogener Daten, die Daten aus dessen Shop betrifft, unverzüglich nach Bekanntwerden in Textform an die vom Händler nach § 2a Nr. 4 hinterlegte Kontaktadresse. Die Meldung enthält, soweit bekannt:

• Beschreibung der Art der Verletzung, die Kategorien und die ungefähre Zahl der betroffenen Personen und Datensätze,
• Kontaktstelle für weitere Auskünfte (datenschutz@kyth.systems),
• die wahrscheinlichen Folgen,
• die ergriffenen und die vorgeschlagenen Gegenmaßnahmen.

Sind noch nicht alle Angaben verfügbar, meldet KYTH zunächst den bekannten Sachverhalt und liefert das Übrige unverzüglich nach. Die Meldung an die Aufsichtsbehörde und die Benachrichtigung betroffener Personen obliegen dem Händler (§ 2a Nr. 6); KYTH unterstützt ihn dabei mit den vorliegenden Informationen.

Grenze dieser Zusage. Der Kanal zum Händler steht, weil die Kontaktadresse beim Vertragsschluss erhoben wird (§ 0.2, § 2a Nr. 4). Er hängt aber daran, dass der Händler sie aktuell hält. Ist die hinterlegte Adresse unzustellbar geworden, kann KYTH ihn nicht mehr unmittelbar erreichen; KYTH veröffentlicht die Meldung dann unter https://kartuu.kyth.systems/rechtliches/auftragsverarbeitung und weist in der eingebetteten Oberfläche darauf hin. Das ersetzt eine unmittelbare Benachrichtigung nicht — die 72-Stunden-Frist des Händlers nach Art. 33 Abs. 1 DSGVO lässt sich auf diesem Weg nicht zuverlässig wahren.

KYTH unterhält einen dokumentierten Ablaufplan für Sicherheitsvorfälle mit Eskalationsstufen, benannten Zuständigkeiten, der 72-Stunden-Frist des Art. 33 DSGVO und der zuständigen Aufsichtsbehörde (Bayerisches Landesamt für Datenschutzaufsicht, BayLDA).

8.3 Datenschutz-Folgenabschätzung und vorherige Konsultation (Art. 35, 36 DSGVO)

Führt der Händler eine Datenschutz-Folgenabschätzung durch oder konsultiert er die Aufsichtsbehörde, stellt KYTH auf Anfrage die dafür erforderlichen Informationen über die Verarbeitung durch Kartuu zur Verfügung — insbesondere die Anlagen 1 und 2 dieses Vertrages sowie Auskunft über die eingesetzten Unterauftragsverarbeiter.

§ 9 Löschung oder Rückgabe nach Ende der Verarbeitung

9.1 Was wann geschieht

Die zu leerenden Tabellen werden dabei nicht aus einer gepflegten Liste, sondern zur Laufzeit aus dem Datenbankkatalog ermittelt. Erfasst werden alle Tabellen im Schema public, die eine Spalte mit dem Namen shop_id tragen; der heutige Datenbestand fällt vollständig darunter. Der Aufräumlauf nach 9.3 Nr. 1 benutzt genau denselben Pfad. Fremdschlüssel zwischen diesen Tabellen werden erst am Ende der Transaktion geprüft, damit die Löschung in jeder Reihenfolge gelingt.

Die Bytes der hochgeladenen Bildmotive liegen nicht in der Datenbank, sondern in der Bildablage (§ 6.3); sie werden auf einem eigenen Weg gelöscht, siehe 9.3 Nr. 6.

9.2 Löschung oder Rückgabe — der Händler wählt

Nach Beendigung der Verarbeitung löscht KYTH sämtliche Daten des Händlers oder gibt sie nach Wahl des Händlers heraus (Art. 28 Abs. 3 lit. g DSGVO).

Die Wahl gehört vor die Deinstallation. Shopify fordert die Löschung in der Regel 48 Stunden nach der Deinstallation an, und KYTH führt sie dann aus (§ 9.1). Verlangt der Händler die Herausgabe, teilt er das deshalb vor der Deinstallation in Textform an datenschutz@kyth.systems mit und deinstalliert die App erst, nachdem er die Daten erhalten hat. Eine Mitteilung nach der Deinstallation kann KYTH nur erfüllen, solange die Daten noch nicht gelöscht sind. Ohne Mitteilung löscht KYTH.

Verlangt der Händler die Herausgabe, stellt KYTH die zu seinem Shop gespeicherten Daten innerhalb von 14 Tagen nach Zugang der Mitteilung in einem gängigen maschinenlesbaren Format (JSON) bereit. Eine automatische Ausleitung ist nicht umgesetzt; KYTH stellt die Daten in diesem Fall von Hand zusammen.

Zur Einordnung: Zu den technischen Daten des Shops — Shop-Domain, deren Hash, verschlüsselte Zugangstoken, verschlüsselte Kontaktadresse, Zustimmungsnachweis, zuletzt gelesener Abonnementstand, technische Zeitstempel und die Einträge des Protokolls über Zugriffe auf geschützte Kundendaten — gilt: Die Zugangstoken sind nach der Deinstallation ungültig. Die Wahl bleibt beim Händler.

Gutscheindaten. Verlangt der Händler die Herausgabe, gibt KYTH sie in JSON heraus, mit den verschlüsselten Feldern entschlüsselt. Der Gutscheincode gehört ausdrücklich dazu. Die Herausgabe geht ausschließlich an den Händler als Verantwortlichen und ausschließlich an die nach § 2a Nr. 4 hinterlegte Kontaktadresse.

Hochgeladene Bildmotive. Verlangt der Händler die Herausgabe, gibt KYTH sie als Dateien heraus — im hochgeladenen Format, also nicht in JSON verpackt. Eine Ausnahme gilt für SVG-Motive: Herausgegeben wird die bereinigte Fassung, denn nur die ist gespeichert (Anlage 2 Abschnitt 2.6). Die Ausgangsdatei liegt beim Händler und ist bei KYTH zu keinem Zeitpunkt aufbewahrt worden.

9.3 Vernichtung vorhandener Kopien — verbindliche Fristen

Art. 28 Abs. 3 lit. g DSGVO verlangt, dass KYTH nach Beendigung der Verarbeitung auch die vorhandenen Kopien vernichtet, soweit keine gesetzliche Aufbewahrungspflicht besteht. KYTH sagt dafür die folgenden Fristen zu.

Übersicht:

1. Wenn shop/redact ausbleibt: 30 Tage. Bleibt der Webhook aus — die Zustellung geht verloren, der Endpunkt ist vorübergehend nicht erreichbar, Shopify meldet ihn nie —, löscht ein Aufräumlauf die Shop-Zeile 30 Tage nach dem Deinstallationszeitpunkt vollständig, über denselben Löschpfad wie shop/redact. Wer die App versehentlich deinstalliert und bald neu installiert, behält so Zustimmung und Kontaktadresse. Zweiter Fall desselben Aufräumlaufs: nie zustande gekommene Verbindungen — 90 Tage. Scheitert nach der Zustimmung der Abruf des Zugangstokens bei Shopify, gibt es keinen Deinstallationszeitpunkt. Derselbe Aufräumlauf löscht deshalb über denselben Löschpfad einen Datensatz, der keinen Deinstallationszeitpunkt trägt, kein Zugangs- und kein Erneuerungstoken hat und dessen letztes Lebenszeichen länger als 90 Tage zurückliegt.

Schlüsselwechsel. Nach jedem Schlüsselwechsel werden die Suchhashes neu berechnet, damit eine Deinstallationsmeldung ihren Shop weiterhin findet.

Der Aufräumlauf startet mit der Anwendung und ruft beide Regeln alle 24 Stunden auf; denselben Lauf benutzen Nr. 3 und Nr. 7. 2. Sicherungen: 30 Tage auf dem Server, 95 Tage im Objektspeicher — davon 90 Tage unlöschbar. Es wird täglich nachts eine vollständige Sicherung der Datenbank erstellt und mit AES-256 verschlüsselt, bevor sie den Server verlässt. Sie liegt auf dem Server und im Objektspeicher der IONOS in Berlin, im Eimer kaspar-kyth-db-backup-worm.

Auf dem Server: 30 Tage. Das setzt das Sicherungsskript selbst durch, bei jedem Lauf.

Im Objektspeicher wirken zwei Mechanismen nacheinander. Zuerst ist die Sicherung durch Object Lock im COMPLIANCE-Modus 90 Tage lang für niemanden löschbar — auch nicht für KYTH selbst und auch nicht für jemanden, der den Server samt Zugangsdaten übernimmt. Danach löscht eine Lebenszyklusregel des Eimers (sicherungen-nach-95-tagen-loeschen, gesamter Eimer, 95 Tage nach Erstellung und ebenso 95 Tage für nicht mehr aktuelle Versionen) sie auf Speicherebene. Die fünf Tage Abstand sorgen dafür, dass die Löschung nicht auf eine noch gesperrte Sicherung trifft.

Das Sicherungsskript löscht im Objektspeicher nichts; aufgeräumt wird dort ausschließlich über die Lebenszyklusregel des Eimers.

Der Abzug ist verschlüsselt. Er wird symmetrisch mit AES-256 verschlüsselt, bevor er den Server verlässt; das Kennwort liegt auf dem Server und nicht im Objektspeicher. Die Übertragung zum Objektspeicher erfolgt mit TLS 1.3. Innerhalb der Sicherung liegen die schutzbedürftigen Felder zusätzlich feldweise mit AES-256-GCM verschlüsselt; der Schlüssel dafür steht allein in der Umgebung der Anwendung auf dem Server, nicht in der Sicherung und nicht im Objektspeicher. Die Wiederherstellbarkeit ist durch eine tatsächliche Wiederherstellung geprüft, und ein täglicher Prüflauf meldet ausgebliebene Sicherungen.

Gelöschte Daten in Sicherungen. Wird ein Shop gelöscht — durch shop/redact, durch den Aufräumlauf nach Nr. 1 oder auf Verlangen des Händlers —, bleiben seine Daten in bereits erstellten Sicherungen enthalten und verschwinden von dort erst mit dem Ablauf der genannten Fristen: spätestens 30 Tage später auf dem Server, spätestens 95 Tage später im Objektspeicher. Einzelne Datensätze werden aus vorhandenen Sicherungen nicht herausgeschnitten. Solange die Daten dort liegen, werden sie ausschließlich zur Wiederherstellung im Störungsfall verwendet. 3. Technische Webhook-Kennungen: 30 Tage nach Abschluss. Die Tabelle mit den Kennungen eingehender Webhooks (Duplikatschutz) trägt keine Shop-Zuordnung und wird vom Löschvorgang des Shops nicht erfasst. Ein eigener Aufräumlauf entfernt einen abgeschlossenen Eintrag 30 Tage nach seinem Abschluss. Inhaltlich sind das ausschließlich von Shopify vergebene technische Kennungen ohne Personenbezug. Einträge, deren Verarbeitung nie abgeschlossen wurde, bleiben stehen, damit derselbe Webhook nicht ein zweites Mal verarbeitet wird; auch sie haben keinen Personenbezug. 4. Anwendungs- und Containerprotokolle: 14 Tage. Sie enthalten die Shop-Domain, die interne Shop-Kennung, im Bestellablauf zusätzlich Bestell-, Positions- und Gutscheinkennung sowie den Fehlergrund als kurze eigene Kennung, und den Typ aufgetretener Ausnahmen — keine Token, keine Kontaktadresse, keinen Gutscheincode, keinen Empfänger- oder Absendernamen, keinen Grußtext und keine Kundenadresse. Nach 14 Tagen werden sie verworfen. Die Frist ist im Betriebswerkzeug eingestellt. 5. Protokoll über Zugriffe auf geschützte Kundendaten. Es trägt eine Shop-Zuordnung und verschwindet vollständig mit dem Shop — über shop/redact und über den Aufräumlauf nach Nr. 1. Eine eigene, kürzere Frist gibt es nicht, weil das Protokoll als Nachweis gegenüber Shopify dient. 6. Hochgeladene Bildmotive: mit shop/redact, und zwar vor allem anderen. Die Bildmotive haben keine eigene Frist. Sie werden aufbewahrt, solange der Händler die App benutzt, und mit dem Shop gelöscht.

Wie gelöscht wird. Jedes Objekt eines Shops liegt unter einem Schlüssel, der mit der Kennung dieses Shops beginnt. Gelöscht wird alles unter diesem Anfang — auch ein Objekt, dessen Upload abgebrochen ist, bevor seine Zeile geschrieben war. Die Objekte werden vor den Datenbankzeilen gelöscht; scheitert das, bleibt der Shop bestehen, und die Löschung wird wiederholt.

a) Der Aufräumlauf nach Nr. 1 geht denselben Weg, in derselben Reihenfolge: zuerst die Objekte, dann die Datenbankzeilen.

b) Nicht mehr genutzte Motive werden nicht aufgeräumt. Lädt ein Händler ein Motiv hoch und benutzt es nie oder nicht mehr, bleibt es liegen, solange sein Shop besteht. Eine Stelle in der App, an der ein Händler ein einzelnes Bild löschen kann, gibt es nicht. Wer das verlangt, wendet sich an datenschutz@kyth.systems (§ 7.3); die Löschung erfolgt dann von Hand. 7. Gutscheine: personenbezogene Angaben drei Jahre nach dem Anlegen. Drei Jahre nach dem Anlegen eines Gutscheins werden seine personenbezogenen Angaben geleert: Empfänger, dessen Adresse und deren Suchwert, Absender, Grußtext, Käufer, dessen Adresse samt Suchwert und die Kundennummer. Der Gutschein selbst bleibt bestehen — Code, Zustand und Wert —, denn er ist der Beleg über eine eingegangene Verpflichtung. Die Frist entspricht der Regelverjährung des Anspruchs aus dem Gutschein (§ 195 BGB); Buchungsbelege führt der Händler in seinem Shopify-Konto. Ausgeführt wird das täglich vom selben Aufräumlauf wie Nr. 1 und Nr. 3. Der Abruflink eines Gutscheins gilt nicht länger als diese Frist.

Die Zeilen tragen eine Shop-Zuordnung und verschwinden vollständig mit dem Shop, über shop/redact wie über den Aufräumlauf nach Nr. 1.

a) Die Löschung einer einzelnen Person löscht die Zeile nicht. Sie leert die personenbezogenen Felder und lässt Code, Zustand, Wert und Vorlagenabbild stehen (§ 7.2), weil der Gutschein bezahlt ist und eingelöst werden kann.

b) Für die beschenkte Person gibt es keinen Auslöser über Shopify. Verlangt sie die Löschung vor Ablauf der Frist, führt KYTH sie auf Weisung des Händlers von Hand aus (§ 7.2).

9.4 Gesetzliche Aufbewahrung

Besteht ausnahmsweise eine gesetzliche Pflicht zur weiteren Aufbewahrung, unterbleibt insoweit die Löschung; die Daten werden in ihrer Verarbeitung eingeschränkt und ausschließlich zu diesem Zweck verwendet. KYTH teilt dem Händler eine solche Aufbewahrung mit.

§ 10 Nachweise und Prüfrechte des Verantwortlichen

10.1 Nachweise

KYTH stellt dem Händler auf Anfrage an datenschutz@kyth.systems alle Informationen zur Verfügung, die zum Nachweis der Einhaltung der Pflichten aus Art. 28 DSGVO erforderlich sind. Regelmäßig genügen dafür:

• dieser Vertrag mit Anlage 1 (Verarbeitungsübersicht) und Anlage 2 (technische und organisatorische Maßnahmen),
• die aktuelle Liste der Unterauftragsverarbeiter,
• der Ablaufplan für Sicherheitsvorfälle,
• Auskunft über die zum Shop des Händlers gespeicherten Daten.

10.2 Prüfungen

Reichen diese Nachweise im Einzelfall nicht aus, ermöglicht KYTH Überprüfungen einschließlich Inspektionen und trägt zu ihnen bei (Art. 28 Abs. 3 lit. h DSGVO). Der Händler kann die Prüfung selbst durchführen oder einen von ihm beauftragten Prüfer einsetzen, der nicht in Wettbewerb zu KYTH steht und zur Verschwiegenheit verpflichtet ist.

Prüfungen erfolgen nach Ankündigung mit angemessenem Vorlauf — in der Regel 30 Tage —, zu üblichen Geschäftszeiten, ohne Störung des Betriebsablaufs und höchstens einmal je Kalenderjahr; bei einem konkreten Anlass, insbesondere nach einer Verletzung des Schutzes personenbezogener Daten oder auf Verlangen einer Aufsichtsbehörde, auch darüber hinaus und kurzfristig.

10.3 Was eine Prüfung nicht umfassen kann

• Zertifikate: KYTH hält keine. Es kann kein Prüfbericht vorgelegt werden, den es nicht gibt (siehe § 5).
• Rechenzentrum: Die Serverinfrastruktur ist bei der IONOS SE angemietet. Eine Prüfung vor Ort im Rechenzentrum kann KYTH nicht gewähren; hierfür ist auf die Nachweise und Zertifizierungen von IONOS zu verweisen.
• Daten anderer Händler: Eine Prüfung darf nicht dazu führen, dass der Prüfer Zugang zu Daten anderer Händler erhält. KYTH wird Zugriffe entsprechend beschränken.

10.4 Behörden

KYTH unterstützt den Händler bei Prüfungen durch die zuständige Aufsichtsbehörde und erteilt dieser auf Verlangen unmittelbar Auskunft (Art. 31 DSGVO). KYTH informiert den Händler unverzüglich über behördliche Maßnahmen, die dessen Daten betreffen, soweit das rechtlich zulässig ist.

§ 11 Rangfolge und Schlussbestimmungen

1. Dieser Vertrag geht den übrigen Vertragsbedingungen zwischen den Parteien vor, soweit es um die Verarbeitung personenbezogener Daten im Auftrag geht.
2. Die Anlagen 1 und 2 sind Bestandteil dieses Vertrages.
3. Änderungen und Ergänzungen bedürfen der Textform. Das gilt auch für die Aufhebung dieses Formerfordernisses.
4. Ist eine Bestimmung unwirksam, bleibt der übrige Vertrag wirksam. Die Parteien ersetzen die unwirksame Bestimmung durch eine wirksame, die dem verfolgten Zweck am nächsten kommt.
5. Es gilt deutsches Recht. Gerichtsstand ist, soweit gesetzlich zulässig, der Sitz von KYTH.
6. Fortschreibungspflicht: Vertrag und Anlagen geben den im Kopf genannten Stand der Software wieder. Vor jeder Erweiterung, die den Kreis der verarbeiteten Daten verändert, werden Anlage 1 und Anlage 2 neu erhoben und der Vertrag nach § 0.3 in neuer Fassung vorgelegt.

§ 12 Was Sie als Händler tun müssen

Die Pflichten aus § 2a stehen dort im Vertragston. Hier stehen sie noch einmal kurz und im Klartext, damit Sie nach dem Lesen wissen, was Sie übernommen haben.

1. Halten Sie Ihre Kontaktadresse aktuell. Die E-Mail-Adresse, die Sie beim Verbinden der App angegeben haben, ist unser einziger Weg zu Ihnen — bei einer Datenpanne, bei einer Vertragsänderung, bei einem Wechsel eines Unterauftragsverarbeiters. Ändert sie sich, schreiben Sie uns an datenschutz@kyth.systems. Wird sie unzustellbar, erreichen wir Sie nicht mehr, und die 72 Stunden aus Art. 33 Abs. 1 DSGVO laufen trotzdem (§ 2a Nr. 4, § 8.2).
2. Sorgen Sie für die Rechtsgrundlage. Für die Verarbeitung der Daten Ihrer Kundschaft brauchen Sie eine Rechtsgrundlage nach Art. 6 DSGVO. Wir prüfen sie nicht und können sie nicht prüfen.
3. Informieren Sie Ihre Kundschaft und die Beschenkten. Die Informationspflichten nach Art. 13 und Art. 14 DSGVO treffen Sie, nicht uns. Beschenkte geben ihre Daten nicht selbst — dafür gilt Art. 14 DSGVO. Nehmen Sie Kartuu in Ihre eigene Datenschutzerklärung auf.
4. Beantworten Sie Anfragen betroffener Personen selbst. Wendet sich jemand an uns, leiten wir die Anfrage an Sie weiter und beantworten sie nicht (§ 7.1).
5. Melden Sie Datenpannen selbst an Ihre Aufsichtsbehörde. Wir melden Ihnen den Vorfall; die Meldung nach Art. 33 DSGVO und die Benachrichtigung der Betroffenen nach Art. 34 DSGVO machen Sie (§ 8.2).
6. Erteilen Sie Weisungen in Textform. Einzelweisungen gehen an datenschutz@kyth.systems. Was Sie mündlich sagen, bestätigen Sie uns bitte unverzüglich in Textform (§ 3.2).

Anlage 1 — Verarbeitungsübersicht

Gibt den im Kopf genannten Stand der Software wieder. Nachweise zu einzelnen Angaben erhält der Händler nach § 10 auf Anfrage an datenschutz@kyth.systems; einer Aufsichtsbehörde legt KYTH sie auf Verlangen vor (Art. 31 DSGVO).

Angaben nach Art. 30 Abs. 2 DSGVO

Die vollständigen Firmendaten des Händlers (Firmierung, Anschrift, Vertretung) erhebt KYTH nicht; sie ergeben sich aus dem Shopify-Konto des Händlers und werden bei einer Anfrage nach Art. 31 DSGVO über die hinterlegte Kontaktadresse erfragt.

Garantien nach Art. 30 Abs. 2 lit. c DSGVO. Für Übermittlungen an Shopify-Stellen außerhalb des EWR: die EU-Standardvertragsklauseln nach Durchführungsbeschluss (EU) 2021/914, einbezogen über Shopifys Data Processing Addendum in der Fassung vom 07.07.2026. Für Kanada daneben der Angemessenheitsbeschluss 2002/2/EG. Einzelheiten stehen in § 3.4.

A. Tatsächlich gespeicherte Daten

Die genannten Daten liegen in der PostgreSQL-Datenbank auf dem Server in Berlin und gehen in die Sicherungen nach § 9.3 Nr. 2 ein — mit einer Ausnahme: Von den hochgeladenen Bildmotiven steht nur die Beschreibung in der Datenbank. Die Bytes liegen in der Bildablage (§ 6.3) und sind nicht Teil der Datenbanksicherung. Für sie gibt es keine Sicherung; geht die Ablage verloren, sind sie weg.

B. Nur flüchtig berührte Daten — keine Speicherung

C. Nicht verarbeitet

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

Gibt den im Kopf genannten Stand der Software wieder. Aufgeführt sind ausschließlich umgesetzte Maßnahmen; Abschnitt 7 benennt die bekannten Lücken.

1. Vertraulichkeit

1.1 Verschlüsselung gespeicherter Daten

• Mit AES-256-GCM verschlüsselt gespeichert werden: Access-Token, Refresh-Token, die Kontaktadresse des Händlers, Benutzername und Passwort seines Mailzugangs sowie der Gutscheincode, der Abruf-Token, der Empfängername, die E-Mail-Adresse des Beschenkten, der Absendername, der Grußtext und Name und E-Mail-Adresse des Käufers. Jedes Chiffrat trägt eine Schlüsselkennung, und diese Kennung ist kryptografisch an das Chiffrat gebunden — ein nachträgliches Umschreiben der Kennung fällt beim Entschlüsseln auf.
• Die Datenbank lässt Klartext in einer verschlüsselten Spalte nicht zu. Jede dieser Spalten trägt eine Prüfregel auf das Chiffratformat, jede Suchwertspalte eine auf genau 64 Hexzeichen.
• Suchwerte statt Klartext, wo gesucht werden muss. Gutscheincode, Abruf-Token und die E-Mail-Adressen von Beschenktem und Käufer tragen je einen nicht umkehrbaren Suchwert (HMAC-SHA256) neben dem Chiffrat. Die Shopify-Kundennummer des Käufers liegt im Klartext, weil sie der Suchschlüssel der beiden Datenschutz-Webhooks ist.
• Was gegenüber Shopify nicht preisgegeben wird. Die Notiz, die beim Anlegen einer Geschenkkarte an ihr hinterlegt wird, enthält keine Personendaten. Wer beschenkt wird, steht in der verschlüsselten Spalte bei KYTH und nicht in einem Freitextfeld bei Shopify.
• Der Schlüssel stammt ausschließlich aus einer Umgebungsvariablen; je Umgebung ein eigener. Es gibt keinen Betriebsmodus, in dem die Verschlüsselung abschaltbar wäre.
• Der Suchhash nutzt nicht den rohen Verschlüsselungsschlüssel, sondern einen davon abgeleiteten eigenen Schlüssel (Trennung der Einsatzzwecke).
• Die Feldverschlüsselung wirkt auch innerhalb der Datenbanksicherungen; der Schlüssel liegt nicht in der Sicherung und nicht im Objektspeicher. Siehe § 9.3 Nr. 2.

1.2 Trennung der Mandanten

• Jede Tabelle mit einer Shop-Kennung (shop_id) ist mit Zeilenschutz auf Datenbankebene (Row-Level-Security, mit ENABLE und FORCE) und genau einer Richtlinie über den gesetzten Mandanten versehen. Ohne gesetzten Mandanten liefert die Datenbank für diese Tabellen keine Zeile — kein Mandant, kein Zugriff.
• Die Tabelle shops selbst trägt keinen Zeilenschutz. Sie hat keine shop_id-Spalte, sondern ist die Shop-Tabelle; die Anwendungsrolle hat auf ihr SELECT über alle Zeilen und DELETE. Die Mandantentrennung wirkt dort über die Anwendung — jede Abfrage filtert über den Suchhash der Shop-Domain — und über spaltenweise Rechte (1.3). Siehe Abschnitt 7.
• Die Anwendung verbindet sich mit einer entrechteten Datenbankrolle, die den Zeilenschutz nicht umgehen darf und ausdrücklich nicht Eigentümerin der Tabellen ist.
• Fehlt diese Rolle im Betrieb oder ist sie mit der Verwaltungsrolle identisch, bricht die Anwendung den Start ab, statt ohne wirksame Mandantentrennung zu laufen.
• Die Datenzugriffsschicht kann ohne Mandantenangabe keine Abfrage bilden. Tabellennamen werden gegen eine Freigabeliste und ein festes Namensmuster geprüft, Werte ausschließlich als Parameter übergeben; ein rohes SQL-Fragment lässt sich nicht übergeben.
• In der Bildablage trennt der Namensraum selbst. Der Schlüssel eines Bildes beginnt mit der Kennung seines Shops. Zwei Händler, die dasselbe Motiv hochladen, bekommen deshalb zwei verschiedene Schlüssel und zwei getrennte Dateien. Jeder Schlüssel wird an jeder Stelle gegen ein vollständig verankertes Muster geprüft, bevor daraus ein Pfad wird; die Dateiablage prüft zusätzlich, dass der aufgelöste Pfad unterhalb ihres Wurzelverzeichnisses liegt. Eine allgemein lesbare Adresse gibt es nicht. Ein Bild wird entweder nach Prüfung der Sitzung des Händlers ausgeliefert oder über eine signierte Adresse, deren Signatur Shop, Schlüssel und ein Zeitfenster aneinanderbindet; sie gilt ein bis zwei Stunden. Die Route reicht die signierte Shop-Kennung an die Ablage weiter, und die Ablage lehnt jeden Schlüssel außerhalb dieses Shops ab. Solche Adressen stehen in der Vorschau im Adminbereich und in der Kartenvorschau auf der Produktseite (Anlage 1 Abschnitt B).

1.3 Rechte auf das Nötigste beschränkt

Datenbankrechte sind spaltenweise statt tabellenweit vergeben:

• Ändern der Shop-Tabelle nur auf einzeln freigegebenen Spalten: Token samt Ablauf, Rotation und Berechtigungsumfang, Deinstallationszeitpunkt, Kontaktadresse, Zustimmung, Abonnementstand, eingelöster Aktionscode, Versandweg, Auftritt auf der Karte, Hausfarben, Sprache der Gutscheine, Einrichtungsstand, Stand der Bewertungsfrage, die Zeitpunkte der gesehenen Themeblöcke und der letzten Händlermeldung — nicht auf Shop-Domain, deren Suchhash und dem Installationszeitpunkt,
• Anlegen eines Shops nur mit Domain und Hash,
• Lesen der Webhook-Kennungen nur auf den tatsächlich gelesenen Spalten,
• Anlegen einer Bildzeile nur auf den sieben tatsächlich geschriebenen Spalten — nicht auf der laufenden Nummer und nicht auf dem Zeitpunkt des Hochladens, den die Datenbank selbst setzt,
• kein Änderungsrecht auf dem Protokoll über Zugriffe auf geschützte Kundendaten, damit Einträge nachträglich nicht veränderbar sind — und aus einem anderen Grund auch keines auf den Bildzeilen: Der Schlüssel ist die Prüfsumme des Inhalts, eine geänderte Zeile beschriebe also ein anderes Objekt unter derselben Adresse.

Bei den Gutscheinen:

• Ein Gutschein kann nicht als „bereit" entstehen. Die Anwendungsrolle hat beim Anlegen kein Recht auf den Zustand und auf den Zeitpunkt des Zustandswechsels, und ebenso wenig auf Code, Geschenkkartenkennung oder Vorlagenabbild; diese entstehen erst in späteren Schritten des Ablaufs.
• Die Identität eines Gutscheins ist unveränderlich. Auf Shop, Bestellung, Position, laufender Nummer, Art, Vorlage und Abruf-Token gibt es kein Änderungsrecht. So bleibt die Wiederholungsfestigkeit erhalten, und ein bereits zugestellter Abruflink zeigt nicht ins Leere.
• Kein Änderungsrecht auf der Zuordnung der Bildmotive, und auf den Gutscheinprodukten nur für den Stand des Produktbilds. Welche Bilder in einer ausgestellten Karte stecken, bleibt fest. Ein angelegtes Produkt gehört dem Händler; Kartuu gleicht es nicht nachträglich ab.

1.4 Keine Geheimnisse an falscher Stelle

• Weder Access-, noch Refresh-, noch Sitzungstoken werden protokolliert — auch nicht gekürzt. Dasselbe gilt für die Kontaktadresse des Händlers und für Gutscheincode, Abruf-Token, Empfänger- und Absendername, Grußtext und die E-Mail-Adressen der Kundschaft. Geloggt werden aus dem Bestellablauf ausschließlich Shopdomain, Bestell-, Positions- und Gutscheinkennung, die Anzahl angelegter Gutscheine, der erreichte Zustand und der Fehlergrund als kurze eigene Kennung. Im Fehlerfall wird in der Regel nur der Ausnahmetyp geschrieben; die Ausnahmen davon stehen im übernächsten Punkt.
• Auch die Antworten von Shopify werden nicht im Wortlaut protokolliert. Lehnt Shopify das Anlegen einer Geschenkkarte oder eines Produkts ab, werden ausschließlich die Fehlerkennung und der Feldpfad übernommen — beides Namen aus dem GraphQL-Schema.
• Wo zusätzlich die Meldung geschrieben wird: Scheitert der Token-Tausch mit Shopify vorübergehend, steht eine Meldung aus eigenem Text, HTTP-Statuscode, Ausnahmetyp, Zeilenzahl und Shop-Domain im Protokoll. Außerdem die Meldungen eigener Fehlerklassen, wenn eine Kartengestaltung nicht geprüft oder gerendert werden kann (mit dem Namen des betroffenen Feldes oder dem Bildschlüssel), wenn ein Bild beim Hochladen abgelehnt wird (der Grund: Format, Maße, Ergebnis der SVG-Bereinigung), wenn die Bildablage nicht erreichbar ist, und die Meldung der Ausnahme, wenn ein Schritt des täglichen Aufräumlaufs scheitert. Token, Kontaktadressen, Gutscheincodes sowie Namen, Grußtexte und E-Mail-Adressen der Kundschaft stehen darin nicht im Klartext. Die Meldungen dienen dazu, die Ursache einer Störung einzugrenzen.
• Ein Prüflauf gegen versehentlich eingecheckte Geheimnisse (gitleaks) läuft als Git-Haken automatisch vor jeder Übernahme in die Versionsverwaltung und prüft die vorgemerkten Änderungen; ist das Werkzeug nicht eingerichtet, wird die Übernahme abgebrochen. Die lokale Prüfroutine durchsucht zusätzlich den gesamten Verlauf. Die Umgebungsdatei ist von Repository und Container-Abbild ausgeschlossen.
• Zugangsgeheimnisse liegen ausschließlich in der Bereitstellungsumgebung.

1.5 Protokoll über Zugriffe auf geschützte Kundendaten

Das Protokoll ist inhaltsfrei: Die zulässigen Werte für Akteur und Feldkategorie sind doppelt abgesichert (Prüfung im Code und Prüfregel in der Datenbank). Ein Fehler beim Protokollieren bringt den fachlichen Aufruf nicht zu Fall.

Einträge entstehen unter anderem bei der Entgegennahme einer bezahlten Bestellung und bei den Datenschutz-Webhooks. Vermerkt werden nur die tatsächlich berührten Kategorien; eine Bestellung ohne jede Personenangabe schreibt keinen Eintrag. Der Eintrag zur Bestellung entsteht beim Entgegennehmen und nicht beim Rendern, sodass ein Wiederholungslauf keinen zweiten Eintrag über denselben Zugriff erzeugt.

2. Integrität

2.1 Prüfung eingehender Aufrufe

• Webhooks: HMAC-SHA256 über den rohen Inhalt, Vergleich in konstanter Zeit, Ablehnung mit Statuscode 401 bei Fehlern — und zwar vor jeder weiteren Verarbeitung.
• Sitzungstoken: Prüfung mit erzwungenem Signaturverfahren, Vergleich in konstanter Zeit, enge Toleranz bei Gültigkeitszeitpunkten, Wiedereinspielfenster von 70 Sekunden, Prüfung des Adressaten gegen die eigene Anwendungskennung sowie Kreuzprüfung von Aussteller und Ziel einschließlich Schutz vor eingeschleusten Benutzerangaben im Hostnamen.
• Anfragen aus dem Shop (Kartenvorschau auf der Produktseite) kommen über den App-Proxy von Shopify und werden an ihrer Signatur geprüft; die Anfragen des Kartuu-Blocks auf Danke- und Bestellstatusseite tragen ein von Shopify ausgestelltes Sitzungsmerkmal. Geprüft werden Signatur, Adressat (die eigene Anwendungskennung), Ziel (der Shop, aus dem auch die Mandantenzuordnung stammt) und Gültigkeit. Zwei Abweichungen gegenüber dem Sitzungstoken des Adminbereichs: Das Merkmal trägt keinen Aussteller — der Shop ist allein über Signatur und Ziel belegt —, und es darf bis zu 330 Sekunden alt sein statt 70, weil die Erweiterung dasselbe Merkmal bis zu fünf Minuten lang wiederverwendet.
• Abrufseite der Gutscheine (Adressen unter /gutschein): Vor der Anwendung bremst der Reverse-Proxy die Anfragen je IP-Adresse — im Mittel eine je Sekunde, bis zu 20 auf einmal. Die Adresse steht dafür nur im Arbeitsspeicher und wird zwei Sekunden nach ihrer letzten Anfrage verworfen. Dahinter begrenzt die Anwendung die Abrufe je Shop, gesondert die Anfragen, die zu keinem Gutschein führen, und das Erzeugen des PDF über alle Shops.

2.2 Absicherung der eingebetteten Oberfläche

Sicherheitskopfzeilen: Inhaltsrichtlinie (Content-Security-Policy) mit dynamischer Einbettungsbeschränkung, deren Shop-Parameter gegen ein vollständig verankertes Muster geprüft wird und bei mehrfacher Angabe abweisend reagiert; X-Content-Type-Options; Referrer-Policy: strict-origin-when-cross-origin.

2.3 Angriffsfläche klein halten

Schema-Beschreibung und interaktive Dokumentation der Schnittstelle sind im Produktivbetrieb abgeschaltet (die Routen existieren dort nicht).

2.4 Prüfung der Eingaben des Zustimmungsschritts

Die im Zustimmungsschritt eingegebene Kontaktadresse wird serverseitig gegen ein vollständig verankertes Muster geprüft (keine Zeilenumbrüche, keine Trennzeichen, kein spitzklammerartiger Anhang, Domäne mit Punkt, Längenbegrenzung), Randleerzeichen werden entfernt, die Groß- und Kleinschreibung bleibt erhalten. Die Zustimmung muss als echter Wahrheitswert übermittelt werden — Zeichenketten oder Zahlen gelten nicht als Zustimmung.

Begrenzung des Anfragekörpers. Der Körper dieser Anfrage darf 4 Kilobyte nicht überschreiten. Die Grenze wirkt an zwei Stellen: vorab gegen die vom Aufrufer angekündigte Länge und während des Einlesens selbst, das abgebrochen wird, sobald die Grenze überschritten ist — auch dann, wenn eine Anfrage ihre Länge verschweigt.

Derselbe Mechanismus an den übrigen Anfragen mit Körper, jeweils mit einem eigenen Deckel: 256 Kilobyte an den Renderaufrufen (Vorschau und PDF) und beim Sichern eines Entwurfs, weil der Körper dort das vollständige Gestaltungsdokument trägt; deutlich weniger an allen anderen. Alle Grenzen stammen aus einer gemeinsamen Umsetzung. Ein Körper über dem Deckel endet in einer Ablehnung und nicht in einer Antwort mit leeren Werten.

2.5 Prüfung der Eingaben des Gutschein-Editors

Texte und Gestaltungen aus dem Editor werden serverseitig geprüft, bevor daraus ein Dokument entsteht; auf eine Prüfung im Browser verlässt sich der Server dabei nicht.

• Erlaubnislisten statt freier Werte, und Ablehnung statt stiller Ersetzung. Fest vorgegeben sind die wählbare Vorlage, das Blattformat, der Ebenentyp, die Fläche der Klappkarte, die Ausrichtung, die Schrift und die zulässigen Platzhalternamen. Ein unbekannter Wert wird abgelehnt, ebenso ein unbekannter Schlüssel im übermittelten Objekt.
• Die Schrift kommt nie als Name aus der Eingabe. Übermittelt wird ausschließlich eine Kennung, die serverseitig auf eine feste Formatvorlage abgebildet wird.
• Farben ausschließlich als Hexwert oder „transparent“. Farbfunktionen des Gestaltungsformats sind damit ausgeschlossen, einschließlich solcher, die einen Aufruf nach draußen auslösen könnten.
• Längengrenzen je Feld, aus den Flächen der Vorlagen gerechnet: Empfänger- und Absendername je 40 Zeichen, Gutscheincode 20, Betrag 18, Grußtext 240, Shopname 60, Gültigkeitsangabe 40. Dazu höchstens 2000 Zeichen je Ebenentext und höchstens 200 Ebenen je Dokument.
• Zahlen nur innerhalb benannter Grenzen — Schriftgröße 4 bis 400 Punkt, Zeilenhöhe 0,5 bis 4,0, Buchstabenabstand höchstens 40 Punkt in beide Richtungen, Drehung höchstens 360 Grad, Stapelposition 0 bis 999; Position und Größe werden gegen das Blatt geprüft. „Keine Zahl“ und „unendlich“ werden abgelehnt statt zurechtgebogen.
• Steuerzeichen werden entfernt. Zeilenumbrüche bleiben nur im Grußtext erhalten.
• Eine zweite, unabhängige Schicht an der Ausgabe. Beim Erzeugen des HTML läuft jede Zahl noch einmal durch eine feste Formatvorlage, aus der kein Trennzeichen entstehen kann, und wird auf das Blattformat geklemmt; jede Farbe wird erneut gegen dieselbe Erlaubnisliste geprüft und andernfalls durch „transparent“ ersetzt. Das gilt auch für ein Dokument, das nicht über die Eingabeprüfung in den Renderer gelangt.
• Kein Auswerten von Händlereingabe als Vorlage. Die Platzhalter im Text einer Ebene werden rein textuell und in einem Durchgang ersetzt. Ein Wert, der selbst wie ein Platzhalter aussieht, wird deshalb nicht ein zweites Mal ersetzt. Alle freien Texte werden beim Einsetzen maskiert; ein Skript kann im Ergebnis nicht stehen.
• Ratenbegrenzung je Shop: 120 Renderläufe und sechs PDF-Abrufe pro Minute, nach einem Eimermodell, das sich stetig nachfüllt. Schlüssel ist die Shop-Domain aus dem geprüften Sitzungstoken und nie eine Angabe aus Körper oder Adresszeile. Jeder der vier Arbeitsprozesse führt ein eigenes Kontingent; die tatsächliche Obergrenze liegt beim Vierfachen.
• Der Dateiname des PDF ist fest und wird nicht aus den Werten gebaut.
• Nichts davon landet im Protokoll. Wird ein Wert abgelehnt, wird der Name des Feldes vermerkt, nie sein Inhalt (Anlage 1 Abschnitt A, Zeile Anwendungsprotokolle).

2.6 Prüfung hochgeladener Bilder

Ein hochgeladenes Bild wird einmal beim Hochladen geprüft, bevor es gespeichert wird; was die Prüfung nicht besteht, wird nie gespeichert.

• Erlaubnisliste der Formate. Angenommen werden ausschließlich JPEG, PNG, WebP und SVG. Andere Bildformate werden abgelehnt und nicht umgewandelt.
• Das Format wird aus dem Inhalt bestimmt, nicht aus der Behauptung des Aufrufers. Der Typ, den die Anfrage angibt, wird nicht gelesen, und einen Dateinamen kann die Anfrage nicht mitschicken. Ein Raster wird an seinen Kopfdaten erkannt und vollständig dekodiert; ein SVG daran, dass es sich als SVG lesen lässt.
• Deckel auf die Größe: 5 Mebibyte. Er wirkt an drei Stellen: vorab gegen die vom Aufrufer angekündigte Länge, während des Einlesens und ein drittes Mal in der Prüfung selbst.
• Riegel gegen Dekompressionsbomben. Die Pixelgrenzen (höchstens 6000 Bildpunkte je Kante, höchstens 12 Millionen insgesamt) greifen nach dem Lesen der Kopfdaten und vor dem Dekodieren. Dahinter liegt als Rückfallebene die eigene Grenze der Bildbibliothek, herabgesetzt auf denselben Wert.
• SVG wird bereinigt, und gespeichert wird die bereinigte Fassung. Die Bereinigung arbeitet mit einer Erlaubnisliste für Elemente und Attribute und baut das Motiv daraus neu auf. Entfernt werden damit unter anderem Skriptelemente und Ereignisattribute, eingebettetes HTML, Formatvorlagen und das Stilattribut sowie jeder Verweis nach draußen; Verweise sind nur auf Elemente desselben Dokuments zulässig. Dokumenttypdefinitionen und Entitäten sind abgeschaltet. Die Schachtelungstiefe ist auf 40 Ebenen begrenzt. Ein Motiv, das nach der Bereinigung nichts mehr zeichnen würde, wird abgelehnt und nicht leer gespeichert.
• Ratenbegrenzung je Shop: zehn Uploads pro Minute, nach demselben Eimermodell wie in 2.5, aber mit eigenem Kontingent. Schlüssel ist auch hier die Shop-Domain aus dem geprüften Sitzungstoken und nie eine Angabe aus der Anfrage. Wie in 2.5 führt jeder der vier Arbeitsprozesse ein eigenes Kontingent.
• Reihenfolge der Schritte. Sitzungstoken prüfen, Ratenbegrenzung ziehen, Shop auflösen — und erst danach ein Byte des Körpers lesen.
• Erst die Datei, dann die Zeile. Bricht der Vorgang dazwischen ab, bleibt eine Datei ohne Zeile zurück, die der nächste identische Upload wieder einsammelt und die shop/redact über den Namensraum mit abräumt. Eine Zeile ohne Datei entsteht so nicht.
• Nichts davon landet im Protokoll. Vermerkt werden der angenommene Typ oder der Grund einer Ablehnung — nie der Schlüssel, nie die Prüfsumme, nie ein Ausschnitt der Datei.
• Aufnahmedaten. Kartuu entfernt sie aus jedem Raster. Über 2000 Pixel Kantenlänge wird das Bild heruntergerechnet und neu kodiert; darunter verwirft Kartuu nur die Blöcke der Datei, die Aufnahmedaten tragen (EXIF, XMP, IPTC, Kommentare, eingebettete Vorschaubilder), und die Bildpunkte bleiben unverändert. Erhalten bleibt allein die Ausrichtung. Bilder von vor dem 23.09.2026 werden beim Start der Anwendung auf dieselbe Weise bereinigt; ersetzt wird eine Datei nur, wenn beide Fassungen Bildpunkt für Bildpunkt gleich sind.

2.7 Maßnahmen des Bestellablaufs

• Idempotenzschlüssel je Stück. Shop, Bestellung, Bestellposition und laufende Nummer bilden zusammen einen eindeutigen Index. Shopify wiederholt einen Webhook über bis zu 48 Stunden; eine Wiederholung trifft damit dieselben Zeilen und erzeugt keine zweiten Gutscheine. Der Shop steht an erster Stelle des Schlüssels, damit die Eindeutigkeit nicht shopübergreifend gilt.
• Ein Datensatz je Stück, nicht je Bestellposition. Drei gekaufte Gutscheine über je 50 Euro ergeben drei Zeilen mit drei Codes; jeder lässt sich einzeln verschenken und einlösen.
• Der Zustandslauf steht an einer Stelle und wirkt an zwei. Zehn benannte Zustände, festgeschrieben als Prüfregel in der Datenbank. Welche Übergänge erlaubt sind, hängt der einzige Schreibpfad als Bedingung an die Schreibanweisung selbst; zwei gleichzeitig laufende Arbeiter können denselben Gutschein nicht zweimal weiterschalten.
• Vollständigkeit ab dem Zustand „bereit". Die Datenbank lässt diesen Zustand nur zu, wenn Code und Vorlagenabbild vorhanden sind — bei einem Wertgutschein zusätzlich Nennwert und Geschenkkartenkennung.
• Der Code steht in der Zeile, bevor die Karte bei Shopify entsteht. Kartuu schreibt zuerst den Code, und zwar in einer Anweisung, die nur greift, solange das Feld leer ist; erst danach ruft es Shopify. Von zwei gleichzeitigen Arbeitern ruft damit nur einer die Mutation auf, und ein Abbruch dazwischen führt beim nächsten Anlauf zu demselben Code. Weil ein Gutscheincode je Shop eindeutig ist, entsteht entweder die fehlende Karte oder Shopify lehnt den Code als vergeben ab. Am Ende existiert genau eine bezahlte Karte. Lehnt Shopify den Code als vergeben ab, endet der Vorgang in einem sichtbaren Fehlzustand (Abschnitt 7).
• Der Fehlergrund ist eine eigene kurze Kennung, nie eine fremde Fehlermeldung. Die Datenbank erzwingt das Format [a-z0-9_], damit keine durchgereichte Meldung Empfängername oder Gutscheincode zitieren kann.
• Der Code wird nicht geraten und nicht verwechselt. Er stammt aus einem kryptografisch sicheren Zufallsgenerator, 16 Zeichen aus einem Alphabet ohne die auf Papier verwechselbaren Paare. Der Abruf-Token stammt aus derselben Quelle; er berechtigt zum Abruf und steht deshalb nirgends, wo der Code steht.
• Der Webhook quittiert erst, wenn die Zeilen in der Datenbank stehen. Alles Teure (Shopify-Aufruf, Rendern) läuft danach; ein Neustart verzögert die Verarbeitung, er verliert sie nicht.
• Was der Kunde im Bestellformular nicht ausgefüllt hat, wird nicht geraten. Eine Bestellung über einen Express-Bezahlweg kommt ohne Personalisierung an. Diese Zeilen werden als „Angaben unvollständig" gekennzeichnet, bleiben stehen und lösen keinen Aufruf bei Shopify aus, bis der Händler die Angaben ergänzt.
• Zustellung genau einmal. Bevor ein Gutschein verschickt wird, beansprucht ein Arbeitsprozess die Zustellung in der Datenbank; ein zweiter Prozess findet sie beansprucht und verschickt nicht erneut.

2.8 Nachvollziehbarkeit von Änderungen

Das Datenbankschema wird ausschließlich über Migrationen und in einem eigenen Prozess vor dem Start der Anwendung geändert; kein Arbeitsprozess sieht ein halbfertiges Schema.

3. Verfügbarkeit und Belastbarkeit

• Der Container läuft nicht mit Systemrechten (eigener Benutzer), mehrstufiger Aufbau, Zustandsprüfung.
• Sperrkonflikte in der Datenbank laufen in eine Zeitgrenze von 20 Sekunden und enden in einer sauberen Fehlermeldung statt in einem hängenden Arbeitsprozess.
• Tägliche Datenbanksicherung, mit AES-256 verschlüsselt, bevor sie den Server verlässt, abgelegt auf dem Server (Aufbewahrung 30 Tage) und im Objektspeicher der IONOS in Berlin (Aufbewahrung 95 Tage, davon die ersten 90 durch Object Lock unlöschbar). Damit liegt eine Kopie außerhalb des Servers. Einzelheiten in § 9.3 Nr. 2.
• Die Sicherung prüft sich selbst. Vor dem Hochladen wird die verschlüsselte Datei wieder entschlüsselt und darauf geprüft, dass ein Datenbankabzug herauskommt; nach dem Hochladen wird beim Speicher zurückgefragt, ob das Objekt in der erwarteten Größe angekommen ist. Ein zu kleiner Abzug führt zum Abbruch.
• Ein täglicher Prüflauf meldet ausgebliebene Sicherungen an die Betriebsadresse von KYTH, wenn seit mehr als 26 Stunden kein erfolgreicher Lauf vermerkt wurde. Dass sich eine Sicherung einspielen lässt, ist durch eine tatsächliche Wiederherstellung geprüft.
• Für die hochgeladenen Bildmotive gibt es keine Sicherung. Sie liegen in der Bildablage und nicht in der Datenbank; der tägliche Lauf oben erfasst sie deshalb nicht. Geht die Ablage verloren, sind die Motive weg — die Karten der Händler wären dann ohne Bild, die übrigen Angaben blieben vollständig. Siehe Abschnitt 7.

4. Belastbarkeit der Konfiguration

Die Anwendung startet nicht ohne die erforderlichen Konfigurationswerte; der Verschlüsselungsschlüssel wird auf das korrekte Format geprüft. Fehlkonfiguration führt zum Abbruch, nicht zu stillem Weiterlaufen.

5. Trennung von Test und Produktion

Zwei getrennte Anwendungen mit je eigener Datenbank, eigenem Verschlüsselungsschlüssel, eigener Datenbankrolle mit eigenem Kennwort, eigener Domain und eigener Shopify-Anwendung. Auch die Adressen der Rechtstexte werden je Umgebung aus der jeweils eigenen Anwendungsadresse abgeleitet.

6. Verfahren zur Überprüfung und Bewertung

• Löschpfad ohne pflegbare Liste: Die beim Löschen zu leerenden Tabellen werden zur Laufzeit aus dem Datenbankkatalog ermittelt — alle Tabellen im Schema public mit einer Spalte shop_id; der heutige Datenbestand fällt vollständig darunter. Die Löschung läuft in einer Transaktion.
• Ein Löschpfad, zwei Auslöser. Der Aufräumlauf für verwaiste Shops (§ 9.3 Nr. 1) benutzt dieselbe Löschfunktion wie shop/redact, einschließlich des ersten Schritts, des Entfernens der Bildmotive über den Namensraum des Shops.
• Automatische Prüfungen gegen schleichende Abweichung: Jede neue Tabelle mit Shop-Zuordnung muss über die Datenzugriffsschicht erreichbar sein oder begründet ausgenommen werden, muss ein Löschrecht für die Anwendungsrolle tragen, und jede Tabelle mit einer nach Namensmuster personenbezogenen Spalte muss in die Liste der Tabellen mit personenbezogenen Feldern eingetragen sein — sonst schlägt die Prüfung fehl. Über diese Liste laufen Auskunft und Löschung nach Art. 15 und Art. 17; heute steht die Gutscheintabelle darin. Die Tabelle shops ist ausgenommen, weil sie keine shop_id-Spalte hat; die Kontaktadresse darin ist als Händlerdatum genau für diese eine Spalte ausgenommen.
• Ablaufplan für Sicherheitsvorfälle mit 72-Stunden-Frist, benannter Aufsichtsbehörde (BayLDA), Eskalationsstufen und ausdrücklichem Hinweis auf Art. 14 DSGVO für Beschenkte.

7. Bekannte Lücken

Diese Punkte sind nicht oder nicht vollständig erfüllt.