Where does the data from your forms actually go?

A driving school in Thun has a registration form on its website: name, address, date of birth, phone number, licence category, and a comments box in which people occasionally mention that they wear glasses. The form has worked for years. One day a customer calls and asks where those details are actually stored.

It is a simple question and a surprisingly hard one to answer if nobody in the business has ever looked. But it can be answered, and without any specialist knowledge: the answer sits in a handful of documents that already exist, and the journey the data takes has fewer stops than you might expect.

The chain, stop by stop

Between the click on “send” and the moment someone in the business reads the answer, the stops are usually the same ones.

Stop	What happens there
Browser	The entries are assembled into an HTTP request
The form’s target	The request goes to the server named in the form
The provider’s app	The answer is validated, stored, logged
Storage and backups	Database, file storage for uploads, backups
Notification	An email containing the answer goes to the business
Connections	Export, spreadsheet, accounting, newsletter tool, webhook

Each of those stops is a place, and places can be named. The four distinctions behind them — storage location, legal system, access and sub-processors — are pulled apart in a separate post; this one follows the concrete route of a single form submission.

Stop 1: where the form sends

An HTML form has an attribute called action. It decides where the data goes. MDN Web Docs put it this way: the action attribute defines where the data gets sent, and its value must be a valid relative or absolute URL; if the attribute is not provided, the data is sent to the URL of the page containing the form.

That single line decides more than anything else on the page. If it holds an address on your own domain, the answer stays with your own hosting to begin with. If it holds the address of a form service, the answer leaves your website the moment someone presses send — even when the form looks embedded and the visitor never appeared to leave your site at all.

Whether the transfer is encrypted depends on the protocol in that address. With an HTTPS address the data is encrypted along with the rest of the request; if the form sits on a secure page but points at an insecure HTTP address, MDN notes that all browsers show a security warning when the visitor tries to send.

It is worth being clear about what transport encryption does and does not do. It protects the journey. It says nothing about the place the answer is filed afterwards, or about who can read it there.

Stop 2: what the provider’s documentation says

At the end of that address sits a service, and most services document publicly where they store. Two examples, both taken from the provider’s own documentation.

Microsoft Forms. Microsoft lists Forms among the “Additional Microsoft 365 Services” — those for which, unless the Product Terms state otherwise, there are no specific data residency commitments. The table then gives the intended storage location by the tenant’s default geography: for tenants in EU or EFTA countries that is “Macro Region Geography 4 — European Union/EFTA”, and for all other locations the United States. Switzerland is an EFTA country. Separately there is the Advanced Data Residency add-on, which makes commitments for local country regions; Microsoft lists Switzerland among those local regions and lists the included services one by one — Exchange Online is among them, Forms is not.

Google Forms. Google offers data regions for Google Workspace: covered data can be stored in a chosen geographic location, namely the United States or Europe. For Forms, Google names the covered data as “Text, embedded images, responses, and draft responses”. Two limits appear on the same page: depending on the subscription, coverage applies to data at rest rather than necessarily to processing, and data regions cannot be applied to data types not specifically stated there — logs and cached content, for instance.

Both examples show the same pattern, and it is a useful one: a statement about storage location applies to certain data, in a certain product edition, in a certain region. “Where is the data” therefore rarely has a one-word answer, but it almost always has a documented one.

Stop 3: who else is involved

Hardly any provider runs everything itself. Behind a form service there is usually a data centre, a sender for notifications, an error log, a support tool. Those service providers are sub-processors, and many providers publish them in a list.

Google Workspace shows how much such a list can hold. Per entry, Google names the entity, the services concerned, the activity — “Technical Support” or “Security Risk Detection”, for example — the countries in which the processing is performed, the registered address, the country of registration and the ultimate parent company. Earlier versions of the list are available on the same page, so changes can be traced.

Legally this chain is not a side issue: a processor may delegate processing to a third party only with the prior authorisation of the controller (Art. 9 para. 3 FADP). Where no public list exists, that is information too — and something that can be asked by email.

Stop 4: the second copy nobody counts

Most form services send a notification email when a new answer arrives, and in many configurations that email contains the full content of the answer. From that moment the answer exists in at least two places: in the form service’s storage and in the business’s mailbox.

The mailbox is a stop of its own, with its own answers. Exchange Online, for instance, falls under the commitments of Microsoft’s Advanced Data Residency offering, which does not include Forms — the same group, the same sign-in, two different answers to the same question. Then come the connections: the export into a spreadsheet, the handover to an accounting or newsletter tool, a webhook into a third system. Each of those is another copy in another place, and each is visible in the form’s settings, because somebody set it up there once.

For the driving school that means something very practical: a customer’s registration does not live “in the form”. It lives in the service, in the mailbox, in the downloaded spreadsheet on the office computer, and possibly in the appointment calendar.

What the contract adds

For the business, the technical chain is one half and the contract is the other. The FDPIC states the starting point plainly: even when the processing of personal data is delegated to a processor, the client remains responsible for data protection, and is obliged to select the processor carefully, instruct it appropriately and supervise it as far as necessary. Among the points the FDPIC lists are processing only on instruction, appropriate data security measures, and prior consent to bringing in further service providers.

Many providers keep this contract available as a standard document to download, often under “Data Processing Agreement”. It answers what the technical documentation leaves open: which instructions apply, how new sub-processors are announced, what happens after a security breach, and what becomes of the answers when the contract ends.

And from the point of view of the person who filled in the form

Anyone who collects personal data informs the data subject appropriately and provides at least the identity and contact details of the controller, the purpose of the processing, and where applicable the recipients or categories of recipients (Art. 19 paras. 1 and 2 FADP). Where data is disclosed abroad, the state also belongs in that information, together with the safeguard under Art. 16 para. 2 FADP or the exception under Art. 17 FADP (Art. 19 para. 4 FADP).

That is why the chain matters at all: what ends up in a privacy statement is exactly the list of stops that somebody once put together. With that list, the customer’s question on the phone can be answered in one sentence — and without it, the list can be assembled in an hour or two: page source, provider documentation, sub-processor list, contract, mailbox, connections.

The online forms app we are building approaches that chain from the other end: answers will be encrypted in the browser of the person filling them in, and operation and storage will be in Switzerland. That does not make the chain disappear — it makes it shorter, and short enough to describe in a sentence. Which is the most useful measure anyway: not whether an answer to the question exists, but whether it fits into one sentence.