Technical and Organisational Measures (TOMs)

Version: 1.0 Effective from: 2026-10-09 Provider: Paul Bengart, Keplerstraße 4A, 39104 Magdeburg, Germany

Introduction

(1) Scope. This document describes the technical and organisational measures under Article 32 GDPR that the Provider has implemented for the operation of the Choicery platform (https://app.choicery.ai). It is Annex 1 to the Data Processing Agreement and applies to all processing that the Provider carries out on behalf of its Customers and as controller.

(2) Principle. Only implemented measures are described.

(3) Operating model. The Provider does not operate its own data centres. The application and the file storage run on a rented server of netcup GmbH in the data centre in Nuremberg, Germany. The database is a managed PostgreSQL database of Ubicloud B.V. in the data centre in Frankfurt am Main. Deployment and updating of the application are controlled via Coolify Cloud (coolLabs Solutions Kft.). E-mails are sent via Greenmark IT GmbH (do.de). Details of the recipients are set out in the list Subprocessors and Recipients.

(4) Structure. The structure follows the protection objectives of Article 32 GDPR in the order used by the German Data Protection Conference (Datenschutzkonferenz): confidentiality, integrity, availability and resilience, procedures for regular review, supplemented by control of processors and the deletion concept.

1 Confidentiality

1.1 Physical Access Control

The application server and file storage are located in the data centre of netcup GmbH in Nuremberg (Germany), the database in the data centre of Ubicloud B.V. in Frankfurt am Main (Germany).
Physical access security of the data centres is the responsibility of the providers and is the subject of the data processing agreements with them. The Provider has no physical access to the data centres.
The Provider accesses the systems exclusively via encrypted remote connections (section 1.2).
The Provider itself keeps the encrypted external storage medium holding copies of its own backups (section 3.2).

1.2 Logical Access Control

Platform

Sign-in with e-mail address and password. Passwords are stored exclusively as a salted hash; they are not stored in plain text.
Alternatively, sign-in via Google or Microsoft (OAuth 2.0 / OpenID Connect). The Provider does not receive any passwords in this process, only the e-mail address, account ID and display name.
A new account is activated only after the e-mail address has been verified. Verification links are valid for 24 hours, password reset links for 60 minutes; both can be used only once, and sending is limited per account and per day.
Sessions are managed server-side and are limited in time. Session cookies carry the Secure, HttpOnly and SameSite attributes and are bound to the respective host. Separate session cookies are used for the account and for survey participation.
All sessions of an account can be invalidated at once by incrementing a server-side session version, for example after a password change or on suspicion of abuse.
Form-based actions are protected by CSRF tokens with limited validity.
Sign-in, registration, password reset and e-mail sending are subject to rate limits per IP address and per account or e-mail address.
Security-relevant account actions such as account deletion require re-entry of the password and a confirmation.
Administrative functions of the platform are enabled exclusively for expressly designated administrator accounts of the Provider and are separately authorised on every call.

Infrastructure

Administrative access to the application server takes place via SSH exclusively with key-based authentication.
Administrative access to the application and to the accounts with service providers is protected by two-factor authentication.
Deployment control (Coolify Cloud) accesses the application server administratively as a sub-processor (section 5).
The database is reachable only with credentials and via TLS with verification of the server certificate (section 1.5).
Keys and credentials reside exclusively in the deployment configuration and not in the source code.

1.3 Authorisation Control

Within a workspace there are the roles Owner, Admin, Member and Viewer with graduated permissions (view, analyse, edit, manage, export, delete). Every access to a project is checked server-side on the basis of user, workspace membership and role; projects are uniquely assigned to a workspace or user.
Participants in public surveys receive exclusively the survey content of the respective project and have no access to project data, responses of other participants or analyses.
Download links for exports and reports are bound to the signed-in session, can be used only once and are valid for a short time.
For data retrieval via the export interface (API), the user creates personal access tokens. Tokens are stored only as a hash and can be revoked at any time.
For the optional Google Sheets connection, Choicery must present a refresh token from Google again later; it therefore cannot be stored as a hash and is encrypted reversibly instead (section 1.5). The permission drive.file covers app-created or explicitly selected files; this connection uses only the spreadsheets it creates itself. Connecting and updating require export rights for the project; stopping and disconnecting are bound to the user's own connection and remain possible after export rights are lost. All of these actions are protected by CSRF tokens. A password change, a password reset, "Sign out everywhere" and account deletion end the consent in the same step; the revocation at Google follows from a queue.
The Provider's administrative access is used only for operations, support at the Customer's request and security checks; administrative actions are logged as audit events (section 2.1).
Persons who are granted access are committed to confidentiality and receive only the permissions required for their task.

1.4 Separation Control

The data of all Customers are logically separated in a shared database and a shared file storage. Every record is assigned to a user, workspace and project via unique identifiers; every query is checked against this assignment.
Development and testing take place on separate systems of the Provider; the production environment is not used for testing.

1.5 Pseudonymisation and Encryption

Encryption in transit

All public endpoints are reachable exclusively via HTTPS. The application sets HTTP Strict Transport Security with a validity of one year including subdomains.
The connection between the application and the database is encrypted with TLS; the server certificate is verified against a stored certificate bundle, including verification of the hostname.
E-mails are handed over to the e-mail provider via a TLS-secured connection.
Administrative access takes place via SSH (section 1.2).

Encryption at rest

Encryption of the storage media in the data centres is determined by the configuration of the respective providers and is the subject of the data processing agreements with them.
Passwords are stored hashed (section 1.2). Checksums for responses and audit events are generated with a server-side secret key (section 2.1).
Two kinds of tokens are protected differently: personal access tokens for Choicery's export interface are stored only as a one-way hash and cannot be recovered from it (section 1.3). Refresh tokens from Google for the Google Sheets connection are stored with reversible encryption (Fernet; the key is derived with HKDF from the application's secret key, separately for each purpose). When the secret key is changed, older tokens remain readable with the previous key and are re-encrypted with the current key the next time they are read. Access tokens from Google are not stored; they exist only briefly in memory during an update. The encryption protects database contents and backups; it does not protect against a compromised application server that holds the key.

