Most cybersecurity regulation works one way: it tells you what you must do, and penalises you when you don't. HIPAA, PCI DSS, the FTC Safeguards Rule, CMMC — all obligations, all downside.
Ohio has a law that runs in the opposite direction. It requires nothing. Instead it offers a legal benefit to businesses that voluntarily run a decent security programme, and that benefit is worth understanding, because it turns security spending into something you can point at in a courtroom rather than a cost you defend to a board.
It has been on the books since November 2, 2018. In conversations with Ohio businesses across manufacturing, healthcare, professional services and the defense supply chain, we can count on one hand the number who knew it existed.
What the statute actually provides
The Ohio Data Protection Act was enacted as Substitute Senate Bill 220 by the 132nd General Assembly, and lives at Ohio Revised Code Chapter 1354, sections 1354.01 through 1354.05. Ohio was the first state to pass a law of this kind, and several other states have since copied the structure.
The core of it, in §1354.02: a covered entity that creates, maintains and complies with a written cybersecurity programme meeting the statute's requirements is entitled to an affirmative defence to any cause of action sounding in tort that is brought under Ohio law or in Ohio courts and that alleges the failure to implement reasonable information security controls resulted in a data breach.
Read that carefully, because the wording is precise. It is a defence, not immunity. It applies to tort claims. And it is available only if the programme existed and was being complied with at the time of the breach — you cannot build one afterwards and claim the benefit.
What the programme has to contain
The statute asks for a written programme containing administrative, technical and physical safeguards, designed to do three things:
- Protect the security and confidentiality of the information
- Protect against any anticipated threats or hazards to its security or integrity
- Protect against unauthorised access to and acquisition of the information that is likely to result in a material risk of identity theft or other fraud
Those three purposes will look familiar to anyone who has read the GLBA Safeguards Rule — the drafting borrows heavily from it.
The eight ways to qualify
§1354.03 is where the statute gets concrete, and it is unusually generous about how you can get there.
If you are not otherwise regulated, your programme must reasonably conform to one of six named frameworks:
- The NIST Cybersecurity Framework
- NIST Special Publication 800-171
- NIST Special Publications 800-53 and 800-53a
- The FedRAMP Security Assessment Framework
- The Center for Internet Security Critical Security Controls
- The ISO/IEC 27000 family
If you are already regulated, conforming to the security requirements of the regime you are already subject to qualifies you — HIPAA's Security Rule at 45 CFR Part 164 Subpart C, Title V of Gramm-Leach-Bliley, FISMA, or HITECH.
If you take card payments, the statute treats PCI DSS as a partial answer: you comply with PCI DSS and conform to one of the frameworks in the first list.
For most Ohio SMBs that are not already in a regulated regime, the CIS Critical Security Controls are the pragmatic choice. They are free, they are ordered by priority, Implementation Group 1 is explicitly scoped for smaller organisations, and they translate into concrete technical work rather than policy abstractions. The NIST Cybersecurity Framework is the other sensible default if you want something that maps cleanly onto board-level reporting.
One maintenance obligation worth diarising: when a framework is revised, you have one year from the revision's effective date to conform to the updated version. A programme pinned to a superseded revision drifts out of qualification quietly.
"Reasonably conforms" is doing a lot of work
Here is the honest weak point. The statute does not define what it means to "reasonably conform" to a framework, and it does not say how a defendant proves it. That ambiguity cuts both ways: it gives a small business room to run a proportionate programme, and it gives a plaintiff's lawyer room to argue your conformance was nominal.
What closes that gap is evidence. A framework mapping that shows which controls you implemented and how. Dated artefacts showing the controls were operating — access reviews, patch records, training completions, log retention, incident tickets. A risk assessment that was actually revisited when the environment changed. In practice, the difference between a business that can raise this defence credibly and one that cannot is almost entirely a documentation difference.
Who counts as a covered entity
Broadly, almost everyone. §1354.01 defines a covered entity as a business that accesses, maintains, communicates or processes personal information or restricted information through systems, networks or services located in or outside this state. "Business" is drawn widely — LLCs, partnerships, corporations, sole proprietorships, associations, state institutions of higher education, financial institutions and their parents and subsidiaries.
If you hold customer or employee records on a computer, you are almost certainly a covered entity. Being small does not exclude you, and neither does hosting your data with a cloud provider outside Ohio.
Ohio's second tier: restricted information
This part is distinctive and frequently missed. The statute recognises two categories of data.
Personal information takes its meaning from Ohio's breach-notification statute, §1349.19 — the familiar name-plus-identifier construction.
Restricted information is broader: information about an individual, other than personal information, that can be used to distinguish or trace that individual's identity, or that is linked or linkable to an individual, where the information is unencrypted, unredacted and unaltered, and where a breach would create a material risk of identity theft or other fraud.
Why it matters: the scope of your defence tracks the scope of your programme. A programme written to protect personal information earns a defence against claims involving personal information. A programme written to cover both personal and restricted information earns the broader defence. If you are going to do this work, scoping the programme to both is usually the better decision — the incremental effort is small and the protection is materially wider.
Scaled to your business, not to an enterprise
The statute anticipates the obvious objection — that a fifteen-person firm cannot run a defence-contractor security programme — and answers it directly. A programme's scale and scope is appropriate if it is based on:
- The size and complexity of the covered entity
- The nature and scope of its activities
- The sensitivity of the information to be protected
- The cost and availability of tools to improve information security and reduce vulnerabilities
- The resources available to the covered entity
This is the provision that makes the law usable by ordinary Ohio businesses. You are not held to what a hospital system or a bank would implement. You are held to what is reasonable for an organisation of your size, handling your data, with your resources — provided you can show you thought about it and wrote it down.
Four limits worth understanding
We would rather you go in clear-eyed than oversold.
1. It is a defence, not immunity. You must plead it and prove it. It does not prevent a lawsuit being filed; it gives you a recognised basis for defeating one. The cost and disruption of litigation still land on you.
2. It covers tort claims only. It does not shield you from regulatory enforcement. An OCR investigation under HIPAA, an FTC action under the Safeguards Rule, a state attorney general, or your obligations under Ohio's breach-notification statute all sit outside its reach entirely. Notification duties are unaffected.
3. It is largely untested. The Act has been law since 2018, and there is very little published case law showing how Ohio courts apply it — including on the central question of what "reasonably conforms" requires. Anyone telling you exactly how a court will treat your programme is guessing.
4. It creates no private right of action. §1354.04 is explicit that the chapter does not create a private right of action, including a class action. That protects you — nobody can sue you for failing to have a conforming programme — but it also means the statute imposes no floor. Compliance is entirely voluntary, and the law sets no minimum standard.
What to actually do
If you want to be in a position to raise this defence, the work is unglamorous and finite.
- Pick a framework and name it in writing. For most unregulated Ohio SMBs, CIS Controls Implementation Group 1. If you are already under HIPAA, GLBA, FISMA or HITECH, you may already be most of the way there.
- Scope the programme to personal and restricted information. Broader defence, marginal extra effort.
- Run a real risk assessment and revisit it when the environment changes — new locations, new systems, a cloud migration, an acquisition.
- Write the programme down, with the administrative, technical and physical safeguards actually in place, and record the reasoning behind the scale decisions you made under the five factors. That reasoning is itself evidence.
- Instrument the controls so they generate dated evidence without anyone having to remember. Access reviews, patching records, training completions, log retention, incident documentation.
- Diarise framework revisions — one year to conform.
- Have counsel review it. This is a legal position. We build and operate the controls; a lawyer should confirm the posture.
Why bother, if it is untested?
Because every item on that list is something a well-run business should be doing regardless, and the safe harbour is the rare case where the security work has a second payoff attached.
The same programme that positions you for this defence also answers the security questionnaire your largest customer sends, supports the control attestations on your cyber-insurance renewal, shortens your next audit, and — most importantly — genuinely reduces the chance you ever need the defence at all. The legal benefit is a reason to start. It is not the reason the work matters.
If you are an Ohio business and nobody has ever mentioned Chapter 1354 to you, that is worth a conversation with whoever handles your security, whether or not that turns out to be us.
Want to know how close your current programme is to conforming with a recognised framework?
This article is general information about Ohio law and is not legal advice, and it does not create an attorney-client relationship. Whether the affirmative defence in ORC Chapter 1354 is available in any particular circumstance is a question for your own counsel. Any Torchsec engagement is governed by the executed Torchsec service agreement.
