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

• Purpose and scope
• Minimisation measures
• Deletion classes (Löschklassen)
• Retention schedule
• Statutory holds and erasure
• Deletion mechanics, backups, and review
• 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 metrics snapshot the engine records from them at each decision.
• Class B. Operational telemetry. Model-call telemetry (token counts and duration), security and access logs, in-app notifications, and sign-in rate-limit counters, 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, and the contract acceptance ledger that records which version of each contract document the account accepted.
• 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. Periods marked as enforced are executed by a scheduled purge job that runs once daily and attempts one evidence row per category per run; a failed evidence write surfaces separately rather than failing the deletion itself, and Section 6 describes the mechanism. For a category whose job is committed but not yet implemented, the period states the legally correct target under Article 5(1)(e); the Status column identifies those categories, and until the job is built the data is retained for the life of the account.

The unconcluded-experiment hold currently has no outer bound. The 90-day window for raw visitor events is suspended while the experiment those rows belong to has not concluded, so that a running test is not decided on truncated data. As implemented, "concluded" means the experiment reached its terminal state; an experiment that is paused, or left awaiting approval, holds its events for as long as it stays in that state. There is no maximum age at which those rows are deleted regardless. We disclose this rather than smooth over it: it is a known gap against Article 5(1)(e), it is tracked as a fix, and the fix is to define an outer bound after which the rows are purged whatever the experiment's state.

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.

The contract acceptance ledger is class D, not class E. The ledger records which version of the Terms of Service, the Acceptable Use Policy and the Data Processing Agreement each account accepted, and for a pilot partner which version of the Pilot Order Agreement, with a snapshot of the company name declared at signup and the account email that name the partner, together with the time of acceptance, the language the document was read in, and the surface the acceptance was given on. It is erased with the account, as the last step of the account-deletion hook and after the tenant data is wiped, so that an account which still exists always still holds the evidence of what it accepted. No statutory hold reaches it, because the statutory records this policy recognises are held elsewhere: the two class E rows in Section 4 place the 8-year Buchungsbeleg hold for billing records and invoices, and the 6-year Handelsbrief hold for business correspondence and contracts, in Stripe and the external accounting system, outside the Autopage database. The one ledger entry that also evidences a concluded paid contract, the order confirmation, has its statutory twin in that same external place: the Stripe Checkout Session metadata written when the order is placed carries the confirmation timestamp, the version of the confirmation wording, and the remaining fields of the record, so the evidence a statutory hold would reach survives in Stripe's retention class rather than in this database. Keeping the ledger row past account deletion would therefore add nothing the statutory archive does not already hold, and would contradict the immediate and complete deletion this policy and the Data Processing Agreement both promise.

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 run as a scheduled job rather than on an ad hoc basis, so that data does not accumulate past its period by default. The job runs once daily and covers raw visitor events, their session assignments, model-call telemetry, in-app notifications, expired dashboard sessions, and sign-in rate-limit counters. Each run attempts, per category, an evidence record of the cutoff it applied, the number of rows deleted, and whether the category completed or failed, so that the execution of this policy is evidenced rather than asserted; a failed evidence write is reported separately and does not prevent the deletion itself. Deletion is performed in bounded batches, which means a large backlog is cleared over successive runs rather than in a single long-running statement. The one category in Section 4 not yet covered, the dedicated security and access log, goes live before the first signed Data Processing Agreement; until then it is not separately retained, because it does not yet exist.

Derived aggregates lag the purge. Deletion removes the raw rows. Of the two aggregate layers computed from them, variant_metrics is a plain SQL view evaluated at query time and therefore reflects a deletion immediately, while context_variant_stats is a materialised view whose contents are refreshed on the periodic optimisation sweep and not by the purge itself. Between a purge and the next sweep, that materialised view can still hold population-level counts computed from rows that no longer exist. Those counts are identifier-free: they carry no session identifier and cannot be resolved to a visitor. We state this rather than omit it, because a deletion concept that describes only the primary tables would overstate how completely a deletion propagates.

Backups. There are no backups of the production database 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. For this policy that means a deletion has no backup tail: no copy of a deleted record survives in a backup and no restore can reintroduce one. Backups are a committed measure that goes live before the first signed Data Processing Agreement; once they exist they are retained only for a bounded period rather than indefinitely, data deleted from the live system is removed from them as they expire on the backup rotation cycle, any restore re-applies prior deletions, and backups are not selectively restored to retain deleted data.

The absence of backups is a resilience gap, not a deletion gap. It is recorded here because this policy describes where deleted data can survive, and today the answer is nowhere. The availability consequence is stated in the technical and organizational measures annex (Sections 5 and 6).

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.