Ransomware: three questions to review backups, access and response

If you cannot open your invoices or customer diary tomorrow, what would you use to keep working? I would start with that question before choosing another security program. It makes you look at the data that supports the working day: where it is, who can access it and how you would recover it.

Three questions can start the review. Answering them does not certify that your business is protected; each answer needs a check. I would not set a three-minute deadline for restoring data or reviewing every account.

Which backup could you recover?

Ask whoever manages your backups to show you the date of the last successful run, what it includes and the result of a test restoration. A “backup completed” notification is different from being able to open the recovered data.

The INCIBE backup guide explains the 3-2-1 strategy: three copies, counting the original, on two different types of storage, with one outside the business premises. It also recommends periodically checking integrity and recovery.

For ransomware, I would also review the access a work computer has to those backups. A permanently connected drive may contain a backup, but it is exposed if the attack can write to it. Storing it in the cloud does not establish that it is isolated either. I would ask what prevents it being modified or deleted from a compromised account. INCIBE's ransomware guide describes how connected storage and shared resources can also be affected. INCIBE recommends not paying the ransom (pp. 26 and 29): payment does not guarantee data recovery.

The test needs to resemble what you need to recover. Opening a document is useful; it does not establish that the invoicing program's database will start. As a business criterion, I would note how many hours you can be without that program and how much recent data you can afford to lose. The provider can use that to propose a specific test and backup frequency.

Who signs in with more than a password?

List email, storage, invoicing, website administration and remote access, according to the services you use. Check which accounts have multifactor authentication, including administrative ones. Before changing it, prepare a recovery method and assign responsibility so you do not lock yourself out.

A second factor adds protection, but does not make a stolen password useless in every circumstance. Methods do not offer the same resistance to deception. Microsoft's documentation distinguishes MFA from phishing-resistant MFA: a password with an SMS or authenticator app code is not in the same category as a FIDO2 security key.

I would ask the provider to review the phishing-resistant options available in your services. MFA alone does not prevent malicious software running on a computer either. Updates, permissions and exposed access still need review; this initial list does not replace that work.

Whom do you notify if something goes wrong?

Prepare a sheet you can access even if email is down: the person responsible, the support phone number, the activity that must continue and who decides to stop a system. Rehearse it with a hypothetical case: reception cannot open shared files. Does the person there know how to report it without continuing to use the suspect computer?

Microsoft's response documentation includes isolating affected systems and investigating the scope before recovery. I would agree those first actions with support and write them on the sheet. Restoration and reconnection require checking that the attacker's access has been removed.

If an answer stops at “I think so”, set a specific task: demonstrate a restoration, review an account or rehearse reporting an incident. That way, the review ends with a test to do and someone responsible for doing it, rather than a feeling of security.