Introduction
This guide focuses on the technical security controls and notification requirements under the General Data Protection Regulation (GDPR) that organizations handling sensitive personal data must implement. It uses the enforcement decision against 23andMe following their April 2023 breach affecting 6.9 million people worldwide, including over 2,600 Spaniards, as a case study. You'll learn about specific GDPR articles violated, the technical failures that enabled the breach, and steps to prevent similar regulatory exposure. This isn't about 23andMe specifically. It's about the control gaps that turn credential stuffing into multi-million-euro fines.
Key GDPR Requirements
Article 32: Security of Processing
You must implement "appropriate technical and organisational measures" considering current technology, costs, and risks to data subjects' rights. For genetic data, the requirements are stricter.
Article 33: 72-Hour Notification Requirement
Notify your supervisory authority within 72 hours of becoming aware of a breach unless it's unlikely to risk rights and freedoms. The AEPD decision highlighted that 23andMe took 12 days to notify Spanish officials, emphasizing the importance of immediate notification for early mitigation.
Credential Stuffing vs. Traditional Breach
The attack vector matters. When attackers use compromised credentials from third-party breaches to access your systems, you can't claim a sophisticated hack. You failed to implement controls to prevent reused passwords from working.
IP-Based Rate Limiting
Implement controls to restrict login attempts, data access requests, or downloads from a single IP address within a defined time window. The AEPD specifically cited 23andMe's failure to implement these limits.
Requirements Breakdown
Article 32(1)(a): Pseudonymisation and Encryption
Encrypt personal data, especially genetic information. This includes:
- Transport layer encryption for data in motion
- Application-layer encryption for sensitive fields in databases
- Separate encryption key management from data storage systems
Article 32(1)(b): Ongoing Confidentiality and Resilience
Multifactor authentication (MFA) is essential. The AEPD decision noted 23andMe's lack of mandatory MFA as a major factor in the attack. Your implementation must include:
- Mandatory MFA for all user accounts
- Risk-based authentication for logins from new devices or locations
- Session management to terminate inactive sessions
Article 32(1)(d): Regular Testing and Evaluation
Document evidence of testing your security measures. The AEPD noted 23andMe's acknowledgment of risks without implementing basic controls. Acknowledging risk without mitigating it doesn't satisfy Article 32.
Article 33: Notification to Supervisory Authority
The 72-hour clock starts when you become "aware" of the breach. In 23andMe's case, executives learned about the breach from a Reddit post. That's your awareness trigger, not when your security team confirms the scope.
Your notification must include:
- Nature of the breach and categories of data subjects affected
- Likely consequences of the breach
- Measures taken or proposed to address the breach
Article 34: Communication to Data Subjects
When the breach is likely to result in high risk to data subjects' rights and freedoms, communicate directly to affected individuals. For genetic data breaches, assume high risk by default.
Implementation Guidance
Phase 1: Access Control Hardening (Week 1-2)
Start with authentication improvements.
- Mandatory MFA rollout: Use TOTP-based authenticators or hardware tokens. Avoid SMS-based MFA if possible.
- Password policy enforcement: Define minimum length, complexity requirements, and prohibit previously breached passwords.
- Rate limiting implementation: Set login attempt limits, API rate limits, and download volume limits per IP address.
Phase 2: Detection and Monitoring (Week 3-4)
- Anomaly detection for credential reuse: Monitor for patterns consistent with credential stuffing.
- Data access logging: Track who accessed what data, when, and from where.
Phase 3: Incident Response Preparation (Week 5-6)
- 72-hour notification playbook: Document your decision tree for breach notification.
- Communication templates: Pre-write your Article 34 data subject notifications.
Common Pitfalls
- Optional MFA: Mandate MFA for all users.
- Risk Acknowledgment Without Mitigation: Implement controls for documented risks.
- Notification Delay Rationalization: Notify regulators within 72 hours of breach awareness.
- Treating Credential Stuffing as Unforeseeable: Implement known mitigations like MFA and rate limiting.
- Inconsistent Privacy Policy: Ensure your privacy policy reflects your actual security controls.
Quick Reference Table
| GDPR Article | Requirement | 23andMe's Failure | Your Control |
|---|---|---|---|
| Article 32(1)(b) | Confidentiality and resilience | No mandatory MFA | Enforce MFA for all accounts |
| Article 32(1)(b) | Appropriate security measures | No IP-based rate limiting | Implement login attempt limits and download throttling |
| Article 32(1)(d) | Regular testing | Acknowledged risks without mitigation | Document risk assessments with corresponding controls |
| Article 33(1) | 72-hour notification | 12-day delay after awareness | Define "awareness" trigger and notification workflow |
| Article 5(1)(f) | Integrity and confidentiality | Inadequate password policy | Enforce strong passwords and check against breach databases |
The €2.4 million fine against 23andMe wasn't for failing to stop a sophisticated attack. It was for failing to implement basic controls that make credential stuffing difficult. Your supervisory authority expects you to know these threats exist and to deploy appropriate countermeasures. If your fiscal reports or board decks mention cyber risk, ensure your technical controls can withstand regulatory scrutiny.
