GDPR Compliance Checklist

Required legal gdpr_compliance_checklist

Agent Prompt Snippet

Verify that lawful basis, consent mechanisms, data minimization, retention limits, and cross-border transfer safeguards are addressed in a GDPR compliance checklist.

Purpose

The General Data Protection Regulation applies the moment a single player in the European Union launches your game. It does not matter where the studio is incorporated, where the servers are hosted, or whether the game is free-to-play—if you process personal data of EU residents, GDPR governs that processing. A GDPR compliance checklist translates the regulation’s 99 articles into a concrete, auditable set of obligations mapped to your game’s specific data flows.

Games collect a remarkably broad range of personal data. Player profiles contain usernames, email addresses, and avatar images. Telemetry systems record play sessions, device identifiers, IP addresses, and hardware fingerprints. Chat logs capture free-text communication that may include names or locations. Payment systems process billing addresses and transaction histories. Leaderboards and matchmaking services associate persistent identifiers with behavioral data. Every one of these data categories requires a documented lawful basis, a defined retention period, and a technical mechanism for erasure upon request.

The checklist covers seven compliance domains: data mapping and classification, lawful basis determination for each processing activity, consent management UI and record-keeping, Data Subject Access Request (DSAR) procedures, breach detection and 72-hour notification workflows, DPO designation, and cross-border transfer mechanisms for data leaving the EEA. It also addresses the intersection of GDPR with children’s data—Article 8 requires verifiable parental consent for players under 16 (or 13, depending on member state), which overlaps with COPPA obligations for studios serving US audiences.

Without this document, the team operates on assumptions. Engineers guess which data is “personal.” A player requests deletion and no one knows which databases, backups, and third-party integrations contain copies. A breach occurs and the 72-hour window passes while the team scrambles to determine what was exposed.

Who needs this document

Persona	Why they need it	How they use it
Sam (Indie Dev)	Publishing on any platform accessible to EU players triggers GDPR obligations; non-compliance fines can reach €20M or 4% of global revenue	Works through the checklist before launch to identify all personal data flows, implement consent UI, and configure deletion endpoints for each data store
Claude Code (AI Agent)	Must implement data collection, storage, and deletion logic that conforms to documented lawful bases and retention periods	Reads the checklist to determine which fields require consent before collection, which data stores must support record-level deletion, and what audit logging is required for DSAR fulfillment
Priya (Eng Lead)	Responsible for ensuring the engineering team builds GDPR-compliant systems and can respond to DSARs within the 30-day statutory deadline	Uses the checklist to scope DSAR automation work, assign data store owners, and verify that every third-party SDK has a signed Data Processing Agreement
DevOps (Infrastructure)	Manages the infrastructure where personal data is stored, replicated, and backed up across regions	References the checklist to configure data residency controls, verify encryption at rest and in transit, ensure backup retention aligns with GDPR retention limits, and validate that cross-border transfers use approved mechanisms (SCCs or adequacy decisions)

What separates a good version from a bad one

Criterion 1: Every processing activity has a documented lawful basis

✓ Strong: “Player gameplay telemetry (session duration, level completion, device ID) is processed under legitimate interest (Article 6(1)(f)) for game balancing and crash diagnostics. Legitimate interest assessment completed 2025-01-15, documented in LIA-007. Marketing email sends are processed under consent (Article 6(1)(a)), collected via the opt-in checkbox on the registration screen, with consent records stored in the consent management table (retention: duration of account + 3 years).”

✗ Weak: “We process player data as needed for game operations.” (No lawful basis identified per processing activity. “As needed” is not a GDPR-recognized legal ground. An auditor or supervisory authority will reject this immediately.)

Criterion 2: DSAR procedures specify systems, owners, and timelines

✓ Strong: “Upon receiving a DSAR, the support team logs the request in Jira (SLA: acknowledge within 48 hours). The data engineering team queries five systems: player database (PostgreSQL), analytics warehouse (BigQuery), payment processor (Stripe—via API export), chat logs (Redis archive), and backup storage (S3 Glacier—restore time: 24 hours). All data is compiled into a machine-readable JSON export and delivered to the requester within 25 calendar days, leaving a 5-day buffer before the 30-day statutory deadline.”

✗ Weak: “Players can request their data by emailing support.” (No internal workflow, no system inventory, no timeline commitment. When a DSAR arrives, the team will spend the first two weeks figuring out where data lives—leaving no time for actual fulfillment.)

Criterion 3: Right to erasure covers all data stores including backups and third parties

