Technical and organisational measures pursuant to Art. 32 GDPR

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

• main resources in region europe-west3 (Frankfurt): application, database, analytics mirror, the data assistant’s language model and the application logs
• separately: administration and system logs of the cloud platform in global logging buckets of the provider that cannot be moved to a region (up to 400 days; a further global bucket with seven days, to which the application logs are not written)
• separately: logs that the providers keep themselves to operate their services, under their terms
• possible: access by group companies and service providers of the providers from outside the EU for administration and support; Annex 2 names them per provider with the transfer basis

• sign-in with email and password; passwords are hashed with Argon2id and never stored in clear
• two-step verification per RFC 6238, available for every user account and switched on by the person themselves; the software does not enforce it. 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
• the contractor’s privileged accounts: platform administration signs in only through individually authorised Google Workspace accounts, where a second factor is enforced; the accounts with cloud, code, mail and payment providers also carry a second factor
• 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: Admin, 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 while the tenant allows it in its settings (switched on by default, can be switched off at any time; switching it off ends any running access), only to handle a request of the client or a fault, time-limited, separately logged with its reason and shown in the tenant’s change log

• 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; the only identifier sent is that platform’s click ID, never our own personal or device identifiers

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 “Further processors” annex. A new direct processor is announced 30 days before its engagement, changes at further tiers under section 7 of the agreement.

• 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 development environment in the cloud on 16 September 2026, not yet in the production environment; 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: if a processing step fails, accepted events stay in the queue and are processed later. This does not protect against every loss: what does not arrive while intake is down cannot be collected afterwards, and after restoring from a backup, data since the recovery point may be missing
• 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 (HMAC) formed with a secret key and the client’s identifier; they are processed in transit and for rate limiting. The address is protected by the secret key and the separation per client, not by the truncation; the value is a pseudonym, not anonymisation
• 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.

Restore tests: on 16 September 2026, the daily backup was restored into a new instance in the development environment in the cloud, with a sign-in and a report against the restored data. On 24 September 2026, a test with a real backup on a separate instance in the same environment showed that erasures, objections and withdrawals since the time of the backup are reapplied before release. No test has yet run in the production environment, and point-in-time recovery has not been tested.

An external penetration test is outstanding. What is open here stays named as open for as long as it is open.