Data Retention Policy

This Data Retention and Minimisation Policy is issued by Finalform GmbH, Theodor-Heuss-Str. 106, 26129 Oldenburg, Germany (“Finalform”, “we”, “us”), the operator of Autopage. It is Finalform’s deletion concept (Löschkonzept) and gives effect to the storage limitation and data minimisation principles of Article 5 GDPR across the data Autopage processes. It is written in plain B2B English.

This policy is structured following the method of DIN EN ISO/IEC 27555 (which in September 2025 replaced the withdrawn DIN 66398). Under that method, each category of data is assigned exactly one deletion rule consisting of a regular retention period (Regellöschfrist) and a defined start trigger (Startzeitpunkt), and categories that share a rule are grouped into deletion classes (Löschklassen). A written deletion concept is not itself mandated by the GDPR, but it is the recognised way to evidence the accountability duty in Article 5(2) GDPR.

Contents

1. Purpose and scope
2. Minimisation measures
3. Deletion classes (Löschklassen)
4. Retention schedule
5. Statutory holds and erasure
6. Deletion mechanics, backups, and review
7. Relationship to the Data Processing Agreement

1. Purpose and scope

This policy sets out how long Finalform retains the categories of data it processes through Autopage, and the measures it applies to keep the amount of personal data to what each purpose actually requires. It gives effect to two principles of Article 5(1) GDPR:

• Data minimisation, Article 5(1)(c): personal data must be adequate, relevant, and limited to what is necessary for the purposes for which it is processed.
• Storage limitation, Article 5(1)(e): personal data must be kept in a form that permits identification of data subjects for no longer than is necessary for those purposes.

This policy covers two distinct roles:

• Finalform as controller. Data Finalform processes for its own account, billing, transactional-email, marketing, and website purposes (the data of the customer’s own account holders and visitors to autopage.dev). This processing is described in the Privacy Policy, and the retention periods here must be read consistently with it.
• Finalform as processor. The visitor interaction data collected through the Autopage snippet on the customer’s pages, where the customer is the controller and Finalform is the processor under Article 28 GDPR. For that data, this policy is read together with the Data Processing Agreement (Auftragsverarbeitungsvertrag), which governs deletion and return at the end of the engagement (see Section 7).

Deletion-execution owner. The Geschäftsführer, Robin Schröder, is responsible for executing and reviewing the deletion rules in this policy, including triggering deletions and confirming the scheduled purge jobs run as intended.

This policy is a Finalform-internal control. It does not shorten any statutory retention obligation, and it does not extend any retention period beyond what is lawful.

2. Minimisation measures

Autopage is designed to collect and process only the personal data the optimisation actually needs, and to avoid collecting identifying data in the first place rather than collecting and then reducing it. The principal measures are:

• No visitor IP, user-agent, referrer, geolocation, or device fingerprint is collected or stored. This is minimisation by design, not truncation, masking, hashing, or anonymisation after the fact: the relevant fields simply do not exist in the visitor data model. The snippet on the customer’s pages cannot read the visitor’s IP address, and no application code persists a visitor IP, user-agent string, referrer, precise geolocation, or device fingerprint to any database table or log line. Separately from the visitor pipeline, dashboard sign-in records the account holder’s login IP address and browser user agent in the session record, and the sign-in rate limiter stores request counters keyed by client IP; this concerns the customer’s own account holders, not page visitors.
• Transient IP for rate limiting only. The single point at which a visitor IP is touched server-side is the in-memory rate limiter, which holds the IP as a lookup key in a process-memory map, with a request count and an approximately 60-second reset window, after which the entry is swept. The IP is never written by Autopage application code to any database table or log, and is never truncated, hashed, or otherwise persisted. The raw visitor IP transits the hosting provider edge and proxy layer only; that infrastructure layer is a sub-processor matter recorded in the TOMs, not application storage.
• Direct identifiers stripped before any model prompt. Before any content is sent to the large language model supplied by Anthropic, PBC for variant generation, direct identifiers are stripped. Only the tenant brief, the baseline page copy, and population-level aggregate metrics (such as rates and medians) are sent. No per-visitor data, namely no session identifier, no IP address, and no raw event, is placed in any prompt.
• No prompt or response content is logged. Finalform does not log the prompts sent to, or the responses received from, the model. Only call telemetry, namely token counts and call duration, is retained for operational purposes (see Section 4, class B).
• Pseudonymisation and population-level reporting. Visitors are distinguished only by a pseudonymous session identifier that is a random value, not a fingerprint, with a 30-day lifetime. Reporting on experiment results is conducted at the population level rather than on identifiable individuals, and the metrics used by the optimisation engine are aggregates, not raw per-visitor rows.
• Collect only what the optimisation needs. The snippet and pipeline are scoped to the coarse, bucketed interaction signals required to generate, serve, and evaluate variants (such as device class, traffic-source category, scroll depth, and time on page). Finalform collects no special-category data, and the agent’s “enrichment” uses cross-tenant industry-benchmark data, which is non-personal, not data acquired from a data broker about individuals.

