Log inStart for free

Legal

Technical and organizational measures (TOMs)

How we protect the data TickySmart processes on behalf of organizers. This description under Art. 32 GDPR is Annex 3 to the data processing agreement.

Last updated: October 26, 2026

1. Overview

TickySmart is provided by CaterSmart GmbH, Hauptstraße 41, 95482 Gefrees, Germany. The measures apply to every part of TickySmart: ticket shop and widget, dashboard, scan app, app, API and the background services. We adapt them when technology or risks change. The level of protection never decreases (§ 5 of the DPA).

  • Hosted in Germany: servers, database, files and backups are with Hetzner Online GmbH in German data centers.
  • Separated workspaces: every organizer only sees their own data. The database itself enforces this separation.
  • Encrypted: all connections use TLS, access keys are stored encrypted with AES-256.
  • Backed up: a full backup to separate storage every night, the last 30 are kept.

2. Physical access control

Goal: unauthorised people cannot get to the servers.

  • All servers are in data centers of Hetzner Online GmbH in Germany. Hetzner is certified to ISO/IEC 27001.
  • According to Hetzner, electronic access control, video surveillance and security staff protect the data centers around the clock. Only authorised staff have access.
  • We do not run our own servers in offices. We do not keep customer data permanently on work devices.

3. System access control

Goal: only authorised people can use the systems.

  • Everyone signs in with their own account. Passwords need at least 10 characters and are only stored as a hash, never in plain text.
  • Two-factor sign-in (TOTP) with backup codes is available for every account. New accounts confirm their email address.
  • Sign-in and the interfaces limit the number of requests per period. This makes guessing passwords and other attacks harder.
  • Sessions use secure cookies that scripts in the browser cannot read.
  • We store API keys only as a hash. Every key can be revoked at any time.
  • Scan app devices sign in with their own access, which the organizer can revoke or renew at any time.
  • In the TickySmart app, the sign-in stays in the protected storage of the operating system (Keychain or Keystore). If wanted, the app only opens with fingerprint, face or device lock and locks again after five minutes in the background.
  • Only the web services are reachable from outside, via HTTPS. Database, cache and PDF generation cannot be reached directly from outside.
  • Only a few named people at CaterSmart GmbH have access to servers, cluster, database and source code, with personal accounts and over encrypted connections.
  • Credentials for our services are kept as protected secrets in the cluster and the pipeline, never in the source code.
  • Work devices are protected with a password and an encrypted disk, lock automatically and receive security updates regularly.

4. Data access control

Goal: people who are signed in only see and change what they are allowed to.

  • Organizers assign permissions through roles such as Owner, Admin, Accounting, Marketing, Box office or Ticket checker. Team members can be limited to selected events, and the database enforces that too.
  • Every request to the interface is checked for sign-in, workspace and permissions before data is read or changed.
  • The TickySmart app checks the same roles and permissions as the dashboard. It deletes the ticket list for entry without a connection when the account signs out or the device is signed out in the team.
  • Ticket PDFs and uploaded documents are kept in non-public storage and can only be retrieved through signed links that expire.
  • Buyers enter card and account details directly with the payment provider. TickySmart does not store them.
  • Staff of CaterSmart GmbH only access customer data where this is needed for operations, fixing errors or a request from the customer. Such access is logged.
  • Hetzner erases and destroys storage media in the data centers using its certified procedures.

5. Separation control

Goal: data of different customers and purposes stays separate.

  • Every record belongs to exactly one workspace. The database (PostgreSQL with row level security) only returns a workspace’s own data, even if there were an error in the program code.
  • Automated tests check this separation with every change, some of them directly in the database.
  • The public ticket shop uses its own database role and can only read published content.
  • Development, test environment and production are separate, with their own databases on different servers and their own credentials. We do not use production data for development and testing.
  • Public images and confidential files are kept in separate storage areas.

6. Encryption and pseudonymisation

