What personal data can a community group collect?

Whatever you can justify, and no more. The data minimisation principle in UK GDPR Article 5(1)(c) says personal data must be adequate, relevant and limited to what is necessary for the purpose you are processing it for. That is a test you apply field by field rather than a fixed list. For most community events a name and an email address deliver the ticket and let you contact somebody if the date moves. Anything beyond that needs a purpose you can state out loud, a lawful basis under Article 6, a place it is stored securely, and a point at which it gets deleted. The practical question is not whether you are allowed to ask, it is whether you would still ask if you had to write down why next to the box.

Is a dietary requirement special category data?

Sometimes, and that is the awkward part. A preference for no mushrooms is not special category data. An answer of halal, kosher or no meat on Fridays reveals religious belief, and a coeliac or nut allergy answer reveals health data. Both religious belief and health are special category data under UK GDPR Article 9, which prohibits processing unless one of the Article 9(2) conditions applies, most commonly explicit consent for a community organisation. That condition is needed in addition to an Article 6 lawful basis, not instead of one. Many groups collect this without realising what they have taken on. If the caterer only needs to know about allergens and free-from requirements, ask a narrower question, keep the answer with the catering rather than in the general attendee list, and delete it after the event.

How long can we keep attendee data?

UK GDPR Article 5(1)(e) sets no fixed period. It requires that personal data is kept in a form permitting identification for no longer than is necessary, which means you choose the period and the accountability principle in Article 5(2) means you must be able to justify it. In practice most community organisations set financial records at around six years for HMRC purposes, attendee lists at the event date plus a refund and complaints window, and marketing contacts until the person opts out or goes cold. The number matters far less than whether anybody ever actions it. A written policy nobody runs is worse than a shorter policy that gets applied, because it documents a rule you are visibly breaking.

Do we need to ask for a full postcode?

Usually not. Funders ask for postcodes so they can show which areas an activity reached, and that analysis is almost always done at the level of a ward, district or deprivation measure rather than a household. The outward code, the first half such as LS6 or TR11, gets you geography without pointing at a doorstep. A full postcode in a small village can identify a single household, which turns a monitoring field into something much more identifying than you intended. Ask the funder what granularity they actually need before you collect. If they genuinely require full postcodes, collect them, say so on the form, and delete them once the report is filed.

What is special category data and why does it matter for events?

UK GDPR Article 9 covers personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data concerning sex life or sexual orientation. Processing it is prohibited unless a condition in Article 9(2) applies, and several of those conditions also require a condition from Schedule 1 of the Data Protection Act 2018. Community organisations collect it more often than they realise, because access requirements reveal health, dietary requirements can reveal religion, and equality monitoring collects ethnicity and disability directly. The trigger is what the answer reveals, not which box it sat in on your form.

Should equality monitoring questions be optional?

In practice yes, and a prefer-not-to-say option should be a real choice rather than a token one. Equality monitoring collects ethnicity, disability, religion and sexual orientation, all of which are special category data under UK GDPR Article 9, so you need an Article 9(2) condition as well as an Article 6 lawful basis. Two conditions are relevant. Where you rely on explicit consent under Article 9(2)(a), ICO guidance is clear that consent must be freely given, which is difficult to argue if somebody cannot get a ticket or join without answering. The alternative is Article 9(2)(g), substantial public interest, read with paragraph 8 of Schedule 1 to the Data Protection Act 2018, which covers processing necessary for identifying or keeping under review the existence or absence of equality of opportunity or treatment between groups. That condition does not depend on consent, but it carries its own safeguards, including an appropriate policy document and a right for the individual to give written notice requiring you to stop. Making the questions mandatory also degrades the data, because people who feel cornered give inaccurate answers. Use the funder wording rather than inventing your own, say plainly what the answers are used for, and report the prefer-not-to-say count alongside the rest.

What do we do if someone asks for a copy of their data?

