IndieDev Games

COPPA and GDPR for indie games: where to start

Updated

This guide is general information, not legal advice. Laws change and the right answer depends on your game, your players, and where you operate. If your game is aimed at children, have a lawyer or privacy professional review your plan before launch.

Most indie developers never read a privacy law, and most do not need to become experts. What you do need is a clear picture of who plays your game, what data it touches, and a short list of things to put in place. This guide gives you that picture. The COPPA and GDPR checklist turns it into a list you can tick through and download.

The two laws people mean

COPPA is a United States rule enforced by the Federal Trade Commission. It protects children under 13. It applies to online services that are directed to children, and to services that knowingly collect personal information from a child under 13. "Online service" includes games, apps, and websites.

GDPR is the European Union's data protection law, and the UK has its own version. It applies when you offer your game to people in the EU or UK, wherever your studio is based. It covers everyone, not only children, and it has extra rules for children. Cookies and similar trackers are covered separately by ePrivacy rules.

Other places have their own laws, including several US states. The two above are the ones most small studios meet first, because most stores and web games are available worldwide.

Step 1: decide who your game is for

Almost everything else depends on this, so decide early and write down your reasons. There are three common answers: directed to children under 13, a general audience, or a mixed audience that includes children.

Regulators look at the whole picture, not only what you say. Subject matter, art style, characters, music, the way ads are used, and evidence of who actually plays all count. A cartoon style or a cute mascot can make a game look child-directed even if you never meant it to. A short dated note that explains how you decided is worth keeping. If a platform or regulator ever asks, you will be glad to have it.

Step 2: list the data your game collects

You cannot protect, disclose, or delete data you have not listed. Go through your game and your website and write down everything that collects anything:

  • Accounts, email addresses, and usernames.
  • IP addresses, device identifiers, and advertising IDs. Under both laws, these can count as personal information.
  • Cookies and analytics events.
  • Crash reports and engine telemetry.
  • Chat, voice, and user-generated content.
  • Location, even if it is only approximate.

Then list every third-party SDK and plugin in your build: analytics, ads, crash reporting, social login, and anything your engine adds by default. You are generally responsible for what the tools you embed do. Check each vendor's documentation for a child-directed or privacy-safe mode.

Once you have the list, cut. Data you never collect is data you never have to secure, disclose, or delete. Ask of each item whether the game really needs it.

Step 3: if children may play

If your game is directed to children, or you know that children under 13 use it, COPPA brings specific duties. The main ones:

  • Parental consent. You generally need verifiable parental consent before collecting a child's personal information. The FTC lists the accepted methods, and the right one depends on how you use the data, so check the current list rather than inventing your own.
  • Clear notice. You tell parents what you collect, how you use it, and whether you share it, as well as having an easy-to-find privacy policy.
  • No behavioral ads. Tracking and ad targeting based on persistent identifiers is personal information use. Turn off personalized ads for child users and set every ad network to its child-directed mode. Ad SDKs often default to the wrong setting.
  • Parent rights. Parents can review the data you hold, ask you to delete it, and stop further collection. You need a working process, such as a monitored email address, before the first request arrives.
  • Security and retention. Limit who can reach children's data, use HTTPS, and hash passwords. The updated COPPA Rule also expects written policies on security and on how long you keep children's data, so check the current text.

If your game is for a general audience, a neutral age screen helps. Ask for a birth date without hinting at a required age. Telling people which age gets them in invites false answers. Once you know a user is under 13, COPPA applies to that user.

Chat, voice, and friend features deserve extra thought. Open communication with strangers is the highest-risk feature for children, and it brings a moderation job with it. Turn these off by default for child players, or limit them to filtered options, and give people a way to report harmful content.

Step 4: if you have players in the EU or UK

  • Lawful basis. Pick and record a reason that lets you use each kind of personal data, such as contract, legitimate interests, or consent.
  • A plain privacy notice. Say who you are, what you collect, why, who receives it, how long you keep it, what rights people have, and how to contact you. Write it so the age group you serve can understand it.
  • Consent for trackers. Ask for opt-in consent before setting non-essential cookies or running analytics or ad trackers. Declining must be as easy as accepting, and people must be able to change their mind later.
  • Children's consent age. If you rely on consent for a child, GDPR sets the age at 16 by default, but EU countries may lower it to 13. The UK uses 13. Below that age you need a parent's consent. List the countries you target and check each one. UK players also fall under the Age Appropriate Design Code, which sets higher privacy defaults for services children are likely to use.
  • People's rights. Be ready to access, correct, delete, or export someone's data, and to respond within one month. For a small team, a monitored email address and a simple internal process is usually enough.
  • Vendors and breaches. Sign data processing agreements with vendors that handle personal data for you, and decide in advance what you will do in a breach, including who tells the authority within 72 hours when that is required.

Small studios are often exempt from some of the heavier requirements, such as appointing a data protection officer. Large-scale processing of children's data can change that, and if you are outside the EU and UK you may need a local representative. A lawyer can confirm this quickly.

Step 5: platform forms and your own pages

The law is one layer. Each place you publish adds its own forms and rules on top.

  • Steam. Fill in the Steamworks questionnaires, including the content survey, accurately, and keep them in step with the game. Wrong answers can get a page restricted or pulled. Check what any Steamworks features or third-party SDKs in your build send, and make sure your privacy policy matches.
  • itch.io. Describe your game's content honestly, link your privacy policy on the page, and say if the game collects data or connects to online services. Players rely on what you write.
  • Your own site or an HTML5 game. Make sure no analytics, ad, or social script runs before consent. Open the browser's network tab with cookies cleared to see what really loads, because a game page can quietly load many trackers. Serve everything over HTTPS.

Link your privacy policy inside the game, in settings or the main menu, and on every store or download page. A policy people cannot find is not much use.

Common mistakes

  • Leaving an ad or analytics SDK on its default settings in a game children play.
  • Loading analytics before the player has agreed.
  • Copying another studio's privacy policy without checking that it describes your game.
  • Answering a platform questionnaire once and never revisiting it after adding online features.
  • Collecting an email or birth date "just in case".

Before you launch

Run through the checklist, fix what is missing, and keep the downloaded copy with your records. Re-run it whenever you add an SDK, a platform, an online feature, or a new market. Most compliance problems come from changes made after launch. If children are your audience, finish with a review by someone qualified.

If you also need to know how your game fits the main rating systems, the age ratings guide covers that.

Get new tools in your inbox

One short email when we ship a new free tool for indie developers. No spam, unsubscribe any time.

By subscribing you agree to get these emails. You must be 13 or older. We confirm by email first and never share your address. See the privacy policy.