Anlage 2 · Technische und organisatorische Maßnahmen

zum Vertrag über die Auftragsverarbeitung nach Art 28 DSGVO

Die unternehmensrechtlichen Angaben zum Auftragsverarbeiter (Kammerzugehörigkeit, zuständige Aufsichtsbehörde, Standort der Gewerbeberechtigung) stehen im Impressum. [OFFEN: Gewerbeberechtigung — Kammer, Aufsichtsbehörde und Standort erst nach Anmeldung]

Bitte lesen Sie Abschnitt E, bevor Sie zustimmen

Diese Anlage benennt in Abschnitt E neunundzwanzig offene Punkte, davon fünf mit der Bewertung kritisch oder hoch, die Sie vor Ihrer Entscheidung kennen müssen:

1. Es wird kein Einwilligungsnachweis für Ihre Gäste geschrieben (E.1).
2. Es gibt an keinem Zugang einen zweiten Faktor — auch nicht am Zugang zur Plattformverwaltung, der alle Betriebe erreicht (E.2).
3. Es gibt heute keine automatische Löschung. Das Löschkonzept ist programmiert, aber nicht in der Datenbank aktiv (E.3).
4. Es gibt keine automatischen Sicherungen der Datenbank und keine durchgeführte Wiederherstellungsprobe (E.4).
5. Für die vier eingesetzten Dienstleister ist kein Vertragsnachweis abgelegt (E.5).

Dieser Hinweis steht hier, weil eine solche Aufzählung in einer technischen Anlage niemand erwartet. Nach § 864a ABGB werden nachteilige Bestimmungen ungewöhnlichen Inhalts nur dann Vertragsinhalt, wenn auf sie besonders hingewiesen wird. Derselbe Hinweis erscheint im Annahmeschritt vor der Zustimmung.

Vorbemerkung — der Maßstab dieser Anlage

Art 32 DSGVO verlangt angemessene, nicht vollständige Maßnahmen. Maßstab sind Stand der Technik, Implementierungskosten, Art, Umfang, Umstände und Zwecke der Verarbeitung sowie das Risiko für die betroffenen Personen.

Übersetzt heißt das: Verlangt wird, was bei dieser Art von Daten, bei dieser Menge und bei diesem Risiko mit vertretbarem Aufwand heute üblich und machbar ist — nicht alles, was technisch denkbar wäre.

Diese Anlage beschreibt deshalb nicht, was wünschenswert wäre, sondern was die Plattform tatsächlich tut. Jede Maßnahme ist am Quelltext belegt; die Belegstellen stehen in der Tabelle in Abschnitt F. Was nicht belegt ist, steht in Abschnitt E als offener Punkt — auch dann, wenn es in einer solchen Anlage üblicherweise angekreuzt wird.

Wessen Daten diese Anlage schützt

Die Anlage gilt für alle Daten, die Stammkartl im Auftrag des Betriebs verarbeitet. Das sind zwei Gruppen:

• Ihre Gäste — Vorname, Stempelstand, Geburtstag ohne Jahr, Nachrichten-Entscheidung, Kartenverlauf.
• Ihre Mitarbeiter — Name, PIN als Prüfwert, Zuordnung zu Ihrem Betrieb und die Auswertung ihrer Stempelvorgänge (Scans heute, diese Woche und in den letzten zwölf Monaten, erster und letzter Scan, die letzten zwanzig Einzelvorgänge mit Uhrzeit und dem Vornamen des bedienten Gastes).

Für beide Gruppen sind Sie der Verantwortliche, Stammkartl ist Auftragsverarbeiter. Das ist eine Änderung gegenüber Fassung 1.0, die die Mitarbeiterdaten Stammkartl zugeordnet und aus dem Vertrag herausgenommen hatte. Diese Zuordnung war mit dem System nicht in Deckung: Im Produkt legt ausschließlich der Betrieb Mitarbeiter an, vergibt Namen und PINs, ändert, löscht und wertet aus. Das sind die Merkmale, an denen die Verantwortlichkeit hängt.

Daraus folgt eine Pflicht, die neu bei Ihnen liegt: Sie müssen Ihre Mitarbeiter über diese Verarbeitung informieren. Stammkartl stellt Ihnen dafür einen fertigen Textbaustein als eigene Anlage des Hauptvertrags bereit, so wie für die Information Ihrer Gäste. Ob und in welchem Umfang eine Leistungsauswertung dieser Art arbeits- und betriebsverfassungsrechtlich zulässig ist, beurteilt diese Anlage nicht — das ist in Österreich anwaltlich zu klären und bleibt Ihre Entscheidung (Abschnitt E.23).

Keine eigenen Server, keine Geschäftsräume mit Datenverarbeitungsanlagen

Stammkartl wird von einer Einzelperson ohne Betriebsstätte betrieben; die gesamte Verarbeitung läuft bei den in Abschnitt D.4 genannten Dienstleistern. Die physische Sicherheit der Anlagen liegt daher vollständig bei den Rechenzentrumsbetreibern. Die Gebäudepunkte des WKO-Musters (Portier, Sicherheitstüren, Besucherausweise, Alarmanlagen, Schließsystem) sind für diesen Auftragsverarbeiter gegenstandslos und wurden gestrichen, statt sie unzutreffend zu bejahen.

Änderungen dieser Anlage

Änderungen erfolgen nach § 10 Abs 1 des Hauptvertrags. Stammkartl informiert den Betrieb mindestens 30 Tage vorab in Textform; der Betrieb kann aus wichtigem datenschutzrechtlichem Grund widersprechen. Das in dieser Anlage beschriebene Schutzniveau darf dadurch nicht sinken; ob es gesunken ist, hat im Streitfall Stammkartl darzulegen — nicht der Betrieb zu widerlegen.

Eine Angabe, die am Tarif hängt

Zwei Aussagen dieser Anlage setzen voraus, dass die Anwendung im Pro-Tarif der Hostingplattform betrieben wird: die Geltung des Auftragsverarbeitungsvertrags dieses Anbieters (D.4) und die Aufbewahrungsdauer von einem Tag für dessen Zugriffsprotokolle (C.1). Der Auftragsverarbeiter rüstet vor dem Livegang auf diesen Tarif auf. Steht zum Zeitpunkt der Verarbeitung ein anderer Tarif, sind beide Aussagen neu zu bewerten.