Goal: data is protected in transit, and only as much is stored as needed (Art. 32(1)(a) GDPR).

  • All connections to the shop, dashboard, scan app, app and API are encrypted with TLS. Certificates renew automatically, including for organizers’ own domains.
  • Credentials for payment and tracking accounts, ticket signing keys and webhook secrets are stored in the database encrypted with AES-256.
  • QR codes contain no names or contact details, only a signed ticket identifier.
  • Buyer data is anonymised automatically every night once the retention period chosen by the organizer has passed (1 to 120 months after the last date). Organizers can anonymise individual people immediately at any time.
  • We remove metadata such as the GPS location from uploaded images.
  • We do not store a date of birth for age limits. The buyer only confirms that they are old enough.

7. Transfer control

Goal: data is not read or changed in transit and only goes where it is meant to.

  • Emails are sent encrypted to our email service and signed with DKIM.
  • Webhooks are signed with HMAC-SHA256 and a timestamp. Targets in internal networks are blocked.
  • Every QR code is signed with Ed25519. The scan app detects forged or altered tickets even without a connection.
  • Backups are transferred over an encrypted connection (SFTP) to separate storage.
  • Buyers reach their order through a secret link or a sign-in link by email. Exports are only available to team members with the right permission.
  • Data only goes to systems the organizer connects (API, webhooks, tracking, AI assistants) if the organizer sets them up.

8. Input control

Goal: it is traceable who entered or changed which data and when.

  • We record important changes in the workspace in the audit log: who, when and what. This includes changes made with API keys.
  • Every scan is stored with time, device and result.
  • Orders record when the buyer agreed to which terms.
  • Every interface validates input against a fixed schema. Database queries are parameterised so injected code is not executed.

9. Availability and resilience

Goal: TickySmart keeps running during rushes and disruptions, and no data is lost (Art. 32(1)(b) GDPR).

  • TickySmart runs in a Kubernetes cluster on several servers. In production every service runs at least twice, on different servers where possible. If a service fails, it restarts by itself and only receives requests again once it is ready.
  • Emails, ticket PDFs, wallet passes and webhooks go through queues and are retried several times on errors.
  • A waiting room spreads the rush when presales open. Stock is checked in locked transactions so no ticket is sold twice.
  • The scan app checks tickets on the device and keeps working without a network.
  • The systems are monitored around the clock and raise an alarm when something goes wrong.
  • According to Hetzner, the data centers have redundant power and network connections, emergency power, air conditioning and fire protection.
  • Updates only go live once type checks and automated tests have passed, and into production only after approval. If a database change fails, the previous version keeps running.

10. Recovery

Goal: after an incident, data and operations are back quickly (Art. 32(1)(c) GDPR).

  • Every night we back up the complete database to separate storage at Hetzner outside the cluster. The last 30 backups are kept.
  • After every upload we check the size and checksum of the backup.
  • The restore procedure is documented and tested regularly.
  • Files are kept in Hetzner’s object storage, which stores them redundantly. Ticket PDFs can be regenerated at any time.
  • The entire infrastructure is described as code and the database schema as migrations, so the environment can be rebuilt after an outage.

11. Organization and regular review

Goal: the measures work and stay up to date (Art. 32(1)(d) and Art. 25 GDPR).

  • Management is responsible for data protection and information security. We are currently not required to appoint a data protection officer.
  • We review these measures at least once a year and whenever TickySmart changes significantly.
  • Everyone with access to customer data is bound to confidentiality in writing and trained in data protection. People who leave lose all access immediately.
  • Working remotely or from home is allowed if the same measures apply. We do not use private devices for this.
  • There is a fixed process for data breaches: assess, contain, inform the customer within 48 hours and document everything.
  • We keep a record of processing activities.
  • Privacy-friendly defaults: tracking is off until the organizer sets it up. Without tracking, the shop shows no cookie banner.
  • Secure development: more than 3,000 automated checks cover checkout, entry, payments and the separation of workspaces. Containers run without administrator rights, and we keep dependencies on the latest stable versions.
  • Security vulnerabilities can be reported to support@tickysmart.io. We look into every report.

12. Processor control

Goal: data is only processed the way the customer wants, also by our service providers.

  • We only process data on the customer’s instructions (§ 3 of the DPA).
  • We choose subprocessors based on their security measures. We conclude an agreement under Art. 28 GDPR with each of them, with EU standard contractual clauses for third countries, and list them in the list of subprocessors.
  • We announce changes to this list at least 30 days in advance.
  • When the agreement ends, we delete the data under § 12 of the DPA.