Technical and organisational measures pursuant to Art. 32 GDPR

Processing takes place in ISO 27001 data centres within the EU. Physical access is limited to the data centre operator’s staff. We operate no hardware of our own.

• sign-in with email and password; passwords are hashed with Argon2id and never stored in clear
• two-step verification per RFC 6238 for every account; a code is accepted once, within its thirty-second time step and one step before and after, so that a clock running slightly off does not lock anyone out
• account lock-out for fifteen minutes after ten failed attempts
• optional sign-in through the company account (single sign-on) with domain verification
• sessions expire; a person can end all of their sessions at once, and blocking an account ends them as well

• roles with graded permissions: administration, analysis, read only
• tenant separation additionally enforced in the database through row-level security; access without a tenant context returns no row. The tables belong to a dedicated owner role; the services connect with a role that owns nothing and check at start-up that it does not bypass the filters
• API keys with limited scope and an expiry date; an expired key is rejected
• support access only after explicit, time-limited authorisation by the tenant, separately logged and shown visibly in the product

• transport exclusively over TLS; HSTS is set
• tracking elements are signed; there is no open redirect and there is replay protection
• server-side events can be transmitted signed; the signature is verified against the raw body
• transfer to advertising platforms happens only on the tenant’s explicit setting and covers only identifiers that originated from that platform

Changes to settings, access, campaigns, tracking elements and privacy requests are logged with person, time and — where given — reason. The log is visible in the product and is kept for 180 days; where an incident is investigated, the relevant extract is secured separately.

Further processors are bound by contract under Art. 28 GDPR, reviewed before use and disclosed in the “Sub-processors” annex. A change is announced 30 days in advance.

• daily database backup; in the production environment additionally recovery to any point in time within the last seven days. Restoring the daily backup into a new instance was tested in the cloud on 16 September 2026; point-in-time recovery has not yet been tested. A repetition each quarter is planned
• processing through a queue with retry and dead-letter storage: an outage causes delay, not loss
• per-tenant ingest rate limiting so a single sender cannot degrade operations
• notification to the tenant when data stops arriving — measurement time that was lost cannot be collected afterwards

Data of different tenants is logically separated and additionally protected by row-level security. Test and production data live in separate environments; test data enters no report and can be reset at any time.

• IP addresses in the event data only as a truncated hash formed with a secret; they are processed in transit and for rate limiting
• plaintext email addresses and phone numbers cause the event to be rejected
• no fingerprinting, no probabilistic matching
• without matching consent no advertising event is stored, not even in raw form

A measure nobody follows up on is an intention. So the cadence is stated here too.

• Access review: memberships and roles quarterly, granted support access monthly, service accounts whenever the infrastructure changes
• Joining, moving, leaving: access only through a named account with a second factor; on leaving, memberships are removed, sessions revoked and credentials rotated — on the last working day, not after it
• Vulnerabilities: automatic alerts for dependencies, handling by severity (critical within seven days at the latest, high within thirty), every deployment builds anew
• Effectiveness: tenant separation, consent, the suppression list, the deletion paths and rate limiting each have their own tests, which run before every deployment

The database instance does have a public address. It is still not reachable: the allow list of networks holds none, every connection must be encrypted, and the application connects through the connector socket. The connector alone would not be evidence — the authorisation is.

The restore path is verified locally and not in the target environment. An external penetration test is outstanding. Both stay named as open for as long as they are open.