Ransomware protection for bookkeepers rests on one fact: if a clean copy of every client file sits somewhere the attacker cannot reach, a ransom note becomes an inconvenience. Keep offline or immutable backups and test them, apply updates quickly, filter email, use multi-factor sign-in, and write a recovery plan before you need it.
How does ransomware reach a bookkeeping practice?
Ransomware usually reaches a bookkeeping practice through a person, not a clever exploit: an email attachment that looks like an invoice, a link to a fake login page, a stolen password reused on a remote access tool, or an old laptop that missed months of updates. Once inside, it encrypts every file it can reach and demands payment.
Bookkeeping work makes some of these routes more likely than in other small businesses:
- Attachments are normal. A bookkeeper opens statements, invoices and spreadsheets from strangers' email addresses every week, so a malicious "invoice.zip" does not look out of place.
- Many logins. Each client adds portals, and a password reused on any of them can be tried elsewhere.
- Remote access. A home office that connects to an office computer through a remote desktop tool exposes that tool to the internet.
- Shared drives. One infected laptop connected to a shared drive can encrypt every client's folder, not just its own files.
Modern attacks often add a second threat. Before encrypting files, the attacker copies them out and threatens to publish them. A good backup restores the files but does not undo that copy, which is why the prevention habits later in this post matter alongside the backups.
Ransomware-proof backups for client books and statements
A ransomware-proof backup is one the attacker cannot change or delete even with full control of your computer. That means at least one copy kept offline or in storage that blocks deletion for a set period, separate credentials for the backup account, and a restore you have actually tested. A synced folder alone is not a backup.
The federal CISA #StopRansomware Guide puts this first among its recommendations: maintain offline, encrypted backups of critical data, and regularly test their availability and integrity in a recovery scenario. A backup that has never been restored is a hope, not a plan.
Backup layers for a small practice
Most small practices can reach a solid position with three layers. The settings below are examples to adapt, not a standard.
| Layer | What it protects against | Example setting |
|---|---|---|
| Cloud storage with version history | Accidental deletion, small infections | Version history kept 30 days or more |
| Separate cloud backup with deletion lock | Ransomware that reaches your main account | Daily backup, locked against deletion for 30 days, own login with MFA |
| Offline drive | Loss of every online account | Weekly copy to an external drive, unplugged and stored away from the office |
The second layer is the one most practices skip. Version history in your main cloud drive helps, but an attacker who controls that account can often delete the history too. A backup service with its own login, its own multi-factor sign-in, and a lock on deletion is much harder to undo.
What goes into the backup matters as much as how. Include client statements, workpapers, exported files, engagement letters, and any desktop accounting company files. The post on backing up client bookkeeping files covers the file list and schedule in more detail.
Testing a restore
Restore one client folder from the backup each quarter, to a spare location, and time how long it takes, because that number tells you how long the practice will be down. The step-by-step restore test for client bookkeeping backups lists what to open and record.
Update and email habits that block ransomware
Updates and email filtering block most ransomware before backups are ever needed. Turn on automatic updates for the operating system, browser and office software on every device, filter incoming mail for malicious attachments and links, and train staff to report anything odd rather than open it. Multi-factor sign-in closes the stolen-password route.
The CISA guide lists these alongside backups: patch and update software and operating systems to the latest versions, filter email at the gateway, run user awareness training, and disable macro scripts in Office files received by email. For a bookkeeping practice, the last item is easy to apply. Clients rarely need to send you a spreadsheet with active macros.
Habits worth writing down
- Update on a schedule. Automatic updates on, and a monthly check that every device actually installed them.
- Retire old devices. A laptop that no longer receives security updates should not hold client data.
- Treat unexpected attachments as suspect. Confirm with the sender by phone or a known address before opening a zip file or macro document they did not mention.
- No reused passwords. A password manager makes this practical. The guide to password managers for bookkeepers explains how to set one up across a team.
- MFA everywhere. Email, remote access, cloud storage, backups and accounting software.
- Close remote access you do not need. If the practice moved to cloud tools, turn off the old remote desktop connection.
None of these is expensive. Their weakness is that they decay quietly when nobody checks. Put a ten-minute review on the calendar each month.
Are cloud accounting files safe from ransomware?
Cloud accounting files in QuickBooks Online or Xero are not encrypted by ransomware running on your laptop, because the books live on the provider's servers rather than your disk. They are still at risk if the attacker steals your login, since anyone signed in as you can change or delete data. Local files around the books stay exposed.
A cloud ledger shifts the risk rather than removing it. Consider what still sits on local or synced storage in a typical practice:
- The client's original bank statements and the converted files made from them.
- Spreadsheets of adjustments, reconciliations and workpapers.
- Exported reports sent to clients and CPAs.
- Any desktop accounting company files you still maintain.
Statements processed in a cloud tool reduce that local pile. AutoBankConvert keeps each client's statements, rules and history in its own workspace with files encrypted in transit and at rest, so the source statements do not have to live in a synced folder on a laptop. Protect that login with multi-factor sign-in, like every other account holding client data.
A ransomware recovery plan for client files and books
A ransomware recovery plan sets out what you do in the first day: isolate infected devices, protect the accounts that are still clean, report the incident, decide whether to restore, and tell clients what they need to know. Print it and keep a copy off the network, because the plan file may be encrypted too.
The first day, step by step
- Disconnect. Take infected devices off the network and Wi-Fi. Do not wipe them yet; they hold evidence.
- Secure clean accounts. From a device you trust, change passwords and sign out sessions for email, cloud storage, backups and accounting software.
- Check the backups. Confirm the backup account is untouched before you connect anything to it.
- Report. CISA advises reporting to CISA, your local FBI field office, the FBI's Internet Crime Complaint Center or the Secret Service. Call your cyber insurer early if you have a policy, since a policy may require notice before you hire outside help.
- List what was reached. Which clients, which folders, which dates, and whether files may have been copied out.
- Restore to clean devices. Rebuild or replace infected machines, then restore files from the last clean backup.
- Tell clients. Affected clients need to know what happened and what you are doing, in plain words.
The CISA guide also recommends consulting federal law enforcement about possible decryptors before taking other steps. Whether to pay a ransom is a decision for the business owner with legal and insurance advice; payment does not guarantee the files come back, and it does nothing about data already copied out.
Retention policy limits how bad step 5 gets. Statements for clients who left years ago are files that can be stolen without serving anyone. The post on how long to keep client bank statements helps set a schedule that keeps the pile small.
Restoring books after ransomware without losing a month
Restoring books after ransomware usually leaves a gap between the last clean backup and the day of the attack. Close that gap from the source documents: download fresh statements from each client's bank for the missing days, rebuild the transactions, and reconcile each account to the bank's balance before you treat the books as current again.
Suppose a practice's last clean backup is from the 3rd and the attack hits on the 17th. Here is an example of how the two weeks come back for one client:
- Restore the client's folder and accounting file as of the 3rd.
- Request or download the bank and card statements covering the 3rd to the 17th.
- Convert those statements and import the transactions for the gap.
- Reconcile each account so the closing balance on the 17th matches the bank.
- Re-enter adjustments and journal entries made in that window, from email or notes.
- Check for filings and payments made during the gap and record them.
Step 6 is where errors hide. A sales tax remittance paid on the 10th may appear on the bank statement but not in your restored records of what was filed. The guide to recording sales tax payments explains how to post that payment so it clears the liability rather than landing as an expense.
Batch conversion helps when many clients share the same gap. A balance check confirms that each statement's opening balance plus its transactions equals its closing balance, so a statement with missing lines is flagged rather than imported. It cannot see days no statement covers, so check that the statement periods span the whole gap.
When a synced folder spreads ransomware to every device
A synced cloud folder can spread ransomware instead of stopping it. When an infected laptop encrypts files in its local copy of a synced drive, the sync client uploads the encrypted versions, and every other computer and phone on the account downloads them. Within minutes the whole practice can be looking at the same scrambled files.
This is the edge case that catches practices that thought they had a backup. Syncing is built to copy changes everywhere, and encryption is a change. Three settings limit the damage:
- Version history long enough to roll back past the attack date, and a check that your plan includes restoring a whole folder, not one file at a time.
- Ransomware detection in the cloud storage service, where offered, which can pause sync or alert you when many files change at once.
- A backup that does not sync, such as the locked cloud backup or the offline drive in the layer table above.
Also limit what each device syncs. A staff laptop that works on six clients does not need every client's folder synced locally. Fewer local copies mean less for an infection to reach, and less for an attacker to copy out.