Almost every organization that builds or runs software keeps a second copy of its systems somewhere, for testing changes before they go live. Almost every one of those copies, at some point, gets filled with real data because real data makes testing easier. The University of Copenhagen has just shown what that costs when the copy is the part that gets breached.
What happened
The university's account of how the attack was spotted is worth reading closely. Its IT staff noticed that "an IT system had carried out a series of actions that it should not have performed," and those actions turned out to be cover for what the attacker was doing. The attacker had gained access to systems "normally restricted to a limited number of the University's IT staff," tried several of them, succeeded against one, and from there reached a database of personal data. The data in it had last been partly updated in January 2026.
On the evening of Friday 23 October the university announced that hackers had gained access to "one of the university's test environments," affecting around 525,000 people. The same evening it quietly closed physical access to "selected critical physical locations." Two days later it explained why: the PIN codes of about 20,000 people who use access cards had been compromised. It said it had held that detail back until every one of those PINs had been changed. Access reopened once the new codes were issued.
The following week was messier. On 26 October the university announced what it called a new hacker attack and shut down administrative systems as a precaution. The next morning it corrected itself: the activity was related to the original breach, not a second one. Systems came back gradually over the rest of the week, with the staff and student intranet still restricted to the campus network on 30 October.
Notification letters went out by Denmark's Digital Post system on 27 October and by email the day after. Students were less than impressed with the pace. "It's a shame we only hear about it three days later," the chair of the student council told TV 2.
One nuance about the term "test environment." The university used it in its public announcements, but the formal letter to affected people does not; it refers to restricted systems and a database. The precise nature of the system has not been published. What is clear is that the data in it was real, recent and extensive.
A copy of the data is the data
There are good reasons a test system ends up holding real records. Realistic data catches bugs that invented data misses, copying production is faster than building a convincing fake, and nobody intends the copy to be permanent.
The trouble is that the copy rarely inherits the protection of the original. Test systems tend to have more people with access, looser monitoring, less frequent patching and nobody whose job it is to notice when they should be switched off. They are also easy to forget, which is the theme that keeps returning in the incidents we write about, from the staging site nobody took down in the php2shell article to the decommissioned platforms in the Mexico leak.
None of that matters to the 525,000 people in this database. For them there is no difference between a breach of the live system and a breach of a copy. The names, identity numbers and phone numbers are equally real either way, and so is the phishing that tends to follow.
Look at the date range, too. Records going back to 2002 means this database held information on people who left the university more than two decades ago. Data that is no longer needed cannot be stolen if it has been deleted, and a test copy is the least defensible place to keep it.
Encrypted, with the key next to it
The university did encrypt the CPR numbers, which are Denmark's national identity numbers and the most sensitive item in the set. It also told affected people there is "a strong likelihood" the attacker can decrypt them, because "the information required for decryption has also been extracted."
This is the same lesson as the Railway breach the same month, at a smaller scale. Encryption only protects data from someone who does not also hold the means to decrypt it. When the key, or the information needed to derive it, sits in the same place as the data it protects, encryption mostly protects you from having to say "unencrypted" in the notification letter.
When a data breach unlocks doors
The detail that makes this incident unusual is the PINs. A database of names and identity numbers is a privacy problem. A database that also holds the codes for physical access cards is a security problem in a building full of people, which is why the university's first visible response was to lock doors rather than to send emails.
It is worth noticing how well that part went. The university closed access to critical locations the same evening it announced the breach, changed 20,000 PINs, and only then explained why. No misuse of the stolen PINs has been reported.
The part that cannot be fixed by the university is reuse. Its letter specifically told people to change any PIN they had reused elsewhere, "for example for your bank cards." Four digits chosen once and used everywhere are common, and a list of them tied to names is useful far beyond a campus.
What this means for a smaller organization
A 50-person company does not have half a million records, but it almost certainly has the same pattern in miniature:
- A staging copy of the website or online shop, loaded with a real customer export.
- A developer's laptop or a contractor's environment with a copy of the customer database "for testing."
- Spreadsheets exported from the CRM or the HR system for a one-off task, still sitting in a shared folder.
- A vendor demo or trial environment that someone populated with real data to see how it would look.
- Door-entry, alarm or access-control systems whose codes are stored in the same place as staff records, and staff who use the same PIN for the door and their bank card.
None of those is exotic, and each is a copy of real data with weaker protection than the original.
What to actually do
Find the copies. Ask your developers, your IT provider and any agency you use one question: where do copies of our customer or staff data exist outside the live system? Write down the answers, including the ones that sound temporary.
Keep real data out of test systems. Use invented or masked data for testing wherever possible. Where real data genuinely has to be used, treat that system exactly like production: the same access controls, the same patching, the same monitoring, and a date on which it is switched off.
Delete what you no longer need. Set retention periods for customer, staff and applicant records, and apply them to every copy, not only the live system. Data from people who left years ago is pure liability.
Keep keys away from what they protect. If you or a supplier encrypt sensitive data, ask where the decryption keys are kept. If the answer is "in the same database" or "on the same server," the encryption is not doing much.
Treat access codes as credentials. Building, alarm and door codes deserve the same care as passwords: stored separately, changed when people leave, and never shared with anything else. Remind staff not to reuse a door PIN for their bank card, and the reverse.
Plan the physical response in advance. Decide now who can lock down a building, how new codes or cards would be issued, and how you would tell staff, so that a breach like this one becomes an afternoon's disruption rather than a week's.
The summary
The University of Copenhagen handled the most dangerous part of this well: it locked doors fast and changed every exposed PIN before saying a word about them. What it could not undo was the decision, made long before any attacker arrived, to keep two decades of real personal data in a system it described as a test environment.
Every organization has its own version of that system. The useful question is not whether yours is as large as a university's, but whether you know where it is.
Sources
- Orientering om bruddet på persondatasikkerheden — University of Copenhagen (English version)
- Driftsforstyrrelser på KU — University of Copenhagen, incident updates
- Underretning om brud på persondatasikkerheden — University of Copenhagen, notification letter of 27 October 2026 (Danish and English)
- Københavns Universitet har været udsat for cyberangreb — DR
- University of Copenhagen data breach exposes data of 525,000 people — BleepingComputer
- Copenhagen University data breach — Infosecurity Magazine
- Studerende utilfredse med KU efter cyberangreb — TV 2 Kosmopol