A · Vertraulichkeit (Art 32 Abs 1 lit b DSGVO)

A.1 Zutrittskontrolle — Schutz vor unbefugtem physischen Zutritt

Stammkartl betreibt keine eigene Infrastruktur. Daten werden ausschließlich bei folgenden Anbietern verarbeitet:

Die physische Zutrittskontrolle zu diesen Rechenzentren obliegt ausschließlich den genannten Anbietern. Stammkartl hat dort weder Zutritt noch Einfluss und kann die getroffenen Maßnahmen nicht aus eigener Anschauung bestätigen. Soweit Stammkartl sich darauf stützt, geschieht das über die in Abschnitt D.4 genannten Verträge.

Hinweis zur Vollständigkeit: Die vorgelagerte Routing-Schicht der Hostingplattform arbeitet unabhängig von der Regionseinstellung regionsübergreifend. Die Aussage „Verarbeitung ausschließlich in Frankfurt" wäre daher unrichtig; zutreffend ist: Anwendungslogik in Frankfurt, Routing und Auslieferungsnetz regionsübergreifend, abgesichert über die Garantien in § 6 des Hauptvertrags.

Das einzige Endgerät, von dem aus Stammkartl auf Produktivdaten zugreift, ist der Arbeitsplatzrechner des Auftragsverarbeiters. Bei einer Einzelperson ohne Büro ist das die einzige Stelle, an der physische Sicherheit überhaupt in ihrer Hand liegt — und sie ist derzeit nicht dokumentiert.

[OFFEN: Festplattenverschlüsselung, Bildschirmsperre und Sperrfrist des Arbeitsplatzrechners, von dem aus auf Produktivdaten zugegriffen wird]

A.2 Zugangskontrolle — Schutz vor unbefugter Systemnutzung

Anmeldewege

Speicherung der PINs. PINs werden mit bcrypt (Kostenfaktor 10) in einen nicht umkehrbaren Prüfwert umgerechnet und bei der Anmeldung damit verglichen; der Klartext wird nicht gespeichert.

Einschränkung, ausdrücklich benannt: Für den Chef-PIN besteht im Code weiterhin ein Rückfall auf einen Klartextvergleich, der greift, wenn der gespeicherte Wert nicht als bcrypt-Prüfwert erkennbar ist. Dieser Rückfall lebt an zwei Stellen: bei der Anmeldung und bei der PIN-Änderung durch den Wirt. Die Aussage „alle PINs liegen ausschließlich als Prüfwert vor" wäre deshalb unrichtig und wird hier nicht getroffen. Siehe E.8.

Entlastend geprüft: Der Mitarbeiter-PIN kennt diesen Rückfall nicht. Dort wird ausschließlich bcrypt verglichen; der frühere Klartextweg ist entfernt.

Für Mitarbeiter-PINs aus der Anfangszeit ist der Bestand nicht geprüft, der Mechanismus schon: Die Anmeldung prüft keine Mindestlänge. src/app/api/staff/[slug]/verify-pin/route.ts vergleicht den eingegebenen Wert ausschließlich per bcrypt gegen die gespeicherten Prüfwerte. Ein vierstelliger PIN aus der Anfangszeit bleibt deshalb anmeldefähig, bis er ersetzt wird; neu vergebene PINs müssen sechs bis acht Ziffern haben.

Der Bestand ist am 3. Oktober 2026 lesend geprüft worden. Es gibt zwei Mitarbeiter-Zugänge. Die Mindestlänge gilt seit dem 28. August 2026; ein Zugang wurde am 26. August 2026 angelegt, also zwei Tage davor, der zweite am 8. September danach. Die Länge selbst ist aus einem bcrypt-Prüfwert nicht ablesbar — das ist der Sinn eines Prüfwerts. Ein Zugang von zweien kann daher einen vierstelligen PIN tragen. Abhilfe ist eine Neuvergabe durch den Betrieb; sie dauert einen Klick. [OFFEN: Neuvergabe des vor dem 28.08.2026 angelegten Mitarbeiter-PIN — danach entfällt dieser Absatz]

Ein Weg, auf dem ein PIN das System im Klartext verlässt: Beim Anlegen eines Betriebs und beim Zurücksetzen gibt die Verwaltungsschnittstelle den Chef-PIN einmalig im Klartext in ihrer Antwort aus, damit er dem Wirt übergeben werden kann. Von dort wandert er erfahrungsgemäß per Messenger weiter. Das ist der einzige verbliebene Klartextweg, und er steht hier, damit er begrenzbar wird. Siehe E.9.

Sitzungen. Chef- und Mitarbeitersitzungen werden als HMAC-SHA256-signierte Cookies geführt (httpOnly, Secure im Produktivbetrieb, SameSite=Lax, Laufzeit 30 Tage).

Der Schlüssel, mit dem diese Sitzungen unterschrieben werden, ist ein eigener und wird nirgends durch ein anderes Passwort ersetzt. Fehlt er, stellt das System gar keine Sitzung mehr aus und erkennt auch keine an: Es sperrt lieber zu, als ohne Schlüssel zu unterschreiben.

Schutz gegen Durchprobieren. An den Anmeldewegen (Chef-PIN, Mitarbeiter-PIN, Verwaltung) greift eine Ratenbegrenzung in zwei Dimensionen — je Kombination aus Adresse und Konto sowie je Konto insgesamt. Die Sperrdauer beträgt für Chef- und Mitarbeiteranmeldung 5 Minuten, für die Plattformverwaltung 15 Minuten. Die Antwortzeiten sind angeglichen (eine bcrypt-Prüfung läuft auch bei unbekanntem Betrieb), sodass sich aus der Antwort nicht ableiten lässt, ob ein Betrieb existiert.

Was es nicht gibt: Eine Zwei-Faktor-Authentifizierung besteht an keinem Zugang — auch nicht für die Plattformverwaltung, deren Wirkungskreis sämtliche Betriebe und deren Karteninhaber umfasst. Hinzu kommen zwei Nebenbefunde: Das Verwaltungspasswort dient zugleich als Schlüssel für die Signatur der Verwaltungssitzung, und die Sitzungsdauer ist zweimal unterschiedlich festgelegt — die eigentliche Prüfung sieht 4 Stunden vor, die vorgelagerte Prüfschicht lässt 24 Stunden durch. (Zur Fairness: Der Quelltext begründet den geteilten Schlüssel damit, dass das Verwaltungscookie genau eine Identität beglaubigt und wer das Passwort kennt sich ohnehin regulär anmelden könnte. Diese Begründung trägt — die Doppelnutzung bleibt gleichwohl eine Verengung auf ein einziges Geheimnis.) Siehe E.2.

