Ohio HB 96 Cybersecurity Compliance: What ORC 9.64 Requires Now That the Deadline Has Passed

If you serve an Ohio township, village, school district, library, or fire district, the compliance deadline for Ohio Revised Code 9.64 was July 1, 2026. It passed almost a month ago.

Nobody called. No fine arrived. No letter came from Columbus.

That silence is being misread across Central Ohio as a sign that this one can wait. It cannot, and the reason is structural rather than dramatic. ORC 9.64 has no enforcement patrol. Compliance gets verified in exactly one place: your regular audit. When the Auditor of State's staff arrive on their normal cycle, they will not ask whether you intend to adopt a cybersecurity program. They will ask to see the one you were legally required to have in place already.

This guide covers what the law actually requires, the three provisions most entities have missed, what auditors will ask for, and how to close the gap if you are behind. It is written for the small entity with no IT department, because that describes most of the organizations this law now governs.

Section 1Who the law covers

ORC 9.64 applies to political subdivisions, which the statute defines broadly as counties, townships, municipal corporations, school districts, and other bodies governing a geographic area smaller than the state. In practice that includes:

• Townships and villages
• Cities and counties
• Public school districts and educational service centers
• Public libraries
• Fire districts and EMS districts
• Regional councils, port authorities, and similar public bodies

If your entity is audited by the Auditor of State, assume you are covered.

It does not cover private schools, churches, nonprofits, or private businesses. There is a note for those organizations near the end of this article.

Section 2The deadlines, and what the effective date actually means

The law took effect September 30, 2025. Compliance deadlines were staggered:

Both dates have now passed. There is no grace period written into the statute.

Section 3The five things your program has to address

ORC 9.64 does not prescribe a product list. It requires a written program, scaled to your size and risk, adopted by your legislative authority. Per Auditor of State Bulletin 2025-007, the program must safeguard your data, information technology, and IT resources for availability, confidentiality, and integrity, and must address:

1. Your critical functions and the cybersecurity risks to them. What operations would stop, and what would it cost you, if a given system went down.
2. The potential impact of a breach. Not just downtime. Payroll, utility billing, public safety dispatch, student records.
3. Threat detection. Something actively watching for compromise, not just the antivirus that came with the computer.
4. Incident response and communication. Who does what, in what order, and who gets called.
5. Repair, recovery, and ongoing maintenance. How you get back up, and how you stay protected afterward.

Plus a sixth requirement that stands on its own: mandatory cybersecurity training for employees, based on their job duties. The Auditor's bulletin confirms that annual training through Ohio's O-PCI program satisfies this requirement, which is a genuinely useful shortcut for entities with no training budget.

Section 4Which framework to pick

The statute points toward generally accepted best practices and names NIST and CIS as examples. For most small Ohio subdivisions, the honest answer is CIS Controls Implementation Group 1.

IG1 is a foundational set of 56 safeguards, designed specifically for small to medium organizations with limited IT expertise, standard off-the-shelf technology, and low tolerance for downtime. That is a fair description of nearly every township and village office in this part of the state. A well-run small entity can legitimately close most of those 56 items.

The flexibility in this law is real. A five-person village office is not held to the same standard as a county with 400 endpoints. But flexible does not mean optional. Every covered entity needs something written, adopted, and actually followed.

Section 5The three requirements almost nobody has handled

In conversations with local officials across Pickaway and Ross counties this summer, the written program is usually the part people know about. These three keep getting missed, and each one is harder to fix during an incident than before one.

1. The reporting clocks are short, and there are two of them

If you discover a cybersecurity or ransomware incident, you must notify:

• The Ohio Cyber Integration Center within 7 days. OCIC@dps.ohio.gov or 614-387-1089.
• The Ohio Auditor of State within 30 days, using the Cybersecurity Reporting Form. Cyber@ohioauditor.gov.

Both are maximums, not targets. Consider the practical timing. If your fiscal officer discovers something on a Friday afternoon and decides to raise it at the next regular board meeting, you have very likely already missed the seven day window before the conversation even happens.

Note also that the Auditor's definition of a reportable incident is broader than most people assume. It covers substantial loss of confidentiality, integrity, or availability, serious operational impact, and business disruption including payment redirection and phishing. If your clerk gets tricked into changing a vendor's bank details, treat that as reportable and consult counsel rather than assuming it does not count.

Somebody in your organization needs to know today who makes that call and what address they send it to.

2. You cannot pay a ransom without a resolution

Your legislative authority must formally approve any ransom payment through a resolution or ordinance that specifically explains why paying is in the subdivision's best interest.

