A Cybersecurity Incident Response Plan for Ohio Public Entities: The Duties Most Templates Miss
It is the one control ORC 9.64 and your cyber insurer both require. Here is what a public-entity plan must contain, the Ohio notification clocks it has to encode, and how to build one your team can actually run at 2 a.m.
By William Bradshaw | July 6, 2026 | 11 min read
Most of a cybersecurity program is built to prevent an incident. The incident response plan is the part that assumes prevention failed. For an Ohio township, fire or EMS district, or municipal office, it is also the one control that two very different audiences both insist on: ORC 9.64 asks for it as a program element, and the cyber insurance underwriter asks for it as a condition of coverage. A subdivision can defer a lot of things. A written, exercised response plan is not one of them.
The problem with most plans is not that they are missing. It is that they were downloaded from a generic template, filled in once, and filed. A generic template does not know that Ohio law puts hard clocks on a public entity after a breach, or that paying a ransom is not a decision the IT lead can make alone. When an incident hits, those omissions are exactly what turns a bad day into a compliance failure on top of a security failure.
This article walks what a public-entity incident response plan has to contain, the Ohio-specific statutory duties that belong in it and rarely make it into an off-the-shelf template, and how a network assessment and a recurring scan build the visibility the plan depends on. If you are already running an ORC 9.64 program, this is the Respond-and-Recover half of it; our guide to maintaining ORC 9.64 after July 1 covers the recurring rhythm the rest of the program runs on.
A Plan Is a Control, Not a Document
The reason underwriters ask whether your plan has been exercised, not just whether it exists, is that they have seen what happens to plans that have not been. An incident is a bad time to discover that the phone number for your IT vendor is two people out of date, that no one is sure who is allowed to disconnect a server, or that the backup everyone assumed was current has been failing silently for a month. A plan that has never been walked through is a set of assumptions, and assumptions are what fail under pressure.
For a public entity, the stakes are compounded by the audience. A township does not respond to an incident in private. It answers to a board, to residents, to the Auditor of State, and increasingly to a cyber insurance carrier whose coverage depends on the entity having done what it attested to. Each of those relationships has its own timeline and its own expectations, and a plan that only covers the technical steps of containment misses most of them.
The good news is that a usable plan is short. It is not the multi-hundred-page document a large enterprise maintains. For a small subdivision, the working plan is a handful of pages that any staff member could pick up during an incident and follow: who is in charge, who to call and in what order, what clocks are running, what to preserve, and how to get systems back. Length is not the goal. The goal is that the plan answers the questions that come up in the first hour, and that the people named in it have seen it before the day they need it.
The Ohio Duties Your Plan Has to Encode
This is where a generic template falls short for an Ohio political subdivision. ORC 9.64 attaches specific obligations to a cybersecurity incident, and those obligations run on clocks that start at discovery. If the plan does not name them, the entity can handle the technical response competently and still miss a statutory deadline. Build these three into the plan so the response and the compliance duties move together.
Notify Ohio Homeland Security within 7 days
A cybersecurity incident or ransomware event triggers a notice to the Ohio Department of Public Safety's homeland security division. Seven days is not long once an incident is underway, so the plan should name who owns this notification and where the contact channel is recorded, decided before the clock starts rather than looked up during the response.
Notify the Auditor of State within 30 days
The Auditor of State receives a separate notification on a longer clock. Thirty days feels comfortable on day one and disappears quickly once recovery and cleanup consume the calendar. Assign the owner and the format in the plan so it is not the item that slips while everyone is focused on restoring service.
A ransom cannot be paid without a legislative resolution
A political subdivision may not pay a ransomware demand without a formal resolution adopted by its legislative authority. That vote cannot be arranged in the hours an attacker's deadline allows, which is precisely why the decision framework belongs in the plan in advance: who convenes the board, what the entity's default posture is, and how the legal and insurance coordination happens if the question ever arises.
None of this replaces legal counsel. Statutory language and timelines change, and the point of naming these duties in the plan is to make sure the entity confirms and honors them, not to substitute a web article for an attorney. Treat the plan as the place where the response team and counsel have already agreed who does what, so the incident is spent executing rather than researching. Our ORC 9.64 readiness guide covers where these duties sit inside the broader program.
What the Plan Has to Contain
A plan a small entity can actually run comes down to a handful of components. Each one answers a question that reliably comes up in the first hour of an incident, when confusion is highest and the temptation to improvise is strongest.
A named incident lead and clear roles
One person is in charge of the response, with a named backup. The plan states who can authorize disruptive actions like isolating a system or shutting down a service, so no one waits for permission that is not coming and no one acts without authority they do not have.
A contact and escalation tree
Who to call, in what order, with current numbers: the IT lead, the managed provider, the cyber insurance breach hotline, legal counsel, and the board chair or administrator. Most policies require you to call the carrier's breach line before engaging any outside vendor, so that call belongs at the top of the tree.
The notification clocks
The 7-day Homeland Security notice and the 30-day Auditor of State notice, each with a named owner. Writing the clocks into the plan is what keeps a competent technical response from becoming a compliance miss.
Evidence preservation
Guidance to preserve logs and system state rather than wiping and rebuilding on instinct. The carrier's forensics team, and any later review, depend on evidence that a well-meaning cleanup can destroy in minutes.
Communications and public records
Who speaks for the entity, what is said and when, and how the public-records obligations of a government body are handled during an active incident. A single designated spokesperson prevents the mixed messages that make a bad situation worse.
Recovery and a tested restore
The steps to bring systems back from backups that have been proven to restore, in a priority order set in advance. An untested backup is not a recovery plan, and the incident is the wrong time to learn the difference.
The Response Lifecycle, 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. Its Respond and Recover functions describe the same lifecycle a working incident plan follows. Mapping the plan's phases to the framework is what lets one document answer the incident, the ORC 9.64 review, and the insurance questionnaire at once.
| Phase | NIST CSF 2.0 function | What it means for a small entity |
|---|---|---|
| Prepare | Govern and Identify | Roles, contacts, and an asset inventory in place before anything happens. |
| Detect and analyze | Detect | Recognize an incident and gauge its scope from monitoring and scan history. |
| Contain | Respond | Isolate affected systems to stop the spread, on the authority the plan names. |
| Eradicate | Respond | Remove the foothold and close the path the attacker used to get in. |
| Recover | Recover | Restore from tested backups in a set priority order and confirm service is clean. |
| Post-incident review | Identify and Govern | Capture what happened, notify per the Ohio clocks, and feed the lessons back into the plan. |
The notifications are not a separate afterthought bolted onto recovery. They run in parallel from the moment an incident is confirmed, which is why the plan names their owners up front. Our compliance framework mapping guide shows how a single piece of evidence, like a documented response, can satisfy several requirements at once.
You Cannot Respond to What You Cannot See
A response plan is only as good as the visibility behind it. The Detect and Prepare phases assume you know what is on the network and what normal looks like. Many small entities discover during an incident that the inventory in their heads does not match the network on the floor: an unmanaged switch, a forgotten server still running a service, a device no one remembered was internet-facing. You cannot isolate or restore what you did not know existed.
A network assessment builds the asset inventory the Prepare phase depends on: every host, device, and service documented, so that when an incident hits, the response team is working from a map rather than a guess. That inventory is the same one ORC 9.64 and the insurance questionnaire ask for, so it does double duty the moment it exists.
A recurring vulnerability scan keeps that picture current and feeds the Detect phase: a dated history of what was open on the network makes it far easier to understand how an attacker got in and what else they could have reached. The open-source netvuln-tool scanner produces this baseline at no license cost, and Bullium's managed collection portal keeps the results current and reviewable when you want the recurring cadence handled for you. The reciprocal is the point: the same scan that supports your ORC 9.64 program and your insurance renewal is the visibility your incident response depends on. Renewal season underscores it, and our guide to cyber insurance requirements for Ohio public entities shows how the written, exercised plan sits on the underwriter checklist alongside that scan.
Frequently Asked Questions
What must an Ohio public entity incident response plan include?
A named incident lead and roles, a contact and escalation tree that includes the cyber insurance breach hotline, the Ohio notification clocks (7 days to Homeland Security, 30 days to the Auditor of State), evidence preservation, communications and public-records handling, and a tested recovery procedure. It is a short operational document that has been walked through at least once.
Does ORC 9.64 require reporting a cybersecurity incident?
Yes. A political subdivision that experiences a cybersecurity incident or ransomware event must notify Ohio Homeland Security within 7 days and the Auditor of State within 30 days. The plan should name who makes each notification. Confirm the current statutory language with counsel as part of adopting the plan.
Can an Ohio township pay a ransomware ransom?
Not without a formal resolution adopted by its legislative authority. Because that vote cannot be arranged in the time an attacker's deadline allows, the decision framework belongs in the plan in advance, not improvised during the incident.
Do cyber insurers require a written incident response plan?
Yes. A written and exercised plan is a standard item on the cyber insurance questionnaire. Most policies also require that you call the carrier's breach line before engaging outside vendors, so that instruction should be the first step in the plan.
How often should we test the plan?
At least annually, and after any significant change in staff, systems, or vendors. A one-hour tabletop exercise against a realistic scenario is enough to surface the gaps that matter, and it satisfies the exercised-plan expectation underwriters look for.
Build a Plan Your Team Can Run at 2 a.m.
Bullium works with Ohio townships, fire districts, and public entities to write an incident response plan that fits a lean team, encodes the ORC 9.64 notification duties, and stands up to a cyber insurer's questionnaire. We start with a network assessment so the plan rests on an accurate inventory, then walk your team through it in a tabletop so it is exercised before it is needed. No commitment to engage further.
Related Reading
Cyber Insurance Requirements for Ohio Public Entities
The underwriter checklist that names the written, exercised plan, and the other controls a renewal scores.
ORC 9.64 After July 1, 2026
The recurring program the response plan lives inside: scanning, training, and the annual rhythm.
How to Respond to a Cyber Breach
The first-hours playbook for any organization: contain, preserve evidence, and avoid the mistakes that make a breach worse.
NIST CSF 2.0 for Local Government
The Respond and Recover functions the response lifecycle maps onto, explained for a public-sector team.
Related Services
Security Consulting
Write the incident response plan, encode the ORC 9.64 duties, and run the tabletop that exercises it.
Network Assessment
The asset inventory the Prepare phase depends on: every host, device, and service documented.
vCIO Practice
Board-level ownership of the plan: adoption, the ransom-resolution posture, and the annual review.
netvuln-tool Platform
Recurring vulnerability scanning that keeps the visibility your response plan depends on current.