That is a subject access request under UK GDPR Article 15, and it can arrive by any route, including a message to a committee member. You must respond within the applicable time period, which is one calendar month under Article 12A of the UK GDPR as inserted by the Data (Use and Access) Act 2025, extendable by up to two further months where the request is complex or where there are many requests. Article 12A also brought in the stop-the-clock rule. The month runs from the latest of the request arriving, any information you reasonably need to confirm the requester's identity arriving, and any applicable fee being paid, and the clock pauses again while you are reasonably awaiting clarification of what a request covers, with a large quantity of information given as the example of when asking is reasonable. That is useful, but it only helps if you ask promptly and in writing. There is no special form and no fee in ordinary cases. The difficulty for most community groups is not the deadline, it is that the data lives in a ticketing system, a shared inbox, two personal laptops, a WhatsApp group and a box of paper forms, and nobody has a list of those places. Write that list down before you get a request rather than during one.

Which lawful basis covers collecting attendee data?

It depends on the field, and you should be able to say which basis covers which purpose. UK GDPR Article 6 now provides seven lawful bases: consent, contract, legal obligation, vital interests, public task, legitimate interests, and recognised legitimate interests. The last of those, Article 6(1)(ea), was inserted by section 70(2)(b) of the Data (Use and Access) Act 2025 and came into force on 5 February 2026. It removes the balancing assessment, but only for a closed list of purposes in a new Annex 1 covering crime prevention and detection, safeguarding vulnerable individuals, emergencies, national security, and assisting public bodies with tasks sanctioned by law, so it will rarely apply to ordinary attendee data. The details you need to deliver a ticket usually sit under contract. Marketing by electronic mail has two possible routes rather than one. The first is consent under Article 6(1)(a) together with PECR regulation 22(2). The second is legitimate interests under Article 6(1)(f) together with the soft opt-in in PECR regulation 22(3), which applies where the contact details were obtained in the course of a sale or negotiations for a sale, the marketing is in respect of that organisation's own similar products and services only, and a simple means of refusing was given when the details were collected and in every message since. A ticket purchase is the kind of transaction regulation 22(3) is drafted around; a list built from an enquiry form, a sign-up sheet or a bought file is not. Funder monitoring is its own decision and needs its own reasoning.

Every field you add is a promise you have to keep.

Most community organisations have never sat down and looked at what they collect. The booking form grew a field at a time, the membership form was inherited from a previous secretary, the funder added three questions in 2019 and nobody removed them when the grant ended. What you end up with is a set of questions that nobody chose, held in places nobody has listed, for a period nobody has decided.

This guide walks through what a typical UK community organisation actually needs from the people it deals with, what it collects out of habit, and what it should stop collecting. It covers the fields one by one, the point at which an ordinary-looking question becomes special category data, what funders really need from monitoring questions, how long to keep things, and the uncomfortable question of where the data physically lives.

It is general information for UK organisers, not legal advice. Nothing here tells you what is lawful in your specific case. For the underlying legal framework, including lawful bases, privacy notices, marketing consent and breach reporting, see the companion guide on GDPR for UK event organisers. For decisions that affect your organisation, consult a solicitor or contact the Information Commissioner's Office directly.

Last updated 19 July 2026.

Reviewed on 19 July 2026 against the current text of the UK GDPR on legislation.gov.uk (including the seventh lawful basis added by the Data (Use and Access) Act 2025, in force from 5 February 2026), the Data Protection Act 2018 (including the Schedule 1 substantial public interest conditions), the Privacy and Electronic Communications Regulations 2003, and published ICO guidance, to the best of our knowledge at the time of writing. Guidance changes and funder requirements vary. For decisions about your specific organisation, talk to a solicitor or the ICO directly.

The short version.

Data minimisation is not a legal formality you comply with once. It is a running cost. Every field on your form is something you have to justify, store securely, keep accurate, produce on request, and eventually delete. A question that takes two seconds to add creates an obligation that lasts for years and outlives whoever added it.

