ORC 9.64 After July 1, 2026: Building and Maintaining Cybersecurity Compliance
The deadline is a start line, not a finish line. How to get a current security baseline this week, put it on a recurring schedule, and keep ORC 9.64 evidence current, on your own or with help.
By William Bradshaw | June 22, 2026 | 8 min read
If you run IT for an Ohio township, fire district, or special district, the ORC 9.64 deadline is days away. Counties and municipal corporations were the first tier, on January 1, 2026. Townships, fire and EMS districts, and the remaining subdivisions must adopt their cybersecurity program by July 1, 2026. Our ORC 9.64 readiness guide covers what the statute requires and how to get a program adopted in time.
This article is about what happens next. Adopting a program is an action you take once; running one is something you do continuously. The annual training requirement recurs, the incident-notification duties stand at all times, and the technical evidence is only convincing if it stays current. The cheapest way to fail an ORC 9.64 review is to adopt a program on paper in June and let it go stale by September. So the useful question after July 1 is not "are we compliant?" but "what is the routine that keeps us compliant?"
What follows is the practical version of that routine: get a current baseline this week, put the scan on a recurring schedule, keep the evidence somewhere a board and an auditor can see it, and close the policy gaps a tool cannot. We use our own netvuln-tool platform to show the mechanics, and we are explicit about what is open source and at no cost versus what is a managed service. This is 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.
The Deadline Is a Start Line, Not a Finish Line
ORC 9.64 requires each subdivision's legislative authority to adopt a cybersecurity program by the applicable date. That adoption is a discrete act: a resolution on the board's record. But the substance the program promises (safeguarding the availability, confidentiality, and integrity of your systems and data) is not a one-time deliverable. It is an operating commitment that runs every month after the resolution passes.
Three parts of the statute make the continuing nature concrete. The training requirement is annual, so it comes back around every year. The incident-notification duties (a 7-day notice to Ohio Homeland Security and a 30-day notice to the Auditor of State) apply whenever an incident occurs, which means the procedures have to be current and the contacts have to be correct on a date nobody can predict. And the technical divisions describe detection and risk identification, which are only meaningful if they reflect your network as it is now, not as it was the week you adopted the program.
The Auditor of State is the backstop here. A readiness package that was accurate in June but never refreshed is weak evidence in a review eighteen months later. The way to make the obligation manageable is to stop treating it as an event and start treating it as a routine that produces evidence on its own schedule. The rest of this article is how to build that routine without a large IT team.
Step One: Get a Current Baseline This Week
You cannot run a program against an environment you have not measured. Before anything recurring, get a point-in-time baseline that answers three questions: what is actually on the network, what is exposed, and what should be fixed first. That baseline is also the artifact that evidences the front half of the ORC 9.64 technical divisions.
The open-source netvuln-tool scanner is built for exactly this. The scanning engine is open source and carries no license cost. It installs on a single Linux machine (an old workstation or a small appliance is enough), scans your network range, and produces a report with the findings, a risk score, and a prioritized remediation list. For a small subdivision network, you can go from install to a first report in an afternoon. See the netvuln-tool platform overview, look at a sample report, and walk the process step by step in our guide to running a vulnerability scan.
That single scan plus the asset inventory you build alongside it evidences three of the five ORC 9.64 technical divisions: identifying critical functions and cybersecurity risks, identifying potential breach impacts, and detecting cybersecurity threats. It is the most ground you can cover in the least time, which is why it is step one rather than step three.
Step Two: Put the Scan on a Schedule
A one-time scan satisfies a checkbox. ORC 9.64 expects a program. The difference between the two is a schedule. Once the baseline scan works, set it to run on its own: netvuln-tool can install a recurring scan as a cron job or run as a persistent agent under systemd, so a fresh assessment runs weekly or monthly without anyone remembering to start it. The annual risk-assessment refresh and the recurring cadence that the readiness guide recommends stop being a calendar reminder and become part of the infrastructure.
The second half of "set it and forget it" is being told when something needs attention. The scanner can send an email alert when a scan completes, when a new critical finding appears, or when the overall risk score crosses a threshold you set. That keeps the program quiet when nothing has changed and loud when it has, which is the behavior you want from a control that runs in the background between board meetings.
The payoff is the part that matters for an audit: recurring scans produce recurring evidence. Instead of reconstructing your security posture the week before the Auditor of State asks, you have a trail of scans that shows the program operating continuously. That trail is far stronger evidence than a single snapshot, and it costs you nothing to maintain once the schedule is in place.
Step Three: Keep the Evidence Where a Board and an Auditor Can See It
A scan report sitting on a laptop is not evidence anyone else can use. The last step turns the recurring output into something a clerk, a board, and an auditor can read without logging into a server. Each scan session pushes to the online collection portal, which aggregates sessions over time so you can see your posture trend rather than a single point.
For political subdivisions, the portal renders an ORC 9.64 readiness panel. It maps the current findings to the five technical divisions and shows which ones your evidence covers, tracks the four attestation items as a checklist with their deadlines attached, and shows the deadline that applies to your entity type. The result is a readiness view in plain terms: which technical areas are evidenced, which attestations are still pending, and where the gaps are. Each session can be shared through a link, so handing the current state to a board member or an auditor is a URL rather than an export-and-email exercise.
Here is the honest line between the pieces. The scanning engine that produces your baseline and your recurring scans is open source and carries no license cost. The online collection portal and its ORC 9.64 readiness reporting are part of the managed, commercial platform. You can run the open-source scanner entirely on your own, you can use the managed portal for the reporting and the shareable evidence, or you can have us run both. None of those choices is wrong; they map to how much of the work you want to own.
What a Tool Closes, and What It Does Not
A scanning platform is the engine of the technical evidence and the cadence. It is not the whole program, and pretending otherwise is how a subdivision ends up with a confident dashboard and a failed review. Be clear-eyed about the division of labor.
What the recurring scan covers
Three of the five technical divisions: identifying critical functions and risks (C)(1), identifying breach impacts (C)(2), and detecting threats (C)(3). The scan and the asset inventory produce this evidence as their normal output, and the schedule keeps it fresh.
What stays human: incident response and recovery
Divisions (C)(4) and (C)(5) are a written incident-response plan and a tested backup-and-restore procedure. They are short documents, but they are documents and drills, not scan output. The tool cannot write them for you.
What stays human: the four attestations
Annual training, the 7-day notice to Ohio Homeland Security, the 30-day notice to the Auditor of State, and the rule against paying a ransom without a legislative resolution are policy and board actions. A tool can track their status and remind you of deadlines, but the actions themselves belong to people.
Our compliance mapping guide shows how scan findings become framework evidence in detail, and the readiness guide lays out the policy items the tool cannot evidence. Read them together and the split is clear: automate the technical evidence and the cadence, and assign an owner to the governance work that remains.
On Your Own, or With Bullium
There are two honest ways to run this, and the right one depends on the capacity you have rather than the size of your budget. If your team has someone comfortable on Linux, the self-service path is real: deploy the open-source scanner, schedule the recurring scans, and own the baseline and the cadence in-house at no license cost. Plenty of subdivisions can carry that, and they should.
If you do not have that capacity, or you would rather spend the hours on the work only your team can do, the managed path hands the recurring scanning and the online readiness reporting to us, and pairs it with the governance work the tool cannot touch. That is where our security consulting and vCIO practice come in: writing the incident-response and recovery plans, scheduling the annual training, getting the ransom-payment resolution onto a board agenda, and briefing the board so the program is adopted and understood rather than just filed.
Either way, the design goal is the same. Build the program so the proof is a byproduct of the work, not a separate project every audit cycle. Get the baseline, put it on a schedule, keep the evidence online, and close the policy gaps with a named owner. Do that and ORC 9.64 stops being a deadline you scramble toward and becomes a routine that quietly keeps you ready.
Make ORC 9.64 a Routine, Not a Scramble
Bullium works with Ohio townships, fire districts, and state agencies on exactly this: a current baseline, recurring scans, an online readiness package your board can adopt and your auditor can accept, and the incident-response, recovery, and attestation work that closes the gaps a scanner cannot. We scope it to a public-sector budget and the cadence you need to maintain. No commitment to engage further.
Related Reading
ORC 9.64 Readiness Guide
The companion piece. What the statute requires, the five technical divisions, the four attestations, and how to get a program adopted before the deadline.
NIST CSF 2.0 for Public Sector IT
The framework ORC 9.64 maps onto. Adopt it as the organizing structure and the statute comes along for the ride.
How to Run a Vulnerability Scan
The scan that produces your baseline and evidences three of the five technical divisions, walked through step by step.
Compliance Framework Mapping Guide
How scan findings turn into framework evidence across CIS, NIST, PCI, and SOC 2. The same mechanics apply to ORC 9.64.
Open-Source vs Commercial Scanners
Where the open-source baseline ends and a managed platform earns its keep. The trade-off behind the two paths in this article.
Related Services
Security Consulting
Scope the program: baseline, recurring scans, the incident-response and recovery documents, and the readiness package your board adopts.
netvuln-tool Vulnerability Scanning
The scanning platform with an ORC 9.64 readiness view: division coverage, attestation tracking, recurring scans, and deadlines.
Managed IT Services
Ongoing scanning, patching, monitoring, and evidence generation for subdivisions without in-house IT capacity.
vCIO Engagement
Fractional CIO leadership to own the program, brief the board, and keep readiness on a cadence after the deadline.