This document is provided in English. The German version will follow our legal review.
Last updated: 2026-08-04
This document sets out the technical and organizational measures (the "TOMs", technische und organisatorische Maßnahmen) that Finalform GmbH applies to protect personal data processed through Autopage, in accordance with Article 32 GDPR. It is Annex 2 to the Data Processing Agreement(the "DPA") and forms part of it. Where the DPA and this Annex differ, the substantive descriptions of the measures in this Annex govern the controls; the contractual obligations in the DPA govern the relationship.
The measures are appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of the processing, as well as the likelihood and severity of the risk to the rights and freedoms of natural persons (Art 32(1), (2) GDPR). Finalform may update these measures over time, provided the level of security is not reduced.
Role. For the visitor personal data processed through the Autopage snippet, Finalform acts as processor and the Customer as controller (Art 28 GDPR). These TOMs describe the measures Finalform applies as processor. They are stated concretely so that the Customer can assess them, as Art 28(3)(c) GDPR requires of an AVV annex.
Operator. Finalform GmbH, Theodor-Heuss-Str. 106, 26129 Oldenburg, Germany.
Systems in scope. The personal data covered by the DPA is processed across the following systems:
These six services are operated by the five external recipients named in the Sub-processor List (Railway hosting and Railway managed Postgres are the same vendor). Each recipient, its role, its data category, its hosting region, and its transfer mechanism are set out there. Finalform does not operate its own data centres and relies on these providers for the physical and environmental security of the infrastructure (Section 11).
Data minimisation at the boundary. The customer-side snippet transmits behavioral and event data only to the first-party Autopage API; it calls no third party directly. Every onward transfer of visitor data to a sub-processor happens server-side from the engine, never browser-to-vendor. This keeps the set of recipients of visitor data closed and auditable.
System access (Zugangskontrolle). Access to the Autopage application is controlled by an account model with mandatory email verification, password and magic-link sign-in, and organization-and-role membership. The application protects against email enumeration on the authentication endpoints and refuses to start in production if a placeholder authentication secret is configured. Authentication attempts are rate-limited.
Data access within the application (Zugriffskontrolle). Access to personal data inside the application is mediated by per-tenant credentials and role-based membership checks. Service-to-service calls between the dashboard and the engine are authenticated with high-entropy secrets (128-bit, generated with a cryptographically secure random source) compared in constant time to resist timing attacks. Per-tenant API keys are issued from a cryptographically secure random source.
Administrative access (Zutrittskontrolle to the platform consoles). Production infrastructure is administered through the consoles of the underlying providers (Railway, the database, Stripe, Anthropic, Cloudflare, Resend). Access is role-based and granted on a need-to-know basis. Multi-factor authentication is active on every internal and administrative account that can reach production systems or personal data. It is not yet enforced at the platform level: the hosting workspace's account-wide enforcement setting is off, so the control rests today on each account having a second factor switched on and not on the platform refusing an account that does not. Turning on workspace-level enforcement, which is what keeps the statement above true when a further account is added, is a committed measure that goes live before the first signed DPA, as is a defined review cadence for administrative access.
Note: Autopage does notoffer end-user MFA as a product feature. Customer users sign in to the dashboard with a password or a magic link; no second factor is offered to them today and none is claimed here. The multi-factor statement above is for Finalform's own internal and administrative accounts only and must not be read as a customer-facing product control.
In transit.All connections between the visitor's browser and the Autopage API, between the dashboard and the engine, and between the engine and each sub-processor are made over TLS (HTTPS). The Railway edge terminates TLS for the application domains. HTTP requests are redirected to HTTPS and a minimum TLS version is enforced at the edge.
Application-to-database transport.The connection from the application to the managed PostgreSQL database is encrypted in transit, over the provider's private network or with TLS enforced on the database connection string.
At rest. Personal data stored in the managed PostgreSQL database is encrypted at rest, as a managed property of the Railway database platform. There are no database backups today (Section 5), so there is no second copy of that data to encrypt; the backups committed in Section 5 are encrypted at rest on the same managed basis once they exist.
Visitors are identified to the service only by a random, non-identifying session identifiergenerated client-side. It is not a device or browser fingerprint and is not derived from any visitor attribute; it singles out a browser for the cookie's 30-day lifetime and no longer. The identifier is written to the database in pseudonymous form and is never resolved to a natural person by Finalform.
No identifying network or device data is collected by the snippet or stored by the application. The visitor-event store has no column for IP address, full user-agent string, raw referrer, or precise geolocation; only the pseudonymous session identifier and coarse, bucketed signals (a device-class bucket, a five-way traffic-source bucket, scroll depth, time on page) are persisted.
IP addresses are never stored, never truncated, and never hashed. The snippet cannot read the visitor IP (no browser API exposes it). Server-side, the IP is read in exactly one place, the in-memory rate limiter, where it is used only as a short-lived key to count requests and is discarded when the rate-limit window (approximately 60 seconds) elapses or the process restarts. No application code copies the IP into any database table or log line. Because nothing is retained, no IP truncation, hashing, or anonymisation step applies.
Infrastructure caveat (true, not application behaviour): the Railway edge and the hosted database terminate the network connection and therefore see the raw client IP in transit, and provider access logs at the infrastructure layer may retain it. This is the relationship described in the Sub-processor List; no Autopage application code persists the IP.
Only the tenant brief, the baseline page copy, and population-level aggregate metrics (rates and medians computed across visitors) are sent to the language-model API to generate or rewrite copy. No per-visitor data (no session identifier, no IP, no raw event) is ever placed in a prompt. Direct identifiers are stripped before the request is assembled. On the Finalform side, no prompt or response content is logged; only operational token-count telemetry (token counts and call duration) is retained. The language-model API is engaged on a no-training basis: Anthropic does not train its models on inputs or outputs submitted through the commercial API, and the one customer-controllable exception, the setting that would send full prompts and responses for future model improvements, is switched off (verified 2026-07-30). Zero Data Retention is not enabled: Anthropic retains inputs and outputs for 30 days and may access them for safety and security purposes. Because identifiers are stripped and no per-visitor data reaches a prompt, that window covers tenant briefs, baseline page copy, and population-level aggregates, not visitor data. See the Sub-processor List, row 2.
Visitor data is collected behind a gate in every mode, with two exceptions named here rather than left to the sentences below: in the default relaxed mode the variant-assignment record described next is written server-side before consent and is not gated at all, and the gate itself opens without consent on pages where no consent platform is detectable. The snippet defaults to relaxed mode: it fetches and applies a page variant before consent, and records that assignment server-side against a random identifier, but it sets no identifier on the visitor's device and emits no behavioral event until the gate opens. The gate opens on a consent signal (via a TCF 2.x consent-management platform's Purpose 1, or via an explicit grant call) and, in relaxed mode only, on a non-consent fallback where no consent platform is detectable on the page at all, which opens the gate after the three-second pending window instead of denying. That fallback is not consent and is not recorded as consent; it is disclosed to the Customer with a switch to disable it. The Customer may switch the snippet to strict mode, in which the variant fetch and the page mutation also wait for consent and the no-platform case denies. On withdrawal, the event listeners are torn down, the session identifier cookie is deleted, and the traffic-source value is cleared.
Persons authorized by Finalform to process personal data do so only on documented instruction from the Customer, as set out in the DPA, unless required to act otherwise by Union or Member State law. All such persons, employees and engaged externals alike, are bound by written confidentiality undertakings that survive the end of their engagement, and receive data-protection and security awareness training on a recurring basis.
External input, whether from end users, from sub-processor API responses, or from the snippet, is validated before use. The snippet does not inject untrusted content as HTML (text is written via safe text nodes, never innerHTML) and performs no dynamic code execution. This holds across the event-ingestion path.
Changes to the service are managed through version control with a mandatory pull-request review before deployment to production, so that changes are tracked, attributable, and reversible. The default branch is protected and changes reach production only through the reviewed pipeline.
Authentication and security-relevant application events are recorded in structured logs. A dedicated request-level access log over personal-data endpoints, with its own store and retention period (Section 9), does not exist yet; it is a committed measure that goes live before the first signed DPA, at which point requests routed through those personal-data endpoints become traceable and attributable at request level. Its scope is deliberately narrow: it covers application requests through the covered endpoints, and not direct database access, provider-console administrative action, or sub-processor-side access, each of which is governed by the controls in Section 2.1 and by the providers' own logging rather than by this measure. Until then, the structured application logs above are what is available.
Note: the optimization-decision audit that the engine already keeps records what the optimizer did (which variant was served, which copy was changed). It is a domain audit, not a personal-data-access audit, and is not relied on as the access log committed above.
Autopage is multi-tenant, and tenant data is kept logically separated at the database layer.
There are no backups today (Section 5). The isolation model is part of the database itself, in the schema, the roles, and the row-level-security policies, rather than a layer applied on top of it, so the backups committed in Section 5 carry the same logical separation and a restore reinstates it.
Backups. The managed PostgreSQL database has no backups today. The database platform plan currently in use provides none: its backup entitlement is zero, so no backup schedule can be configured and no backup exists. Verified in the provider control plane on 2026-07-30. Backups on a regular schedule, encrypted at rest and with a stated frequency and retention window, are a committed measure that goes live before the first signed DPA.
Until backups exist, the consequence is stated rather than mitigated: a loss of the database volume would lose the personal data it holds. What that leaves recoverable is set out in Section 6.
Rate limiting and abuse resistance. The ingestion API enforces an in-memory request-rate limit (100 requests per minute per source) to resist floods and abuse. The control disables itself only outside production; in production the disable switch is refused.
Monitoring.The engine and the dashboard each expose a health endpoint, and the hosting provider's console reports deployment and instance status. External availability monitoring that polls those endpoints and routes an alert to the responsible operator is not yet in place, so detection today depends on the operator observing the console or the service rather than on being paged. That external monitoring, with alert routing, is a committed measure that goes live before the first signed DPA.
Resilience and network. Autopage runs in a single-region deployment and carries no contractual uptime guarantee. Platform-level resilience (network availability, redundancy, and DDoS protection at the edge) is supplied by the underlying providers; Finalform does not represent high availability beyond what those providers deliver.
There is no tested restore capability today, and no restore has ever been performed, because there is nothing to restore from: the database has no backups (Section 5). Recovery from backups, tested so that the availability of and access to personal data can be restored in a timely manner after a physical or technical incident, exercised against a defined recovery point objective (RPO) and recovery time objective (RTO), with the date of the last successful restore test recorded, is a committed measure that goes live before the first signed DPA and follows the backups it depends on.
No RPO, no RTO, and no restore-test date are claimed here, and none will be stated until a restore has actually been performed. The figures are recorded once the first test is complete.
What can be restored today is the service and not the data in it: the application, the database schema, and the infrastructure configuration are held in version control and can be redeployed to a new instance, while the personal data held in the database volume has no second copy from which it could be reinstated.
List and cross-reference. Each sub-processor that Finalform engages is named in the Sub-processor List, together with its legal entity, role, data category, hosting region, and transfer mechanism. The List operates under the general written authorization the Customer grants in the DPA (Art 28(2) GDPR) and forms part of the DPA.
Selection and binding. Sub-processors are selected with regard to their technical and organizational security and data-protection guarantees. Each is bound by a data-processing agreement imposing data-protection obligations equivalent to those in the DPA (Art 28(4) GDPR). Signed sub-processor DPAs are retained on file.
Residual liability. Finalform remains fully liableto the Customer for the performance of each sub-processor's data-protection obligations.
Residency and transfers. All personal data that Autopage persists is stored in the European Union: the managed PostgreSQL database and every production service run in Railway's Amsterdam region (europe-west4-drams3a), verified 2026-07-30, and the Railway workspace default region is set to the same EU region. That establishes EU residency at rest only; it does not establish the absence of a Chapter V transfer, because the same data is reached by the legs described next. Finalform does not represent that no personal data leaves the EEA. Railway Corporation is a US entity whose addendum states that its primary processing operations take place in the United States and that the US transfer is necessary to provide the services, so a US processing leg remains and is a third-country transfer; and the language model, browser-rendering, and transactional email providers process outside the EEA. Where a sub-processor processes personal data outside the EEA, the transfer relies on the EU-US Data Privacy Framework where the recipient is certified, and otherwise on the European Commission's Standard Contractual Clauses supported by a transfer-impact assessment. The language-model provider makes no Data Privacy Framework claim, so that transfer rests on the Standard Contractual Clauses. The third country and the Art 44 ff. mechanism are disclosed, and proof of the safeguards is available to the Customer on request. The per-recipient mechanism is set out in the Sub-processor List.
Change notification and objection. Finalform gives affected Customers at least 30 days' advance notice before a new or replaced sub-processor begins processing personal data, by updating the List and notifying the Customer through the channel named in the DPA. The Customer's right to object on reasonable data-protection grounds, and the consequences of an objection, are governed by the DPA. The advance-notice period and the objection period are distinct clocks and are not asserted as a single figure here.
Deletion in life and on request.On a Customer's request, and on account closure, deletion of the Customer's personal data is immediate and complete. A single transaction wipes all tenant-scoped tables on the owner's action: there is no soft-delete, no scheduled grace period, no anonymisation tail, and no retained shadow copy in the live database. This beats the one-month maximum in Art 12(3) GDPR.
Deletion or return at the end of services (Art 28(3)(g)). After the end of the provision of services, Finalform deletesthe Customer's personal data, unless the Customer elects returnwithin the return window. Return is provided as a machine-readable export (JSON / CSV) of the Customer's personal data on request. The Customer may request export within 30 days of service end; after that window, or immediately on a delete election, Finalform deletes the data.
Sub-processor deletion.On contract end, Finalform instructs each sub-processor to delete or return the Customer's personal data on the same basis (Art 28(4) flow-down).
Backups. There are no backups today (Section 5), so no residual copy of deleted data survives in one and no restore can reintroduce it. Once the backups committed in Section 5 exist, residual copies in them are overwritten on the backup rotation cycle, backups are not separately restored to retain deleted data, and a restore re-applies prior deletions.
Statutory-retention carve-out. Data that Finalform must keep to meet a legal obligation, namely statutory billing and accounting records (Section 9), is exempt from deletion and is retained only for the statutory period in the external accounting system, then deleted.
The retention principle is storage limitation (Art 5(1)(e) GDPR): each category of personal data is kept only as long as it is needed for the purpose it was collected for, then deleted or reduced to a non-identifying record. The windows below define that limit per category.
Three of those categories are time-bound and are enforced by a scheduled purge job that runs once daily: raw visitor events with their session assignments, language-model call telemetry, and in-app notifications. Each run attempts, per category, an evidence record of the cutoff applied and the number of rows deleted, so that the execution of this schedule is evidenced rather than asserted; a failed evidence write is reported separately and does not prevent the deletion itself. The remaining rows are not on that clock and each states its own trigger: the metrics snapshot and the decision audit last for the life of the account, account and tenant data is deleted on request, statutory billing records are held outside this schema, and the security and access log does not yet exist.
| Data category | Retention |
|---|---|
| Raw visitor events and their session assignments (pseudonymous session identifier + coarse behavioral signals; no IP, user-agent, referrer, or geo stored) | 90 days, then purged. Rows belonging to an experiment that has not yet concluded are held past 90 days until it concludes, so a running test is never decided on truncated data. That hold currently has no outer bound: an experiment left paused or awaiting approval holds its rows for as long as it stays in that state. An outer maximum age is being defined. |
| Per-iteration metrics snapshot (population-level counts recorded at each engine decision) | Life of the account; non-identifying. This, and not the live aggregate views, is what survives the raw-event purge. Neither aggregate is a durable record, and the two differ: variant_metrics is computed at query time and reflects the purge immediately, while the materialised context_variant_stats is refreshed by the periodic sweep rather than by the purge, so between a purge and the next sweep it can still hold identifier-free population counts derived from deleted rows. |
| Language-model call telemetry (token counts + call duration only; no prompt or response content) | 90 days. |
| Optimization decision and iteration audit | Life of the account; deleted on tenant deletion. |
| Security / access logs | Target of 30 days. No dedicated log exists yet (Section 3.3), so this window is a commitment rather than current behaviour. |
| In-app notifications | 30 days. |
| Account / tenant data | Immediate and complete deletion on request (no grace tail). |
| Statutory billing records (invoices / Buchungsbelege) | 8 years (§ 147 AO as amended by the Bürokratieentlastungsgesetz IV, effective 2025-01-01), with GoBD write-once archiving. |
A retention-policy review cadence and a named deletion-execution owner are maintained.
Regular review. Finalform reviews and evaluates the effectiveness of these technical and organizational measures on a defined cadence, at least annually and on any material change to the service, and updates them as the service evolves, without reducing the level of security.
Breach readiness. Finalform maintains a personal-data-breach process with a named responsible person and a breach register and runbook, so that a breach can be assessed and, where Finalform acts as processor, notified to the Customer without undue delay after becoming aware of it, enabling the Customer to meet the 72-hour notification window of Art 33 GDPR and any obligation to data subjects under Art 34 GDPR.
Finalform does not operate its own data centres. Physical and environmental security of the infrastructure is provided by the underlying hosting and database providers, which operate from data centres with physical access controls, environmental controls, and recognized certifications.
The exact certifications of each provider (for example ISO 27001, SOC 2 Type II, BSI C5) are recorded and confirmed before being cited.