What Happened
Sony Network Communications, a Japanese internet-service subsidiary of Sony, disclosed on Oct. 27 a breach involving 2,585,481 customer records from So-net and plala (S Course). The exposed data included names, phone numbers, email addresses, user IDs, birth dates, gender, and internet connection IDs.
Additionally, passwords were exposed for 54,401 email addresses across certain So-net email services. Seven records tied to password-reset notifications contained user IDs and passwords, and 16 records included bank-account details like account numbers and holder names. Sony confirmed no bank-account PINs or credit-card data were compromised. The affected group also included former customers. The incident was reported to Japan's Personal Information Protection Commission, and the investigation into its cause and scope is ongoing.
This analysis uses GDPR as the reference standard. While the incident occurred under Japanese law, the issues it highlights are relevant to your obligations.
Timeline
- Oct. 19: Unauthorized access occurs.
- Oct. 23: Sony detects the intrusion, four days later. It stops the affected server and blocks communications from the unauthorized source.
- Oct. 24: Investigators confirm personal data was exposed.
- Oct. 27: Email-service passwords are reset, the incident is reported to the Personal Information Protection Commission, and the public notice is published.
- Oct. 29: The notice is updated. Sony states it has not confirmed secondary harm.
Which Controls Failed or Were Missing
The root cause is still under investigation, so it's unclear which specific control failed. However, the disclosed facts highlight key exposure points.
Detection Latency. Four days passed between access and detection. This gap allowed data to be read, copied, or used. A password reset can't reveal what happened during this time. As one security expert noted, a reset "doesn't tell us whether an inbox was accessed beforehand."
Credentials in Scope. Email-service passwords appeared in the exposed data for 54,401 addresses. The disclosure doesn't specify how they were stored, so avoid assuming a hashing failure. It does indicate that credential data was accessible from the compromised environment.
Scope of Retained Data. Former customers were affected. While the disclosure doesn't confirm improper retention, it raises questions about your own data retention practices.
Residual Identity Data. Names, birth dates, and connection IDs can't be changed. Once exposed, they can be used for fraudulent activities. A password reset closes one route but leaves others open.
What the Relevant Standard Requires
Article 32 (Security of Processing). Implement appropriate technical and organizational measures, including ensuring ongoing confidentiality and restoring availability and access. Regularly test and evaluate these measures. Detection capability, like alerting on unusual bulk reads and exports, is essential.
Article 5(1)(e) (Storage Limitation) and Article 5(1)(c) (Data Minimisation). Retain personal data only as long as necessary. Records of former customers need a documented purpose and defined retention period.
Article 33 (Notification to the Supervisory Authority). Notify without undue delay and within 72 hours of becoming aware of a personal data breach, unless it's unlikely to result in a risk to individuals. The clock starts from awareness, not from the intrusion.
Article 34 (Communication to Data Subjects). If a breach is likely to result in high risk, inform affected individuals without undue delay, using clear language. Describe the likely consequences and measures taken or proposed. Exposed credentials combined with identity details likely meet the high-risk threshold.
Article 33(5) (Documentation). Document every personal data breach, including facts, effects, and remedial action, whether or not you notify.
Lessons and Action Items for Your Team
1. Treat Detection Time as a Metric You Own. Measure how long it takes to notice unusual access to systems holding customer data. Add alerting on bulk reads and exports from customer databases, and test it. Your Article 33 clock starts when you become aware, so earlier awareness is crucial.
2. Plan for the Credentials, Not Just the Reset. When credentials are exposed, reset them and go further. Check mailbox activity for unrecognized sign-ins, review recovery addresses and active sessions, and look for forwarding rules. Investigate unfamiliar recovery addresses or forwarding rules even after a password change.
3. Address Credential Stuffing Directly. Exposed passwords will be tested against other services where people reused them. Enforce multi-factor authentication, screen new logins against known breached credentials, and advise affected individuals to change reused passwords everywhere. Move toward phishing-resistant authentication like passkeys, and secure the recovery flow to prevent bypassing stronger controls.
4. Write Your Article 34 Communication to Prevent Scams. Attackers can exploit the breach response itself. Warn customers about potential phishing attempts. Advise them to access account settings through your official website, not through unsolicited links, and clearly state what you will and won't ask for by phone, text, or email.
5. Stop Treating Static Personal Details as Proof of Identity. Birth dates, names, and account identifiers may now be in criminal hands. Review your help-desk and call-center verification processes. Add a second factor or a callback to an established channel for sensitive requests, and apply the same scrutiny to workplace account resets.
6. Audit Retention of Former Customers. Identify which cancelled-account records you hold, document the purpose for keeping each category, and delete what you can't justify under Article 5(1)(e).
7. Extend the Checks to Your Processors. Ensure processors holding customer data meet the same detection, retention, and notification standards. Your contracts should require prompt breach notification so your Article 33 clock isn't spent waiting.
8. Don't Equate "No Confirmed Misuse" with "No Harm." Sony said it hadn't confirmed secondary harm as of Oct. 29. Lack of confirmation isn't proof of absence. Record the reasoning behind your risk assessment in your breach register, and revisit it as the investigation develops.
By focusing on these strategies, your team can better mitigate the impact of data breaches and protect exposed credentials and personal information.
