Legal and compliance teams don't usually get their breach response questions answered in a conference room. They come up in Slack at 11 PM, in hallway conversations with the CISO, or during the first frantic hour after you confirm unauthorized access. The Capcom breach, which exposed account data for more than 11 million users and saw 196 passwords changed by an attacker, surfaces the questions every privacy officer needs to answer before the next incident hits.
Here's what practitioners are actually asking when a breach lands on their desk.
Do We Really Need to Notify if It's "Just" Account Metadata?
Yes, and here's why the "just metadata" argument won't hold up.
The Capcom breach exposed account creation timestamps, last login dates, login counts, and the most recent client IP address for each account. While it's not payment card data or Social Security numbers, it's still personal data under GDPR Article 4(1) and similar frameworks. An IP address tied to a timestamp can be directly identifying.
More importantly, the 72-hour notification requirement under GDPR Article 33 doesn't depend solely on data sensitivity. You're evaluating the likelihood and severity of risk to individuals' rights and freedoms. If an attacker can use that metadata for phishing campaigns, credential-stuffing attacks, or social engineering, you've got risk. The combination of email addresses, login patterns, and IP geolocation gives attackers enough to craft convincing spear-phishing messages.
Your notification decision tree should ask: Can this data be weaponized against the individual? If yes, notify.
The Attacker Changed Passwords on 196 Accounts. Is That a Separate Incident or Part of the Same Breach?
It's the same incident with an escalated risk profile.
Unauthorized password changes indicate the attacker had write access, not just exfiltration capability. That shifts your breach register entry from "unauthorized disclosure" to "unauthorized disclosure plus unauthorized alteration." Under GDPR Article 4(12), a personal data breach covers confidentiality, integrity, and availability. You've got a confidentiality breach (data exposed) and an integrity breach (passwords altered).
For your notification to the Supervisory Authority, document both. The password changes affect a subset of users, but they demonstrate the attacker's level of access and intent. That matters when the authority evaluates whether you had appropriate Technical and Organisational Measures in place under Article 32.
Practically, those 196 users need direct notification under Article 34 because they face immediate risk of account takeover. The broader 11 million may not require individual notification if you can demonstrate low risk, but the 196 absolutely do.
We Reset the Compromised Passwords. Does That Change Our Notification Obligations?
No, but document it thoroughly.
Resetting passwords is a containment measure, not a substitute for notification. GDPR Article 34(3) allows you to skip individual notification if you've implemented measures that render the data unintelligible (like encryption) or if you've taken subsequent measures ensuring the high risk no longer materializes. A password reset addresses future unauthorized access, but it doesn't undo the exposure that already occurred.
Your breach register should show:
- Detection timestamp
- Containment actions taken (password resets completed by [date/time])
- Residual risk assessment post-containment
- Rationale for notification decisions
The password reset strengthens your position that you acted swiftly under Article 33(1), but it doesn't erase the breach. If you're notifying the Supervisory Authority, include the reset as part of your remediation measures.
How Do We Warn Users About Phishing Without Causing Panic?
Be specific, not vague.
Capcom's approach, warning users to watch for phishing emails, is correct but often executed poorly. Don't send a generic "be vigilant" message. Tell users exactly what data was exposed and what a phishing attempt might look like.
Your notification should include:
- What data the attacker accessed (email, login timestamps, IP addresses)
- What the attacker did NOT access (payment methods, game save files, etc.)
- Specific phishing tactics to watch for ("Emails claiming your account will be suspended unless you click a link")
- How your organization will actually contact them (official domain, no links in emails, etc.)
Under Article 34(2), individual notifications must describe "the likely consequences of the personal data breach" and "the measures taken or proposed to be taken." Phishing is a likely consequence. Your proposed measure is user education paired with your own monitoring for credential-stuffing attempts against your authentication endpoints.
If you've got a security team monitoring for anomalous login patterns post-breach, say so. It reassures users and demonstrates you're meeting the "appropriate Technical and Organisational Measures" standard.
Should We Offer Credit Monitoring or Identity Theft Protection?
Not for this type of breach, but have a framework ready.
The Capcom breach didn't expose financial account numbers, government IDs, or health data. Credit monitoring won't help users whose email addresses and login metadata were exposed. It's a mismatch between the harm and the remedy.
Your framework should tie remediation offers to actual risk:
- Financial data exposed: Credit monitoring, fraud alerts
- Credentials compromised: Password manager subscriptions, MFA enrollment support
- Identity documents exposed: Identity theft protection services
- Metadata/account info exposed: Clear phishing guidance, account monitoring
Offering irrelevant services looks like you're checking a box, not protecting users. For a breach like Capcom's, the right remediation is forcing password resets, enabling MFA by default if you haven't already, and providing actionable phishing education.
We're a B2B SaaS Company, Not a Consumer Service. Do the Same Rules Apply?
Yes, with one addition.
If you're processing personal data on behalf of enterprise customers, you're likely a processor under GDPR Article 28. Your customer contracts probably include a breach notification clause requiring you to notify the controller "without undue delay" after becoming aware of a breach.
That's in addition to, not instead of, your Article 33 obligation to notify the Supervisory Authority. You've got two notification paths:
- To your customers (the controllers), per your Data Processing Agreement
- To the Supervisory Authority, per Article 33
Your customers then decide whether to notify their own users under Article 34. Don't assume your customer notification satisfies your regulatory obligation. They're separate requirements.
Where to Go for More
Your breach register isn't a post-incident checklist. It's a living document that should already contain your notification thresholds, decision trees, and contact lists before the breach happens. If you're building one from scratch, start with Article 33's required elements: nature of the breach, categories and approximate number of individuals affected, likely consequences, and measures taken. The European Data Protection Board's Guidelines 01/2021 on Examples Regarding Data Breach Notification walks through scenarios that clarify when notification is mandatory versus optional.
For phishing-specific guidance after a breach, NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) includes communication templates that balance transparency with operational security. Your goal isn't to eliminate user anxiety, it's to give users the information they need to protect themselves while you contain the damage.
