Ohio ORC 9.64 Political Subdivision Cybersecurity, Complete Guide

Ohio Revised Code § 9.64 is Ohio’s first cybersecurity mandate for local governments. It requires every political subdivision—counties, municipalities, townships, and special districts—to implement and maintain a formal cybersecurity program to ensure the security and protection of its information systems and data.

Ohio’s cybersecurity governance now operates on a dual foundation. Before 2025, only state agencies were covered under ORC § 125.18, working within the centralized oversight of the Department of Administrative Services (DAS) and the statewide ITS-SEC-02 framework.

The introduction of ORC § 9.64 extends that oversight to local governments, creating a unified framework for cybersecurity across the state. The goal is to establish a consistent statewide baseline for protecting public data and critical services (ORC § 9.64(A)).

This marks a major step in strengthening Ohio’s overall cybersecurity posture by closing the gap between state and local protections. The law standardizes expectations and oversight while still allowing flexibility for local execution.

This ORC 9.64 implementation guide explains what the law requires from local governments, why it matters and how it fits within Ohio’s broader cybersecurity strategy. It breaks down each step political subdivisions must take to build compliant programs by the 2026 deadlines.

What Is ORC 9.64?

ORC § 9.64, or Political Subdivision Cybersecurity statute, is Ohio’s first law to require local governments—including counties, municipalities, townships, and special districts—to establish and maintain formal cybersecurity programs.

Its purpose is to safeguard public data and IT systems, ensuring the confidentiality, integrity, and availability of government information across the state.

By mandating that every political subdivision maintain a cybersecurity program, the statute creates a shared baseline of protection across local governments. Even smaller jurisdictions gain a framework to defend critical systems, protect resident data and coordinate effectively during cyber incidents.

Although it doesn’t dictate how each program must look, it directs local governments to align their efforts with recognized best-practice frameworks such as the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) and the Center for Internet Security (CIS) Controls, extending their flexibility.

Local governments can also turn to statewide partners for support, including the Ohio Cyber Reserve, the Ohio Cyber Integration Center (OCIC), the Ohio Persistent Cyber Improvement (O-PCI) program and the Auditor of State (AOS).

These agencies provide tools and guidance for risk identification, impact assessment, threat detection, incident response and infrastructure recovery.

Who Must Comply with ORC 9.64 and When?

ORC § 9.64 applies to all political subdivisions, defined as “a county, township, municipal corporation or other body corporate and politic responsible for governmental activities in a geographic area smaller than that of the state” (ORC § 2744.01(F); ORC § 9.64(A)).

Because Ohio’s cybersecurity governance operates on a dual framework, state agencies are regulated separately under ORC § 125.18 and the ITS-SEC-02 enterprise security standards administered by the Department of Administrative Services (DAS). As a result, they do not fall under ORC § 9.64, which applies exclusively to local governments.

ORC 9.64 Compliance Timeline

Compliance deadlines vary by the type of political subdivision. While ORC § 9.64 takes effect on Sept. 30, 2025, enforcement begins shortly after.

• Counties & municipalities — audits begin: Jan. 1, 2026 (AOS audit window).
• All other subdivisions—including townships, special districts, and local authorities— adoption deadline: July 1, 2026.

The Jan. 1, 2026 implementation date specifically applies to county governments where the board of county commissioners or county council serves as the legislative authority.

Who Oversees the Implementation of ORC 9.64?

The legislative authority of each political subdivision is responsible for formally adopting the cybersecurity program.

In counties, that means the board of commissioners or county council takes the lead. Once adopted, the program extends to all entities within the county, including systems managed by other officeholders.

Implementation typically falls to IT directors, city managers, county administrators and township trustees — the teams responsible for building programs, securing resources and meeting statutory requirements.

What Data Is In Scope for ORC 9.64?

ORC § 9.64 applies to all data managed by political subdivisions, regardless of type or classification. This includes:

• Confidential information
• Personally identifiable information (PII)
• Sensitive personal information
• Public and non-confidential data
• State-controlled or shared data

