After a data breach, the lawsuit usually alleges that the company failed to implement reasonable security, and in a few US states a documented programme that conforms to a recognised framework is a statutory answer to that claim. Ohio, Utah and Iowa have enacted cybersecurity safe harbour laws that give organisations an affirmative defence in tort actions if they maintain a written cybersecurity programme that reasonably conforms to a listed framework such as the NIST Cybersecurity Framework, NIST SP 800-171, SP 800-53, FedRAMP, the CIS Critical Security Controls or the ISO/IEC 27000 family. This guide compares the three statutes as their official texts read, sets out what the programme must contain, when the defence fails, and how a CISO can build the evidence a court would need. It is for CISOs, general counsel, GRC leads and risk committees deciding whether a framework programme is worth the investment. Status: summarised from the Ohio Revised Code, the Utah enrolled bill and the Iowa Code as published by each legislature, checked 27 October 2026.
Key takeaways
- It is a defence, not an immunity. Each law gives an affirmative defence to certain tort claims; it does not stop regulators, contract claims or breach notification duties, and each law states that it creates no private cause of action.
- Utah's defence is the widest. Utah covers claims that you failed to implement reasonable controls, failed to respond appropriately to a breach and failed to notify appropriately; Ohio and Iowa cover the failure to implement reasonable controls.
- Conformance must be current. All three expect you to move to a revised framework, generally within one year of its publication, so a programme still built on an old version may not qualify.
- Iowa adds a loss test. Iowa requires an annual evaluation of the maximum probable loss from a breach, and treats the programme's scale as appropriate if its operating cost is no less than that value.
- Utah removes the defence for ignored warnings. If you had actual notice of a threat, did not act on known remedial efforts within a reasonable time, and the threat caused the breach, Utah's defence is unavailable.
Scope: who and what is covered
These laws apply to private civil litigation in the enacting state's courts or under its law. They do not depend on where your company is based: Ohio and Iowa expressly cover systems "in or outside" the state. For the wider map of state duties see the US State Cybersecurity Laws Map.
| Feature | Ohio (R.C. Chapter 1354) | Utah (Code 78B-4-701 to 705) | Iowa (Code Chapter 554G) |
|---|---|---|---|
| Enacted or in force | Sections 1354.02 to 1354.05 effective 2 November 2018 | H.B. 80 Data Security Amendments, effective 5 May 2021 | 2023 Acts, chapter 63 |
| Who can use it | Covered entity: a business handling personal or restricted information through systems in or outside Ohio | A "person" that maintains a qualifying programme | Covered entity: a business that accesses, receives, stores, maintains, communicates or processes personal or restricted information, in or outside Iowa |
| Data protected | Personal information as defined in R.C. 1349.19; optionally restricted information (linked or linkable data not encrypted) | Personal information as defined in Utah Code 13-44-102 | Personal information (relating to an identifiable individual) and restricted information |
| Claims covered | Tort actions alleging failure to implement reasonable controls resulted in a breach | Claims of failure to implement reasonable controls, to respond appropriately to a breach, or to notify appropriately | Any cause of action sounding in tort alleging failure to implement reasonable controls resulted in a breach |
| Private right of action | None created (1354.04) | None created (78B-4-704) | None created (554G.4) |
| Distinctive feature | Earliest of the three; defence can extend to restricted information if the programme covers it | Defence lost on ignored actual notice; contract choice of Utah law carries the defence (78B-4-705) | Annual maximum probable loss evaluation and cost test |
Other states are often named in commentary on safe harbour laws, including Connecticut. This guide covers only the statutes whose official text could be read on 27 October 2026; check any other state's law directly before relying on it.
Key obligations
The written programme
All three laws require a written cybersecurity programme with administrative, technical and physical safeguards (Iowa adds operational safeguards) that is designed for protective purposes and scaled to the organisation.
| Requirement | Ohio | Utah | Iowa |
|---|---|---|---|
| Design purposes | Protect security and confidentiality, protect against anticipated threats or hazards, protect against unauthorised access likely to result in identity theft or fraud | Protect security, confidentiality and integrity; protect against anticipated threats; protect against a breach of system security (702(4)(a)) | Continually evaluate and mitigate anticipated threats; at least annually evaluate maximum probable loss; communicate risk and protective actions to affected parties after a known breach (554G.2(2)) |
| Scale factors | Size, nature of activities, sensitivity of information, cost and availability of tools, resources | Size and complexity, nature and scope of activities, sensitivity, cost and availability of tools, resources (702(4)(c)) | Appropriate if programme operating cost is no less than the most recently calculated maximum probable loss (554G.2(3)) |
| Framework conformance | Reasonably conform to an industry recognised framework (1354.03) | Reasonably conform to a recognised framework (703) | Reasonably conform to an industry recognised framework (554G.3) |
Recognised frameworks and regulations
| Basis | Ohio | Utah | Iowa |
|---|---|---|---|
| NIST Cybersecurity Framework | Yes | Not in the 703(1)(b)(ii) list | Yes |
| NIST SP 800-171 | Yes | Yes | Yes |
| NIST SP 800-53 and 800-53A | Yes | Yes | Yes |
| FedRAMP security assessment framework | Yes | Yes | Yes |
| CIS Critical Security Controls | Yes | Yes | Yes |
| ISO/IEC 27000 family | Yes | Yes | Yes |
| Sector regulation route | HIPAA, GLBA Title V, FISMA, HITECH | HIPAA Security Rule, GLBA Title V, FISMA 2014, HITECH, Utah Protection of Personal Information Act, other applicable regulations | HIPAA, GLBA Title V, FISMA 2014, HITECH, Iowa chapter 507F, certain critical infrastructure rules |
| PCI DSS | Only combined with another listed framework | For information PCI DSS protects | Only combined with another listed framework |
| Other route | None | A "reasonable security program" meeting 78B-4-703(2) | None |
| Revised framework deadline | Generally one year after the revision | No later than one year after the revision is published; reasonable time for amended regulations | As the framework states, no later than one year after publication |
Practically, NIST CSF 2.0 (February 2024) is a revision for Ohio and Iowa purposes, and PCI DSS v4.0.1 and ISO/IEC 27001:2022 are revisions to plan against. For framework detail see the CIS Controls Guide and the ISO 27001 Certification Guide.
Timeline and current status
| Date | Event |
|---|---|
| 2 November 2018 | Ohio Revised Code sections 1354.02 to 1354.05 take effect |
| 5 April 2019 | Current version of Ohio definitions section 1354.01 effective |
| 11 March 2021 | Utah H.B. 80 signed by the Governor |
| 5 May 2021 | Utah H.B. 80 takes effect |
| 2023 | Iowa enacts chapter 554G (2023 Acts, chapter 63) |
| 27 October 2026 | Status check for this guide: Ohio and Iowa text read from the current codes; Utah text read from the enrolled 2021 bill because the codified pages did not render |
Because the Utah reading is from the enrolled bill, confirm with counsel that no later amendment has changed sections 78B-4-701 to 705. State legislatures continue to propose similar bills, so revisit this list annually.
Enforcement and penalties
These laws impose no penalties of their own: they are optional defences. The value lies in the litigation they affect and the conditions that remove the defence.
- Where the defence applies: tort claims, typically negligence, alleging that a failure to implement reasonable controls caused the breach. In Utah it also reaches claims about the breach response and notification.
- Where it does not: regulatory enforcement by attorneys general or sector regulators, contract and warranty claims, and statutory claims outside tort. Breach notification duties under each state's notification law continue to apply.
- Burden: an affirmative defence is raised and proved by the defendant, so the organisation must show the written programme existed, conformed to a framework at the relevant time and was followed.
- Losing the defence in Utah: under 78B-4-702(5), the defence is unavailable where the organisation had actual notice of a threat or hazard, did not act within a reasonable time to take known remedial efforts, and that threat caused the breach. A risk assessment carried out to improve security is not, by itself, actual notice.
- Choice of law in Utah: 78B-4-705 provides that where a contract chooses Utah law, this part applies in civil actions on the contract wherever they are filed, which some organisations consider in customer and supplier agreements.
What it means for AI agents and non-human identities
- Frameworks include machine identity controls: conforming to SP 800-53 or the CIS Controls means account management, credential management and least privilege for service accounts and API keys as well as people. A programme that ignores non-human identities may fail the "reasonably conforms" test where the breach came through one. See the Audit Readiness for AI Agents and NHIs.
- Known exposed secrets are "actual notice": a secret scanning alert, a vendor advisory about a leaked token or a penetration test finding of a hard-coded key is the kind of warning that, if left unremediated, could remove Utah's defence. Track and close those findings with dates.
- AI agents need to be inside the programme: agents acting with delegated credentials are part of the system the programme protects. Document their inventory, permissions and monitoring in the same programme so conformance covers them. See the Agent Identity and Access Guide.
- Iowa's loss model must include machine paths: maximum probable loss scenarios should include compromise of a highly privileged integration or CI/CD credential, which often has wider reach than any one user.
Compliance steps
- Decide whether the defence matters: identify where you hold residents' data from Ohio, Utah or Iowa and where you could be sued in those states, and agree with counsel whether to pursue the defence.
- Choose the framework or regulation route: pick one framework (or the sector regulation route, such as HIPAA or GLBA, where it fits all the data) and record the version in use.
- Write the programme: a board or senior management approved document stating purposes, scope (including restricted information for Ohio and Iowa), safeguards, roles and the framework mapping.
- Evidence conformance: run a gap assessment against the framework, track remediation, and keep dated assessment reports, ideally independent. Reasonable conformance is a factual question you will have to prove.
- Add the state specifics: for Iowa, a documented annual maximum probable loss evaluation and a comparison with programme operating cost; for Utah, breach response and notification procedures and a register of threat notices with remediation dates.
- Track revisions: diarise new framework versions and plan migration within a year of publication.
- Use it in contracts and insurance: reference the conforming programme in customer assurance and cyber insurance submissions. See the Cyber Insurance Guide.
- Preserve the record: keep historic versions of the programme, assessments and remediation logs, because litigation will ask what was true on the date of the breach.
Measuring it
- Framework currency: months since the chosen framework's latest revision was adopted; target under 12.
- Assessed conformance: percentage of framework controls or safeguards assessed as implemented, by assessment date.
- Notice to remediation time: median days from a high-severity threat notice or finding to closure.
- Programme coverage: percentage of systems holding personal information within the programme's documented scope, including non-human identities.
- Iowa loss test: ratio of programme operating cost to the latest maximum probable loss value.
Framework mapping for the programme itself
| Programme element | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| Understanding legal duties and defences | GV.OC-03 | PL-2 |
| Written programme and policy | GV.PO-01 | PM-1 |
| Risk and loss assessment | ID.RA-05 | RA-3 |
| Acting on threat notices | ID.RA-08 | SI-5 |
| Breach response and notification | RS.CO-02 | IR-6 |
Common failure patterns
- A programme on paper only: the policy cites NIST CSF but no assessment shows conformance, so the defence cannot be proved.
- Stale framework versions: still mapped to an older framework revision more than a year after the new one was published.
- Scope gaps: the programme covers corporate IT but not the SaaS platform or cloud workload where the breach happened.
- Ignored findings: a penetration test or vendor warning sat open for months before the breach, which in Utah can defeat the defence.
- Treating it as immunity: leadership assumes the safe harbour ends liability and underinvests in notification and regulatory readiness.
- No dated history: the programme was updated after the breach and earlier versions were overwritten.
Practitioner checklist
- Counsel has confirmed which state safe harbour laws matter for your data and litigation exposure.
- One framework or regulation route is chosen and its version recorded.
- The written programme states purposes, scope, safeguards, roles and framework mapping and is approved.
- A dated conformance assessment exists, with a remediation plan.
- Framework revisions are tracked and adopted within one year.
- Non-human identities, secrets and AI agents are inside the programme scope.
- For Iowa, the annual maximum probable loss evaluation is documented.
- For Utah, threat notices are logged with remediation dates, and response and notification procedures are documented.
- Historic versions of the programme and assessments are retained.
Standards and references
- Ohio Legislature: Ohio Revised Code Chapter 1354, Businesses Maintaining Recognized Cybersecurity Programs
- Utah State Legislature: H.B. 80 Data Security Amendments (2021), enrolled text
- Utah State Legislature: H.B. 80 bill status
- Iowa Legislature: Iowa Code Chapter 554G, Tort Liability, Cybersecurity Programs
- Iowa Legislature: Iowa Code section 554G.2, Affirmative defense, requirements
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
Related NHI Mgmt Group resources: US State Cybersecurity Laws Map · Massachusetts 201 CMR 17.00 Guide · CIS Controls Guide · Cyber Insurance Guide. This guide summarises the Ohio, Utah and Iowa cybersecurity safe harbour laws and is not legal advice.