ORC 9.64 — what Ohio public entities must put in writing (and what the Auditor will read)

ORC 9.64 is the Ohio statute that moves cybersecurity for political subdivisions from "a good idea" to "a written program the entity has to have." A county, a municipality, a township, a school district — each is a political subdivision under the statute, and each is asked to do the same five things: adopt a written cybersecurity program, designate a cybersecurity coordinator, train the staff who touch systems, maintain an incident response plan, and report annually to the legislative authority on the program's status. The sixth line is the one most public entities read last: the Auditor of State may audit the program under ORC 117.43, which means the program is not just written — it is read, by an auditor, against the evidence trail the subdivision kept all year.

The statute does not prescribe a specific framework. It asks for a program that addresses the subdivision's systems and data, kept current, and run by a named coordinator. The Ohio Department of Administrative Services (DAS) publishes a model cybersecurity program, and most subdivisions stand their written program up against the DAS model — not because the statute names DAS, but because the model gives the auditor a recognized shape to read against. A program that mirrors the DAS model is easier to defend on audit than a bespoke document a vendor drafted once and left in a drawer.

The five things the statute asks for

01 — A written cybersecurity program

The program has to be written, it has to address the subdivision's systems and data, and it has to be maintained — not authored once. "Maintained" is the word that separates a binder from a program. A program that runs is a program that gets reviewed against the DAS model on a cadence, updated when the systems change, and re-issued when the risk picture moves. A binder that was drafted in 2023 and never reopened is not a maintained program; it is a document with a date on it. The honest read on audit is whether the program was touched in the last reporting year, and whether the changes track to changes in the subdivision's environment — a new payroll system, a new records-management platform, a new vendor with remote access.

02 — A cybersecurity coordinator

One named person is responsible for the program. The coordinator is the name the auditor asks for first. A common mistake is to name an elected official or a department head who does not run the technical work — the statute asks for a coordinator responsible for the program, not a sponsor of it. A subdivision that does not have a full-time security engineer on staff can designate an internal coordinator and back the role with an outside security engineer who runs the day-to-day program. The coordinator is the single point of accountability; the backing engineer is the one who keeps the program current against the DAS model.

03 — Staff training

Employees with access to systems receive cybersecurity training, and the subdivision keeps the completion records. "Keeps the completion records" is the line that turns training from a poster in the breakroom into an auditable control. The training does not have to be long; it has to be delivered, documented, and re-delivered on a cadence — annual is the common reading. Phishing simulation is not required by the statute, but it is the easiest way to produce evidence that the training landed, and it gives the coordinator a metric to put in the annual report.

04 — An incident response plan

A written incident response plan, exercised — not just drafted. "Exercised" is the word that moves the plan from paper to practice. A tabletop exercise once a year is the minimum credible cadence; the exercise produces notes, the notes become evidence, and the evidence is what the auditor reads to confirm the plan was tested rather than filed. The incident response plan should tie to the alerting pipeline — if the subdivision runs a SIEM, the plan should name which alerts trigger which steps, and who is paged at 2 a.m. A plan that does not reference the actual alerting path is a plan that was drafted away from the operations it is supposed to govern.

05 — An annual report

The coordinator reports annually to the legislative authority — the county commission, the city council, the township trustees, the school board — on the status of the program. The report is the single document that ties the program together: what was done, what was tested, what incidents occurred, and what will change next year. The cleanest way to produce the annual report is to pull it from the same ticket-system and SIEM exports that feed the IT operations report — one set of numbers, read two ways. A subdivision that runs its compliance program on a separate evidence trail from its IT contract ends up reconciling two datasets at audit time, which is where the hours go.

The sixth line — ORC 117.43 audit readiness

The Auditor of State may audit the cybersecurity program under ORC 117.43. The audit reads the program against the evidence: the written program document, the coordinator designation, the training completion records, the incident response plan and exercise notes, and the annual report delivered to the legislative authority. The audit is not a penetration test; it is a records read. The subdivision that keeps the evidence trail in one place — logs, training records, risk assessments, exercise notes, the annual report — passes the records read without a scramble. The subdivision that keeps the evidence across three vendors and a shared drive passes the same audit with a week of reconstruction work.

