Game server privacy: player data and GDPR

A game server collects more personal data than most owners realise: every player's IP address in the logs, their platform IDs and names, chat history, and whatever your plugins add - ban records, linked Discord accounts, email addresses for login plugins, answers on whitelist applications. If you run a community server open to people in the EU or UK, the GDPR (or its UK version) very likely applies to you, and the obligations for a typical server are modest: know what you collect, collect less where you can, keep it only as long as you need it, tell players in a short privacy notice, answer the occasional request to see or delete data, and keep it secure. A server for a handful of friends usually falls under the exemption for purely personal activity.

This post is practical guidance for server owners, not legal advice. If your community is large, takes payments or is aimed at children, it is worth paying for an hour of a data-protection professional's time.

What your server actually collects#

Start with an inventory. Most owners are surprised by the second half of the table.

Some concrete examples of where this sits on disk:

• Minecraft writes a line like Steve[/203.0.113.5:51234] logged in with entity id 412 for every join in logs/latest.log, and keeps compressed old logs beside it indefinitely by default. usercache.json maps names to UUIDs, and banned-ips.json holds addresses. EssentialsX keeps a file per player under plugins/Essentials/userdata/ that includes their last address.
• Source games log connections with the address when logging is on, and SourceMod logs admin actions with SteamIDs.
• FiveM with txAdmin records every identifier a player connects with, including IP and hardware tokens, in its database.
• Survival games generally log joins with platform IDs, and many log addresses too.

Then there is everything outside the game server: the Discord server, a web map that shows player positions and names, a statistics website, a ban list shared with other communities, spreadsheets of staff applications. Those count too.

Does the GDPR apply to your server?#

Three questions decide it.

1. Is it purely personal or household activity? The GDPR does not apply to processing by an individual "in the course of a purely personal or household activity". A private server for you and your friends, not advertised, not open to strangers, is very probably in this category.
2. Are you or your players in the EU or UK? The GDPR applies to anyone established in the EU, and to people outside it who offer services to or monitor people in the EU. A public server that accepts European players is in scope in practice, whoever runs it. The UK has its own version with nearly identical rules.
3. Is it a community, a club or a business? Once a server is public, has staff, takes donations or sells ranks, it is no longer household activity. The fact that nobody makes a profit does not take it out of scope.

For a public community server, assume it applies. The good news is that the obligations scale with what you do, and a typical game server does not do much.

Why you are allowed to collect it#

The GDPR requires a lawful basis for each use of personal data. For a game server, three cover almost everything:

• Legitimate interests - running the server securely, preventing cheating and abuse, enforcing bans, investigating reports. IP logs and ban records fit here, as long as you keep them proportionate. This is the basis for most of what a server does.
• Contract - providing something a player paid for, such as a rank. The store platform usually handles the payment data as its own responsibility.
• Consent - anything optional: a newsletter, linking a Discord account for a cosmetic role, public statistics pages with names, recording voice. Consent must be freely given, specific and as easy to withdraw as to give.

Legitimate interests is not a blank cheque. It means a real interest, data that is actually needed for it, and a balance with the player's reasonable expectations. Keeping every IP address forever "in case" fails the test; keeping them for a few weeks to deal with ban evasion passes comfortably.

Retention: how long to keep what#

Most servers keep everything forever by accident, because logs are never deleted. A short retention table, written down and enforced by a schedule, is the single most useful privacy step you can take.

These are reasonable starting points, not legal limits. Pick numbers you can justify, write them in your privacy notice, and make the server follow them.

On a Linux server, a scheduled find does the log part:

# Delete Minecraft logs older than 60 days$ find /srv/minecraft/logs -name '*.log.gz' -mtime +60 -delete# The same idea for Source game logs$ find /srv/tf2/tf/logs -name '*.log' -mtime +60 -delete

On a hosted panel without shell access, the same thing can be done by hand from the file manager on a calendar reminder, or by a plugin with a log-retention setting. Server logs worth keeping covers what is worth keeping in the first place and how to rotate it.

Backups are the part people forget. A world backup from a year ago contains the logs and player data from a year ago. Keeping backups is right; keeping an unlimited number of them indefinitely is not. Let rotation do its job, and only lock the backups you have a reason to keep.

Collect less in the first place#

The cheapest data to protect is data you never collected.

• Do not ask for what you do not need. Whitelist applications rarely need a real name, an exact age, a location or a photo. "Are you 13 or over?" and "How did you find us?" are usually enough.
• Turn off logging you never read. Chat logging to a database, position tracking, detailed statistics with names - if nobody uses it, switch it off.
• Limit who can read logs. Moderators need chat and action logs; very few people need IP addresses. On a panel with subusers, give moderators console access rather than file access, which keeps raw logs and plugin databases out of reach.
• Avoid public statistics with identifiers by default. A leaderboard is fine. A public page with every player's login times and last address is not.
• Do not share ban lists wider than necessary. Global ban systems for communities covers what is reasonable to exchange.

