There’s an old saying in IT: “There is no cloud. It’s just someone else’s computer.” It’s a bit cheeky, but this week it stopped being a joke for hundreds of organisations in Japan.
On 7 October, ransomware hit IDCF Cloud, a cloud platform run by SoftBank-owned IDC Frontier. The provider has since told some customers that the only way to get their data back is from backups they hold themselves. Here’s what happened, and what it means for small businesses and charities in the UK, with no daft jargon.
What happened?
IDC Frontier says the incident began at around 3:40am Japan time on 7 October (7:40pm on 6 October, UK time). In its second notice that day, it confirmed that a fault in its East Japan Region 1 had been caused by a ransomware attack by a third party, and that 495 companies and local governments using IDCF Cloud were affected (IDC Frontier).
To stop the damage spreading, the company cut East Japan Region 1 off from the network and shut it down. It also switched off customer management consoles in its other regions while it checked they were safe (BleepingComputer).
NHK reported that websites for Ibaraki Prefecture’s local government and police headquarters couldn’t be reached, and that a logistics subsidiary of food producer Nissui couldn’t receive or ship goods at any of its 17 distribution centres in Japan (NHK World).
The most sobering update came on 8 October. IDC Frontier said virtual servers in four zones of East Japan Region 1 had stopped and could not be restarted, and that customer data stored there was expected to be difficult to retrieve or restore. In its view, as things stand, that data can only be restored from backups held by the customers themselves. Those customers are being advised to rebuild in a separate environment (IDC Frontier).
IDC Frontier has since set up an emergency response team with its parent company SoftBank, is working with an outside security firm, and is reporting to regulators and the police (IDC Frontier). Its latest status note, posted on 10 October, says investigation and recovery work is continuing, with no significant new facts to report (IDC Frontier).
What we still don’t know
IDC Frontier hasn’t named the attackers, said how they got in, or confirmed whether any data was stolen; NHK reported that it is checking whether information has leaked. Screenshots shared by customers before they were locked out show a message from the attacker claiming it took just seven minutes to break in, and that it reached 239 hypervisors (the software that runs virtual servers) and wiped 554,153 snapshots (BleepingComputer). None of that is confirmed: an IDC Frontier official told Kyodo the company was aware of the statement but was investigating its authenticity (The Mainichi).
Why this matters to you (even if you’ve never heard of IDC Frontier)
You may never use a Japanese cloud, but if you rely on a hosted server, a virtual machine in Azure or AWS, or a hosting company, the lessons travel.
1. Renting servers isn’t the same as protecting them.
IDCF Cloud is what’s called infrastructure as a service (IaaS): you rent virtual servers, storage and networking, and run your own systems on top. Under the shared responsibility model, the provider looks after the buildings, hardware and virtualisation layer, but your data is down to you. Microsoft’s own guidance puts it plainly: “For all cloud deployment types, you own your data and identities” (Microsoft Learn). We saw the same lesson last month, when Microsoft told some nonprofits that Microsoft 365 data it had deleted in error “cannot be recovered” (The Register).
2. Copies on the same platform aren’t a backup.
Snapshots kept inside your provider are handy for quick rollbacks, but they sit on the same platform, under the same management systems, as the thing you’re protecting. If an attacker takes control of that platform, or the provider has to switch it off, those copies can be out of reach too. The snapshot claims are unverified, but the provider’s own advice shows what mattered: copies customers held themselves.
3. You can be locked out of your own systems.
Even customers whose servers weren’t hit lost access to their management consoles while checks were carried out, and IDC Frontier has been starting and stopping servers for customers on request. Sensible, but imagine if your only route to your backups ran through that console. The UK’s National Cyber Security Centre (NCSC) recommends agreeing a separate, out-of-band way into your backups, such as a separate account or device, so an attacker can’t deny you all access (NCSC). In plain English: break-glass access.
3-2-1, and why we now say 3-2-1-1-0
The good news is that the fix isn’t complicated. The long-standing 3-2-1 rule still does most of the heavy lifting:
Veeam and other backup specialists now recommend an upgraded version, 3-2-1-1-0 (Veeam), which adds:
1 immutable, offline or air-gapped copy: a copy that can’t be changed or deleted for a set period, even by someone holding your admin passwords.
0 errors: your backups are checked by actually restoring from them, and any problems are fixed. A backup you’ve never tested is a hope, not a plan.
A backup isn’t a recovery plan
Customers in the affected zones aren’t just restoring a few files; they’re rebuilding somewhere new, which takes servers, settings, passwords and, above all, time. So alongside your backups you need a short written plan that answers four questions:
How long can you manage without it? That’s your recovery time objective (RTO). A day? A week? Be honest, then check your plan can actually hit it.
How much data can you afford to lose? That’s your recovery point objective (RPO), and it decides how often you back up.
Where will you rebuild? Another provider, another region or on-site hardware, decided in advance rather than on the day.
Who does what, and how do you reach them if email and your usual logins are down?
Tools such as Veeam can write backup copies to immutable storage, either on your own hardware or with a choice of cloud storage providers (Veeam). Other good products exist too. The brand matters less than the principle: your recovery copy, and the means to reach it, must survive your main provider having a very bad day.
Your quick cloud recovery checklist
- List what runs where: every hosted server, cloud virtual machine, website and online app, and who provides it.
- Check what your contract actually covers. Is backup included, where is it stored, and who can restore it?
- Keep at least one backup outside your main provider, in a separate account with separate passwords.
- Make one copy immutable or offline, so ransomware or a stolen admin account can’t delete it.
- Set a recovery time target for each key system, and agree it with whoever runs the business.
- Test a full restore a few times a year, not just a single file, and write down how long it took.
- Set up break-glass access: a separate admin account with strong multi-factor authentication, with details stored securely offline.
- Write a one-page recovery plan with contacts, priorities and the steps to rebuild somewhere else.
- Review it once a year, or whenever you change providers, systems or key staff.
References
- BleepingComputer, “Ransomware attack disrupts Japan’s IDCF Cloud used by govt clients”, Bill Toulas, 8 October 2026
- IDC Frontier, second incident report on unauthorised access to IDCF Cloud (in Japanese), 7 October 2026
- IDC Frontier, third incident report: affected zones and data recovery (in Japanese), 8 October 2026
- IDC Frontier, fourth incident report: emergency response arrangements (in Japanese), 9 October 2026
- IDC Frontier, homepage status update (in Japanese), 10 October 2026
- NHK World-Japan, “Japan cloud service hit by ransomware attack”, 8 October 2026
- The Mainichi (Kyodo), “SoftBank subsidiary’s cloud service disrupted in cyberattack”, 8 October 2026
- Microsoft Learn, “Shared responsibility in the cloud”
- National Cyber Security Centre, “Principles for ransomware-resistant cloud backups”, 22 November 2024
- Veeam, “Understanding Immutable Backups and Their Role in Cyber Resilience” (3-2-1-1-0 rule), updated 26 June 2026
- The Register, “Microsoft tells nonprofits their deleted M365 data isn’t coming back”, Carly Page, 28 September 2026
Need a hand applying any of this to your business? Get in touch — call +44 1472 564538 or email services@msl.org.uk.