splitforms GDPR compliance — form backend data protection.

Roles — controller vs processor

GDPR splits responsibility for personal data between two roles, and developers building forms often conflate them. Here's how it works on splitforms:

One practical consequence: if a form submitter emails [email protected] asking us to delete their data, we can't do that without identifying which form they submitted to — we'll route the request to you, the form owner, who has the context to act.

What data is collected on a submission

When someone POSTs to your form, splitforms persists exactly this set of fields and nothing else:

We do not enrich submissions with third-party data, do not run analytics on submission contents, and do not share them with anyone other than you (the form owner) and the sub-processors listed below.

Lawful basis for processing

Under GDPR, every act of processing personal data needs one of six lawful bases (Art. 6). For form submissions handled through splitforms, the relevant ones are usually:

• Consent — newsletter sign-ups, marketing opt-ins, surveys. The submitter freely says "yes, you may contact me."
• Legitimate interest — contact forms, lead forms, sales inquiries. The submitter is reaching out to you for a clear, expected purpose.
• Contract — quote requests, service applications. Processing is necessary to take steps at the request of the data subject prior to entering into a contract.

Capturing the basis is your responsibility as controller — usually a short note in your form's privacy text plus, where consent applies, a checkbox the submitter ticks themselves. splitforms doesn't inject consent text on your behalf.

The eight data subject rights — and how to action each

GDPR grants data subjects (the people who fill out your forms) a defined set of rights. Here's how each one maps onto splitforms tooling:

1. 01Right of access (Art. 15)

   Form owners can view all submissions in the splitforms dashboard, export them as CSV on paid plans, or pull them as JSON through the REST API on any plan. End-users (form submitters) should request access from the form owner — splitforms doesn't know which submission belongs to which natural person without that context.

2. 02Right to rectification (Art. 16)

   Submission values can't be edited in the dashboard today. To correct stored data, form owners can delete the wrong entry and have it resubmitted, or contact [email protected]. End-users should contact the site that operates the form.

3. 03Right to erasure (Art. 17)

   Form owners can delete individual submissions from the dashboard, or delete their entire splitforms account, which cascades and removes every form, submission, webhook, and uploaded file.

4. 04Right to restriction of processing (Art. 18)

   Form owners can pause a form (`is_active = false`) so it no longer accepts submissions while review is in progress. The existing submission rows stay untouched until you choose what to do with them.

5. 05Right to data portability (Art. 20)

   Form owners on paid plans can export any form's submissions as a CSV file from the dashboard; on any plan, the REST API returns them as JSON. The CSV export contains all original fields, IP, user-agent, referer, and timestamp — a structured, machine-readable format.

6. 06Right to object (Art. 21)

   Delete the relevant submission(s) from the dashboard. For account-level objections (e.g. you no longer want splitforms processing for any of your forms), delete your account.

7. 07Rights related to automated decision-making (Art. 22)

   Not applicable. splitforms does not perform automated decision-making or profiling on form submitters. The optional rule-based spam scoring flags spam vs not-spam for the form owner's review; it does not produce legal effects on the submitter.

8. 08Right to withdraw consent (Art. 7)

   Consent for the underlying form (e.g. newsletter sign-up) is captured by the form owner, not splitforms. As the data controller, you remain responsible for offering withdrawal mechanisms (e.g. an unsubscribe link). On the splitforms side, deleting the submission removes our copy.

Data Processing Agreement (DPA)

We offer a standard DPA for any splitforms customer that needs one for their own GDPR obligations — typical for agencies handling EU client data, B2B SaaS reselling forms, and anyone whose own privacy programme requires a written processor contract.

The DPA covers: processor obligations under Art. 28, sub-processor list (matching the table below), breach notification timelines, data subject rights flow-through, audit rights, and Standard Contractual Clauses for any transfer outside the EU.

To request: [email protected] with subject "DPA".

Sub-processors

We use a small set of named sub-processors to operate the service. We update this list when it changes, with notice sent to active accounts before any new sub-processor is engaged.