The law does not prescribe different controls for each data category. However, more sensitive data requires stronger safeguards consistent with best-practice frameworks, such as the NIST Cybersecurity Framework (CSF) and CIS Controls.

The Six Core Program Components (ORC 9.64(C))

Under ORC § 9.64(C), every political subdivision must include, at minimum, six core components in its cybersecurity program. Together, these ensure that each organization is equipped to manage risk, detect and respond to threats, and recover quickly. They also make continuous training a core requirement so teams can respond effectively.

While the statute sets a baseline, each subdivision has the flexibility to adapt these components to its size, structure, and technical capacity.

Component 1: Risk Identification and Critical Functions

Objective

To identify all mission-critical systems, assets and services that support the political subdivision’s essential operations, and to understand the cybersecurity risks that could disrupt them.

The following steps can help local governments identify and address critical functions and cybersecurity risks:

Conduct a complete system inventory.
Gather information across departments to map every IT asset, application, and data source used by the political subdivision. This establishes visibility into what systems exist, who manages them, and how they interact.

Document vulnerabilities and dependencies.
Record potential weaknesses, interdependencies, and threat exposures for each identified system. This helps determine which systems pose the greatest risk to operational continuity or public safety.

Identify mission-critical systems and services.
Collaborate with department heads and key staff to determine which systems and functions are essential for maintaining core services, such as finance, emergency response, or utilities.

Analyze and prioritize.
Use the information collected to highlight the organization’s most important—and most vulnerable—functions. These will serve as the foundation for your broader risk management and impact assessment efforts.

Expected Outcome

By completing this step, your organization should have two key deliverables in place—each forming the backbone of your cybersecurity program documentation.

A comprehensive risk register that captures every identified risk, its likelihood, potential impact, mitigation strategy, and assigned owner.

This document serves as your single source of truth for managing cybersecurity risk, keeping accountability visible and decisions defensible.

A critical systems inventory detailing all essential systems, their functions, interdependencies, and designated owners.

This inventory ensures the team knows exactly which assets support core public services—and which ones must be protected first.

Together, these outputs provide the visibility needed to prioritize security efforts, prepare for audits, and clearly communicate risk to leadership and stakeholders.

Aligned Frameworks and Practical References:

• NIST SP 800-30 (Guide for Conducting Risk Assessments)
• CIS Control 1 (Inventory and Control of Enterprise Assets)
• CyberOhio’s Cyber Frontline First Aid Kit (With asset inventory guidance)

Component 2: Impact Assessment

Objective

To determine the potential impact of cybersecurity incidents on essential operations, public services, and data availability.

This step helps quantify what’s at stake if systems fail or are compromised.

The following steps can help local governments evaluate potential impacts of cybersecurity incidents:

Identify critical functions and dependencies.
Review the systems and services identified in Component 1 to understand how each supports public operations, safety, and service delivery.

Assess potential consequences of disruption.
Determine what would happen if a critical system were compromised or became unavailable. Consider impacts on residents, financial stability, emergency services, and regulatory obligations.

Perform a business impact analysis (BIA).
Estimate both qualitative and quantitative impacts (e.g., downtime costs, public trust erosion, safety risks). Document maximum tolerable downtimes and recovery priorities for each critical system.

Prioritize recovery objectives.
Use your impact analysis to set clear Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). These define how quickly each system must be restored and how much data loss is acceptable.

Together, these activities provide a structured understanding of how cybersecurity incidents may impact operations and establish clear recovery priorities for maintaining critical public services.

Expected Outcome

A documented impact assessment report summarizing how incidents could affect critical systems, including potential service disruptions, cost implications, and recovery priorities. This report supports planning, resource allocation, and compliance audits by demonstrating an understanding of operational risk.

Aligned Frameworks and Practical References:

• NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems)
• CIS Control 11 (Data Recovery)

Component 3: Threat Detection Mechanisms

Objective

To establish methods for detecting, monitoring, and alerting on potential cybersecurity threats and abnormal system activity before they escalate into major incidents.

