Customer DPIA Assist Template

This template helps you, an Autopage customer, run your own Data Protection Impact Assessment (DPIA, German Datenschutz-Folgenabschätzung / DSFA) under Article 35 GDPR for deploying Autopage on your landing pages.

Your role. When you install Autopage on a page you own or control, you are the controllerfor your website visitors' personal data and Finalform GmbH is your processor under a Data Processing Agreement (Art 28 GDPR). The Article 35 DSFA is the controller's statutory duty. It is therefore your responsibility, not Finalform's. Finalform's duty is to assist you with it (Art 28(3)(f) GDPR), and this template, together with the documents named in Step 5, is how Finalform discharges that assistance.

What this template is, and is not. This is an aid that mirrors the scaffold a German DSFA follows (the DSK KurzpapierNr. 5 process and the four mandatory Art 35(7) report elements), pre-filled with the facts about Autopage you can lift into your own assessment and with Autopage's own worked risk evaluation as a starting point you adapt. It is not a finished DSFA and it is not legal advice. It does not reach conclusions for you. Use your own counsel and, where you have one, involve your Data Protection Officer throughout (Art 35(2)).

Do you even need a DSFA?

A DSFA is mandatory where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons (Art 35(1) GDPR). You decide this for your own deployment, but for most Autopage customers the answer is almost certainly yes, for two independent reasons.

1. The German DSK Muss-Liste. The German supervisory authorities publish lists of processing operations that always require a DSFA. Autopage matches Nr. 11 of the non-public-sector Muss-Liste, use of artificial intelligence to steer interaction or to evaluate personal aspects, and is adjacent to Nr. 9 (comprehensive profiles over interests or personality) and Nr. 14 (profiles over behaviour). A processing operation on the Muss-Liste requires a DSFA without any further balancing. The competent authority for Finalform is the LfD Niedersachsen (the Lower-Saxony state DPA), which adopts the DSK list. The authority competent for your own establishment may differ.

2. The WP 248 nine-criteria threshold. The Article 29 Working Party criteria, endorsed by the EDPB, treat processing that meets two or moreof nine criteria as likely-high-risk in most cases. Autopage's profile meets at least three:

• evaluation or scoring: behavioural profiling of your website visitors (WP 248 names "building a behavioural or marketing profile of a website user" as a canonical example);
• systematic monitoring of visitor behaviour;
• innovative use of a new technology: AI rewriting of your page copy.

Document your decision either way. Article 35(1) requires written reasoning. If you conclude a DSFA is not needed, record why, in writing, before you go live. If you conclude it is needed, work through the steps below.

Step 1: Systematic description of the processing (Art 35(7)(a))

This is the first mandatory element of your DSFA: a systematic description of the processing and its purposes. The block below is the factual description of Autopage, reconciled to how the product actually behaves in production. You can paste it directly into your assessment and then add your own purpose and legal basis in Step 2.

What Autopage does and the data it processes. Autopage is an autonomous landing-page optimization service from Finalform GmbH. After we install its JavaScript snippet on a page we own or control, Autopage assigns visitors to page variants, serves them via A/B testing, and uses a large language model supplied by Anthropic, PBC to rewrite the copy on our pages.

Gated collection. By default the snippet runs in relaxedmode: it fetches and applies a page variant before consent, but writes no cookie, accesses nothing on the visitor's device, and collects no behavioural data until the gate opens. The pre-consent variant request does cause the assignment to be recorded on Autopage's own systems against a random identifier held only in browser memory; nothing is placed on the visitor's device. We can switch the snippet to strict mode, in which the variant fetch and page change also wait for consent.

