What is the Ohio Data Protection Act (ORC 1354)?

Ohio Revised Code Chapter 1354, titled Businesses Maintaining Recognized Cybersecurity Programs, was enacted by Senate Bill 220 of the 132nd General Assembly. Sections 1354.02 through 1354.05 took effect on November 2, 2018, and the definitions in 1354.01 took effect on April 5, 2019. It creates a voluntary safe harbor: a covered entity that creates, maintains and complies with a written cybersecurity program conforming to one of the recognized frameworks may plead that program as an affirmative defense to a tort claim alleging that inadequate security controls caused a data breach. Nothing in the chapter requires a business to do any of this.

Which cybersecurity frameworks qualify for the ORC 1354 safe harbor?

Section 1354.03 division (A) lists the NIST Framework for Improving Critical Infrastructure Cybersecurity, 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, and the ISO/IEC 27000 family. Division (B) covers entities already regulated under the HIPAA Security Rule, Gramm-Leach-Bliley Act Title V, the Federal Information Security Modernization Act of 2014, or the HITECH Act. Division (C) covers entities subject to the PCI Data Security Standard, which must conform to PCI DSS and to one of the division (A) frameworks. When a framework is revised, a covered entity has one year from the publication or effective date of the revision to conform to it.

Is a small business too small to qualify for the ORC 1354 safe harbor?

No. Section 1354.02 makes the scale and scope of the program the test rather than any fixed control count. The factors are 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, and the resources available to the covered entity. A twelve-person firm is measured against what a twelve-person firm can reasonably do, which is what makes the safe harbor reachable rather than decorative. It also means the program has to be genuinely proportionate: a two-page policy at a company processing payment data is unlikely to satisfy the test.

What does a business actually have to produce to rely on ORC 1354?

A written cybersecurity program containing administrative, technical and physical safeguards, which reasonably conforms to a named framework, and evidence that the program was complied with rather than merely written. Section 1354.02 requires the program to be designed to protect the security and confidentiality of the information, protect against anticipated threats or hazards to its security or integrity, and protect against unauthorized access to and acquisition of the information that is likely to result in a material risk of identity theft or other fraud. In practice the defensible artifacts are the policy itself, a control mapping to the chosen framework, an asset inventory, dated vulnerability scan and remediation records, access reviews, training records and incident response exercises.

How does ORC 1354 relate to ORC 9.64?

They are the two halves of Ohio's cybersecurity policy and they work in opposite directions. ORC 9.64 imposes a duty on political subdivisions to adopt a cybersecurity program, with phased deadlines that have now passed. ORC 1354 imposes no duty on anyone; it offers businesses a litigation benefit in exchange for doing voluntarily what 9.64 requires of local government. The underlying technical work is close to identical, which matters for a business that contracts with Ohio public entities and is being asked about its own posture during procurement.

A consultant seated at a conference table turns the pages of a printed information security policy binder, framework control-mapping sheets spread beside a laptop showing an asset inventory, with a single red folder resting on the table edge

Compliance / Cybersecurity

ORC 1354 Cybersecurity Safe Harbor: What Ohio's Data Protection Act Actually Protects

Q: Who counts as a covered entity under ORC 1354?

Section 1354.01 defines a covered entity as a business that accesses, maintains, communicates or processes personal information or restricted information in or through one or more systems, networks or services located inside or outside Ohio. Business is defined broadly and covers limited liability companies, limited liability partnerships, corporations, sole proprietorships, associations, state institutions of higher education, private colleges and other groups, however organized and whether operating for profit or not for profit, including financial institutions and their parents or subsidiaries. Political subdivisions are not the subject of this chapter; the Ohio cybersecurity obligation aimed at townships, counties and municipalities is ORC 9.64.

Q: Does ORC 1354 protect a business from being sued after a data breach?

No. It is an affirmative defense, not immunity from suit. A covered entity can still be sued, still has to appear, and still bears the burden of pleading and proving the defense. What the statute changes is the ground the case is fought on: instead of arguing about what reasonable security ought to have looked like in hindsight, the entity points to a written program that reasonably conformed to a named framework at the time of the breach. Section 1354.04 also states that sections 1354.01 to 1354.05 shall not be construed to provide a private right of action, including a class action, so the chapter does not create a new claim against anyone either.

Ohio will trade you a legal defense for a written cybersecurity program. Here is exactly what the trade is, which frameworks qualify, and what you have to be able to prove when it matters.

By William Bradshaw | August 24, 2026 | 12 min read

Most cybersecurity regulation tells you what you must do and what happens if you do not. Ohio Revised Code Chapter 1354 does neither. It requires nothing of anybody. Instead it makes an offer: build a written cybersecurity program that reasonably conforms to a recognized framework, and if you are later sued over a data breach, you may plead that program as an affirmative defense.

