Two Regulators, One Incident Notification
A digital lender suffers a data breach: an exposed storage bucket reveals names, addresses, and partial account numbers for 120,000 customers across two countries. The lender operates under a data-protection regime in Country A requiring notification to the regulator within 72 hours of awareness where there is a risk to individuals, and a financial regulator in Country B requiring notification of material operational incidents within 24 hours. The security team confirmed the exposure at 16:00 Friday; the fix was applied at 19:00. The general counsel wants to wait for a full forensic report before notifying anyone, arguing that premature disclosure creates liability. The CEO is travelling and unreachable until Monday. The 24-hour clock in Country B expires Saturday afternoon.
1. What should the risk manager advise on notification timing, and how should the competing pressures be resolved?
Read the worked answer
The risk manager should separate three questions that the general counsel is merging: whether to notify, when, and how much to say.
Whether: both regimes appear engaged. Country A's 72-hour test turns on risk to individuals, and partial account data with names and addresses is likely to meet it. Country B's test is materiality of an operational incident; a 120,000-record exposure is plausibly material, and the 24-hour clock is running. Waiting for a complete forensic report is not a lawful basis for delay where the regimes require notification on awareness with the information then available.
When: the Country B deadline expires Saturday. The risk manager should advise notifying within the deadline with an initial report marked as preliminary and subject to update, which most regimes permit. The 72-hour Country A clock should be diarised and met.
How much: initial notifications can be factual and bounded-what is known, what is not, what is being done, and when the next update will come. This addresses the GC's liability concern without breaching deadlines.
Escalation: the CEO's unavailability is not a defence. The risk manager should invoke the incident-response escalation plan, document the decision and its rationale, and identify the delegated authority. A documented, timely, good-faith notification is far more defensible than a late one justified by an unfinished report.
2. After notification, what should the risk manager do to convert this event into durable program improvement?
Read the worked answer
The event is a control failure with a governance dimension, so the response should address both.
Immediate containment and evidence: preserve logs, confirm the fix, and verify no other buckets are similarly exposed. Scope the affected population precisely so notifications and any remediation are accurate.
Root cause and control gap: the failure was likely a configuration and change-management weakness, not a one-off. The risk manager should ask whether cloud-storage configuration is covered by the control framework, tested, and monitored. Add automated configuration scanning and a pre-production check to the control set, with an owner and evidence.
Detection and response: measure time from exposure to detection and from awareness to notification. If detection took weeks, that is a monitoring gap; if notification was delayed by escalation, that is a governance gap. Fix both-define delegated authority for notification decisions so a travelling CEO cannot stall a statutory clock, and pre-draft notification templates.
Third-party and regulatory follow-up: expect regulator questions and possibly a customer claim. Coordinate with legal on privilege and with communications on messaging.
Finally, report to the risk committee: the incident, the root cause, the control changes, and the residual risk rating. Record it in the risk register and test the revised plan in the next exercise.