The University of Copenhagen said on October 23 that attackers reached one of its test environments and obtained information on about 525,000 individuals. A test environment that holds real national identity numbers is a production system, and security teams should scope, monitor and retire it as one.
What the university disclosed
The University of Copenhagen’s own incident page sets out the facts. It says the attack was detected on Tuesday, October 20, and brought under control, and that the hackers gained access to one of its test environments. In its words, “The hackers have gained access to information on approximately 525,000 individuals.” The page lists the data as full name, national identity number, work and home telephone numbers and a personal email address. It also says there is no indication the attackers reached systems that support day-to-day operations.
The university has reported the incident to the Danish Data Protection Agency and says it falls within the scope of the General Data Protection Regulation. A later update says PIN codes for ID cards belonging to about 20,000 staff and students were compromised, that new codes were issued, and that physical access to selected locations was restricted and then reopened. On October 27 it corrected a report of a second attack and said the shutdown of administrative systems remains linked to the original incident.
This column takes no view on the university’s decisions. The point sits with the category of system involved, because the same thing can be true at any organization with a staging or test database.
My argument: the label does not change the data
I think security teams treat the word “test” as a statement about risk, and it is only a statement about purpose. A test database that holds 525,000 records with national identity numbers carries the same breach consequences as the production one: notification duties, regulator contact and months of work for the people affected. The university’s own page shows this, since it treats the incident as a GDPR matter with the data protection agency informed.
My recommendation has three parts. First, inventory every non-production environment and record what data each one holds, because you cannot protect a copy you have not listed. Second, apply the production access model to any environment holding real personal data, with the same logging, the same multi-factor rules and the same network exposure review. Third, set a retention date for copies of production data in test systems, and delete them when the date arrives.
A workable rule helps here. If exposing a field would trigger a notification duty, that field does not belong in a test copy unless the environment is governed like production. Give each non-production environment a named owner who answers for what it holds, because test systems tend to outlive the project that created them and nobody remembers what was loaded into them. Ownership also tells the incident team whom to call when a scanner or an alert points at a system nobody on the security team has heard of.
The strongest objection
The best counter-argument is that developers need realistic data to test properly, and synthetic data never matches the shape of the real thing. That is true for some workloads. It argues for masking or tokenizing fields such as national identity numbers before the copy lands in a test system, which keeps the shape and drops the exposure. Where real records are unavoidable, the environment moves into production scope, with the cost that comes with it. Treating it as a lower tier saves money only until the first disclosure.
A second objection holds that a contained test environment limits the damage. The university’s page says there is no indication the day-to-day systems were reached, and that is welcome. The exposure still came from the test copy alone, so the limit on the blast radius did not limit the harm to the people whose records sat in it. Our earlier column on guarding backups like production makes the same point about another copy of the data that tends to get less attention.
What to do this week
- List the staging, test and development databases and note which hold real personal data.
- Mask national identifiers and contact details in any copy that does not need them.
- Put the remaining environments under the same monitoring and access controls as production.
- Pair this with the exposure inventory described in our piece on why an exposure inventory decides your first hour after an advisory, so test systems appear on the list from day one.
Anil Kale writes about data protection, vulnerabilities and the business of security for CyberTech.