Ratenbegrenzung außerhalb der Anmeldung. Von 111 Schnittstellen der Anwendung verfügen 27 über eine Ratenbegrenzung — darunter die Anmeldewege und der Beitritt von Gästen. Eine Ratenbegrenzung „auf allen Schnittstellen" besteht nicht und wird hier nicht behauptet.

Zählweise, Stand 02.10.2026: Dateien route.ts unter src/app/api; 111 insgesamt, 27 davon binden eine Ratenbegrenzung ein.

A.3 Zugriffskontrolle — Trennung der Betriebe und Beschränkung auf das Erforderliche

Dieser Punkt wird bewusst genauer gefasst als in Fassung 1.0, weil die dortige Beschreibung den tatsächlichen Aufbau falsch wiedergab.

Erste Ebene — die Datenbank sperrt sich von außen selbst ab. Die Datenbank hat eine eingebaute Zeilensperre (englisch Row Level Security). Sie ist auf allen Basistabellen eingeschaltet, und für die meisten ist keine einzige Ausnahme hinterlegt. Wer die Datenbank von außen mit dem öffentlichen Schlüssel anspricht, bekommt deshalb nichts zurück — weder lesend noch schreibend.

Ein eigener Datenbankschritt geht alle Tabellen durch, schaltet die Sperre überall dort nach, wo sie fehlt, und meldet jede dieser Tabellen. Mehrfaches Ausführen schadet nicht. So sind auch Tabellen erfasst, die jemand von Hand angelegt hat.

Nicht erfasst sind Sichten (gespeicherte Abfragen). Der Schritt durchläuft ausschließlich Basistabellen. Heute ist das folgenlos, weil keine Sicht mit Personenbezug existiert — es wird in dem Moment scharf, in dem die vorbereitete Datenbankänderung 077 ausgeführt wird, denn sie legt eine betriebsübergreifende Sicht an. Das ist eine Reihenfolgenaussage, die Sie kennen müssen: Dieselbe Ausführung, die E.3 schließt, öffnet E.20, wenn er bis dahin nicht behoben ist.

Zweite Ebene — dass ein Betrieb nur seine eigenen Daten sieht, stellt jede Schnittstelle selbst sicher. 100 der 111 Schnittstellen arbeiten mit dem Dienstschlüssel der Datenbank, und dieser Schlüssel umgeht die Zeilensperre bauartbedingt. Die Trennung der Betriebe hängt deshalb nicht an der Zeilensperre. Sie hängt daran, dass jede Schnittstelle die Datenbank immer zusammen mit der Nummer des Betriebs (gastro_id) fragt. Diese Nummer nimmt sie aus der Anmeldung — nie aus dem, was der Browser mitschickt. Sonst könnte jemand eine fremde Nummer eintragen und die Daten eines anderen Betriebs abrufen.

Zählweise, Stand 02.10.2026: Dateien route.ts unter src/app/api, die den Dienstschlüssel einbinden; 100 von 111.

Das ist eine tragfähige Architektur — aber nur, solange sie geprüft wird. Deshalb:

• tests/mandanten/trennung.test.ts fährt die echten Schnittstellen gegen zwei Betriebe und prüft beides: das Ergebnis und strukturell, dass der Filter überhaupt gesendet wurde;
• tests/mandanten/filterWaechter.test.ts wacht darüber, dass neue Schnittstellen den Filter nicht vergessen;
• tests/mandanten/auskunft.test.ts prüft denselben Schnitt für die Auskunftswege.

Der Dienstschlüssel wird ausschließlich serverseitig verwendet und ist im ausgelieferten Browsercode nicht enthalten.

Zugriff von Menschen. Es existiert genau ein Verwaltungszugang; er wird ausschließlich vom Auftragsverarbeiter selbst genutzt. Es gibt keine weiteren Personen mit Zugriff auf Produktivdaten.

Einschränkung: Die vier Dateiablagen (Logos, Pass-Bilder, Onboarding-Material) sind öffentlich lesbar, und die Pfade sind erratbar. Im gesamten Projekt wird keine einzige signierte Abruf-Adresse verwendet. Siehe E.7.

A.4 Pseudonymisierung und Datenminimierung (Art 32 Abs 1 lit a, Art 25 Abs 2)

• Karten werden über Zufallstoken adressiert, nicht über fortlaufende Nummern: 16 Zufallsbytes aus dem kryptografischen Zufallsgenerator des Systems, sowohl für die geräteweite Gastkennung als auch für das Zugriffstoken des Apple-Passes.
• Der Geburtstag wird ohne Jahr gespeichert. Das Jahr wird fest auf 2000 gesetzt; ein Alter ist aus dem gespeicherten Wert nicht ableitbar. Die Angabe ist freiwillig.
• Der Beitrittsweg erhebt von Karteninhabern weder Nachname noch E-Mail-Adresse noch Telefonnummer. Der Vorname ist freiwillig; ohne Angabe lautet er „Gast". Genauer, weil der Beleg sonst gegen die Aussage spricht: Die Tabelle customers führt eine Spalte email, und das Kundenprofil zeigt sie im Ausdruck an. Über den Beitritt wird sie nicht befüllt. Eine Durchsuchung aller Schreibpfade auf customers ergibt: Keine Codestelle schreibt diese Spalte — weder der Beitritt (/api/join/[slug]), noch die Verwaltung, noch ein Hintergrundlauf. Die Spalte stammt aus der ersten Fassung des Datenmodells (supabase/migrations/001_initial.sql) und ist seither unbenutzt. Am 3. Oktober 2026 lesend geprüft: Von 28 Kundendatensätzen trägt kein einziger einen Wert in dieser Spalte. Die Aussage, dass vom Karteninhaber keine E-Mail-Adresse erhoben wird, trifft damit nicht nur auf den Weg, sondern auch auf den Bestand zu.
• Der Standortabgleich für die Anzeige auf dem Sperrbildschirm findet ausschließlich auf dem Gerät des Gastes statt. Die Karte enthält die Koordinaten des Betriebs; weder der Betrieb noch Stammkartl erfahren, wo sich der Gast befindet. Es existiert kein Rückkanal, der eine Standortangabe entgegennehmen könnte.
• Die Mitarbeiter-Leistungsauswertung ist auf zwölf Monate und zwanzig Einzelvorgänge begrenzt. Das ist eine Grenze, aber keine Minimierung mit Begründung; eine dokumentierte Abwägung fehlt (E.23).

