Reporting a Confirmed Breach to Regulators and Customers
On a Friday afternoon the team confirms that a database containing 12,000 customer records (names, emails, hashed passwords) was accessed by an external actor. The intrusion began 9 days ago; the team has contained it. The company operates in a jurisdiction with a 72-hour breach-notification clock that starts when the breach is confirmed, and has customers in two other countries with their own notification rules. Legal is asking the security team for a factual summary by end of day. The CEO wants to wait until the full forensic report is done (estimated 3 weeks) before saying anything publicly. Marketing has drafted a statement calling it a "minor incident."
1. What is the correct position on timing, and what does the 72-hour clock actually require?
Read the worked answer
The clock started today, when the breach was confirmed - not when the intrusion began and not when the forensic report is finished. Waiting three weeks for a complete report would blow the deadline. The regulatory notification does not require a complete root-cause analysis; it requires notification within the window with the information then known, followed by updates as facts develop. The security team should deliver the factual summary now (what data, how many records, when detected, containment status, known scope) and flag what is still unknown. "We are still investigating" is an acceptable supplement, not a substitute for notifying on time.
2. How should the team respond to the CEO's request to wait and Marketing's "minor incident" framing?
Read the worked answer
Both are risks the security team must push back on, in writing and with rationale. Waiting past the deadline converts a breach into a regulatory violation and likely a larger penalty. "Minor incident" is inaccurate - 12,000 records including hashed passwords is a reportable breach, and a misleading public statement can itself create legal exposure and destroy credibility when the truth emerges. The right framing is factual and scoped: what happened, what data, what the company is doing, what customers should do (e.g., password reset given hashed passwords were taken). Recommend Legal own the final wording, but the security team's factual summary must not be softened to the point of misstatement. Document the recommendation and the decision.
3. What should the customer-facing communication include and avoid, given hashed passwords were exposed?
Read the worked answer
Include: the fact of unauthorized access, the categories of data (names, emails, hashed passwords), the approximate number affected, when it was detected, containment status, and a concrete recommended action - prompt a password reset, especially for any customer who reused that password elsewhere, and warn about phishing that may reference the breach. Avoid: minimizing language ("minor"), speculation about the attacker, guarantees that no other data was affected while the investigation is open, and blaming. Note that hashed passwords are not automatically safe - the hash type and salting matter, and weak or unsalted hashes can be cracked; the team should confirm the hash scheme before deciding how strongly to word the password-reset advice.