A password of "123456" and approximately 14 million automated searches. That's what Denmark's investigation revealed after 8.8 million registry records were exposed through a third-party company's legitimate credentials. The breach wasn't sophisticated, it was preventable.
If you're responsible for managing third-party access to sensitive databases, you're facing a decision that most organizations defer until after an incident: how much access should external partners actually have?
The Decision You're Facing
You need to grant database access to an external partner, a processor performing identity verification, a contractor building an integration, or a service provider handling customer inquiries. The question isn't whether to grant access. It's how to structure that access so a compromised account can't extract millions of records before you notice.
This isn't about choosing between "secure" and "insecure." You're choosing between access models that determine what happens after credentials are stolen or misused.
Key Factors That Affect Your Choice
Three variables shape your decision:
Data sensitivity and volume. A processor verifying individual customer identities needs different permissions than one requiring bulk analytics. The Denmark breach involved a company authorized to search the Central Register of Persons, a database containing approximately 11 million records covering current residents, deceased individuals, and former residents.
Query patterns you can predict. If your processor typically processes 50 lookups per day, you can detect 14,000 searches in 24 hours. If query volume varies unpredictably, behavioral monitoring becomes harder.
Your detection capabilities. Rate limiting only works if you're monitoring it. Database activity alerts only help if someone reviews them. The Denmark incident was reportedly discovered through unusually high billing charges, a financial signal, not a security control.
Path A: API-Only Access with Rate Limiting
Choose this when: Your processor needs programmatic access to verify or retrieve specific records, but you can define normal usage patterns.
How it works: The processor authenticates through an API with strict rate limits. They can query individual records but cannot execute bulk searches or access administrative functions.
Requirements you must meet:
Set hard limits on queries per hour and per day. If a legitimate use case requires 100 lookups daily, cap the API at 150 and alert at 120.
Implement request throttling that slows or blocks rapid sequential queries. The Denmark incident involved automated searches, code that an expert assessment suggested was AI-generated. Throttling won't stop a determined attacker, but it buys you detection time.
Log every query with timestamp, account identifier, and search parameters. You need this audit trail for Article 32 compliance (appropriate technical and organizational measures) and for investigating anomalies.
When this path fails: If your processor's legitimate needs genuinely require bulk access, artificial rate limits will force them to request exceptions until the control becomes meaningless.
Path B: Role-Based Access with Mandatory Human Review
Choose this when: The processor needs broader permissions, but you can require human oversight for sensitive operations.
How it works: Create processor-specific roles that separate read, write, and administrative privileges. Require two-person authorization for bulk exports or administrative changes.
Requirements you must meet:
Define roles based on actual job functions, not convenience. The Denmark breach reportedly involved compromised Pays ApS accounts, including an administrator account using "123456" as a password. Administrator privileges should never be the default.
Enforce phishing-resistant multifactor authentication on all processor accounts. Denmark's Data Protection Agency is investigating how the breach occurred. Password-only authentication for database access is indefensible under Article 32.
Establish approval workflows for any query returning more than a defined threshold of records. If a processor account requests 1,000 records at once, someone on your team should review and approve it before execution.
When this path fails: If you lack the internal resources to review processor requests promptly, approval workflows create operational delays that pressure you to weaken controls.
Path C: Isolated Environment with Data Minimization
Choose this when: The processor needs analytical access or testing capabilities but doesn't require live production data.
How it works: Provide access to a separate environment containing pseudonymized or synthetic data that preserves statistical properties without exposing actual personal information.
Requirements you must meet:
Pseudonymize personal identifiers before replication. Names, addresses, and national identification numbers (like Denmark's CPR numbers) should be replaced with consistent but unlinkable tokens.
Implement technical controls that prevent re-identification. If your processor can correlate pseudonymized records with external data sources to identify individuals, you haven't achieved meaningful protection.
Monitor for attempts to access production systems. Vendors with isolated environment access should have no credentials for live databases.
When this path fails: If the processor's function requires verifying actual identities or updating real customer records, synthetic data won't work. You can't verify someone's CPR number against a pseudonymized test database.
Path D: Just-In-Time Access with Continuous Monitoring
Choose this when: processor access is infrequent but unavoidable, and you have mature security operations capabilities.
How it works: processor credentials are disabled by default. Access is provisioned on request for a defined time window and automatically revoked when the window expires.
Requirements you must meet:
Implement automated provisioning and de-provisioning tied to approved tickets. Access that requires manual re-enabling is access that will be left enabled "temporarily" until it becomes permanent.
Deploy database activity monitoring that baselines normal behavior and alerts on deviations. The approximately 14 million searches in the Denmark incident should have triggered immediate investigation, not discovery through billing anomalies weeks later.
Establish clear escalation procedures. Alerts are worthless if no one is responsible for investigating them within a defined timeframe.
When this path fails: If your processor needs continuous access to perform their contracted services, just-in-time provisioning creates friction that doesn't match the operational reality.
Summary Matrix
| Access Model | Best For | Primary Control | Detection Method | Weakest Against |
|---|---|---|---|---|
| API with rate limits | Predictable, low-volume queries | Hard query caps | Threshold alerts | Legitimate high-volume needs |
| Role-based with approval | Varied access needs | Least privilege + human review | Approval logs | Resource constraints for review |
| Isolated environment | Analytics, testing, development | Data minimization | Production access attempts | Identity verification requirements |
| Just-in-time access | Infrequent, necessary access | Time-bounded credentials | Behavioral monitoring | Continuous operational needs |
The Denmark breach demonstrates what happens when none of these models are enforced. A third-party company had legitimate access. That access was reportedly protected by "123456." And approximately 14 million automated searches occurred before the activity was detected.
Your choice isn't about eliminating third-party access. It's about ensuring that when credentials are compromised, and they will be, the damage is contained by design, not discovered by accident.
Which path matches your processor's actual needs and your detection capabilities? That's the decision. Make it before your supervisory authority asks why you didn't.
