What actually leaves the EU when you use a form backend
The Formward TeamFormward, Stockholm7 min read
Every European form backend, ours included, has at some point printed the sentence "your form data never leaves the EU". It is a good sentence. It is short, it answers the question a buyer is actually asking, and it fits on a comparison table. It is also, read literally, false for almost every such product — and we recently went through our own site and rewrote it everywhere it appeared. This post is the explanation of why, because the underlying distinction is one that anyone doing a transfer assessment needs to understand, and it is not specific to us.
Start with the mechanism that makes the claim fail, because it is not an obscure edge case. When you create a form, you give it an address to notify. That notification is on by default — a form backend whose whole purpose is to tell you when someone fills in your form would be strange if it were not. The notification contains the submission: the name, the email address, the message. Now suppose you typed a Gmail address, because a great many people do. The submission content has just been delivered to a mailbox operated by a US company. Nothing was switched on, no integration was enabled, no checkbox was ticked. The default configuration of the product sent personal data to a US provider.
That is the whole problem in one paragraph, and once you see it you cannot unsee it. The vendor's infrastructure genuinely is in the EU. The database is in Sweden or Frankfurt or Paris, the sub-processors are European, the AI runs in France. Every one of those claims can be true and auditable. And yet the data still left, because the last hop in the pipeline is a destination the customer chose, and the customer chose one outside the EU.
The useful way to think about this is to ask who the sentence is about. "Your form data never leaves the EU" has the customer's data as its subject, and makes a claim about everywhere that data will ever go — including places the vendor does not control and cannot see. "Formward stores and processes your form data in the EU" has the vendor as its subject, and makes a claim about the vendor's own processing. The second sentence is narrower. It is also true unconditionally, which is what you want from a sentence a data protection officer is going to rely on.
This distinction is not pedantry, because it maps onto a real allocation of responsibility under the GDPR. For your visitors' data, you are the controller and the form backend is the processor. The processor is responsible for its own processing: where it stores the data, which sub-processors it uses, how it secures the transfer. The controller is responsible for deciding what happens to the data — including instructing the processor to send a copy somewhere. When you configure a notification address, you are issuing that instruction. If the address is outside the EU, the resulting transfer is one you made, and the Chapter V assessment for it is yours, not the vendor's.
A vendor who tells you their product means no transfer assessment ever arises is, at best, describing only their half of the arrangement. At worst they are encouraging you to skip an assessment you actually owe. That is the part that pushed us to rewrite our own pages rather than leave a sentence that read well: a customer reading our compliance documentation, seeing a categorical assurance, and concluding they had nothing to assess would have been misled by us into a gap in their own records.
So here is the honest inventory for a typical form backend. Four things routinely carry submission content out of the EU, and only one of them looks like an integration. The notification email, which is on by default and goes wherever you pointed it. The autoresponder, if you use one, which replies to whatever address the person filling in the form typed — meaning the destination is chosen by a stranger, and can be anywhere on earth. A spreadsheet sync, if you enable one, which for Google Sheets means the United States. And outbound webhooks, which deliver to whatever URL you configured, and which no vendor can locate for you because an arbitrary hostname does not tell you where the server is.
Notice that three of those four are invisible in the vendor's own infrastructure diagram. The submission arrives in the EU, is stored in the EU, and is processed in the EU. Then it is handed to a destination the customer owns. Every claim about the EU portion remains true, and the data is in Virginia. This is why an infrastructure diagram is not a transfer assessment, and why "we are hosted in the EU" answers a narrower question than the one being asked.
There is a second, subtler problem we ran into, which is worth mentioning because it applies to any product that shows customers a compliance summary. We have a page that lists, per form, exactly where that form's submissions go. It is a good feature. But it was hardcoding the notification email as an EU destination — because our email infrastructure is in the EU — without looking at the recipient address at all. A customer with a Gmail notification address opened the page that exists to answer "do I owe a transfer assessment" and was told, in a green badge, that their data never leaves the EU. The feature designed to give an honest answer was giving a confidently wrong one.
The fix there was not better wording. It was admitting that the underlying value is not a boolean. A destination is not either in the EU or outside it; there is a third state, which is that we send from the EU and genuinely cannot tell where it lands, because you cannot determine a mailbox's hosting from its address. Forcing that third state into "no, it does not leave" is what produced the wrong badge. If you build compliance tooling, the lesson generalises: the case you cannot determine deserves its own representation, and defaulting it to the reassuring answer is the one choice guaranteed to mislead.
None of this makes EU hosting worthless — quite the opposite, and we would say that even if we were not selling it. If the vendor's own processing happens in the EU with EU sub-processors, then the part of the pipeline you do not control is clean, and the part you do control is entirely within your power to keep clean too. Point the notification at a mailbox your own organisation hosts in Europe, skip the US spreadsheet sync, send webhooks to your own EU infrastructure, and the data genuinely does stay in the EU end to end. The difference is that this is now something you have verified rather than something you were promised.
Which suggests a short checklist when you evaluate any form backend on residency. Ask where the vendor stores and processes submissions, and expect a country. Ask for the sub-processor list, and check the email provider specifically, since that is the one people forget. Then ask the question the marketing page will not answer for you: given how I intend to configure this, where does my data end up? Enumerate your own destinations — the notification mailbox, the autoresponder, any sync, any webhook — and check each one's jurisdiction yourself. A vendor who helps you do that, and who tells you plainly which parts are your responsibility, is being more useful than one who tells you there is nothing to check.
We would rather be the first kind, even at the cost of a less quotable sentence on the comparison table. Formward stores and processes your form data in the EU/EEA, on Swedish infrastructure with EU-only sub-processors for submission data. What leaves the EU is what you route out of it, and your data-flow page lists exactly which destinations each of your forms is using right now, including the ones we cannot vouch for. That is a longer answer than "never leaves the EU". It has the advantage of being true.