GDPR for community organizers: a practical guide

If you run a Discord, Slack, Telegram, or WhatsApp community and you ask people for an email, a name, or “why do you want to join?”, you are in the personal-data business. GDPR for community organizers is mostly about your join form, attendee list, and spreadsheet — not about pretending you can rewrite Discord’s privacy policy.

The work is boring and finite: know what you collect, name a lawful basis, tell people, keep it only while you need it, and answer when they ask. Below is a sequence you can actually run.

What you’ll learn

• When GDPR applies to a community that “isn’t a company”
• Controller vs platform: who owns which data
• Lawful basis without a 40-page policy
• What to put next to a join form
• Retention, access, deletion, kids, and vendors
• A one-page checklist

Does this even apply to me?

GDPR applies to processing personal data of people in the EU and EEA. Personal data is anything that identifies someone: email, name, photo, Discord handle tied to an application, IP address, ticket receipt, “I work at Acme.”

Common myths that do not help:

• “We’re just volunteers.” Volunteer status is not an exemption.
• “We’re small.” There is no member-count threshold that turns the law off.
• “It’s a free community.” Free is not anonymous.
• “Everyone is in the US.” If EU people can apply, you still need a story for their data. Geo-blocking is a product choice, not a privacy policy.

If you have zero forms, zero lists, and the only data is inside the chat app under its own terms, your leftover duty is mostly: do not export member lists into random Google Sheets. The moment you add a join page, a waitlist, or event RSVPs, you are collecting.

You are probably a controller — for some of the data

This is the distinction that saves organizers from panic and from laziness.

The chat platform (Discord, Slack, Telegram, WhatsApp, and so on) processes account data and messages under its own terms and privacy notice. You do not become Discord’s DPO because you clicked Create Server.

You are the controller of data you decide to collect for your own purposes:

• Join applications and screening answers
• Email verification records
• Approval / rejection notes
• Event RSVPs and ticket buyer fields
• Spreadsheets you exported
• Newsletter lists you maintain

Those two piles must not be collapsed. Your privacy notice should say, in plain language: we collect X on this form for Y. For chat messages, see the platform’s policy. Link it. Do not paste Discord’s policy and pretend it covers your Typeform.

Pick a lawful basis that matches the job

Article 6 lists bases. Communities mostly touch three. Use the ICO’s guidance to sanity-check; do not mix them into one mega-checkbox.

What you are doing	Basis that usually fits	What that means in practice
Deciding who may enter a private community	Legitimate interests, sometimes contract	You have a real interest in screening; document it; offer a way to object
Selling a ticket or paid membership	Contract	You need the data to deliver the ticket
Sending a newsletter that is not required to be a member	Consent	Separate opt-in. Not pre-ticked. Not bundled with “I agree to the rules”

Consent is not “the GDPR one.” Consent is the strict one. If someone must tick a box to join, that tick is a bad place to hide marketing permission. Unbundle: rules and privacy notice as information; optional marketing as its own control.

Legitimate interests needs a short balancing note you can show later: what you want to do, why, what data, what you considered about the person’s rights, and the opt-out. A paragraph in a doc is enough for a small community. Skip it and you do not have a basis, you have a vibe.

Special category data (health, politics, religion, sexual orientation, and the rest of Article 9) is a different, harder regime. If your screening questions wander into those topics, stop and get advice. “Tell us your story” is how people volunteer data you never needed.

What to put on the join form

You do not need a novel. You need answers to four questions, next to the form, in language a tired person will read on a phone:

1. Who is collecting this (a named person or org, with an email)
2. What you collect (fields, not “data”)
3. Why, and the basis (screening the community / delivering a ticket / optional newsletter)
4. How long you keep it, and that they can ask for a copy or deletion

Link a longer notice if you have one. The longer notice should also say where you send data (your form vendor, email provider, Stripe if you sell tickets) and that the chat platform is separate.

Field hygiene is privacy hygiene. Every extra question is extra data you must justify, store, and delete. We already argued for short forms on conversion grounds in what to put on a community join page; GDPR points the same way.

Practical checkbox rules:

• Do not pre-tick
• Do not combine “I accept the rules” with “email me forever”
• If you use consent, record what they saw and when
• A checkbox without a notice is theater

Retention: the part everyone skips

Decide, write it down, then actually delete.

Record	A working default (adjust if you have a reason)
Approved member contact fields	While they are a member, plus a short wind-down if you must message about the closure
Rejected applications	30–90 days, then delete, unless a documented abuse case needs a review date
Event RSVPs	Until the event is done plus a short window for no-show follow-up, unless tax/accounting rules say otherwise
Ticket receipts	Whatever your accountant and Stripe’s records require — do not keep a second shadow copy “just in case”
Export CSVs on laptops	Delete after the task; they are the leak

Set a calendar reminder. Privacy policies that say “we keep data as long as necessary” without a number are how folders live forever.

If your tool has an export (CSV of members, for example), treat downloads as personal data in motion. Do not drop them in a public Drive. Pro plans that include CSV member export are convenient and also a responsibility.

Access and erasure without a drama desk

Article 15 (access) and Article 17 (erasure) scare people into silence. The community-sized version:

1. Publish an email that a human reads.
2. Verify you are talking to the same person (a confirmation loop to the email on file is usually enough).
3. Gather what you hold: form vendor, sheet, event tool. You have a month in most cases.
4. For chat-platform data, tell them which product to contact and that you cannot delete their Discord account for them.
5. For erasure, delete or irreversibly anonymize. Keep a minimal log that you fulfilled the request so the next email does not look like you ignored them.

You can refuse or narrow a request in limited cases (the ICO lists them). Do not invent “we never delete because community history.” You can keep aggregated, non-identifying stats.

Processors, US platforms, and “is this even legal”

If a vendor processes personal data for you (hosted join page, email, analytics, ticketing), you need a processor relationship: a DPA, a description of subprocessors, and a transfer story if data leaves the EEA/UK.

You will not get a perfect answer from a blog. You will get a vendor that publishes a DPA and a subprocessor list, or one that does not. Prefer the first. Discord, Slack, Google, and Meta are large, documented, and still your problem to choose. Read their current terms; they change.

Country allow/deny on a join form is not a GDPR substitute. It can reduce the chance you collect EU data if you truly do not want to. It is a blunt instrument and a product decision. Link it in your notice if you use it so people are not surprised.

Children

If your community is for under-16s (the GDPR default; member states can lower to 13), consent rules get stricter and you should not be improvising screening questions. Age-gate theater (“I am 18”) is weak. If kids are in scope, get qualified advice before you collect emails.

If your community is for adults, say so, and moderate it that way. “Everyone is welcome” plus no age line is how you accidentally process children’s data.

A one-page checklist

• Inventory: list every form, sheet, and vendor that holds member or applicant data
• Split: your data vs the chat platform’s data
• Basis: membership / screening vs contract vs marketing consent, written in a paragraph
• Notice: four questions answered next to the join form, plus an email
• Fields: delete any question you cannot defend
• Retention: numbers and a calendar reminder, especially rejected applications
• Rights: one inbox, a one-month habit, no promises about Discord message deletion
• Vendors: DPA or equivalent, or a conscious risk
• Kids: in or out, explicitly
• Review: once a year, or when you add ticketing or a new tool

How Inviter fits (optional)

Inviter can show a consent checkbox and a privacy notice on the join form, and it stores applications so you can approve people into Discord, Telegram, WhatsApp, or Slack. That is a control, not a certificate. You still write the notice, pick a basis, set a retention habit, and answer rights requests. Free to start; Pro is $19.99/month or $191.90/year. See pricing.

A Notion page plus a Google Form can implement the same checklist. The law does not require a particular logo. It requires that you know what you collected and why.

The honest ending

Most community GDPR failures are not exotic transfer theories. They are a join form with seven fields, a checkbox that says “I agree to everything,” a Sheet called members-final-FINAL, and nobody who knows what to do when someone emails “please delete me.”

Fix that pile. Link the regulation and the ICO guides from your notice so you are not the last word. Then go run the community — with a door that asks for less, and a folder that does not keep rejected applicants until the heat death of the account.