The following steps can help local governments implement effective threat detection mechanisms:

Define detection scope.
Identify which systems, networks, and applications need continuous monitoring. Prioritize those that handle critical data or public-facing services.

Set up log collection and analysis.
Configure system, network, and application logs to capture relevant security events. Aggregate them into a central log management or SIEM (Security Information and Event Management) system.

Establish alert thresholds and escalation paths.
Define what types of activity trigger alerts (e.g., failed logins, privilege changes, or network anomalies) and who is responsible for reviewing and escalating them.

Integrate with statewide resources.
Coordinate with the OCIC to align with statewide monitoring and threat intelligence efforts.

These activities enable your organization to identify potential cyber threats early, contain them quickly, and coordinate effectively with state-level response partners.

Expected Outcome

A documented threat detection and monitoring procedure that defines data sources, alert thresholds, escalation processes, and integration points with OCIC.

Threat detection mechanisms will help ensure that every suspicious activity is detected, logged, and acted on in time to prevent disruption.

Aligned Frameworks and Practical References:

• NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide)
• CIS Control 8 (Audit Log Management)

Component 4: Incident Response Procedures

Objective

To define how your organization prepares for, responds to, and recovers from cybersecurity incidents in a timely, coordinated manner.

The following steps can help local governments establish effective incident response procedures:

Develop an incident response plan (IRP).
Outline clear roles, responsibilities, and communication protocols for responding to cybersecurity events.

Establish communication and escalation channels.
Identify points of contact for internal teams, executive leadership, OCIC, and the AOS.

Test and refine the plan.
Conduct tabletop exercises or simulated incidents to verify that your procedures work as intended.

Document and review incidents.
Record incident details, lessons learned, and post-incident improvements to strengthen future responses.

These steps ensure your organization can act quickly, minimize damage, and maintain service continuity when incidents occur.

Expected Outcome

A comprehensive incident response plan that defines detection, escalation, communication, containment, and recovery actions, plus reporting timelines to OCIC and AOS.

This plan demonstrates operational readiness and fulfills statutory reporting obligations.

Aligned Frameworks and Practical References:

• NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide)
• CIS Control 17 (Incident Response Management)
• Ohio IT-18 (Information Security & Privacy Incident Response Policy)

Component 5: Infrastructure Repair and Maintenance

Objective

To ensure systems can be restored and maintained securely after an incident, reducing downtime and preventing recurring vulnerabilities.

The following steps can help local governments establish effective repair and maintenance processes:

Develop recovery and restoration procedures.
Define how to rebuild, patch, or restore affected systems using validated backups.

Test backup integrity regularly.
Schedule routine recovery tests to ensure backups are reliable and complete.

Document and verify repairs.
Keep detailed records of restored systems, applied patches, and post-incident security validation.

Implement preventive maintenance.
Regularly update software, apply patches, and review system configurations to prevent recurrence.

These activities enhance operational resilience by enabling faster service restoration and sustained security after an incident.

Expected Outcome

A documented system recovery and maintenance plan including restoration steps, validation checklists, and evidence of periodic testing.

A well-documented plan equips political subdivisions to respond effectively and recover operations swiftly following a disruption.

Aligned Frameworks and Practical References:

• NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems)
• CIS Control 11 (Data Recovery)

The Ohio Cyber Reserve provides recovery and continuity planning resources designed to guide jurisdictions through post-incident restoration, validation, and system hardening.

Closing the gap between containment and recovery enables stronger, more resilient operations after each incident.

Component 6: Employee Training Requirements

Objective

To define cybersecurity training obligations for all employees and contractors, ensuring awareness and accountability are built into daily operations. Training must be tailored to job duties and kept current as threats evolve.

The following steps can help local governments establish effective cybersecurity training programs:

The following steps can help local governments build and maintain effective cybersecurity training programs:

Establish Mandatory Training
Implement annual cybersecurity training for all employees and contractors, regardless of technical role. Make participation a standing requirement to maintain compliance and awareness across the organization.