Sort your fields into three buckets. There is data you genuinely need to deliver the thing: a name to check on the door, an email to send the ticket. There is data that is useful and defensible if you can state the reason: access requirements you can act on, a phone number for the person leading a coach trip. And there is data you collect out of habit with no reason anybody can articulate: date of birth on a form with no age restriction, postal address for an e-ticket, occupation on a membership form because the old form had it.

The third bucket is usually bigger than people expect, and emptying it is the cheapest improvement available to most organisations. It costs nothing, needs no policy, and reduces both your obligations and your exposure at the same time.

The principle itself is one line. Personal data must be adequate, relevant and limited to what is necessary in relation to the purposes for which it is processed. What that means day to day is that the burden runs the other way from how most forms get built. The default is not to ask; asking is the thing that needs a reason. This matters because the cost of a field is invisible at the moment you add it and obvious three years later. A field you collect is a field somebody has to store safely, keep accurate under Article 5(1)(d), include in a response to a subject access request, hand over intact at a committee handover, and delete when the retention period expires. Multiply that by the dozen or more fields on a typical inherited membership form and you have created a genuine administrative liability in exchange for information nobody has ever used. There is also a quieter benefit. Data you never collected cannot be lost, cannot be emailed to the wrong person, and cannot appear in a breach report. The most secure way to hold somebody's date of birth is not to have it.

The test is per field and per purpose, not per form. The same question can be justified for one event and not another
Write the reason next to the field. If you cannot finish the sentence, remove the field
Optional fields are still collected data. Making something optional reduces the pressure on the person, not your obligations
"We might need it later" is not a purpose. Collect it later, when you do
Review the form before each season rather than inheriting it. Questions outlive the reason they were added for
Fewer fields also means higher completion. Minimisation and conversion point the same way for once

Three buckets, and how to tell them apart.

Take your current booking or membership form and put every field into one of three groups. Do it honestly, with somebody who was not involved in writing the form.

Needed to deliver the thing. Without this field the transaction does not work. You cannot email a ticket without an email address. You cannot check somebody in against a list without a name. You cannot take a payment without whatever the payment provider needs. This bucket is nearly always smaller than the form suggests.

Useful, with a justification you can state. This is the honest middle. A phone number for the one person organising a coach. Access requirements you have the ability to act on. A dietary answer where there is genuinely a caterer who will see it. The test is whether somebody will actually do something with the answer, and whether you can name who that somebody is.

Collected out of habit. Nobody currently in the organisation can say why the field is there. The answers have never been used. It was on the old form, or a funder asked for it once, or it seemed sensible at the time. Every organisation has these and almost none of them are load-bearing.

Below is the set of fields that appears again and again on booking forms, membership applications and workshop sign-ups across amateur theatre, choirs, schools, churches, dance schools and village halls. Each one is worth a moment of thought rather than a default. The pattern that emerges is consistent: the top two fields do almost all the work, the middle group is defensible when there is a real operational reason, and the bottom group is where most organisations are carrying obligations they get nothing back from.

