When a Japanese household-products manufacturer disclosed that personal information on up to 7.7 million people may have been exposed through unauthorized access to an external cloud service, the reaction in many boardrooms was predictable. Some called it a vendor problem. Others called it a cloud problem. Neither framing helps you.
Third-party risk myths persist because they're comfortable. They let you believe the hard part of security ends at your contract's signature page. The Iris Ohyama incident, which affected customers of its Iris Plaza online store, offers a clear set of facts to test those beliefs against.
Myth 1: "If the breach happened at the vendor, it's the vendor's liability."
Reality: Your customers don't know your vendor's name. They know yours. In this case, the company that suspended its online store, notified Japan's Personal Information Protection Commission and police, and answered to the public was Iris Ohyama, not the cloud provider.
Regulators and plaintiffs follow the same logic. Under most breach notification requirements, the entity that collected the data carries the duty to notify, regardless of where the data sat. Contractual indemnities may help you recover costs later, but they don't transfer your obligations or your reputational exposure. Treat vendor-hosted data as your data, because legally and commercially, it is.
Myth 2: "Encrypted passwords mean the exposure is minor."
Reality: Encryption limits damage; it doesn't erase it. The company said passwords for active members were stored in encrypted form, though it didn't specify the scheme. That detail matters enormously. Passwords protected by a strong, salted, slow hashing function are expensive to crack at scale. Passwords protected by weak or reversible methods are not.
Also consider what else was potentially exposed: full names, physical addresses, phone numbers, email addresses, gender, and dates of birth. That combination is exactly what's needed for targeted phishing and identity fraud, and no password encryption touches it. If your data protection strategy focuses on credentials alone, you've protected the least interesting part of the dataset to an attacker.
Myth 3: "No credit card data was involved, so the incident is low severity."
Reality: Payment data is the category everyone knows how to price, which is why its absence feels like relief. The company confirmed card information wasn't stored in the affected cloud service, and that's a genuine mitigating factor. But severity isn't measured only by card fraud.
Up to 5.8 million registered and former members, plus 1.9 million non-members, were potentially in scope. That's a population large enough to drive notification costs, call center load, legal review, and regulatory scrutiny regardless of whether a single card was compromised. Under a Stand-Alone Cyber Policy, those response costs are often the bulk of a first-party claim. Scale of identity data, not just sensitivity of any one field, drives your loss.
Myth 4: "Fast shutdown and early disclosure prove the response was handled well."
Reality: Speed is necessary, not sufficient. The company suspended Iris Plaza and related systems on October 28 and notified the regulator and police on October 29. That's a quick containment and notification sequence, and it's worth emulating.
But the initial public disclosure was limited in detail, and weeks later the company was still working to determine how many records and individuals were affected. That's normal; scoping a cloud breach takes time. The lesson isn't that early disclosure is a trap. It's that you should pre-plan what you'll say when you don't yet have the numbers. Decide in advance who approves holding statements, when your Breach Coach gets involved, and how you'll update customers as the count firms up. Under your policy, check whether Insurer Consent Requirement language affects the timing of public statements or vendor engagement. First Notice of Loss should go out early, even when the facts are incomplete.
Myth 5: "A vendor security questionnaire is third-party risk management."
Reality: A questionnaire captures what a vendor says about itself at a point in time. It doesn't tell you whether access to your data is monitored, whether credentials to that cloud environment are protected with multi-factor authentication, or how quickly the vendor would detect a suspicious file. In this incident, the company's own discovery was a suspicious file in the external service, a reminder that detection capability inside the vendor environment determines how long exposure lasts.
Effective third-party risk management maps to the NIST CSF Core Functions, not just Identify. You need to know which vendors hold what data (Identify), restrict and encrypt it (Protect), monitor for anomalies in the shared environment (Detect), agree on joint playbooks (Respond), and rehearse restoration (Recover). Where your operations depend on a vendor to function, also confirm whether you have Contingent Business Interruption coverage, since a suspended storefront stops revenue even when your own systems are untouched.
What to Do Instead
Start with a data-location inventory: which third parties hold Nonpublic Information about your customers, and in what form. Rank them by record volume and data sensitivity, not by contract value.
Then tighten the controls you actually own. Require customer-managed encryption keys where the provider offers them, so a compromised cloud account doesn't automatically mean readable data. Specify password hashing standards in your own architecture reviews. Minimize what you send to vendors in the first place; data you never shared can't be exposed.
Finally, rehearse the first 72 hours with a vendor-breach scenario. Test who calls the Breach Coach, who drafts the holding statement, how you'll suspend customer-facing systems, and how quickly you can estimate affected population. Align the plan to your Breach Notification Requirements and, where relevant, NIS2 or CIRCIA reporting clocks.
The reliance on cloud services isn't a ticking time bomb. Unexamined reliance is.
