When Capcom disclosed unauthorized access to 11.7 million account records in October, security teams closely observed how the company handled detection, containment, and notification. The breach itself wasn't remarkable. What stood out was how quickly common incident response myths surfaced in the analysis that followed.
These myths persist because they sound reasonable. They align with how we think incident response should work, not how it actually works when you're coordinating across legal, technical, and regulatory teams under time pressure.
Here's what the Capcom incident reveals about five assumptions that don't hold up in practice.
Myth 1: Fast Detection Means You Stopped the Damage
Reality: Capcom detected suspicious activity on October 19 and confirmed the intrusion the same day. That's solid detection work. But by the time they confirmed it, attackers had already accessed 11.7 million records and changed passwords on 196 accounts.
Speed matters, but detection speed doesn't determine breach scope. The damage window opens when the attacker gains initial access, not when your monitoring catches them. Your detection timeline measures how long they operated undetected, not how much they accomplished.
What actually limits damage: segmentation that restricts lateral movement, access controls that prevent privilege escalation, and data minimization that reduces what's available to steal. Detection tells you when to activate your response plan. It doesn't undo what already happened.
Myth 2: External Advisory Bodies Slow Down Your Response
Reality: Capcom informed its Information Technology Security Oversight Committee on October 20, one day after detection. This external advisory body didn't delay their response. It ran parallel to their internal incident response headquarters, which they established the same day.
The myth assumes external oversight creates bureaucratic friction. In practice, external advisors provide specialized expertise your internal team may lack, particularly in forensics, legal obligations, and communication strategy. They've seen patterns across multiple incidents that your team hasn't.
The coordination overhead is real, but you're not choosing between speed and expertise. You're choosing between making critical decisions with incomplete context or getting input from people who've managed similar incidents. Capcom reported to Japan's Personal Information Protection Commission and the Osaka Prefectural Police on October 21, meeting their regulatory obligations without compromising their technical response.
Myth 3: If Payment Cardholder Data Wasn't Compromised, Notification Can Wait
Reality: Capcom's breach didn't include Cardholder Data. That's significant for PCI DSS scope, but it doesn't reduce the notification urgency. The exposed email addresses create immediate phishing risk, and the 196 accounts with unauthorized password changes represent active account takeover.
This myth conflates data sensitivity with notification priority. Payment Cardholder Data triggers specific PCI DSS requirements under Requirement 12.10, but notification timing depends on what attackers can do with what they took, not just what category of data it falls into.
Email addresses combined with system metadata (creation dates, login patterns, IP addresses) let attackers craft convincing phishing campaigns. They know which accounts are active, when users typically log in, and where they connect from. For 43 accounts, attackers also obtained dates of birth, gender, country, and nicknames. That's enough context to personalize social engineering at scale.
Your notification timeline should reflect the fraud risk to account holders, not just your compliance obligations.
Myth 4: Completing Emergency Response Means the Incident Is Over
Reality: Capcom stated it "completed its emergency response and identified and addressed the attack method" while simultaneously noting that "its investigation is ongoing." These aren't contradictory statements. They reflect how incident response actually works.
Emergency response focuses on containment: blocking attacker access, securing compromised accounts, and preventing further damage. Completing that phase doesn't mean you understand the full scope or have closed every gap the attackers exploited.
The investigation continues because you need to answer questions that emergency response doesn't address: What was the initial access vector? How long did attackers maintain persistence before detection? What other systems did they probe? Were there earlier intrusions you didn't detect?
Capcom committed to publishing updates if the investigation reveals information requiring disclosure. That's the correct posture. You can't notify affected parties about facts you haven't yet confirmed, but you can't assume your initial assessment captured everything either.
Myth 5: Repeat Breaches Mean Your Security Program Failed
Reality: Capcom experienced a ransomware attack in November 2020 that compromised data for up to 350,000 individuals. This October incident affected a different system (CAPCOM ID accounts) and involved different attack methods.
The myth assumes that if you fixed security after one breach, you shouldn't have another. But your attack surface changes constantly. New services launch, third-party integrations expand, and attackers shift techniques. The 2020 ransomware attack and the 2024 account compromise aren't the same failure repeated. They're different threat actors exploiting different vulnerabilities.
What matters is whether you applied lessons from the first incident to your broader security posture. Did you improve monitoring? Did you segment systems to limit lateral movement? Did you update your incident response procedures based on what worked and what didn't?
Rockstar Games confirmed an attack in April 2024 claimed by ShinyHunters. These aren't isolated incidents. Gaming companies face persistent targeting because they hold valuable data and operate services with large user bases. The question isn't whether you'll face another incident. It's whether each incident response improves your capability for the next one.
What to Do Instead
Stop treating incident response as a checklist you complete once and file away. Your response plan should evolve with each tabletop exercise and each real incident.
Document your detection-to-containment timeline for every incident, even minor ones. That baseline tells you whether your monitoring is improving or degrading as your environment changes.
Establish relationships with external advisors before you need them. Capcom's Information Technology Security Oversight Committee didn't slow their response because the relationship already existed. If you're building that advisory structure during an active incident, you've added unnecessary coordination overhead.
Separate your emergency response procedures from your investigation protocols. You need different teams with different skills operating on different timelines. Emergency response optimizes for containment speed. Investigation optimizes for forensic completeness. Don't let investigation requirements slow your containment, and don't let containment urgency compromise your evidence collection.
Most importantly, assume your notification will happen under time pressure with incomplete information. Prepare templates that work with partial facts. Identify your legal and regulatory notification triggers in advance. Know which regulator you're reporting to and what their expectations are for initial versus updated notifications.
The myths persist because they're simpler than reality. Your incident response plan needs to account for how breaches actually unfold, not how we wish they would.
