Lessons from the IDC Frontier Attack: Why a Separate Backup Saves Your Business

Imagine it’s 3:40 a.m. and your business servers stop and won’t start again. A few hours later, your cloud provider tells you your data will likely be difficult to retrieve, and that the only way back is a backup you keep yourself. That is what hundreds of IDC Frontier customers in Japan faced on October 7, 2026.

What happened at IDC Frontier?

IDC Frontier, the SoftBank Group subsidiary that runs IDCF Cloud, announced that part of its systems had been disrupted by unauthorized third-party access, a ransomware attack, starting at around 3:40 a.m. Japan time on October 7, 2026.

In its official report on October 8, IDC Frontier said 495 companies and local governments were affected. Virtual servers in four zones of East Japan Region 1 (tesla, henry, pascal, and joule) were stopped and could not be restarted. The company said data in those zones is expected to be difficult to retrieve or restore, and that in its current view, recovery is only possible from backups held by customers themselves.

Websites for Ibaraki Prefecture, Kodaira city, Tobu Zoo, and the Jiji Press news agency could no longer be viewed or updated. Rail operator JR East and credit card company View Card said up to 6.09 million records may have been accessed through email-delivery services running on IDCF Cloud, though credit card numbers, home addresses, and phone numbers were reportedly not exposed.

A message claimed to be from the attacker said the attack took just seven minutes, with more than 554,000 backup snapshots deleted and around 225 storage systems locked. These claims have not been verified, and the figures vary between reports. IDC Frontier has not disclosed how the attackers got in; the investigation is ongoing with help from a security firm.

Why did the backups disappear too?

The technical cause is still under investigation. But this attack pattern is well known, and the lesson applies to any business: a backup that lives alongside your production systems goes down with them.

Three common mistakes make backups useless when you need them most:

• Stored in the same environment. Snapshots usually sit on the same server or storage as the original data. If that storage is encrypted or fails, the snapshots go with it.
• Controlled by the same admin account. If attackers take over the console or an administrator account, they can delete backups with the same privileges before encrypting your data.
• Never tested. Many companies only discover their backups are broken or incomplete when they try to restore in the middle of a crisis.

SDxCentral cites Google security research finding that virtualization infrastructure was targeted in about 43% of the ransomware intrusions Google responded to in 2025, up from 29% in 2024. Ransomware groups use automated scripts to power off VMs, delete snapshots and backup copies, and then launch the ransomware.

In the IDC Frontier case, the customers who still had a way out were those who kept a copy of their data outside the provider’s environment.

The 3-2-1-1-0 backup rule, in plain terms

The 3-2-1-1-0 rule is a practical guide to keeping backups reliable:

• 3 copies of your data: the original plus at least two backups.
• 2 different types of media: for example local disk and cloud storage, so one failure can’t wipe out everything.
• 1 copy offsite: stored in a location and environment separate from your main systems.
• 1 immutable or offline copy: a copy that can’t be changed or deleted for a set period, or that isn’t connected to the network.
• 0 errors in restore tests: backups are tested regularly with real restores until they’re proven to work.

A 5-step checklist

1. Map your critical and personal data. List the systems that store customer, employee, and transaction data. Decide how long the business can afford to be down.
2. Separate backups from production. Keep copies in a different location and platform, with accounts and passwords separate from your server admin accounts. Turn on multi-factor authentication wherever it’s available.
3. Encrypt your backups. Make sure backup data is encrypted and the encryption key is stored safely, for example in your company password manager.
4. Test restores regularly. Schedule restore tests, at least for your most critical systems, and document the results.
5. Prepare an incident response plan. Decide who does what during an attack, including recovery procedures and any breach notifications your local data protection rules require.

This article is for general education, not legal advice. For specific compliance obligations, consult your legal advisor.

How Cloudku Cyber Protection helps

Cloudku Cyber Protection gives you a backup copy that’s separate from your servers, so your data can still be restored if a server is hacked or hit by ransomware:

• Separate cloud backup, stored in Indonesia. Backups are kept in an Acronis data center in Indonesia, separate from the servers, PCs, virtual machines, web hosting (cPanel), and websites they protect.
• AES-256 encryption. Backups are encrypted with a password only you know; not even the Cloudku team can open them.
• Anti-malware and anti-ransomware. AI-based static and behavioural detection against malware, ransomware, and zero-day attacks.
• Unlimited devices, priced by capacity. See plans and pricing.
• Additional protection on request: Microsoft 365 backup, Microsoft Entra ID, Google Workspace, and Disaster Recovery.

A separate cloud backup gives you an offsite copy on different media, two key parts of the 3-2-1-1-0 rule. Our team can help you design the other layers for your infrastructure.

Don’t wait for an attacker to test your backups

The IDC Frontier case shows that even a large cloud provider can be attacked, and that responsibility for your data copies stays with you. The question is simple: if your servers won’t start tomorrow morning, where will you restore your data from?