Denmark's Central Population Register (CPR) is the country's national civil registry. It holds names, addresses, dates of birth, marital status, and CPR identification numbers. Recently, the registry reported that a private Danish company's legitimate access was misused by threat actors to obtain data on roughly 8.8 million registered individuals, out of the 11 million in the system. The Danish Data Protection Agency stated that the attack involved brute-forcing to enumerate valid CPR numbers and extract related data.
The incident occurred in September 2026. CPR administration became aware of it on October 2, and the private company's access has since been blocked.
This incident raises a critical question for every controller that grants external access to large datasets: Should you keep broad access open for legitimate business partners and invest in monitoring, or should you restrict access to prevent bulk enumeration, even if it reduces operational convenience?
Evaluating Third-Party Access
This isn't about whether third-party access needs controls; it's about where the primary control should sit.
Approach A views third-party access as a manageable risk. You grant it under contract, relying on detection, auditing, and rapid revocation to catch abuse. Approach B treats bulk-queryable access as inherently unsafe, redesigning access so no single partner credential can reach an enumerable slice of the population.
Both approaches reference the same legal text. Article 32 GDPR requires appropriate technical and organizational measures, considering the state of the art, cost, and risks to individuals. Article 5(1)(f) requires integrity and confidentiality. Article 28 governs processors, and Article 25 mandates data protection by design and default. The debate centers on which obligation should take precedence when they conflict.
The Case for Approach A
Advocates for open-but-monitored access argue:
Legitimate use is valuable. Registries exist because organizations need to verify identities and addresses. Banks, utilities, insurers, and public bodies have lawful reasons to query population data. Over-restricting access can push these organizations toward workarounds, like maintaining shadow copies of the data, which might create more exposure than a controlled query interface.
Prevention has limits; detection is key. Every access control can eventually meet a compromised credential. Assuming this will happen, investment should focus on logging, anomaly detection, and fast revocation. In this case, once the breach was identified, the company's access was blocked.
Contracts and audits allocate accountability. Under Article 28, the controller must use processors providing sufficient guarantees and have binding agreements covering security, sub-processing, audit rights, and breach notification. Proponents argue that a well-run processor management program, with periodic audits and clear liability, is a proportionate response, and Article 32 allows you to weigh cost.
Over-engineering has costs. Complex tokenization and rate-limited gateways require budget and engineering time. For a mid-sized controller, this effort may be better spent on monitoring existing access.
The Case for Approach B
The counter-argument focuses on the incident's nature: enumeration. Brute-forcing valid identifiers is an attack on the access model, not on a single weak password.
Detection after the fact is inadequate for irreversible harm. A national identifier, once exposed, can't be rotated like a password. The delay between the incident and its discovery shows how much can happen before detection. Proponents of B argue that when harm is permanent, controls should prevent extraction rather than just notice it.
Bulk-queryable access violates data protection by design. Article 25 requires measures that ensure only necessary personal data is processed. A partner verifying one customer's address doesn't need an interface that can be walked across an entire identifier space. Alternatives include query volume ceilings per credential and lookups requiring a matching known attribute.
The partner is your attack surface. Your security is only as strong as the weakest credential holder. A contract can assign blame after an incident, but it can't prevent one. Article 5(2) makes the controller accountable, and accountability for a breach of this scale doesn't transfer to a processor simply because the processor held the credential.
Monitoring requires action. Logging is cheap; reviewing it is not. Many organizations collect partner access logs they never analyze.
Practical Implementation
In practice, few controllers choose a pure version of either approach. Experienced data protection officers (DPOs) suggest:
- Tier the access. Partners with low-volume needs get constrained interfaces. Those with bulk needs face stricter vetting, narrower field sets, and tighter contractual terms.
- Treat volume as a signal. Alerting on query rates and access patterns is seen as essential.
- Test the partner, not just the paper. Questionnaires meet Article 28 requirements, but evidence of how the partner protects credentials reduces risk.
- Rehearse revocation. The ability to quickly cut off a partner and track their access determines if you can notify within the 72 hours Article 33 allows after becoming aware.
DPOs differ on sequencing. Some prioritize monitoring for visibility across all partners, while others focus on redesigning high-risk interfaces first.
Our Take
Approach B should prevail for datasets containing permanent identifiers about large numbers of people. Detection is necessary, but it's the wrong primary control when harm can't be undone. If a single partner credential can enumerate your records, the design is the vulnerability, and an Article 28 contract doesn't fix a design problem.
However, A's critics shouldn't dismiss its practical point. Constrained interfaces require real engineering effort, and monitoring you can deploy now beats a redesign you'll finish later. The sensible path is to do both: use monitoring and revocation as an immediate safety net, and treat bulk-enumerable access as a defect to be engineered out.
For your program, start with one question: Can any single third-party credential retrieve a meaningful fraction of your records? If the answer is yes, you've found your first priority, and Article 25 says it belongs ahead of the next processor questionnaire.