Einschränkung, gegenüber Fassung 1.0 verschärft: Die Adresse des Gastes wird bei der Beitrittsbegrenzung ungekürzt und ungehasht als Teil des Primärschlüssels der Begrenzungstabelle gespeichert — ebenso wie bei der Anmeldung eines Betriebs. Die Projektbibliothek stellt mit kurzeIp eine Kürzung bereit; verwendet wird sie nur in einer Protokollzeile, nicht beim Speichern. Zusätzlich erscheint die vollständige Adresse im Laufzeitprotokoll: bei jeder ausgelösten Anmeldesperre und bei jedem Zählfehler des Beitrittszählers.

Fassung 1.0 und die zugrunde liegenden Prüfdokumente führen hier eine Kürzung, die es im Speicherpfad nicht gibt. Diese Aussage ist damit zurückgenommen. Siehe E.11.

Verschlüsselung ruhender Daten. Hierzu trifft Stammkartl keine eigene Konfiguration. Eine Verschlüsselung gespeicherter Daten ist, soweit sie besteht, eine Eigenschaft der Dienstleister; sie wird von Stammkartl weder eingerichtet noch überprüft. Eine anwendungsseitige Feld- oder Spaltenverschlüsselung besteht nicht. Diese Anlage behauptet deshalb zu ruhenden Daten nichts, was über Abschnitt D.4 hinausgeht. Siehe E.29.

A.5 Klassifikationsschema

Ein formales, schriftlich festgelegtes Klassifikationsschema (etwa öffentlich / intern / vertraulich / streng vertraulich) besteht nicht. Das wird hier benannt und nicht umschrieben.

Faktisch wirksam ist eine Trennung in drei Stufen, die in der Architektur selbst abgebildet ist:

Die Schwäche dieser faktischen Einteilung ist die dritte Zeile: In der Ablage für Onboarding-Material liegen bis zu zwölf Geschäftsfotos und eine Logovorlage, die auch eine PDF sein darf — alle öffentlich lesbar (E.7). Auf Fotos aus einem Gastraum können Mitarbeiter und Gäste zu sehen sein. Eine geschriebene Klassifikation hätte diesen Fall erfasst. Sie ist nachzuholen (E.26).

B · Datenintegrität (Art 32 Abs 1 lit b DSGVO)

B.1 Weitergabekontrolle

Transport. Die Übertragung erfolgt ausschließlich verschlüsselt (TLS). Erzwungen wird das zusätzlich durch einen HSTS-Kopf mit einer Gültigkeit von einem Jahr einschließlich aller Unterdomänen.

Weitere Schutzköpfe, für jede ausgelieferte Antwort gesetzt:

Was fehlt: Eine Content-Security-Policy besteht nicht. Siehe E.12.

Schutz vor untergeschobenen Anfragen. 38 der 111 Schnittstellen prüfen, von welcher Seite eine Anfrage kommt, und weisen sie ab, wenn sie von einer fremden Seite stammt. Das verhindert, dass eine fremde Webseite, die ein angemeldeter Wirt nebenbei offen hat, in seinem Namen etwas auslöst.

Keine der 27 Schnittstellen der Plattformverwaltung tut das. Siehe E.13.

Das Geheimnis für die zeitgesteuerten Läufe wird seit dem 02.10.2026 ausschließlich in der Kopfzeile der Anfrage angenommen. Der frühere Rückfall, es auch als Teil der Adresse zu akzeptieren, ist geschlossen — ein Geheimnis in der Adresse landet in Zugriffsprotokollen und Weiterleitungs-Kopfzeilen und ließe dort echten Nachrichtenversand an Gäste auslösen.

Signierte Ausgabe. Apple-Wallet-Pässe werden serverseitig gebaut und kryptografisch signiert. Beim Bauen erfolgt kein Netzaufruf zu Apple.

Nachrichten sind auf dem Weg verschlüsselt. Push-Nachrichten werden verschlüsselt, bevor sie den Server verlassen. Der Dienst, der sie an das Handy ausliefert — je nach Browser Apple, Google oder Mozilla —, transportiert sie nur und kann sie nicht lesen. Er sieht, dass und wann etwas an welches Gerät geht, nicht aber, was darin steht. (Verfahren: RFC 8291.)

Der Standard verlangt zusätzlich, bei jedem Versand eine Kontaktadresse für technische Rückfragen mitzusenden. Sie geht damit an alle drei Dienste. Hinterlegt ist eine E-Mail-Adresse des Auftragsverarbeiters. Daten der Gäste oder der Mitarbeiter sind darin nicht enthalten.

Was Dritte dennoch erfahren — offen benannt:

• Apple erhält bei der Aktualisierung einer Karte Gerätetoken, Pass-Kennung und Zeitpunkt. Der Benachrichtigungsinhalt ist leer; Apple erfährt daraus nichts über den Gast. Beim Hinzufügen der Karte überträgt das Gerät des Gastes die auf der Karte sichtbaren Angaben an Apple; Apple verknüpft sie mit dem Apple-Konto und speichert sie, solange die Karte in Wallet liegt. Apple handelt dabei als eigener Verantwortlicher (D.4).
• Google erhält bei jeder Nachricht den vollständigen personalisierten Text im Klartext einschließlich des Vornamens — und zwar für jede Karte, auch für Gäste, die ausschließlich ein iPhone verwenden. Google handelt dabei als eigener Verantwortlicher (D.4). Siehe E.14.
• Sentry erhält Fehlerereignisse aus dem Browser und vom Server, einschließlich der vollständigen Anfrageadresse; Zugriffstoken darin sind maskiert, die Übermittlung personenbezogener Zusatzangaben ist abgeschaltet, Ereignisse werden in der EU verarbeitet.

Was nicht stattfindet. Es gibt keine Analytik, kein Tracking, keine Werbenetzwerke und keine zur Laufzeit nachgeladenen Fremdressourcen. Schriftarten werden zur Bauzeit eingebunden und von der eigenen Domain ausgeliefert.

B.2 Eingabekontrolle — Nachvollziehbarkeit von Eingabe, Änderung und Entfernung