The gate opens on a consent signal from our consent management platform (CMP) via IAB TCF 2.x (Purpose 1) or the JavaScript API window.autopage.grantConsent(). In relaxed mode only, it also opens where Autopage recognizes no CMP on the page, on a fallback basis. That fallback is not consent. Nothing is inferred about what the visitor wanted, no consent record is created for them, and it relies on our own lawful basis as controller. Autopage shows us when it is active and gives us a switch to disable it. Recognition is pattern-based (the TCF API, known vendor scripts, globals and containers, Google Consent Mode) and is checked once, when the three-second window closes, so a fully custom banner Autopage does not recognize, or one that finishes loading after those three seconds, is treated as absent and the fallback applies to it. Wiring window.autopage.grantConsent() into our banner is the supported route for either case. If we have no consent banner, we should either add one or switch the snippet to strict mode rather than rely on this fallback.

A ?ap_preview=1 parameter lets us preview our own pages without any cookie being set or any visitor event being recorded; besides the variant request itself, the preview sends only a one-time anonymous installation check carrying the page address and tagged-element names. The pending state resolves after three seconds: to denied where a CMP is present but has not answered, and, in relaxed mode, to collecting on the fallback basis where Autopage recognizes no CMP. On such pages collection therefore starts three seconds into the visit, and a visitor who clicks or leaves before then is not recorded.

Data collected. Once the gate opens, which is a consent signal where Autopage recognizes a CMP on our page and, where it recognizes none, the non-consent fallback described above, the snippet sets one first-party cookie, a pseudonymous, random 30-day session identifier (ap_session, not a fingerprint), and collects coarse, bucketed signals: device class (mobile, tablet, desktop), a five-way traffic-source category (organic, social, paid, referral, direct), scroll depth, and time on page. No IP address, user-agent string, precise geolocation, device fingerprint, raw referrer, raw UTM parameters, or form input is ever collected or stored. This is data minimisation by design, not by truncation.

AI rewriting. Copy is generated and rewritten by the Anthropic model. Only the tenant brief, the baseline page copy, and population-level aggregate metrics (rates and medians) are sent to the model. Direct identifiers are stripped and no per-visitor data (no session identifier, no IP address, no raw event) is placed in any prompt. No prompt or response content is logged; only token-count telemetry is retained.

Recipients (visitor data). Finalform acts as our processor under a Data Processing Agreement. Two sub-processors receive visitor data: Railway Corporation (application hosting and compute, and the managed PostgreSQL database that stores the pseudonymous session identifier and the coarse behavioural events); and Anthropic, PBC (the language model, which receives population-level aggregates only, never per-visitor data). A third sub-processor, Cloudflare, Inc. (Browser Rendering), supports the baseline scrape but receives only our public landing-page URL and returns rendered HTML, no visitor data.

Where the data rests, and what still leaves the EEA. All visitor data persisted by the Autopage application is stored in the European Union: the Railway database and every production service run in Railway's Amsterdam region (europe-west4-drams3a), confirmed 2026-07-30. This establishes EU residency at rest only; Railway's separate US processing and access leg remains a third-country transfer covered by the safeguards stated below. The residency claim is scoped to Autopage's own application storage and does not extend to Railway's provider-side infrastructure logging, whose location Finalform has not verified and does not assert; the raw visitor IP can appear there. This is not the same as saying nothing leaves the EEA. Railway Corporation is a US entity whose data processing 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 the raw visitor IP transits Railway's edge and proxy layer. Anthropic processes outside the EEA and does not limit this to the United States. Cloudflare processes in the United States. For those transfers: Railway's US leg relies on the EU-US Data Privacy Framework where the recipient is certified and otherwise on the EU standard contractual clauses, with a transfer-impact assessment maintained either way; Cloudflare relies on its Data Privacy Framework certification and otherwise on standard contractual clauses with supplementary measures, with a transfer-impact assessment maintained either way; and Anthropic relies on Article 46 standard contractual clauses with a transfer-impact assessment, since Anthropic makes no Data Privacy Framework claim. Each mechanism is stated with its fallback, so the description stays complete even if a certification lapses.

Roles. We are the controllerfor our visitors' data; Finalform is our processor.

Notes on the recipients you cite, to confirm against the current Sub-processor List before you rely on this paragraph:

• Railway Corporation (Delaware, US). Hosting plus the managed PostgreSQL database holding all persisted visitor data. Raw visitor IP transits the Railway edge and may sit in provider access logs at the infrastructure layer, but no Autopage application code stores it. The Autopage database and services are hosted in Amsterdam, Netherlands (europe-west4-drams3a), verified 2026-07-30, so the application data is stored at rest in the EU; this does not remove Railway's separate third-country processing and access leg. That verification covers Autopage's own services and volume, not Railway's provider-side logging, whose location is not asserted here. Railway Corporation is nonetheless a US entity whose addendum states that its primary processing takes place in the United States and that the US transfer is necessary, so a US processing leg remains, covered by the DPF where the recipient is certified and otherwise by the EU SCCs, with a transfer-impact assessment maintained for that leg either way.
• Anthropic, PBC (Delaware, US). Receives no per-visitor data, only the tenant brief, baseline copy, and population-level aggregates with identifiers stripped. Engaged on a no-training basis (no training on commercial API inputs or outputs; the customer-controllable user-feedback setting is 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. Note that this is Anthropic's retention, not Finalform's: the statement above that no prompt or response content is logged describes Finalform's own systems, which retain only token-count telemetry. The two are consistent, and both must be carried, since a copy of the prompt content does exist at Anthropic for 30 days even though none exists at Finalform. Because identifiers are stripped and no per-visitor data reaches a prompt, that window covers tenant briefs, baseline copy and population-level aggregates rather than visitor data. Transfer rests on Art 46 SCCs plus a transfer impact assessment, since Anthropic makes no DPF claim and does not limit processing to the United States.
• Cloudflare, Inc. (Delaware, US). Receives only the public landing-page URL, no visitor PII. Transfer rests on Cloudflare's Data Privacy Framework certifications and otherwise on standard contractual clauses with supplementary measures, with a transfer-impact assessment maintained either way. Stated with its fallback so the description holds even if a certification lapses.

Stripe (your billing) and Resend (transactional email to your account holders) process your own account and billing data, for which Finalform is a separate controller. They do notprocess website-visitor data and are not part of this visitor-data assessment. The full sub-processor list is in Finalform's Sub-processor List.

Categories of data subjects: your website visitors. Categories of personal data: a pseudonymous 30-day session identifier, coarse bucketed behavioural signals (device class, traffic-source bucket, scroll depth, time on page), and variant-assignment data.

Step 2: Your purpose and legal basis (fill in)

The systematic description must include the purposes of the processing (Art 35(7)(a)) and, in the German reading (DSK Kurzpapier Nr. 5), the legal basis for each operation. State yours.

• Purpose of processing. State why you deploy Autopage, for example: ____________________ (for example, optimizing landing-page conversion on your own pages).
• GDPR Article 6 lawful basis. As the controller, state your lawful basis for processing visitor data, for example: ____________________ (for example, consent under Art 6(1)(a), or legitimate interest under Art 6(1)(f) with a documented balancing test). This is a separate question from the device-storage consent rule below.
• § 25(1) TDDDG device-storage opt-in. Distinct from your Art 6 basis. Because Autopage stores and reads a cookie on the visitor's device, and A/B testing plus behavioural analytics are not strictly necessary, you must obtain opt-in consent before collection. Confirm your CMP obtains that opt-in before Autopage collects, and that you register Autopage under Statistics/Analytics or Personalization, never Necessary/Essential: ____________________.
• Your privacy notice. Confirm your own privacy notice discloses the processing, the AI rewriting, and Finalform and its sub-processors as recipients: ____________________.

Step 3: Necessity and proportionality test (Art 35(7)(b))

The second mandatory element. Assess whether the processing is necessary for, and proportionate to, your stated purpose. Work through these prompts.

• Is the processing necessary for the purpose? Behavioural interaction data is necessary to run A/B experiments and to evaluate which variant performs better; without it there is no basis on which to choose a variant. Confirm this holds for your deployment: ____________________.
• Are there less-intrusive alternatives? Consider whether you could achieve the purpose with less data or a less-intrusive method, and record why you did or did not adopt one: ____________________.
• Is the data minimised? Note that Autopage collects no IP, user-agent, referrer, geolocation, or fingerprint, keeps only a pseudonymous session identifier plus coarse buckets, strips direct identifiers before any AI prompt, and sends only population-level aggregates to the model. Record how this supports proportionality for your purpose: ____________________.
• Automated decision-making (Art 22).Autopage's A/B experimentation and AI copy rewriting operate at the population level. They are not, in Finalform's assessment, a solely-automated individual decision producing legal or similarly significant effects on a visitor (Art 22(1)). Confirm this characterisation for your deployment: ____________________.

Step 4: Risk evaluation (Art 35(7)(c))

The third mandatory element is an evaluation of the risks to data subjects, not a yes/no checklist. A DSFA assesses each risk for severity and likelihood, applies measures, and records the residual risk that remains (DSK Kurzpapier Nr. 5, steps 7 and 8).

The table below is pre-filled with Autopage's own draft risk assessment as a worked example. Adapt it to your deployment: your privacy notice, your CMP configuration, and your transfer position will change the residuals. The ratings are draft assessments for you and your DPO or counsel to confirm, not legal facts. Scale: Low / Medium / High.

One more risk to weigh as the publisher. The AI rewrites your live page copy. You remain the publisher responsible for the truthfulness, legality, and IP clearance of the copy that is served. Record your review measure: ____________________.

Step 5: Measures and safeguards (Art 35(7)(d))

The fourth mandatory element: the measures, safeguards, and mechanisms that address the risks. Record both your controller-side measures and what Finalform provides as your processor.

Your controller-side measures (fill in).

• Privacy-notice disclosure of the processing, the AI rewriting, and the recipients: ____________________.
• CMP configuration: opt-in before collection, Autopage registered under Statistics/Analytics or Personalization: ____________________.
• Your review process for AI-generated copy before it goes live: ____________________.
• Your data-subject-rights handling (access, erasure, objection) for visitor requests: ____________________.

What Finalform provides (Art 28(3)(f) assistance). These documents are part of Finalform's statutory duty to assist your DSFA, not goodwill. On request, Finalform provides:

• The Technical and Organizational Measures (TOMs) (Art 32), describing the security measures Finalform applies as processor.
• The Sub-processor List (Art 28(2)), naming every sub-processor, its role, region, and transfer mechanism, with an effective date.
• The Data Processing Agreement (DPA) (Art 28), setting out instructions, confidentiality, sub-processor rules, assistance with data-subject rights, international transfers, and deletion or return at the end of the service.

Scope of Finalform's DSFA assistance.Beyond handing over the three documents above, Finalform provides the factual descriptions and means a controller needs to complete this assessment, but the DSFA itself remains the controller's statutory duty under Art 35 GDPR and Finalform does not carry it out or reach its conclusions for you.

Request channel. Requests may be directed to support@autopage.dev.

Step 6: DPO and data-subject view

Data Protection Officer (Art 35(2)). If you have a DPO, you must seek the DPO's advice when carrying out a DSFA. This is a duty during the assessment, not a footnote at the end. Record the DPO's advice and the date: ____________________.

Views of data subjects (Art 35(9)). Where appropriate, you should seek the views of data subjects or their representatives on the intended processing. For transient, large-N, pseudonymous website-visitor populations this is often not practicable. If you reach that conclusion, record it as considered and impracticable rather than simply omitting it: ____________________.

Step 7: Outcome and prior consultation

Record your outcome. If, after your measures, a high residual risk remains, Article 36 GDPR obliges you to consult your supervisory authority before you begin processing. Decide and record this before go-live.

Step 8: Re-run trigger (Fortschreibung)

A DSFA is iterative, not a one-time form (DSK Kurzpapier Nr. 5, step 16; Art 35(11)). Re-assess on any material change, including: a new sub-processor, a new or changed AI model, a new category of data collected, a new international transfer, or a change in your purpose or legal basis. Finalform notifies controllers of changes to its Sub-processor List; treat each such notice as a trigger to review this assessment.