When Iris Ohyama disclosed that personal data on up to 7.7 million people may have been exposed through unauthorized access to a third-party cloud service, the details were sobering. Names, addresses, phone numbers, email addresses, gender, dates of birth, and account passwords were potentially in scope. The company suspended its online store and related systems on October 28 and notified Japan's Personal Information Protection Commission and police on October 29.
You can learn from this without knowing every technical detail of the attack. The pattern matters more than the specifics, and it's one Third-Party Governance Teams see repeatedly.
Why These Mistakes Keep Happening
Cloud services often feel like infrastructure, not vendors. Teams provision them quickly, store data in them, and then treat them as part of the furniture. Procurement closes the deal, security reviews it once, and the arrangement drops off everyone's radar. Meanwhile, the data keeps accumulating.
The result is a governance gap. Ownership is split between IT, the business unit, and procurement, so nobody owns the data's full lifecycle at the vendor. The mistakes below follow from that gap.
Mistake 1: Treating the Cloud Service as a Utility, Not a Vendor
Why it happens: Cloud storage and SaaS tools are bought like commodities. They rarely get the Criticality Classification a payment processor would, even when they hold millions of customer records.
The consequence: Weak scrutiny at Vendor Intake and no scheduled reassessment. In this incident, the exposed data sat in an external cloud service supporting a customer-facing store, and the operational impact was immediate: the store and related systems went offline.
The fix: Classify by data volume and sensitivity, not by contract value. Any service holding personal data at scale belongs in your highest review tier. Run a Pre-Contractual Assessment using SIG Core, and align your requirements to ISO 27036 for supplier relationship security. Reassess on a defined cycle and when the data footprint changes.
Mistake 2: Storing More Data Than the Business Needs
Why it happens: Data collection is cheap and deletion is nobody's job. Records pile up in the cloud environment long after they're useful.
The consequence: Exposure scales with retention. In this case, the potentially affected population included both current and former members, plus non-members. Former members were in scope for the exposure even though, as the company noted, no passwords are stored for them. That detail shows retention has a cost: people who stopped being customers can still be part of a breach.
The fix: Set retention limits in the contract and enforce them. Require the vendor to support deletion workflows, and verify them. Ask what data lives in the service, for whom, and why. If you can't answer, you're holding risk you haven't priced.
Mistake 3: Accepting "Encrypted" as an Answer
Why it happens: Questionnaires ask yes/no questions. "Are passwords encrypted?" gets a yes, and the box gets checked. Iris Plaza said it stores active members' passwords in encrypted form but didn't specify the scheme. That's a useful reminder that the word "encrypted" alone tells you very little.
The consequence: You can't judge exposure severity without knowing the method. For passwords specifically, the distinction between reversible encryption and salted, adaptive hashing changes everything about what an attacker can do with stolen data.
The fix: Replace the checkbox with specific questions:
- What algorithm and key length protect data at rest and in transit?
- For credentials, is the method a purpose-built password hashing function with unique salts?
- Who controls the encryption keys, you or the vendor?
- How often is the scheme reviewed against current guidance?
Write the answers into your Risk Scoring and revisit them annually.
Mistake 4: Skipping Incident Escalation Design Before You Need It
Why it happens: Teams assume the vendor will notify them in time and that a plan can be improvised. Contracts often say "prompt notification" without defining it.
The consequence: Delay compounds. Iris Ohyama's first public notice carried limited detail, and the company said it was still working to establish how many records were exposed and how many people were affected. Investigations take time, and early statements will be incomplete. If your vendor's Notification Timeline is vague, your own regulatory clock may start before you know anything useful.
The fix: Define the Notification Timeline in hours, not adjectives. Require the vendor to share indicators, scope, and affected data categories as they emerge. Pre-assign roles for Vendor Breach Management: who decides to suspend systems, who contacts the regulator, who drafts customer messaging. Rehearse it with a tabletop exercise that includes the vendor.
Mistake 5: Communicating Before You Can Say Anything Specific
Why it happens: Pressure to speak early collides with uncertainty. Teams either say too little or commit to figures they later have to revise.
The consequence: Updating numbers erodes trust. A staged approach works better, and the Iris Ohyama timeline illustrates it: an initial notice, then an update describing a suspicious file in the external cloud service, the categories of data at risk, what wasn't stored (credit card information), and the current status of misuse reports. As of November 5, the company had received no reports of misuse or financial loss. Stating what you know, what you don't, and what you've done is a defensible posture.
The fix: Prepare notification templates with fields for confirmed facts, unconfirmed scope, and customer actions. Because passwords are involved in incidents like this, include guidance on changing credentials, especially where people reuse them elsewhere. Keep regulators and affected individuals on a single, consistent set of facts.
Prevention Checklist
- Classify any cloud service holding personal data at scale in your top tier, regardless of spend.
- Complete a Pre-Contractual Assessment (SIG Core) before data moves.
- Include a Right to Audit and Sub-Processor Disclosure in every contract.
- Cap retention and verify deletion, including for former customers.
- Demand named encryption and password-hashing methods, plus key ownership details.
- Define the Notification Timeline in hours and the data the vendor must share.
- Maintain a Wind-Down Plan so you can suspend or exit a service without improvisation.
- Run joint tabletop exercises with critical cloud vendors annually.
- Prepare staged communication templates for regulators, customers, and employees.
- Monitor continuously: Continuous Monitoring of Active Arrangements should include external exposure signals, not just annual reviews.
The question to ask your team this week is simple: if your largest cloud repository of customer data were accessed tomorrow, could you say what's in it, how it's protected, and who has to be told within what timeframe? If not, start with Mistake 1.