Develop Role-Based Modules
Create targeted training content for staff who handle sensitive data, manage systems, or perform administrative and operational duties. Tailored lessons ensure each employee understands risks relevant to their job.

Integrate Onboarding and Refreshers
Include cybersecurity awareness in onboarding programs and conduct periodic refresher sessions to reinforce key practices such as password security, phishing prevention, and incident reporting.

Maintain Training Records
Document training participation, completion dates, and coverage areas to demonstrate compliance during state audits and to identify where additional training may be needed.

Expected Outcome

A comprehensive, role-based cybersecurity training program that ensures all employees understand their security responsibilities.

The mandate also requires training records and completion tracking that demonstrate ongoing compliance with ORC § 9.64.

By making cybersecurity training mandatory, ORC § 9.64 turns awareness into routine practice across local government operations.

Aligned Frameworks and Practical References:

• NIST SP 800-50 (Building an Information Technology Security Awareness and Training Program)
• CIS Control 14 (Security Awareness and Skills Training)

Annual training provided by the State of Ohio or through the Ohio Persistent Cyber Improvement (O-PCI) program fulfills this requirement.

CyberOhio guidance from July 2025, strongly recommends annual training as a best practice and encourages local governments to leverage O-PCI’s free courses to meet compliance and build cyber awareness.

ORC § 9.64 Implementation Process

The ORC § 9.64 implementation process can be divided into four phases designed to help political subdivisions build, validate, and sustain compliant cybersecurity programs.

Each phase builds on the last, guiding local governments from initial readiness to ongoing improvement.

This phased approach aligns with best practices outlined in the NIST Cybersecurity Framework (CSF) and ensures programs remain flexible, auditable, and proportionate to organizational size and capacity.

The four phases of ORC § 9.64 implementation are:

1. Preparation (Now – Three Months Before Deadline)
2. Program Development (Three Months Before – Deadline)
3. Implementation and Validation (Deadline – Six Months After)
4. Continuous Improvement (Ongoing)

Implementation Timeline for ORC § 9.64 Compliance

How ORC 9.64 Political Subdivision Cybersecurity Aligns with Other Frameworks?

ORC § 9.64 does not prescribe a single cybersecurity framework. Instead, it directs local governments to structure their cybersecurity programs around established best practices such as the NIST Cybersecurity Framework (CSF) and the Center for Internet Security (CIS) Controls.

The NIST CSF provides a strategic structure, defining how to identify, protect, detect, respond, and recover from cyber risks.

The CIS Controls provide the technical implementation guidance, offering local teams prioritized, measurable safeguards that translate those functions into daily practice.

At the state level, ORC § 125.18 and ITS-SEC-02 set enterprise security standards for agencies under the Department of Administrative Services (DAS). While those rules don’t apply directly to counties, cities, or townships, they provide a useful reference for how Ohio expects cybersecurity programs to mature over time.

In effect, ORC § 9.64 connects local cybersecurity efforts to the same frameworks that guide federal and state programs—promoting consistency in outcomes while allowing flexibility in execution.

This alignment provides local governments with a clear starting point, drawing on established frameworks and state resources while allowing flexibility in implementation.

Incident Reporting & Ransomware Requirements

How does ORC § 9.64 Define a Cybersecurity Incident?

A reportable “cybersecurity incident” includes any event that results in a substantial loss of confidentiality, integrity or availability; materially affects safety or resiliency; disrupts services; or involves unauthorized access to systems or non-public data, including incidents via cloud/MSP or supply chain compromise (ORC § 9.64(A)(1)).

This broad definition covers both direct attacks and third-party compromises.

Reporting Obligations

ORC § 9.64(D) also requires political subdivisions in Ohio to promptly report cybersecurity and ransomware incidents to two state authorities within strict timelines.

1. OCIC Incident Reporting Process Within 7 Days of Discovery

Local governments must report cybersecurity incidents to the Ohio Cyber Integration Center (OCIC) within seven days of discovery (R.C. 9.64 (D); Ohio Department of Public Safety).

Step 1 — Initial Contact and Case Creation

