Who counts as a covered entity, and what information does the chapter cover?
The chapter builds the term in two steps. First, "business" is defined broadly in 1354.01(A): any limited liability company, limited liability partnership, corporation, sole proprietorship, association, state institution of higher education as defined in section 3345.011, private college as defined in section 3365.01, or other group, however organized and whether operating for profit or not for profit. The definition expressly includes financial institutions organized, chartered, or licensed under the laws of Ohio, another state, the United States, or another country. It also includes the parent or subsidiary of any of the above. Nonprofits are in. A one-person sole proprietorship is in.
Second, 1354.01(B) narrows "business" to "covered entity": a business that accesses, maintains, communicates, or processes personal information or restricted information in or through one or more systems, networks, or services. Note the last clause. Those systems, networks, or services may be "located in or outside this state." Where the servers sit is not the test. The test is whether the business touches the covered data.
"Personal information" is not defined inside Chapter 1354. Division (D) borrows it whole from section 1349.19 of the Revised Code, Ohio’s breach notification statute. The exact boundary of that term is set in 1349.19, not in this chapter.
"Restricted information" in 1354.01(E) is the chapter’s own term, and it is a four-part test. The information must (1) be about an individual, (2) be something other than personal information, (3) alone or combined with other information (including personal information) be usable to distinguish or trace that individual’s identity, or be linked or linkable to that individual, and (4) not be encrypted, redacted, or altered by any method or technology in a way that makes it unreadable. On top of all that, the breach of it must be likely to result in a material risk of identity theft or other fraud to person or property. "Encrypted," "individual," and "redacted" also carry their 1349.19 meanings. Restricted information matters because it is what separates the two tiers of the defense, covered in the next section.
"Data breach" is defined in 1354.01(C) and is narrower than everyday usage. It means unauthorized access to and acquisition of computerized data that compromises the security or confidentiality of personal information or restricted information owned by or licensed to a covered entity, and that causes, reasonably is believed to have caused, or reasonably is believed will cause a material risk of identity theft or other fraud to person or property. Access alone is not enough. The definition requires access and acquisition.
Two things are carved out of "data breach" entirely. Under (C)(1), good faith acquisition by the covered entity’s own employee or agent for the covered entity’s purposes is not a data breach, provided the information is not used for an unlawful purpose or subject to further unauthorized disclosure. Under (C)(2), acquisition under a search warrant, subpoena, or other court order, or under a subpoena, order, or duty of a regulatory state agency, is not a data breach either.
What are the two tiers, and what does each one earn?
Chapter 1354 does not order any business to do anything. It sets out something a covered entity can choose to build, and it names what that choice earns in court. The words in the statute are conditional: a covered entity "seeking an affirmative defense" under sections 1354.01 to 1354.05 shall do one of two things. An entity that is not seeking the defense is asked nothing by the section. Whether the defense is available to any particular business in any particular case is a legal question for that business and its own counsel. TTS Cyber is an IT company, not a law firm, and cannot answer it.
There are two tiers, and they are not the same. Under 1354.02(A)(1), the program covers personal information. Under 1354.02(A)(2), the program covers both personal information and restricted information. Everything else in the two tiers is worded identically. The only difference is the scope of information the safeguards protect.
The two tiers earn two different defenses. Division (D)(1) says a covered entity that satisfies (A)(1), (B), and (C) is entitled to an affirmative defense to a cause of action alleging that the failure to implement reasonable information security controls resulted in a data breach concerning personal information. Division (D)(2) says a covered entity that satisfies (A)(2), (B), and (C) is entitled to that defense where the claim concerns a data breach of personal information or restricted information. The wider program earns the wider defense. Note also that (D) requires all three of (A), (B), and (C) together: the tier chosen, the design goals, and the scale factors. Meeting one or two of them is not what the statute describes.
The definitions matter to the tier choice. "Personal information" takes the meaning it has in section 1349.19 of the Revised Code, per 1354.01(D). "Restricted information," defined at 1354.01(E), is information about an individual other than personal information that, alone or in combination with other information (including personal information) can be used to distinguish or trace that individual’s identity, or that is linked or linkable to an individual, where the information is not encrypted, redacted, or altered by any method or technology in such a manner that it is 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.
So what does the written program actually have to contain? Section 1354.02(A) is specific on four points. First, it is written. Second, it contains administrative, technical, and physical safeguards for the protection of the information in the tier chosen. The statute names all three categories. Third, three verbs apply to it: create, maintain, and comply with. A program that exists on paper but is not maintained, or not followed, is not what (A)(1) or (A)(2) describes. Fourth, it reasonably conforms to an industry recognized cybersecurity framework, as described in section 1354.03. Two further requirements sit outside (A), and division (D) folds them in: the design goals in 1354.02(B) and the scale-and-scope factors in 1354.02(C), both set out below. The individual controls are listed nowhere in 1354.02. They come from the framework the program conforms to under 1354.03, and that section sets out which frameworks count and its separate one-year windows for staying current, each with its own trigger.
What does the affirmative defense actually reach, and what does it leave untouched?
Both tiers are limited the same way, and the words are worth quoting because everything turns on them. The defense runs to "any cause of action sounding in tort that is brought under the laws of this state or in the courts of this state and that alleges that the failure to implement reasonable information security controls resulted in a data breach." (D)(1) closes on "concerning personal information" and (D)(2) on "concerning personal information or restricted information." Four limits are stacked in that one sentence. The claim must sound in tort. It must be brought under Ohio law or in an Ohio court. It must allege a failure to implement reasonable information security controls. And it must allege that failure resulted in a data breach as 1354.01(C) defines that term.
What follows from that is a list of things the text simply does not address. It is not immunity. It says nothing about claims that sound in contract. It says nothing about federal enforcement or regulatory action. It does not touch Ohio’s breach notification duties under section 1349.19. The chapter borrows that statute’s definition of personal information and leaves its obligations alone. And earning the defense is conditional on the whole package: (D) grants it only to an entity that satisfies (A)(1) or (A)(2) along with the design requirements in 1354.02(B) and the scale-and-scope factors in 1354.02(C).
Then 1354.04 draws a line in the other direction. These sections "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." Chapter 1354 creates no new claim anyone can bring against a business for failing to have a program. It is a defense a defendant can raise. That limits what the chapter hands plaintiffs; it does not narrow the defense.
One last word on the statute’s own wording. Division (D) grants the defense "to any cause of action ... that is brought." So the defense operates inside a case someone has already brought, and nothing in the text says it keeps a claim from being brought in the first place. How a court would weigh it in any particular case is not a question this page can answer. What is measurable is where a business’s controls stand today: TTS Cyber’s vCISO and Compliance-as-a-Service practice does gap analysis, evidence tracking, control maintenance, and audit readiness against SOC 2, ISO 27001, and CMMC, and the independent $349 Security Analysis maps findings across 38 compliance frameworks. Those are our frameworks. Section 1354.03 names its own list, set out below, and the two are not the same list. No assessment we run certifies conformance under this chapter, supplies the defense, or answers the legal questions. Those belong to a business’s own attorney.
What does a program have to be designed to do to support the defense, and how big does it have to be?
Division (B) sets three design goals, and they apply to a covered entity that is going after the affirmative defense. Section 1354.02(A) speaks to "[a] covered entity seeking an affirmative defense." Nothing in the chapter orders any business to build a program at all. For an entity that is seeking it, the program "shall be designed to do all of the following" with respect to the information covered by the tier chosen under (A)(1) or (A)(2). All three apply. They are: protect the security and confidentiality of the information; protect against any anticipated threats or hazards to the security or integrity of the information; 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 to the individual to whom the information relates.
Read those three together and they say something useful. The first is about security and confidentiality. The second is forward-looking. It covers anticipated threats and hazards, not only the ones that have already landed. The third is aimed at the specific harm the chapter cares about, and it echoes the data-breach definition in 1354.01(C), which turns on "a material risk of identity theft or other fraud to person or property." The wording in (B)(3) is close but not identical: there the risk runs "to the individual to whom the information relates." The scope of the design goals follows the tier. Where a program was built to (A)(1), "the information" means personal information. Where it was built to (A)(2), it means personal and restricted information.
Division (C) is the part about size. It says the scale and scope of the program "is appropriate if it is based on all of the following factors." There are five: the size and complexity of the covered entity; the nature and scope of the entity’s 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.
Three of those five are about the business itself rather than the threat. Size and complexity. Cost and availability of tools. Resources available. The statute does not set a floor of spending, a headcount, or a control count. It says scale and scope is appropriate if it is based on the five listed factors, and three of them are facts about what the entity is and what it has.
Two cautions on (C). The word is "all." The text says appropriate scale and scope is based on all five factors, so leaning on the resource factor alone is not what the section says. And two of the five push the other direction: the nature and scope of the entity’s activities, and the sensitivity of the information it holds. A small business handling highly sensitive information is being measured on that too. Being small does not by itself settle the question.
A practical note, and not a legal one. The design goals in (B) and the factors in (C) are written to be applied to a specific business, with its own information, activities, and resources. Knowing what you hold, where it lives, and how it is protected today is the groundwork for any of it.
What counts as "reasonably conforms to an industry recognized cybersecurity framework"?
Section 1354.02 says that a covered entity seeking the affirmative defense is the one whose written cybersecurity program has to reasonably conform to an industry recognized cybersecurity framework "as described in section 1354.03." Section 1354.03 is where that phrase gets its meaning. It opens by saying a program reasonably conforms "if division (A), (B), or (C) of this section is satisfied." So there are three separate routes, and satisfying any one of them meets the test. None of this is required of anyone. Chapter 1354 creates an affirmative defense a covered entity may raise; it does not order any business to build a program at all.
Route one is division (A)(1). The program reasonably conforms to the current version of any of the following, or any combination of them, subject to divisions (A)(2) and (D). The statute names exactly six, and these are its own words: (a) the "framework for improving critical infrastructure cybersecurity" developed by the "national institute of standards and technology" (NIST); (b) "NIST special publication 800-171"; (c) "NIST special publications 800-53 and 800-53a"; (d) the "federal risk and authorization management program (FedRAMP) security assessment framework"; (e) the "center for internet security critical security controls for effective cyber defense"; (f) the "international organization for standardization/international electrotechnical commission 27000 family - information security management systems." That is the whole list in (A)(1). Popular frameworks that are not on it are not on it, and the statute says "current version" rather than naming any particular edition or release number.
Route two is division (B)(1), and it is written for regulated entities. Two things have to be true. First, the covered entity "is regulated by the state, by the federal government, or both, or is otherwise subject to the requirements of any of the laws or regulations listed below." Second, the cybersecurity program "reasonably conforms to the entirety of the current version" of any of the four the statute lists, subject to division (B)(2). Note the words "the entirety of," which appear in (B) and not in (A). The four are: (a) the security requirements of the "Health Insurance Portability and Accountability Act of 1996," as set forth in 45 CFR Part 164 Subpart C; (b) Title V of the "Gramm-Leach-Bliley Act of 1999," Public Law 106-102, as amended; (c) the "Federal Information Security Modernization Act of 2014," Public Law 113-283; (d) the "Health Information Technology for Economic and Clinical Health Act," as set forth in 45 CFR part 162.
Route three is division (C)(1), the PCI route, and it is the only one that asks for two things at once. The program has to reasonably comply with the current version of the "payment card industry (PCI) data security standard" AND conform to the current version of "another applicable industry recognized cybersecurity framework listed in division (A) of this section," subject to divisions (C)(2) and (D). PCI DSS on its own does not satisfy division (C). It has to be paired with one of the six frameworks named in (A). Also worth noting: the statute uses "complies with" for the PCI standard and "conforms to" for the frameworks, and division (D) keeps both words, requiring an entity to "conform to or comply with, as applicable, all of the revised frameworks."
Which route fits a given business is a question about that business’s own regulators, payment activity, and existing controls. TTS Cyber is an IT company, not a law firm, and cannot tell any reader whether the defense in Chapter 1354 applies to them. That is a question for their own counsel.
When a framework changes, how long is the one-year window, and what starts it?
Each route carries its own catch-up clock, and there is a fourth clock for combinations. All four give one year. They do not all start on the same event. Anyone tracking this needs to know which route they are on, because the trigger date is different.
Division (A)(2) covers the six frameworks. Its words: "When a final revision to a framework listed in division (A)(1) of this section is published, a covered entity whose cybersecurity program reasonably conforms to that framework shall reasonably conform to the revised framework not later than one year after the publication date stated in the revision." Two details matter. The revision has to be a final one, and the clock runs from the publication date stated in the revision itself, not from the date anyone noticed it, downloaded it, or started work.
Division (B)(2) covers the regulated-entity route, and its trigger is different. Its words: "When a framework listed in division (B)(1) of this section is amended, a covered entity whose cybersecurity program reasonably conforms to that framework shall reasonably conform to the amended framework not later than one year after the effective date of the amended framework." Here the event is an amendment rather than a published revision, and the clock runs from the amendment’s effective date. That is the only date (B)(2) names.
Division (C)(2) covers the PCI standard and reads like (A)(2). Its words: "When a final revision to the ’PCI data security standard’ is published, a covered entity whose cybersecurity program reasonably complies with that standard shall reasonably comply with the revised standard not later than one year after the publication date stated in the revision." Again: a final revision, and the publication date stated in the revision.
Division (D) is the combination rule, and it is easy to miss. It applies where a program "reasonably conforms to a combination of industry recognized cybersecurity frameworks, or complies with a standard, as in the case of the payment card industry (PCI) data security standard, as described in division (A) or (C) of this section," and "two or more of those frameworks are revised." In that case the entity has to conform to or comply with all of the revised frameworks "not later than one year after the latest publication date stated in the revisions." So with staggered revisions, the single deadline is measured from the latest publication date, not the earliest. It applies to all of them. Note also which routes (D) reaches: divisions (A)(1) and (C)(1) are each expressly made subject to (D), while (B)(1) is made subject only to (B)(2).
A practical way to keep this straight: one year is the length in all four, but (A) and (C) start from a stated publication date, (B) starts from an amendment’s effective date, and (D) starts from the latest stated publication date when a combination is revised. Nothing in the chapter requires a business to adopt any framework or to meet any of these dates. The dates matter only to a covered entity that is relying on a route in 1354.03 to support the affirmative defense in 1354.02(D), and sections 1354.01 to 1354.05 do not name any state agency to review, approve, or certify conformance.
One more section rounds out the chapter. Section 1354.05 is a severability clause: if any provision of sections 1354.01 to 1354.05, or its application to a covered entity, is held invalid, the remainder of those provisions and their application to other covered entities are not affected.