Backup and Disaster Recovery for Ohio Public Entities: The Recovery Controls Underwriters Actually Test
Every cybersecurity control assumes a tested restore exists at the end of it. Here is what backup and recovery has to look like for a township or fire district, why cyber insurers scrutinize it more than almost anything else, and how to set a recovery objective you can defend.
By William Bradshaw | July 13, 2026 | 11 min read
Most of a cybersecurity program is built to keep an incident from happening. Backup and disaster recovery is the part that decides what a bad day costs once one does. For an Ohio township, fire or EMS district, or municipal office, recovery is the quiet assumption behind every other control: the readiness checklist, the incident response plan, and the insurance questionnaire all take for granted that somewhere there is a backup that will actually restore. That assumption is the one most likely to fail under pressure, and it fails silently, months before anyone finds out.
Cyber insurers understand this better than almost anyone, which is why backups get more scrutiny on the renewal questionnaire than nearly any other control. An underwriter has watched enough claims to know that the difference between a covered outage and an uncovered catastrophe is usually whether the entity could restore from a clean copy the attacker could not reach. Ransomware has made that a security question rather than an IT-operations footnote, because modern attackers go looking for the backups first.
This article covers what backup and recovery has to look like for a small public entity: why backup is not the same as recovery, what cyber insurers actually ask, how ransomware broke the classic backup rule and what replaced it, and how to set a recovery objective your board and your carrier will both accept. If you are already running an ORC 9.64 program, this is the Recover half of it. It sits directly alongside your incident response plan, which is where a tested restore stops being a spreadsheet line and becomes the last, most important step of the response.
Backup Is Not Recovery
A backup is a copy of your data. Recovery is the tested ability to get systems and data back into service within a time the entity can tolerate and with an amount of data loss it has agreed to accept. Those are not the same thing, and the gap between them is where most recovery plans quietly fail. An entity can run nightly backups for years, see green checkmarks every morning, and still have no recovery capability, because no one ever proved the backups restore, because the only copy sits on a server the same attacker just encrypted, or because bringing systems back would take a week the township does not have.
The failure modes are almost always discovered at the worst moment. A backup job that has been erroring for a month because a drive filled up. A restore that works for files but not for the database that actually runs utility billing. A cloud backup whose admin credentials were stored in the same password vault the attacker compromised. Each of these looks fine on a status dashboard and is only exposed by an actual restore, which is exactly why underwriters ask whether restores are tested rather than whether backups exist.
The practical rule is simple to state and easy to skip: a backup you have not restored is a hypothesis, not a recovery plan. The only way to convert one into the other is to periodically restore from it, to a separate environment, and confirm the systems come back and the data is intact. For a small entity that does not mean an elaborate program. It means a scheduled test, a documented result, and a named owner, so that the first real restore is not the first restore anyone has ever run.
What Cyber Insurers Actually Ask About Backups
The cyber insurance supplemental questionnaire is the clearest statement of what a mature backup posture looks like, because it is written by the people who pay when recovery fails. The questions are specific, and an entity that can answer them cleanly is usually one that could actually recover. Our guide to cyber insurance requirements for Ohio public entities covers the full renewal checklist; these are the backup items that carry the most weight.
Is at least one backup copy offline or immutable?
This is the question underwriters care about most. A copy that is air-gapped or write-once cannot be encrypted or deleted by an attacker who reaches the network. If every copy is online and reachable, the entity is one credential away from losing its backups along with production.
Is multi-factor authentication required to access the backup system?
The backup console is a high-value target. MFA on it, separate from the credentials that run production, keeps a single phished password from becoming both an outage and a lost recovery path.
Are backups separated from the production domain?
If a domain-administrator compromise can reach the backup infrastructure, the backups inherit the same blast radius as everything else. Separation, a different credential set and ideally a different trust boundary, is what keeps recovery possible after a full domain compromise.
Are backups encrypted, and how often are restores tested?
Encryption protects the copy at rest and in transit. Testing proves it works. Underwriters want a cadence, not a one-time answer: a documented restore test on a schedule, with the result recorded, is the evidence that the backup posture is real rather than assumed.
None of these require enterprise budgets. They require design decisions: where the offline copy lives, who holds the backup credentials, and when the restore gets tested. Those decisions are exactly the kind a vCIO engagement is meant to own on behalf of a lean team, and they are the ones an insurer rewards with a cleaner renewal. Confirm the specific requirements against your own policy and carrier, since terms vary between programs.
How Ransomware Broke the 3-2-1 Rule
For years the backup standard was 3-2-1: keep three copies of your data, on two different media types, with one copy offsite. It was designed for a world of hardware failures, fires, and floods, disasters that do not think. Ransomware thinks. A modern attacker who lands on the network goes looking for the backup server and the cloud backup credentials before deploying the payload, because destroying the recovery path is what turns an outage into a ransom payment. A copy that is online and reachable from the compromised network can be encrypted right alongside production, which means a textbook 3-2-1 setup can leave an entity with three encrypted copies.
The updated rule: 3-2-1-1-0
Keep 3 copies of your data, on 2 different media, with 1 offsite, 1 of which is offline or immutable (air-gapped or write-once, so ransomware cannot alter it), and 0 errors verified by an actual tested restore.
The two additions are the whole point. The offline or immutable copy is what survives an attacker who reaches everything else. The zero-errors requirement is what proves the copy is real. Together they close the gap that turned 3-2-1 from a safeguard into a false sense of security.
For a small public entity the immutable copy does not require exotic hardware. It can be a cloud backup with an immutability or object-lock setting enabled, a rotated set of drives kept physically disconnected, or a backup appliance that enforces write-once retention. What matters is that at least one copy lives outside the reach of a compromised domain and cannot be silently deleted. This is also where a recurring vulnerability scan earns its place: knowing which systems are exposed tells you which ones the attacker reaches first, and therefore which backups need the strongest isolation.
Setting a Recovery Objective You Can Defend
Two numbers turn backup from an IT habit into a recovery plan. The Recovery Time Objective (RTO) is how long a system can be down before the disruption becomes unacceptable. The Recovery Point Objective (RPO) is how much data the entity can afford to lose, which in practice sets how often the system must be backed up. There is no universally correct value for either, and setting them too aggressively across the board wastes money the entity does not have. The useful move is to set them per system, because not everything a township runs deserves the same objective.
| Tier | Example systems | Objective |
|---|---|---|
| Critical | Utility billing, payroll, public-safety dispatch, financials | Short RTO and RPO: back up frequently, restore first, test most often. |
| Important | Email, shared drives, permitting and records systems | Moderate objective: a day of data loss and a day to restore is usually tolerable. |
| Standard | General file storage, workstations, non-essential apps | Relaxed objective: recovered after the critical and important tiers are back. |
Tiering is what makes the objectives defensible to a board and affordable to a small budget. It concentrates the frequent backups, the immutable copies, and the restore testing on the handful of systems the community actually depends on, and it lets the standard tier ride a lighter schedule. It also gives the incident response team a priority order for the Recover phase before an incident starts, so no one is debating what to bring back first while the clock runs. Write the tiers and their objectives down once, review them when systems change, and the recovery plan stops being a guess.
The Recovery Controls, Mapped to NIST CSF 2.0
ORC 9.64 points subdivisions toward a recognized framework, and the NIST Cybersecurity Framework 2.0 is the common choice. Backup and recovery live mostly in its Protect and Recover functions, and mapping the controls to the framework is what lets one backup posture answer the ORC 9.64 program, the insurance questionnaire, and the incident response plan at the same time.
| Control | NIST CSF 2.0 function | What it means for a small entity |
|---|---|---|
| Backups created and protected | Protect (PR.DS) | Regular backups of critical systems, protected from tampering and encrypted. |
| Offline or immutable copy | Protect (PR.DS / PR.PS) | At least one copy an attacker who reaches the domain cannot alter or delete. |
| Recovery objective set | Govern and Identify | Know which systems come back first and how much data loss each can tolerate. |
| Recovery plan execution | Recover (RC.RP) | Restore to a known-good state in priority order and verify integrity before returning service. |
| Tested restore | Identify and Recover | Prove the backups restore on a schedule, and record the result as evidence. |
| Recovery communication | Recover (RC.CO) | Keep leadership, staff, and the carrier informed through the restore. |
The mapping is not busywork. It is what makes a single restore test count as evidence for the ORC 9.64 review, the insurance renewal, and the incident response tabletop at once. Our compliance framework mapping guide shows how one piece of evidence can satisfy several requirements, and the recovery controls are one of the clearest examples of that leverage.
You Can Only Recover What You Know You Have
A recovery plan is scoped by an inventory. You cannot set a recovery objective for a system you forgot you run, and you cannot restore a server whose data was never in the backup set because no one knew it held anything important. This is the same visibility gap the incident response plan runs into: the map in everyone's head rarely matches the network on the floor. An unmanaged application server, a line-of-business database on a workstation under someone's desk, a share that quietly became the system of record, each is a recovery failure waiting to be discovered during an outage.
A network assessment builds the inventory that scopes recovery: every host, service, and data store documented, so the backup set covers what actually matters and the recovery tiers reflect the real network rather than the remembered one. That inventory does double duty, because it is the same asset list the ORC 9.64 program and the insurance questionnaire ask for. The open-source netvuln-tool scanner produces the exposure baseline at no license cost, and Bullium's managed collection portal keeps it current when an entity wants the recurring cadence handled for it.
Recovery is also where the incident response loop closes. Containment and eradication stop the damage; recovery is the phase that ends the incident, and it is only as good as the tested backups behind it. That is why the backup posture and the incident response plan belong to the same program: the plan names the tested restore as its final step, and this is where that restore gets designed, isolated, and proven. Build them together and a public entity has a program that not only detects and responds, but genuinely recovers.
Frequently Asked Questions
What is the difference between backup and disaster recovery?
A backup is a copy of your data. Disaster recovery is the tested ability to get systems and data back into service within an acceptable time and with an acceptable amount of data loss. You can have current backups and no recovery capability if the restore has never been tested, if the only copy is reachable by the same attacker who hit production, or if restoring would take longer than the entity can tolerate.
What do cyber insurers require for backups?
Typically: encrypted backups, at least one offline or immutable copy, MFA on the backup system, separation from the production domain, and a documented cadence of tested restores. Backups carry heavy weight on the questionnaire because ransomware recovery depends on them. Confirm the exact requirements against your own policy and carrier.
Why did ransomware break the 3-2-1 rule?
3-2-1 assumed passive disasters, not an adversary that hunts backups. Modern ransomware looks for backup servers and cloud credentials first, so an online, reachable copy can be encrypted with production. The common update is 3-2-1-1-0: add one offline or immutable copy and verify zero errors through a tested restore.
What RTO and RPO should a small public entity set?
Set them per system rather than site-wide. Tier systems into critical, important, and standard; give each tier a defensible Recovery Time Objective and Recovery Point Objective; and size backup frequency and recovery design to meet the critical tier first. Payroll and utility billing usually need shorter objectives than a general file share.
Does ORC 9.64 require backups and disaster recovery?
ORC 9.64 requires a cybersecurity program and points to a recognized framework such as NIST CSF 2.0, whose Recover function covers backup and recovery, and tested backups are a standard insurance-questionnaire control for the same entities. It is framed as part of the overall program rather than a standalone mandate. Confirm the current statutory language with counsel.
Make Sure Your Backups Would Actually Recover
Bullium works with Ohio townships, fire districts, and public entities to design backup and recovery that fits a lean team: an immutable copy the attacker cannot reach, recovery objectives your board can defend, and a restore test that proves it all works before you need it. We start with a network assessment so the backup set covers the real network, then wire recovery into your ORC 9.64 program and your insurance renewal. No commitment to engage further.
Related Reading
A Cybersecurity Incident Response Plan for Ohio Public Entities
The Respond half of the program, whose final step is the tested restore this article designs.
Cyber Insurance Requirements for Ohio Public Entities
The renewal checklist where tested, immutable backups carry some of the heaviest weight.
ORC 9.64 After July 1, 2026
The recurring program the recovery controls live inside: scanning, training, and the annual rhythm.
NIST CSF 2.0 for Local Government
The Protect and Recover functions the backup and recovery controls map onto.
Related Services
Managed IT Services
Backup design, immutable copies, and recurring restore testing handled for a lean team.
Security Consulting
Set defensible recovery objectives, isolate the backup copy, and prove the restore in a tabletop.
Network Assessment
The inventory that scopes recovery: every host, service, and data store the backup set must cover.
vCIO Practice
Board-level ownership of the recovery objectives, the backup budget, and the annual review.