When Burger King Japan disclosed a personal data breach on October 13, they had already spent six days knowing customer information had leaked. What they still didn't have: an answer to the most important question. How did the attackers get in?
What Happened
An unauthorized party accessed Burger King Japan's membership system between October 2 and October 7, compromising approximately 11.18 million customer records. The exposed data included names, email addresses, phone numbers, dates of birth, gender, member IDs, and prefectures of residence. The system also leaked registration types, email verification status, and mobile ordering flags.
The company blocked access from the suspected source and notified Japan's Personal Information Protection Commission. Credit card numbers weren't stored in the affected system, and BK Japan reported no confirmed cases of fraudulent use. But by the time they went public, they still hadn't identified the vulnerability that allowed the breach.
Timeline
- October 2-7: Unauthorized access to membership system
- October 13: Company determines customer information has leaked
- October 13: Disclosure to Personal Information Protection Commission
- October 14: Public disclosure (date of source article)
- Root cause: Not yet identified at time of disclosure
Which Controls Failed or Were Missing
The absence of a root cause makes this analysis provisional, but several control failures are already visible:
Access monitoring and alerting: Five days of unauthorized access suggests detection controls either didn't exist or didn't trigger appropriate alerts. Your membership system should flag unusual query patterns, bulk data exports, or access from unexpected IP ranges.
Data minimization: The breach exposed 11.18 million records containing birth dates, phone numbers, and residence prefectures. Ask yourself: does your loyalty program need a customer's birthday to function? Does it need their phone number if they've already verified an email address? Article 5(1)(c) requires that you collect only what's adequate, relevant, and limited to what's necessary. Every field you don't collect is a field that can't leak.
Retention controls: How many of those 11.18 million accounts were dormant? If you're storing profile data for customers who haven't logged in for two years, you're maintaining risk with no corresponding business value. Article 5(1)(e) requires you to keep personal data no longer than necessary. Your retention policy should automatically purge inactive accounts after a defined period.
Access segmentation: We don't know if the attackers compromised a single system or moved laterally across BK Japan's infrastructure. But the fact that one entry point exposed 11.18 million records suggests the membership database wasn't segmented. Your loyalty platform shouldn't share database credentials with your point-of-sale system. Your marketing team shouldn't have the same access level as your database administrators.
What the Relevant Standard Requires
Article 5(1)(f) requires you to process personal data "in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing." That's not a suggestion to install antivirus software. It's an obligation to implement controls proportionate to the risk.
Article 32 defines what "appropriate technical and organisational measures" look like. You need to consider the state of the art, implementation costs, and the nature and scope of processing. For a database holding 11.18 million records, that means:
- Encryption of personal data at rest and in transit
- Regular testing and evaluation of security effectiveness
- Procedures to restore availability after an incident
- Monitoring to detect unauthorized access attempts
Notice that Article 32 doesn't just require controls. It requires testing those controls. Your penetration test should attempt to exfiltrate customer records, not just scan for known CVEs.
Article 25 requires data protection by design and by default. That means your loyalty platform should ship with the minimum necessary access permissions, not administrator rights for every user. It means your database should enforce row-level security, not rely on application-layer access controls that attackers can bypass.
Lessons and Action Items for Your Team
Run a data inventory audit this quarter: List every field you collect in your loyalty program, CRM, or customer database. For each field, document the lawful basis, the business purpose, and the retention period. If you can't articulate why you need a customer's birthday, stop collecting it.
Implement automated retention policies: Your database should purge inactive accounts without manual intervention. Define "inactive" based on your processing purpose. If your loyalty program exists to reward repeat purchases, a customer who hasn't transacted in 24 months doesn't need a stored profile.
Separate your environments: Your production membership database shouldn't be accessible from your corporate network. Your developers shouldn't test code against live customer data. Create a segmented architecture where a compromised endpoint can't reach your most sensitive systems.
Test your detection capabilities: Schedule a tabletop exercise where your security team attempts to export customer records without triggering alerts. If they succeed, you'll find out in a conference room instead of a breach notification letter.
Review your third-party access: If your loyalty platform runs on a processor's infrastructure, you need to know what access controls they enforce and how they monitor for unauthorized queries. Article 28 requires you to choose processors that provide sufficient guarantees. "Sufficient" means you've verified their controls, not just reviewed their marketing materials.
Document your incident response procedures before you need them: BK Japan took six days to determine that customer information had leaked. Your playbook should define who investigates, who notifies the supervisory authority, and who communicates with affected individuals. You have 72 hours from becoming aware of a breach to notify your supervisory authority under Article 33. That timeline doesn't pause while you figure out your escalation chain.
The Burger King Japan breach won't be the last time a loyalty program leaks millions of records. But it doesn't have to be your loyalty program. The controls that would have reduced the impact, data minimization, retention limits, access segmentation, aren't exotic security measures. They're baseline GDPR obligations you should have implemented already.