Data location

Today the default region is the United States. Submissions, profiles, and uploaded files all live on Supabase Postgres and Storage in AWS US regions. The application is hosted on Hostinger and served through Cloudflare’s edge network. Amazon SES sends from US infrastructure.

Planned: EU data residency. A Supabase EU-resident project for splitforms is on the roadmap. We'll list the exact region and migration steps on this page the day it goes live. Until then, EU customers can rely on the SCCs documented in our DPA for cross-border transfers.

Data breach notification

If splitforms becomes aware of a personal data breach affecting your data, we will notify you within 72 hours of becoming aware, in line with Art. 33 GDPR. The notice will include: the nature of the breach, the categories and approximate volumes of data affected, the likely consequences, and the measures we have taken or propose to take to address it.

Notification goes to the email on your splitforms account, so please keep that address current.

International transfers

Where personal data is transferred outside the EEA, UK, or Switzerland, splitforms relies on the European Commission's Standard Contractual Clauses (SCCs) as the transfer mechanism, alongside our sub-processors' own adequacy decisions and Data Privacy Framework participation where applicable.

We do not currently rely on Binding Corporate Rules — we don't have the multi-entity structure that BCRs are designed for. SCCs are the right tool for a small, single-entity SaaS.

Retention

Submissions have no automatic expiry on any plan, Free included: they are kept until you delete them. You stay in control of when data is removed:

• Per-submission delete from the dashboard at any time. Deleted submissions sit in the recycle bin for 180 days, then are permanently deleted; emptying the bin erases them immediately.
• CSV export from the dashboard on paid plans, so you can keep your own archive offsite.
• Account deletion cascades through Postgres foreign keys and removes every form, submission, webhook, uploaded file, and profile row. Backups rotate within 30 days.

For a custom retention policy (e.g. auto-delete submissions older than 90 days), email [email protected].

Form drop-off analytics

Forms embedded through our WordPress plugin or our iframe embed count how many people opened the form, how many started filling it in, and which field they were in when they left. Form owners see this on their Analytics page so they can find the question that is costing them leads.

It records field names, not field values. If a visitor types an email address and then closes the tab, we record that they were in the field called email — never what they typed. Nothing a visitor enters reaches us unless they actually submit the form. The server independently discards any field name the form did not declare, so this holds even if the page script is tampered with.

No cookie, no local storage, and no identifier is written to the visitor's browser. The session reference is a random value that exists only in page memory and is gone when the tab closes, so the same person visiting twice is counted as two views and cannot be linked across visits, sites or devices. No IP address or browser string is stored — only a desktop / mobile / tablet label. Records are deleted after 90 days.

Form owners can switch this off per form under "Auto-reply & form behavior" in the dashboard. The plain HTML form snippet contains no JavaScript and is not covered by this at all.

Partial lead capture (optional, off by default)

Separately from the names-only drop-off analytics above, a form owner can turn on partial lead capture for a specific form. When enabled, if a visitor fills in part of that form and then leaves without submitting, the values they entered are saved so the owner can follow up. This is the one case where what a visitor types can reach us before they press submit.

It is off by default and chosen form by form by the owner, and any form with it enabled shows the visitor a short notice that their progress may be saved. As with drop-off analytics, it sets no cookie and writes no identifier to the browser, stores no IP address or browser string, and records are deleted after 90 days. A form owner who enables it is the data controller for those partial entries and is responsible for having a lawful basis and disclosing it in their own privacy notice.

Cookies

splitforms.com uses essential cookies only — an HttpOnly, SameSite=Lax session cookie issued by Supabase Auth so you stay signed into the dashboard. We do not run marketing cookies, advertising pixels, session-replay scripts, or third-party analytics on the dashboard.

Cookies on your site are your responsibility. The splitforms POST endpoint at /api/submit doesn't set cookies in your visitors' browsers — it's a stateless API call.

Frequently asked questions