Pseudonymisation and data minimisation

Response records contain no IP address, no full browser identifier and no device fingerprint. Participants are identified by a response identifier assigned by the system and, only if the Customer configures this for its project, by a panel code passed by the Customer.
IP addresses are processed for the technical connection and for short-lived security controls (rate limiting). Application logs are rotated daily and retained for no longer than 14 days; container logs are rotated by size (section 4.2).
Audit and security events relating to accounts may contain the IP address and the browser identifier. IP addresses there are truncated automatically after 90 days (IPv4 to a /24 network, IPv6 to a /48 network).
Error reports and CSP reports are stripped of credentials, tokens and similar secrets before storage.

2 Integrity

2.1 Input and Change Control

Sign-ins, account changes, administrative actions, exports, deletions and changes to response data are logged as audit events. Every audit event carries an HMAC-SHA256 signature generated with a server-side secret key; subsequent changes to events are thereby detectable.
Every response record receives an HMAC-SHA256 checksum over its content when stored. Changes in the data editor are logged with check values before and after the change.
In addition to the database, responses are stored as a file-based backup copy per project. A maintenance process regularly reconciles the database and the backup copy and records discrepancies.
Responses deleted by the Customer are first marked as deleted and moved to the project's bin. They remain restorable there until the Customer deletes them permanently or empties the bin. Imported responses are permanently deleted immediately, without the bin.
Input is validated server-side. HTML entered by the Customer is sanitised against an allow-list of permitted elements and attributes; CSS values are checked. Output in pages is escaped automatically.
Single-choice answers are stored as a stable index of the original answer option, not as the displayed text, so that renaming and random ordering do not change the stored values.

2.2 Transfer Control

All transfers are encrypted in accordance with section 1.5.
All pages of the platform are delivered with a strict, nonce-based Content Security Policy. Scripts and styles are executed only with a nonce newly generated for each request; third-party content may be embedded only from the expressly approved video providers, and only after a click by the participant.
Exports can be generated only by authorised users; download links are session-bound and single-use (section 1.3). Generated export files are deleted after 30 days.
The application and the survey pages currently do not integrate any analytics, tracking or advertising services, third-party fonts or external AI services. Excepted are the marketing pages of the website on a separate host: there, Google Analytics 4 is loaded only after the visitor's consent in the cookie banner; the cookies set in the process are limited to that host and reach neither the application nor surveys. The Provider evaluates the usage of the application itself: page views and actions of signed-in users are counted on the server without third parties, without IP address, without browser identifier and without content in the Provider's own database, deleted after 90 days and shown only in aggregated form to platform administrators; users can object in their profile. Survey responses are not sent by e-mail.

3 Availability and Resilience

3.1 Availability

The web application runs with several parallel worker processes; containers are restarted automatically on failure.
Compute-intensive analyses run separately from the web application with a limited number of concurrent jobs; further jobs are placed in a queue. Memory limits per process, time limits per request and a size limit for uploads protect operations against overload.
Rate limits at sign-in and survey endpoints limit automated access.
The Provider makes no availability commitment. Maintenance and support are described in the Support and Maintenance Policy.

3.2 Data Backup

The database is backed up within the point-in-time recovery of the database provider. It can be reset to any point in time within the recovery window retained by the database provider.
In addition, the Provider creates its own backups of the database and of the project files on the application server every day. Copies of these backups are kept on an encrypted external storage medium of the Provider.
Own backups on the application server are retained for no longer than 30 days. Copies on an encrypted external storage medium are replaced with each new copy and deleted after 45 days at the latest.
Responses additionally reside as a file-based backup copy per project on the application server (section 2.1).
Customers can back up their data at any time via the export functions of the platform (CSV, JSON, Excel, SPSS, replication packages, project export).

