What Happened
Unauthorized parties accessed Denmark's Central Person Register through a small Danish company's legitimate account over a 10-day period in September. This breach exposed names, addresses, and personal identification numbers for about 8.8 million people, roughly 80% of the register. The attackers used automated lookups to identify valid CPR numbers, exploiting the company's lawful access rights. An employee at the register's administration noticed the unusual activity on October 2, leading to the suspension of the company's access and a report to Datatilsynet, Denmark's supervisory authority. Police are investigating.
Timeline
September (10-day window): Unauthorized parties conducted automated lookups through a small Danish company's account, systematically querying the register to identify valid CPR numbers.
Friday, October 2: A register administration employee noticed unusual activity patterns in the company's account.
Weekend of October 3-4: The administration determined the scope, approximately 8.8 million records accessed.
October 4: The register's administration filed a notification with Datatilsynet.
October 5: The digitalization ministry issued a public statement. Datatilsynet published its initial notice.
This timeline reveals a critical gap: 10 days elapsed between the start of the breach and detection. The GDPR 72-hour notification requirement under Article 33 starts when you become aware of the breach, not when it begins. But you can't notify what you haven't detected.
Which Controls Failed or Were Missing
Access Monitoring and Anomaly Detection: The breach ran for 10 days before anyone noticed. A small company making automated lookups at scale should have triggered alerts within hours. The volume alone, queries covering 80% of a national register, was an obvious deviation from normal business use.
Access Scope Controls: The company had legitimate access rights under Denmark's CPR Act, but those rights were meant for looking up customers or employees the company already dealt with. No technical control prevented the account from querying millions of records it had no business reason to access. The gap between "what the law permits" and "what the system enforces" left the door open.
Authentication and Credential Management: Official statements don't explain how unauthorized parties gained access to the company's systems. This suggests either compromised credentials or inadequate access controls at the company level. The register's administration had no visibility into whether the "authorized" company was actually the one making the queries.
Rate Limiting and Throttling: Automated lookups to identify valid CPR numbers should have hit rate limits. A CPR number has 10 digits: 6 for date of birth, 4 serial digits. Systematically testing combinations at scale is a brute-force attack, and nothing stopped it.
What the Relevant Standard Requires
Article 32 (Security of Processing): Controllers and processors must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. For a national population register, that risk is inherently high. Measures must include the ability to ensure ongoing confidentiality, integrity, and availability, and the ability to restore availability after an incident.
Automated monitoring isn't optional at this scale. Article 32(1)(d) explicitly requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures." If your monitoring can't catch 10 days of automated queries against 8.8 million records, your testing process has failed.
Article 33 (Notification of a Personal Data Breach): The register's administration notified Datatilsynet within 72 hours of becoming aware, meeting the Article 33(1) deadline. But "becoming aware" happened 10 days late because detection controls weren't working. Compliance with notification timing doesn't excuse the failure to detect.
Article 5(1)(f) (Integrity and Confidentiality): Personal data must be processed in a manner that ensures appropriate security, including protection against unauthorized processing. The breach violated this principle directly. The data wasn't technically "unauthorized" under the access agreement, but the use was, highlighting why access rights need technical enforcement, not just contractual terms.
Processor Oversight (Article 28): If the small company was acting as a processor for other controllers, those controllers failed their Article 28(1) obligation to use only processors providing sufficient guarantees. If the company was a controller in its own right, the register's administration should have had stronger controls over third-party controller access.
Lessons and Action Items for Your Team
Build Access Monitoring That Detects Volume Anomalies in Real Time: If a third-party account suddenly queries 100 times its normal rate, you need an alert within minutes. Set baseline thresholds for each account based on their business purpose, and flag deviations automatically. For high-risk systems, consider requiring human review for any access pattern that exceeds daily norms by more than 50%.
Enforce the Principle of Least Privilege at the Technical Layer: Contractual restrictions ("you may only look up your customers") mean nothing if the system lets an account query anyone. Scope access by IP range, time of day, query volume, and specific data subsets. If a company's legitimate use case involves 500 lookups per month, configure the system to block the 501st.
Implement Rate Limiting on Lookup Functions: Any interface that accepts identifiers as input, CPR numbers, email addresses, account IDs, should throttle requests. A human user might make 10 lookups in a session. An automated script trying to brute-force valid identifiers will make thousands. Set limits that accommodate legitimate use while blocking enumeration attacks.
Require Multi-Factor Authentication for Third-Party Access: If the unauthorized parties compromised the company's credentials, MFA would have added a barrier. For access to sensitive registers, consider hardware tokens or certificate-based authentication, not just SMS codes.
Review Your Third-Party Access Agreements Now: List every external party with system access. For each one, document: What data can they access? What's their business justification? When did you last verify they still need it? If you can't answer those questions for every account, you're operating blind.
Test Your Detection Controls with Realistic Scenarios: Run a tabletop exercise: "A third-party account starts making 10,000 queries per day. How long until we notice? Who gets alerted? What's our response process?" If the answer is "we'd probably notice eventually," your controls aren't sufficient for Article 32.
Denmark's minister for digitalization told the press that alarms should have gone off given how long the breach lasted. She's right. The question for your team: would your alarms go off, or would you find out 10 days later?