That structure is unusual enough that it gets misread in both directions. Some businesses hear "safe harbor" and assume it means they cannot be sued. Others hear "voluntary" and assume it is not worth the effort. Both readings cost money, in different ways and at different times.

This article works through what the chapter actually says: who it covers, what the defense does and does not do, which frameworks qualify, and what a covered entity has to be able to put in front of a court. It is practical guidance from a managed-services lens, not legal advice; confirm how the chapter applies to your specific entity with the statute and your legal counsel.

If you are a township, a county, a fire district or another political subdivision, this is not your statute. Yours is ORC 9.64, whose readiness requirements we cover separately, and its deadlines have already passed.

What Chapter 1354 Is

Chapter 1354 is titled Businesses Maintaining Recognized Cybersecurity Programs. It was enacted by Senate Bill 220 of the 132nd General Assembly and is commonly called the Ohio Data Protection Act. Sections 1354.02 through 1354.05 took effect on November 2, 2018. The definitions section, 1354.01, took effect on April 5, 2019.

The whole chapter is five short sections, and it is worth knowing what each one does before reading anything written about it:

Section	Title	What it does
1354.01	Definitions	Defines business, covered entity, data breach, personal information and restricted information.
1354.02	Safe harbor requirements	Creates the affirmative defense, sets the design objectives for a qualifying program, and defines the scale and scope test.
1354.03	Reasonable conformance	Lists the frameworks a program may conform to, and the one-year window to catch up after a framework is revised.
1354.04	No private right of action	States that the chapter creates no cause of action, including no class action.
1354.05	Severability	Standard severability clause.

Source: Ohio Revised Code Chapter 1354, as published by the Ohio Legislative Service Commission.

Who Counts as a Covered Entity

Section 1354.01 defines a covered entity as a business that accesses, maintains, communicates or processes personal information or restricted information in or through one or more systems, networks or services located in or outside Ohio.

The definition of business underneath that is deliberately wide. It reaches limited liability companies, limited liability partnerships, corporations, sole proprietorships, associations, state institutions of higher education, private colleges and other groups, however organized and whether operating for profit or not for profit, including financial institutions and their parents or subsidiaries.

Two consequences that catch people out:

Nonprofits are in. The phrase "whether operating for profit or not for profit" is doing real work. A community foundation, a trade association or a private school is a business for the purposes of this chapter.
Political subdivisions are not the subject of this chapter. Townships, counties, municipalities, fire and EMS districts are addressed by ORC 9.64, which imposes an obligation rather than offering an incentive. If you sit on both sides, for example a company that contracts with public entities, the two read together are useful: the technical work is nearly the same, and your 9.64 clients will increasingly ask what you do about your own posture.

The geographic scope is broader than most people expect. The systems do not have to be in Ohio. What matters is that the entity is a business handling the covered information and that the claim is brought under Ohio law or in an Ohio court. A business with all its infrastructure in a cloud region three states away is still a covered entity.

What the Defense Actually Does, and What It Does Not

Section 1354.02 entitles a qualifying covered entity to an affirmative defense to any cause of action sounding in tort that is brought under the laws of Ohio or in an Ohio court and that alleges that the failure to implement reasonable information security controls resulted in a data breach. The section provides for it in two flavours: one keyed to personal information, and one keyed to personal information and restricted information together.

The word doing the work is affirmative. An affirmative defense is something the defendant raises and carries. It is not a bar to being sued.

What it gives you

A defined, named standard to be measured against, chosen in advance by you rather than reconstructed by an expert witness afterwards.
A shift in the argument from "what would reasonable security have looked like" to "did this program reasonably conform to the framework it named".
A reason to have documentation that is useful long before any lawsuit: in procurement, in insurance renewal, and in an incident.

What it does not give you

Immunity from suit. You can still be sued and still have to defend.
Any protection against contractual claims, regulatory enforcement, or obligations arising outside Ohio tort law.
Relief from Ohio's breach notification duties under ORC 1349.19, which are a separate obligation and unaffected by this chapter.
Anything at all if the program exists on paper and was not complied with.

Section 1354.04 is the other half of the bargain and it is short enough to quote: sections 1354.01 to 1354.05 shall not be construed to provide a private right of action, including a class action, with respect to any act or practice regulated under those sections. In other words the chapter does not create a new way to sue a business that has no program. Not having one leaves you exactly where you would have been in 2018, which is the point: the statute is a carrot with no stick attached.

Restricted Information Is the Part People Miss

