Denmark has about six million residents. In September, someone pulled the names, addresses and ID numbers of about 8.8 million people from its Central Person Register, known as the CPR. The register holds about 11 million records, because it includes people who have died or moved abroad as well as the living, so the breach covers roughly 80% of it.
The route in was not a smashed firewall. According to the Danish ministry that runs the register, someone abused the legal access of a small private Danish company that was entitled to query the CPR. Reports say the company made more than 14 million lookup attempts over ten days, and about 8.8 million of them returned a record. The company has not been named and its access has been cut off. Police have secured evidence at the firm but, at the time of the reports we reviewed, had identified no suspects and charged no one.
Found through an invoice
What makes the story unusual is how it came to light. Companies pay per lookup, and an unusually large invoice for this one firm flagged the heavy September usage. The ministry noticed the irregular activity on the evening of Friday 2 October, established the scale over the weekend, told the Danish Data Protection Agency (Datatilsynet) on Sunday 4 October and announced the breach on Monday 5 October. In other words, billing noticed what security monitoring had not.
The minister responsible, Christina Egelund, called it "a deeply serious incident" and asked for a thorough security review of the CPR system. People with name and address protection were reported as not affected, and services that rely on MitID, Denmark's national digital login, were not touched. Datatilsynet has opened a case into what happened, how it was possible and who is responsible for the data. Denmark's civil security agency has advised companies and authorities to stop relying on a CPR number alone to prove identity, because the numbers should now be treated as exposed.
Why this matters outside Denmark
You do not need to run a national register to be in the same position. Any organisation that lets suppliers, partners or customers query a data set through an API, a portal or a shared system has built a version of the CPR lookup. The questions are the same:
- Who has access, and why? Many organisations can name the contract but not the individual accounts behind it. Access granted for a project in 2022 often still works today.
- What does normal look like? A firm that usually makes a few hundred lookups a day suddenly making hundreds of thousands is an anomaly that a basic alert would catch. If your only alarm is the invoice, you are relying on the slowest control you have.
- Is the data minimised? Under UK GDPR, data minimisation means a recipient should get what it needs, not everything the system holds. Ask whether bulk lookup is necessary for each user and whether rate limits exist.
- Does your Record of Processing Activities reflect reality? A record that lists "supplier access" as one line is not doing its job. Each external party with access to personal data should appear with its purpose, the categories of data and the safeguards in place.
A worked example
A regional housing association lets a repairs contractor look up tenant names, addresses and phone numbers through an online portal so that engineers can book visits. The contractor has 40 logins. Six belong to people who left the contractor two years ago and nobody has removed them. The portal allows an export of the whole tenant list in one click, though the contractor never needs more than the day's appointments. No one has ever checked how many lookups the contractor makes in a day.
Nothing has gone wrong. But if one of those six accounts were compromised, the association would learn about it only when a tenant complained about a phishing call. A short review would find all three weaknesses within an hour.
Five practical steps
- List every external party with direct access to a system holding personal data, and the named people or accounts behind each.
- Record the volume each normally queries, then set alerts at a multiple of that baseline.
- Review accounts quarterly and remove any not tied to a live contract or a current employee.
- Rate-limit bulk queries, and require a documented reason for any exception.
- Stop treating an identifier such as a national insurance number, customer number or national ID as a password. Where you use one to verify identity, add a second factor.
What this means for your risk
UK GDPR makes you responsible for security, including security of data you allow others to reach. A regulator looking at an incident like this would ask what you knew about the access, how you monitored it and how quickly you noticed. "The supplier had a contract" is a starting point, not an answer.
Frequently asked questions
Is this a hack or a misuse of legitimate access? The Danish ministry says attackers misused a company's legitimate access. The detail of how has not been made public.
Does the UK have a similar register? Not one national register of this kind, but many UK bodies hold large data sets that they share with suppliers and partners through portals and APIs, so the lesson applies.
Do I need to tell the ICO if a supplier's access is abused? If it is a personal data breach likely to result in a risk to individuals, the controller must report it within 72 hours of becoming aware. Record your decision either way.
How often should access be reviewed? At least quarterly for any supplier with access to sensitive data, and whenever a contract ends.
How Pathway 2 Privacy can help: a Data Governance Framework sets who owns each data set and who approves access, a RoPA records every external party with access and why, and an Advisory Retainer gives smaller teams a named adviser to run the quarterly review without a full-time data protection officer. See also our data protection risk assessments, our GDPR support for small businesses and why a supplier breach is still your problem. Or start with a free data protection review.
Sources: Help Net Security, 6 Oct 2026; The Next Web, 6 Oct 2026; The Register.
