When Capcom disclosed a breach affecting over 11 million customer accounts, the security community didn't just scrutinize what happened. They watched how the company communicated, what technical measures failed, and which assumptions about breach response proved wrong.
Most organizations build their incident response plans on inherited wisdom that hasn't been stress-tested. These myths persist because they sound reasonable in a conference room, but they collapse under the pressure of a real personal data breach. Let's examine what actually matters when you're managing unauthorized access to customer data.
Myth 1: "We'll figure out communication when we know the full scope"
Reality: Waiting for complete information before notifying affected individuals violates your Article 34 obligations and destroys trust.
Under GDPR, you have 72 hours to notify your supervisory authority of a personal data breach likely to result in high risk to individuals' rights and freedoms. That clock starts when you become aware of the breach, not when you've completed forensics. For direct communication with data subjects, you must act "without undue delay" when the breach poses high risk.
Capcom's approach demonstrates the practical middle ground. They disclosed the breach affecting 11 million accounts while investigations continued, then provided updated details as they learned that 196 accounts experienced unauthorized password changes. This staged disclosure meets regulatory requirements while acknowledging uncertainty.
Your communication plan should include templated notifications for different breach scenarios. Draft language that acknowledges what you know, what you're investigating, and what protective steps you're taking. Saying "we're still determining the full extent" is acceptable. Going silent for weeks while you investigate is not.
Myth 2: "Password resets solve the unauthorized access problem"
Reality: Resetting compromised credentials is necessary but insufficient. You need to understand how the access occurred and close that vector.
When Capcom reset passwords for the 196 accounts that experienced unauthorized changes, they addressed the immediate symptom. But the underlying question remains: how did attackers change those passwords in the first place? Did they exploit a vulnerability in the password reset flow? Bypass authentication controls? Use stolen session tokens?
Your incident response plan must distinguish between containment actions (resetting passwords, revoking tokens) and remediation (fixing the vulnerability that allowed the breach). Article 32 requires you to implement appropriate technical and organizational measures to ensure security appropriate to the risk. If you don't identify and close the attack vector, you haven't met that obligation.
Document your technical investigation process: What authentication controls were in place? Were rate limiting or IP reputation checks active? Did you log suspicious password reset attempts? The answers inform both your Article 33 notification to the supervisory authority and your Article 34 communication to affected individuals about what steps you're taking to prevent recurrence.
Myth 3: "If we didn't store sensitive data, the breach isn't high-risk"
Reality: Even seemingly low-sensitivity data creates risk when combined with breach context and potential secondary attacks.
Capcom's breach exposed account creation dates, login timestamps, login frequency, and IP addresses. None of these individually constitute special category data under Article 9. But this combination enables targeted phishing campaigns, account enumeration, and social engineering attacks.
The breach exposed 43 records that included birthdates, nicknames, gender, and country information. While limited in scope, this subset creates identity theft risk. More importantly, the organization explicitly warned users about phishing threats following the incident, acknowledging that even basic account metadata becomes weaponized in attackers' hands.
When you're conducting your Article 34 assessment of whether a breach is "likely to result in high risk," don't evaluate data elements in isolation. Consider:
- Can this data enable follow-on attacks?
- Does it reveal patterns (login times, locations) that expose individuals?
- Will threat actors use it to make phishing attempts more convincing?
The phishing risk is particularly relevant. When attackers know someone has a Capcom account, they can craft targeted emails referencing the breach, creating urgency around "verifying your account" or "confirming your details." Your breach notification should pre-empt these tactics by telling individuals exactly how you'll communicate with them and what you'll never ask for.
Myth 4: "Our incident response plan covers GDPR requirements"
Reality: Most incident response plans focus on IT recovery, not regulatory obligations and data subject rights.
Your security team's runbook probably covers containment, forensics, and system restoration. But does it address:
- Who drafts the Article 33 notification to your supervisory authority within 72 hours?
- How you'll document your decision-making process for the supervisory authority?
- Which team manages Article 34 communications to affected individuals?
- How you'll handle the surge of DSARs that typically follow breach disclosure?
After a breach, you should expect affected individuals to exercise their Article 15 right of access, asking exactly what data you held about them and whether it was compromised. You'll also likely face Article 17 erasure requests from individuals who no longer trust you with their data. Your incident response plan needs defined ownership for these requests and realistic timelines that account for your Article 12 obligation to respond within one month.
Build a cross-functional response team before you need it. Your data protection officer (if you have one), legal counsel, security team, communications lead, and customer support must know their roles. Run tabletop exercises that include regulatory notification scenarios, not just technical recovery.
Myth 5: "We can assess our security posture internally"
Reality: Internal teams develop blind spots, and supervisory authorities expect independent validation of your Article 32 measures.
Regular security audits aren't just a good idea. They're evidence that you're meeting your Article 32 obligation to ensure appropriate security. When a breach occurs, your supervisory authority will ask what technical and organizational measures you had in place and how you validated their effectiveness.
Internal assessments miss the attack vectors you haven't considered. They're conducted by people who designed the systems and therefore share the same assumptions. External penetration testing, security audits, and architecture reviews surface the gaps you didn't know existed.
Document your audit findings and remediation timelines. If a vulnerability was identified but not yet fixed when a breach occurred, you'll need to explain why to your supervisory authority. "We were planning to address it next quarter" won't satisfy Article 32's requirement for security appropriate to the risk.
What to do instead
Start with an honest assessment of your current incident response capability. Can you notify your supervisory authority within 72 hours of becoming aware of a breach? Do you have templated communications ready for affected individuals? Have you identified which breaches would trigger Article 34 notification requirements?
Build your cross-functional response team now. Define who drafts regulatory notifications, who communicates with affected individuals, and who manages the expected surge in data subject rights requests. Run quarterly tabletop exercises that include regulatory scenarios, not just technical recovery.
Schedule external security audits at least annually. Treat audit findings as your roadmap for closing vulnerabilities before they're exploited. Document your remediation progress so you can demonstrate to your supervisory authority that you're actively maintaining appropriate security measures.
Most importantly, abandon the assumption that you'll have time to figure things out when a breach occurs. The 72-hour notification window passes quickly, and your decisions under pressure will determine whether you maintain compliance and stakeholder trust or face regulatory enforcement and lasting reputational damage.