Bewusste Beschränkung: Protokolliert werden verändernde Zugriffe und Anmeldungen, nicht lesende — mit einer Ausnahme: die Ausleitung der Daten eines Gastes. Sie ist der folgenreichste Lesezugriff im System und deshalb eigens protokolliert. Jeden Seitenaufruf zu protokollieren erzeugte dagegen Rauschen, in dem die eine Zeile untergeht, auf die es ankommt. Ein Protokollfehler blockiert nie die protokollierte Handlung.

Vier Einschränkungen, ausdrücklich benannt:

1. Ein Einwilligungsnachweis für Gäste wird derzeit nicht geschrieben. Die dafür vorgesehenen Spalten sind noch nicht in der Datenbank angelegt, und keine Stelle im Code beschreibt sie. Diese Anlage behauptet daher nicht, es gebe einen solchen Nachweis. Siehe E.1.
2. Das Zugriffsprotokoll hat keinen Leseweg. admin_audit_log wird geschrieben, aber im gesamten Projekt nirgends gelesen — auch nicht in der Plattformverwaltung. Es ist damit heute ein Beweismittel, das nur nach einer Datenbankabfrage von Hand zugänglich ist. Siehe E.17.
3. Der Nachweis der Vertragsannahme wird beim Fassungswechsel überschrieben statt historisiert. Die Annahme einer früheren Fassung ist danach nicht mehr belegbar. Die Abhilfe liegt als Datenbankänderung 081 (Protokolltabelle vertragsannahmen) fertig vor und wartet auf dieselbe Ausführung wie E.3. Siehe E.16.
4. Die IP-Adresse im Verwaltungsprotokoll wird aus einer Angabe gelesen, die der Anfragende selbst mitschicken kann. Wer will, kann dort eine fremde Adresse eintragen. Als Beweis, wer etwas getan hat, taugt diese Zeile deshalb nur eingeschränkt — alles Übrige im Protokoll bleibt davon unberührt. Siehe E.24.

Ein zweiter Ausleitungsweg, der nichts protokolliert. Der Knopf „Daten exportieren", den der Wirt im Kundenprofil sieht, erzeugt die Datei im Browser aus den bereits geladenen Feldern. Er ruft die oben genannte protokollierte Schnittstelle nicht auf, enthält nur rund zehn Felder und hinterlässt keinen Protokolleintrag. Es gibt damit zwei Wege, auf denen Personendaten das System verlassen, und der sichtbare ist der ungeprüfte. Siehe E.18.

C · Verfügbarkeit und Belastbarkeit (Art 32 Abs 1 lit b und c DSGVO)

C.1 Verfügbarkeitskontrolle

Stammkartl betreibt keine eigene Infrastruktur; die Verfügbarkeit der Plattform hängt vollständig an der Verfügbarkeit der Dienstleister. Eine Verfügbarkeit wird nicht zugesagt; es besteht kein Service Level Agreement, und diese Anlage begründet keines.

Davon unberührt bleibt die gesetzliche Pflicht aus Art 32 Abs 1 lit c DSGVO, Verfügbarkeit und Zugang nach einem Zwischenfall rasch wiederherstellen zu können. Diese Pflicht ist nicht abdingbar und besteht ohne Service Level Agreement fort. Dass sie heute nur eingeschränkt erfüllt ist, steht als offener Punkt E.4 in dieser Anlage und ist bei der Entscheidung über die Nutzung zu berücksichtigen.

Vorhanden sind:

• Technische Fehlerüberwachung über Sentry (Verarbeitung der Ereignisse in der EU, Übermittlung personenbezogener Zusatzangaben abgeschaltet, Zugriffstoken in Adressen maskiert). Fehler werden protokolliert und ausgewertet.
• Zeitgesteuerte Läufe auf derselben Plattform wie die Anwendung. Der stündliche Takt wird von der Zeitplanfunktion der Hostingplattform ausgelöst (vercel.json, 0 * * * *). Ein zusätzlicher Dienstleister ist dafür nicht eingebunden, und das Zeitplan-Geheimnis verlässt die Plattform nicht. Der stündliche Takt setzt den Pro-Tarif voraus; der Eintrag liegt im Projekt vor und wirkt mit der nächsten Veröffentlichung.
• Laufzeitwache für die zeitgesteuerten Läufe: Überschreitet ein Lauf 45 von 60 Sekunden, bricht er geordnet ab, statt in eine Zeitüberschreitung der Plattform zu laufen, und hinterlässt einen Eintrag.
• Überwachung der Wallet-Zugangsdaten: Das Apple-Pass-Zertifikat wird mit seinem echten Ablaufdatum ausgelesen. Beim Google-Zugang gibt es kein Ablaufdatum, das man ablesen könnte; deshalb fragt das System in Abständen schlicht bei Google an — kommt eine Antwort, ist der Zugang gültig, bleibt sie aus, meldet es das.

Was fehlt: Eine automatische Alarmierung an einen Bereitschaftsdienst besteht nicht; Warnungen werden protokolliert, es wird niemand geweckt. Bei einer Einzelperson ohne Vertretung bedeutet das: Kenntnis von einer Störung — und damit auch von einer Datenschutzverletzung — kann verzögert eintreten. Das steht in einem Spannungsverhältnis zur 48-Stunden-Zusage in D.2, deren Frist ab Kenntnis läuft. Siehe E.19.

Eine selbst gesetzte Grenze: Der Lauf begrenzt sich auf 60 Sekunden und zieht die Reißleine bei 45. Pro Lauf werden höchstens 200 Warnungen und 200 Löschungen bearbeitet, und die Auswahl erfolgt ohne feste Reihenfolge. Übersteigt die Zahl der Betroffenen diesen Deckel, kann an jedem Lauf derselbe Ausschnitt gezogen werden, während andere nie an die Reihe kommen. Aus einer Frist würde so ein Zufall. Heute folgenlos, weil die Fristen ohnehin nicht laufen (E.3) — ab deren Ausführung aber wirksam. Siehe E.22.

C.2 Rasche Wiederherstellbarkeit

Die folgende Darstellung wird gegenüber Fassung 1.0 unverändert fortgeführt, weil sie zutrifft:

