Legal
Privacy policy
What FormHam stores, why, how long for, and who else touches it. Written against what the software actually does rather than what a template says.
Last updated 5 September 2026.
Who we are
FormHam is a form backend: your website posts its contact forms to us, we store the submission, notify whoever needs to know, and tell you when a form quietly stops working.
FormHam is a trading name of a sole trader based in the United Kingdom—not a limited company. You can reach us at tgf@xpose.online.
Two different relationships. For the details of your own account we are the controller. For the enquiries your visitors send through your forms we are a processor, acting on your instructions—you are the controller of that data, and your own privacy notice is the one your visitors read. The terms governing that role are in our data processing agreement.
What we store when someone submits your form
We store the fields the visitor filled in, exactly as your form defined them. We do not choose those fields—you do—so what personal data ends up in a submission is a consequence of your form design. Alongside them we record:
- the IP address the submission came from, unmodified—we do not truncate or hash it;
- the page URL the form was submitted from (falling back to the
RefererorOriginheader); - timestamps, a receipt reference, and the form and account the submission belongs to;
- details of any file attached, where file uploads are enabled on your account.
We deliberately discard the CSRF token, the reCAPTCHA response token, the idempotency key and the locale hint before storing anything. We do not set cookies on your visitors, and the pages of this marketing site make no external requests at all—no web fonts, no CDN, no analytics.
Encryption at rest
The submission payload—every field the visitor typed, plus the IP and source URL—is encrypted in the database using the application's own key. It is decrypted only when it is shown to you, exported, or sent to a recipient you configured. Delivery logs and form activity logs are not encrypted; see below for what they contain.
Spam scoring and quarantine
If reCAPTCHA is enabled on a form, the visitor's browser talks to Google as part of solving it. On the classic (non-Enterprise) integration we also send the visitor's IP address to Google when we verify the token; on the Enterprise integration we send only the token, the site key and the expected action. A submission that fails scoring is held, not discarded—it is stored in full and kept out of every notification channel until someone reviews it.
Activity and delivery logs
Two log tables sit alongside submissions, and both hold personal data in plain text:
- Form activity logs record blocked, held and rejected attempts, including the raw IP address and the origin of the request. Audit entries—a record of who in your team looked at what—additionally hold the acting user's name, email and browser user agent.
- Delivery logs record, for each notification, the address or number it was sent to and the reason if it failed.
A nightly sweep deletes these on a schedule: activity logs and delivery logs after 365 days, and the stored payloads of billing webhooks after 180 days. Activity and delivery match the submission retention period, so a log entry about a submission cannot outlive the submission itself. Erasing a submission also redacts the recipient and failure message on its delivery logs immediately, and hard deletion removes them entirely.
Audit entries are the one deliberate exception: they are exempt from retention, because a record of who accessed what that can be pruned away is not a record at all.
How long we keep submissions
By default a submission is dealt with 365 days after it arrives, and the default treatment is anonymisation: any attached files are permanently deleted, and the payload is overwritten with a redaction marker. The row itself survives—so your submission counts and trends stay honest—carrying its identifiers, its timestamps, and a keyed hash of the submitter's email address so that a later erasure request can still find it.
You can set a shorter retention period on your account, and you can switch your account to hard deletion instead, in which case the submission row and everything attached to it are removed outright. The retention job runs once a day.
Other clocks:
- Held submissions that nobody opens are removed after 30 days. This is a retention rule and not a spam judgement: anything a human has opened is exempt permanently, and the removal is reversible.
- Test submissions, if you have enabled that option, are permanently deleted 24 hours after they arrive.
- Subject access exports are deleted from our storage 7 days after they are generated, along with any copied attachments.
- Edge-buffered submissions (see below) are deleted as soon as they are replayed to us, and in any case after 7 days.
Who else processes the data
The list below is exhaustive for the platform as shipped. Several entries only apply if you turn the feature on. The same list, with the contractual terms attached, is in the data processing agreement.
| Processor | What it is for | What it receives |
|---|---|---|
| Mailgun | Sending notification and system email | The submission content that appears in the notification, and the recipient address. We use Mailgun's EU endpoint by default. |
| Bunny.net | CDN, DNS, and an edge failover buffer | Static assets normally. If our origin is unreachable or returns an error, the edge script buffers the submission at Bunny so the enquiry is not lost, and we replay and delete it within minutes. |
| Google (reCAPTCHA) | Bot scoring, where you enable it | The reCAPTCHA token, plus—on the classic integration only—the visitor's IP address. Google also collects data in the visitor's browser through its own script. |
| Stripe | Card billing | Your billing email and account reference. No submission data. |
| GoCardless | Direct Debit billing | Your customer and bank-account references. Bank details are entered directly into GoCardless's own hosted flow and never reach us. No submission data. |
| Mailchimp (optional) | Mailing-list sync, if you configure it | Subscriber email address and name. |
| Slack, Formspark, and any webhook or CRM endpoint you configure (optional) | Forwarding submissions where you tell us to | The submission payload. These are destinations you choose; anything you send onward is between you and that provider. |
SMS and WhatsApp delivery are present in the product but switched off, and no submission data reaches any messaging provider today. Attached files are stored on our own private storage, not in any object store or CDN, and are served only through short-lived signed links.
Where it is processed
Mailgun is configured to the EU region by default. Attachments and the database sit on the application's own infrastructure. Several of the processors above are US-headquartered and will process data outside the UK under their own transfer arrangements. If the precise hosting location matters to your own compliance position, ask us and we will confirm it in writing rather than have you rely on a sentence on a web page.
Your account
For your own account we store your name, email address, a hashed password, which businesses you can reach, and—if you turn it on—two-factor authentication settings. API tokens are stored only as a hash; the token itself is shown once, at creation, and never again. Sessions record your IP address and browser user agent.
Your rights
Under UK GDPR you can ask for access to your data, correction, erasure, restriction, portability, and to object to processing. These are built into the product rather than handled by hand:
- Access. We can export everything held against an email address—every submission payload, every attachment, and every mailing-list entry—as a single file, including records that have been soft-deleted.
- Erasure. We can erase by email address across an account. Attachments are permanently deleted, the payload is overwritten, mailing-list entries are anonymised and unsubscribed, and the recipient and failure text on the delivery logs are redacted.
If a request reaches us about data in your account, we will pass it to you rather than act on it ourselves, because you are the controller of that data.
Email tgf@xpose.online to exercise any of these. If you are unhappy with how we have handled a request you can complain to the Information Commissioner's Office at ico.org.uk.
Changes
When this policy changes we update the date at the top of the page. If a change materially affects how we handle submissions on your behalf we will tell account holders directly.