Ransomware Protection: Does It Stop at "We Have Backups"?

The short answer

"We back up every day, so we're fine." Even so, when a system actually stops, you may not be able to retrieve the data you need and get back to work.

The question is not only whether a backup exists, but whether you can restore data from the point in time you need, within the time you can afford.

What a recent official publication says

On 8 September 2026, IPA (the Information-technology Promotion Agency, Japan) published a ransomware handbook for executives and updated it on 10 September. Based on interviews with organisations in Japan that suffered ransomware attacks, it sets out lessons on executive involvement, business continuity and preparing for stolen data to be exposed.

In today's intrusion-type ransomware attacks, the problem is not only encryption of data but also extortion using information the attackers have taken. In other words, even if you can restore your data, you may still need to investigate and respond to the theft of information.

"The files came back" is not "we can work again"

The following is a fictional example.

A company backs up its order data every night. The files could be restored, but the database and application settings were missing, so the order system could not be brought back to a usable state.

Getting back to work involves not just data but also applications, settings, connections to other systems and the credentials they need. Credentials must be properly protected, and you need to decide in advance who can use them during recovery.

How far back do you need to recover?

Try answering two questions.

• How many hours or days of data could you lose and still rebuild your work?
• How many hours can the system be down before it causes serious problems?

For example, with one backup a day, orders entered after the backup may be missing. If recovery takes two days, you also need to decide how to handle orders and communication in the meantime.

These conditions become concrete when you work them out with the people who actually do the work, rather than leaving them to the system staff alone.

Test a restore without breaking production

Check backups somewhere that cannot affect production, such as an isolated test environment. Avoid trial restores that overwrite important originals.

You can start by picking representative data and checking its contents. But being able to open one file is not the same as being able to recover the whole system. In the test record, note what was restored, the backup date and time, how long the restore took, what you could confirm and what issues remain.

Also, restoring straight back into an environment that was attacked risks being hit again. Recovery after an incident has to proceed while checking how far the compromise reached and whether the recovery destination is safe.

Prepare for the work that continues while systems are down

Of orders, invoicing, shipping and customer contact, decide what continues and what stops. Settle on alternative ways to record work, how to communicate, and who makes the calls.

It also matters not to keep backup contact details and procedures only inside the system that has stopped.

Example restore test record