Public S3 Bucket, Unknown IP, and the 72-Hour Clock
At 10:00 Friday, a cloud security analyst confirms that an S3 bucket containing 50,000 customer records, including names, emails, and hashed passwords, was publicly readable for 36 hours. Access logs show 14 GET requests from two IP addresses: one a known security scanner, the other an unknown VPS. The bucket also receives writes from a third-party marketing vendor whose contract does not mention S3. The company has EU customers and is subject to GDPR; the DPO is on leave until Monday. Legal counsel advises waiting for the full forensic report before notifying regulators. The CEO wants to avoid reputational damage and asks whether notification can be delayed until the vendor confirms whether the unknown IP is theirs. The 72-hour clock started when the analyst confirmed the exposure at 10:00.
1. What notification decision framework applies, and what facts matter?
Read the worked answer
Use the GDPR Article 33 framework: notify the supervisory authority within 72 hours of becoming aware unless the breach is unlikely to result in a risk to rights and freedoms. Here, the data includes names, emails, and hashed passwords, and the bucket was public for 36 hours, so risk is plausible. The unknown VPS IP and the vendor uncertainty affect scope and severity, not whether the clock runs. Assess the nature of the data, categories and approximate number of records, likely consequences such as phishing or credential stuffing, and measures taken. Hashed passwords are not automatically safe; determine the algorithm and whether they can be cracked. The vendor's role matters for controller/processor obligations, but the company cannot wait indefinitely for the vendor to confirm. Document the uncertainty and notify with what is known, then supplement. Legal counsel should advise, but 'wait for the full report' is not a valid reason to miss the deadline.
2. Who should decide, and how do you handle the DPO absence and CEO pressure?
Read the worked answer
The decision should sit with the incident response lead, the DPO or deputy DPO, and legal counsel, with executive sign-off on communications. The DPO's absence does not suspend the obligation; escalate to a deputy or external DPO service. The CEO can set tone and reputational strategy but should not unilaterally delay a regulatory notification. Record the options considered, the risk assessment, the advice received, and the final decision with timestamp. If the risk is unclear at the deadline, notify and state that the investigation is ongoing; regulators generally prefer timely notification with updates over silence. Do not let the vendor's confirmation timeline set the regulatory clock. Brief customer support and communications before any public statement.
3. What should be in the regulator notification and customer communication?
Read the worked answer
Include the nature of the breach, categories and approximate number of data subjects and records, the DPO or contact point, likely consequences, and measures taken or proposed. Avoid speculation about the unknown IP or naming the vendor unless confirmed. State that hashed passwords were exposed and advise customers to reset passwords if risk warrants it. For customer communication, coordinate with legal to avoid admitting liability or waiving privilege, but be clear about what happened and what customers should do. Describe containment: bucket made private, access keys rotated, logging enabled, vendor contract reviewed. Keep a record of all notifications and their timestamps. If later facts change the scope, send a supplement rather than staying silent.