Website & Data Protection: Self-Check for Community Groups

How to use this

You and your group, not your web developer or host, is responsible for how you handle personal data. This checklist helps you work out what you actually do, so you can write an honest privacy notice and spot the risky habits.

Two committee members should fill it in together: the secretary or membership secretary, plus whoever runs the mailing list.
Answer from what really happens, not from what the constitution says.
Any “don’t know” is an action point.
The answers to Sections A, B, D, E and G are the raw material for your privacy notice. Section F is what your web developer needs from you.

This is a prompt for thinking, not legal advice, we’re not lawyers.

For anything unusual, use the ICO’s SME hub or take advice.

A. Who you are and who is responsible

What legal form is the group: unincorporated association, SCIO, company limited by guarantee, community council, or something else?
Is it a registered charity (OSCR in Scotland)? This affects your email marketing options in Section E.
Who on the committee is responsible for data protection? Name one person. “Everyone” means no one.
Do you share data with, or act on behalf of, another body (a funder, a council, a partner project, a parent organisation)? If so, who decides how that data is used?
Do volunteers or paid staff handle personal data? Have they been told what they can and can’t do with it?

B. What personal data you hold, about whom, and why

Fill in one row for each group of people. Add rows as needed. Most groups have more than they think.

Who	What you hold	Why you hold it	Where it came from
Members
Newsletter subscribers who aren’t members
Volunteers
Event attendees or booking contacts
Survey or consultation respondents
Petition signatories
People given advice or a service (energy, housing, benefits, etc.)
Donors
Contacts at other organisations
Photos or video of identifiable people

Then check:

Do you hold anything sensitive: health, disability, ethnicity, religion, political views, or details about children? These need extra care and a stronger justification.
Could you do the job with less? For example, a postcode instead of a full address, or no date of birth at all.
Do you ever use data collected for one purpose for something else? For example, adding survey respondents to the newsletter list.

C. The ICO fee exemption: does it really apply to you?

The not-for-profit exemption only excuses you from paying the ICO fee. It does not excuse you from data protection law. You still need a privacy notice, security, and a lawful reason for everything in Section B.

In broad terms, the exemption covers a not-for-profit body that only processes data to run its membership and support, to run activities for members or people in regular contact with it, plus its own staff admin, accounts and publicity. One activity outside that is enough to lose the exemption.

Look back at your table in Section B. Answer yes or no to each of these:

☐ We collect petition signatures from the public.
☐ We run surveys or consultations open to non-members.
☐ We provide advice or a service to households that aren’t members (energy advice, home surveys, signposting, case work).
☐ We share personal data with a funder, council or partner for monitoring or referrals.
☐ We use CCTV, or record meetings that include volunteers, members of the public.
☐ We hold data on behalf of a project run jointly with another body.

Any yes means you probably need to pay the fee. Check with the ICO’s fee self-assessment. It takes about five minutes. The fee for a small organisation is modest; being caught without it is not.

D. Where the data actually lives

The biggest risks are rarely on the website. They are in personal accounts, old laptops, and people who have left the committee but still have access.

Where	Do we use it?	Whose account is it?	Who has access now?
Spreadsheet on someone’s own computer
Personal Dropbox, Google Drive or OneDrive
Personal email account (Gmail, Hotmail, BT)
WhatsApp or Facebook groups
Mailchimp or another mailing service
Website forms and their stored entries
Paper forms or sign-up sheets
Online booking or payment tools

Then check:

Is everything in an account the group owns, not one that belongs to an individual? If the treasurer left tomorrow, would you still have the data, and would they still have a copy?
When someone leaves the committee, does anyone remove their access and get back any copies?
Do group emails go out with everyone’s address visible in the To or CC line? Use BCC or the mailing service.
Are files containing personal data shared by link? If so, could anyone with the link open them?
Are passwords shared? Is two-factor sign-in turned on for the main accounts?
Do you know which of these services store data outside the UK? Mailchimp, Dropbox and Google all do, at least in part. Your privacy notice should say so.

E. Emails and newsletters

There are two kinds of email, and the rules differ.

Admin messages to members (AGM notices, subscription reminders, meeting papers) are part of running the membership. You don’t need separate consent for them.
Promotional messages (newsletters, event promotion, campaigns, appeals, fundraising) count as direct marketing under PECR. This applies even when a voluntary group sends them. Each one needs a lawful basis.

