Data Processing Agreement — SFT Visitor Journeys

Draft under legal review, not yet in force.

This is an engineering-drafted template prepared for legal review, not a finished legal document. Every technical fact in it (retention periods, sub-processors, security measures) is taken directly from the system’s own engineering specification — nothing here is invented or assumed. Bracketed items marked [TBD — …] are open decisions the founder and/or the lawyer still need to make; do not present this to a customer, or link it from the Terms and Stripe Checkout’s acceptance step, until it has been reviewed and every TBD is resolved.

between the customer identified in the SFT Visitor Journeys account (“Controller”)

and Smooth Flow Tech, Horn, Austria [TBD — full legal name, registered address, and company register number of the entity operating SFT Visitor Journeys] (“Processor”)

(each a “Party”, together the “Parties”)

This Data Processing Agreement (“DPA”) supplements the Terms of Service between the Parties and applies whenever the Processor processes Personal Data on the Controller’s behalf in connection with the SFT Visitor Journeys service (“the Service”). In the event of a conflict between this DPA and the Terms of Service on data protection matters, this DPA prevails.

1. Subject matter and duration

Subject matter: the Processor operates a web-analytics platform. The Controller installs a tracking script (and, optionally, a reverse-proxy configuration and a Google Ads tracking template) on its own website(s), which sends data about that website’s visitors to the Processor’s infrastructure for processing and display back to the Controller.

Duration: this DPA runs for as long as the Controller has an active account and at least one site configured with the Service, and survives its termination for as long as any Personal Data covered by it remains with the Processor (see §7, Deletion).

2. Nature and purpose of processing

The Processor collects, stores, aggregates and displays data about the Controller’s own website visitors, on the Controller’s instructions, for three purposes only:

Web analytics — page views, clicks, scroll depth, time on page, navigation paths, and similar behavioural signals, shown back to the Controller as reports and “visitor journeys”.
Lead attribution — linking a form submission, an embedded booking or contact tool, or a webhook-reported lead, back to the visit and marketing channel that produced it.
Ad-fraud detection — flagging visits and ad clicks that show signs of automation or originate from data-centre network ranges, so the Controller can review them and, at its own discretion, act on them in its own advertising accounts.

The Processor does not use Personal Data processed under this DPA for its own purposes (e.g. to build products for other customers, train models, or for its own marketing), and does not sell it.

3. Categories of data subjects

Visitors to the Controller’s website(s) — the general public browsing those sites, who have no direct relationship with the Processor.

4. Categories of Personal Data

Exactly as processed by the Service:

IP address (visitor’s own website visits; also carried on ad-click records where the visitor arrived via a tracked ad)
Browser user agent string (ad-click records only)
A pseudonymous, per-visitor, per-day identifier (“day id”), derived from the IP address, user agent, and a secret salt that is deleted at the end of each day. This identifier cannot be recomputed from the IP address once that day’s salt is deleted, but is stored alongside the raw IP address for the retention period below.
A persistent visitor identifier, stored in the visitor’s browser, only when the Controller has configured a consent mode that permits it and the visitor has given the relevant consent.
Google Ads click identifiers (gclid, gbraid, wbraid) when a visit originated from a tracked ad click.
Page paths and titles visited, labels of clicked elements (the visible text or a developer-assigned name), external referrer (limited to origin and path, with no query string), device class, browser language, and a coarse network classification (residential/unknown, data centre, private relay, or “Google ad review” traffic).

Categories of Personal Data explicitly NOT processed: the values a visitor types into any form field, contenteditable region, or password field; cookies (the Service sets none); names or e-mail addresses (a “lead” event carries only a provider name and an optional short label chosen by the Controller or its own code — the lead webhook rejects any other field, including e-mail addresses, outright).

5. Retention

IP addresses and user agent strings: erased 60 days after collection (automated deletion, verified on a nightly schedule).
All other event data (page views, clicks, journeys, ad-click records): erased 180 days after collection.
The daily salt used to compute a day’s pseudonymous visitor identifier: deleted at the end of that day.
Account and billing data (organization, users, site configuration, invoices): retained for as long as the Controller’s account exists, plus any period required by applicable tax or accounting law.
Backups: the Processor backs up its databases (account/configuration data and visitor/event data) every night and deletes each backup 14 days after it was taken. The backups are kept on the server and, encrypted before they leave it, in object storage in the EU (Annex 2). In addition, the hosting provider keeps its two most recent weekly backups of the whole server. Because of this, Personal Data that has been deleted from the live system under the schedule above may persist in backups for up to a further 28 days before the last copy is deleted. [Check before signing: the hosting provider’s backup retention as currently stated by Hostinger.]

6. Technical and organisational measures (TOMs)

See Annex 1 below.

7. Sub-processors

The Processor’s current sub-processors for data covered by this DPA are listed on our sub-processor page, which is incorporated by reference and forms Annex 2 of this DPA. [TBD — the lawyer should decide and state here the mechanism for authorising new sub-processors: general written authorisation with advance notice and a right to object (Art. 28(2) GDPR), or specific prior authorisation for each one].

The Processor shall:

a. process Personal Data only on the Controller’s documented instructions (including regarding international transfers), unless required to do otherwise by EU or Member State law, in which case it will inform the Controller of that legal requirement before processing, unless that law prohibits this; b. ensure that persons authorised to process the Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality; c. implement the technical and organisational measures set out in Annex 1; d. respect the conditions for engaging sub-processors set out in §7; e. taking into account the nature of the processing, assist the Controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller’s obligation to respond to requests for exercising a data subject’s rights (see §9); f. assist the Controller in ensuring compliance with its obligations under Articles 32 to 36 GDPR, taking into account the nature of processing and the information available to the Processor; g. at the choice of the Controller, delete or return all Personal Data to the Controller after the end of the provision of services relating to processing, and delete existing copies, subject to §5’s backup retention (see §11); h. make available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR, and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller, subject to reasonable advance notice and confidentiality (see §10).

9. Assistance with data subject requests

Because visitor data is pseudonymous by design, the Processor cannot on its own identify which stored record belongs to a specific data subject; it can only look up and act on an IP address that the Controller (or the data subject, via the Controller) supplies. When the Controller receives a data subject request (access, erasure, objection, etc.) concerning a website visitor, the Processor will, on the Controller’s instruction and within the 60-day retention window during which the IP address is still held (§5), locate and, where requested, erase the corresponding record(s) by IP address. [TBD — the lawyer should set: a response-time commitment for this assistance, and whether it is offered at no extra cost or as a billable service beyond a stated number of requests per year].

10. Audits

[TBD — the lawyer should draft this section: scope and frequency of audits the Controller may conduct or commission, notice period, cost allocation, and whether a certification, an independent auditor’s report, or a completed questionnaire may be offered by the Processor in place of an on-site audit.]

11. Deletion at the end of the contract

On termination of the Controller’s account (or removal of a specific site), the Processor deletes the site’s data (site deletion cascades its domains, keys, labels and billing rows in PostgreSQL; the corresponding ClickHouse event data is deleted separately). [TBD — the lawyer and the founder should set: how quickly after termination this deletion happens (immediately, or after a grace period during which the Controller can still export or reactivate), whether the Controller receives a data export before deletion, and confirm the backup tail described in §5 applies here too.] This item also tracks the Terms of Service’s open item on data deletion after cancellation — the two documents must state the same policy once decided.

12. Breach notification

The Processor shall notify the Controller without undue delay after becoming aware of a Personal Data breach concerning Personal Data processed under this DPA, providing the information reasonably necessary for the Controller to meet its own notification obligations under Articles 33 and 34 GDPR. [TBD — the lawyer should set a specific maximum notification window, e.g. “without undue delay and in any event within 48 hours”, and what the notification must contain at minimum.]

13. International transfers

[TBD — confirm with the lawyer. As designed, all sub-processors processing visitor data under this DPA are located in the EU (see our sub-processor page), so no transfer mechanism (SCCs, adequacy decision) should be needed for visitor data; confirm this remains true once the open sub-processor decisions (backup storage, transactional e-mail) are made, and add Standard Contractual Clauses as Annex 3 if any sub-processor ends up outside the EU/EEA or a country covered by an adequacy decision.]

14. Liability

[TBD — the lawyer should draft a liability clause consistent with the main Terms of Service, typically referencing/capping at the same limits.]

Annex 1 — Technical and organisational measures

Taken from the Service’s own security design; the lawyer should confirm this list is complete and add any organisational measures (staff policies, access review cadence, etc.) that exist outside the codebase.

Hosting: a single VPS in an EU data centre (§13; exact data centre TBD, see our sub-processor page). PostgreSQL and ClickHouse have no published ports and sit on an internal network reachable only from the application container.
Encryption in transit: the public-facing reverse proxy terminates TLS for all traffic; internal service-to-service traffic stays on the Docker Compose internal network.
Access control: database roles follow least privilege — the application’s own database role has data-manipulation rights only; a separate, more privileged role is used solely for running migrations. Dashboard access requires authenticated login (e-mail and password, with required e-mail verification); every site-scoped action re-checks the requesting user’s membership and permissions on the server, not just at the page/navigation level.
Least-privilege secrets: all credentials live in a single, file-mode-restricted environment file on the server, never in the application’s source code or container image; the application validates every required secret is present at startup and refuses to start otherwise.
Key rotation: the Controller can rotate its site’s proxy and API keys at any time (a new key is issued, the old one is revoked, and the change takes effect immediately). The Controller’s public tracking key can likewise be regenerated, immediately invalidating the old one, if it is ever exposed or abused.
Logging discipline: application logs never contain IP addresses, user agent strings, click identifiers, or lead references — only a site identifier, an error reason, and a short diagnostic hint. Access logging at the reverse-proxy layer is disabled specifically because it would otherwise capture visitor IP addresses.
Automated retention enforcement: the 60-day and 180-day deletion windows in §5 are enforced by the database itself (column- and table-level time-to-live rules), not by a script that could be forgotten or fail silently, and are checked nightly.
Abuse defences on the public data-collection endpoint: an allow-list of the Controller’s own registered domains, automated-traffic detection, per-IP and per-site rate limits, and strict validation of every field, all applied before any data is written.
Backups: nightly, each kept 14 days, encrypted before it leaves the server for EU object storage; the hosting provider’s weekly server backups (the two most recent) add up to 14 days — see §5 for how this interacts with the deletion schedule.

Annex 2 — Sub-processors

See our sub-processor page.

Annex 3 — International transfer mechanism (if applicable)

[TBD — add only if a non-EU/EEA sub-processor is engaged; see §13.]

Data Processing Agreement (Art. 28 GDPR)