A test environment at the University of Copenhagen was reportedly the entry point for an attack that exposed personal data tied to approximately 525,000 people. The compromised records included encrypted Danish CPR numbers, and the university warned that the information needed to decrypt them was also taken. Access-card PINs for approximately 20,000 students and employees were exposed too.
This checklist covers the controls your data governance team can verify in nonproduction environments: data inventory, masking, encryption key separation, credential handling, and breach readiness. Each item has a done/not-done state and a description of what good looks like.
Prerequisites
Before you start, confirm you have:
- A current list of every nonproduction environment (test, staging, development, training, analytics sandboxes), including those run by processors.
- Your record of processing activities under Article 30, with the owners of each system identified.
- Access to the people who manage database refreshes and key management. Their answers will differ from what policy documents say.
The Checklist
1. Inventory every nonproduction environment that holds personal data.
Reference: Article 30 (records of processing), Article 5(2) (accountability).
Done: Each environment is listed with an owner, a data source, and a refresh method. Not done: You rely on production inventories alone.
What good looks like: Nonproduction systems appear in your records of processing as distinct entries, and no environment exists that nobody can name an owner for.
2. Establish a lawful basis and purpose for test data use.
Reference: Article 5(1)(b) (purpose limitation), Article 6.
Done: You've documented why personal data is needed for testing and run a compatibility assessment where data was collected for another purpose. Not done: Production copies are used because it's convenient.
What good looks like: The default answer to "can we copy production into test?" is no, and exceptions are approved in writing.
3. Replace live data with masked, synthetic, or minimized data.
Reference: Article 5(1)(c) (data minimization), Article 25 (data protection by design and by default).
Done: Direct identifiers such as national identity numbers, contact details, and credentials are removed or replaced before data reaches a test environment. Not done: Test databases are restored from production backups.
What good looks like: A developer can do their job without ever seeing a real person's identifier, and refresh scripts apply masking as a mandatory step, not an optional one.
4. Apply the same access controls as production, at minimum.
Reference: Article 32(1) (appropriate technical and organizational measures).
Done: Multifactor authentication, role-based access, logging, and network restrictions match production standards. Not done: Test systems use shared accounts or flat network access.
What good looks like: Your risk assessment treats a test environment holding real data as production-equivalent, and nobody argues otherwise.
5. Keep encryption keys physically and logically separate from encrypted data.
Reference: Article 32(1)(a) (encryption), Article 32(2) (risk assessment).
Done: Keys live in a dedicated key management system or hardware security module, with access limited to named roles and no keys stored in the same database, server, or environment as the data they protect. Not done: Keys, key derivation material, or decryption routines sit alongside the ciphertext.
What good looks like: An attacker who fully compromises a test database still cannot decrypt a single record. Copenhagen's experience shows why this matters: encryption only protects data when the means of decryption stay out of reach, and the university considered there to be a significant risk that the CPR numbers could be recovered.
6. Treat encrypted data as personal data in your risk assessment.
Reference: Article 4(1), Article 4(5) (pseudonymization), Recital 26.
Done: Your risk assessments assume encrypted or pseudonymized data remains personal data and consider what happens if the key is lost with it. Not done: Encrypted fields are treated as out of scope for breach analysis.
What good looks like: Breach risk scoring has a distinct line for "encrypted, key status unknown or compromised," and it is scored as exposed.
7. Never store credentials in recoverable form.
Reference: Article 32(1), Article 25.
Done: Secrets such as access PINs, passwords, and tokens are hashed with a suitable algorithm where recovery isn't required, and are never copied into test data. Not done: Credentials are stored in plain or reversibly encrypted form for convenience.
What good looks like: A leaked table of credentials gives an attacker nothing directly usable, and test data contains no live credentials at all.
8. Link physical access credentials to a revocation procedure.
Reference: Article 32(1)(b) (ongoing confidentiality and integrity), Article 33(5) (documenting breaches and remedial action).
Done: You can revoke and reissue every physical access credential on short notice, and you know which systems store them. Not done: Revocation depends on a manual process nobody has tested.
What good looks like: When credentials are exposed, replacement and temporary access restrictions can be executed as one coordinated step. Copenhagen replaced the compromised PINs and temporarily restricted access to selected critical locations while it did so.
9. Set retention limits for nonproduction data.
Reference: Article 5(1)(e) (storage limitation).
Done: Test datasets have an expiry date and are deleted on schedule. Not done: Old copies persist indefinitely. The Copenhagen incident involved records that turned out to be older than first stated, a reminder that historical data tends to outlive its purpose.
What good looks like: You can state the age range of data in any environment with confidence, and nothing sits there without a reason.
10. Extend breach detection and response to nonproduction systems.
Reference: Article 33 (notification to the supervisory authority within 72 hours), Article 34 (communication to data subjects).
Done: Nonproduction environments feed your monitoring, and your incident playbook names them explicitly. Not done: Alerts only cover production.
What good looks like: Scoping a personal data breach involving a test environment takes hours, not days, because you already know what data lives there and who is affected.
11. Plan for people you can't reach.
Reference: Article 34(3)(c) (public communication where individual notice requires disproportionate effort).
Done: You've documented a fallback for records that lack contact details. Not done: Notification assumes every record has an email address. Copenhagen found some compromised records held only a name, and published its notification letter publicly as a result.
What good looks like: Your playbook includes a public notice route that meets the Article 34(3)(c) test.
Common Mistakes
- Assuming test means low risk. Risk follows the data, not the environment label.
- Masking once, then refreshing from production. One unmasked refresh undoes the whole control.
- Treating encryption as a finish line. If keys travel with the data, you've added a step for the attacker, not a barrier.
- Forgetting processors. Hosted test and staging environments are your responsibility under Article 28 as much as production is.
- Skipping physical consequences. Digital stores of access codes connect directly to building security.
Next Steps
Start with item 1. You can't secure what isn't listed. Then pick one test environment and run items 3, 5, and 7 against it this week; those three controls would have limited the damage in an incident like Copenhagen's. Report the results to your DPO, record any gaps in your Article 32 risk assessment, and set a date to revisit the remaining items.
