Denmark's Central Person Register breach, which exposed 8.8 million records through a company's lawful access, highlights a critical oversight: assuming authorized access is inherently safe. This checklist will help you audit and strengthen your third-party access controls for systems holding sensitive personal data.
Checklist Overview
This audit targets access granted under legal bases such as legitimate interest, contractual necessity, or Legal Obligation. It's relevant for systems where external parties query or extract personal data through APIs, portals, or direct database connections. If you manage a civil registry, healthcare database, credit bureau, or similar system, these controls are crucial for your risk management.
Prerequisites
Before starting this audit:
- Document all active third-party access grants. Maintain an inventory showing which entities access what data, under which legal basis, and through which technical mechanism.
- Identify your lawful basis register. Each access grant should map to Article 6(1) GDPR (or equivalent under your jurisdiction's framework).
- Confirm you have logging infrastructure. Ensure query logs, authentication events, and data extractions are captured and retained according to your Retention Rule.
Checklist Items
1. Access Provisioning Review
Check: Every third party with system access has a documented, current legitimate interest assessment or alternative lawful basis.
Requirement: Article 6(1)(f) GDPR requires balancing your interests against data subjects' rights. For civil registries operating under national law, verify compliance with your jurisdiction's specific access provisions.
Good looks like: A register showing company name, access scope, legal basis, approval date, and review date. The Danish CPR incident occurred because a company maintained access it used for unauthorized purposes. Your register should include use-case limitations, not just entity names.
2. Authentication and Authorization Controls
Check: Access uses cryptographic authentication (not shared credentials) and enforces role-based or attribute-based access policies.
Requirement: ISO/IEC 27001 Control A.9.2.1 (user registration and deregistration) and A.9.4.1 (information access restriction).
Good looks like: Each third party authenticates via API keys rotated every 90 days, client certificates, or Security Assertion Markup Language federation. Authorization policies limit queries to specific data categories and record counts per time window.
3. Query Rate and Volume Limits
Check: Technical controls prevent bulk extraction beyond legitimate use cases.
Requirement: Technical and Organisational Measures under Article 32 GDPR must include measures to detect and prevent unauthorized processing.
Good looks like: API rate limits set per access grant. A company authorized to verify ten addresses daily can't extract thousands of records without triggering alerts. The CPR breach was discovered through "abnormal behavior" detection, but only after exfiltration occurred.
4. Real-Time Anomaly Detection
Check: Automated monitoring flags access patterns inconsistent with documented use cases.
Requirement: Article 32(1)(d) GDPR requires procedures to test and evaluate security effectiveness regularly.
Good looks like: Rules that trigger alerts when a third party queries records outside their geographic scope, accesses deceased individuals' data without documented need, or shows sudden volume spikes. Alerts go to a monitored queue with defined response procedures.
5. Access Audit Trail
Check: Logs capture who accessed which records, when, and for what stated purpose, with retention aligned to your breach register requirements.
Requirement: Article 30 GDPR (records of processing activities) and your jurisdiction's breach notification timeline. Denmark's 72-Hour Notification requirement means you need immediate log access during incident response.
Good looks like: Structured logs showing timestamp, authenticated entity, query parameters, record count returned, and purpose code. Logs are immutable, stored separately from production systems, and retained for at least the duration of your supervisory authority's investigation window (typically 12-24 months).
6. Deprovisioning Procedures
Check: Access termination happens immediately when the legal basis expires or the third party's legitimate interest ends.
Requirement: Article 5(1)(e) GDPR (storage limitation) implies you can't permit access longer than necessary.
Good looks like: Calendar reminders for access review dates, with automated suspension if renewal isn't documented. When CPR "immediately terminated the private company's access" after discovering the breach, that capability existed because someone built it. You need the same kill switch.
7. Contractual Controls
Check: Access agreements include security obligations, audit rights, breach notification timelines, and liability for misuse.
Requirement: Article 28 GDPR processor requirements apply by analogy even when third parties aren't formal processors.
Good looks like: Contracts stating the third party will notify you within 24 hours of suspected unauthorized access, submit to annual security audits, and maintain insurance covering data breach costs. After the CPR incident, the Danish Data Protection Agency will scrutinize these agreements. Yours should withstand similar review.
8. Periodic Access Recertification
Check: Someone with authority reviews and reapproves each access grant at least annually.
Requirement: ISO/IEC 27001 Control A.9.2.5 (review of user access rights).
Good looks like: A workflow requiring business owners to confirm continued need, updated use cases, and compliance with original approval terms. Access expires automatically if recertification isn't completed within 30 days of the review date.
Common Mistakes
Treating lawful access as permanent. Legal bases change. A company's legitimate interest for address verification doesn't justify accessing 8.8 million records. Revalidate scope annually.
Logging without alerting. The CPR breach was discovered through abnormal behavior detection, but only after significant exfiltration. Logs are evidence, not controls. You need real-time alerts with response playbooks.
Granting database-level access. Direct database connections bypass application-layer controls. Require third parties to use APIs with enforced rate limits and field-level access restrictions.
Assuming compliance equals security. A company accessing CPR under Denmark's Data Protection Regulation still caused a breach. Legal authorization doesn't guarantee the third party has adequate security controls.
Next Steps
Run this checklist within 30 days. For each failed item, document the gap, assign an owner, and set a remediation deadline. Prioritize items 3, 4, and 6 (technical controls preventing bulk extraction) if you manage a registry or database with broad third-party access.
If you discover access grants without documented legal basis or technical controls, suspend them immediately and conduct a Prior Consultation with your supervisory authority before restoring access. The CPR incident demonstrates that "lawful" access becomes unlawful the moment it's misused.
Your Notification to Supervisory Authority obligation under Article 33 GDPR starts when you become aware of a breach. Don't wait for external notification like CPR did. Build the detection controls now.
