CCPA vs GDPR for Test Data: What Each Requires in Non-Production

Engineering and compliance teams keep hitting the same wall: a feature ships, QA needs realistic data, and someone clones the production database into staging. That copy carries the same personal data the law protects in production, and two of the most consequential privacy regimes, the EU's GDPR and California's CCPA/CPRA, both reach into that copy. They do not reach in the same way. This article compares what each law requires for personal data in non-production, cites the specific articles and code sections, and shows where fictional test data removes the problem entirely.

What is the core difference between CCPA and GDPR for test data?

GDPR and CCPA both regulate personal data in test and staging, but GDPR applies a consent-and-lawful-basis model to any identifiable EU person, while CCPA applies a notice-and-rights model to California consumers and households. GDPR has no production-only exemption; CCPA covers the same data in non-production copies, which makes the two regimes overlap heavily in practice.

The shared insight for teams is that neither law cares whether a database is labeled "prod" or "staging." GDPR scope is set by Article 2 (material scope) and Article 4 (definitions), and a staging row about a real EU resident is as protected as a production row ^[gdpr-art4]. CCPA scope follows the data, not the environment, under Cal. Civ. Code 1798.140 ^{[ccpa-1798140]}, and the California Attorney General frames the law as covering personal information wherever a covered business holds it ^[ccpa-oag]. The divergence shows up in definitions, the anonymization bar, and the penalty math.

What counts as personal data under GDPR vs personal information under CCPA?

Under GDPR Article 4(1), personal data is any information relating to an identified or identifiable natural person, directly or indirectly, by reference to identifiers like a name, ID number, location data, or online identifier. CCPA 1798.140(v) defines personal information as information that identifies, relates to, describes, or could reasonably be linked with a consumer or household, which sweeps in inferences and household-level signals.

The CCPA definition is notable for two extensions GDPR handles differently: it explicitly names households and inferences drawn to create a profile. GDPR reaches inferences through its broad "relating to" language and treats household data as personal where it can be tied to an individual, but California wrote both into the statute. The table below maps common test-data fields to each definition.

How do GDPR anonymization and CCPA deidentification differ for staging data?

GDPR anonymization is a high bar: under Recital 26, data is anonymous only when a person can no longer be identified by all means reasonably likely to be used, and anonymous data falls entirely outside GDPR ^{[gdpr-recital26]}. CCPA/CPRA deidentification under 1798.140(m) is a lower bar: data that cannot reasonably be linked to a consumer, supported by technical safeguards and a contractual ban on re-identification. National standards bodies treat re-identification risk as a measurable property rather than a binary, which is why irreversibility, not relabeling, is the test that holds up ^[nist-deid].

Why pseudonymized test data still counts under GDPR

Pseudonymization, defined in GDPR Article 4(5), replaces identifiers but keeps a key that can re-link the data. Pseudonymized data remains personal data and stays fully in scope ^[gdpr-art4]. A staging database where names are swapped for tokens, but a mapping table exists somewhere, is pseudonymized, not anonymized, and every GDPR obligation continues to apply. The deeper treatment of true irreversibility lives in our companion piece at /blog/synthetic-data-gdpr-anonymization.

Why CCPA deidentified data still carries duties

Even when data meets the 1798.140(m) deidentification standard, the business must maintain the safeguards, publicly commit to keeping the data deidentified, and contractually prohibit re-identification by recipients. Deidentified data is not fully exempt the way GDPR-anonymous data is; it is conditionally relieved of certain obligations as long as the safeguards hold ^{[ccpa-1798140]}.

The principles of data protection should not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.

What are the penalties for mishandling test data under each law?

GDPR penalties for personal data exposed in staging reach up to 20 million euros or 4 percent of worldwide annual turnover, whichever is higher, under Article 83(5) ^[gdpr-art83]. CCPA/CPRA administrative penalties run to 2,500 USD per violation or 7,500 USD per intentional violation under 1798.155, plus a private right of action with statutory damages of 100 to 750 USD per consumer per breach under 1798.150 ^{[ccpa-1798150]}.

The penalty structures reward different behaviors. GDPR's turnover-linked cap means a large enterprise faces existential numbers from one mishandled staging dump. California's per-violation and per-consumer math scales with the number of records, so a non-production copy of millions of consumers multiplies fast. Regulators have signaled that non-production data is squarely in scope: the California Privacy Protection Agency began enforcement under CPRA following the rulemaking that took effect in 2023 ^[cppa].

What compliance actions reduce risk in non-production environments?

The most reliable control is to never load real personal data into non-production at all: generate fictional records that satisfy both GDPR Article 4 and CCPA 1798.140(v) by describing no identifiable person. Where real data is unavoidable, apply GDPR-grade irreversible anonymization, restrict access under Article 32, and document a lawful basis and retention limit for every copy.

1. Default to synthetic data. Provision test and staging from generated records using reserved, never-issued, and sandbox value ranges so no row maps to a real person under either definition.
2. Engineer to the stricter bar. Build for GDPR irreversible anonymization (Recital 26); meeting it also clears the CCPA deidentification standard (1798.140(m)).
3. Minimize and scope. If production data must be subset, copy only the fields a test actually needs, satisfying GDPR data minimization (Art. 5(1)(c)).
4. Lock down access and logging. Apply Article 32 security controls to staging identically to production, including encryption and access logging.
5. Document basis and retention. Record a lawful basis (Art. 6) and a deletion schedule for every non-production copy that holds real personal data.
6. Map your obligations once. Maintain a register that tags each environment against GDPR and CCPA scope so audits and breach reviews are fast.

For US companies serving EU users, the practical answer to "which law" is both, engineered to the stricter one. A California business with EU customers must satisfy CCPA for California consumers and GDPR for EU data subjects simultaneously. Designing non-production data to GDPR's irreversible standard, or skipping real data altogether with synthetic records, collapses two compliance problems into one engineering decision.