A ransomware attack on Japanese cloud provider IDC Frontier disrupted services used by 495 companies and local authorities. The incident began on 7 October 2026, at around 03:40 local time, according to the provider’s confirmation that day.
For customers, the hardest question soon became whether they could recover their data. On 8 October, IDC Frontier warned that recovery in the affected part of its cloud would depend on backups held by customers themselves.
That distinction matters to any organization buying cloud services. Having a supplier run your systems does not, by itself, tell you how you will recover if those systems become unavailable.
What customers were told about recovery
IDC Frontier identified four affected zones in East Japan Region 1: tesla, henry, pascal and joule. In its 8 October update, it said retrieving or restoring data there was expected to be difficult. It advised affected customers to rebuild in a separate environment and restore their own backups.
Ransomware can make files and systems unusable by encrypting them. Restoring service then requires usable data and somewhere safe to run the application. Buying replacement server capacity solves only part of that problem.
The consequences reach beyond the cloud customer
A business can depend on an affected cloud without having a direct contract with it. Its software or communications supplier may use that infrastructure behind the scenes.
JR East’s 9 October disclosure described disrupted member email services and possible exposure of customer information. It listed maximum affected counts of about 1.67 million Ekinet records and 390,000 Otona no Kyujitsu Club records. Those were potential exposure figures, not confirmation that all those records had been stolen. The notice concerned email services, not a shutdown of train operations.
The consequences can also affect physical work. In a 7 October notice, Nissui said its logistics subsidiary could not receive or ship goods following a systems failure. It suspected unauthorized access at a contracted data center and was investigating whether information had leaked.
These are different problems to manage: restoring operations and establishing what happened to data. An organization may need to do both, but evidence of one does not establish the other.
What remained unresolved
The initial access route was still under investigation in IDC Frontier’s 8 October notice. It would be premature to blame phishing, a stolen password or a particular software flaw.
The provider’s 9 October update described work with parent company SoftBank and external security specialists, including backup guidance, migration support and recovery planning. It was not an announcement that everything had been restored. This article reflects the notices reviewed on 11 October 2026.
Test whether your recovery plan survives a supplier outage
The practical question for your IT team is specific: can you restore an essential service if the usual cloud environment and its management tools are unavailable?
The joint CISA and FBI StopRansomware guide recommends offline, encrypted backups and regular recovery tests. It also recommends keeping an offline copy of the incident response plan. Those are general precautions, not evidence of what caused this attack.
Use a recovery exercise to answer four questions:
- Where is the usable copy? Identify who holds the backup and who can retrieve it when the primary service is down.
- What else must be rebuilt? Include application settings and access arrangements, so restoring files leads to a working service.
- How long can the business wait? Measure an actual restore and compare it with the time your teams can operate without the system.
- How will people keep working? Agree on temporary procedures and a way to communicate if the usual tools are unavailable.
Start with one service your organization cannot comfortably lose for a day. Ask its owner to demonstrate recovery, record what blocks it, and fix those gaps. A completed backup job is useful evidence; a successful restore tells you much more.
