Running a Discord Community Under the GDPR: Who Is Responsible for What

This is an engineering article about a legal topic, written by engineers rather than lawyers, and it is not legal advice. What it does is map the parts of the GDPR that change how you build a Discord community, so that the conversation with an actual lawyer starts from the right questions.

When it applies to you at all

The Regulation applies to processing of personal data in the context of an establishment in the EU, and to processing about people in the EU where goods or services are offered to them. A company running a community for its customers is squarely inside that. A purely personal, household-activity server is outside it — but that exemption is narrow and does not survive the moment the server serves a business purpose.

Note what counts as personal data here. A Discord user ID is an identifier. A message someone wrote is content attributable to a person. A join timestamp, an activity log, a ticket transcript — all of it.

Controller and processor, applied

The controller determines the purposes and means of processing; the processor acts on the controller’s instructions. The European Data Protection Board’s guidelines on these concepts are the practical reference, and the assignment is functional rather than contractual — you are a controller because of what you decide, not because of what a document calls you.

For your own community that means: Discord operates the platform and processes on its own account for its own purposes, with its own privacy policy toward its users. Where you use Discord features that process on your behalf, Discord offers a data processing agreement covering that relationship. But the moment you run a bot that stores anything, you are the controller for that store, unambiguously and alone.

Your bot is your processing

This is the sentence most server operators have never been told. A bot that logs message deletions, keeps ticket transcripts, records activity for a levelling system or remembers who attended an event is a database of personal data that you decided to create, for purposes you chose, on infrastructure you selected.

Everything the Regulation asks of a controller follows from that: a lawful basis for each purpose, a retention period, appropriate security, a record of what you process, and the ability to answer a request from the person the data is about.

Legal basis: the two that actually apply

For a support ticket system, processing is generally necessary to handle the request the member initiated — the pre-contractual and contractual basis. For moderation logging, the usual basis is legitimate interest: you have a genuine need to keep a community safe, and the processing is proportionate to it.

Legitimate interest is not a blank cheque. It requires that you actually balance your interest against the member’s, and that the processing is no broader than the interest justifies. Logging every message in every channel forever, on the theory that it might be useful in a dispute, will not survive that test.

Retention is where most setups fail

Storage limitation is a principle, not a nice-to-have: personal data may be kept only as long as necessary for the purpose. In practice that means every store your bot maintains needs a defined period and a job that actually deletes.

Concretely: ticket transcripts might be kept for a year, moderation records for as long as a sanction can be appealed or repeated, activity counters not at all beyond the current period. Whatever you choose, write it down and make the deletion run automatically. A retention policy that depends on someone remembering is not a retention policy.

Requests from members, in practice

A member can ask what you hold about them and ask you to delete it. If your bot stores by Discord user ID, both are straightforward to implement — a command or an internal script that exports and one that erases. If your storage was designed without that in mind, they are painful, which is the argument for designing with them in mind.

Two subtleties worth knowing. A request to Discord about their platform data is Discord’s to answer, not yours. And erasure is not absolute: where you have a documented, overriding reason to keep a record — an unresolved safety matter, for instance — the balance can fall the other way. That is a judgement to document, not to make silently.

Moderation logs versus erasure

These two pull against each other and the tension is real. A log exists so that decisions can be reviewed and repeat behaviour recognised; erasure exists so that people are not kept in a record indefinitely. The workable compromise is minimisation: log the decision, the reason and the identifier, not the entire conversation, and set a period after which the record goes.

A minimal setup that holds up

Store the least each feature needs. Give every store a written purpose and period. Keep transcripts out of channels where staff who have no reason to read them can. Run the deletion job and check that it ran. Name a person responsible. And publish, in the server, a short note saying what is logged and for how long — which costs an afternoon and pre-empts most of the questions.

None of this makes a community harder to run. Systems designed this way are smaller, because most of the data people store turns out never to be read. The compliance benefit is a side effect of the engineering benefit.

Third-party bots are somebody else’s processing

Installing a public bot introduces a party you did not build and cannot inspect. Depending on what it does and who decides its purposes, that operator may be your processor or a controller in their own right — and either way, data about your members now sits somewhere you do not control.

Before installing anything with elevated permissions, look for three things: a published privacy policy, a stated retention period and a way to request deletion. A bot that offers none of the three is not a tool you can responsibly run in a community with European members, however convenient it is.

Where the data actually sits

A self-hosted bot puts you in charge of the hosting decision, which is a benefit and an obligation. Choose the region deliberately, know whether backups leave it, and record the choice. Where processing involves a provider outside the EEA, the transfer needs a valid mechanism — which is exactly the sort of thing that is easy to arrange up front and awkward to discover afterwards.

The pragmatic version for a small community: host in the EU, keep backups in the EU, and write down which provider you use for what. That single paragraph answers most of the questions anybody will ever ask you.

Minors

Discord sets a minimum age for its own service, and higher thresholds apply in some countries. For a community operator the practical consequence is that a portion of your members may be minors, and processing their data — particularly for anything resembling profiling or marketing — carries stricter expectations.

The workable response is restraint rather than verification theatre: do not build features that profile members, do not retain activity data longer than the feature needs, and keep marketing consent out of a Discord server entirely. A community that collects almost nothing has almost nothing to get wrong.

What to actually publish

A short notice in a pinned message or an information channel, in plain language: what the bots log, why, how long it is kept, who to contact, and how to ask for a copy or a deletion. Half a page. Link the full privacy policy from your website for the formal version.

Publishing it has a second effect beyond compliance. It forces you to write down what your systems actually store, and in our experience that exercise removes at least one store nobody could justify keeping.