Cybersecurity team tracing breach scope

The Ohio Data Protection Act (ORC Chapter 1354) gives covered businesses a voluntary affirmative defense to certain tort claims when they maintain a qualifying written cybersecurity program. It’s not a privacy law and it doesn’t excuse you from breach-notification duties. If you want the legal shield, you need to build, document, and maintain a program mapped to a recognized security framework, sized to fit your business.

TL;DR:

  • Maintaining a cybersecurity program must be scaled to your business size, handling data sensitivity with frameworks like NIST CSF or CIS Controls, or risk losing the defense.
  • The defense only applies to tort claims under Ohio law and does not cover contract disputes, federal regulations, or breach-notification requirements.
  • A breach involving personal or restricted information triggers a mandatory notification within 45 days, regardless of your cybersecurity program’s quality.
  • Demonstrating reasonable conformance depends on documented policies, framework mapping, and ongoing updates, with annual reviews and strict record-keeping essential.
  • Outsourcing cybersecurity to a local managed provider ensures consistent documentation, testing, and rapid response, crucial for building and maintaining an ODPA-qualifying program.
Mavericks Office Solutions
Build a Stronger Cybersecurity Program
Mavericks provides managed IT services, cybersecurity, and 24/7 monitoring for businesses seeking secure, well-supported technology.

Explore IT solutions

Table of Contents

What Is the Ohio Data Protection Act and Why Does It Exist?

Ohio Senate Bill 220 became law on November 2, 2018, creating what legal scholars call one of the country’s more unusual cybersecurity statutes. Instead of mandating specific controls or threatening fines for noncompliance, ORC 1354.02 offers a carrot: businesses that maintain a qualifying written cybersecurity program get an affirmative defense against certain tort claims arising from a data breach.

Think of it as a legal incentive program rather than a mandate. Ohio lawmakers wanted to nudge businesses toward better security practices without creating a compliance bureaucracy or a new set of penalties for the businesses that don’t opt in. There’s no requirement that you build a cybersecurity program under this law. But if you’re sued after a breach and you didn’t have one, you lose access to a defense that could otherwise end the case early.

Here’s how the mechanism works in practice. Say a customer’s personal information is exposed in a breach and that customer sues your business for negligence, alleging you failed to protect their data. Under Ohio’s common law, you’d typically have to litigate whether your security practices were reasonable, a fact-heavy fight that can drag on for months. The ODPA changes that calculation. If you can show the court that you maintained a written cybersecurity program that reasonably conforms to one of the frameworks the statute recognizes, you have an affirmative defense you can raise early in the case.

Legal scholarship treats this incentive design as genuinely distinctive among state cybersecurity laws. One University of Cincinnati Law Review analysis frames the ODPA as a deliberate attempt to reward proactive security investment with a litigation advantage, rather than punishing businesses that fall short. That framing matters for how you think about compliance. This isn’t a checkbox exercise for a regulator. It’s a bet that documenting good security practices now saves you a costly negligence fight later.

Ohio chose this safe-harbor approach partly because comprehensive privacy mandates were (and remain) politically difficult to pass, and partly because the state wanted to avoid burdening small businesses with prescriptive technical requirements they couldn’t realistically meet. The tradeoff is flexibility: the statute tells you what categories of frameworks qualify, but it leaves you room to scale your program to your size, sector, and risk profile.

What Is the Ohio Data Protection Act and Why Does It Exist? — overview diagram

Who and What Does the Ohio Data Protection Act Cover?

The Act applies broadly. Under ORC 1354.01, a “covered entity” is any 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. That’s intentionally wide. If your business touches customer, employee, or patient data in any digital system, you’re almost certainly a covered entity.

The statute distinguishes between two categories of protected data, and the difference shapes what your cybersecurity program actually needs to protect.

Personal information generally means an individual’s name combined with a data element like a Social Security number, driver’s license number, or financial account number, matching the definition used elsewhere in Ohio’s data laws. Restricted information covers a broader category: any information about an individual, other than personal information or publicly available information, that alone or combined with other data could be used to distinguish or trace someone’s identity, or that is linked to a specific person, and where a breach would create a material risk of identity theft or other fraud.

That second category catches things a lot of businesses overlook. Health-adjacent data, biometric identifiers, and detailed behavioral profiles can all qualify as restricted information even when no Social Security number is involved.

A “data breach” under the statute means unauthorized access to and acquisition of computerized data that compromises the security or confidentiality of personal or restricted information, resulting in (or creating a reasonable risk of) identity theft or fraud. A few practical scenarios illustrate where the line falls:

  • An employee laptop with encrypted, unreadable data gets stolen: typically not a qualifying breach, since the data wasn’t actually compromised.
  • A phishing attack exposes a customer database with unencrypted account numbers: qualifies as a breach.
  • An internal system glitch exposes employee names alone, with no other identifying data attached: generally doesn’t meet the definition, since name alone isn’t personal information under the statute.

