GDPR

What happens to the data your forms collect: where answers and attachments are stored, what is never recorded, who is responsible for which part of it, and the controls that delete it.

If a form asks for a name, an email address or anything else that identifies a person, the people who fill it in have rights over what they typed, and whoever asked has duties. This page says what happens to those answers in Tinyform, who is responsible for which part of them, and what changes if you run the software on your own server. How to create a GDPR-compliant form is the practical guide to the form itself.

What happens to the answers your forms collect

Attachments and signatures are not on the public web. A file a respondent uploads, and a signature they draw, go to a storage bucket of their own that has nothing serving it: no public address, no anonymous read, and no domain pointed at it. Every path that reads one of those objects asks first — either a signed-in member of the workspace that owns the form, or a link the server signed that stops working after seven days. A request that is neither gets a 404 rather than a refusal, so the door cannot be used to find out which submissions exist. Covers, logos and the images an author puts on a page are a separate, public bucket; what a respondent attached never enters it. The app refuses to start if the two are configured as one.

Deleting a response deletes what came with it. Removing a submission from the Submissions tab removes the row, the files the respondent uploaded and the signature they drew, in a single transaction — not a row marked deleted with the bytes left behind. Deleting a form puts it in the trash for thirty days and then removes it with every submission under it.

A retention window does it without being asked. Each form can carry its own period, from minutes to years, after which a background sweep removes each submission that has passed that age, unfinished fills included. Submissions data retention is the control, and it is free on every plan.

Answers are only ever shown to the workspace that owns the form. Access to a form's submissions, files and Insights follows workspace membership; there is no other reader.

Connections are encrypted. Every page and every submission travels over HTTPS, with certificates issued and renewed automatically — including for a domain a form owner connects themselves. Encryption at rest is a property of the disks and the object store a deployment runs on rather than something the software configures, so it is the deployment's own privacy notice that can state it.

Backups are kept away from the app. Both databases are dumped nightly into a third bucket that the application never touches, under credentials scoped to that bucket alone, and nothing is kept on the machine itself. Backups older than thirty days are removed.

Is Tinyform GDPR compliant?

Compliance belongs to a deployment, not to a piece of software, and any product that tells you otherwise is describing its own paperwork rather than your obligations. What the software can do is make a compliant deployment straightforward — the section above is that list — and then get out of the way of the decisions that are genuinely yours: what you ask for, why you are allowed to ask, the notice you give your respondents, and how long you keep what they tell you.

The rest of the page is about who owns which of those decisions.

Who is responsible for what

For what a respondent types into a form, the form's owner is the controller. You decided what to ask and why, so the answers are yours; whoever runs the server stores and delivers them on your behalf, as a processor. The Data Processing Agreement is the agreement between the two.

For the account data of the form owners themselves — the address you signed up with, your workspaces, your sessions — the operator of the deployment is the controller. The Privacy notice sets out what is held and why.

If you run the software yourself and are the only person building forms on it, both roles are yours and there is no agreement between two parties to make.

What the product records without being asked

Four things, and they are worth knowing before you publish a form.

Insights counts footsteps. Views, starts, answers and submissions are counted for each form so its owner can read the Insights tab. One visitor is told apart from another by a hash of their address, their browser and the current date, taken under a secret only that deployment holds; because the date is part of what is hashed, the same person cannot be recognised tomorrow or on another form. No address is stored in the analytics database, no cookie is set for any of it, no consent banner is drawn, and a deployment that has not set that secret records nothing at all rather than an identifier somebody could guess. Alongside the hash the event keeps a country and city, the device, browser and operating system read off the request, the host name of the page that linked to the form, and — so the owner can see where people give up — which question was reached. No answer ever rides that path; the analytics store holds counts and never the words somebody typed. Raw events are kept ninety days; the daily counts computed from them outlive them.

Two footnotes on that, because a privacy page should not round them off. Views and submits are recorded by the server from the request itself; starts and answers are batched by the page and sent to the deployment's own address, which is a first-party request that sets nothing and carries no answers. And addresses do exist briefly, outside analytics: the counters that stop somebody hammering a form or a password box hold the raw address for up to an hour and are then deleted.

