The Conventional Wisdom
When 8.8 million CPR records in Denmark were accessed without authorization, the immediate response was predictable: tighten third-party access controls. Conduct more processor assessments. Add another layer of approval workflows. The minister called for a security review, and every privacy officer reading about it mentally added "audit processor access" to their Q4 priorities.
This reaction assumes the fundamental problem is third-party access itself. If we just screen vendors better, monitor their activity more closely, and limit what they can see, we'll prevent the next incident. It's a comforting narrative because it gives us something concrete to fix.
The Real Issue
The Denmark incident didn't happen because a company had access to the CPR. It happened because someone misused that company's legitimate access credentials. The company was entitled to query specific records under Danish law. The access wasn't excessive or poorly justified. The controls that failed weren't at the processor selection stage but at the authentication and authorization stage.
Framing this as a "third-party risk" problem obscures what actually broke: the system couldn't distinguish between the legitimate company using its own credentials and unauthorized parties using those same credentials. Adding more processor due diligence questionnaires won't fix that. Neither will more restrictive data processing agreements.
Your third-party risk program exists to ensure processors and joint controllers meet their Article 28 and Article 26 obligations. It's not designed to prevent credential compromise or insider misuse. Those are access control and monitoring problems that live in your technical architecture, not your processor contracts.
The Evidence
Look at what Denmark's authorities actually said. The unauthorized access occurred "within the categories of information available to private companies through the CPR system." The company's access was lawful under Danish legislation. They had a legitimate interest to obtain register information about defined groups of people they'd already identified individually.
The failure point wasn't the scope of access. It was the inability to detect that the access pattern didn't match the company's stated purpose. Someone queried 8.8 million records when the company's legitimate interest likely covered a much smaller population. That gap should have triggered an alert on Friday evening, not over the weekend after irregular activity was noticed.
Your Article 32 obligation to implement appropriate technical and organisational measures includes "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." That means your monitoring needs to catch anomalous behavior in real-time, not just verify that your processor signed the right contract clauses.
Consider what real-time monitoring would look like here. If a company typically queries 500 records per month and suddenly pulls 8.8 million, your system should halt the request and require manual authorization. If queries usually happen during business hours and suddenly spike at 2 AM, that's a detection event. If the same credentials access records from two different IP addresses simultaneously, that's impossible without credential sharing or compromise.
None of these controls require you to trust your third parties less. They require you to verify their behavior continuously.
What to Do Instead
Stop adding steps to your processor onboarding process and start instrumenting your access logs. Your Article 30 records of processing activities should document who has access to what categories of personal data. Your Article 32 security measures should detect when that access deviates from documented patterns.
Build access controls that enforce purpose limitation technically, not just contractually. If a processor's legitimate purpose is to verify employment history for 200 candidates per month, configure their API access to reject bulk queries above that threshold. If they need more, they request an exception and document the lawful basis.
Implement behavioral baselines for every third-party integration. Track query volume, timing, record types accessed, and geographic origin. When behavior shifts outside normal parameters, your system should require additional authentication or human review before proceeding.
Segregate credentials by purpose. Don't give a single API key access to your entire data estate. If a company needs CPR data for address verification and separate access for employment checks, issue separate credentials with separate scopes. When one is compromised, you've contained the exposure.
Review your Article 33 breach notification procedures with this scenario in mind. Denmark's authorities detected irregular activity on Friday evening but didn't establish the scope until the weekend. Your 72-hour notification clock starts when you become aware of the breach, but "aware" means you've established that a breach likely occurred. Make sure your detection systems can quantify scope quickly enough to meet that deadline.
When the Conventional Wisdom Is Right
Third-party risk management still matters. Your Article 28 processor agreements need to specify security requirements, audit rights, and breach notification timelines. Your due diligence should verify that processors have their own access controls and monitoring.
If Denmark's investigation reveals that the company whose access was misused had inadequate credential management or failed to detect that unauthorized parties were using their access, then yes, processor selection failed. If they didn't have multi-factor authentication, didn't rotate credentials, or didn't monitor their own API usage, those are gaps your due diligence should catch.
The conventional wisdom is also right that you can't outsource accountability. As controller, you're responsible for processor security under Article 32, regardless of what your contract says. If your processor's credentials get compromised and you had no technical controls to detect misuse, you've failed your obligation to implement appropriate measures.
But don't let processor management become a substitute for access control. The Denmark incident shows what happens when we rely on contracts to enforce technical requirements. The company had a legitimate contract. The access was lawful. The credentials worked exactly as designed. And 8.8 million records were accessed without authorization anyway.
Your next security review shouldn't ask whether your vendors are trustworthy. It should ask whether your systems can detect when trustworthy vendors' credentials are being misused. That's the gap Denmark is now scrambling to close.
