Context
Last week, I joined a cross-functional incident review where the pressing question was: "How do we know we'd catch this faster than Sony did?" The Sony Network Communications breach, 2.5 million records exposed, detected four days after initial access, has IT and security teams reassessing their detection capabilities and response protocols.
These questions come from real Slack threads, post-incident reviews, and planning sessions I've observed recently. They're not hypothetical. They're what your team will ask when you're four days into an incident you didn't know you had.
Q1: Four days to detect? What's realistic for catching unauthorized database access?
Four days isn't ideal, but it's not uncommon. Most organizations lack real-time alerting on every database query pattern.
Here's what matters: do you have automated alerts for unusual access volumes, off-hours queries, or credential use from unexpected locations? The Sony breach involved unauthorized access to their So-net member database. If you're running an ISP or handling similar customer volumes, you need query-level monitoring that flags anomalies without overwhelming your team with false positives.
Focus on these detection points:
- Failed authentication attempts above your baseline
- Successful logins from new IP ranges
- Bulk data exports or queries returning more than a set number of records
- Database access outside normal business hours for that account
Your detection window depends on how detailed your logging is and whether someone's actively monitoring those logs. Four days suggests they caught it through secondary indicators, not primary monitoring. Don't let that be your story.
Q2: We're a processor for multiple controllers. Who reports to the supervisory authority?
Under Article 33, the controller reports to the supervisory authority within 72 hours of becoming aware of the breach. As a processor, you must notify the controller "without undue delay" after becoming aware.
In the Sony case, both Sony Network Communications and NTT Docomo had reporting obligations because they served different customer bases. Sony reported to Japan's Personal Information Protection Commission. NTT Docomo had to notify its own customers.
Your processor agreement should specify notification timelines. If it says "immediately" or "without undue delay," that means the same business day you confirm the breach, not when you've finished your investigation. The controller needs time to meet their 72-hour window.
Document who you've told and when. If you're processing for five controllers and the breach affects all of them, you're making five notifications before you've had your second coffee.
Q3: The breach exposed names, emails, dates of birth, but no payment data. Do we still have to notify individuals?
Yes, probably. Article 34 requires individual notification when the breach is "likely to result in a high risk to the rights and freedoms of natural persons."
Names, email addresses, phone numbers, dates of birth, and user IDs? That's enough for targeted phishing, identity theft, and account takeover attempts. NTT Docomo explicitly warned customers about phishing emails impersonating their services, they knew the risk.
The "high risk" threshold isn't about what data types were exposed. It's about what someone can do with that combination. If attackers can use the exposed data to impersonate your organization, compromise accounts, or target individuals with credible social engineering, you're past the threshold.
Don't wait for confirmed misuse. Sony and NTT Docomo notified customers even though, as of October 27, neither had confirmed the data was being actively exploited. By the time you see it in the wild, your customers have already been targeted.
Q4: What goes in the notification to customers? We've never actually written one.
Article 34 specifies minimum content. Your notification must include:
- The nature of the breach (unauthorized access to customer database)
- Contact details for your DPO or someone who can answer questions
- Likely consequences (risk of phishing, account takeover)
- Measures you've taken or propose to take (server shutdown, credential resets, enhanced monitoring)
Write it in plain language. "An unauthorized party accessed our member database containing your name, email, phone number, date of birth, and user ID" is clearer than "a security incident may have resulted in potential exposure of certain personal data elements."
Sony told customers to change their passwords for the 54,401 accounts where passwords were exposed. NTT Docomo warned about specific phishing tactics they expected. That's the level of specificity you need, tell people what to watch for and what to do.
Q5: We shut down the compromised servers immediately. Did we just destroy evidence the supervisory authority will want?
You did the right thing. Article 33 requires you to document the breach, including "measures taken or proposed to be taken to address the personal data breach." Shutting down compromised servers and blocking external communication is exactly what that means.
What you need is forensic preservation before you shut down. Capture memory dumps, preserve logs, document the state of the system. Then isolate it.
The supervisory authority will want to know:
- How the attacker got in
- What they accessed
- How long they had access
- What you did to contain it
If you shut down first and capture evidence second, you've lost the ability to answer those questions. Your incident response plan should have a 30-minute forensic checklist that runs before you pull the plug.
Q6: How do we know if we're seeing the same attack pattern that hit Sony, KDDI, and the other Japanese companies?
You probably don't have enough information to know. Reports mention "multiple cyberattacks" targeting Japanese providers but don't detail the attack vectors.
What you can do: review your authentication logs for credential-based access patterns. The Sony breach involved unauthorized access to a member database, that suggests compromised credentials or an authentication bypass, not a typical ransomware or malware deployment.
Look for:
- Valid credentials used from unusual locations
- Lateral movement after initial access
- Database queries that don't match normal application behavior
- Access to backup or secondary systems that aren't regularly used
If you're seeing similar patterns, assume you're part of a broader campaign and escalate accordingly. Share indicators with your industry peers and your supervisory authority. Coordinated attacks require coordinated defense.
Q7: Our processor agreement says we'll notify the controller "as soon as practicable." Is that good enough?
No. "As soon as practicable" is vague enough to get you in trouble. Article 33(2) says the processor must notify the controller "without undue delay", that's the standard your contract should mirror.
Renegotiate if you can. If you can't, document your interpretation in writing with your controller: "Without undue delay means within [X hours] of our security team confirming unauthorized access to personal data you control."
The controller's 72-hour clock starts when they become aware of the breach. If you wait 48 hours to tell them because you were "still investigating," you've left them 24 hours to meet their legal obligation. That won't go well for anyone.
Where to go for more
Your incident response plan should include notification templates for both supervisory authorities and data subjects, along with decision trees for when each notification is required. If you don't have those templates, build them now, not at 2 AM when you're four days into a breach you just discovered.
Review your processor agreements for notification language. If they're older than two years, they probably don't reflect current supervisory authority expectations around timing and detail.
And test your detection capabilities. Run a tabletop exercise where an attacker has valid credentials to your customer database. How long until someone notices? If the answer is "longer than four days," you've got work to do.