Getting this classification right matters before you ever reach the affirmative defense question, because the defense only becomes relevant once a breach involving covered data has actually occurred.

How Do You Qualify for the ODPA’s Affirmative Defense?

To claim the defense, your written cybersecurity program has to contain administrative, technical, and physical safeguards, and it has to reasonably conform to one of the frameworks the statute recognizes. “Reasonably conform” is deliberately flexible language, and Chapter 1354 ties that flexibility to your size, the sensitivity of the information you handle, the cost and availability of tools to protect it, and your available resources. A five-person accounting firm and a 400-employee manufacturer will build very different programs and both can still qualify.

The statute enumerates the frameworks that count. Your program needs to reasonably conform to one of these:

  • NIST Cybersecurity Framework (CSF), the most commonly cited baseline for general-purpose programs.
  • NIST Special Publication 800-171, aimed at organizations handling controlled unclassified information, common for government contractors.
  • NIST Special Publication 800-53 or 800-53a, a more rigorous federal-grade control catalog.
  • FedRAMP, relevant if you work with cloud service providers serving federal agencies.
  • CIS Critical Security Controls, a widely adopted, practically oriented control set favored by many small and mid-market businesses.
  • ISO/IEC 27000 family, the international standard many businesses with global operations already use.
  • HIPAA, GLBA, HITECH, or FISMA, for entities already regulated under those federal regimes, since compliance with your sector’s existing rules can satisfy the ODPA independently.
  • PCI DSS, but only when paired with one of the other listed frameworks. PCI alone does not qualify.

The one-year rule deserves its own attention, and it’s the part of the statute that catches unprepared businesses off guard. When one of these frameworks gets revised, meaning NIST publishes an updated CSF version, or ISO issues a new 27001 revision, you have one year from the framework’s revision date to bring your program into conformance with the new version. Miss that window, and you’re arguably relying on an outdated version of the framework at the exact moment you need the defense.

That timing rule is really a governance requirement in disguise. Someone in your organization, whether that’s an IT director, a compliance officer, or a managed service partner, needs to be watching for framework revisions and scheduling an update review the moment a new version drops. Waiting until your annual security review rolls around isn’t good enough if that review happens to fall eleven months after a framework update you missed.

Choosing which framework to adopt comes down to three questions: What size is your business, and what can you realistically maintain? What sector-specific rules already apply to you (a healthcare practice already living under HIPAA has a natural starting point)? And how much documentation rigor can you sustain year over year? CIS Controls tend to fit small and mid-market businesses well because they’re organized in implementation tiers that scale with maturity. NIST CSF suits businesses that want a framework recognized across nearly every industry and regulator conversation. Whatever you choose, pick one you can actually sustain, not the most impressive-sounding option.

What the ODPA Safe Harbor Doesn’t Cover

The defense is narrower than a lot of business owners assume, and misunderstanding its limits is one of the most common mistakes counsel sees. The affirmative defense applies only to tort claims brought under Ohio law or in Ohio courts. Negligence claims arising from a data breach are the clearest example.

It does not extend to contract claims. If a client sues you for breach of a data-protection clause in a services agreement, your ODPA-qualifying program doesn’t defend that claim, because it’s contractual, not tort-based. It does not extend to statutory claims brought under other Ohio or federal statutes. And it provides zero protection against federal regulatory enforcement. The Federal Trade Commission, the Department of Health and Human Services, and other federal regulators can still pursue action against your business regardless of your ODPA status.

Practitioners who write on this statute consistently flag this as the point where clients get confused. One Akron Law Review analysis warns that the ODPA is frequently mischaracterized as a privacy law when it’s really a defensive litigation strategy, nothing more and nothing less. It doesn’t grant Ohio consumers any new rights to access, correct, or delete their data. Ohio still lacks a comprehensive consumer privacy statute along the lines of California’s or Virginia’s, and the ODPA does nothing to close that gap.

The practical consequence: your ODPA program runs parallel to, not instead of, every other compliance obligation you already carry. If you’re a healthcare provider, HIPAA still applies in full. If you handle financial data, GLBA obligations don’t disappear because you built an ODPA-qualifying program. If you process payment card data, PCI DSS rules still govern that data independently of whatever framework you paired it with for ODPA purposes. And regardless of your program’s quality, Ohio’s breach-notification law still requires you to notify affected residents when a qualifying breach occurs.

How Does the ODPA Interact With Ohio’s Breach-Notification Law?

