Website Forms for Charities: Where the Data Goes and Who Is Responsible
Key takeaways
- Every form is a data collection point. Before it goes live, know where its submissions are stored, who receives them and how long they are kept.
- Your organisation decides why and how the data is used, so under UK GDPR the responsibility stays with you whichever platform stores it.
- If different people handle different enquiries, route them: separate forms, each with its own recipients, is the simplest way, and an automation tool can route one form by a field.
- Any form collecting personal data needs a lawful basis under Article 6 of the UK GDPR, plus an unchecked marketing opt-in where one applies, a privacy policy link near the submit button, and a documented retention approach.
- Every field needs a visible, persistent label. Never rely on placeholder text, which disappears on typing and is not reliably announced by screen readers.
- Test every form with the keyboard alone. If it cannot be completed without a mouse, it fails WCAG 2.2 AA.
Summary
What a charity or nonprofit needs to settle for every contact, volunteer and event form: where submissions go, who receives them, GDPR consent on a contact form, connecting a CRM, and how to check a form works for everyone.
A GDPR contact form on a charity or nonprofit website depends on four things being settled: where submissions go, who receives them, how long they are kept, and whether anyone is being added to a marketing list. The same goes for volunteer applications, event registrations, feedback and referral requests.
This guide covers those forms. Taking money is a separate job for a donation platform, covered in How to Add a Donation Form or Page to Your Charity or Nonprofit Website. How a form looks and converts is in form design for nonprofit websites.
Where Does Website Form Data Go?
Usually to more than one place, and each one is somewhere personal data now sits:
- The website platform, if it stores submissions in a dashboard
- Email, in the inbox of everyone on the notification list
- A connected app, such as a CRM or an automation tool
- A third party directly, if the form on the page belongs to another service
For each form, find out which of these apply, who can read them, and how long anything stays there. Do not assume a platform clears out old submissions for you. Webflow's documentation, for example, describes no automatic expiry: submissions are deleted by hand. So the retention period has to be yours: state it in your privacy policy, and make sure someone carries it out.
Who Is Responsible for the Data
Your organisation. The ICO's guidance is that a controller determines the purposes and means of processing and is responsible for complying with the UK GDPR, while a processor acts on its behalf. Choosing a platform to hold submissions does not hand that responsibility to the platform.
Who Receives Each Submission
Where different people handle different enquiries, you need routing: contact enquiries to the communications team, volunteer applications to the volunteer coordinator, event registrations to the events team.
Some platforms send every notification from a form to the same recipients. If yours does, you have two options: separate forms for each enquiry type (the simplest approach, since each form can notify different people), or an automation tool such as Zapier that routes submissions by a field (more complex, but it allows a single form with a 'type of enquiry' dropdown).
Volunteer Sign-Up Forms
A volunteer form tends to be the longest on the site, covering personal details, availability and interests. Use headings inside the form to create clear sections, which helps both sighted and screen reader users navigate it, and send it to the volunteer coordinator. If you also intend to send applicants marketing, the consent section below applies to this form too.
Consent and GDPR on a Contact Form
Every form that collects personal data needs a lawful basis under Article 6 of the UK GDPR, and the ICO is explicit that you must keep a record of it and include it in your privacy information. On the form itself, at minimum:
Consent checkbox for marketing. If the form sign-up will result in marketing emails (newsletters, appeals), include an unchecked checkbox that the user must actively opt into. The label should clearly state what they are consenting to: 'I agree to receive email updates from [Organisation Name]. You can unsubscribe at any time.'
Marketing email is governed by regulation 22 of PECR. Prior consent is the general rule, and since 5 February 2026 a charity may also rely on the soft opt-in in regulation 22(3A), inserted by section 114 of the Data (Use and Access) Act 2025. It is narrower than it sounds: the sole purpose of the marketing must be to further the charity's charitable purposes, the contact details must have been obtained in the course of the person expressing an interest in, or offering or providing support for, those purposes, and a simple free means of refusing must be offered both when the details are collected and in every message after. An address given for something else, such as a general enquiry or a resource download, is not covered. Nor does it displace the Code of Fundraising Practice, which requires a way to opt out and, where you do not have specific permission to contact someone, a check against lists such as the Fundraising Preference Service. An unchecked box records the consent explicitly, so it holds on either basis.
Privacy policy link. Include a link to your privacy policy near the submit button, with wording such as 'By submitting this form, you agree to our privacy policy.'
Data retention. State how long submissions are kept, in every place they sit, in your privacy policy.
For the full framework, see the GDPR Checklist for Charity and Nonprofit Websites.
Connecting Forms to a CRM
CRM integration has two usual routes. The CRM's own form can be embedded on the page, so submissions go straight in. Or a submission on the website's form can trigger an automation, through a tool such as Zapier, that creates a new contact in the CRM with the form fields mapped across. Either way, the CRM is now another place the data sits, so add it to your list.
Labels, Errors and Keyboard Testing
Every field needs a visible label, a name used in submissions and integrations, and the correct input type (email for email addresses, tel for phone numbers). Do not use placeholder text as a substitute for labels. Placeholders disappear when users start typing and are not reliably announced by screen readers: WCAG 2.2 requires labels or instructions for input under 3.3.2 Labels or Instructions, Level A.
Error messages should be descriptive and tied to the relevant field (3.3.1 Error Identification, Level A) and suggest a correction where one is known (3.3.3 Error Suggestion, Level AA). The success message should confirm the submission clearly and say what happens next. Focus should move logically through the fields, and the submit button should be clearly labelled.
Test every form by completing it using only the keyboard. If you cannot complete the form without a mouse, it fails WCAG 2.2 AA. The wider requirements are in WCAG 2.2 AA: What the Build Settles and What Your Team Must Keep Doing.
On Webflow? The platform-specific steps are in Platform Notes.
Next Step
If submissions need to reach a CRM, read CRM Integration for Nonprofit Websites: What Goes Where next.
Free download
Your website, for the board.
A two-page briefing you can fill in and put in the next board pack. It covers the six things funders check, how to see what AI tools say about you, and the options to put to trustees.
That did not send. Email hello@socialectric.com and we will send you the briefing. The spam check did not finish. Try again, or email hello@socialectric.com and we will send you the briefing.
Frequently asked questions
- Where does website form data go?
Usually to more than one place: stored by the website platform, emailed to whoever is on the notification list, and sometimes passed to a CRM or another app. Each is somewhere personal data now sits. Find out how long submissions have been sitting in each and document the retention position in your privacy policy, as part of the wider GDPR checklist.
- Who is responsible for data from a website form?
Your organisation. The ICO's guidance is that a controller determines the purposes and means of processing and is responsible for complying with the UK GDPR, while a processor acts on its behalf. A charity collecting enquiries for its own purposes is making those decisions, whichever company's platform holds the submissions.
- Can different enquiries go to different people?
Yes, though not always from one form, because some platforms send every submission from a form to the same recipients. The simplest option is a separate form for each enquiry type, so contact enquiries go to communications, volunteer applications to the volunteer coordinator and event registrations to the events team. The more complex option is an automation tool such as Zapier, which lets a single form carry a 'type of enquiry' dropdown that decides where the notification goes.
- Can a nonprofit's website forms feed our CRM?
Yes. Either the CRM's own form is embedded on the page, or a submission triggers an automation that creates a contact in the CRM with the form fields mapped across. The wider picture is in CRM Integration for Nonprofit Websites.
- What does GDPR require on a charity contact form?
Three things at minimum. If submitting the form will result in marketing emails such as newsletters or appeals, include an unchecked checkbox the user has to opt into actively, with a label that says plainly what they are agreeing to. Include a link to your privacy policy near the submit button. And know how long submissions are retained, then state that in the privacy policy. Marketing email is governed by regulation 22 of PECR, which since 5 February 2026 has also carried a soft opt-in for charities.
- Can we use placeholder text instead of labels to keep the form tidy?
No. Placeholders disappear as soon as someone starts typing and are not reliably announced by screen readers, so every field needs a visible, persistent label for accessibility and for plain usability.
- How do we check a form is accessible?
Complete it using only the keyboard: the keyboard test sets out how. If you cannot get through it without a mouse it fails WCAG 2.2 AA. Also check that every field has a visible label, that error messages are descriptive and tied to the field they refer to, that focus moves through the fields in a logical order, and that the submit button is clearly labelled.