A private company's compromised access to Denmark's Central Population Register exposed 8.8 million records in September 2024. This breach affected more people than Denmark's entire living population because the register includes deceased individuals and those who've moved abroad. For data protection officers managing third-party access to sensitive databases, this incident highlights the risks when identification numbers become the primary security layer.
Scope: What This Guide Covers
This guide addresses access control architectures for systems where third parties need ongoing access to personal data registers. It covers specific requirements under GDPR Articles 5, 24, 25, 28, and 32, and suggests implementation patterns for identity verification that don't rely on identification numbers as authentication secrets.
This guide doesn't cover one-time data exports or processor relationships where the third party acts under your instructions. It's for scenarios where external entities access your database directly under their own controller responsibilities.
Key Concepts and Definitions
Identification vs. Authentication: An identification number (CPR, social security number, national ID) tells you who someone claims to be. Authentication proves they are that person. Denmark's breach occurred because a company's legitimate identification was sufficient for authentication.
Defined Group Access: Under section 38(1) of Denmark's Civil Registration System Act, private entities can access CPR data for "a defined group of people identified individually in advance." This isn't blanket access. Your access control system must enforce this boundary technically, not just contractually.
Appropriate Technical and Organizational Measures: Article 32 requires security "appropriate to the risk." When your database contains millions of records, relying on a single access credential creates disproportionate risk. The Danish incident demonstrates this: one compromised access point exposed 80% of the register's contents.
Requirements Breakdown
Article 5(1)(f): Integrity and Confidentiality
You must process personal data "in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing."
What this means for access control: If a third party's legitimate access can be "abused," your security measures weren't appropriate to the risk. You need technical controls that limit what an authenticated party can do, not just who can log in.
Article 24: Controller Responsibility
You're required to "implement appropriate technical and organizational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation."
What this means for third-party access: When you grant database access to external controllers, you remain responsible for demonstrating that your access architecture prevents unauthorized processing. The Danish ministry's access terms required recipients to be "legally entitled to process the information under the GDPR." That's a legal requirement, but Article 24 demands you enforce it technically.
Article 25(1): Data Protection by Design
Security measures must be implemented "at the time of the determination of the means for processing and at the time of the processing itself."
What this means for register architecture: If your system was designed when identification numbers were treated as secrets, it's not compliant by design for today's threat environment. Danish cybersecurity specialist Jan Kaastrup called treating CPR numbers as secrets a "broken" approach. Your architecture must assume identification numbers are public information.
Article 32: Security of Processing
You must implement measures including "the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services."
What this means for access logging: The CPR administration discovered "irregular activity during September" on October 2. That's a detection gap of weeks. Your logging architecture must surface anomalous access patterns within hours, not months.
Implementation Guidance
Multi-Factor Authentication for Database Access
Don't accept a company identifier or API key as sole authentication. Require:
- Organizational credential (company registration, API key)
- Individual credential (named user within that organization)
- Time-bound session tokens that expire and require re-authentication
This pattern means compromising one company's access doesn't grant unlimited querying. You know which individual made which queries.
Query Scope Enforcement
The Danish system allowed access to "a defined group of people identified individually in advance." Implement this technically:
- Pre-approved identifier lists: The third party submits a list of CPR numbers they're entitled to access. Your system rejects queries for identifiers not on their list.
- Rate limiting: Flag any access pattern that queries more records per hour than the approved scope justifies.
- Temporal restrictions: If a company needs quarterly access for payroll, their credentials should only work during defined processing windows.
Anomaly Detection That Triggers Lockout
The breach was discovered through "irregular activity." Build automated responses:
- Baseline normal usage: If a company typically queries 50 records per session, flag sessions exceeding 500.
- Geographic anomalies: If access normally originates from Danish IP ranges, block and alert on queries from unexpected countries.
- Automatic suspension: Don't wait for human review. Suspend access automatically when thresholds are crossed, then investigate.
Verification Beyond the Number
Kaastrup argued that "a number alone should not be accepted as proof of identity." For systems where third parties act on data subjects' requests, require:
- Out-of-band verification: If a company claims authority to access a citizen's record, send a notification to that citizen through a separate channel.
- Document verification: Require third parties to upload proof of legitimate interest (employment contract, service agreement) that you can audit.
Common Pitfalls
Pitfall 1: Treating legitimate access as permanent access
The unnamed Danish company had "legitimate access" under section 38(1). That doesn't mean permanent, unlimited access. Review and re-certify third-party access quarterly. Require organizations to confirm their processing purpose hasn't changed.
Pitfall 2: Logging access but not monitoring logs
The CPR administration had logs showing September activity, but didn't detect the breach until October 2. Logs are useless if nobody reviews them in real time. Use automated monitoring tools that alert on deviation from baseline patterns.
Pitfall 3: Assuming contractual terms prevent technical abuse
Denmark's access terms required recipients to be "legally entitled to process the information under the GDPR." The breach happened anyway. Contracts establish liability, but they don't prevent breaches. Your technical architecture must enforce what your contracts require.
Pitfall 4: Designing for yesterday's threat model
If your system was built when identification numbers were confidential, it's vulnerable today. Assume every identifier in your database is already public. Design authentication and authorization accordingly.
Quick Reference Table
| Requirement | Article | Technical Control | Detection Metric |
|---|---|---|---|
| Ensure appropriate security | 5(1)(f) | Multi-factor authentication for all third-party access | Failed authentication attempts per organization |
| Demonstrate compliance | 24 | Pre-approved identifier lists with technical enforcement | Queries rejected for out-of-scope identifiers |
| Data protection by design | 25(1) | Assume identifiers are public; layer additional authentication | Percentage of access requests requiring secondary verification |
| Ongoing confidentiality | 32 | Automated suspension on anomalous access patterns | Time from anomaly detection to access suspension |
| Integrity of processing | 5(1)(f) | Query scope limits tied to approved processing purpose | Queries per session vs. approved scope baseline |
| Accountability | 5(2) | Individual-level access logging within organizational accounts | Audit trail completeness for all queries |
When 8.8 million records leak through legitimate access, the problem isn't the access itself. It's the architecture that couldn't distinguish between authorized login and unauthorized extraction. Your access control system must enforce the principle that authentication proves identity, but authorization proves entitlement to specific data. Build both layers technically, not just contractually.
