How to store customer data from website forms safely
A single form submission often ends up in four or five places: the form tool, an email inbox, a chat channel, a spreadsheet and a CRM. Each copy has its own readers, its own security and its own lifetime. Storing it safely means knowing every copy, cutting the ones you don't need, protecting the logins to the rest, and deleting on a schedule.
Map where one submission goes
Send yourself a test submission and follow it. Write down every place it appears and who can open that place. A typical small business ends up with something like this:
| Copy | Who can read it | Main risk |
|---|---|---|
| Form tool's inbox or dashboard | Everyone with an account login | Shared passwords, no two-factor sign-in |
| Notification email | Anyone with access to that mailbox, on every device it syncs to | Lost phones, forwarded threads, mailbox breaches |
| Chat channel | Every member of the channel, now and later | Channels that grow, long retention |
| Spreadsheet | Everyone it's shared with, and anyone with the link if link sharing is on | Over-broad sharing, downloads to laptops |
| CRM or email platform | Every user of the tool | Many users, data kept indefinitely |
Cut the copies
Every copy you remove is one less thing to secure and delete. Ask of each: does someone act on the data here, or is it a habit? A team that triages enquiries in chat may not need full details in email as well. A spreadsheet started "for now" is often a duplicate of the form tool's own list. Where a copy is only an alert, send less: a notification that says "New enquiry from the website" with a link is safer in a busy place than one with the full message.
Protect what remains
- Turn on two-factor sign-in for every account that can open submissions: the form tool, email, chat, spreadsheet and CRM.
- Give each person their own login, so you can remove one person without changing everyone's password and can see who did what.
- Limit access to those who act on it. The ICO's guide to data security describes access control as restricting who can view, change or delete personal data to people you've authorised, alongside encryption and regular review.
- Prefer tools that encrypt data at rest and transmit it over HTTPS. Check the form posts to an
https://address. - Keep secrets out of pages. API keys and webhook URLs that let tools write data belong in the tool's settings, never in the website's code.
- Remove access promptly when someone leaves or a contractor finishes.
Decide how long to keep it
The ICO's storage limitation guidance says you set and justify your own periods, and that keeping data just in case isn't acceptable. A workable starting point: enquiries that didn't become work, a few months; customer records, as long as tax and dispute rules need; newsletter sign-ups, until they unsubscribe. Write the periods into your privacy policy, then delete from every copy on your map, not just the first one.
Mistakes that cause leaks
- A spreadsheet shared as "anyone with the link can view" and pasted into a group chat.
- One shared login to the form inbox, used by the whole team and two former staff.
- Form notifications auto-forwarded to a personal email account.
- Sensitive details, such as health information on a clinic's form, posted into a team chat.
- Exports downloaded to a laptop's Downloads folder and never deleted.
If something goes wrong
If submissions are exposed, act in this order: close the hole (revoke the link, reset the password, remove the user), work out what data and how many people were affected, and record what happened. Under the UK GDPR and the GDPR, a personal data breach that risks people's rights must be reported to the regulator within 72 hours of becoming aware of it, and people must be told directly if the risk to them is high. Write down your reasoning even if you decide not to report.
Check your setup
Once a quarter, open each place on your map and list who has access. Remove anyone who doesn't need it. Search for submissions older than your retention period and delete them. Then send a test submission and confirm it lands only where your map says it should.
Form data on Anticode
On Anticode, contact, booking and newsletter submissions are saved and sealed at rest with AES-256-GCM. An access log records the last 200 reads, exports and deletes of form data, so you can see who opened it. A site that collects data can't be published until the account owner and the person publishing have two-factor sign-in on. Connector credentials, such as a Slack webhook URL or a HubSpot token, are sealed and write-only, so they can't be read back out of the dashboard. In Team workspaces, members can't delete projects or take sites down. Each project's Keep submissions setting deletes stored submissions automatically once they pass the period you choose.
The rest of the map is yours. Each connector you turn on, and each notification email, puts a copy somewhere Anticode doesn't control, under that service's own access and retention. The GDPR checklist covers the wider duties, and form submissions to Slack covers keeping chat copies lean.
Questions people ask
Is it safe to receive submissions by email?
It's common and can be reasonable for low-risk enquiries, with two-factor sign-in on the mailbox. It's another copy, though, so keep a stored list as the record and delete old emails on the same schedule.
Do form submissions need to be encrypted?
They should travel over HTTPS, and encryption at rest is a sensible measure the ICO recommends. Encryption doesn't help if a shared password lets the wrong person sign in, so pair it with access control.
How long should I keep contact form data?
As long as you need it for the purpose, and no longer. Set a period, write it in your privacy policy, and delete on schedule.
Sources
- ICO: A guide to data security, checked
- ICO: Principle (e): Storage limitation, checked