When Your Cloud Provider Is Hit by Ransomware, Whose Backup Is It?

In the early hours of October 7, a ransomware attack took down part of IDCF Cloud, a Japanese cloud service run by IDC Frontier. The company says 495 companies and local governments were affected. Within days, some of them learned something unwelcome: for data in the hardest-hit part of the system, the only way back was a backup the customer had made on its own.

If your business runs on someone else's cloud, that sentence should get your attention. Most boards assume that "the cloud" means "someone else is handling resilience." This incident is a clear reminder of where that assumption can break.

What has been reported

IDC Frontier, which BleepingComputer describes as a SoftBank Group subsidiary, says the outage began at about 3:40 a.m. local time on October 7 in its "East Japan Region 1" data center cluster. The company stated that the disruption was caused by a ransomware attack by a third party. It cut off the region's network, shut down its systems, and suspended customers' management consoles in all regions while it verified they were safe.

Japanese reporting says customer data in four zones of that region was difficult or impossible to extract or restore, and that recovery was possible only from backups the customer itself held. The company advised customers in unaffected areas to back up their own data.

Later reporting, which I could only find in secondary sources, adds some nuance. Of the 495 affected customers, 194 had used the provider's snapshot feature, and the company said those snapshots could be retrieved. Whether they can actually be restored is being worked out customer by customer. The other 301 depend on their own backups.

On data theft, IDC Frontier says it found no trace that customer data was viewed or taken and has concluded that nothing leaked. It also said account details for 48 customers' portal logins were improperly viewed, though without evidence they were taken. Note the wording: this is based on not finding traces, and the company has not said how far back its logs reach. It is a reasonable statement, not yet a proven one.

An image circulating online, attributed to the attackers, claims they got in within seven minutes, encrypted about 3.6 petabytes, and destroyed more than 550,000 snapshots. IDC Frontier has said some images appear to match what was shown on its console, but it has not confirmed those figures. Treat them as the attackers' claims. No group has been named, and no ransom demand has been reported.

The downstream effects have been concrete. Six Apart, which hosts a blogging service on the platform, said it did not expect to recover its servers there and began migrating customers to another provider using its own backup data. Rail and airline companies in Japan also published notices about possible exposure of email-related records tied to services hosted on the platform, though several said no leak had been confirmed.

Why this belongs in your boardroom

Shared responsibility is not shared accountability

Cloud contracts divide duties. The provider secures the infrastructure; you protect your data and configuration. That division is real, but when the infrastructure fails, your customers do not call the provider. They call you. Cyber Risk Is Business Risk makes this point repeatedly: you can outsource a service, but you cannot outsource the consequences.

The Three Questions, applied to a vendor

The Three Questions are simple. What are we trying to protect? What could go wrong? What are we doing about it? Apply them to your largest cloud dependency. The first answer is probably your revenue-producing systems. The second answer needs to include "the provider is encrypted or taken offline for days." The third answer is where many companies go quiet.

Compliance is not recoverability

Many organizations can produce a vendor questionnaire, a SOC report, and a contract clause on business continuity. Those documents show that a provider has controls. They do not show that your data can be restored after the provider's worst day. The only proof is a restore test, from a copy the provider cannot reach, run by your own people.

Budget conversations

Independent backups cost money, and they feel redundant until the day they are the whole recovery plan. Frame the spend as insurance against a specific, named scenario: the platform is down and the vendor's backups are gone. That scenario has now happened to hundreds of organizations.

What to ask your CISO this week

1. Which of our critical systems run on a single cloud provider or region? Can we name them without a research project?
2. Do we hold a backup of that data that the provider's accounts cannot touch or delete? Where is it, and who controls the credentials?
3. When did we last restore from it, and how long did it take? A backup that has never been restored is a hope, not a control.
4. What does our contract actually say about data restoration after a provider-side attack? Who pays, and what is the stated recovery time?
5. If the provider's management console is unavailable for a week, how do we operate?
6. Who decides, and who speaks to customers and regulators, if the outage is not ours but the impact is?

The takeaway

The most important facts in this story are not the attackers' boasts. They are that the company confirmed the cause, that restoration for some customers depended on backups they kept themselves, and that others were left waiting on the provider. When you ask your team whether you are resilient, ask whose copy of your data they are counting on.