Audit readiness is the difference between a program that runs and a program that was written. The program that runs produces the evidence as a byproduct of the year — every training session logged, every exercise noted, every incident documented, every report delivered. The program that was written produces the evidence at audit time, reconstructed from memory and email. ORC 9.64 asks for the first; ORC 117.43 reads for the first.

How ORC 9.64 differs from the FTC Safeguards Rule

Ohio auto dealerships and other "financial institutions" under the Gramm-Leach-Bliley Act read the FTC Safeguards Rule (16 C.F.R. Part 314); Ohio political subdivisions read ORC 9.64. The two statutes share a shape — written program, designated individual, risk assessment, training, incident response, annual report — but they differ in three places that matter at signing.

First, the audience. Safeguards is private-sector and financial; 9.64 is public-sector and broad. A county treasurer's office that handles motor vehicle titling may sit under both statutes at once — Safeguards for the customer financial data, 9.64 for the public-entity program. The two programs can share a single written document and a single coordinator, but the reporting lines differ: Safeguards reports to the board or controlling partner; 9.64 reports to the legislative authority.

Second, the technical bar. Safeguards names specific technical safeguards — MFA for customer-data systems, encryption in transit and at rest, secure development practices, disposal within two years of last use. 9.64 does not name a specific technical list; it asks for a program that addresses the subdivision's systems and data, and points to the DAS model for the recognized shape. The practical reading is that a subdivision running the same eight operational layers as a private SMB — helpdesk, 24/7 endpoint monitoring, EDR, patch management, MDM, building security, SIEM, and network monitoring — is already most of the way to the technical bar both statutes imply.

Third, the audit. Safeguards is enforced by the FTC; 9.64 is auditable by the Auditor of State under ORC 117.43. The FTC enforcement is complaint-driven and infrequent; the state audit is cyclical and routine. A subdivision should expect the audit on the Auditor's regular cycle, not wait for a complaint.

What to ask before signing

A political subdivision reading ORC 9.64 for the first time — or re-reading it ahead of an audit cycle — should bring six questions to every walkthrough. The vendor whose answers line up with the statute is the vendor worth signing.

• Program document. Will the vendor draft the written program against the DAS model, keep it current on a cadence, and re-issue it when the systems change — or is the program a one-time deliverable that lives in a drawer?
• Coordinator. Will the vendor's security engineer serve as coordinator, or back the in-house designee — and is the coordinator named in the contract, not just on a slide?
• Training. Is annual training delivered with completion records retained for audit, and is phishing simulation available to produce evidence the training landed?
• Incident response. Is the incident response plan written, exercised annually, and tied to the actual SIEM alerting pipeline — or is it a standalone document that does not reference the operations it governs?
• Annual report. Is the annual report pulled from the same ticket and SIEM exports that feed the IT operations report, or is it produced on a separate evidence trail that has to be reconciled at audit time?
• Audit readiness. Does the vendor maintain the evidence trail — logs, training records, risk assessments, exercise notes — in one place, on the same contract as the IT operations, so the Auditor's records read is a single-source pull?

How CIT ships ORC 9.64

The subdivision gets the same eight operational layers as a private Ohio SMB — helpdesk, 24/7 endpoint monitoring, antivirus / EDR, patch management, MDM, building security, SIEM, and network and bandwidth monitoring — with the compliance program layered on top of the same per-endpoint contract. The coordinator role is backed by CIT's Security Engineer, the written program is drafted against the DAS model and kept current, training is delivered annually with completion records, the incident response plan is exercised and tied to the SIEM alerting pipeline, and the annual report is pulled from the same ticket and SIEM exports that feed the SLA report. One contract, one rota, one annual report an auditor can read — no separate compliance retainer sitting beside the IT contract, and no second evidence trail to reconcile at audit time.

The point of ORC 9.64 is not the binder; it is the program that runs. A subdivision that runs the program all year produces the annual report as a byproduct, and passes the ORC 117.43 records read without a reconstruction week. The vendor whose answers line up with the statute is the vendor worth signing — and the vendor whose program runs on the same contract as the helpdesk is the vendor whose evidence trail stays in one place.

Published by Central IT Dept, LLC · Carroll, OH — also marketed as citcyber.com. Pairs with the ORC 9.64 guide and the FTC Safeguards guide. Walkthrough requests go straight to the engineering inbox; the language above is read against the same contract on every quote.