Companion animal in a veterinary practice workspace.
Practice2026-05-22 · 19 min read

Veterinary PIMS Cybersecurity Backup Drill: Ransomware Readiness for Independent Practices

How to run a quarterly ransomware backup drill for a veterinary clinic: 3-2-1-1-0 backups, immutable copies, restore testing, role-based access, vendor responsibilities, and the downtime log.

Ran Chen
Ran Chen
Founder, VetMedGuide. Life-sciences operator and 10× global market-access lead.
Published

In late October 2019, the Ryuk ransomware variant encrypted Microsoft Active Directory and Exchange servers at National Veterinary Associates' support center. By morning, approximately 400 of NVA's roughly 700 hospitals were infected, lost access to their practice information management software, and "were immediately unable to provide care," according to internal communications obtained by KrebsOnSecurity. Recovery took weeks; some affected hospitals were reportedly still feeling residual effects months later. NVA had been hit by Ryuk earlier that same year — the second compromise suggested the first had not been fully remediated.

The veterinary trade has not gotten safer since. Healthcare-adjacent sectors are prime ransomware targets because data is time-sensitive and downtime is expensive, and most independent practices lack the enterprise security stack that a hospital corporate parent maintains. The 2024 Change Healthcare attack alone disrupted clinical and financial workflows across the U.S. healthcare system for months — VA officials reported in mid-2024 that some payment workflows would not be fully restored until February 2025. Sixty-seven percent of healthcare organizations were hit by ransomware in 2024, nearly double the 2021 rate (Medical ITG). The average post-ransomware downtime in 2024 was approximately three weeks in both U.S. and UK organizations (Cutover), and the mean data-recovery cost of a successful attack was $1.82 million. CISA reports ransomware attacks "hit a new target every 14 seconds."

For an independent companion-animal practice running $1.5M annual revenue, three weeks of downtime is roughly $87,000 in lost gross revenue plus the multi-month effect of client churn — even before paying a ransom, paying forensics, or paying breach-notification costs. The math on a backup drill that prevents that outcome is not subtle.

The question for an independent veterinary practice is not whether the backup will be needed but whether it will work the day it is needed. This article describes the quarterly backup drill — a structured, scheduled, documented test of your practice's ability to restore service after a ransomware event — and the 3-2-1-1-0 backup architecture, role-based access controls, and vendor accountability the drill validates.

What the drill is testing

A backup drill is not the same as "we run backups." Three failure modes specifically defeat veterinary practices that thought they were prepared:

  1. The backup runs but cannot be restored. A backup file that has been silently corrupting for six months looks healthy on the storage dashboard and fails when read. LUCCA's veterinary security writeups describe this as the single most common reason a clinic with backups still pays a ransom — the backup file existed, but it would not restore.
  2. The backup is reachable from the production network. Modern ransomware variants — Ryuk, LockBit, Phobos, Medusa — actively hunt for backup files on the same network they encrypt. If the only "off-site" copy is a Synology NAS in the back room joined to the same domain, the attacker encrypts it too.
  3. The runbook lives in someone's head. When the senior tech who knew the restore procedure is on vacation and the practice manager is staring at a ransom note, the institutional knowledge of how to recover does not exist on paper anywhere.

The drill tests all three. It is not a tabletop discussion of what we would do — it is an exercise in actually restoring a representative dataset to an isolated environment and verifying the restored data is usable.

The architecture the drill is validating: 3-2-1-1-0

CISA endorses the 3-2-1 rule as the practical baseline for small-business backup, and modern ransomware-aware variants extend it to 3-2-1-1-0:

  • 3 copies of the data (one production + two backups).
  • 2 different media types (e.g., a local NAS + cloud object storage).
  • 1 copy stored off-site.
  • 1 copy immutable or air-gapped — cannot be modified or deleted within its retention window, even by an administrator account that has been compromised.
  • 0 errors when verified — every backup is tested.

For a single-site veterinary clinic on a cloud PIMS plus a few on-premise systems (imaging server, server-based legacy PIMS, lab analyzers, document store), a realistic implementation looks like:

Copy What Media Off-site? Immutable?
1 Production data PIMS database + imaging server + file shares No No
2 Local backup On-prem NAS or backup appliance No No (rapid restore)
3 Cloud backup Object storage with object-lock / WORM (Wasabi, Backblaze B2, AWS S3 with Object Lock, Azure Blob with immutability policy) Yes Yes

For a multi-site or hospital-group operation, add a fourth copy: a separate cloud account on a different identity provider, so a credential compromise on the primary cloud does not destroy the backup of last resort.

