Wird geladen…
Wird geladen…
Anlage 2 zum Auftragsverarbeitungsvertrag — Art. 32 DSGVO.
Fassung 1.0gültig seit 15.09.2026aktuelle Fassung aus pllaybook
Diese Aufstellung ist Anlage 2 zum Auftragsverarbeitungsvertrag und beschreibt, wie wir die Daten schützen. Sie benennt auch die Grenzen des heutigen Standes — das ist Absicht: eine Maßnahmenliste, die nur Erfülltes aufzählt, ist im Streitfall wertlos.
Version
1.0· Stand 22.08.2026 Ab wann diese Fassung gilt, steht im Fassungs-Register und auf der Website — nicht hier: ein Datum im Text veraltet in dem Moment, in dem sich die Freigabe verschiebt. Diese Anlage beschreibt die Maßnahmen nach Art. 32 DSGVO. Sie ist Anlage 2 zum Auftragsverarbeitungsvertrag und wird mit ihm zugestimmt, nicht gesondert.
Bis zur Fassung 1.0 des AVV stand dieser Text als Anlage im Vertrag. Er ist herausgelöst worden, weil er sich häufiger ändert als der Vertrag: Eine verbesserte Maßnahme soll nicht jeden Verein zu einer neuen Zustimmung zwingen. § 7.3 AVV regelt dafür die Anzeige.
Jede Aussage hier ist am 22.08.2026 gegen die laufende Infrastruktur oder den Quelltext geprüft. Sie gilt in der jeweils aktuellen Fassung; Änderungen sind zulässig, solange das Schutzniveau nicht unterschritten wird.
Warum hier auch steht, was fehlt. Eine Maßnahmenliste, die mehr behauptet, als die Software hält, ist keine Zusicherung, sondern eine Vertragsverletzung mit Anlauf. Abschnitt 8 nennt deshalb die bekannten Grenzen. Ein Verein, der prüft, findet sie ohnehin — besser er findet sie hier.
1.1 Übertragung. Sämtlicher Verkehr zwischen Browser und Anwendung läuft ausschließlich über TLS. Die Datenbank nimmt ausschließlich verschlüsselte Verbindungen an (sslMode: ENCRYPTED_ONLY) — eine unverschlüsselte Verbindung wird abgewiesen, nicht bloß nicht angeboten.
1.2 Ruhende Daten. Datenbanken, Dateiablagen und Sicherungen sind auf Ebene der Infrastruktur verschlüsselt (Google-verwaltete Schlüssel). Alle Ablagen liegen in der Europäischen Union, die Datenbank in europe-west3 (Frankfurt am Main).
1.3 Bankverbindungen. Vollständige IBAN werden zentral gehalten; in der operativen Vereinsdatenbank stehen sie ausschließlich maskiert. Ein Auszug aus der operativen Datenbank enthält damit keine vollständige Bankverbindung.
2.1 Anmeldung. Ausschließlich über den Anmeldedienst (Firebase Authentication) mit individuellen Konten. Es gibt kein gemeinsam genutztes Konto und keinen Zugang ohne Person dahinter.
2.2 Zugänge des Betreibers. Zugriffe auf Produktivsysteme erfolgen über persönliche Kennungen und werden protokolliert. Es gibt keine geteilten Betreiber-Zugangsdaten.
2.3 Zutritt. Keine eigenen Server. Die Verarbeitung findet in zertifizierten Rechenzentren des Cloud-Anbieters statt (ISO 27001, SOC 2); die physische Sicherheit obliegt diesem.
3.1 Trennung der Vereine setzt die Datenbank durch. Nicht erst die Anwendung: Jeder Zugriff ist über Row-Level-Security an genau einen Verein gebunden. Ein fehlender Vereinskontext liefert keine Daten statt aller Daten — der Fehlerfall ist die leere Menge, nicht der Vollzugriff.
3.2 Rechte je Rolle. Jedes Recht ist einzeln zuteilbar. Ein Zugang entsteht durch Zuweisung, nicht durch Zugehörigkeit.
3.3 Getrennte Datenbestände. Plattformweite und vereinsbezogene Daten liegen in getrennten Datenbanken. Entwicklungs-, Test- und Produktivumgebung sind vollständig getrennt — eigene Datenbanken, eigene Zugangsdaten, eigene Speicher.
3.4 Dateien. Vertrauliche Dateien (Atteste, Nachweise, Belege) liegen in einer nicht öffentlich lesbaren Ablage und werden über kurzlebige, individuell erzeugte Abruf-Adressen ausgeliefert. Für Wappen, Avatare, Event-Bilder und Mediathek gibt es eine bewusst öffentlich lesbare Ablage — siehe Abschnitt 8.
4.1 Nachvollziehbarkeit. Verändernde Vorgänge werden mit handelnder Person, Zeitpunkt und Bezug protokolliert.
4.2 Belege sind unveränderlich. Eine Korrektur erfolgt durch Ungültigsetzen und Neuausstellen, nicht durch Überschreiben.
4.3 Rechtsfassungen sind unveränderlich. Zu jeder Fassung wird eine Prüfsumme über den Wortlaut geführt. Eine nachträgliche Änderung an einer bereits zugestimmten Fassung ist damit prüfbar und nicht Vertrauenssache; eine Änderung erzeugt eine neue Fassung, die alte bleibt als Nachweis.
4.4 Keine Zahlungsdienstleistung. Erzeugt werden SEPA-Dateien, die der Verein bei seiner Bank einreicht. Es findet kein Geldfluss über den Auftragsverarbeiter statt.
5.1 Sicherungen. Automatische tägliche Sicherung der Datenbank durch den Cloud-Anbieter, Aufbewahrung von sieben Sicherungen, Ablage in der EU.
5.2 Wiederherstellung auf den Zeitpunkt. Point-in-Time-Recovery ist eingeschaltet, die Transaktionsprotokolle werden sieben Tage vorgehalten. Ein Datenverlust durch eine fehlerhafte Änderung lässt sich damit auf den Moment davor zurücknehmen, nicht nur auf die letzte Nachtsicherung.
5.3 Ausrollen. Über unveränderliche Abbilder mit Rückrollmöglichkeit auf den vorherigen Stand.
6.1 Automatisierte Prüfungen bei jeder Änderung. Die Mandantentrennung und die Zugriffsrechte werden bei jeder Änderung maschinell geprüft; eine Änderung, die eine Trennung aufhebt, wird vor dem Ausrollen abgewiesen.
6.2 Stückliste der Fremdkomponenten. Eine Stückliste aller eingesetzten Komponenten samt Fassung, Lizenz und Risikobewertung wird versioniert geführt. Die daraus folgenden Nennungspflichten stehen in den Lizenzhinweisen.
7.1 Unterauftragsverarbeiter. Wer außer dem Auftragsverarbeiter Daten verarbeitet, steht namentlich in Anlage 1, mit Leistung, verarbeiteten Daten, Ort und Grundlage.
7.2 Künstliche Intelligenz. KI-gestützte Funktionen laufen über Vertex AI in europe-west3, angemeldet über das Dienstkonto der Anwendung und ohne API-Schlüssel — also unter dem bestehenden Auftragsverarbeitungsvertrag mit dem Cloud-Anbieter, nicht unter den Bedingungen der Endkunden-Schnittstelle.
7.3 Weisungen. Verarbeitung ausschließlich auf dokumentierte Weisung des Vereins; die Wege dafür stehen in § 4 AVV.
Diese Aufstellung gehört zur Ehrlichkeit dieses Dokuments.
| Grenze | Was das bedeutet |
|---|---|
| Wappen, Avatare, Event-Bilder und Mediathek liegen in einer öffentlich lesbaren Ablage. Wer die vollständige Adresse kennt, kann die Datei abrufen. | Das ist für Wappen und Vereinsbilder gewollt. Für Avatare von Mitgliedern heißt es: Die Adresse ist nicht erratbar, aber ein einmal geteilter Link bleibt gültig. Atteste, Nachweise und Belege sind davon nicht betroffen — sie liegen in der geschützten Ablage. |
Hochverfügbarkeit über mehrere Zonen ist nicht eingerichtet (availabilityType: ZONAL). | Der Ausfall einer Zone bedeutet eine Unterbrechung, keinen Datenverlust. |
| Eine Wiederherstellung aus der Sicherung ist als Verfahren vorhanden, aber noch nicht in einer Übung erprobt. | Die Wiederherstellungsdauer ist nicht gemessen. |
| Protokolliert werden verändernde Vorgänge, nicht plattformweit auch lesende Zugriffe. | Für rein lesende Zugriffe ist im Nachhinein nicht in jedem Fall feststellbar, wer sie vorgenommen hat. |
| Ein Werkzeug, mit dem ein Verein eine Auskunft für eines seiner Mitglieder anfordert, gibt es nicht. | Die Unterstützung nach Art. 28 Abs. 3 lit. e erfolgt auf Anfrage und von Hand. Bei mehr als vereinzelten Anfragen ist ein Werkzeug zu bauen. |
Diese Grenzen werden abgearbeitet. Der jeweils erreichte Stand ist Gegenstand der Fortschreibung dieser Anlage; erhebliche Änderungen werden nach § 7.3 AVV angezeigt.
| Version | Stand | Änderung |
|---|---|---|
| 1.0 | 22.08.2026 | Erstfassung. Herausgelöst aus Anlage 2 des AVV 1.0, gegliedert nach Art. 32 Abs. 1 lit. a–d, gegen die laufende Infrastruktur geprüft. Der Vermerk „Point-in-Time-Recovery vor Produktivstart einzurichten" ist entfallen — sie ist eingerichtet. |
Dieser Text wird bei jedem Aufruf aus pllaybook gelesen. Er ist die Fassung, der in der Anwendung zugestimmt wird — eine Abschrift auf dieser Seite gibt es bewusst nicht.