The lawful basis for promotional messages is usually one of these:

Consent: the person actively ticked a box or signed up for this specific thing. Pre-ticked boxes and “by joining you agree to…” don’t count.
Charitable soft opt-in: registered charities only, since 5 February 2026. It applies only to contact details collected on or after that date, from someone who supported or expressed interest in the charity. The message must be about your charitable purposes, and the person must be offered an opt-out when you collect their details and in every message. See the ICO guidance. Groups that aren’t charities can’t use it.

Check:

☐ For each person on the list, we can show how and when they signed up. Mailchimp records this for its own forms; it doesn’t for names you imported.
☐ We have never added people to the newsletter list from a petition, survey, event booking or advice enquiry without asking them.
☐ Every message has a working unsubscribe link, and unsubscribes are respected everywhere, including any spreadsheet copies.
☐ Sign-up forms say plainly what people are signing up to and how often they’ll hear from you.

Members of a charity, community benefit society etc

Joining as a member gives you a contract. That covers what is needed to run the membership, but not promotional emails.

Message	Contract covers it?	What you need
AGM/EGM notices, voting papers, rule changes, share or interest statements	Yes	Nothing extra. The rules must allow notices by email.
Factual reports to members on how the society and its finances are doing	Probably	Keep the tone factual, not promotional.
Events, shop or café offers, new share offers, appeals, volunteer calls, campaigns	No: this is marketing	Consent, or the charitable soft opt-in if the society is a registered charity

Check:

☐ The membership form has a separate, unticked box for newsletters and other news.
☐ Our records keep “member” and “agreed to marketing” as separate fields.
☐ A member who unsubscribes from the newsletter still gets statutory notices. Mailchimp unsubscribes someone from the whole audience, so use a separate audience or another channel for formal notices.
☐ A mixed newsletter is treated as marketing, because the promotional parts decide it.

F. The website: embeds, links, forms and cookies

When you embed something from another service, such as a map, a video, a Facebook or Instagram feed, or a booking widget, every visitor’s browser contacts that service as soon as the page loads. That sends it their IP address, and often lets it set cookies or track them. That happens on your site, so it’s your responsibility, not the provider’s. The cookie banner tool can block some of this, but only for the services it recognises.

The default rule: link, don’t embed. A plain link sends nothing until the visitor chooses to click. If you want something visual, put up a screenshot saved on your own site and link it to the live map or page.

Before configuring your opt out policies, answer these questions:

List anything you have embedded or want to embed: maps, videos, social media feeds, calendars, donation or booking widgets, newsletter sign-up boxes. For each one, would a link do?
What forms are on the site (contact, membership, newsletter, booking)? Who receives the entries, and are they also stored on the website?
Do you collect visitor statistics? If so, which tool, and does anyone actually look at them?
Do you take payments or donations online? Which service handles them?
Have you added any plugins yourself that have a hidden payload, or has anyone else?

And for yourselves:

We won’t add an embed unless we know what data it sends, and we’ll ask the web developer first.
We’ve removed any old social media feeds, unless there’s a clear reason to keep them.

G. Keeping, deleting, people’s rights and when things go wrong

How long do you keep each kind of data from Section B? For example: lapsed members for one year, petition data until the petition closes, advice records for X years. Write down a period for each.
Who actually deletes old data, and when? An annual reminder at the AGM works.
If someone asks “what do you hold about me?” or “delete me”, who deals with it? You have one month to respond.
If data gets lost, sent to the wrong people, or accessed by someone who shouldn’t have it (for example a laptop stolen, an email to the whole list with every address visible, or a shared folder left open), who decides what to do? Serious breaches must be reported to the ICO within 72 hours.
Is there a written note somewhere of the answers to 1 to 4? A single page in the committee files is enough.

What to do with your answers

Fix the quick wins first: move data into accounts the group owns, remove access for people who have left, switch to BCC, and turn on two-factor sign-in.
Decide on the ICO fee using Section C and the self-assessment.
Write your privacy notice from Sections A, B, D, E and G. The ICO’s privacy notice generator will walk you through it. It should describe what you actually do, in plain language.
Give Section F to your web developer. They can check that the cookie banner and embeds work as you want and suggest adding other website details to your notice, if you’ve missed anything.
Review once a year, and whenever you start something new such as a petition, survey, advice service or new partner project.