The ODPA and Ohio’s breach-notification statute operate as two separate obligations that happen to intersect at the moment of a breach. ORC 1349.19 requires you to notify affected Ohio residents as soon as possible after discovering a qualifying breach of their personal information. That 45-day clock runs regardless of whether you have an ODPA-qualifying program in place. Having a great cybersecurity program buys you a potential litigation defense down the road. It buys you zero extra time on notification.

The statute specifies how you notify people, and the method scales with the size of the incident. Written notice, telephone notice, or electronic notice (when the recipient has agreed to it) typically satisfies the requirement for smaller incidents. When a breach affects more than 1,000 Ohio residents, you also have to notify every consumer reporting agency that compiles files on a nationwide basis, in addition to notifying the affected individuals themselves.

There’s a built-in exception for law enforcement. If a law enforcement agency determines that notification would interfere with a criminal investigation, you can delay notification for the period that agency specifies, and the 45-day clock adjusts accordingly. That exception exists precisely for situations where premature disclosure could tip off an ongoing investigation or alert an attacker still inside your systems.

This is where a documented ODPA-style cybersecurity program actually pulls double duty. A business with clear asset inventories, logging, and incident-response procedures can typically determine breach scope faster and with more confidence than one that’s improvising in the middle of a crisis. Knowing exactly which systems store restricted information, having audit logs that show what was accessed and when, and having a pre-built incident-response plan all shrink the gap between “we think something happened” and “here’s exactly what happened and who was affected.” That accuracy matters, because getting the notification wrong (either underreporting the scope or notifying too broadly) creates its own legal and reputational headaches. A breach-response plan built ahead of time gives you a running start when the 45-day clock is already ticking.

Building an ODPA-Ready Cybersecurity Program: A Practical Checklist

Turning statutory language into an actual program comes down to five phases: build the core controls, map them to your chosen framework, keep the program running, document everything, and review it on a set schedule.

  1. Build the core components. Start with written policies covering acceptable use, data handling, and incident response. Add a current asset inventory (you can’t protect what you don’t know you have), a documented risk assessment, access controls with multi-factor authentication on anything sensitive, encryption for data at rest and in transit, centralized logging, a vendor-management process for third parties touching your data, employee training, and a tested backup strategy.
  2. Map each control to your framework. Every policy and control needs a clear line back to the specific framework requirement it satisfies. If you’ve adopted CIS Controls, your MFA policy should reference the specific CIS Safeguard it fulfills, not just exist as a standalone IT rule.
  3. Keep dated evidence for everything. Policy version history, review notes, audit logs, training completion records: all of it needs a date stamp. A policy that exists but can’t be dated is nearly worthless as courtroom evidence.
  4. Operationalize ongoing maintenance. Set a patching cadence, run regular vulnerability scans, schedule periodic penetration testing appropriate to your size, and run tabletop exercises so your team has actually practiced the incident-response plan before a real breach forces the issue.
  5. Preserve records for litigation readiness. Retain every policy version, not just the current one. Keep audit trails, remediation tickets showing you fixed identified issues, and records of board or leadership approval for major security decisions.

Academic guidance on this statute converges on one point: the mapping document connecting your internal policies to your chosen framework, complete with adoption dates, enforcement evidence, and remediation records, is the single most important artifact you can hand to counsel if litigation ever arises. That mapping is what turns “we have a security program” into “we have a program that reasonably conforms to NIST CSF, and here’s the paper trail proving it since 2024.”

Review your program at least annually, and update it within one year of any revision to your chosen framework. Miss that window and your defense weakens right when you need it most.

Pro Tip: Keep a single running document, not scattered files, that maps every control to its framework citation and its adoption date. When your attorney needs to build a defense six months after a breach, that one document saves days of digging through old email threads and shared drives.

If your team doesn’t have the bandwidth to maintain this cadence internally, a documented cybersecurity plan built with outside support beats an ad hoc one built in-house and forgotten after the first quarter.

How Will Courts Evaluate “Reasonable Conformance” in Practice?

Reasonableness under the ODPA is fact-specific, not a fixed checklist a judge runs through mechanically. A court weighing whether your program “reasonably conforms” to a framework will look at your size, your resources, the sensitivity of the data you handle, and whether your security decisions were proportionate to those factors. A ten-person law office and a regional bank will be held to different practical standards even under the identical framework.

What tips the scale in your favor is contemporaneous documentation, meaning records created at the time decisions were made, not reconstructed after a lawsuit lands. A mapping document dated and updated over the two years before a breach carries far more weight than a polished compliance binder assembled the week after your attorney got the complaint. Judges and opposing counsel can tell the difference, and so can forensic experts hired to poke holes in your defense.

Third-party attestations or certifications, such as a SOC 2 report or an ISO 27001 certification, strengthen your position but don’t guarantee anything. One white paper analysis of the statute makes clear that no provision in the statute promises an automatic defense. A certification tells the court a third party reviewed your controls at a point in time. It doesn’t substitute for your own documentation showing ongoing compliance between audits.

