ORC 9.64 Cybersecurity Compliance: A Readiness Guide for Ohio Public Sector
Ohio townships, fire districts, and special districts must adopt a cybersecurity program by July 1, 2026. Here is what the law requires and a practical path to readiness.
By William Bradshaw | June 15, 2026 | 8 min read
If you run IT for an Ohio township, fire district, or special district, you have a deadline. Ohio Revised Code 9.64, enacted as part of Ohio House Bill 96 and effective September 30, 2025, requires every political subdivision in the state to adopt a cybersecurity program. Counties and municipal corporations were already on the hook as of January 1, 2026. Townships, fire and EMS districts, and the rest of the subdivisions have until July 1, 2026.
The good news is that the law does not ask you to invent something from scratch. It describes a program that protects the availability, confidentiality, and integrity of your data and systems, and that maps cleanly onto a recognized framework. If you have read our NIST CSF 2.0 guide for public-sector IT, most of what follows will feel familiar: ORC 9.64 is essentially a state-codified push toward the same discipline that framework already gives you.
This article explains what the statute actually requires, separates the technical requirements (the ones a vulnerability scan and an asset inventory can evidence) from the organizational attestations (the ones that need a policy and a signature), and lays out a readiness path a small IT team can execute before the deadline. It is practical guidance from a managed-services lens, not legal advice; confirm the obligations that apply to your specific entity with the statute and your legal counsel.
What ORC 9.64 Is, and Who It Covers
ORC 9.64 sits in the section of the Ohio Revised Code that governs political subdivisions, and it does one core thing: it requires every subdivision's legislative authority to adopt a cybersecurity program. The program has to safeguard the entity's data, information technology, and information technology resources, framed around the familiar security triad of availability, confidentiality, and integrity.
"Every political subdivision" is broad on purpose. It covers counties, municipal corporations, townships, school districts, fire and EMS districts, and the long tail of special districts (water, parks, transit, library, and the rest). There is no size carve-out. A township with one part-time IT contractor is as much in scope as a county with a full IT department. That is the part most small subdivisions underestimate: the law was written to reach the entities least likely to already have a formal program.
The statute is the latest in a national pattern of states moving cybersecurity expectations from "recommended best practice" to "legal requirement" for local government, driven by a steady run of ransomware incidents against under-resourced public entities. Ohio's version is notable for pairing the program mandate with concrete incident-notification duties and a hard rule on ransom payments, which we cover below.
The Two Deadlines
The compliance dates are phased by entity type. Find your row and work back from it.
Counties and municipal corporations: January 1, 2026
The first tier. If you run IT for a county or a city and have not yet adopted a program, you are already past the date and the work is overdue, not upcoming.
Townships, fire and EMS districts, and all other subdivisions: July 1, 2026
This is the deadline most readers of this article are working toward. From the publication of this guide, that is roughly two weeks out. A program adopted on paper plus a documented readiness effort is the realistic target for that window.
"Adopt a cybersecurity program" is an action by the legislative authority (the board of township trustees, the district board, the council), not just an IT task. That matters for timing: if your board meets monthly, the resolution adopting the program has to land on an agenda with enough runway to make the date. Scope the IT work and the board action in parallel, not in sequence.
The Five Technical Requirements (and How to Evidence Them)
The statute's technical divisions, ORC 9.64(C)(1) through (C)(5), describe the program's security substance. The useful insight for an IT team is that these are not abstract: they map directly onto the functions of NIST CSF 2.0, and an asset inventory plus a vulnerability scan can produce evidence for most of them. Here is the mapping we use when we build a readiness package for a subdivision.
| ORC 9.64 division | Maps to NIST CSF 2.0 | What evidences it |
|---|---|---|
| (C)(1) Identify critical functions and cybersecurity risks | Identify (Govern) | Asset inventory, a documented list of critical systems, a risk register. |
| (C)(2) Identify potential breach impacts | Identify (Risk Assessment) | A risk assessment that ties findings to the systems and data they would affect. |
| (C)(3) Mechanisms to detect cybersecurity threats and events | Detect | Vulnerability scanning, logging, monitoring, and the records they produce. |
| (C)(4) Incident analysis, communication, and containment procedures | Respond | A written incident-response plan with roles, escalation, and containment steps. |
| (C)(5) Post-incident infrastructure repair and recovery | Recover | Backup and restore procedures, tested recovery runbooks, restore logs. |
The practical takeaway: three of these five (identify functions and risks, identify breach impacts, and detect threats) are exactly what a network vulnerability scan and an asset inventory produce as output. If you have never run one, our guide on how to run a vulnerability scan on your network walks through the process, and our compliance mapping guide shows how those findings become framework evidence. The remaining two (incident response and recovery) are documents and tested procedures rather than scan output, but they are short documents, not multi-month projects.
The Four Things a Scanner Cannot Prove
Beyond the technical divisions, ORC 9.64 carries four organizational requirements that no tool can evidence for you. Each one needs a policy, a record, or a signature. These are the items most likely to be overlooked because they live with the clerk or the board rather than with IT, so assign an owner to each one explicitly.
Annual cybersecurity training, scaled to duties (9.64(C)(6))
Employees need annual training appropriate to their roles. You do not have to build it yourself: the Ohio Cyber Range Institute and other state-provided training options satisfy this requirement and are designed for exactly this audience.
Seven-day incident notice to Ohio Homeland Security (9.64(D)(1))
A cybersecurity incident or ransomware event must be reported to Ohio Homeland Security, through the Ohio Cyber Integration Center, as soon as possible and no later than 7 days after discovery. Put the contact details in your incident-response plan now, before you need them.
Thirty-day incident notice to the Auditor of State (9.64(D)(2))
The same incident must be reported to the Ohio Auditor of State no later than 30 days after discovery, using the Auditor's designated reporting process. The two notices are separate obligations with different deadlines and recipients.
No ransom payment without a legislative resolution (9.64(B))
A subdivision may not pay or comply with a ransomware demand unless its legislative authority passes a formal resolution or ordinance authorizing the payment and explaining how it serves the public interest. The decision is a public, recorded act, not an operational call made under pressure.
A Practical Readiness Path Mapped to NIST CSF 2.0
Rather than treat ORC 9.64 as a standalone checklist, adopt NIST CSF 2.0 as the organizing framework and let it carry the statute. The framework gives you a structure your auditor and your cyber-insurance carrier already recognize, and it turns "comply with ORC 9.64" into a repeatable program rather than a one-time scramble. Here is the sequence we run for a subdivision working toward the deadline.
Build the asset inventory
List every device, server, application, and data store, and flag the ones that are critical to operations. This single artifact evidences division (C)(1) and is the foundation everything else builds on.
Run a vulnerability scan and a risk assessment
Scan the inventory, then tie each finding to the system and data it would affect. That covers divisions (C)(2) and (C)(3) and gives the board a concrete picture of risk to fund against.
Write the incident-response and recovery plans
A short, role-based incident-response plan (with the 7-day and 30-day notification contacts built in) covers (C)(4), and a tested backup-and-restore procedure covers (C)(5). Keep them brief enough that they will actually be used.
Close the four attestation items
Schedule annual training, document the notification procedures, and put a ransom-payment resolution policy on the board's record. Assign an owner to each so none of them falls through the gap between IT and the clerk's office.
Adopt the program and set the cadence
Get the legislative authority to formally adopt the cybersecurity program, then schedule the recurring work (periodic scans, an annual risk-assessment refresh, the training cycle) so readiness is maintained, not just achieved once for the deadline.
Turning the Work into Evidence You Can Hand to an Auditor
Adopting a program is one thing; proving you have one when the Auditor of State asks is another. The technical divisions in particular are easiest to defend when the evidence is generated continuously rather than reconstructed the week before an audit. That is the gap our netvuln-tool platform is built to close for political subdivisions.
When you run a scan in ORC mode, the platform maps each finding to the relevant ORC 9.64 technical division, reports which of the five divisions your current evidence covers, and tracks the four attestation items as a readiness checklist with their deadlines attached. The output is a readiness view a clerk or a board can read and an auditor can accept: which technical areas are evidenced, which attestations are still pending, and where the gaps are. It is documentation that keeps pace with your environment instead of a snapshot that goes stale the day after you produce it.
The point is not the tool for its own sake. It is that ORC 9.64 readiness is a recurring obligation, and a recurring obligation is best served by a process that produces evidence on its own schedule. Whether you run that process in-house or hand it to a managed-services provider, build it so the proof is a byproduct of the work, not a separate project every audit cycle.
Need to Be Ready by July 1?
Bullium works with Ohio townships, fire districts, and state agencies on exactly this: an asset inventory, a vulnerability scan and risk assessment, the incident-response and recovery documents, and an ORC 9.64 readiness package your board can adopt and your auditor can accept. We scope it to a public-sector budget and the deadline you are working toward. No commitment to engage further.
Related Reading
NIST CSF 2.0 for Public Sector IT
The framework this readiness path maps onto. Start here for the structure ORC 9.64 expects under the hood.
Compliance Framework Mapping Guide
How a vulnerability scan turns into evidence across CIS, NIST, PCI, and SOC 2. The same mechanics apply to ORC 9.64.
How to Run a Vulnerability Scan
The scan that evidences three of the five technical divisions, walked through step by step.
Security Awareness Training
The human side of the program, and the annual training requirement the statute makes mandatory.
Related Services
Security Consulting
Scope the ORC 9.64 program: inventory, scan, risk assessment, and the readiness package your board adopts.
vCIO Engagement
Fractional CIO leadership to own the program, brief the board, and keep readiness on a cadence.
Managed IT Services
Ongoing scanning, patching, monitoring, and evidence generation for subdivisions without in-house IT capacity.
netvuln-tool Vulnerability Scanning
The scanning platform with an ORC 9.64 readiness view: division coverage, attestation tracking, and deadlines.