Most Ohio businesses already have a working idea of "personal information" from the breach notification statute: name plus a Social Security number, driver's licence number, or financial account number with the access code. Chapter 1354 adds a second, wider category.

Restricted information is defined as any information about an individual, other than personal information, that alone or in combination with other information can be used to distinguish or trace the individual's identity or that is linked or linkable to an individual, where the information is not encrypted, redacted or otherwise made unreadable, and where a breach of it is likely to result in a material risk of identity theft or other fraud to person or property.

That is a much larger surface than the notification statute's list, and it is optional in a specific way: the higher tier of the affirmative defense is the one that covers restricted information as well as personal information, and it is available only to a program whose safeguards protect both.

The practical read. If you scope your written program narrowly to the data elements that trigger breach notification, you have built toward the narrower defense. Scoping to restricted information as well usually means taking the asset inventory seriously, because you cannot protect a category you have not located. That inventory is the piece most small programs are missing, and it is the piece every framework in 1354.03 asks for first.

What a Qualifying Program Has to Do

Section 1354.02 requires a covered entity to create, maintain and comply with a written cybersecurity program that contains administrative, technical and physical safeguards, and that reasonably conforms to an industry recognized framework. Note the three verbs: create, maintain and comply with. A program written once and never operated satisfies one of the three.

The program must be designed to do three things:

1. Protect the security and confidentiality of the information

The baseline. Access control, encryption where it is warranted, and a defensible answer to who can reach what.

2. Protect against anticipated threats or hazards to its security or integrity

The word "anticipated" implies you looked. This is where a documented risk assessment and a recurring vulnerability scan earn their place, because they are the evidence that anticipation happened on a schedule rather than in hindsight.

3. Protect against unauthorized access to and acquisition of the information that is likely to result in a material risk of identity theft or other fraud

The outcome test. It is the same standard the definition of data breach uses, which keeps the chapter internally consistent.

If those three objectives read like the Gramm-Leach-Bliley Safeguards Rule, that is because the drafting borrows from it. A business already subject to GLBA has done most of this work and should be mapping what exists rather than starting over.

Which Frameworks Qualify (1354.03)

Section 1354.03 is the operative list. It has three divisions, and which one applies to you depends on what else already regulates you.

Division (A): the general list

Any covered entity may conform its program to one of these:

The NIST Framework for Improving Critical Infrastructure Cybersecurity, better known as the NIST Cybersecurity Framework
NIST Special Publication 800-171
NIST Special Publications 800-53 and 800-53a
The Federal Risk and Authorization Management Program (FedRAMP) security assessment framework
The Center for Internet Security Critical Security Controls for Effective Cyber Defense
The ISO/IEC 27000 family of information security management standards

Division (B): already-regulated entities

A covered entity regulated by the state or federal government, or otherwise subject to one of the following, may conform to that instead:

The HIPAA Security Rule, at 45 CFR Part 164 Subpart C
Title V of the Gramm-Leach-Bliley Act
The Federal Information Security Modernization Act of 2014
The HITECH Act requirements at 45 CFR Part 162

Division (C): payment card data

A covered entity subject to the PCI Data Security Standard has to do both: comply with PCI DSS and conform to one of the division (A) frameworks. PCI on its own is not sufficient for the safe harbor. That is the single most commonly misstated point about this chapter, and it matters to any Ohio retailer or restaurant group whose entire security posture is currently defined by its annual PCI attestation.

The one-year clock nobody tracks

When a framework is revised, a covered entity must conform to the revision within one year of its publication date (division A) or effective date (division B). Frameworks move: NIST published CSF 2.0 in February 2024, a structural revision that added the Govern function. An organization whose written program still maps to CSF 1.1 and has never been revisited is relying on a version the statute's clock has already passed. This is the maintenance obligation hiding inside a chapter that otherwise looks like a one-time project, and it is the reason our compliance mapping guide treats the mapping as a living document rather than a deliverable.

The Scale and Scope Test Is What Makes This Reachable

The most common objection to the safe harbor is that NIST CSF or ISO 27001 is enterprise machinery and a thirty-person company cannot run it. Section 1354.02 anticipates that. The scale and scope of the program is appropriate if it is based on the following factors:

Factor	What it means in practice
Size and complexity of the entity	One office and one server room is a different program from nine sites and a hybrid cloud.
Nature and scope of its activities	A design studio and a medical billing company are not held to the same thing.
Sensitivity of the information	The more the loss would hurt the individual, the more the program has to do.
Cost and availability of tools	Controls that are cheap and widely available are harder to justify omitting. Multi-factor authentication has moved firmly into this category.
Resources available to the entity	The test bends toward a small organization, but it bends in proportion to what that organization could reasonably afford.