3. Deletion classes (Löschklassen)

Following the DIN EN ISO/IEC 27555 method, the data categories below are grouped into deletion classes that share a retention logic. The concrete period and start trigger for each category are set out in the schedule in Section 4.

• Class A. Visitor interaction data. Raw visitor events processed on behalf of the customer (pseudonymous session identifier plus coarse behavioral signals), and the population-level aggregate metrics derived from them.
• Class B. Operational telemetry. Model-call telemetry (token counts and duration), security and access logs, and in-app notifications, retained for operating, securing, and monitoring the service.
• Class C. Decision and audit data. The optimisation engine’s decision records (iterations, proposals, applied changes, and enrichment audit) that document how the service ran for an account.
• Class D. Account and tenant data. The customer’s own account, profile, configuration, and authentication data, plus all tenant-scoped data tied to the account.
• Class E. Statutory records. Records Finalform must keep to meet German statutory retention duties, namely billing records and business correspondence, held in the external accounting system.

4. Retention schedule

The table below sets out, for each category, the deletion class, the target retention period, the start trigger (Startzeitpunkt) from which that period runs, and the status in code. For some categories the period states the legally correct target under Article 5(1)(e) while the scheduled purge job that enforces it is committed but not yet implemented; the Status column identifies those categories, and until the job is built the data is retained for the life of the account.

Account and tenant deletion is immediate. When the account owner deletes the organisation, all tenant-scoped data is wiped in a single transaction. There is no soft-delete, no scheduled grace tail, and no anonymised residue. This meets, and is faster than, the one-month maximum in Article 12(3) GDPR. There is no 30-day or 90-day post-closure retention window for account data.

Billing retention is 8 years, not 10. The German Bürokratieentlastungsgesetz IV reduced the retention period for accounting vouchers and invoices (Buchungsbelege) to 8 years with effect from 2025-01-01. The 2025 re-extension to 10 years applies only to banks, insurers, and securities institutions, not to a normal SaaS GmbH such as Finalform. The 8-year period runs from the end of the calendar year in which the invoice was issued (Section 147(4) AO), and overrides any shorter operational period for this category.

5. Statutory holds and erasure

A request for erasure under Article 17 GDPR does not override a statutory retention obligation. Where a statutory hold applies, in particular the 8-year obligation for billing records and invoices and the 6-year obligation for business correspondence, the affected data is retained for the statutory period under the Article 17(3)(b) carve-out. During the hold the data is restricted from ordinary use under Article 18 GDPR rather than deleted, and it is deleted once the obligation lapses.

Marketing-consent records. Finalform retains records of marketing consent to be able to demonstrate, under Article 5(2) and Article 7 GDPR, that valid consent existed for any commercial email sent. These records are kept for as long as the marketing relationship is active and for a demonstrability tail after consent is withdrawn, then deleted. The fixed 5-year retention for telephone-advertising consent under Section 7a UWG applies only if Finalform conducts telephone advertising; by default Finalform does not conduct telephone advertising, so Section 7a UWG does not apply and email-marketing consent is governed by the general Article 5(2) and Article 7 demonstrability duty.

6. Deletion mechanics, backups, and review

Routine deletion. Time-bound deletions in Section 4 are designed to run as scheduled jobs rather than on an ad hoc basis, so that data does not accumulate past its period by default. The scheduled purge jobs for the affected categories (raw visitor events, model-call telemetry, and security and access logs) go live before the first signed Data Processing Agreement; until then those categories are retained for the life of the account.

Backups. Backups are retained only for a bounded period rather than indefinitely. Data deleted from the live system is removed from backups as those backups expire on the backup rotation cycle, and any restore from backup re-applies prior deletions, so that records already deleted are not reintroduced into the live system. Backups are not selectively restored to retain deleted data.

Review. Finalform reviews this policy and the retention schedule at least annually and on any material change to the engine, the snippet, the sub-processors, or the applicable law, whichever is sooner. The review confirms that each period is still no longer than necessary, that the minimisation measures still hold, and that the scheduled purge jobs are running as intended. The review is the responsibility of the deletion-execution owner named in Section 1.

7. Relationship to the Data Processing Agreement

For visitor interaction data and any other personal data that Finalform processes on behalf of a customer, Finalform acts as a processor and the customer acts as the controller. For that data, deletion or return at the end of the engagement is governed by the Data Processing Agreement (Auftragsverarbeitungsvertrag, Article 28 GDPR), not by this policy alone.

Under the Data Processing Agreement, at the end of the provision of the processing services Finalform deletes or returns the customer’s personal data in line with the customer’s choice and the agreement, except where Union or German law requires storage of the personal data (Article 28(3)(g) GDPR). The retention periods in Section 4 for class A visitor data describe Finalform’s default operational behaviour during the engagement; the controller’s documented instructions and the Data Processing Agreement prevail where they differ. The technical and organisational measures that protect this data during retention are set out in the technical and organisational measures annex (TOMs) to the Data Processing Agreement.