Der genutzte Tarif des Datenbank-Anbieters enthält keine automatischen Sicherungen. Sicherungen der Datenbank erstellt der Auftragsverarbeiter manuell vor Änderungen an der Datenbankstruktur; sie werden außerhalb der Plattform verwahrt. Eine zugesagte Wiederherstellungszeit und ein zugesagter maximaler Datenverlust bestehen daher nicht: Bei einem Ausfall zwischen zwei manuellen Sicherungen können die seither erfassten Daten verloren gehen. Der Betrieb wird hierauf ausdrücklich hingewiesen.

Das ist eine dokumentierte und befristete Entscheidung, keine Nachlässigkeit: Die Anbieterauskunft („Free Plan does not include project backups. Upgrade to the Pro Plan for up to 7 days of scheduled backups.") und der Beschluss vom 09.09.2026, im unentgeltlichen Produkttest darauf zu verzichten, liegen in docs/AVV-FREIGABE-CHECKLISTE.md A2. Der Punkt kommt vor jeder Ausweitung über den Produkttest hinaus erneut auf den Tisch; ein Test wacht darüber, dass das nicht vergessen wird.

Ergänzend:

• Der Quelltext und die vollständige Migrationsgeschichte der Datenbankstruktur liegen in einer Versionsverwaltung. Die Anwendung ist daraus wiederherstellbar — allerdings nur in einer von Hand einzuhaltenden Reihenfolge: Es gibt weder einen Migrations-Runner noch eine Zustandstabelle, und zwei Dateien legen dieselbe Tabelle (reviews) mit unterschiedlichem Löschverhalten an. Gewinnt auf einer frischen Datenbank die spätere, fehlt das Weiterreichen der Löschung, und jede Löschung eines Gastes oder eines Betriebs scheitert. Die richtige Reihenfolge ist in supabase/migrations/022_reviews.sql dokumentiert; tests/betrieb/migrationsHygiene.test.ts bewacht nur neue Fälle. Siehe E.21.
• Die Daten sind ohnehin nur im Umfang der zuletzt erstellten manuellen Sicherung wiederherstellbar.
• Eine Wiederherstellungsprobe wurde bislang nicht durchgeführt. Eine Sicherung, die nie zurückgespielt wurde, ist eine Annahme und kein Nachweis. Siehe E.4.

D · Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art 32 Abs 1 lit d DSGVO)

D.1 Datenschutz-Management

• Alle Rollen in einer Hand. Stammkartl beschäftigt keine Personen. Die Vertraulichkeitsverpflichtung nach § 5 Abs 1 des Hauptvertrags trifft daher den Auftragsverarbeiter persönlich und wirkt über die Beendigung des Vertrags hinaus. Werden künftig Personen beauftragt, erfolgt dies erst nach schriftlicher Verpflichtung auf die Vertraulichkeit.
• Kein Datenschutzbeauftragter bestellt. Die Voraussetzungen des Art 37 Abs 1 DSGVO liegen nicht vor: keine Behörde, keine Kerntätigkeit umfangreicher regelmäßiger und systematischer Überwachung, keine umfangreiche Verarbeitung besonderer Datenkategorien. Diese Begründung ist dokumentiert und wird bei Wachstum erneut geprüft.
• Verzeichnis von Verarbeitungstätigkeiten wird geführt, getrennt nach Art 30 Abs 1 (eigene Verantwortlichkeit) und Art 30 Abs 2 (Auftragsverarbeitung). Die Ausnahme des Art 30 Abs 5 greift nicht, weil die Verarbeitung nicht nur gelegentlich erfolgt. Teil I ist vollständig; in Teil II fehlt die nach Art 30 Abs 2 lit a verlangte namentliche Liste der Verantwortlichen — die Angaben liegen in der Datenbank und sollen von dort erzeugt statt abgeschrieben werden. Siehe E.28.
• Automatisierte Prüfung bei jeder Änderung. Der Quelltext wird durch 120 Testdateien abgedeckt (Stand 02.10.2026, gezählt als *.test.ts und *.test.tsx unter tests/). Darunter befinden sich ausdrücklich: die Trennung der Betriebe, die Einwilligungslogik, die Versandwege, die Vertragsfassungen und die Hygiene der Datenbankmigrationen.
• Dokumentierte Durchgänge. Die Datenschutz- und Sicherheitsprüfungen liegen schriftlich im Projektverzeichnis (docs/recht/), einschließlich der jeweils offenen Punkte. Diese Anlage ist aus diesen Dokumenten abgeleitet.

Prüfintervall. Die Überprüfung nach Art 32 Abs 1 lit d erfolgt jährlich und zusätzlich anlassbezogen bei jeder Änderung an Empfängern, Zwecken oder Löschfristen (Festlegung vom 3. Oktober 2026).

Warum beides und nicht nur das eine. Ein reines Jahresintervall ginge an der Wirklichkeit dieses Produkts vorbei: Zwischen zwei Terminen kann ein Dienstleister wechseln, ein Zweck dazukommen oder eine Frist sich ändern — und genau das sind die Momente, in denen eine Maßnahme unpassend wird. Umgekehrt wäre „nur anlassbezogen" das, was bis heute galt, und es hat dazu geführt, dass es keinen festen Termin gab.

D.2 Incident-Response-Management (Art 33, Art 34 DSGVO)

Der Ablauf ist schriftlich festgelegt (docs/recht/DATA_BREACH_PROCESS.md) und unterscheidet die beiden Rollen:

Die 48 Stunden sind eine Höchstgrenze, kein Recht abzuwarten. Art 33 Abs 2 DSGVO verlangt die Meldung an den Verantwortlichen ohne jede Verzögerung; die Zahl benennt nur, wann die Verzögerung jedenfalls zu lang wäre.

Die Dokumentation jeder Verletzung — auch jeder nicht gemeldeten, mit Begründung — erfolgt nach Art 33 Abs 5 und wird nicht im öffentlich einsehbaren Projektverzeichnis abgelegt. Für Verletzungen, die Daten Ihrer Gäste oder Mitarbeiter betreffen, stellt Stammkartl Ihnen die zur Dokumentation nach Art 33 Abs 5 erforderlichen Angaben in Textform zur Verfügung; Bewertung und Aufbewahrung obliegen Ihnen. Die eigene Ablage bedeutet also keine Zurückhaltung von Informationen.

Erste Maßnahmen im Ernstfall sind festgelegt (Geheimnisse wechseln, Zeitpunkt der Kenntnis festhalten, Umfang bestimmen). Dass der Wechsel des Sitzungsgeheimnisses alle Betriebe abmeldet, ist dort ausdrücklich als hinzunehmende Folge vermerkt.