Name. Almost always needed, to match a person to a booking on the door. Consider whether you need a full legal name or just something to check against
Email address. Needed to deliver a ticket and to reach people if the event changes. This is the single most useful field you hold
Phone number. Rarely needed for a standard ticket. Genuinely useful for a coach trip, an outdoor event that might be cancelled on the day, or a group organiser. Ask per event, not by default
Postal address. Only if you are posting something. An e-ticket does not need a house number. Many forms ask because the form used to be a paper one
Date of birth. Only where age genuinely matters: a licensed bar, an age-restricted show, an under-18 activity, a concessionary rate you have to evidence. Otherwise an age band or nothing at all
Emergency contact. Justifiable for residential trips, youth activities, rehearsals with a duty of care, and physical activity. Not justifiable for a Saturday-night concert audience
Next of kin. Narrower again. Ask only where somebody is in your care for a sustained period, and be clear you are collecting a third party's data with their knowledge
Access requirements. Ask when you can act on the answer. Say what you will do with it. This is very often health data, covered in the next section
Dietary requirements. Only where there is catering and a named person who will see the list. Ask narrowly, about allergens and free-from needs, rather than inviting a free-text explanation
Health and medical information. Only for activities where it is genuinely operational, such as youth groups, residentials or physical rehearsal. Special category data, and it needs handling as such
Occupation. Almost never needed by a community organisation. It appears on inherited membership forms and is worth deleting on sight
How did you hear about us. Useful marketing insight, genuinely optional, and does not need to be tied to a name at all. Consider collecting it as an aggregate count instead
Marketing preferences. Needed if you want to email people about future events, and governed by PECR as well as UK GDPR. Keep it separate from everything else on the form

Two worked examples.

A choir selling tickets to a Saturday concert in a parish church. Needed: name, email. That is the whole list. There is no catering, no age restriction, nothing posted, and no duty of care beyond the evening. Defensible additions: an access question, because the church has three steps at the main door and somebody can open the side entrance if they know in advance. Everything else, and most such forms carry a phone number and a postal address, is in the habit bucket.

A youth theatre running a week-long summer workshop for eight to fourteen year olds. Needed: the child's name, a parent or guardian name, an email, a contactable phone number for the week, an emergency contact, and any medical or access information the staff need to keep the child safe. That is a much longer list, and every item on it earns its place because somebody would act on it during the week. The same organisation should not carry that form over to its evening performances for adults, which is exactly what tends to happen when one form gets reused.

The lesson from the pair is that the right amount of data is a property of the activity, not of the organisation. One form for everything is how the wrong data gets collected from the wrong people.

Article 9 of the UK GDPR prohibits the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, along with genetic data, biometric data used to identify a person, health data, and data concerning a person's sex life or sexual orientation. The prohibition lifts only where one of the conditions in Article 9(2) applies, and several of those conditions require an additional condition from Schedule 1 of the Data Protection Act 2018. Crucially this sits on top of Article 6 rather than replacing it: you need a lawful basis and an Article 9 condition. For most community organisations the Article 9(2) route that comes to mind first is explicit consent under Article 9(2)(a), which is a higher bar than ordinary consent and has to be specific about the data and the purpose. It is not the only route. Article 9(2)(g) covers processing necessary for reasons of substantial public interest, and in the UK that is given effect through the conditions in Part 2 of Schedule 1 to the Data Protection Act 2018. Paragraph 8 of that Schedule, equality of opportunity or treatment, is the one written for monitoring work, and other paragraphs in the same Part cover things such as safeguarding. Those conditions do not depend on consent, but they are not a shortcut either: under paragraph 5 of Part 2 they are met only where the controller has an appropriate policy document in place, with the required contents set out in Part 4. The reason this catches people is that Article 9 is drafted around what data reveals rather than what you called the question. A free-text access field that comes back with a diagnosis is health data. A dietary field that comes back with halal or kosher reveals religious belief. A question about which member of the union committee to contact reveals trade union membership. None of those fields were labelled as sensitive when they were added to the form. Design the question so the answer you get back stays as narrow as the operational need, and keep whatever you do collect separated from your general list rather than sitting in the same spreadsheet column as everybody's email address.

What Article 9 covers

Racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health, sex life and sexual orientation.

What you need

An Article 6 lawful basis and, separately, an Article 9(2) condition. Explicit consent under 9(2)(a) is one route. Substantial public interest under 9(2)(g) is another, and it requires a condition from Schedule 1 of the Data Protection Act 2018.

How it arrives

Rarely through a box marked sensitive. Usually through access needs revealing health, dietary answers revealing religion, or monitoring questions asked on a funder's behalf.

Narrowing the question is usually better than restricting the answer.

