A retailer discovered suspicious files in an external cloud service on October 28. It promptly shut down its online store, confirmed third-party access, and reported the incident to the police and the Personal Information Protection Commission by October 29. Approximately 7.7 million people may be affected, with customer passwords among the compromised data. While the response speed is commendable, the incident highlights common failures in cloud security. These failures are often predictable and avoidable.
Why These Mistakes Keep Happening
Cloud environments often blur ownership responsibilities. Marketing might create a storage bucket for a campaign, engineering might add a data store for a feature, and a processor might keep a copy "for convenience." Without clear ownership, no one manages the full inventory or the associated risks.
The shared responsibility model is often misunderstood. Many teams assume the provider handles security, but this isn't the case. Under Article 32 GDPR, the controller must implement appropriate technical and organizational measures. Article 28 makes the controller responsible for choosing processors that provide sufficient guarantees. The mistakes outlined below stem from these ownership gaps and misunderstandings.
Mistake 1: Treating the Cloud as a Dumping Ground for Historical Data
Why It Happens: Storage is cheap, and deletion requires decisions. Data from campaign participants, guest shoppers, and lapsed accounts accumulates because no one schedules their removal.
Consequence: The affected environment held data for about 5.8 million registered members, including former members, and about 1.9 million nonmembers like guest shoppers and campaign participants. Retaining unnecessary records increases the notification population and potential harm. Article 5(1)(e) storage limitation exists to prevent this.
Fix: Set retention periods for each data category, including guests and campaign entrants, and enforce them with automated deletion jobs. Review cloud inventories quarterly against the retention schedule. If a record has no active purpose, it shouldn't be in a live cloud store.
Mistake 2: Saying "Encrypted" Without Being Able to Say How
Why It Happens: Encryption is often treated as a checkbox. Teams enable provider defaults without documenting what is protected, how, and who holds the keys.
Consequence: The retailer claimed that passwords and some fields were encrypted, but didn't disclose the protection methods. Customers and authorities can't assess the risk from an unexplained claim. Encryption only reduces risk if the method is sound and the keys weren't exposed alongside the data. An attacker with access to the same environment may reach both.
Fix: Document encryption per field: at rest, in transit, and at the application layer for sensitive attributes. Store passwords with a salted, deliberately slow hashing algorithm, not reversible encryption. Keep keys in a separate system with separate access controls. Record all this so your breach assessment under Article 33 can confidently state what was and wasn't readable.
Mistake 3: Vetting the Processor Once, at Signing
Why It Happens: Procurement runs a security questionnaire, the contract gets signed, and the file is closed. Monitoring lacks ownership and budget.
Consequence: If an external cloud service is compromised, your operations stop even if your systems are intact. In this case, the store went offline, and sister sites and service applications were suspended as a precaution. Third-party exposure quickly leads to business interruption.
Fix: Make Article 28 diligence continuous. Require processors to notify you of incidents without undue delay and set a concrete contractual window. Request current audit reports annually. Map which of your systems and group companies depend on each processor, so you can scope a shutdown in hours, not days. Test the dependency map during a tabletop exercise.
Mistake 4: Discovering the Incident Before You've Defined Who Decides
Why It Happens: Incident response plans describe technical containment but leave authority vague. Who can take the store offline? Who calls the data protection officer (DPO)? Who decides if it's a personal data breach?
Consequence: Delay. Article 33 gives you 72 hours from awareness to notify the supervisory authority, where feasible. The retailer found the files on October 28 and reported on October 29, demonstrating a pre-agreed decision path. Teams without one lose that window to debate.
Fix: Name a decision-maker for containment, one for breach assessment, and one for external notification, with deputies. Pre-authorize service shutdown criteria. Involve the DPO from the first hour. Keep a template notification that already maps to Article 33(3) content requirements, so you're filling in facts, not drafting from scratch.
Mistake 5: Communicating with Customers in Vague, Delayed, or Incomplete Terms
Why It Happens: Legal wants certainty before saying anything, while the investigation is still counting records. Teams wait for a complete picture that never arrives on schedule.
Consequence: Customers who reuse passwords remain exposed while you deliberate. Impersonation attempts follow breaches, and silent customers are easy targets. Where a breach is likely to result in high risk, Article 34 requires communication to data subjects without undue delay, in clear language.
Fix: Notify in stages. State what you know: the categories of data involved, which groups are affected, and what isn't affected, such as payment card data not held in the compromised service. Say plainly that the investigation continues. Give specific actions: change reused passwords elsewhere, and treat unsolicited messages with suspicion. State that you will never ask for passwords, PINs, or authentication codes. Update as facts firm up.
Prevention Checklist
- Maintain a living inventory of every cloud service holding personal data, with a named owner for each.
- Enforce retention schedules, including guest, campaign, and former-member data, with automated deletion.
- Document encryption and hashing per field, key custody, and key separation.
- Review each processor against Article 28 on a fixed cycle, not just at onboarding.
- Map dependencies so you can scope shutdowns and group-wide impact quickly.
- Assign decision rights for containment, breach assessment, and notification, with deputies.
- Pre-draft Article 33 and Article 34 notification templates.
- Run a tabletop exercise each year based on a processor-side compromise.
- Prepare customer guidance on password reuse and impersonation before you need it.
None of this is novel. The teams that handle cloud compromises effectively are those that did the groundwork before the files appeared.