Read together, these cut in both directions. A small firm cannot be faulted for not running a security operations centre. It can be faulted for not turning on multi-factor authentication, because the fourth factor makes cost and availability an explicit part of the test and that control now costs close to nothing. The same logic is why a recurring vulnerability scan is difficult to argue your way out of: the tooling is available, the cost is low, and the output is dated evidence that you anticipated threats on a schedule.

The Evidence You Would Actually Need

A safe harbor you cannot evidence is not a safe harbor. If the defense is ever pleaded, the question becomes what you can show about the state of the program on the day of the breach, not what you can assemble afterwards. That is a records problem more than a technology problem, and it is where most programs are thin.

The written program

The policy set itself, version controlled and dated, naming the framework it conforms to. Undated policy is close to worthless here, because the question is always what was true at a point in time.

The control mapping

A document tying each framework control to what you actually do, including the ones you consciously scoped out and why. The reasoning behind an exclusion is evidence; a silent gap is not.

The asset inventory

Systems, data stores and the categories of information each holds. Every framework in 1354.03 starts here, and it is the only way to substantiate that the program covered restricted information.

Dated operational records

Scan results and what was remediated, patch records, access reviews, training completion, backup restore tests, and incident exercises. This is the evidence of the "comply with" verb.

The overlap with insurance is not a coincidence. Underwriters have converged on almost exactly this list, which means the work you would do for the safe harbor is largely the work that answers a renewal questionnaire. We walk through that questionnaire line by line in our guide to what Ohio underwriters now demand, and the honest reason most organizations get this documentation built is the renewal rather than the statute.

A Realistic Path for a Business Starting From Nothing

For most small and mid-sized Ohio businesses, the practical entry point is the CIS Critical Security Controls, because they are ordered by priority and written as actions rather than outcomes. NIST CSF is the better choice if you already have a risk-management vocabulary or a customer who asks for it by name. Both are on the division (A) list, so both qualify.

Inventory first. Systems, data stores, and which of them hold personal or restricted information. Until this exists nothing else can be scoped honestly.
Pick one framework and write it down. Naming it in the policy is what converts an ordinary security posture into a conformance claim.
Map what you already do. Most organizations are further along than they think and the mapping exercise mostly documents existing practice.
Close the cheap gaps immediately. Multi-factor authentication, tested backups, and a current patch position. The fourth scale-and-scope factor makes these the hardest omissions to defend.
Put the recurring evidence on a schedule. Scanning, access review, training, restore tests. Dated records beat a thicker policy every time.
Review annually and after any framework revision, inside the one-year window that 1354.03 sets.

If you want a fuller worked example of steps two and three against a specific framework, our NIST CSF 2.0 implementation guide walks all six functions with concrete examples. It is written for local government, but the framework mechanics are identical for a business, and CSF 2.0 is the current version the one-year clock refers to.

Frequently Asked Questions

Does ORC 1354 protect a business from being sued after a data breach?

No. It is an affirmative defense, not immunity. You can still be sued, still have to appear, and you carry the burden of pleading and proving the defense. What changes is the ground the case is fought on: a named framework you chose in advance rather than a standard reconstructed in hindsight.

Is my business too small to qualify?

No. Section 1354.02 makes scale and scope the test rather than a fixed control count, and two of the five factors are explicitly about cost and available resources. A small firm is measured against what a small firm can reasonably do.

We are PCI compliant. Is that enough?

Not on its own. Division (C) of 1354.03 requires an entity subject to PCI DSS to comply with PCI DSS and to conform to one of the division (A) frameworks. This is the most commonly misstated point in the chapter.

Does this replace Ohio's breach notification requirements?

No. Notification duties under ORC 1349.19 are separate and unaffected. Chapter 1354 changes what happens in a later tort claim; it does not change what you must do in the days after discovering a breach.

Do we have to be certified or audited against the framework?

The chapter requires reasonable conformance, not certification, and it names no auditor or registry. There is no filing and no state body that approves a program. That keeps the cost down and puts the entire weight on your own documentation, which is why the records matter as much as the controls.

We are a township, not a business. Does this apply to us?

This chapter is aimed at businesses. The Ohio cybersecurity requirement for political subdivisions is ORC 9.64, whose phased deadlines have passed, and we cover it in a separate readiness guide.

Want to Know What Your Program Would Actually Have to Show?

Bullium builds and operates written cybersecurity programs for Ohio businesses, nonprofits and public entities, including the asset inventory, the framework mapping and the recurring evidence that makes a conformance claim defensible. We will review what you already have, tell you plainly which of the 1354.03 frameworks fits your situation, and show you the gaps that would matter. No commitment to engage further.

Book a Consultation Security Consulting Services