Why immutability matters. When LockBit, Ryuk, or similar variants land on an admin account, they delete or encrypt the backup repository before they encrypt production — to remove the recovery path. An immutable object-lock copy cannot be deleted within its retention window even by a compromised administrator. SentinelOne and Veeam both frame this as "the most important single change a small business can make to its backup posture" — and it is the cheapest. Object lock is included with the storage at most providers; you turn it on per bucket.

What the PIMS vendor backs up — and what it does not

A cloud PIMS contract is not a backup. Read the agreement carefully. Three patterns repeat:

  • Cloud PIMS vendors back up the database for service continuity, not customer recovery. ezyVet, Provet, Shepherd, Instinct EMR, Cornerstone Cloud, Avimark Cloud, Vetspire, and Digitail all run their own infrastructure backups. Those backups exist to restore the vendor's service after the vendor has an incident. Customer-side restore (the customer requests a copy of their own data on a specific date) is a separate contractual entitlement. Some vendors offer it; some charge for it; some only offer it during contract termination.
  • Imaging and lab data often lives outside the PIMS. Digital radiography images on the imaging-server hard drive, ultrasound clips on the cart, in-house lab analyzer flat files — none of these are in the PIMS database. If the imaging server is the on-premise machine that gets ransomwared, your local DR images go with it unless you have a separate backup target.
  • Document attachments and front-desk file shares. Most clinics store estimates, consent forms, intake PDFs, lab outputs, payroll records, and HR files on a shared file system. These are not in the PIMS. They are in the easiest folder for the receptionist to find, which is also the easiest folder for an attacker to find.

The drill must restore all four data classes — PIMS database, imaging library, document store, and any standalone analyzer exports — not just the PIMS.

Role-based access control: the prerequisite

A drill cannot validate a system whose access controls are wrong. Before the first drill, fix the access model:

  • Unique logins per employee. No shared receptionist accounts.
  • Multi-factor authentication on all administrator-level accounts, all email, and the PIMS. This is the single highest-leverage control. The Vetandtech, LUCCA, and Mandelbaum Barrett veterinary IT writeups all rank MFA as the #1 control.
  • Role-based permissions. The receptionist does not need the database-export role. The DVM does not need to install software. The kennel attendant does not need PIMS access at all.
  • Local-admin lockdown on workstations. Standard accounts for daily work; named local-admin accounts only when needed.
  • Separated backup credentials. The account that writes backups should not be a domain admin. The account that restores backups should be a separate account from the account that writes them. Object-lock retention should be configured by an account that cannot itself remove the lock.
  • Vendor accounts. Any PIMS-vendor, imaging-vendor, lab-vendor, or remote-support account on your network should be reviewed and disabled when not in active use, and MFA-enforced when in use. Most veterinary cyber incidents that LUCCA documents trace back to either a phished employee credential or an unsecured vendor account.

If role-based access is wrong, the drill will appear to succeed and the production environment will still be vulnerable on the day of the actual incident. Fix the controls first.

The quarterly drill: an actual procedure

Timing

Schedule four 90-minute drills per year. Anchor them to a fixed cadence (first Tuesday of the second month of every quarter, for example) so they happen.

Roles

Name them in writing:

  • Incident commander. Usually the practice manager. Runs the drill, decides scope.
  • Technical lead. Internal IT, MSP, or the PIMS vendor's customer support. Drives the restore.
  • Clinical operations lead. Senior DVM or medical director. Validates that restored data is clinically usable (right patients, right records, right history).
  • Communications lead. Decides what the team and clients see during a real incident. (Tested in the drill.)
  • Observer. Watches and writes the after-action report. Often the practice owner or a board member.

Drill scope by quarter

