GDPR for UK clubs and associations: a practical 2026 guide

Yes. The bit of folklore that the "domestic exemption" covers small clubs is wrong. The exemption is for things like your personal Christmas card list, not for an organised club with a committee, a membership list and a bank account.

If your club holds a membership list, you are a data controller under UK GDPR. That is true whether you have twelve members or twelve hundred, whether you are incorporated or unincorporated, and whether you pay anybody or not. It is true for sports clubs, social clubs, working men's clubs, Masonic lodges, Rotary clubs, associations, alumni groups and societies of every flavour.

The good news is that the law is proportionate. The ICO does not expect a village cricket club to behave like a bank. It expects you to handle member information sensibly, be honest about what you do with it, and respect a member's right to see, correct or remove their own data. That is genuinely it for most of the work.

Before you can write any sort of policy you have to know what you actually have. Most clubs hold five buckets of member data, and the rules below all reference back to these:

1. Identity: name, date of birth, sometimes a photo. Used to know who is a member, to apply age-restricted rules (18+, junior section, voting eligibility) and to address communications.
2. Contact: email, phone number, postal address. Used to actually get in touch with members about club business.
3. Membership status: when they joined, what category they are in, whether their subs are paid, whether they hold a committee role. The administrative spine of the club.
4. Payment: records of subs, event payments, kit orders. Usually you hold the record of a payment, not the card number itself, because that lives with Stripe or your bank.
5. Engagement: attendance, RSVPs, who opened a notice, who replied to a poll. This is often the least thought-about bucket but it is genuinely personal data and needs to be handled with the same care.

Some clubs also hold sensitive categories like health information (allergies for catered events, accessibility needs, fitness disclosures for sports), photos that could identify members, and historical records that go back decades. These get extra attention later in the guide.

You need a lawful basis for every category of processing you do. For a small club, three bases cover almost everything: contract, legitimate interests, and consent. Most committees get this wrong by leaning too hard on consent, which actually creates more work and more risk.

Contract (or membership relationship)

This covers anything you need to do to actually deliver the membership a member has signed up for. Taking subs, telling them when the AGM is, letting them know the club is closed on Bank Holiday Monday, sending them the fixture list. You do not need their consent to do this. They joined the club. This is the deal.

Legitimate interests

This covers things that are reasonable for the club to do and that a member would expect, even if they did not specifically agree to it. Examples include sending a renewal reminder, posting a roll of honour, or letting other committee members see who attended last month. You do a quick balancing test (is this a reasonable thing for a club to do, and would a member be surprised by it) and you write it down.

Consent

Consent is needed for genuine marketing, third-party promotions, and anything outside the normal operation of the club. Consent must be specific, freely given, and as easy to withdraw as it was to give. It must never be bundled into the terms and conditions of joining. A pre-ticked box is not consent. A blanket "I agree to receive communications from the club" is not consent because it is not specific.

This is the distinction that catches most committees out. Get it right and most of your communication life becomes simpler.

A practical pattern that works: use one channel for operational communications and another for genuinely optional things like sponsor offers. Members can opt out of the second without losing access to the first. Critical notices in Comnly are structured exactly this way, so the operational channel cannot accidentally turn into a marketing channel.

Every club needs a privacy notice. It does not need to be twelve pages of legalese. It needs to be honest and complete. A member should be able to read it and understand exactly what you do with their data and why.

The checklist:

• Who you are and how to contact you, including a real email for data queries.
• What personal data you collect, broken down into the five categories above.
• What you do with it, and the lawful basis for each use.
• Who you share it with (your accountant? Your governing body? Your payment processor?) and why.
• How long you keep it. Do not say "as long as necessary." Be specific.
• What rights the member has (access, correction, deletion, portability) and how to exercise them.
• How to complain to you, and how to complain to the ICO if you ignore them.

Publish it somewhere members can actually find it. Linked from the join form, linked from the member area of your website, and ideally referenced in your welcome email. If it is buried three clicks deep, it does not really exist.

Retention is one of the most common gaps. Most clubs hold data forever because nobody ever told them to throw anything away. UK GDPR expects you to set a period for each category and stick to it. The numbers below are typical ranges for small clubs. Your committee can sense-check them against your insurance, governing body rules, and HMRC requirements if you take payments.

Write your numbers down in the privacy notice. Stick a calendar reminder on the secretary's account to do an annual retention sweep. That is the whole job.

Members have rights over their data. They can ask to see it, correct it, have it deleted, or take a copy with them. You have to respond within one calendar month, free of charge unless the request is genuinely excessive. In practice these requests are rare in small clubs, but when they come you cannot ignore them.

Subject access requests

A member writes in and asks "what data do you hold about me?" You owe them a copy of their personal data plus an explanation of why you hold it. Keep it proportionate. They do not need every committee email that mentioned their name in passing. They do need their membership record, contact details, payment history and anything about them that is not freely available to other members.

