When Fishbrain discovered unauthorized access to its user environment on August 19, the breach had been ongoing for about three weeks. This detection gap turned a manageable incident into a full password reset operation, affecting user credentials, personal data, and trust. While your team might not catch intrusions immediately, you can control the actions taken in the 72 hours after discovery.
This checklist outlines the operational steps your security and privacy teams must execute once you confirm unauthorized access to personal data. It's structured around Article 33 and 34 notification deadlines, but the real focus is on containment, evidence preservation, and user protection.
Checklist Overview
This guide covers the essential response actions when you've confirmed or strongly suspect a personal data breach involving authentication credentials or other high-risk information. It assumes you've detected the incident and need to act quickly on forensics, notifications, and remediation.
Prerequisites
To execute this checklist effectively, your organization needs:
- Designated incident response roles: Know who leads forensics, drafts supervisory authority notifications, and approves user communications before a crisis hits.
- Breach register template: Article 33(5) requires documentation of every breach, including facts, effects, and remediation. Have a template ready.
- User communication channels: Ensure email, in-app messaging, or account portal notifications are tested and ready to deploy quickly.
- Forensic logging capability: Maintain timestamped access logs, authentication logs, and environment snapshots to establish breach timelines and scope.
The 72-Hour Response Checklist
Hour 0-4: Containment and Scoping
☐ 1. Isolate the affected environment immediately
Restrict access, terminate active sessions, and prevent further data exfiltration. Fishbrain terminated sessions and restricted environment access once they confirmed the breach. Aim to have affected systems offline or locked down within two hours of confirmed unauthorized access, with documented approval for the isolation.
☐ 2. Preserve forensic evidence before making changes
Capture logs, memory dumps, and access records before patching or rebuilding. This is crucial for your supervisory authority notification and any follow-up investigation. Ensure timestamped snapshots of authentication logs, access patterns, and affected data sets are stored in write-once media.
☐ 3. Establish the breach timeline
Determine when unauthorized access began, when it was discovered, and what actions the attacker took. Fishbrain's investigation revealed access may have started on July 30, nearly three weeks before detection. Document a timeline with specific dates and evidence sources, even if some dates are estimated.
☐ 4. Identify the categories of personal data exposed
List exactly what data the attacker accessed: names, email addresses, telephone numbers, password hashes, dates of birth. Don't guess. Create a data inventory tied to the affected environment showing which fields were present and which the attacker likely viewed or copied.
Hour 4-24: Assessment and Notification Preparation
☐ 5. Determine whether password hashes are at risk of cracking
Check your hashing algorithm (bcrypt, Argon2, PBKDF2) and configuration. Fishbrain warned that some hashes "may be susceptible to being decoded." If you're using weak hashing or short salts, assume passwords will be cracked. Provide a written assessment from your security team stating hash strength, salt length, and estimated time-to-crack for common password patterns.
☐ 6. Assess cross-account credential reuse risk
If users reused their password on other services, a cracked hash becomes a credential stuffing vector. This elevates risk and affects your Article 34 user notification decision. Document a risk analysis considering that many users reuse passwords, even if you can't measure your specific user behavior.
☐ 7. Draft your Article 33 supervisory authority notification
You have 72 hours from becoming aware of the breach to notify your lead supervisory authority. Include: nature of the breach, categories and approximate number of affected individuals, likely consequences, and measures taken or proposed. Submit a complete notification within 72 hours, even if some details are marked as "under investigation" with a timeline for follow-up.
☐ 8. Decide whether Article 34 user notification is required
If the breach is likely to result in high risk to individuals' rights and freedoms, notify affected users without undue delay. Password hashes plus personal identifiers create high risk due to credential stuffing and phishing exposure. Document the decision with legal or DPO sign-off, citing specific risk factors that triggered the notification requirement.
Hour 24-72: User Communication and Remediation
☐ 9. Reset passwords for all affected accounts
Force password resets before notifying users, so they can't log in with compromised credentials. Fishbrain reset passwords as a precaution. Ensure all affected accounts are locked, password reset emails sent, and clear instructions for creating a new unique password.
☐ 10. Send user notifications with specific protective actions
Inform users exactly what was exposed, what you've done, and what they must do (change passwords on other sites where they reused credentials, watch for phishing). Article 34(2) requires clear and plain language. Send notifications within 72 hours of discovery, written at an 8th-grade reading level, with step-by-step protective actions and a direct contact for questions.
☐ 11. Patch the vulnerability or access vector
Fishbrain patched the vulnerability involved in the incident. Identify the root cause, deploy a patch or configuration change, and complete verification testing before restoring normal operations.
☐ 12. Document everything in your breach register
Article 33(5) requires a record of all breaches, including facts, effects, and remedial action. This isn't optional. Ensure timestamped entries cover detection, containment, notification, and remediation, with evidence attached and DPO review completed.
Common Mistakes
Waiting to notify until you have perfect information. You have 72 hours to notify your supervisory authority, not 72 hours to complete your investigation. Submit what you know and follow up with additional details.
Underestimating password hash risk. If you're not using modern hashing with strong salts, assume passwords will be cracked. Don't reassure users based on "hashed passwords" alone.
Notifying users before resetting passwords. If you tell users about the breach before forcing password resets, some will ignore the email and continue using compromised credentials.
Focusing only on your service. The real risk is credential reuse. Your notification must explicitly tell users to change passwords on other sites.
Next Steps
After the immediate response, conduct a post-incident review within 30 days. Ask: How did the attacker gain access? Why did detection take three weeks? What monitoring gaps exist? Then update your incident response plan, improve your detection capabilities, and test your notification procedures before the next breach.
The Fishbrain breach shows that even when you store passwords as hashes, a three-week detection gap creates enough exposure to force mass password resets and user warnings. Your 72-hour response determines whether a security incident becomes a trust crisis.
