Ransomware for a company with no IT department

The question a small company actually asks is not how it spreads. It is what we lose, and what gets us running again. Both answers are settled before the message appears: by where the copies live, and by whether anyone wrote down which system comes back first. A company with a reachable copy and a written order loses days. One without them has a negotiation on its hands and no way to check it.

What do the attackers take first?

The copies that would let you refuse. Then the places where work lives.

• The backup job. Not only the archive — the account that runs the job, the credentials stored in the script, the console that lists the copies. A backup whose password lives on an encrypted machine is no longer yours.
• The file server or the shared folder. Years of quotes, contracts, photos, delivery notes and the accounting export sit in one tree, mounted on every desk. It is the largest surface and the least segmented.
• The mailbox. It is how you answer customers and send invoices, and it holds the record of what was agreed. A mailbox also receives the reset links for everything else.
• The administration accounts themselves. Whoever holds them does not need to encrypt a file to cause damage; they can remove a user, change a recovery address, or close a share.

One route in is a document or link in mail — the NCSC's phishing guidance describes those messages — which is why the mailbox matters twice: it is a target, and it is where the next message arrives.

Why is "we have backups" not the answer?

Because a copy is only a copy if the credentials the attackers already hold cannot reach it. A job that writes to a mounted drive, runs under a domain account, or is administered from the same console as everything else is inside the blast radius, and destructive attacks look for it deliberately.

Three properties decide whether a copy survives, and each is a question you can answer today:

• Offline. Not mounted, not mapped, not reachable over the network between jobs. A drive that is plugged in is a drive that gets encrypted.
• Immutable. The compromised account cannot delete or overwrite it inside the retention window. "We would never delete it" describes your habits, not your permissions.
• Proven. Someone restored from it and wrote down the date. Until then it is a scheduled job with a green tick.

What comes back first, and in what order?

Mail first, then money, then stock, then the archive. The order follows what stops the business rather than what is easiest to restore.

System	Why it sits here	What "back" means
Mail	Every customer conversation and every password reset passes through it	Sending and receiving on the real domain, with the old messages
Invoicing and accounting	Cash, and the record a tax inspection asks for	Today's invoice issued, with a sequence that continues
Stock and orders	It decides what you can promise a customer	Today's movements recorded, not a snapshot laid over them
Files and archive	Mostly read-only, and asked for one document at a time	The document someone requests actually opens

NIST's contingency planning guide (SP 800-34) is the reference for this shape of plan: what must be recovered, in what order, by whom, and how you will know it worked. The order is the part companies skip, and it is the part that turns a restore into a working week.

Two details decide whether the order holds. Nothing is restored over live data without a decision: a stock figure from four days ago placed on this morning's movements is a second incident, quieter than the first. And the old system stays readable for a while, because someone will ask for last month's invoice and the restored copy may not have it.

Do we pay?

That is a business decision with a legal dimension, and not one to take from an article. What can be said plainly: paying buys a decryptor that may not work, from people who now know your company pays, and the decision belongs to the owner, with advice from a lawyer and, where relevant, the insurer and the authorities. Reporting duties differ by country, and some start a clock.

Settle it beforehand. When the message appears, the decision is made by whoever is in the office, under time pressure, with no authority to spend the money. Write the position while nothing is wrong: who decides, who must be consulted, and what the fallback is if restoring takes longer than expected.

What drill can you run in an afternoon?

One system, not the whole company: the point is to find the gap, not to rehearse a film.

1. Write the order first, in one page: mail, invoicing, stock, files, and the name of the person responsible for each.
2. Pick one system — mail or the invoicing database, whichever holds the record you cannot rebuild.
3. Restore it into an empty environment that cannot reach production, using only what the backup contains.
4. Try to delete a copy with the everyday account. If that account can, the attackers' account can too.
5. Open the documents people ask for, not the ones that are easy: a signed contract, a delivery note, last month's statement.
6. Time it, from the decision to a person who can work, and write the date, the name and what failed.

Repeat it after any change to where data lives, and put the next date in someone's diary, not a plan document.

Where this goes wrong

• "Offline" means a drive on the network. The label is written by the person who set it up, not by the attacker's permissions.
• The plan names tools, not people. "Restore from the cloud backup" is not an instruction; someone has to hold the account, the key and the phone number.
• Everything is restored to the same moment, including systems that were healthy, and the days since the copy are gone without anyone noticing.
• The mail is restored and the rules are not checked. Forwarding rules and mailbox permissions created during the incident survive a restore of the messages.
• The decision to pay is improvised, so the first offer is negotiated by someone with no mandate and no advice.
• The drill is a success and nothing is written down, so the next person repeats the same discovery in a year.

What this does not cover

This is about losing systems and getting them back, not about how an infection arrives or how to investigate one afterwards. It does not replace endpoint protection, patching or mail filtering, and it does not claim any of them stops an attack. Whether a copy counts as evidence, what an insurer requires before it pays, and what must be reported to whom are questions for a lawyer, and they differ by country and contract.

We build the recovery order and the copy it depends on: what comes back first, who restores it, and the afternoon when someone proves it works.