Should You Grant Bulk Access to Your Registry?

A small Danish company had legal access to Denmark's Central Register of Persons. For about 10 days in September 2026, attackers used that access to query 8.8 million records. The system charged per lookup, and nobody noticed until the invoice arrived.

You're facing a similar decision: an external partner needs programmatic access to your customer database, HR system, or identity registry. They have a legitimate business reason, and your legal team has approved the contract. The question isn't whether to grant access. It's how much access, under what controls, and with what monitoring.

The Decision You're Facing

You need to choose between three access models for third parties querying your sensitive registry:

• Batch file delivery: You extract and deliver a static dataset on a schedule.
• Controlled API access: The partner queries your system through rate-limited, logged endpoints.
• Bulk lookup privileges: The partner can query any record in your system at will.

Each option involves different operational costs, breach exposure, and Article 32 GDPR obligations for "appropriate technical and organisational measures."

Key Factors That Affect Your Choice

Data sensitivity and volume. The Danish CPR system contained 11 million records, including names, addresses, and unique national identifiers. If your registry contains special category data under Article 9 GDPR or identifiers that enable account takeover, bulk access creates concentrated risk. A single compromised credential becomes a skeleton key.

Contractual purpose specificity. Denmark's Civil Registration Act allowed companies to look up "groups of identified individuals, for a stated purpose." If your data processing agreement specifies "verify employment status for 200 named applicants," bulk lookup access exceeds the purpose limitation requirement in Article 5(1)(b) GDPR.

Your detection capability. The CPR system wasn't monitored. Officials discovered the breach only when they noticed "irregular behavior" that generated a very large invoice. If you can't detect 8.8 million queries in 10 days, you can't grant query-level access. Your monitoring infrastructure determines which paths are viable.

The partner's security posture. The Danish breach didn't exploit a vulnerability in the CPR system itself. Attackers compromised the small company's credentials and used legitimate access rights. Your assessment must include: Does the partner enforce multi-factor authentication? Do they log access from their side? Can they detect credential compromise within hours, not weeks?

Path A: Batch File Delivery

Choose this when: The partner's need is periodic (monthly reconciliation, quarterly audits), the dataset is definable in advance, or your registry contains high-risk data that can't tolerate real-time query exposure.

How it works: You run an extract against specific criteria, encrypt the file, deliver it through secure transfer, and log the transaction. The partner processes locally. You retain full control over timing, scope, and revocation.

Article 32 requirements you satisfy:

• Pseudonymisation where possible (you can strip or hash fields before delivery).
• Ability to restore availability after an incident (you control the source).
• Regular testing of measures (you audit each extract before release).

What you sacrifice: Real-time data access. If the partner needs current information for fraud checks or identity verification, batch delivery introduces lag that may undermine the business purpose.

Monitoring obligation: Track extract frequency, record counts, and recipient confirmation. Under Article 30 GDPR, your processing record must document "categories of recipients" and "transfers to a third country." Each batch delivery is a processing event.

Path B: Controlled API Access

Choose this when: The partner needs real-time lookups, you can define rate limits that match legitimate use, and you have logging infrastructure that captures query patterns in near-real-time.

How it works: The partner authenticates to your API, submits queries with specific identifiers, and receives responses. You enforce per-minute rate limits, require query justification fields, and alert on anomalies. API authentication must include token expiration, IP allowlisting, and anomaly detection.

Article 32 requirements you satisfy:

• Ability to ensure confidentiality (TLS in transit, token-based auth, query logging).
• Ongoing monitoring of effectiveness (you track query volume, response times, error rates).
• Restriction of access to only what's necessary (rate limits enforce proportionality).

Detection thresholds you need:

• Alert when a single token queries more than X records per hour (set X based on documented use cases).
• Flag queries outside business hours unless pre-authorized.
• Block after three failed authentication attempts.
• Require re-authentication every N hours.

If you can't implement these controls, don't offer API access. The Danish CPR breach ran for 10 days because "the system was not monitored."

Path C: Bulk Lookup Privileges (High-Risk Path)

Choose this when: Never, unless you're legally required to grant it and can implement continuous behavioral monitoring.

Denmark's Civil Registration Act mandated access for companies with stated purposes. You may face similar legal obligations for credit bureaus, background check providers, or regulatory reporting. If you must grant bulk access, treat it as High-Risk Processing under Article 35 GDPR and conduct a Data Protection Impact Assessment before activation.

Mandatory controls if you choose this path:

• Break-Glass Access logging: Every query must capture timestamp, querying user, IP address, and stated purpose code.
• Behavioral baselines: Establish normal query patterns for each partner (records per day, peak hours, common search parameters). Alert when current behavior exceeds baseline by more than 20%.
• Invoice-based detection is too slow: You need real-time cost tracking if you charge per query.
• Immediate revocation capability: You must be able to disable access within minutes of detecting anomalies, not days.

Summary Matrix

The Danish breach exploited a monitoring gap, not a technical vulnerability. Your choice isn't just about access architecture. It's about whether you can detect misuse before the invoice arrives.

If you can't monitor in real time, don't grant real-time access. Article 32(1)(d) GDPR requires "a process for regularly testing, assessing and evaluating the effectiveness" of your measures. A 10-day detection window fails that test.