Around 1500 UK charities recently discovered they'd outsourced their data protection obligations to a CRM provider with inadequate access controls. The Beacon incident didn't compromise payment card details or patient records, but it exposed names, email addresses, phone numbers, and donation histories, data that can enable targeted fraud and donor impersonation.
The breach itself was contained. The real failure occurred months or years earlier, when procurement teams signed contracts without asking the right questions and DPOs inherited processor relationships they couldn't properly oversee.
Why These Mistakes Keep Happening
Third-party risk management often fails because it's treated as a procurement checkbox rather than an ongoing compliance obligation. You might inherit a processor relationship from a previous DPO or a department that signed a contract without consulting legal. The onboarding questionnaire is forgotten. You've never seen the processor's actual appropriate technical and organisational measures, and you wouldn't know what to look for if you did.
Article 28 GDPR requires you to use only processors that provide "sufficient guarantees" to implement appropriate technical and organizational measures. This isn't a one-time assessment. It's a continuous obligation that many organizations fail to meet because they confuse contractual compliance with operational reality.
Mistake 1: Treating the Article 28 Contract as the Control
You have a signed data processing agreement. It includes all the required Article 28(3) clauses: instructions for processing, confidentiality commitments, security obligations, sub-processor notification rights. Legal approved it. You filed it.
That contract doesn't protect a single record.
Why it happens: Procurement teams and legal counsel focus on contractual liability transfer. If the processor breaches, you can point to the contract and argue you did your part. The contract becomes a shield against regulatory criticism rather than a mechanism for actual oversight.
The consequence: When Beacon observed a "spike in activity" indicating data exfiltration, 1500 charities discovered their contractual protections were irrelevant. The data was already gone. The contract gave them the right to sue or terminate, but it didn't prevent the unauthorized access that triggered their own notification obligations under Article 33.
The fix: Separate contractual compliance from operational assurance. Your Article 28 contract establishes the legal framework. Your processor risk program validates that the processor actually implements what the contract requires. That means:
- Annual security attestations (SOC 2, ISO 27001, or equivalent)
- Evidence of encryption at rest and in transit, not just contractual promises
- Documented access control policies and audit logs you can request
- Incident response procedures that include controller notification timelines
- Regular penetration testing results or vulnerability scan summaries
If your processor can't provide these, you don't have "sufficient guarantees" under Article 28(1), regardless of what the contract says.
Mistake 2: Skipping the Encryption Verification
Beacon told customers their data was stored in an encrypted state but that the unauthorized actor may have been able to decrypt it. That suggests encryption was present but ineffective, possibly because the attacker obtained both the encrypted data and the decryption keys.
Why it happens: You ask vendors if they encrypt data. They say yes. You check the box. You never ask about key management architecture, rotation policies, or whether application-layer access bypasses encryption controls entirely.
The consequence: Encryption protects data at rest from physical theft or database dumps. It doesn't protect against an attacker who compromises the application layer with valid (or stolen) credentials. If the application can decrypt data to display it to users, and the attacker has application access, your encryption didn't fail, it was simply irrelevant to the attack vector.
The fix: Ask specific questions:
- Where are encryption keys stored, and who has access?
- Are keys rotated, and what's the rotation schedule?
- Does the application decrypt data in memory for processing?
- What happens if someone compromises an administrator account?
For high-risk processing (health data, special category data, large-scale profiling), consider processors that offer client-side encryption or tokenization, where your organization controls the keys and the processor never has access to plaintext data. This wasn't feasible for a CRM platform like Beacon, but it's worth evaluating for specific data categories.
Mistake 3: Assuming Breach Notification is the processor's Job
Beacon told its customers: "If you were storing data about people in your Beacon account, it is likely to have been downloaded and as such you need to evaluate whether you must in turn notify the people you store in Beacon."
That's correct. The charities are controllers. Beacon is their processor. Article 33(2) requires processors to notify controllers "without undue delay" after becoming aware of a personal data breach. But Article 33(1) puts the 72-hour notification obligation on the controller, not the processor.
Why it happens: Organizations assume that if the processor's systems were breached, the processor handles notifications. They don't realize that processor notification to the controller is separate from controller notification to the supervisory authority and data subjects.
The consequence: Charities affected by the Beacon incident had to report the breach to the ICO themselves. Many likely missed the 72-hour window because they were waiting for complete information from Beacon or didn't understand their independent obligation.
The fix: Your incident response plan must account for processor-originated breaches:
- Contractually require processor notification within 24 hours of discovery (tighter than "without undue delay")
- Maintain an internal decision tree: when you receive processor notification, who assesses supervisory authority notification requirements, and what's the escalation path?
- Pre-draft processor breach templates that you can adapt quickly (you won't have time to write from scratch inside 72 hours)
- Identify which processor relationships involve high-risk data that would trigger Article 34 individual notification requirements
You can't outsource the Article 33 clock. It starts when the processor tells you, not when you've finished investigating.
Mistake 4: Ignoring Access Control Architecture in processor Systems
The Beacon breach involved a "compromised access key" that was "more sophisticated than a simple compromised username and password." That suggests an API key, service account credential, or similar programmatic access token.
Why it happens: You review processor access controls for employee accounts, multi-factor authentication, role-based permissions, password policies. You don't ask about API keys, service accounts, or machine-to-machine authentication, because those aren't visible in the user interface.
The consequence: Many breaches exploit non-human credentials: API keys committed to public repositories, service account tokens with excessive permissions, OAuth tokens that don't expire. These credentials often bypass the MFA and monitoring controls you verified during processor assessment.
The fix: Expand your processor security reviews to include:
- How are API keys and service accounts managed and rotated?
- Do programmatic credentials have the same access logging as user accounts?
- What's the process for revoking compromised keys?
- Are there separate keys for development, staging, and production environments?
For critical processors, request evidence of their privileged access management program. If they can't demonstrate how they prevent, detect, and respond to credential compromise, you're exposed.
Mistake 5: Treating All Processors as Equal Risk
Your procurement team uses the same processor assessment questionnaire for your CRM provider, your email service, your analytics platform, and your office supply processor that processes employee expense addresses.
Why it happens: Standardized processes scale efficiently. Creating risk-tiered processor programs requires ongoing classification, resource allocation, and difficult conversations about which vendors get deeper scrutiny.
The consequence: You spend the same effort reviewing a low-risk processor that handles pseudonymized web analytics as you do reviewing a processor that stores donation records for 1500 organizations. Or worse, you spend minimal effort on both and miss critical risks in your highest-impact processor relationships.
The fix: Classify processors by data sensitivity and volume:
Tier 1 (high risk): Special category data, large-scale profiling, data that would trigger Article 34 individual notification if breached. Annual audits, quarterly security reviews, right to on-site assessment.
Tier 2 (moderate risk): Regular personal data, limited volume or scope. Annual attestation review, incident response testing.
Tier 3 (low risk): Pseudonymized data, aggregated data, minimal personal data. Standard contractual terms, notification on security incidents.
Beacon would be Tier 1 for most charities. Your office supply processor is Tier 3. Allocate your oversight resources accordingly.
Prevention Checklist
Before you sign with a new processor:
- Confirm they can provide current security attestation (SOC 2 Type II, ISO 27001, or equivalent)
- Request their incident response plan and controller notification procedure
- Verify encryption implementation and key management architecture
- Review their sub-processor list and approval process
- Confirm they carry cyber insurance with appropriate coverage limits
For existing processor relationships:
- Classify all processors by data sensitivity and volume (Tier 1/2/3)
- Obtain annual security attestations for Tier 1 processors
- Document your Article 33 notification process for processor-originated breaches
- Test your ability to execute controller notification within 72 hours of processor alert
- Schedule quarterly reviews of Tier 1 processor security posture
- Maintain an up-to-date register of what data each processor holds
The Beacon incident contained no payment card details and no patient records, but it still triggered notification obligations for 1500 organizations. Your processor contracts won't prevent breaches. Your oversight program might.
