Technical and Organizational Measures

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.

1. Scope, roles, and systems

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:

• the application hosting and compute layer that runs the engine API and the web dashboard (Railway);
• the managed PostgreSQL database that is the primary data store (Railway managed Postgres);
• the large language model API used to generate and rewrite landing-page copy (Anthropic);
• the browser-rendering API used to render the Customer’s public landing page once during the baseline scrape (Cloudflare);
• the billing system (Stripe); and
• the transactional email provider (Resend).

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.

2. Confidentiality (Vertraulichkeit, Art 32(1)(b))

2.1 Access control (Zutritts-, Zugangs- und Zugriffskontrolle)

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 enforced on every internal and administrative account that can reach production systems or personal data, and administrative access is reviewed on a defined cadence.

Note: Autopage does not offer end-user MFA as a product feature. The MFA commitment above is for Finalform’s own internal and administrative accounts only and must not be read as a customer-facing product control.

2.2 Encryption (Verschlüsselung, Art 32(1)(a))

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 and in its backups is encrypted at rest, as a managed property of the Railway database platform.

2.3 Pseudonymisation (Pseudonymisierung, Art 32(1)(a))

Visitors are identified to the service only by a random, non-identifying session identifier generated 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.

2.4 Data minimisation and IP handling

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.

2.5 Confidentiality of data sent to the language model

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 no-training / zero-retention tier of the language-model API is contractually enabled.

2.6 Consent gating

Visitor data is collected only behind consent. The snippet defaults to strict mode: it sets no identifier, fetches no variant, mutates no page, and emits no behavioral event until consent is signalled (via a TCF 2.x consent-management platform’s Purpose 1, or an explicit grant call). On withdrawal, the event listeners are torn down, the session identifier cookie is deleted, and the traffic-source value is cleared.

2.7 Staff confidentiality and processing on instruction (Art 32(4))

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.

3. Integrity (Integrität, Art 32(1)(b))

3.1 Input control and safe processing (Eingabekontrolle)

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.

3.2 Change control

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.

3.3 Logging of data-relevant actions (Weitergabe- und Protokollierungskontrolle)

Authentication and security-relevant application events are recorded in structured logs. A request-level access log over personal-data endpoints, with a defined store and retention period (Section 9), is recorded so that access to systems holding personal data is traceable and attributable.

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.

4. Tenant separation (Trennungskontrolle)

Autopage is multi-tenant, and tenant data is kept logically separated at the database layer.

• Data plane (engine). The engine connects to the database under a restricted role with PostgreSQL row-level security. Every tenant-scoped table carries a tenant-isolation policy, and each request runs inside a transaction that sets the tenant context, so a query can only ever see the rows of the tenant it is bound to. This isolation is verified by an automated test suite.
• Control plane (dashboard). The dashboard connects under a higher-privilege role and enforces tenant separation in the application layer, by an explicit tenant filter on every query plus a membership re-check on each request. The two planes together, row-level security in the data plane and enforced application checks in the control plane, keep one tenant’s data inaccessible to another.

Backups inherit the same logical separation; restores re-apply the isolation model.

5. Availability and resilience (Verfügbarkeit und Belastbarkeit, Art 32(1)(b))

Backups. The managed PostgreSQL database is backed up by the database platform on a regular schedule; backups are encrypted at rest. The backup frequency and retention are confirmed with the provider.

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 service and its infrastructure are monitored for availability and errors, with alerts routed to the responsible operator so incidents are detected and addressed.

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.

6. Restorability (Wiederherstellbarkeit, Art 32(1)(c))

Recovery from backups is tested so that the availability of and access to personal data can be restored in a timely manner after a physical or technical incident. The restore is exercised against a defined recovery point objective (RPO) and recovery time objective (RTO), and the date of the last successful restore test is recorded.

7. Sub-processor governance (Auftragskontrolle, Art 28)

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 liable to the Customer for the performance of each sub-processor’s data-protection obligations.

Transfers. 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, otherwise on the European Commission’s Standard Contractual Clauses supported by a transfer-impact assessment. 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.

8. Deletion and return concept (Löschkonzept, Art 28(3)(g), Art 17)

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 deletes the Customer’s personal data, unless the Customer elects return within 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. Residual copies in provider backups are overwritten on the backup rotation cycle and are not separately restored to retain deleted data; 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.

9. Retention

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 non-identifying aggregates. The target windows below define that limit per category.

A retention-policy review cadence and a named deletion-execution owner are maintained.

10. Regular review and breach readiness (Art 32(1)(d), Art 33/34)

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.

11. Physical and environmental security (Zutrittskontrolle, provider layer)

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.

• Application hosting and managed database (Railway). Relies on the physical security controls and certifications of Railway and its underlying cloud-infrastructure providers; the hosting region and EU-residency configuration are confirmed with the provider.
• Language-model API (Anthropic), browser-rendering API (Cloudflare), billing (Stripe), email (Resend). Each relies on the physical security controls and certifications of the respective provider, as set out in that provider’s documentation and DPA.

The exact certifications of each provider (for example ISO 27001, SOC 2 Type II, BSI C5) are recorded and confirmed before being cited.