Rotate the scope so the drill stays useful and does not become rote:

  • Q1 — restore validation drill. Pull a single PIMS database backup from the immutable copy. Restore it to a sandbox environment (a separate VM, a dev tenant, or the vendor's sandbox). Open the restored database. Verify three patient records the medical director picks at random. Verify lab results, controlled-substance logs, and prescription history are intact. Time the entire process.
  • Q2 — full-stack tabletop with partial restore. Simulate a ransomware event. Incident commander declares it 8:30 AM Tuesday. Walk through containment (disconnect from internet, isolate affected machines) and the first 24 hours. Restore one component (imaging server library, document share, or PIMS) from the immutable copy. Verify it.
  • Q3 — credential-loss drill. Simulate the senior tech's domain admin credentials being compromised at 11:00 PM Saturday. Walk through the rotation of credentials, the audit of recently created accounts, and the verification that the immutable backup retention was untouched. Restore one dataset from the air-gapped copy to confirm the air-gapped path still works.
  • Q4 — full restore-from-zero drill. Stand up the PIMS, imaging, and document store in an isolated environment from backups only. Time it. Identify the components that took longest. Update the runbook.

Acrisure's small-business cyber-resilience guidance recommends "running a tabletop exercise plus a backup restoration test plus a failover drill — the best part: you don't have to take your live environment down to do it; run it as a parallel test." This matches the quarter-rotation pattern above.

Recovery time objective and recovery point objective

The drill produces two numbers. Both belong in the after-action report and the next contract negotiation.

  • Recovery Time Objective (RTO). The maximum acceptable downtime. For a single-site GP clinic, an RTO of 24 hours is realistic on a cloud PIMS with a working immutable backup. An RTO of 48–72 hours is realistic for imaging and document restore. Anything longer means significant lost revenue, deferred care, and client attrition — measure against the practice's average daily revenue to set a defensible target.
  • Recovery Point Objective (RPO). The maximum acceptable data loss. If your last good backup is from 23:00 the night before, the RPO is the work done between 23:00 and the moment of compromise. A 24-hour RPO loses one clinical day. A 1-hour RPO loses one client appointment slot.

If the measured restore time is 56 hours and the RTO target is 24 hours, the drill has succeeded — it found the gap before the real event. Adjust the architecture: more frequent backup intervals, smaller restore units, parallel restore of imaging and PIMS.

The runbook

A runbook is the document the technical lead opens during a real incident. It is not a policy document — it is a sequence of actions. The fields:

  1. First 30 minutes.
    • Who declares the incident, and what triggers a declaration (ransom note, unexplained file encryption, PIMS unresponsive, suspicious account activity).
    • Disconnect the internet uplink and isolate affected machines.
    • Lock the doors on the server room, if any.
    • Stop further damage by shutting down workstations rather than rebooting them.
    • Call the cyber-insurance carrier (most policies require notification within hours and have a 24/7 incident-response hotline).
  2. First 4 hours.
    • Identify what was encrypted. Identify what the attacker had access to (lateral movement, data exfiltration).
    • Engage the MSP / IT vendor / forensic firm the cyber-insurance carrier names.
    • Engage law enforcement (FBI IC3 portal for ransomware; state attorney general if PHI/PII exfiltration is suspected).
    • Engage legal counsel for breach-notification obligations under state law.
  3. First 24 hours.
    • Validate immutable backups are intact.
    • Build the restore environment (sandbox VM or cloud tenant) — not the production environment, until the production environment is known clean.
    • Restore PIMS database from the immutable copy. Verify integrity.
    • Communicate with the team. Use the printed contact tree (the laminated card, not the email distribution list — email may be down).
  4. First 72 hours.
    • Restore imaging and document store.
    • Communicate with clients. Honest, brief, no speculation about scope of data exposure.
    • Decide on the ransom question (this is a board-level decision, never a single-owner decision, and the cyber-insurance carrier is part of it).
  5. Recovery and post-mortem.
    • Root-cause analysis with the forensic firm.
    • Credential rotation across all accounts. All MFA tokens re-issued.
    • State and federal breach-notification timelines met (notably the state-by-state PHI/PII rules; some have 30-day clocks).
    • Insurance claim filed.
    • 30-day, 90-day, and 180-day follow-up reviews.

Each step has a named owner from the role list. Each step has a checkbox. Each step has a "stop the line" trigger that escalates if something looks worse than expected (lateral movement to imaging server, signs of double extortion, evidence the attacker is still in the environment).

The runbook should be printed and laminated in two locations: the manager's office and the medical director's office. If the network is down, the file share is down, and the printed copy is gone, the runbook is gone.

The paper-mode workflow — the day-one survival kit

While the technical lead restores systems, the clinic still has appointments. A practice that has never thought through paper-mode operations will spend the first day improvising the same workflow ten times. The veterinary-specific paper-mode survival kit, drawn from a VIN News post-NVA practitioner writeup:

  1. Reconstruct active charts from any paper trail. Pull from chart-audit piles, the recycling bin, the controlled-substance log, the day's printed schedule (if it was printed), and the doctors' rounds notes. As one practitioner put it after the 2019 Ryuk outage: "Get creative, check your recyclable piles, go through chart-audit piles, pull from everywhere. You'll be surprised at how much you can piece together."
  2. Use a non-clinic device to build a charge spreadsheet. A personal laptop, tethered to a mobile hotspot, on a guest network — not on the affected LAN. List service codes and prices so estimates and receipts can be issued.
  3. Save copies of every paper record for re-entry once the PIMS is restored.
  4. Paper appointment book at the front desk. Pre-printed daily schedule sheets work too. This is the scheduling lifeline that prevents double-booking until the PIMS is back.
  5. Mobile credit-card readers (Square, Stripe, or your existing payment vendor's mobile reader). A Wi-Fi-disconnected point-of-sale terminal is useless; a mobile reader on the manager's phone is functional within minutes.
  6. Paper controlled-substance log. If your daily-use controlled-substance log is the PIMS module, switch to the paper log immediately — and document the switch with date, time, and witness signatures. (The DEA does not pause record-keeping requirements during a cyber incident.)
  7. Paper-to-PIMS reconciliation. After restore, every paper chart, paper charge sheet, and paper schedule has to be re-entered into the PIMS. Budget two weeks of reconciliation time after a one-week outage. E4 Health's medical-EHR recovery guidance describes this as "synchronizing mounds of paper documentation generated while EHR and other systems were blocked" — the backlog is often larger than the outage itself.

Print and laminate the paper-mode kit instructions. The whole point is to operate without the network — instructions that live only on the network are not instructions.

Downtime records — the document the inspector reads

A few state veterinary boards and AAHA accreditation surveyors are beginning to ask for downtime records as part of practice IT review. The downtime record captures:

  • the date and time the incident was declared,
  • the affected systems,
  • the manual workaround used (paper records, handwritten controlled-substance log, printed daily schedule),
  • the time of restoration,
  • the data confirmed lost (if any),
  • the breach-notification decisions made,
  • the lessons learned.

A practice that has a downtime record from an incident that was contained shows materially better-prepared posture to insurers, accreditation reviewers, and the state veterinary board than a practice that has no record because it "didn't really happen" or "we recovered in a few hours so nobody asked." Document the small events; the small events are the rehearsal for the big one.

Vendor responsibilities — what to put in the contract

When the PIMS vendor, MSP, or IT-managed-service provider is part of the recovery path, the responsibility allocation belongs in writing:

  • Restore time commitment. What is the vendor's published RTO for a customer-initiated restore? Some cloud PIMS vendors commit to hours; some commit to "best effort." Best effort is not a commitment.
  • Backup retention. How long does the vendor retain its own backup of your data? Some retain 30 days; some retain 7. Make sure the retention is long enough that an attacker who sits in your environment for a few weeks before triggering encryption (the "dwell time" pattern of human-operated ransomware) does not outlast the retention.
  • Customer-side export. Does the vendor support an on-demand customer export, and at what frequency? This is the same question covered in our PIMS data export checklist.
  • Incident notification. If the vendor itself has an incident, how quickly does it notify customers? The NVA timeline showed the second Ryuk infection was framed as a "system outage" for several days before the ransomware nature became public.
  • Forensic cooperation. If your practice has an incident and the vendor's environment is potentially implicated, does the vendor cooperate with forensic discovery?
  • MFA for vendor remote access. Any time the vendor logs into your environment, MFA is required. The contract should say so.

Cyber insurance — the safety net that requires controls

Most veterinary cyber insurance policies in 2026 will not bind without minimum controls in place. Common underwriting requirements:

  • MFA on email and remote access.
  • Endpoint detection and response (EDR), not just anti-virus.
  • Daily backups with at least one immutable or air-gapped copy.
  • Documented incident-response plan and tested restore.
  • Security-awareness training for staff (phishing simulations).

The drill is not just a recovery exercise. It is part of the underwriting evidence. Carriers increasingly ask for the date of the last successful restore test on the application form. "We have backups" is not a satisfactory answer; "we restored a 7-day-old backup to a sandbox on 2026-04-14 in 3 hours 22 minutes and verified clinical records were intact" is.

What "good" looks like at the end of the year

A single-site general practice that has done four drills in a year produces:

  • four after-action reports, each with a measured RTO and RPO and a list of gaps closed;
  • a runbook that has been edited four times — not invented once and forgotten;
  • an immutable backup retention that has been confirmed intact at each drill;
  • a printed contact tree that is current;
  • a cyber-insurance application that lists the date and result of the most recent drill;
  • a team that has done the muscle-memory work of declaring the incident, isolating systems, and beginning recovery without panic;
  • a downtime record from at least one small real event, used to refine the runbook.

The drill does not prevent ransomware. It controls the cost when ransomware happens. A clinic that restores in 24 hours is open the next morning. A clinic that restores in 14 days has lost two weeks of revenue, a meaningful share of its clients, and the institutional confidence of its team — and may not survive the next year. The difference between those two outcomes is rarely the security stack and almost always the rehearsal.

Sources