Auftragsverarbeitungsvertrag (Art. 28 DSGVO)

Dieser Vertrag wird zwischen der blockworx GmbH als Auftragsverarbeiterin und der Organisation, die ihn annimmt, als Verantwortlicher geschlossen. Er gilt für jede Verarbeitung personenbezogener Daten, die blockworx beim Betrieb der venMan-Plattform im Auftrag dieser Organisation vornimmt.

Vertragsgrundlage ist der Durchführungsbeschluss (EU) 2021/915 der EU-Kommission vom 4. Juni 2021 — die Standardvertragsklauseln zwischen Verantwortlichen und Auftragsverarbeitern nach Art. 28 Abs. 7 DSGVO. Diese Klauseln werden durch Verweis in diesen Vertrag einbezogen und gelten vollständig in der im Amtsblatt der Europäischen Union veröffentlichten Fassung.

Amtlichen Text auf EUR-Lex lesen

Der Klauseltext wird hier bewusst weder wiedergegeben noch umformuliert. Klausel 2 Buchstabe a des Beschlusses lässt eine Änderung der Klauseln nicht zu, und gerade eine Nacherzählung erzeugt die Abweichung zwischen angenommenem und amtlichem Text. Diese Seite füllt die vier Anhänge aus, die die Klauseln den Parteien überlassen.

Die Klauseln decken keine Übermittlung personenbezogener Daten in Drittländer ab (Erwägungsgrund 10 des Beschlusses). Jeder Unterauftragsverarbeiter außerhalb des EWR trägt deshalb eine eigene Übermittlungsgrundlage; sie steht in Anhang IV.

Eine Organisation nimmt eine bestimmte Fassung dieses Vertrags in der App unter Einstellungen → Auftragsverarbeitung an. Die Annahme wird mit Fassung, Sprache, annehmender Person und Zeitpunkt festgehalten. Einträge lassen sich danach weder ändern noch löschen; eine neue Fassung muss erneut angenommen werden und tritt neben den früheren Eintrag, statt ihn zu ersetzen.

Unterschrift und Datum sind der beschriebene Annahme-Eintrag. Ein gesondert unterzeichnetes Exemplar wird nicht ausgetauscht.

Die folgenden Maßnahmen sind die, die diese Plattform umsetzt und die sich in ihrem Quellcode und ihrem Datenbankschema nachvollziehen lassen.

• Die Trennung zwischen Organisationen setzt die Datenbank durch, nicht die Oberfläche. Die Tabellen, die die Daten der verantwortlichen Organisation führen, unterliegen Row-Level-Security-Richtlinien, die aktiviert und erzwungen sind und damit auch für die Eigentümerrolle der Tabelle gelten; die Richtlinien bestimmen handelnde Person und Organisation aus Werten, die pro Anfrage gesetzt werden, und nicht aus Angaben des Browsers. Eine kleine Zahl interner Tabellen, die dem Betrieb der Plattform dienen, liegt außerhalb dieses Mechanismus; sie ist im Quellcode der Plattform ausdrücklich aufgeführt, damit die Ausnahme sichtbar bleibt und nicht stillschweigend unterstellt wird.
• Die Anwendung verbindet sich mit einer Datenbankrolle, die selbst keine Rechte besitzt, Row Level Security nicht umgehen kann und keine Rechte automatisch erbt. Eine Anfrage, die gar nicht erst in den Kontext einer Organisation eintritt, läuft deshalb ganz ohne Rechte und wird mit einem Rechtefehler abgewiesen, statt unbemerkt Daten zu lesen, für die sie nie einen Bezug hatte.
• Berechtigungen werden je Aktion gegen ein Berechtigungsmodell geprüft, das im Zweifel sperrt: Eine unbekannte Person oder eine unbekannte Organisation wird abgelehnt und nicht zugelassen.
• Konten lassen sich mit einem zweiten Faktor absichern (zeitbasierte Einmalpasswörter). Passwörter, Wiederherstellungscodes und Terminal-PINs werden ausschließlich als Hash gespeichert; das Geheimnis für die Einmalpasswörter wird verschlüsselt abgelegt.
• Die Zugangsschlüssel der in Anhang IV genannten Unterauftragsverarbeiter und die eigenen Verschlüsselungsschlüssel der Plattform werden zur Laufzeit aus einem OpenBao-Tresor gelesen und liegen nicht im Quellcode-Repository. Zugangsdaten, die eine Organisation für ihre eigenen Drittsysteme hinterlegt, sind davon zu unterscheiden: Sie liegen in der Datenbank der Plattform, unter derselben Trennung zwischen Organisationen wie die übrigen Daten dieser Organisation.
• Ein administrativer Zugriff auf ein fremdes Konto wird an der Anfrage gekennzeichnet und im Audit-Protokoll festgehalten, bevor der Zugriff wirksam wird. Die Datenbank stellt eine solche Sitzung auf Nur-Lesen um, sodass ein Schreibvorgang von PostgreSQL selbst abgewiesen wird und nicht von der Oberfläche; die ändernden Aktionen mit der zusätzlichen Absicherung in der Anwendung verweigern die Ausführung schon davor.
• Sicherheitsrelevante Vorgänge werden in einem Audit-Protokoll festgehalten. Angemeldete Nutzerinnen und Nutzer haben keinen Weg, einen Eintrag zu ändern oder zu löschen: Die Datenbank erlaubt dort nur das Schreiben durch die Systemrolle und das Lesen durch Administratorinnen und Administratoren der Organisation, zu der der Eintrag gehört.
• Nach einer Kündigung des Abonnements stellt die Datenbank die Sitzungen der Organisation selbst auf Nur-Lesen um: Daten bleiben lesbar und exportierbar, neue Daten können nicht mehr geschrieben werden.

Dieser Anhang führt auf, was umgesetzt und nachweisbar ist. Maßnahmen, die nicht aufgeführt sind, werden nicht behauptet.

Die verantwortliche Organisation erteilt eine allgemeine Genehmigung für die folgenden Unterauftragsverarbeiter. blockworx informiert über beabsichtigte Änderungen dieser Liste nach Art. 28 Abs. 2 DSGVO, damit Einspruch möglich ist.

Die Vertragsgrundlage deckt Drittlandsübermittlungen nicht ab; jeder Eintrag trägt deshalb eine eigene Übermittlungsgrundlage.

Anbieter, die eine Organisation selbst mitbringt — etwa ihr Kassen-, Automaten- oder Zahlungssystem — sind keine Unterauftragsverarbeiter von blockworx. venMan liest von ihnen nur auf Weisung der Organisation Daten; sie handeln als eigene Verantwortliche auf Grundlage der Verträge der Organisation.

Anbieter, für die es in der Plattform zwar Codepfade gibt, die aber nicht in Betrieb sind, weil keine Zugangsdaten hinterlegt sind, sind keine Unterauftragsverarbeiter und stehen deshalb nicht hier. Ihre Einordnung ist für angemeldete Administratorinnen und Administratoren unter Einstellungen → Auftragsverarbeitung sichtbar.