When a player asks to see or delete their data#

Players have the right to ask for a copy of their personal data, to have it corrected, and in many cases to have it deleted. Requests are rare on game servers, but they happen, usually after someone leaves a community on bad terms.

You must answer within one month of the request, extendable by two further months for complex requests if you tell the person. A practical routine:

1. Confirm who is asking. Ask them to message from the platform account in question, or join the server, so you do not send someone's data to an impostor.
2. Search everywhere you listed in your inventory. Logs, player data files, plugin databases, ban lists, the Discord bridge, spreadsheets.
3. For an access request, send what you found in a readable form: a list of the data categories, the extracts, how long you keep each, and who else receives it.
4. For a deletion request, delete what you no longer need. You may keep what you still have a legitimate reason for - most commonly an active ban and its evidence. Say so in your reply.
5. Write down what you did and when.

Deleting a player from a world is game-specific: on Minecraft it is their file under world/playerdata/ named by UUID, plus plugin data; on most survival games it is a player save or a database row. Logs older than your retention period should already be gone, which makes this much easier - one more reason to have a retention period.

Children, payments and staff#

Three areas deserve extra care.

Children. Many game communities have young players. Where consent is your lawful basis for an online service offered directly to children, the GDPR requires parental consent below an age that each country sets between 13 and 16. The simplest approach for a server is to avoid needing consent at all: collect nothing optional, rely on legitimate interests for the security basics, and do not ask children for personal details on applications or in Discord.

Payments. If you sell ranks or perks, use a store platform and let it handle payment data. You will still see names and email addresses in purchase records; keep them only as long as you need them for refunds and disputes. Monetising a game server within the rules covers the game-specific rules on what may be sold.

Staff. Your staff see personal data every day: addresses in logs, reports, evidence. Tell them what they may use it for (moderation only), that they may not share it outside the team, and take access away when they leave. A staff member who doxxes a player using your logs is your problem as well as theirs.

Breaches, your host and other services#

A personal data breach is any loss, leak or unauthorised access: a stolen database backup, a leaked plugin database with emails, a staff member posting logs publicly, a compromised server. If a breach is likely to put people at risk, the GDPR requires notifying your data protection authority within 72 hours of becoming aware of it, and telling the people affected directly if the risk is high. A leak of login-plugin emails and password hashes is the classic example that needs both. What to do when your server is hacked covers the technical response; keep a short written record of what happened and what you decided, whatever the outcome.

Your hosting provider stores and processes data on your behalf. RE:NODE runs its servers on hardware in Germany, inside the EU, and platform backups are copied to separate hardware. Other services you connect - Discord, store platforms, server listing sites, RCON services such as BattleMetrics - each handle their own share of your players' data under their own policies. Mention them in your privacy notice.

A privacy notice in plain words#

You need a notice players can find: on your website, pinned in Discord, or linked from the server's message of the day. It does not need to be long. This structure covers a typical server:

Who runs this server: [community name], contact [email or Discord].What we collect: your account ID and name, your IP address when youconnect, chat and commands, and in-game data such as builds andinventory. [Add: emails for login, Discord links, applications.]Why: to run the server, prevent cheating and abuse, and enforce bans.How long: connection and chat logs 60 days; ban records while the banis active plus 6 months; player data until the next wipe or a yearof inactivity.Who else sees it: our host (servers in Germany); [Discord, store,other services].Your rights: ask us for a copy, a correction or deletion at [contact].We answer within one month. You can also complain to your dataprotection authority.

Keep it accurate. A short notice that matches what you do is better than a long template copied from a company that does something else.

FAQ#

Is a private server for friends covered by the GDPR?

Usually not. A server that is private, not advertised and used by a group of people you know falls under the exemption for purely personal or household activity. Once it is public or has a community around it, assume it is covered.

Can I keep IP addresses to stop ban evasion?

Yes, for a proportionate period. Ban evasion is a legitimate interest, and a few weeks to a few months of connection logs is easy to justify. Keeping every address forever is not.

Do I have to delete a banned player's data if they ask?

Not the data you need to enforce an active ban. You can keep the identifier and the reason, delete the rest, and tell them why. Once the ban expires or is lifted, the reason to keep it goes too.

Are game server backups a privacy problem?

They contain personal data like everything else, so they should be secured and rotated. Keeping a reasonable number of backups for restoring the server is legitimate; keeping every backup forever is not.

Who is responsible for player data on a hosted server: me or the host?

You decide what is collected and why, so you are responsible for it. The host stores it on your behalf and is responsible for keeping the platform secure.