The country lookup asks nobody. Both the country on an analytics event and the Respondent's country block read a MaxMind database file on the server's own disk. No request leaves, and a deployment without that file simply records no country.

Duplicate prevention stores a key, not an address. If a form's owner turned on Prevent duplicate submissions and chose the request's address as the key, what is stored beside the submission is a salted hash of it, never the address. If they chose the browser instead, the published page keeps a random id in that browser's own storage — minted only for a form that uses the setting, never planted on a visitor speculatively.

Signing in is recorded. An account's sessions are stored with the address and browser they were started from. That is about the people who build forms, not the people who fill them in: a respondent who only fills a form in is never given a cookie.

There is no advertising pixel, no marketing tag and no third-party analytics script anywhere in the product — not on a published form, not in the builder, not on this help centre. Outside code can still reach a published page, but only because a form's owner asked for it, and Where someone else can be involved below is the whole list.

The controls a form owner has

Export a form's submissions as a CSV file from the Submissions tab.
Delete a single submission or a whole selection; How do I delete responses walks through it.
Set Submissions data retention so submissions delete themselves after a window you choose.
Delete a form, which waits thirty days in the trash first; Delete and recover form data covers the trash.
Ask for consent inside the form, with an unticked box and a link to your own notice — the shape How to create a GDPR-compliant form describes.
Protect a form with a password, verify a respondent's email address, or add a reCAPTCHA block, so that what you collect is what you meant to collect.

Where someone else can be involved

Everything the product needs to run is a container in the deployment's own stack. What follows are the places another company can enter, and every one of them is either configuration or a choice a form owner made.

Component	What it is for	When someone else is involved
The database	Accounts, forms and answers	Never — it runs in the deployment's own stack
Object storage	Uploads, attachments and signatures	Only where the deployment points storage at a hosted bucket instead of the built-in one
The analytics store	The events behind Insights	Never — it runs in the deployment's own stack
The country database	The country on an event and the `Respondent's country` block	Never — it is a file on the server's disk
Amazon SES	Every email the product sends, including a submission notification carrying answers	Always. Mail is the one thing this product cannot do without an account somewhere
Stripe	A paid plan, where one is sold, and a payment a `Payment` block takes	Where it is configured. A form with a payment block loads Stripe's script and draws Stripe's own card fields, under Stripe's privacy policy
Google reCAPTCHA	Bot protection	Only on a form whose owner added the block, on a deployment that configured it. Google's script runs under Google's own privacy policy
Google Fonts	The form's typeface	Only where the form's font was picked from Google's catalogue, which fetches it from Google as the page draws. The default typeface is served by the deployment and loads nothing
Embedded content	A video, a map or a page an author dropped into a form	Whatever the author embedded, from whoever hosts it
A webhook or integration	Whatever the form's owner chose to send	Only what that owner connected, and it is their sub-processor rather than the operator's

Which of those a particular deployment actually uses, and where each one runs, belongs in that deployment's own Privacy notice and Data Processing Agreement.

If you run the software yourself

Tinyform is open source, and docker compose up -d gives you the whole product — the same code, with no feature held back. Everything above is still true, and three things move:

You are the operator. Where the server is, and therefore where the answers live, is your decision rather than something to discover. So are the disks it runs on and whether they are encrypted.
You are the controller of your own account data, and the processor for anyone else who builds forms on your install. If you are the only one, both roles are yours.
The notices are yours to write. Privacy notice, Cookie notice, Terms & Conditions and the Data Processing Agreement are templates, written to describe this software accurately, with your identity, your jurisdiction and your actual providers left for you to fill in. Review them with your own counsel before publishing them.

Mail is the one place a self-hosted install is not self-contained: the whole stack runs without an Amazon SES account, and cannot email anybody without one.

How to create a GDPR-compliant form — consent, retention and deletion in practice.
Privacy notice — what is stored, why, and for how long.
Cookie notice — every entry the product writes into a browser.
Data Processing Agreement — the terms between a form owner and the operator.
Submissions data retention — the control that deletes submissions as they age.