Counties must report the incident to the Ohio Cyber Integration Center (OCIC) by calling 614-387-1089 or emailing OCIC@dps.ohio.gov. After initial contact, OCIC will complete an intake form under a nondisclosure agreement (NDA), assign a case number, and alert relevant stakeholders to begin coordinated response efforts.

Required Reporting Information:

• County contact information (name, address, phone number)
• Primary point of contact (name, title, phone, email)
• Date and time of incident
• Type of incident and any mitigation actions taken before reporting
• Affected devices and whether they were removed or powered off
• Cyber insurance status and whether the provider was notified
• Other entities contacted about the incident
• Security team details: device count, presence of protected personal information (PPI), state-connected devices involved, and date of last backup

Step 2 — Multi-Agency Coordination

A coordination call will be convened with:

• Department of Administrative Services (DAS)
• Department of Public Safety (DPS)
• Secretary of State (if elections are impacted)
• Federal Bureau of Investigation (FBI)
• Department of Homeland Security (DHS)
• Cybersecurity and Infrastructure Security Agency (CISA)

Step 3 — Response Coordination
OCIC manages incident tracking and documentation through its case management system.

Step 4 — Follow-Up and Remediation

Additional coordination calls may be scheduled for forensics, mitigation, and recovery.

Step 5 — Closure and Lessons Learned

Upon resolution, OCIC will share the final disposition and any lessons learned to strengthen statewide cyber resilience.

2. Auditor of State (AOS) Within 30 days of Discovery

In addition to notifying OCIC, counties must also report incidents to the Auditor of State (AOS) within 30 days.

Submission Requirements

• Complete the Cybersecurity Incident Reporting Form.
• Email the completed form to Cyber@ohioauditor.gov.

The AOS process ensures compliance verification under Ohio Revised Code § 9.64(D) and helps establish a consistent statewide record of cyber incidents across local jurisdictions.

The AOS uses these reports to evaluate compliance and resilience during regular audit cycles, ensuring that political subdivisions maintain the minimum cybersecurity program standards required under ORC § 9.64.

Public Records Exemption

When reporting cybersecurity or ransomware incidents, the mandate explicitly excludes three specific records from Ohio’s public-records requirements to prevent exposure of sensitive security information ORC §§ 9.64(E)–(F); 149.43; 149.433. These are

• Records, documents, or reports related to a political subdivision’s cybersecurity program or framework
• Reports of a cybersecurity incident
• Reports of a ransomware incident

Additionally, records that identify cybersecurity-related software, hardware, goods, or services are classified as “security records” under ORC § 149.433.

These records can include details such as vendor names, product names, project titles, or descriptions associated with technology procurement or use.

Local governments do not have to produce these records if a public-records request is submitted. This protection helps safeguard sensitive operational and vendor information that, if disclosed, could expose system vulnerabilities.

Ransomware Response Restrictions

What Is a Ransomware Incident Under ORC § 9.64?

ORC § 9.64(B) defines a ransomware incident as a malicious cybersecurity event in which an unauthorized actor introduces software that gains access to, encrypts, modifies, or otherwise disables a political subdivision’s information systems or data.

The attack typically follows a demand for payment or compliance, often tied to restoring access or preventing the public release of compromised information.

How Can Local Entities Respond to Ransomware Threats?

ORC § 9.64(B) establishes clear restrictions on ransom payments.

If a ransom threat occurs, local governments cannot pay or comply with the demand (ORC § 9.64(B)).

The only exception is if their legislative authority formally approves the payment through a public resolution or ordinance. That approval must also include a clear explanation of how the payment serves the public interest.

While the law allows for limited exceptions through formal approval, the AOS and CyberOhio strongly discourage engaging with threat actors as part of any response.

They advise subdivisions to focus on prevention, maintain offline backups, and coordinate immediately with the Ohio Cyber Integration Center (OCIC) if an attack occurs.

Ohio’s Statewide Cybersecurity Assistance Programs

