A Backup Is Not a Recovery Plan: What Law Firms Should Test
How to find out whether your firm can actually restore files, calendars, email, and practice data after ransomware, device loss, or a provider outage.
“We have backups” is reassuring until someone asks when the firm last restored one.
A green check mark proves that a backup job ran. It does not prove that the right information was copied, that the copy survived an attack, that anyone can find the credentials, or that the firm can resume work before a deadline passes.
CISA’s ransomware guidance recommends maintaining offline, encrypted backups and regularly testing their availability and integrity. The testing is the part small organizations most often postpone.
Begin with the work the firm must continue
Make an inventory in the order the practice would need it after an interruption:
- upcoming deadlines and calendars;
- client and opposing-counsel contact information;
- active matter documents and email;
- practice-management records;
- trust and operating-account information;
- billing, time, and payment records;
- passwords, recovery codes, and software licenses;
- website, domain, and communication services; and
- closed files that remain subject to retention duties.
Do not assume one product contains all of this. A practice platform may back up its database without preserving third-party email, linked cloud files, accounting data, or the firm’s local templates.
Know which failures you are planning for
Different events take out different copies. A stolen laptop may leave the cloud account intact. Ransomware may encrypt both a computer and every synchronized folder. A compromised administrator may delete cloud data and its online backups. A provider outage may make healthy data temporarily unreachable.
For each critical system, ask whether the recovery copy is:
- separate from the working system;
- protected by a different administrative path;
- encrypted;
- unavailable to ordinary ransomware processes;
- covered by an appropriate retention history; and
- recoverable without help from the same device or account that just failed.
At least one current copy should be offline or otherwise immutable enough that an attacker in the production environment cannot alter it.
Put time into plain English
Security plans often use the terms recovery time objective and recovery point objective. The questions are simpler than the labels:
How long can this be unavailable? A two-day restoration may be acceptable for an old closed file and disastrous for tomorrow’s hearing calendar.
How much recent work can we afford to lose? A nightly copy can lose most of a day’s changes. Decide whether that is tolerable for each system.
These answers determine how frequently to copy data and what should be restored first.
Run a real restoration exercise
Choose a representative set: one active matter, one closed matter, an email folder, a calendar, a billing report, and several unusual documents. Restore them to a safe test location.
Check more than whether the files exist:
- Can someone other than the person who configured the backup find the instructions and credentials?
- Are filenames, folder relationships, dates, permissions, and matter links intact?
- Do the documents open, including large, encrypted, signed, and older files?
- Can the practice application read the restored database or export?
- Do calendar entries retain time zones, reminders, and responsible people?
- Do financial totals match a known report?
- How long did the restoration take?
- What had to be improvised?
Write down the result, the gaps, and the person responsible for each correction. A test that uncovers a problem has done its job.
Plan for cloud services too
Synchronization is not the same as backup. If a file is deleted or encrypted and that change synchronizes everywhere, every visible copy may be damaged together.
Ask each provider about version history, retention, administrator deletion, account recovery, export formats, and how a bulk restoration works. Download and test an independent export when the service permits it. Know whether the provider can restore one file, one matter, or the whole account, and how long that request usually takes.
Do not forget the recovery team
A technically sound backup can still fail because the only person with the key is unreachable. Keep an offline recovery packet containing essential contacts, escalation steps, account ownership, backup locations, recovery codes, and the order of restoration. Protect it like the sensitive credential set it is.
Name an alternate decision-maker. Include a way to contact staff and clients without relying on the firm’s ordinary email or phone system.
Set a schedule the firm can sustain
Test the most important data at least often enough to catch changes in systems, staff, and volume before an emergency does. Run another test after a migration, major configuration change, or backup failure. Small sample restores can happen more frequently than a full exercise.
The question is not whether a backup exists somewhere. It is whether this firm, with the people and equipment available on a bad day, can restore the right work in time to protect its clients.
Primary reference
This article is general information for legal professionals, not legal advice or an ethics opinion. Rules of professional conduct vary by jurisdiction—consult yours.