Think about that timeline. Ransomware operators run countdown clocks measured in days. Your board meets monthly. If your trustees have never discussed this in advance, the middle of an active incident is the worst possible moment to discover the process, schedule a special meeting, and draft a justification under pressure.

This is a fifteen minute agenda item today that prevents a genuine crisis later.

3. Training has to map to job duties

A single annual all-staff video does not satisfy the statutory language. The law calls for training based on job duties. Your utility clerk who processes payments and your road crew have meaningfully different exposure, and your program should say so explicitly.

Section 6The part that gets almost no coverage: your program is not a public record

This is the concern that quietly stops small entities from documenting anything, and it deserves a direct answer.

Under ORC 9.64, records, documents, and reports related to your cybersecurity program and framework, and reports of a cybersecurity or ransomware incident, are not public records. Additionally, records identifying your cybersecurity software, hardware, vendors, products, and project details are treated as exempt security records.

Section 7What the auditor will actually ask for

The Auditor of State has stated that compliance procedures will be incorporated into the Ohio Compliance Supplement, and that guidance is still being finalized, so the precise testing steps are not fully published yet. What is clear is the shape of it.

Auditors do not test your firewall. They request documentation. Expect them to ask for:

• The resolution, ordinance, or motion by which your legislative authority adopted the program, and the minutes showing it
• The program document itself
• Evidence that training occurred, and a record of who received it
• Your incident response plan and contact list
• Evidence that the controls you described are actually operating

That last item is where good intentions collapse. A program that states "multifactor authentication is required on all accounts" becomes a liability if MFA is not actually enabled. You are far better served by a program that accurately describes where you are today and includes a dated remediation plan than by an aspirational document describing an organization you are not.

Noncompliance is expected to appear as a formal audit finding. Audit findings are public record, and they are read by your board, your residents, your local paper, and increasingly by your cyber insurance carrier at renewal.

Section 8If you are behind, here is a realistic 30 day plan

August is the practical window, because boards return from summer schedules and school districts come back into session. A workable sequence for a small entity:

1. Week one: inventory. Every device, every cloud service, every account with administrative rights, every backup. You cannot write a credible risk assessment for systems you cannot name. Most small entities find at least one forgotten server or one former employee's account still active.
2. Week two: draft against a framework. Pick CIS IG1 unless you have a reason not to. Write the program to describe your actual environment, including the gaps, with target dates.
3. Week three: adopt it. Get it on the agenda. Board or council adoption is what makes it real, and the minutes are your evidence. This step is not optional and cannot be delegated to your IT vendor.
4. Week four: close the obvious gaps. Multifactor authentication on every account that touches email or money. Backups you have actually tested a restore from, not just backups that report success. Incident contacts printed and posted somewhere a person can find them at six on a Saturday evening. Training scheduled.

If you started this week you would not be on time. You would be documented, adopted, and demonstrably improving, which is a fundamentally different conversation with an auditor than an empty folder and an apology.

Section 9Frequently asked questions

Section 10A note for private schools, churches, and small businesses

ORC 9.64 does not apply to you. Nobody from the Auditor of State is coming.

Your donors, parents, members, and insurance carrier are a different matter. The people scanning for exposed remote access and unpatched systems do not check your tax status first, and the incidents that shut down small organizations in this region over the past two years have not discriminated between public and private.

The same five elements make a sound program whether or not a statute compels it. If you want the structure without the statutory pressure, the framework above works exactly as well.

Section 11Where TechTide IT fits

TechTide IT is a Circleville based managed IT and cybersecurity provider serving townships, villages, schools, funeral homes, and small businesses across Pickaway County, Ross County, and Central Ohio. Most of the organizations we support have between 10 and 50 users and no internal IT staff, which is precisely the profile ORC 9.64 is hardest on.

For entities working through HB 96, we handle the whole path: a gap assessment against ORC 9.64, the written program document and the adoption language your board needs, deployment of the controls behind it, job-based security training, and organized evidence so your next audit is a document request rather than a scramble.

Sources and further reading

• Ohio Auditor of State, cybersecurity program requirements
• Auditor of State Bulletin 2025-007
• Auditor of State cybersecurity reporting form
• Ohio Cyber Integration Center reporting guidance
• CIS Controls Implementation Group 1
• Ohio School Boards Association, cybersecurity requirements in the budget bill

This article provides general information about Ohio Revised Code 9.64 and is not legal advice. Consult your legal counsel or your prosecuting attorney regarding your entity's specific obligations.