Twelve Thousand Records and a Confident CEO
At 23:00 Friday you confirm an attacker accessed a customer database through SQL injection in a legacy order-status page. Scope: 12,000 customer records with names and email addresses, 300 of which also contain full SSNs and dates of birth; passwords are stored as bcrypt hashes with cost factor 12. The attacker appears to have been in for about 40 minutes with no lateral movement observed, but database logs only retain 14 days and the injection flaw may have been open for months. Legal counsel says the incident is 'probably not reportable' because the SSN set is small. The CEO wants a customer email out tonight saying 'no sensitive data was affected'. Your jurisdiction requires notification of affected individuals without unreasonable delay when names and SSNs are involved. It is 23:40.
1. What must be established before the reporting decision, and where do you disagree with counsel?
Read the worked answer
Notification thresholds are per person, not per percentage.
Three hundred people with name plus SSN plus date of birth is a notifiable population in a names-and-SSN regime. 'Small' is not a legal standard; it is a reaction to the size of the 12,000. Separate the populations in the analysis: the 300 have a clear trigger, and the 12,000 email-only records need their own assessment under breach and privacy rules.
Before deciding, establish:
- Confirmed data elements per record, not just table contents; hashed passwords are relevant to what you tell people (bcrypt cost 12 materially lowers urgency of a forced reset) but not to whether you notify.
- Whether exfiltration completed, from proxy and DB connection telemetry.
- Whether the injection was exploited before the 14-day log window. Web server logs, WAF logs, and vendor access logs often reach further back; pull them before accepting the log limit as the boundary of the incident.
Where I disagree: the 14-day log window is a reason to assume a longer exposure, not a shorter one. Also, document the decision and its owner. 'Probably not reportable' given verbally at 23:00 with no named decision-maker becomes indefensible in an audit.
2. Rewrite the CEO's one-line statement into something defensible.
Read the worked answer
The problem with the draft: 'no sensitive data was affected' is factually unsupported at 23:40 and will be contradicted by the SSN population within days. A false reassurance converts a data incident into a trust and potentially a misrepresentation problem, and it fixes the narrative before the facts are in.
Replace it with a factual, dated, bounded statement:
- What happened: unauthorised access to a customer database through a web application flaw, discovered on a specific date.
- What is known: which categories of information were involved, stated precisely rather than reassuringly.
- What is not yet known: whether all affected records have been identified, and when the next update will come.
- What you are doing: flaw closed, credentials rotated, forensic review under way, law enforcement and regulators engaged as required.
- What customers should do now, differentiated: everyone gets phishing caution given name and email exposure; the 300 get direct contact, password reset guidance, and credit monitoring.
Operational discipline matters as much as wording: one spokesperson, one channel, an FAQ ready before the email goes out, and no speculation about attribution. Notify the 300 individually and ahead of any broad statement, so they do not learn they are in the sensitive group from a press article.
3. Which metrics go to the board next quarter, and which belong only to the SOC?
Read the worked answer
Split by decision rights.
The board decides on risk appetite, funding, and accountability. Give them:
- Time to detect and time to contain, trended quarterly, with the definition of each stated.
- Number of material incidents and how many triggered regulatory notification.
- Percentage of critical assets with complete logging and detection coverage, because the 14-day log retention that constrained this incident is a board-level funding question.
- Open risk acceptances past their expiry date.
Keep at the SOC level: alert volume per rule, rule precision, MTTA/MTTR by severity, and detection coverage gaps by technique.
The trap to name out loud: the instinct behind 'no sensitive data was affected' is the same instinct that produces vanity metrics, such as counting blocked phishing emails as a security outcome. If a metric cannot change a decision, it does not go in the board pack. Where the data is genuinely uncertain, present the range and the next checkpoint rather than a single confident number.