To help political subdivisions meet ORC § 9.64 local government cybersecurity requirements, the state provides a set of free, mission-aligned resources:

CyberOhio: CyberOhio coordinates Ohio’s statewide cybersecurity strategy, aligns public-sector standards, and provides outreach, guidance, and resources to local governments.

When to use CyberOhio:

• When you need program guidance or framework alignment advice
• When seeking coordination with state policies and cyber resources
• When clarifying ORC § 9.64 compliance expectations

Ohio Cyber Reserve (OhCR):

OhCR is a volunteer civilian cyber force that assists eligible municipalities with audits, incident response, and vulnerability assessments.

When to use OhCR:

• During or after a cybersecurity incident for on-the-ground support
• To request vulnerability assessments or audits
• When you need help validating compliance or remediation plans
• For free resources on cybersecurity best practices

O-PCI (Ohio Persistent Cyber Improvement): O-PCI offers free training to local government entities, helping satisfy Component 6’s training requirement.

When to use O-PCI:

• When fulfilling the training requirement under Component 6
• To onboard staff unfamiliar with cybersecurity basics
• For continuous education, training, exercising, mentoring, and improvement

OCIC (Ohio Cyber Integration Center): OCIC acts as Ohio’s central cyber coordination hub—providing threat intelligence, incident coordination, and state-level response alignment.

When to use:

• Immediately after detecting a cybersecurity or ransomware incident
• To submit required incident reports under ORC § 9.64
• To coordinate cross-jurisdictional responses and threat sharing

Counties seeking guidance can also refer to model program recommendations developed by the County Commissioners Association of Ohio (CCAO) and the County Risk Sharing Authority (CORSA). CORSA members can access its Cyber Best Practice Guide and Cyber Model Policy on their website under Risk Management → Cyber Risk Management.

How Is ORC § 9.64 Enforced?

Ideally, ORC § 9.64 is enforced through the Ohio Auditor of State (AOS).

During regular audit cycles, the AOS checks whether each political subdivision has built and maintained a cybersecurity program that meets the law’s six core components and reporting requirements.

Enforcement under ORC § 9.64 is adaptive, not punitive.

Auditors look for programs that make sense for that entity’s size, mission, and risk exposure. The important question is whether the program is reasonable and risk-based.

If they find gaps, the AOS will recommend a corrective action plan. The action plan is essentially a roadmap that tells the subdivision what to fix, how to fix it, and when to report back. It’s meant to improve accountability, not create penalties.

And even though AOS sets expectations, local legislative authorities, like city councils or county boards, still retain the final say in decisions around budgeting, resource allocation, and program design. They decide how much to budget, what tools to buy, and how to structure their program, as long as they stay within ORC § 9.64’s minimum standards.

The Auditor of State’s Office is currently updating the Ohio Compliance Supplement, which guides auditors in reviewing local governments during the audit process. The revised Supplement will include instructions related to the implementation of the new cybersecurity program requirements under ORC § 9.64.

The Auditor of State is also developing detailed compliance procedures. Political subdivisions that fail to meet the January 1, 2026 implementation deadline may receive an item of noncompliance during their audit.

Benefits and Outcomes of the ORC 9.64 Compliance

ORC § 9.64 brings Ohio’s local governments under a shared cybersecurity standard—without taking away local control.

• Baseline Protection
  The law brings a consistent minimum level of cybersecurity across all political subdivisions, ensuring essential safeguards statewide.

• Framework Flexibility
  While the mandate defines what must be protected, it leaves room for how. Each entity can tailor its cybersecurity program to its size, mission, and risk profile, while still aligning with frameworks like NIST CSF and CIS Controls.

• Lower Implementation Costs
  By leveraging free, state-supported initiatives such as CyberOhio, the Ohio Persistent Cyber Initiative (O-PCI), and the Ohio Cyber Reserve, local governments can reduce the cost of implementation, training, and technical assistance.

• Enhanced Public Trust
  With visible, statewide standards in place, citizens gain greater confidence that their personal data and digital services are being protected under a unified, accountable framework.