The instinct when a field turns out to be sensitive is to add warnings around it. The more effective move is usually to change what you are asking so the sensitive part never arrives.

Instead of a free-text box reading "please tell us about any medical conditions or disabilities", on a form for a ticketed concert, ask "is there anything we can do to make your visit easier? For example step-free access, a seat near an exit, or a space for a wheelchair." The second version gets you the thing you can act on and does not invite a diagnosis you have no use for.

Instead of "dietary requirements" as an open box, ask about the specific options your caterer can actually provide, with a short free-text field for allergens. You still need to treat allergen answers as health data, but you are no longer collecting an explanation of somebody's faith along with it.

Instead of holding sensitive answers in the main attendee export, keep them with the person who needs them, for the period they need them, and delete them when the event closes. The row in the spreadsheet that says nothing more than "access noted, see front of house list" is a better design than the row that says everything.

Grant funders ask for equality monitoring because they need to show who their money reached, and increasingly because their own reporting obligations require it. That is a legitimate need and it is not going away. What community organisations tend to get wrong is the implementation. Three rules cover most of it. First, use the funder's own wording rather than inventing your own. Their categories are usually derived from established classifications such as those used in the census, which means the answers aggregate properly with everybody else's and you are not asked to redo the exercise. Homemade categories produce data the funder cannot use and questions that read badly to the people answering them. Second, every monitoring question should be optional with a genuine prefer-not-to-say option, and refusing should have no effect on getting a ticket, a place or a membership. Ethnicity, disability, religion and sexual orientation are all special category data under Article 9, and there are two routes through Article 9(2) that behave quite differently. If you rely on explicit consent under Article 9(2)(a), ICO guidance on valid consent requires it to be freely given, which is hard to sustain if answering is a condition of taking part. If you rely instead on Article 9(2)(g), substantial public interest, the condition drafted for this is paragraph 8 of Schedule 1 to the Data Protection Act 2018: processing necessary for identifying or keeping under review the existence or absence of equality of opportunity or treatment between groups, with a view to promoting or maintaining that equality. That route does not rest on consent, which is why it is the one many funders and larger bodies work to, but the Act attaches conditions to it. The processing must not be carried out for measures or decisions about a particular individual, it must not be likely to cause substantial damage or distress, the individual can give written notice requiring you to stop, and you need an appropriate policy document in place under paragraph 5 of Part 2. Which route fits a given organisation is a decision to take deliberately and write down, not one to arrive at by default. Third, be specific on the form about who the answers go to and in what form. Almost always the answer is that they are aggregated into counts for a report and the funder never sees an individual response, which is reassuring and is worth saying. Keeping monitoring answers separate from your operational records makes that promise true rather than aspirational, and makes deleting them at the end of the grant a single action rather than a search.

Ask the funder for their standard wording and categories before you write anything yourself
Decide and record which Article 9(2) condition you are relying on, explicit consent or substantial public interest under paragraph 8 of Schedule 1, because the safeguards differ
Every monitoring question optional, with prefer not to say offered explicitly rather than left as a blank
Say on the form what happens to the answers: aggregated counts in a report, not individual records shared
Report the prefer-not-to-say count alongside the rest rather than quietly dropping it. It is real information
Keep monitoring responses separate from your attendee and membership records so they can be deleted independently
Set the deletion date when the grant reporting ends, not when the project does. Then actually action it
If two funders want incompatible categories, ask them, rather than merging the two lists into something neither can use

Postcodes: the field that is more identifying than it looks.

Postcodes appear on community forms almost entirely because funders ask for them. The funder's purpose is geographic: which wards, which districts, which areas of deprivation did this activity reach. That analysis happens at a level well above the individual household.

A full UK postcode typically covers around fifteen addresses, and in rural areas it can cover one. Combined with a surname, which you also hold, it points at a specific front door. The outward code, the part before the space such as LS6 or TR11, gives you the geography a funder is actually analysing while being far less identifying. For most reporting it is enough. Where it is not, for example where a funder is measuring deprivation at a fine grain, they will tell you so and you can collect the full code for that purpose and delete it afterwards.

