At 3:40 a.m. on October 7, 2026, a ransomware attack hit part of IDCF Cloud, a Japanese cloud platform operated by SoftBank subsidiary IDC Frontier. The next evening, the provider told customers in four of the affected zones that their data was expected to be difficult to retrieve or restore, and that the dependable path back was a backup they had kept themselves.
The incident happened in Japan, but the assumption it exposes is common anywhere organizations have moved servers, files, and applications onto someone else’s infrastructure. Many leaders believe that because the provider runs the hardware, the provider can also give them their data back. This attack tested that belief.
Key takeaways
- A cloud provider’s resilience is built to protect its platform. Getting your data back, on your timeline, still depends on copies you control.
- An independent backup must survive the loss of the provider’s environment, its management console, and the admin credentials you use there.
- Ask your provider and your IT partner how you would rebuild somewhere else, then test that answer before you need it.
What happened at IDCF Cloud
IDC Frontier said the attack began around 3:40 a.m. local time on October 7 and attributed it to “a ransomware attack by a third party,” according to BleepingComputer. The company isolated and shut down its East Japan Region 1 data center cluster and said 495 companies and local governments use the affected service. As a precaution, it also disabled customer access to management consoles in all regions while it verified their security.
On the evening of October 8, IDC Frontier’s update went further. As reported by Impress Watch:
- Customer data in four zones of East Japan Region 1 was expected to be difficult to retrieve or restore.
- The company’s current view was that data could be restored only from backups customers held themselves.
- Customers in those zones were advised to build a separate environment and start over.
- Customers in unaffected zones and regions were also advised to back up their own data.
The difference shows up in individual customers. Six Apart, which runs the Movable Type Cloud publishing service, had 31 servers affected. It concluded recovery on IDCF Cloud was not possible and began restoring service on another provider using backup data.
Several things remain unconfirmed. As of October 9, IDC Frontier had not said how the attackers got in, who they are, whether a ransom was demanded, or whether data was stolen, according to Cybernews. Screenshots shared by customers show the attacker claiming to have “wiped 554,153 snapshots,” a claim IDC Frontier has not confirmed.
Why this matters beyond one provider
The following section is InfiniTech’s analysis.
Cloud providers are clear about this division of labor, even if customers overlook it. Microsoft’s guidance on shared responsibility in the cloud states that regardless of the type of deployment, “You’re responsible for your data, including data classification, data protection, encryption decisions, and compliance with data governance requirements.”
Provider redundancy is usually designed around hardware failures and outages. Replicas and snapshots that live inside the same platform, under the same management plane, can share that platform’s fate when an attacker reaches it. This has happened before. In August 2023, Danish hosts CloudNordic and Azero said attackers encrypted their primary and secondary backup systems and that customer data they held was lost.
The console lockout matters too. Customers in regions with no confirmed intrusion still lost console access for a time. If your only restore process runs through that console, your recovery waits on the provider’s investigation.
None of this argues for leaving the cloud. A well-run cloud platform is often more resilient than a server closet. The point is narrower: hosting and recoverability are separate questions, and only one of them is fully outsourced.
What an independent backup looks like
A backup counts as independent when it can survive a bad day for the provider. Use these criteria to judge yours:
- Separate location. At least one copy lives outside the provider’s platform, or in a separate account that the production environment cannot reach.
- Separate credentials. Someone holding your production admin login cannot delete or alter the backups.
- Offline or immutable. CISA’s #StopRansomware Guide recommends maintaining “offline, encrypted backups of critical data.” For cloud-to-cloud backups, it suggests considering a multi-cloud approach to avoid vendor lock-in.
- Restorable elsewhere. The copy is in a format you can bring up on different infrastructure, not only on the platform it came from.
- Complete enough to rebuild. Beyond files and databases, it includes server images, configurations, DNS records, firewall rules, license keys, and the documentation needed to stand everything back up. CISA calls these maintained “golden images” of critical systems.
- Tested. CISA advises organizations to “regularly test the availability and integrity of backups in a disaster recovery scenario.”
Meeting every criterion for every system costs money and adds complexity. The practical middle path is to tier your systems. Here is an illustrative example:
Imagine a 150-person distributor running its ERP system and file shares on hosted virtual servers. Its ERP database and file shares might get frequent copies to a second provider with immutable retention and a quarterly restore test. Its intranet and archive data might get a weekly copy and an annual test. Its marketing website, which can be rebuilt from source files, might need only a documented rebuild procedure. Leadership decides how long each tier can be down and how much data it can afford to lose. IT designs to those numbers.
What to do next
This week
- Map where things live. For each critical system, list who hosts it, where its backups are stored, and which account controls those backups. Flag any system whose backups sit with the same provider under the same admin login.
- Ask your provider or IT partner five questions:
- If your platform were unavailable for two weeks, where would our data be, and who could restore it?
- Are our backups stored outside your platform, in a separate account with separate credentials?
- Could someone with our production admin rights, or one of your staff, delete or change those backups?
- When did we last restore a full system from backup, and how long did it take?
- Could we restore to a different provider, and in what format?
This quarter
- Run one restore test to a different environment. Pick your most important system, restore it somewhere other than its usual home, and time it. Compare that time to what the business says it can tolerate.
- Set recovery targets with leadership. Agree on acceptable downtime and data loss for each tier. Finance and operations should own these numbers alongside IT.
- Read your contract for data recovery terms. Check what the provider commits to about your data, separate from uptime. An uptime promise does not guarantee your data comes back.
- Add a provider failure scenario to your continuity plan. Document how you would reach your backups and stand up systems if the provider’s console were unavailable for days.
How InfiniTech can help
For organizations that want help putting this in place, InfiniCare, our managed IT service, includes managed data backup to a local server and an offsite data center, data protection for Microsoft 365, and weekly health and security reports. Its routine on-site assessments with a systems alignment engineer are a natural place to work through the questions above.
The bottom line
Cloud platforms are built to keep running, and most of the time they do. When one doesn’t, your recovery depends on a copy the provider cannot lose for you. Before your next renewal, make sure you can answer three questions: where your independent copy lives, who can delete it, and how long a full restore takes.
Sources
- BleepingComputer, “Ransomware attack disrupts Japan’s IDCF Cloud used by govt clients,” October 8, 2026
- Impress Watch, “IDCF Cloud outage: data expected to be difficult to retrieve or restore” (in Japanese), October 8, 2026
- Impress Watch, “IDCF Cloud outage caused by ransomware attack, affecting 495 companies and municipalities” (in Japanese), October 8, 2026
- Cybernews, “Cyberattack on Japanese cloud firm hits railways, police and food suppliers, 495 organizations exposed,” October 9, 2026
- Microsoft Learn, “Shared responsibility in the cloud,” updated August 24, 2026
- CISA, “#StopRansomware Guide,” September 2023
- TechRadar, “Cloud hosting company customers lose all their data following ransomware attack,” August 24, 2023