• Coordinated Incident Response
  The shared cybersecurity standard enables faster, more unified responses to threats through data sharing and coordination with OCIC and state partners.

• Improved Audit Readiness
  By requiring continuous documentation and clear accountability, the mandate simplifies compliance verification during Auditor of State (AOS) audits and strengthens long-term cybersecurity governance.

Compliance Software for ORC 9.64

Implementing ORC § 9.64 requires ongoing visibility into cybersecurity risk, not a one-time checklist. To stay compliant, every political subdivision must continuously document risks, track mitigations, and maintain auditable proof of progress across all six required components.

A modern Governance, Risk, and Compliance (GRC) platform enables local governments to:

• Centralize risk data in one live register that captures vulnerabilities, impacts, and mitigation ownership.
• Coordinate across departments by linking assessments, exceptions, and recovery actions to specific systems and teams.
• Generate continuous evidence through scheduled reviews and audit-ready reports formatted for the Auditor of State.

Without an integrated platform, these activities remain fragmented across spreadsheets and email threads, making compliance reactive instead of operational.

Isora GRC for ORC § 9.64

Isora GRC gives local governments a structured way to meet Ohio’s cybersecurity program mandate under ORC § 9.64. The platform provides the tools to manage assessments, maintain inventories, document risks, and generate audit-ready reports in one shared workspace. Each capability aligns directly to the six statutory components and the oversight expectations of the Auditor of State (AOS) and CyberOhio.

Assessment Management

Isora centralizes the management of cybersecurity assessments across departments, assets, and vendors. Local governments can evaluate systems against NIST CSF or CIS Controls, assign owners, and track remediation progress. Assessment results flow directly into the risk register, creating a single system of record for findings, accountability, and program improvement.

Reports & Scorecards

Isora simplifies how local governments prepare and present compliance evidence. Reports compile data from assessments, inventories, and risk registers into clear, exportable summaries formatted for AOS submission. This allows teams to demonstrate control implementation, remediation status, and compliance progress across all six program components.

Inventory Management

Isora helps local governments build and maintain a connected inventory of assets, vendors, and departments that support essential operations. Each record links directly to associated assessments and risks, providing the visibility required under ORC § 9.64 Component 1. By aligning with NIST CSF (ID.AM) and CIS Controls 1 and 2, Isora ensures every cybersecurity program begins with a complete and defensible picture of what must be protected.

Risk Management

Isora’s collaborative risk register allows political subdivisions to capture and maintain detailed risk records, including likelihood, impact, mitigation strategy, and ownership. Risks link directly to assessments and controls, ensuring documentation, accountability, and visibility remain current across the cybersecurity program.

Common Implementation Pitfalls

Local governments implementing ORC § 9.64 often encounter similar challenges during early rollout. Recognizing these issues in advance helps maintain compliance and avoid last-minute remediation.

Pitfall 1: Waiting Until the Deadline Approaches

Many subdivisions delay implementation until audit deadlines are near. This compresses timelines for system inventory, documentation, and training.

Solution: Start early. Establish ownership, review CyberOhio templates, and begin documenting program components as systems are identified.

Pitfall 2: Treating Compliance as a One-Time Documentation Exercise

Some entities treat ORC § 9.64 as a form-filling exercise rather than an operational program.

Solution: Build continuous improvement cycles. Update risk registers, test incident plans, and refresh training annually to maintain compliance readiness.

Pitfall 3: Copying State Agency Controls Directly

State-level controls under ORC § 125.18 or ITS-SEC-02 are not designed for local use. Applying them without adjustment can create unnecessary complexity.

Solution: Tailor cybersecurity programs to local context—size, staffing, budget, and system complexity—while aligning to NIST CSF and CIS Controls.

Pitfall 4: Overlooking Free State Resources

Some jurisdictions attempt to build programs entirely from scratch, overlooking existing state support.

Solution: Leverage free resources from O-PCI, CyberOhio, and the Ohio Cyber Reserve for training, assessments, and guidance. These tools are designed specifically for local governments.

Conclusion