✓ Strong: “Account deletion removes the player record from the primary database within 24 hours. Leaderboard entries are anonymized (username replaced with ‘deleted_user_[hash]’) within 48 hours. UGC attribution is decoupled (creator field set to null; content retained under platform license). Analytics data is pseudonymized by replacing player_id with an irreversible hash. Stripe is notified via API to delete stored payment methods. S3 Glacier backups expire per the 90-day retention policy; a deletion marker prevents restoration of the specific record.”

✗ Weak: “We delete the user’s account when requested.” (What about leaderboard entries, chat logs, replays featuring that player, analytics data, payment records, and the backup from last Tuesday? Partial deletion is non-compliant deletion.)

Criterion 4: Breach notification workflow meets the 72-hour window

✓ Strong: “Upon confirmed breach: (1) Security lead assesses scope within 4 hours—affected data categories, number of records, geographic distribution. (2) DPO notifies the lead supervisory authority within 72 hours of awareness, including nature of breach, approximate records affected, likely consequences, and mitigation measures. (3) If the breach poses high risk to individuals, affected players are notified via email and in-game banner within 7 days. (4) Post-incident report filed within 30 days.”

✗ Weak: “We will notify authorities if there is a data breach.” (No timeline, no responsible party, no assessment process. The 72-hour clock starts at “awareness”—without a defined detection-to-assessment pipeline, the team will not even know when the clock started.)

Common mistakes

Treating consent as the default lawful basis for everything. Consent is fragile—it can be withdrawn at any time, and withdrawal must be as easy as granting it. Many game data processing activities have stronger legal grounds: contract performance (processing needed to deliver the game service), legitimate interest (analytics for bug fixes and balancing), or legal obligation (financial record-keeping). Over-relying on consent creates operational complexity and user friction. Map each processing activity to the most appropriate lawful basis, not the most familiar one.

Ignoring children’s data until a regulator asks. GDPR Article 8 requires verifiable parental consent for processing personal data of children below 16 (some member states lower this to 13). If your game’s age rating allows players under 16, you must implement age verification and parental consent flows. The Irish DPC fined TikTok €345M in 2023 specifically for children’s data processing failures. Integrate age-gating into the registration flow and document the consent mechanism in the checklist.

Signing cloud provider contracts without a Data Processing Agreement. Every third party that processes personal data on your behalf—cloud hosting, analytics, crash reporting, payment processing, anti-cheat services—requires a signed DPA under Article 28. The DPA must specify processing purposes, data categories, retention, sub-processor controls, and audit rights. Using AWS, Google Cloud, or Unity Analytics without executing their standard DPA is a compliance gap that supervisory authorities check for.

No mechanism for cross-border transfer validation. If player data leaves the EEA—to US-based analytics services, Asian game servers, or global CDN nodes—each transfer requires a legal mechanism. Standard Contractual Clauses (SCCs) are the most common post-Schrems II mechanism. The checklist must document which transfers occur, which mechanism covers each, and when the Transfer Impact Assessment was last reviewed.

How to use this document

When to create it

Write the GDPR compliance checklist during pre-production, before any personal data collection is implemented. Data flows designed without GDPR consideration require expensive retrofitting—adding consent UI to existing screens, building deletion pipelines for databases not designed for record-level erasure, and renegotiating third-party contracts to include DPA terms. If you are adding monetization, analytics, or social features to an existing game, update the checklist before the feature ships.

Who owns it

The Data Protection Officer (or the studio lead performing that function) owns the checklist. Engineering owns the technical implementation of each control. Legal counsel reviews lawful basis determinations, DPA terms, and cross-border transfer mechanisms. The checklist is reviewed quarterly, updated when new processing activities are introduced, and re-assessed when regulatory guidance changes.

How AI agents should reference it

get_standard_docs(type="video_game", features=["monetization"])
→ gdpr_compliance_checklist in documents[]
→ agent reads the checklist before implementing any data collection, storage, or analytics feature
→ agent verifies each new data field has a documented lawful basis and retention period
→ agent ensures deletion endpoints cover all data stores referenced in the DSAR section
→ agent flags if a new third-party integration lacks a signed DPA

The prompt_snippet — “Verify that lawful basis, consent mechanisms, data minimization, retention limits, and cross-border transfer safeguards are addressed” — tells the agent to confirm all five pillars are documented and traceable to specific technical controls.

How it connects to other documents

The GDPR Compliance Checklist operationalizes the Privacy Policy—the policy tells players what data is collected and why; the checklist ensures every claim is backed by a technical control and a lawful basis. The Security & Privacy Plan provides the encryption, access control, and audit logging infrastructure that the checklist’s technical measures depend on. The Data Catalog is the authoritative inventory of every personal data field, its classification, storage location, and retention period—the checklist references this catalog rather than duplicating it. The Incident Response Plan defines the breach detection and escalation workflow that feeds into the checklist’s 72-hour notification procedure.