3.3 Recovery

The database can be restored from the point-in-time recovery of the database provider to a point in time within the recovery window or from the Provider's own backups.
The application is deployed from versioned container images and can be rolled out again via the deployment control; the configuration is stored there.
Project files can be restored from the Provider's own backups.
Responses whose database entry is lost can be re-imported into the database from the file-based backup copy per project.
After a restore, documented deletions are carried out again.

4 Procedures for Regular Testing, Assessment and Evaluation

4.1 Incident Response

Security incidents and vulnerabilities are reported to security@choicery.ai. The contact details are also published in our security.txt.
Procedure in the event of an incident: detection (audit events, error reports, status checks, reports from third parties), containment (blocking accounts, invalidating sessions, rotating credentials and keys, disabling affected functions), analysis, remediation and documentation.
Affected Customers are informed without undue delay via the workspace owner, and further information is provided subsequently (Section 7 of the Data Processing Agreement).

4.2 Logging

Application logs are rotated daily and retained for no longer than 14 days. Container logs are rotated by size and occupy no more than 30 MB per service; there is no fixed age limit for them.
Error reports are deleted automatically after 90 days.
Audit and security events are retained for up to 3 years after the end of the calendar year of the event (evidence, prevention of abuse, defence of legal claims). IP addresses contained in them are truncated automatically after 90 days (section 1.5).
Logs of the providers (netcup, Ubicloud, coolLabs, do.de) are subject to their periods.
Only the Provider and, within the scope of the administrative remote access, the operator of the deployment control have access to logs.

4.3 Vulnerability Management

Essential dependencies of the application are versioned. Security updates for the application, container base images and the server operating system are applied promptly after they become known.
Automated tests are run before releases.
Responsible disclosure: the Provider accepts reports of vulnerabilities at security@choicery.ai (details in our security.txt) and handles them according to severity.

4.4 Data Protection Management and Review

Privacy contact: privacy@choicery.ai (Paul Bengart).
This document, the list of sub-processors and the Retention and Deletion Policy are reviewed regularly and whenever there is a specific cause (change of a provider, security incident, new function involving data, change in the law). Changes are published with their date.
New functions involving data are reviewed for their data protection implications before release, including the question of whether a data protection impact assessment is required.

5 Control of Processors

The Provider processes study and response data as processor of its Customers on the basis of the Data Processing Agreement. Customers issue instructions via the platform or in text form (for example by e-mail).
Sub-processors are contractually bound under Article 28(4) GDPR. The list Subprocessors and Recipients shows for each sub-processor the service, data categories, location and transfer basis. Changes are announced under Section 8 of the Data Processing Agreement.
Sub-processors with the possibility of access to personal data are: netcup GmbH (application server and file storage), Ubicloud B.V. (database; contracting party in the European Economic Area; remote access by the database provider's support from the USA possible, safeguarded by the database provider's intra-group standard contractual clauses under clause 6.1 of its data processing agreement), coolLabs Solutions Kft. (Coolify Cloud; deployment control with administrative access to the application server) and Greenmark IT GmbH (e-mail delivery and mailboxes).
Polar Software, Inc. (USA) is the Provider's processor for account, checkout and subscription data (EU Standard Contractual Clauses under the Polar Data Processing Addendum) and at the same time, as Merchant of Record, an independent controller for the sale of the plans; Polar does not receive study or response data.
Independent controllers (Google Ireland Limited and Microsoft Ireland Operations Limited for sign-in) and participant-facing video providers after a click are not sub-processors and are listed separately in the list.
For the Google Sheets connection, Google is a recipient chosen by the Customer and not a sub-processor (Section 5(5) of the Data Processing Agreement). Each connection is documented as an instruction with the user, project, chosen Google account, and the time and text version of the confirmation.

6 Deletion Concept

The retention and deletion periods are described in the Retention and Deletion Policy. Key points: no automatic deletion of responses during the contract; responses deleted by the Customer remain in the bin until the Customer empties it; projects deleted by the Customer remain restorable for at least 30 days and are then permanently deleted, at the latest after 60 days; account deletion with a grace period of 30 days followed by permanent deletion without undue delay, at the latest within 30 days, and, where immediate deletion is chosen, at the latest 30 days after the request; generated export files after 30 days; application logs no longer than 14 days (daily rotation), container logs rotated by size with no more than 30 MB per service; error reports after 90 days; audit events up to 3 years after the end of the calendar year of the event, with IP truncation after 90 days; own backups no longer than 30 days; after the end of the contract 30 days for retrieval followed by deletion at the latest within 30 days.
On permanent deletion of an account, database entries are deleted, project files are removed from the storage and personal identifiers in audit events and in order data from Polar are pseudonymised.
Deleted data may remain in backups until the respective backup expires and are deleted together with it. After a restore, documented deletions are carried out again.
On request, the Provider confirms deletion in text form.