Last week we wrote about the ransomware attack on IDCF Cloud and why your recovery plan shouldn’t live in the same place as the problem. There’s been a big update since, and it makes a point we can’t make often enough: having a backup isn’t the same as being able to restore it. Here’s the latest, and a practical plan for testing your own backups, with no daft jargon.
What’s new: the fifth IDC Frontier report
On 14 October, IDC Frontier, the SoftBank-owned company behind IDCF Cloud, published its fifth report on the attack (IDC Frontier). Back on 8 October it had said data in four zones of its East Japan Region 1 was expected to be difficult to retrieve or restore, and could only be restored from backups customers held themselves (IDC Frontier). It has now changed that view for some customers.
Working with an outside security firm, it has confirmed the backup data is safe, and says backup data can be retrieved for 194 of the 495 affected companies and local governments: the ones that had been using IDCF Cloud’s snapshot function (IDC Frontier) (ASCII.jp). A snapshot saves the state of a virtual server’s storage at a point in time; ITmedia reports that IDCF Cloud keeps it on physically separate hardware (ITmedia).
Retrieving the data isn’t the end of it. IDC Frontier is contacting each of those customers individually about whether the retrieved data can be restored and how it will be handed over (IDC Frontier). ASCII.jp notes that server restoration is not yet complete and that recovery is being handled case by case (ASCII.jp).
Was any data leaked?
IDC Frontier says it checked how the attacker got in, its access, authentication and operation logs, and any files or settings the attacker left behind. It found no traces showing that data on customers’ virtual servers in the four zones was viewed or taken out, and no misuse or other knock-on harm so far, so it has concluded that no data leaked externally. Checks on its other zones and regions, which weren’t knocked out, are still going on (IDC Frontier).
There is one new finding. In the IDCF Cloud Portal, which customers use to start servers and check bills, the registration details of 48 companies were looked up without authorisation: company names, portal login IDs, passwords (stored as hashes, which are hard to reverse), notification email addresses and total monthly charges. For two of those companies, one email address each may include a staff member’s name. IDC Frontier found no trace of this information being taken out, and has contacted the companies concerned (IDC Frontier) (ITmedia).
What we still don’t know
IDC Frontier still hasn’t named the attackers or said publicly how they got in. Its fifth report doesn’t say what recovery options the other 301 affected customers have beyond restoring from their own backups, as it advised on 8 October (IDC Frontier), and it gives no date for a full recovery. As we said last week, a message shown to customers claimed the attacker had wiped hundreds of thousands of snapshots; that claim has never been verified (BleepingComputer), and IDC Frontier now says snapshot backups for 194 customers are safe to retrieve. At the time of writing (15 October), the fifth report is the latest update on its website.
Two kinds of backup, two very different weeks
Compare the snapshot customers with Six Apart, the company behind the Movable Type website software. Of its hosted Movable Type servers, 31 ran in the affected part of IDCF Cloud. Six Apart said it kept seven days of daily backups for every server on a different platform, Google Cloud (Six Apart). Using the backup taken at 1am on 7 October, less than three hours before the attack began, it had moved all 31 servers to another provider, Sakura Cloud, by 9pm on 8 October (Japan time), about a day and a half after the outage started (Six Apart) (ITmedia).
It wasn’t completely seamless: Six Apart warned that moving meant new IP addresses, and that some specifications such as storage might not match the old plan (Six Apart). Those are exactly the kinds of details a test restore flushes out in advance, rather than on the worst day of the year.
This isn’t a dig at the snapshot customers. Having snapshots switched on put them well ahead of anyone who had nothing. But a week on, whether and how they get their data back is still being worked out with their provider. Their recovery depends on someone else’s timetable. Six Apart’s depended on its own.
Having a backup isn’t enough: test the restore
Last week we explained the 3-2-1 rule and the upgraded 3-2-1-1-0 version. This week, the number that matters most is the last one. Here’s the full rule, as recommended by Veeam and other backup specialists (Veeam):
That “zero errors” step is the one most often skipped. A green tick saying “backup completed” only tells you a job ran. It doesn’t tell you the data is complete, that it isn’t corrupted, or that you can turn it back into a working system. Veeam, for example, links the zero to its SureBackup recovery verification feature (Veeam). Whatever tool you use, the principle is the same: prove it by restoring.
1. Schedule test restores, both file-level and full system
The NCSC says backups should be regularly tested to check they work as expected (NCSC), and that you should be able to test a restore in a way that doesn’t disrupt your live systems, as part of regular monitoring (NCSC). In practice, that means two kinds of test:
File-level, little and often: restore a few files, a folder and a mailbox each month, and check they open.
Full system, a few times a year: rebuild a whole server or key application in a separate, isolated test environment, ideally somewhere other than your main provider, and check it actually works.
Time every test, note what went wrong, and fix it. That’s where you find the forgotten database, the missing licence key or the new IP address.
2. Write down your RTO and RPO, and check your tests hit them
Your recovery time objective (RTO) is how long a system can be down before it seriously hurts the business (NIST). Your recovery point objective (RPO) is the point in time you need to be able to recover data back to (NIST); in plain English, how much recent work you can afford to lose. Six Apart’s backup was taken under three hours before the attack and its servers were running elsewhere within about a day and a half. Write down your own targets for each key system, agree them with whoever runs the business, and compare them with your test results. If a full restore takes three days and you can only cope for one, you’ve found a gap while it’s still cheap to fix.
3. Keep a copy in a separate account, and make it immutable
If the same admin login can delete your servers and your backups, one stolen password can do both. Keep at least one backup in a separate account or tenant, with its own credentials and multi-factor authentication. The NCSC recommends backups that block deletion or changes for a set period, soft-delete so “deleted” backups can still be recovered for a while, and a separate, out-of-band way into your backups so an attacker can’t lock you out of all of them (NCSC).
4. Don’t rely on the provider, or the account, that holds your live data
This week’s report shows that IDCF Cloud’s customer portal, the place customers log in to manage their servers, was itself looked up without authorisation (IDC Frontier). That’s no reason to panic, but it is a reminder that if your only backup sits behind the same provider and the same login as your live systems, it shares their bad day. Six Apart’s copy on a different platform is what let it rebuild elsewhere quickly (Six Apart).
5. Check snapshots are actually switched on, and cover everything
The dividing line in IDC Frontier’s report is simple: customers who had been using the snapshot function, and everyone else (IDC Frontier). Don’t assume yours are on. Check every server, every disk and every database, how often snapshots run and how long they’re kept, and recheck whenever you add a new server. Treat snapshots as a handy extra for quick rollbacks, not as your only backup.
6. Monitor backup jobs, and make sure someone reads the alerts
A backup that quietly stopped working three months ago is worse than useless, because you think you’re covered. The NCSC says you should get alerts for significant changes such as backups stopping, mass deletion requests or changes to retention settings, delivered in a way that still works if your own systems are compromised, such as an email to a monitored group mailbox. It adds that alerts only help if someone acts on them (NCSC). Check the backup reports every week, not just when something breaks.
Your test-restore checklist
- List every system you’d need to restore, where it runs and how it’s backed up today.
- Check snapshots and backup jobs are switched on for every server, disk and database, including new ones.
- Set an RTO and RPO for each key system, and agree them with whoever runs the business.
- Keep one copy off your main provider, in a separate account, with one copy immutable or offline.
- Restore a few files and a mailbox every month, and check they open.
- Do a full system test restore a few times a year, in an isolated environment, and time it.
- Write down what went wrong and fix it, until you get zero errors.
- Turn on alerts for failed or stopped backup jobs, and make sure a named person reads them.
References
- IDC Frontier, fifth report: progress of the investigation into the unauthorised-access outage (in Japanese), 14 October 2026
- IDC Frontier, third incident report: affected zones and data recovery (in Japanese), 8 October 2026
- ASCII.jp English Edition, “IDC Frontier: Backup Data Now Retrievable for 194 Customers”, G. Raymond, 15 October 2026
- ITmedia NEWS, “IDCF Cloud outage: backups retrievable for some customers, no data leak” (in Japanese), Yuka Okada, 15 October 2026
- BleepingComputer, “Ransomware attack disrupts Japan’s IDCF Cloud used by govt clients”, Bill Toulas, 8 October 2026
- Six Apart, “[Second report] Impact of the IDCF Cloud outage on Movable Type cloud edition” (in Japanese), 8 October 2026
- Six Apart, “[Third report] Impact of the IDCF Cloud outage on Movable Type cloud edition” (in Japanese), 9 October 2026
- ITmedia NEWS, “MT cloud edition, stopped by the IDCF Cloud outage, moves to Sakura Cloud using Google Cloud backups” (in Japanese), 8 October 2026
- Veeam, “Understanding Immutable Backups and Their Role in Cyber Resilience” (3-2-1-1-0 rule)
- National Cyber Security Centre, “Offline backups in an online world”, blog post
- National Cyber Security Centre, “Principles for ransomware-resistant cloud backups”, 22 November 2024
- NIST Computer Security Resource Center glossary, “Recovery Time Objective” (from NIST SP 800-34 Rev. 1)
- NIST Computer Security Resource Center glossary, “Recovery Point Objective” (from NIST SP 800-34 Rev. 1)
Need a hand applying any of this to your business? Get in touch — call +44 1472 564538 or email services@msl.org.uk.