D.3 Datenschutzfreundliche Voreinstellungen (Art 25 DSGVO)

• Die Werbe-Einwilligung ist eine eigene, nicht vorausgewählte Entscheidung und von der Nutzung der Stempelkarte unabhängig. Wer sie nicht erteilt, erhält die Karte trotzdem.
• Das einzige einwilligungsbedürftige Cookie wird technisch erst nach der Zustimmung gesetzt. Die Sperre sitzt in der Schreib- und in der Lesefunktion selbst, nicht beim Aufrufer — sie kann deshalb nicht vergessen werden. Bei Ablehnung wird ein bereits vorhandenes Cookie aktiv gelöscht.
• Ein zweites Cookie (stempl_karte_<Betrieb>, Laufzeit ein Jahr) merkt sich die Karte eines Betriebs und wird ohne Einwilligung gesetzt, weil es als unbedingt erforderlich im Sinne des § 165 Abs 3 TKG 2021 eingestuft ist: Ohne dieses Cookie bekäme der Gast bei jedem Wiederkommen eine zweite, leere Karte. Es ist nicht gegen den Zugriff durch Skripte geschützt, weil die Beitrittsseite es im Browser liest und schreibt. Eine Verwendung über mehrere Betriebe hinweg gibt es nicht: Die Partnerseite, die das tat, ist seit 9. November 2026 abgeschaltet. Die Einstufung als „unbedingt erforderlich" ist eine Wertung; sie ist in DATENSCHUTZ-KARTEN-COOKIE.md begründet und steht hier, damit sie nicht stillschweigend erfolgt.
• Der Geburtstag ist freiwillig, eingeklappt und wird ohne Jahr gespeichert. Der Vorname ist freiwillig.
• Kein Nachname, keine E-Mail-Adresse, keine Telefonnummer werden von Karteninhabern über den Beitritt erhoben.
• Der Standortabgleich für die Sperrbildschirm-Anzeige findet ausschließlich auf dem Gerät des Gastes statt.
• Keine Reichweitenmessung, keine Werbenetzwerke, kein geräteübergreifendes Tracking; Schriftarten von der eigenen Domain.
• Mindestalter 14 Jahre. Die Teilnahme am Treueprogramm setzt das vollendete 14. Lebensjahr voraus (§ 4 Abs 4 DSG). Der Betrieb verpflichtet sich in den Nutzungsbedingungen, das nicht zu unterlaufen. Technisch geprüft wird das Alter nicht und kann es auch nicht werden, weil das Geburtsjahr bewusst nicht erhoben wird — die Datenminimierung und die Alterskontrolle stehen hier gegeneinander, und die Entscheidung ist zugunsten der Datenminimierung gefallen.
• Für den stündlichen Nachrichtenversand gelten je Betrieb konfigurierbare Sendefenster und Mindestabstände; der Betrieb entscheidet, was gesendet wird.

Drei Einschränkungen, ausdrücklich benannt:

1. Die Werbe-Entscheidung des Gastes wird auf einem Versandweg nicht geprüft. Der Rundruf aus der Plattformverwaltung lädt die Empfänger ohne jeden Filter auf die Nachrichten-Entscheidung — als einziger Versandweg im System. Ein Gast, der abbestellt hat, erhält eine solche Nachricht trotzdem. Eine Voreinstellung, die ein Weg umgehen kann, ist keine. Siehe E.6.
2. Die Fehlerüberwachung läuft im Browser jedes Gastes ab dem Seitenaufruf, auch wenn kein Fehler auftritt — bei etwa jedem zehnten Seitenaufruf wird zusätzlich eine Geschwindigkeitsmessung übertragen —, und auch auf Seiten, auf denen kein Einwilligungsbanner erscheint. Entlastend: Verarbeitung in der EU, keine Übermittlung personenbezogener Zusatzangaben, Zugriffstoken in Adressen maskiert. Siehe E.15.
3. Ein wirksames automatisches Löschkonzept besteht derzeit nicht. Es ist vollständig entwickelt, aber die zugehörigen Datenbankänderungen sind noch nicht ausgeführt; der Löschlauf endet daher ohne Wirkung. Fristen werden deshalb in dieser Anlage nicht als geltend behauptet. Siehe E.3.

D.4 Auftragskontrolle — Einbindung und Kontrolle von Dienstleistern

Echte Unterauftragsverarbeiter im Sinne des Art 28 Abs 4 DSGVO sind ausschließlich:

Der Zeitplan für die stündlichen Läufe liegt bei Vercel und damit auf derselben Plattform wie die Anwendung. Ein eigener Zeitplandienst ist nicht eingebunden; es kommt dafür kein zusätzlicher Dienstleister hinzu, und das Zeitplan-Geheimnis verlässt die Plattform nicht. Fristen, die am stündlichen Takt hängen, bleiben damit gültig, solange die Plattform läuft.

Keine Unterauftragsverarbeiter — eigenständige Empfänger mit eigener Verantwortlichkeit:

Diese Stellen arbeiten nicht auf Weisung von Stammkartl. Sie entscheiden selbst über Zwecke und Mittel; ein Auftragsverarbeitungsvertrag ist mit ihnen für diese Leistungen nicht möglich. Das ist die folgenreichste Rollenentscheidung dieser Anlage, und sie wird hier offen getroffen statt stillschweigend.

• Apple Distribution International Ltd., Hollyhill Industrial Estate, Cork, Irland. Apple räumt sich an Kartendaten eigene Zwecke ein und stellt für Wallet-Pässe und Benachrichtigungen keine Auftragsverarbeitungsklausel bereit. Ein Auftragsverarbeitungsvertrag mit Apple ist nicht möglich. Verarbeitung im EWR.
• Google Ireland Limited / Google LLC. Der Auftragsverarbeitungsvertrag für die Cloud-Dienste von Google deckt Wallet nachweislich nicht ab; ein Wallet-spezifischer Vertrag ist nicht erhältlich. Drittland USA, abgesichert über Data Privacy Framework und Standardvertragsklauseln. Google bietet keine Löschung von Wallet-Objekten an; möglich ist nur, ein Objekt auf „abgelaufen" zu setzen.
• OpenStreetMap Foundation, Vereinigtes Königreich — ausschließlich Adresssuche im Dashboard des Betriebs. Es werden dabei keine Gästedaten übermittelt.
• Push-Dienste der Browser (Apple, Google, Mozilla) — vom Browser des Gastes bestimmt und von Stammkartl weder auswählbar noch austauschbar. Der Inhalt ist für sie verschlüsselt.

