A Ransomware Attack Took Down 495 Companies' Cloud Servers. The Backups Were Inside

What happened to IDCF Cloud

At roughly 3:40 a.m. JST on October 7, a ransomware attack hit IDCF Cloud, the cloud service run by IDC Frontier, a SoftBank-owned infrastructure provider. The company disconnected the affected region, East Japan Region 1, from the broader network and halted active systems to stop the attack from spreading.

The blast radius was large: 495 companies and local governments lost access to their virtual servers. Named victims included Ibaraki Prefecture, the Ibaraki prefectural police, and a Nissui logistics subsidiary whose nationwide hub operations were disrupted. For organizations that had moved their operations to the cloud precisely to avoid running their own servers, the outage was a rude reminder that outsourcing infrastructure does not outsource risk.

Then came the second blow. On October 8, IDC Frontier told customers that data stored across four zones of the East Japan Region 1 cluster may be difficult or impossible to retrieve. Recovery, if it happens at all, will depend entirely on backups the customers themselves kept outside IDCF Cloud.

The backup failure at the heart of it

Ransomware attacks on cloud providers are not new. What makes the IDCF incident stand out is the data-loss question. An outage is painful; losing data permanently is a different category of disaster.

At least one Japanese prefecture told reporters it could not access its own backup data once IDC Frontier's systems went down. Think about what that means: the backups existed, but they were stored inside the same infrastructure that was attacked. When the cloud went down, the safety net went down with it. That is the textbook cloud backup failure, and it is far more common than anyone in the industry likes to admit.

Backups that live in the same account, the same region, or the same provider as the primary data are not really backups. They are copies with the same fate. A ransomware operator who gains control of your cloud environment can encrypt or delete those copies too, and several major incidents in recent years have followed exactly that pattern.

IDC Frontier has not named the attacker group, confirmed a restoration timeline, or disclosed whether a ransom demand was received. Those gaps are normal in the first days of an incident. But for the 495 affected organizations, the uncertainty is the point: they do not know when services return, or whether their data is gone for good.

What this means for anyone running on someone else's cloud

The 3-2-1 rule still applies, and the IDCF incident is a perfect illustration of why. Keep three copies of your data, on two different media, with one copy off-site. For cloud workloads, "off-site" has to mean off-provider: a different cloud, a different account, or on-premises storage that an attacker in your primary cloud cannot reach.

Test your restores. A backup you have never restored from is a theory, not a safety net. Schedule a restore test at least quarterly, and time it. If restoring your core systems takes three days, that is a business decision you should make deliberately, not discover during a crisis.

Know your provider's responsibilities, and yours. Cloud providers secure the infrastructure; you secure your data and your configuration. The shared-responsibility model is printed in every cloud contract, and it means the provider is not your backup strategy.

Have an exit plan. If your provider goes down for a week, can you run degraded operations elsewhere? You do not need a full hot standby to benefit from this thinking. Even a documented list of which systems matter most, and where their data lives, puts you ahead of most organizations.

Questions to ask your provider this week

The IDCF incident is a good prompt for a conversation with your own cloud provider:

• Are my backups stored in a separate account and region, with separate credentials?
• Are backups immutable, meaning they cannot be deleted or encrypted even by an administrator account?
• What is your recovery time objective, and when did you last test it?
• How will you communicate with me during an incident, and through what channel if your own systems are down?
• What happens to my data if your company, not just your servers, has a bad week?

The AI datacenter boom has put more critical workloads on cloud infrastructure than ever before, and the October breach wave showed that attackers are organized and persistent. The cloud is still the right choice for most workloads. But the IDCF incident is a reminder that "in the cloud" is not a backup strategy, and "my provider handles it" is not a disaster recovery plan. Your backups need to survive the worst day your provider ever has, because that is the day you will need them.