There’s also a jurisdictional wrinkle worth flagging for counsel. The defense applies to tort claims “under Ohio law or brought in Ohio courts,” language that raises real choice-of-law questions when a business operates across state lines or faces litigation in a different forum. If your Ohio-based company gets sued in another state’s court over a breach affecting residents nationwide, whether the ODPA defense even applies becomes its own preliminary legal fight.

Counsel preparing a defensive record should assemble, at minimum: the written cybersecurity policy in effect at the time of the breach, the framework-mapping document with adoption dates, evidence the controls were actually enforced (not just written down), records of any framework updates and your response timeline, and documentation of your risk-assessment process explaining why your program was scaled the way it was.

Where Ohio Businesses Should Focus Their Cybersecurity Efforts This Year

If you’re a small or mid-sized Ohio business trying to figure out where to start, skip the temptation to chase every control on the NIST list at once. Prioritize the handful of controls that deliver the most protection for the least budget strain: know what devices and data you actually have, require multi-factor authentication everywhere it’s technically possible, run automated backups you’ve actually tested, and keep logs that let you reconstruct what happened after an incident. Those four things stop more breaches, and support more defensible litigation postures, than almost anything else you could spend money on first.

Four cybersecurity priorities for small businesses

The bigger mistake I see in how businesses approach this statute is treating documentation as an afterthought, something you scramble to produce after a breach rather than something you build as you go. That’s backward. The paperwork isn’t separate from your security program. It’s part of the security program. Every policy update, every access review, every training session should get logged the moment it happens, not reconstructed from memory months later.

For businesses without a dedicated IT security team, and that’s most small businesses in Ohio, bringing in a managed partner isn’t an admission of weakness. It’s the pragmatic move. Building and maintaining a framework-mapped program with proper documentation takes ongoing attention most owners don’t have time for on top of running their actual business.

— Jeffrey

Get an ODPA-Ready Cybersecurity Program Without Building It Alone

Building a written cybersecurity program that maps cleanly to a framework like NIST CSF or CIS Controls, and keeping that documentation current year after year, is exactly the kind of ongoing work most Ohio businesses don’t have staff to sustain internally. An outsourced IT department can handle that work: policy development, framework mapping, dated evidence retention, and periodic conformance reviews, backed by 24/7 monitoring and a USA-based help desk that answers in under 12 minutes.

Mavericks Office Solutions

That local help desk matters more than it sounds like it should. When a security event happens at 2 a.m., you’re not waiting on an offshore call center to route your ticket. You’re talking to someone who already knows your systems. Beyond the reactive side, Mavericks builds the documentation trail your attorney would actually want to see: dated policy versions, framework-mapping records, incident-response plans that have been tested rather than just written. If you want to see what a managed cybersecurity program built for Ohio businesses looks like in practice, or explore broader managed IT support that covers the operational side of keeping your controls enforced day to day, reach out to Mavericks Office Solutions for a program review.

Primary Sources for the Ohio Data Protection Act

For the statutory text itself, start with ORC Chapter 1354, which lays out the full framework list and definitions, and Section 1354.02 for the affirmative-defense language specifically. Breach-notification obligations sit in ORC 1349.19. The Ohio Attorney General’s CyberOhio program offers practical framework guidance for businesses building a qualifying program. For deeper legal analysis, the University of Cincinnati Law Review and Akron Law Review both offer detailed treatments of the statute’s litigation mechanics.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

FAQ

What Are the Key Requirements Under the Ohio Data Protection Act?

A qualifying program needs administrative, technical, and physical safeguards that reasonably conform to a recognized framework like NIST CSF or CIS Controls, scaled to your business’s size, data sensitivity, and resources, per ORC 1354.02.

Ohio is a one-party consent state for call and conversation recording, meaning only one participant needs to agree to the recording; this rule falls under Ohio’s general privacy and wiretapping statutes, separate from the ODPA’s cybersecurity focus.

What New Data or Privacy Laws Should Ohio Businesses Watch in 2026?

Ohio still lacks a comprehensive consumer privacy statute, so the ODPA’s affirmative defense and the breach-notification rule under ORC 1349.19 remain the two core state-level obligations businesses need to track heading into this year.

What Counts as a Violation of Privacy in Ohio?

Ohio addresses privacy violations through several separate legal paths, including tort claims like invasion of privacy and statutory breach-notification failures, rather than a single unified privacy statute; the ODPA itself creates a defense to certain tort claims, not a new privacy violation standard.

Does the ODPA Replace HIPAA, GLBA, or PCI Compliance?

No. The ODPA is an optional affirmative defense that runs alongside sector-specific rules; regulated businesses still must meet HIPAA, GLBA, or PCI DSS obligations independently of any ODPA program they build.