Weitere Stelle mit Zugang zu Geheimnissen, ohne personenbezogene Daten: Codemagic baut die nativen Apps und hat dabei Zugriff auf die Signaturgeheimnisse. Personenbezogene Daten verarbeitet der Dienst nicht; er ist deshalb kein Auftragsverarbeiter, gehört wegen des Zugangs zu den Signaturgeheimnissen aber in diese Anlage.

Wie Stammkartl kontrolliert. Vor-Ort-Prüfungen bei den Anbietern finden nicht statt und wären für einen Auftragsverarbeiter dieser Größe auch nicht durchsetzbar. Die Kontrolle beschränkt sich auf:

1. den Abschluss bzw. die Archivierung des jeweiligen Auftragsverarbeitungsvertrags samt Abrufdatum,
2. die Prüfung der veröffentlichten Unterauftragsverarbeiter- und Regionsangaben bei jeder Änderung,
3. die Vorabinformation aller Betriebe vor dem Einsatz eines neuen Unterauftragsverarbeiters mit Widerspruchsrecht nach § 6 des Hauptvertrags.

Punkt 1 ist heute nicht erfüllt. Das ist der schwerstwiegende offene Punkt dieses Abschnitts, weil Art 28 Abs 3 DSGVO den Vertrag zwingend verlangt und sein Fehlen durch keine technische Maßnahme aufgewogen wird:

[OFFEN: Bestand und Datum der vier Auftragsverarbeitungsverträge (Supabase, Vercel, Sentry, Groq) — derzeit kein Nachweis abgelegt]

Was die Anbieter dazu angeben, und was davon belegt ist. Beide Anbieter betreiben die Rechenzentren nicht selbst: Supabase und Vercel laufen auf der Infrastruktur von Amazon Web Services. Supabase gibt für sich SOC 2 Type 2 und ISO 27001 an, Vercel SOC 2 Type 2 und ISO 27001:2013 (Herstellerangaben, abgerufen am 2. Oktober 2026).

Eingesehen hat Stammkartl keinen dieser Berichte. Bei Supabase ist das keine Nachlässigkeit, sondern eine Tarifgrenze: Der SOC-2-Bericht steht nach Angabe des Anbieters nur Kunden der Tarife Team und Enterprise im Kundenbereich zur Verfügung — Stammkartl nutzt den Free Plan. Vercel stellt den Bericht auf Anfrage bereit; angefragt wurde er nicht.

Diese Anlage behauptet deshalb keine Zertifizierung, sondern gibt wieder, was die Anbieter von sich sagen. Die Unterscheidung ist nicht pedantisch: Eine Herstellerangabe trägt keine eigene Prüfung des Auftragsverarbeiters nach Art 28 Abs 1 DSGVO.

[OFFEN: Die Berichte beschaffen und archivieren — bei Vercel auf Anfrage, bei Supabase erst ab dem Tarif Team. Bis dahin bleibt es bei der Herstellerangabe]

Weisungsbindung und ausgeschlossene Zwecke. Stammkartl verarbeitet die Daten Ihrer Gäste und Mitarbeiter ausschließlich auf dokumentierte Weisung des Betriebs.

Diese Anlage ist Bestandteil des Vertrags. Der folgende Absatz ist damit selbst eine vertragliche Zusage, nicht die Beschreibung einer anderswo stehenden.

Ausdrücklich ausgeschlossen sind: betriebsübergreifende Auswertungen, Produktverbesserung mit echten Gästedaten, Training von Modellen und Werbung in eigener Sache gegenüber den Gästen. Solche Tätigkeiten machten Stammkartl nach Art 28 Abs 10 DSGVO zum eigenen Verantwortlichen; fänden sie statt, wären sie dem Betrieb offenzulegen und nicht als stillschweigende Nebennutzung zu betreiben.

Hinweis zur Fassung 1.0: Dort war dieser Ausschluss nur in einem internen Dokument festgehalten und im Hauptvertrag nicht enthalten. Mit diesem Absatz wird er Vertragsinhalt. Es wird empfohlen, ihn zusätzlich als eigenen Absatz in § 3 des Hauptvertrags zu spiegeln.

E · Offene Punkte

Diese Liste gehört zur Anlage. Eine Darstellung technischer Maßnahmen, die ihre Lücken verschweigt, ist gegenüber dem Betrieb und gegenüber der Aufsichtsbehörde wertlos — die Lücken werden ohnehin gefunden, dann aber zusammen mit der Frage, was sonst noch beschönigt wurde.

Stand aller Einträge: 2. Oktober 2026.

Die Punkte E.1, E.2, E.3, E.4 und E.5 sollten vor einer Ausweitung über den Produkttest hinaus geschlossen sein. E.5 steht bewusst in dieser Reihe: Ob für den Dienstleister, der bei jeder einzelnen Anfrage Daten verarbeitet, überhaupt ein Vertrag nach Art 28 Abs 3 DSGVO besteht, wiegt schwerer als jede technische Maßnahme, die diese Anlage beschreibt.

Was seit Fassung 1.0 geschlossen wurde

Damit die Liste nicht nur wächst:

• Das Geheimnis für die zeitgesteuerten Läufe wird seit dem 02.10.2026 nur noch in der Kopfzeile angenommen; der Weg über die Adresse, auf dem es in fremde Protokolle gelangen konnte, ist geschlossen (B.1).
• Der Zeitplan liegt auf derselben Plattform wie die Anwendung. Ein eigener Zeitplandienst, der das Geheimnis hielt und echten Versand auslösen konnte, ist nicht mehr eingebunden (C.1, D.4).
• Ein Syntaxfehler in zwei vorbereiteten Datenbankänderungen, der bei der Ausführung alles davor zurückgerollt hätte, ist behoben; tests/betrieb/migrationsHygiene.test.ts wacht über die Wiederkehr.

F · Übersicht: Maßnahme — Umsetzung — Beleg

Fassung: 2026-11-10 · Stand: 10. November 2026 Diese Anlage ist Bestandteil des Auftragsverarbeitungsvertrags und wird mit diesem angenommen.