Correction

If a member says their address is wrong, fix it. If they say their attendance record is wrong, investigate before changing it. Correction is not the same as rewriting history.

Deletion (right to be forgotten)

This one is not absolute. If you have a legitimate need to keep records (HMRC, insurance, an ongoing dispute) you can refuse. Be honest about why. A member who leaves the club has a reasonable expectation that their day-to-day contact data comes out of the active system, even if the historical membership record stays for the six-year retention period above.

Portability

Rarely relevant for clubs. If a member asks for a machine-readable copy of the data they gave you, provide it. CSV is fine.

Some data is treated as higher risk and needs a stronger basis to process. Health, ethnicity, political views, religion and union membership all fall in this bucket. For clubs the realistic ones are health (catering allergies, accessibility needs, sport medical disclosures) and anything involving juniors.

Health

Collect only what you actually need, store it only as long as you need it, and restrict who can see it to the people who genuinely use it (the catering team for allergies, the coach for medical disclosures). Do not let it sit in a shared committee inbox forever.

Photos

A clearly identifiable photo of a member is personal data. A general crowd shot at an event is a grey area. The safest pattern is to tell members at the point of taking the photo what it might be used for (Facebook, website, member area only, never external) and give them an easy way to ask for a particular photo to come down. Heritage and trophy-board photos are usually fine because there is an obvious legitimate interest, but the same opt-out should apply.

Juniors

Comnly does not let juniors hold their own account. Junior members exist as sub-records of an adult parent member. That is a deliberate data minimisation choice. If your club does run a junior section through other means, the principle is the same: collect the minimum, store it for the minimum time, and protect it properly. A junior's data should not be drifting around in a WhatsApp group of twenty committee members.

A data breach is not just a hack. It is any incident where personal data is accessed, lost or disclosed by mistake. A treasurer's laptop left on a train counts. An email sent with the membership list in the To field instead of BCC counts. A shared folder accidentally made public counts.

If a breach is likely to result in risk to members, you have 72 hours to report it to the ICO. The clock starts when you become aware, not when the incident happened. If the risk is high, you also have to tell affected members.

The 72 hours sounds dramatic. In practice the work is:

1. Contain the breach. Recall the email, lock the file, change the password.
2. Work out what data was involved and how many members are affected.
3. Decide whether there is a real risk to members or whether it is a near miss.
4. Document the incident either way, even if you decide not to report.
5. If you report, the ICO has a simple online form. Be honest about what happened.

The single best thing a committee can do to make breaches less likely is to stop using shared inboxes and casual file sharing for member data. A structured tool with proper access controls means a single committee handover does not become a mass disclosure event.

Most small clubs that take electronic payments use a processor like Stripe. This is genuinely good news for GDPR. You do not see, store or process the card number. Stripe does. Your record is a transaction reference, the amount, and which member paid. That is much less sensitive than a card number sitting in a treasurer's spreadsheet.

On the Comnly side, club payment linksrun on the club's own connected Stripe account, so money goes direct to the club and no commission is taken by Comnly. The data on the Comnly side is the membership record of who paid and what for, which is also the record your treasurer needs anyway for the accounts.

If your club still takes payments by cheque or cash, that is fine. The GDPR exposure on that flow is lower because there is even less personal data involved. Keep the receipts in a locked cupboard rather than a stack on the bar and you are in reasonable shape.

Print this out, take it to your next committee meeting, work through it. Most clubs can clear the lot in two sittings.

1. Name a single person responsible for data protection. Usually the secretary.
2. Write down what data you hold, against the five categories in this guide.
3. Pick a lawful basis for each kind of processing. Write it down.
4. Separate operational comms from marketing comms. Use different channels.
5. Publish a member privacy notice. Link it from the join page.
6. Decide retention periods for each category. Set a calendar reminder for the annual sweep.
7. Stop using shared inboxes and casual spreadsheets for member data.
8. Make sure committee handovers transfer access properly, not by emailing a CSV.
9. Have a simple plan for what to do if a breach happens. Even a one-pager helps.
10. Run a dry-run subject access request on yourself once a year.

If you have read this far you have the framework you need. None of it is software. All of it is governance, organisation and habit. A club with the best member management software in the world but no policy on retention will still get this wrong, and a club with a tatty spreadsheet but a thoughtful committee will be in decent shape.

That said, the operational side gets a lot easier when the tools are built for it. Comnly bakes the GDPR-friendly defaults in. Every official notice has an audit trail of who saw it. Members hold their own communication preferences against their membership record. Subject access exports come out with one click rather than three hours of grep. Junior records are restricted to the parent member by design. Sponsored content is separated from operational comms so consent does not get tangled.

None of that replaces the governance work above. It just removes the "we cannot find anything" problem that turns a routine member request into a committee crisis.