The useful habit is to ask the funder what granularity they need before designing the field, rather than collecting the most detailed version available on the assumption that it is safer to have it. It is not safer to have it. It is a more sensitive record with a longer tail of obligations, gathered to answer a question that a less sensitive record would have answered.

Storage limitation under Article 5(1)(e) requires that personal data is kept in a form permitting identification of individuals for no longer than is necessary for the purposes it is processed for. The law deliberately does not give you a number, which means the number is yours and, under the accountability principle in Article 5(2), so is the justification. Here is the honest starting position for most community organisations: nothing has ever been deleted. There are attendee lists from 2017 in a folder, an export of every member who has ever joined, and a mailing list that has been added to and never pruned. That is extremely common and it is worth naming rather than pretending otherwise, because it changes what a good retention policy looks like. A policy you will actually follow has three properties. It is short enough to fit on one page. It has a small number of categories rather than a period for every field. And it names a moment when somebody does the deletion, tied to something that already happens, such as the AGM or the end-of-season wrap-up, rather than to a date nobody is watching. A one-page policy that gets run once a year beats a detailed schedule that has never been executed, because the second one is a written record of a rule you are visibly breaking.

Financial records

Commonly around six years for HMRC purposes. Confirm with your accountant or treasurer, and keep these separately from operational lists.

Attendee lists

Event date plus a refund and complaints window is usually enough. A few months for most community events. Then delete, including the exports.

Sensitive answers

Access, dietary and medical information should have the shortest life of anything you hold. Delete when the event or activity closes, not at the annual review.

What deleting actually means.

Pressing delete in your ticketing system removes one copy. For most community organisations it is not the only one, and often not even the main one.

The attendee list was exported to a spreadsheet for the door team. That spreadsheet was emailed to four people, so it now exists in four sent folders and four inboxes. One of those people put it on a personal laptop so they could work on it at home. Somebody printed it for the box office and the printout went into a folder in the cupboard. A summary got pasted into a WhatsApp message so the front of house team could see who needed step-free access. Deleting the system record touches none of that.

This is not an argument for despair, it is an argument for design. Reduce the number of copies rather than trying to chase them. Export at the last possible moment rather than a week in advance. Share a link to the live list rather than a file, where you can. Agree that sensitive information does not go into group chats, and give people somewhere else to put it. Have one named person shred the paper after the event as part of the pack-down, the same way somebody counts the float. And when you do a deletion run, do it across the list of places you keep data rather than in the one system you happen to be logged into.

Ask a community organisation where its personal data is and the answer is usually the name of a system. The real answer is a list of about eight places, most of which are not systems at all. The membership list is in a spreadsheet on the secretary's own laptop, which is also used by their family and has never had a password on the file. The enquiries inbox holds a decade of correspondence and is accessed by three people through one shared password. The committee WhatsApp group contains phone numbers, names, health details shared in passing, and photographs of children. The paper forms from the last two seasons are in a box at the back of the hall. The old treasurer still has a copy of everything because nobody asked for it back when they stood down. Under Article 5(1)(f), the integrity and confidentiality principle, you are responsible for the security of all of it, and under the accountability principle you have to be able to demonstrate that. But the practical reason for writing the list is more immediate than compliance. You cannot delete what you cannot find, you cannot answer a subject access request without it, and you cannot report a breach accurately if you do not know what was in the place that was breached. Naming these places on one side of paper is the single most useful hour a committee can spend on data protection, and it is worth more than another explanation of Article 6.

