Breach Notification Clock With an Incomplete Picture
A retail bank discovers that a misconfigured API exposed account-balance and transaction-history endpoints for an estimated 9 days. The security team detected it on a Tuesday at 14:00 and contained it by 18:00. By Thursday, the investigation has established: about 60,000 accounts were potentially reachable; logs show 1,200 unique IPs made requests, but logging was sampled at 10% for part of the window, so the true access count is unknown; the exposed data includes balances and transaction descriptions but not credentials or full account numbers; and one internal analyst downloaded a sample of 200 records to a personal device to 'test the exposure' before containment. The bank operates in a jurisdiction with a 72-hour notification clock running from awareness, and has customers in two other countries with their own clocks. The CISO wants to wait for a 'complete picture' before notifying.
1. When does the 72-hour clock start, and what is the strongest argument against waiting for a complete picture?
Read the worked answer
Clock start: the clock starts at awareness, which is when the organization has a reasonable degree of certainty that a security incident has occurred that leads to personal data being compromised - not when the investigation is complete. Here, awareness is at latest Tuesday 14:00 (detection), arguably earlier if monitoring alerts existed. The 72-hour deadline is therefore Thursday 14:00. By Thursday, the bank is already at or past the deadline, and the CISO's proposal to wait is itself a compliance failure.
Strongest argument against waiting: the notification standard is not 'complete picture' - it is 'unless it is unlikely to result in a risk.' The bank already knows enough to conclude risk is likely: 60,000 accounts, financial data, 9-day exposure, confirmed external requests. The unknowns (exact access count, 10% sampling gap) affect scope description, not the decision to notify. The regulation contemplates phased notification: notify within 72 hours with what is known, and supplement later. Waiting converts a containable incident into an aggravated one - the regulator's first question will be why notification was late, not why the count was approximate.
Practical point: the 10% sampling gap is a reason to describe the count as an estimate and explain the logging limitation, not a reason to delay. The personal-device download is a separate internal incident that must be assessed in parallel.
2. The analyst's personal-device download of 200 records is discovered during the investigation. How does it change the notification analysis, and what are the immediate steps?
Read the worked answer
Effect on notification: it adds a second, distinct compromise - an internal unauthorized transfer of personal data to an unmanaged device. It may be an insider-risk event or a well-intentioned but uncontrolled act; either way it is a personal-data breach that must be assessed on its own. It does not change the external-exposure notification, but it must be included in the incident record and assessed for whether it independently triggers notification (200 records of financial data on an unmanaged device is likely a reportable risk, depending on encryption and whether the device is retrievable).
Immediate steps:
- Preserve evidence: do not wipe the device. Instruct the analyst to stop using it, and secure it or obtain a forensic image with HR and legal involvement.
- Determine encryption and access: was the device encrypted, password-protected, and is the data still present? Can it be remotely wiped after imaging?
- Assess scope: confirm exactly which 200 records, whether they left the device (email, cloud sync, messaging), and whether the analyst shared them.
- HR and legal: treat as a potential policy violation and insider-risk matter; preserve the analyst's access logs and communications.
- Contain: revoke the analyst's export privileges pending review; check whether other analysts did the same.
- Notify decision: document the assessment. If the device is encrypted and recovered, risk may be low; if not, notify affected individuals.
- Root cause: the fact that an analyst could export 200 records to a personal device indicates a data-loss-prevention gap that belongs in the same remediation plan as the API misconfiguration.
3. Design the notification decision record the bank should produce, and explain how it handles the three jurisdictions and the unknown access count.
Read the worked answer
Structure of the decision record:
- Incident timeline: detection, containment, each investigative milestone, with timestamps and owners.
- Awareness determination: the date/time the bank had reasonable certainty, and the reasoning. This anchors every clock.
- Data categories and volume: balances and transaction descriptions; ~60,000 potentially reachable; explicitly flag that access counts are estimates due to 10% sampling, with the sampling window stated.
- Risk assessment: nature of data (financial, not credentials), likelihood of harm (fraud, profiling), severity, and the conclusion that risk is likely.
- Notification decisions per jurisdiction:
- Home jurisdiction (72-hour clock): notify by Thursday 14:00 with current knowledge; supplement as the investigation matures. Record the phased approach.
- Country A: identify its clock and threshold (e.g., 72 hours, or 'without undue delay'); map the same facts to its standard and record the deadline.
- Country B: same exercise; note if its threshold is higher (e.g., only if high risk) and document why the facts do or do not meet it.
- For each: who was notified, when, by what channel, and what was said.
- Individual notification: whether affected customers are notified, the content (what happened, what data, what to do, contact point), and the channel.
- Unknowns and how they are handled: the access-count estimate, the sampling limitation, and the plan to refine. State that unknowns were disclosed as estimates rather than used to delay.
- The personal-device incident: separately assessed, with its own risk conclusion and notification decision.
- Remediation and lessons learned: API configuration control, logging completeness (end sampled logging), DLP, and the decision-record process itself.
Handling the unknown count: the record should present a range with its basis (e.g., 'at least 1,200 unique IPs observed; true figure unknown due to 10% sampling between days X and Y'), and state that the estimate does not affect the notification decision. Regulators accept uncertainty disclosed honestly; they do not accept silence justified by uncertainty.