GDPR

Under the GDPR you are the controller of the data your forms collect: you chose to put the form on your site, you decided what it asks for, and you decide who sees the answers. Formpost is your processor — we receive submissions, filter them, store them for the period your plan allows, and deliver them where you told us to.

That split matters because most of the obligations land on the controller. We can give you the tools and the paperwork; we cannot give you a lawful basis for collecting what you collect.

• A Data Processing Agreement that is in force for every account without anyone having to sign anything, incorporating the Standard Contractual Clauses.
• A published list of every sub-processor, what it handles and where it sits, updated before we add one.
• Encryption in transit and at rest, and a submission endpoint that can only ever deliver to the address its form was set up for.
• Self-service export and deletion, so most data subject requests need no ticket to us.
• Retention that ends on its own — thirty days on Free, a year on Pro, and under your control on Business.
• Breach notification without undue delay and within 72 hours of us becoming aware.

Submissions, attachments and account data are processed in the United States. For data coming from the EEA, the UK or Switzerland that is an international transfer, and we rely on the European Commission's Standard Contractual Clauses together with the UK Addendum, incorporated into the DPA.

We do not currently offer EU-only data residency. If your own assessment requires processing to stay inside the EEA, this is the point at which to tell us before you build on it rather than after.

Someone who filled in your form may ask you for a copy of their data, or to have it deleted. Almost all of it you can do yourself, immediately, without opening a ticket with us:

These are yours as controller, and no form backend can do them for you:

• Have a lawful basis for what the form collects. For an ordinary contact form that is usually the legitimate interest of replying to someone who chose to write to you — but the form deciding that is yours, not ours.
• Tell people on the page what you will do with what they send, and link your own privacy notice next to the form.
• Avoid asking for special category data — health, biometrics, political or religious views, sexual orientation — unless you genuinely need it and can lawfully hold it.
• Choose a retention period you can justify. A plan's maximum is not automatically the right answer for your form.
• Keep your own record of processing activities, and run a DPIA if what you collect calls for one. We will help with the parts that concern us.

Two settings reduce how much data you collect in the first place, which is the cheapest kind of compliance there is.

• Domain locking refuses submissions posted from anywhere other than the sites you list, so a copy of your form somewhere else stops feeding your database.
• Spam filtering rejects junk before it is stored, so you are not holding personal data from people who never intended to contact you.

There is no such thing as a GDPR certification for a service like this, and any vendor showing you a compliance badge is showing you a graphic. What exists is a set of obligations, a contract that allocates them, and evidence of what a processor actually does — which is what the DPA and the sub-processor list are for.

We also do not currently have a designated representative in the EU under Article 27. If that matters for your assessment, tell us and we will say where we have got to rather than guess.

The Data Processing Agreement at /dpa is the binding one — it names the sub-processors, the transfer mechanism, the security measures and the deletion terms. The Privacy Policy at /privacy covers what we do with your own account data, where we are the controller. If your review needs a counter-signed copy of the DPA, ask through the contact page.