Write a one-page list of every place personal data lives, including personal devices and paper
Shared inboxes with a single shared password are a standing risk. Individual accounts with delegated access are better
Group chats are a data store you did not intend to create. Agree what may and may not be posted there
Personal laptops and personal email accounts are the usual failure point at a committee handover
Paper forms need a named owner, a locked place, and a date for destruction
Make retrieval of records an explicit item when any officer stands down, and confirm in writing that their copies are gone
Review the list annually. It grows quietly, particularly after a busy season

Subject access requests, briefly.

Anybody whose data you hold can ask you for a copy of it. That is the right of access under UK GDPR Article 15. You generally have one calendar month to respond, a deadline now set out in Article 12A of the UK GDPR as inserted by the Data (Use and Access) Act 2025, extendable by up to two further months where a request is complex or where there are many of them. In ordinary cases there is no fee.

Article 12A also introduced the stop-the-clock rule, which is the part most worth knowing. The month runs from the latest of the request arriving, any information you reasonably need in order to confirm the requester's identity arriving, and any applicable fee being paid. The clock also pauses while you are reasonably awaiting clarification of what the request actually covers, and the legislation gives holding a large quantity of information about the person as the example of when seeking that clarification is reasonable. The practical consequence is that asking a sensible identity or scope question early is not lost time, whereas sitting on a request for three weeks and then asking is. The full mechanics, including when you can refuse and how to handle group bookings, are covered in the GDPR guide.

The point worth making here is the one that connects back to the rest of this guide. A request does not ask for what is in your ticketing system, it asks for the personal data you hold. If your data is spread across an inbox, two laptops, a group chat and a box of forms, you cannot answer it properly, and you have a month to discover that. Every field you did not collect is a field you do not have to find, and every place you have written down is a place you will remember to search.

Requests also tend to arrive at the worst possible moment and through the least formal route: a message to a committee member, a comment after a rehearsal, a reply to a mailshot. Decide in advance who they get passed to, so the clock does not run for three weeks in somebody's personal inbox before anybody notices.

None of these come from carelessness. They come from forms being built under time pressure by whoever had the login, inherited by people who were not there when the decisions were made, in organisations where the committee turns over every couple of years. Checking your own setup against this list will catch most of them.

One form reused for every activity, so concert audiences are asked the questions designed for a children's residential
Fields inherited from a previous secretary that nobody can explain, most often occupation, full postal address and date of birth
A free-text medical or access box that invites far more sensitive information than you have any use for
Dietary requirements collected with no caterer involved, or collected once and then kept indefinitely on the membership record
Treating an Article 9 condition as optional because an Article 6 basis has been identified. You need both
Equality monitoring questions made mandatory, which undermines freely given consent where consent is the condition being relied on, and produces inaccurate answers either way
Inventing your own monitoring categories rather than using the funder's, producing data the funder cannot aggregate
Collecting full postcodes when the outward code would have answered the funder's question
A retention policy that exists as a document and has never once been executed
Deleting the record in the ticketing system and leaving the exported spreadsheet in four inboxes and on two laptops
Personal data held in a committee group chat, including health details and photographs, with no policy and no way to clear it
The former treasurer or secretary still holding a full copy of everything, because nobody asked at handover
No written list of where data lives, so a subject access request or a breach turns into an archaeology exercise
Where consent is the route you are actually relying on, bundling it into the booking, pre-ticking the box or making it a condition of purchase. None of those produce valid consent
Assuming all email marketing needs consent, without ever checking whether the PECR regulation 22(3) soft opt-in route fits the way the contacts were obtained

A practical audit you can do in one committee meeting.

1. Print your current booking form, membership form and any workshop or trip form. Put them side by side. Most organisations discover at this point that the same question is worded three different ways.

2. Go through every field and write the reason next to it in one sentence, naming the person who uses the answer. Delete any field where the sentence will not finish.

3. Mark any field whose answer could reveal health, religion, ethnicity, disability, political opinion, trade union membership or sexual orientation. Those need an Article 9 condition as well as a lawful basis, and they need separating from your general records.

4. For each monitoring question, confirm it came from the funder, is optional, offers prefer not to say, and has a stated purpose on the form.

