Technische und organisatorische Maßnahmen (TOM)

Version: 1.0 Gültig ab: 2026-10-09 Anbieter: Paul Bengart, Keplerstraße 4A, 39104 Magdeburg, Deutschland

Einleitung

(1) Geltung. Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO, die der Anbieter für den Betrieb der Plattform Choicery (https://app.choicery.ai) getroffen hat. Es ist Anlage 1 des Auftragsverarbeitungsvertrags und gilt für alle Verarbeitungen, die der Anbieter im Auftrag seiner Kunden und als Verantwortlicher durchführt.

(2) Grundsatz. Beschrieben werden ausschließlich umgesetzte Maßnahmen.

(3) Betriebsmodell. Der Anbieter betreibt keine eigenen Rechenzentren. Die Anwendung und der Dateispeicher laufen auf einem gemieteten Server der netcup GmbH im Rechenzentrum Nürnberg, Deutschland. Die Datenbank ist eine verwaltete PostgreSQL-Datenbank der Ubicloud B.V. im Rechenzentrum Frankfurt am Main. Die Bereitstellung und Aktualisierung der Anwendung wird über Coolify Cloud (coolLabs Solutions Kft.) gesteuert. E-Mails werden über die Greenmark IT GmbH (do.de) versendet. Einzelheiten zu den Empfängern enthält die Liste der Unterauftragsverarbeiter und Empfänger.

(4) Gliederung. Die Gliederung folgt den Schutzzielen des Art. 32 DSGVO in der von der Datenschutzkonferenz verwendeten Ordnung: Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit, Verfahren zur regelmäßigen Überprüfung, ergänzt um Auftragskontrolle und Löschkonzept.

1 Vertraulichkeit

1.1 Zutrittskontrolle

Anwendungsserver und Dateispeicher stehen im Rechenzentrum der netcup GmbH in Nürnberg (Deutschland), die Datenbank im Rechenzentrum der Ubicloud B.V. in Frankfurt am Main (Deutschland).
Die physische Zutrittssicherung der Rechenzentren liegt in der Verantwortung der Provider und ist Gegenstand der Auftragsverarbeitungsverträge mit ihnen. Der Anbieter hat keinen physischen Zugang zu den Rechenzentren.
Der Anbieter greift auf die Systeme ausschließlich über verschlüsselte Fernverbindungen zu (Abschnitt 1.2).
Den verschlüsselten externen Datenträger mit Kopien der eigenen Sicherungen (Abschnitt 3.2) verwahrt der Anbieter selbst.

1.2 Zugangskontrolle

Plattform

Anmeldung mit E-Mail-Adresse und Passwort. Passwörter werden ausschließlich als gesalzener Hash gespeichert; eine Speicherung im Klartext findet nicht statt.
Alternativ Anmeldung über Google oder Microsoft (OAuth 2.0 / OpenID Connect). Der Anbieter erhält dabei keine Passwörter, sondern nur E-Mail-Adresse, Konto-ID und Anzeigenamen.
Ein neues Konto wird erst nach Bestätigung der E-Mail-Adresse freigeschaltet. Bestätigungslinks sind 24 Stunden gültig, Links zum Zurücksetzen des Passworts 60 Minuten; beide sind nur einmal verwendbar, und der Versand ist je Konto und Tag begrenzt.
Sitzungen werden serverseitig geführt und sind zeitlich begrenzt. Sitzungs-Cookies sind mit den Attributen Secure, HttpOnly und SameSite versehen und an den jeweiligen Host gebunden. Für Konto und Umfrageteilnahme werden getrennte Sitzungs-Cookies verwendet.
Alle Sitzungen eines Kontos können durch Erhöhen einer serverseitigen Sitzungsversion auf einmal ungültig gemacht werden, etwa nach einem Passwortwechsel oder bei Verdacht auf Missbrauch.
Formularbasierte Aktionen sind durch CSRF-Token mit begrenzter Gültigkeit geschützt.
Anmeldung, Registrierung, Passwort-Zurücksetzen und E-Mail-Versand unterliegen Ratenbegrenzungen je IP-Adresse und je Konto beziehungsweise E-Mail-Adresse.
Sicherheitsrelevante Kontoaktionen wie die Kontolöschung erfordern die erneute Eingabe des Passworts und eine Bestätigung.
Administrative Funktionen der Plattform sind ausschließlich für ausdrücklich benannte Administratorkonten des Anbieters freigeschaltet und werden bei jedem Aufruf gesondert autorisiert.

Infrastruktur

Der administrative Zugang zum Anwendungsserver erfolgt über SSH ausschließlich mit Schlüsselauthentifizierung.
Administrative Zugänge zur Anwendung und zu den Dienstleister-Konten sind mit Zwei-Faktor-Anmeldung geschützt.
Die Deployment-Steuerung (Coolify Cloud) greift als Unterauftragsverarbeiter administrativ auf den Anwendungsserver zu (Abschnitt 5).
Die Datenbank ist nur mit Zugangsdaten und über TLS mit Prüfung des Serverzertifikats erreichbar (Abschnitt 1.5).
Schlüssel und Zugangsdaten liegen ausschließlich in der Deployment-Konfiguration und nicht im Quellcode.

1.3 Zugriffskontrolle

Innerhalb eines Workspace gibt es die Rollen Owner, Admin, Member und Viewer mit abgestuften Rechten (Ansehen, Auswerten, Bearbeiten, Verwalten, Exportieren, Löschen). Jeder Zugriff auf ein Projekt wird serverseitig anhand von Nutzer, Workspace-Mitgliedschaft und Rolle geprüft; Projekte sind eindeutig einem Workspace beziehungsweise Nutzer zugeordnet.
Teilnehmer öffentlicher Befragungen erhalten ausschließlich die Befragungsinhalte des jeweiligen Projekts und haben keinen Zugriff auf Projektdaten, Antworten anderer Teilnehmer oder Auswertungen.
Download-Links für Exporte und Berichte sind an die angemeldete Sitzung gebunden, nur einmal verwendbar und kurz befristet.
Für den Datenabruf über die Export-Schnittstelle (API) erzeugt der Nutzer persönliche Zugriffstoken. Tokens werden nur als Hash gespeichert und können jederzeit widerrufen werden.
Für die optionale Verbindung mit Google Sheets muss Choicery ein Aktualisierungstoken (Refresh Token) von Google später wieder vorlegen; es kann deshalb nicht als Hash gespeichert werden, sondern wird umkehrbar verschlüsselt (Abschnitt 1.5). Die Berechtigung drive.file umfasst von der App angelegte oder ausdrücklich ausgewählte Dateien; diese Verbindung nutzt ausschließlich die von ihr selbst angelegten Tabellen. Verbinden und Aktualisieren setzen das Exportrecht für das Projekt voraus; Beenden und Trennen sind an die eigene Verbindung gebunden und bleiben auch nach Verlust des Exportrechts möglich. Alle diese Aktionen sind durch CSRF-Token geschützt. Passwortänderung, Zurücksetzen des Passworts, "Sign out everywhere" und Kontolöschung beenden die Freigabe im selben Schritt; der Widerruf bei Google folgt aus einer Warteschlange.
Der administrative Zugriff des Anbieters wird nur für Betrieb, Support auf Anforderung des Kunden und Sicherheitsprüfungen genutzt; administrative Handlungen werden als Audit-Ereignisse protokolliert (Abschnitt 2.1).
Personen, die Zugriff erhalten, sind zur Vertraulichkeit verpflichtet und erhalten nur die für ihre Aufgabe erforderlichen Rechte.

1.4 Trennungskontrolle

Die Daten aller Kunden werden in einer gemeinsamen Datenbank und einem gemeinsamen Dateispeicher logisch getrennt. Jeder Datensatz ist über eindeutige Kennungen einem Nutzer, Workspace und Projekt zugeordnet; jede Abfrage wird auf diese Zuordnung geprüft.
Entwicklung und Tests erfolgen auf getrennten Systemen des Anbieters; die Produktivumgebung wird nicht für Tests genutzt.

1.5 Pseudonymisierung und Verschlüsselung

Verschlüsselung bei der Übertragung

Alle öffentlichen Endpunkte sind ausschließlich über HTTPS erreichbar. Die Anwendung setzt HTTP Strict Transport Security mit einer Gültigkeit von einem Jahr einschließlich Subdomains.
Die Verbindung zwischen Anwendung und Datenbank ist mit TLS verschlüsselt; das Serverzertifikat wird gegen ein hinterlegtes Zertifikatsbündel geprüft, einschließlich der Prüfung des Hostnamens.
E-Mails werden über eine TLS-gesicherte Verbindung an den E-Mail-Provider übergeben.
Der administrative Zugang erfolgt über SSH (Abschnitt 1.2).

Verschlüsselung ruhender Daten

Die Verschlüsselung der Datenträger in den Rechenzentren richtet sich nach der Konfiguration der jeweiligen Provider und ist Gegenstand der Auftragsverarbeitungsverträge mit ihnen.
Passwörter werden gehasht gespeichert (Abschnitt 1.2). Prüfsummen für Antworten und Audit-Ereignisse werden mit einem serverseitigen geheimen Schlüssel gebildet (Abschnitt 2.1).
Zwei Arten von Tokens werden unterschiedlich geschützt: Persönliche Zugriffstoken für die Export-Schnittstelle von Choicery werden nur als Einweg-Hash gespeichert und lassen sich daraus nicht wiederherstellen (Abschnitt 1.3). Aktualisierungstoken von Google für die Verbindung mit Google Sheets werden umkehrbar verschlüsselt gespeichert (Fernet; der Schlüssel wird mit HKDF aus dem geheimen Schlüssel der Anwendung abgeleitet, je Verwendungszweck getrennt). Wird der geheime Schlüssel gewechselt, bleiben ältere Tokens mit dem vorherigen Schlüssel lesbar und werden beim nächsten Lesen mit dem aktuellen Schlüssel neu verschlüsselt. Zugriffstoken von Google werden nicht gespeichert; sie bestehen nur während einer Aktualisierung kurz im Arbeitsspeicher. Die Verschlüsselung schützt Datenbankinhalte und Sicherungen; gegen einen kompromittierten Anwendungsserver, der den Schlüssel hält, schützt sie nicht.

Pseudonymisierung und Datenminimierung

Antwortdatensätze enthalten keine IP-Adresse, keine vollständige Browserkennung und keinen Geräte-Fingerabdruck. Teilnehmer werden über eine vom System vergebene Antwortkennung identifiziert und, nur wenn der Kunde dies für sein Projekt konfiguriert, über einen vom Kunden übergebenen Panel-Code.
IP-Adressen werden für die technische Verbindung und für kurzlebige Sicherheitskontrollen (Ratenbegrenzung) verarbeitet. Anwendungsprotokolle werden täglich rotiert und höchstens 14 Tage aufbewahrt; Container-Protokolle werden nach Größe rotiert (Abschnitt 4.2).
Audit- und Sicherheitsereignisse zu Konten können die IP-Adresse und die Browserkennung enthalten. IP-Adressen werden dort nach 90 Tagen automatisch gekürzt (IPv4 auf ein /24-Netz, IPv6 auf ein /48-Netz).
Fehlerberichte und CSP-Meldungen werden vor der Speicherung um Zugangsdaten, Token und ähnliche Geheimnisse bereinigt.

2 Integrität

2.1 Eingabe- und Änderungskontrolle

Anmeldungen, Kontoänderungen, administrative Handlungen, Exporte, Löschungen und Änderungen an Antwortdaten werden als Audit-Ereignisse protokolliert. Jedes Audit-Ereignis trägt eine HMAC-SHA256-Signatur, die mit einem serverseitigen geheimen Schlüssel gebildet wird; nachträgliche Änderungen an Ereignissen sind dadurch erkennbar.
Jeder Antwortdatensatz erhält bei der Speicherung eine HMAC-SHA256-Prüfsumme über seinen Inhalt. Änderungen im Dateneditor werden mit Prüfwerten vor und nach der Änderung protokolliert.
Antworten werden zusätzlich zur Datenbank als dateibasierte Sicherungskopie je Projekt gespeichert. Ein Wartungsprozess gleicht Datenbank und Sicherungskopie regelmäßig ab und erfasst Abweichungen.
Vom Kunden gelöschte Antworten werden zunächst als gelöscht markiert und kommen in den Papierkorb des Projekts. Dort bleiben sie wiederherstellbar, bis der Kunde sie endgültig löscht oder den Papierkorb leert. Importierte Antworten werden ohne Papierkorb sofort endgültig gelöscht.
Eingaben werden serverseitig validiert. Vom Kunden eingegebenes HTML wird anhand einer Positivliste zulässiger Elemente und Attribute bereinigt; CSS-Werte werden geprüft. Ausgaben in Seiten werden automatisch maskiert.
Single-Choice-Antworten werden als stabiler Index der ursprünglichen Antwortoption gespeichert, nicht als angezeigter Text, sodass Umbenennungen und zufällige Reihenfolgen die gespeicherten Werte nicht verändern.

2.2 Weitergabekontrolle

Alle Übertragungen sind nach Abschnitt 1.5 verschlüsselt.
Alle Seiten der Plattform werden mit einer strikten, nonce-basierten Content Security Policy ausgeliefert. Skripte und Stile werden nur mit einem je Anfrage neu erzeugten Nonce ausgeführt; fremde Inhalte dürfen nur von den ausdrücklich freigegebenen Videoanbietern eingebettet werden, und dies erst nach einem Klick des Teilnehmers.
Exporte können nur von berechtigten Nutzern erzeugt werden; Download-Links sind sitzungsgebunden und einmalig (Abschnitt 1.3). Erzeugte Exportdateien werden nach 30 Tagen gelöscht.
In die Anwendung und die Umfrageseiten sind derzeit keine Analyse-, Tracking- oder Werbedienste, keine fremden Schriftarten und keine externen KI-Dienste eingebunden. Ausgenommen sind die Marketing-Seiten der Website auf einem eigenen Host: Dort wird Google Analytics 4 erst nach Einwilligung des Besuchers im Cookie-Banner geladen; die dabei gesetzten Cookies sind auf diesen Host beschränkt und erreichen weder die Anwendung noch Umfragen. Die Nutzung der Anwendung wertet der Anbieter selbst aus: Seitenaufrufe und Aktionen angemeldeter Nutzer werden serverseitig ohne Drittanbieter, ohne IP-Adresse, ohne Browserkennung und ohne Inhalte in der eigenen Datenbank gezählt, nach 90 Tagen gelöscht und nur aggregiert an Plattform-Administratoren angezeigt; Nutzer können im Profil widersprechen. Umfrageantworten werden nicht per E-Mail versendet.

3 Verfügbarkeit und Belastbarkeit

3.1 Verfügbarkeit

Die Web-Anwendung läuft mit mehreren parallelen Arbeitsprozessen; Container werden bei Ausfall automatisch neu gestartet.
Rechenintensive Auswertungen laufen getrennt von der Web-Anwendung mit einer begrenzten Zahl gleichzeitiger Aufträge; weitere Aufträge werden in eine Warteschlange gestellt. Speicherlimits je Prozess, Zeitlimits je Anfrage und eine Größenbegrenzung für Uploads schützen den Betrieb vor Überlast.
Ratenbegrenzungen an Anmelde- und Umfrageendpunkten begrenzen automatisierte Zugriffe.
Der Anbieter gibt keine Verfügbarkeitszusage ab. Wartung und Support beschreibt die Support- und Wartungsrichtlinie.

3.2 Datensicherung

Die Datenbank wird im Rahmen der Point-in-time-Recovery des Datenbankanbieters gesichert. Sie kann auf einen beliebigen Zeitpunkt innerhalb des vom Datenbankanbieter vorgehaltenen Aufbewahrungsfensters zurückgesetzt werden.
Der Anbieter erstellt zusätzlich täglich eigene Sicherungen der Datenbank und der Projektdateien auf dem Anwendungsserver. Kopien dieser Sicherungen liegen auf einem verschlüsselten externen Datenträger des Anbieters.
Eigene Sicherungen auf dem Anwendungsserver werden höchstens 30 Tage aufbewahrt. Kopien auf einem verschlüsselten externen Datenträger werden bei jeder neuen Kopie ersetzt und spätestens nach 45 Tagen gelöscht.
Antworten liegen zusätzlich als dateibasierte Sicherungskopie je Projekt auf dem Anwendungsserver (Abschnitt 2.1).
Kunden können ihre Daten jederzeit über die Exportfunktionen der Plattform sichern (CSV, JSON, Excel, SPSS, Replikationspakete, Projektexport).

3.3 Wiederherstellung

Die Datenbank kann aus der Point-in-time-Recovery des Datenbankanbieters auf einen Zeitpunkt innerhalb des Aufbewahrungsfensters oder aus den eigenen Sicherungen des Anbieters wiederhergestellt werden.
Die Anwendung wird aus versionierten Container-Images bereitgestellt und kann über die Deployment-Steuerung erneut ausgerollt werden; die Konfiguration ist dort hinterlegt.
Projektdateien können aus den eigenen Sicherungen des Anbieters wiederhergestellt werden.
Antworten, deren Datenbankeintrag verloren geht, können aus der dateibasierten Sicherungskopie je Projekt wieder in die Datenbank übernommen werden.
Nach einer Wiederherstellung werden dokumentierte Löschungen erneut vollzogen.

4 Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung

4.1 Incident Response

Sicherheitsvorfälle und Schwachstellen werden an security@choicery.ai gemeldet. Die Kontaktangaben stehen zusätzlich in der security.txt.
Ablauf bei einem Vorfall: Erkennen (Audit-Ereignisse, Fehlerberichte, Statusprüfungen, Hinweise Dritter), Eindämmen (Sperren von Konten, Ungültigmachen von Sitzungen, Wechsel von Zugangsdaten und Schlüsseln, Abschalten betroffener Funktionen), Analysieren, Beheben und Dokumentieren.
Betroffene Kunden werden unverzüglich über den Workspace-Owner informiert, weitere Informationen werden nachgereicht (§ 7 des Auftragsverarbeitungsvertrags).

4.2 Protokollierung

Anwendungsprotokolle werden täglich rotiert und höchstens 14 Tage aufbewahrt. Container-Protokolle werden nach Größe rotiert und belegen höchstens 30 MB je Dienst; eine feste Altersgrenze besteht für sie nicht.
Fehlerberichte werden nach 90 Tagen automatisch gelöscht.
Audit- und Sicherheitsereignisse werden bis zu 3 Jahre nach Ende des Kalenderjahres des Ereignisses aufbewahrt (Nachweis, Missbrauchsabwehr, Rechtsverteidigung). Enthaltene IP-Adressen werden nach 90 Tagen automatisch gekürzt (Abschnitt 1.5).
Protokolle der Provider (netcup, Ubicloud, coolLabs, do.de) unterliegen deren Fristen.
Zugriff auf Protokolle haben nur der Anbieter und, im Rahmen des administrativen Fernzugriffs, der Betreiber der Deployment-Steuerung.

4.3 Schwachstellenmanagement

Wesentliche Abhängigkeiten der Anwendung werden versioniert. Sicherheitsupdates für Anwendung, Container-Basisimages und Serverbetriebssystem werden zeitnah nach Bekanntwerden eingespielt.
Vor Releases werden automatisierte Tests ausgeführt.
Responsible Disclosure: Hinweise auf Schwachstellen nimmt der Anbieter unter security@choicery.ai entgegen (Angaben in der security.txt) und bearbeitet sie nach Schwere.

4.4 Datenschutz-Management und Überprüfung

Datenschutzkontakt: privacy@choicery.ai (Paul Bengart).
Dieses Dokument, die Liste der Unterauftragsverarbeiter und die Aufbewahrungs- und Löschfristen werden regelmäßig sowie anlassbezogen überprüft (Wechsel eines Providers, Sicherheitsvorfall, neue Funktion mit Datenbezug, Rechtsänderung). Änderungen werden mit Datum veröffentlicht.
Neue Funktionen mit Datenbezug werden vor der Freigabe auf ihre datenschutzrechtlichen Auswirkungen geprüft, einschließlich der Frage, ob eine Datenschutz-Folgenabschätzung erforderlich ist.

5 Auftragskontrolle

Der Anbieter verarbeitet Studien- und Antwortdaten als Auftragsverarbeiter seiner Kunden auf Grundlage des Auftragsverarbeitungsvertrags. Die Weisungen der Kunden erfolgen über die Plattform oder in Textform.
Unterauftragsverarbeiter werden nach Art. 28 Abs. 4 DSGVO vertraglich gebunden. Die Liste der Unterauftragsverarbeiter und Empfänger weist je Unterauftragsverarbeiter Leistung, Datenkategorien, Standort und Transfergrundlage aus. Änderungen werden nach § 8 des Auftragsverarbeitungsvertrags angekündigt.
Unterauftragsverarbeiter mit Zugriffsmöglichkeit auf personenbezogene Daten sind: netcup GmbH (Anwendungsserver und Dateispeicher), Ubicloud B.V. (Datenbank; Vertragspartner im Europäischen Wirtschaftsraum; Fernzugriff durch den Support des Datenbankanbieters aus den USA möglich, abgesichert durch die konzerninternen Standardvertragsklauseln des Datenbankanbieters nach Ziff. 6.1 seines Auftragsverarbeitungsvertrags), coolLabs Solutions Kft. (Coolify Cloud; Deployment-Steuerung mit administrativem Zugriff auf den Anwendungsserver) und Greenmark IT GmbH (E-Mail-Versand und Postfächer).
Polar Software, Inc. (USA) ist Auftragsverarbeiter des Anbieters für Konto-, Checkout- und Subscription-Daten (EU-Standardvertragsklauseln nach dem Polar Data Processing Addendum) und zugleich als Merchant of Record eigenständig Verantwortlicher für den Verkauf der Tarife; Studien- und Antwortdaten erhält Polar nicht.
Eigenständig Verantwortliche (Google Ireland Limited und Microsoft Ireland Operations Limited für die Anmeldung) und teilnehmerseitige Videoanbieter nach Klick sind keine Unterauftragsverarbeiter und in der Liste gesondert ausgewiesen.
Bei der Verbindung mit Google Sheets ist Google ein vom Kunden gewählter Empfänger und kein Unterauftragsverarbeiter (§ 5 Abs. 5 des Auftragsverarbeitungsvertrags). Jede Verbindung wird als Weisung mit Nutzer, Projekt, gewähltem Google-Konto, Zeitpunkt und Textfassung der Bestätigung dokumentiert.

6 Löschkonzept

Die Aufbewahrungs- und Löschfristen sind in den Aufbewahrungs- und Löschfristen beschrieben. Kernpunkte: keine automatische Löschung von Antworten während des Vertrags; vom Kunden gelöschte Antworten bleiben im Papierkorb, bis der Kunde ihn leert; vom Kunden gelöschte Projekte bleiben mindestens 30 Tage wiederherstellbar und werden danach, spätestens nach 60 Tagen, endgültig gelöscht; Kontolöschung mit 30 Tagen Schonfrist und anschließender endgültiger Löschung unverzüglich, spätestens innerhalb von 30 Tagen, bei gewählter Sofortlöschung spätestens 30 Tage nach dem Antrag; erzeugte Exportdateien nach 30 Tagen; Anwendungsprotokolle höchstens 14 Tage (tägliche Rotation), Container-Protokolle größenrotiert mit höchstens 30 MB je Dienst; Fehlerberichte nach 90 Tagen; Audit-Ereignisse bis zu 3 Jahre nach Ende des Kalenderjahres des Ereignisses, mit IP-Kürzung nach 90 Tagen; eigene Sicherungen höchstens 30 Tage; nach Vertragsende 30 Tage Abruf und anschließend Löschung spätestens innerhalb von 30 Tagen.
Bei der endgültigen Löschung eines Kontos werden Datenbankeinträge gelöscht, Projektdateien vom Datenträger entfernt und personenbezogene Kennungen in Audit-Ereignissen und in Bestelldaten aus Polar pseudonymisiert.
Gelöschte Daten können bis zum Ablauf der jeweiligen Sicherung in Sicherungen enthalten bleiben und werden mit dieser gelöscht. Nach einer Wiederherstellung werden dokumentierte Löschungen erneut vollzogen.
Auf Anforderung bestätigt der Anbieter die Löschung in Textform.