Local governments serve as the backbone of community life—protecting sensitive citizen data and operating critical infrastructure. That makes them high-value targets for cyberattacks, where a single breach can cost millions and shut down essentials like 911 dispatch, water treatment, and public transit.

As attacks grow more sophisticated, the price of recovery falls on taxpayers. Every ransom payment, investigation, and rebuild drains resources meant for schools, roads, and public services.

And unlike their adversaries, local governments are bound by strict data protection laws, regulations and transparency standards, raising both the stakes and the cost of every missed defense.

Recognizing these challenges and risks, Ohio enacted ORC § 9.64. It’s the state’s first cybersecurity law that sets a unified baseline for local government cyber readiness.

ORC § 9.64 helps local governments transition from ad-hoc defenses to structured, proactive, and auditable cybersecurity programs built on best-practice frameworks like the NIST Cybersecurity Framework (CSF) and CIS Controls.

It also ensures that every political subdivision can access shared intelligence, coordinated response resources, and expert guidance, enabling them to meet Ohio’s cybersecurity timelines with consistency and confidence.

The result is a more resilient public sector—one better equipped to prevent, detect, and recover from cyber incidents while maintaining public trust and operational continuity.

ORC 9.64 Frequently Asked Questions (FAQs)

What happens if we miss the implementation deadline?

The Auditor of State (AOS) may issue a corrective action plan during your next audit cycle. The plan will outline specific remediation steps and timelines. There are no immediate penalties, but unresolved gaps could affect audit ratings and public accountability reports.

Isora GRC helps assign owners, deadlines and reminders for corrective actions, keeping progress visible between audit cycles.

Can we voluntarily adopt ITS-SEC-02 even though we’re not a state agency?

Yes. While ORC § 9.64 applies only to political subdivisions, local governments can voluntarily reference the ITS-SEC-02 framework for additional rigor. However, its enterprise-scale controls may exceed local capacity, so selective adoption is recommended.

Do we need to implement all CIS Controls or NIST CSF subcategories?

No. ORC § 9.64 requires programs to be consistent with NIST CSF or CIS Controls, not fully exhaustive. Each subdivision should determine which controls and categories are appropriate based on size, mission, and risk profile.

Isora GRC includes pre-mapped NIST CSF and CIS control sets so teams can choose only what applies and link each control to audit evidence.

What if we use a Managed Service Provider (MSP) for IT? Does that satisfy ORC § 9.64?

Not entirely. Using an MSP does not transfer accountability. The political subdivision remains responsible for ensuring that the MSP’s cybersecurity practices meet ORC § 9.64 requirements and are reflected in contracts and service-level agreements

Isora GRC enables vendors and MSPs to complete secure questionnaires whose responses feed directly into your risk register.

How does ORC § 9.64 interact with other regulations (HIPAA, CJIS, FERPA, etc.)?

ORC § 9.64 serves as a baseline requirement and complements, rather than replaces, sector-specific mandates. Subdivisions subject to HIPAA, CJIS or FERPA should align overlapping controls to reduce duplication.

Is there a cost to use Ohio Cyber Reserve or O-PCI services?

No. Both programs offer free assessments, training and incident-response support to eligible political subdivisions.

What documentation should we maintain for AOS audits?

Keep all records that demonstrate compliance with the six core components:

• Risk register and critical-systems inventory
• Impact assessments
• Incident-response plan and reports
• Recovery and maintenance procedures
• Training records and policies

Isora GRC centralizes these documents, links evidence to each component and generates exportable reports formatted for AOS submission.

Can we adopt a program jointly with other political subdivisions?

Yes. Shared-service models are allowed and encouraged, especially for smaller jurisdictions. Each participating entity must still maintain documented accountability for its own environment.

Isora GRC supports multi-entity collaboration, letting each subdivision manage its own data while securely sharing assessments and reporting structures.

Does ORC § 9.64 require specific software or tools?

No. The statute is framework-neutral. However, GRC platforms such as Isora streamline evidence collection, risk tracking, and reporting under ORC § 9.64.