5. Decide whether you need full postcodes or outward codes, having asked the funder rather than assumed.

6. Write one page listing every place personal data lives, including personal devices, personal email accounts, group chats and paper. Do not stop at the first four.

7. Set a retention period for three or four categories, not for every field, and tie the deletion run to something already in the calendar.

8. Agree who receives a subject access request or a deletion request, and tell the rest of the committee that name.

9. Do the first deletion run in the meeting if you can. The habit is worth more than the policy, and starting it while everybody is in the room is how it survives.

10. Put a repeat of this audit in the diary for twelve months, and make handover of records an explicit item whenever an officer changes.

When to take proper advice.

This guide describes published UK guidance and the principles in the legislation. It does not, and cannot, tell you what is lawful in your specific circumstances. The situations below are the ones where community organisations most often need somebody qualified rather than a guide.

You are collecting health, medical or disability information about children or vulnerable adults on a sustained basis, rather than a one-off access note for an evening event.

You are being asked by a funder, a local authority or a partner organisation to share individual-level personal data rather than aggregate counts, and you are not sure what you are allowed to hand over.

You have discovered historic data going back years with no idea what basis it was collected under, and you need to decide what you can still use and what should go.

You have received a subject access request, a deletion request or a complaint that you cannot straightforwardly answer, or you think you may have had a breach.

You are relying on legitimate interests for anything beyond the obvious and have not carried out a documented assessment.

For any of these, consult a solicitor or contact the Information Commissioner's Office, which publishes detailed guidance and runs a helpline aimed at small organisations.

If your organisation matches one of these patterns.

The principles are identical everywhere. What differs is which field causes the trouble.

If you are an amateur dramatic society with a membership list that has been carried forward since the 1990s, the problem is almost never this season's form. It is the historic record nobody has ever pruned. See notes for amateur theatre groups.

If you are a school, the sensitivity of pupil data and the volume of forms mean the same information tends to exist in several systems at once. See notes for schools.

If you are a dance school with under-13s making up most of your intake, medical and photo information sits alongside routine admin on the same form, which is exactly where separation matters most. See notes for dance schools.

If you are a choir or orchestra with a stable adult membership, the risk is quietly holding data about people who left years ago. See notes for choirs and orchestras.

If you are a church or parish, congregant records and pastoral notes tend to blur into one another, and pastoral information is often special category data. See notes for churches.

If you are a village hall hosting other people's events, be clear about which organisation is the controller for the data collected at any given booking. See notes for village halls.

If you are a producing or receiving theatre, the split between what you hold and what a visiting company holds needs settling in writing before tickets go on sale. See notes for theatres.

Where tooling makes a difference.

Most of this is judgement rather than software. Deciding to stop asking for a postal address does not require a system. What tooling changes is whether the decisions hold once other people are involved.

Two things are worth checking in whatever you use. The first is whether sensitive answers can be kept apart from your general records, so an access note does not end up in the same export as everybody's email address. The second is whether monitoring questions can be answered without the response being tied back to a name, and whether small result sets are protected, because a breakdown of three responses is not anonymous no matter what the form promised. Seaty's surveys and forms take that approach: responses can be identified, confidential or anonymous, and on a non-identified survey no breakdown is shown until at least five responses exist. Whatever route you take, that is the bar to hold a system to.

Related guides and policies

Plain-English explanations of the parts of running UK events that catch organisers out.

GDPR for UK event organisers Photo and media consent Audience feedback surveys Selling tickets for UK charity events How UK ticketing fees actually work Surveys, forms and consent sign-off Custom questions on the order form Anonymity and data protection in surveys Reading and exporting responses Privacy policy

Collect less, and the rest gets easier.

Every field you remove is one less thing to secure, produce on request, hand over at a committee change, and remember to delete. Whatever you run your events on, the audit is worth an hour and costs nothing.

Sources & further reading