ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
CIS Controls safe harbor is the legal protection several US states give to organisations whose written cybersecurity programme reasonably conforms to a recognised framework, and the CIS Critical Security Controls are among the frameworks named. It does not stop a breach, and it does not stop regulators, but in the states that offer it, it can limit what a plaintiff recovers or give you a defence in a data breach lawsuit.
This guide explains what these statutes generally do, what they do not do, how the CIS Controls fit, and what evidence a court would expect you to hold. It is general information and not legal advice, so confirm the position in your own states with counsel. For the controls themselves, see our CIS Controls v8.1 guide.
Free gap assessment
Have you cleared Implementation Group 1?
Score all 18 Controls, free, with IG1 treated as the floor rather than the starting point, so you find out whether the basics are actually covered.
Run the free CIS Controls gap assessment → or View premium report sample
Safe harbor statutes reward organisations for investing in security before a breach. The details differ by state, but the pattern is the same: if your written cybersecurity programme reasonably conforms to a recognised framework, the statute gives you an affirmative defence or limits the damages a plaintiff can claim in a data breach tort case.
| State | Statute | Protection |
|---|---|---|
| Ohio | Ohio Data Protection Act, Rev. Code 1354.01 to 1354.05 | Affirmative defence to data breach tort claims |
| Utah | Cybersecurity Affirmative Defense Act, Code 78B-4-701 to 706 | Affirmative defence to data breach claims |
| Connecticut | Conn. Gen. Stat. 42-901 | Protection from punitive damages, not compensatory damages |
Other states have passed similar laws since, including Iowa and Texas according to recent summaries, with their own scope limits. Texas, for example, is described as applying to smaller businesses and protecting against exemplary damages. Lists change, so check a current source and the statute text for each state where you operate.
The statutes generally list several frameworks, and the CIS Critical Security Controls appear alongside NIST and ISO 27001 in the states summarised above. The frameworks are alternatives, so you do not need all of them. You need one, applied to your size and risk, and documented. Many small and mid-sized organisations pick the CIS Controls because they are prescriptive, ranked by implementation group and free to use. Our CIS Controls vs NIST CSF comparison and CIS Controls to ISO 27001 mapping help you choose, or combine, frameworks.
Ohio, Utah and Connecticut each ask for a programme that suits the organisation, weighing factors such as its size and complexity, the nature and sensitivity of the data, and the cost and availability of tools. That maps well to the CIS implementation groups. A small business with limited data can reasonably aim at Implementation Group 1, while an organisation holding sensitive data at scale should be looking at Groups 2 or 3. Record why you picked your group, since the scaling argument is the heart of the defence. Our CIS Controls implementation plan lays out the IG1 route.
A defence is only as good as the records behind it. If a plaintiff sues after a breach, you will need to show a written programme, a chosen framework, a mapping from the programme to the framework, and proof the controls were in place at the time. That means keeping the following ready.
Several of these statutes expect the programme to keep pace with the framework it relies on, and some set a window for updating after a revision. The CIS Controls have been revised over the years, and you should confirm which version your programme cites and when you last reviewed it. Add a standing review to your calendar: once a year, and whenever the framework, your systems, your data or the law changes materially. Record what you changed and why. An out-of-date mapping to a superseded version is a weak exhibit, whereas a dated review log shows the programme is alive.
A safe harbor argument needs a named owner. Usually that is the CISO, head of IT or an outsourced security lead, reporting to an executive sponsor who approves the programme and its budget. Legal or compliance tracks the state statutes, and the board or owners receive a short annual summary of framework status, open gaps and incidents. Where you rely on managed service providers for security operations, make sure their contracts require them to support the safeguards you have committed to and to give you the evidence, otherwise your written programme describes controls you cannot prove.
Insurers ask many of the same questions as a court would, and a documented CIS Controls programme helps with both. Keep in mind that CIS Controls safe harbor is one layer. Insurance covers direct losses, incident response plans handle the crisis, and contracts with customers may impose their own security terms. Treat the safe harbor as one reason among several to keep the programme evidenced, not as the sole justification.
A regional retailer with 120 employees stores customer payment and contact data. It adopts the CIS Controls at Implementation Group 1 with selected Group 2 safeguards for its payment systems, documents why, and assesses itself twice a year. After a phishing incident exposes a mailbox, a customer sues in a state with a safe harbor statute. The retailer produces its programme, the framework memo, the latest assessment and the evidence of multi-factor authentication and staff training. Whether the statute protects it will depend on the state, the facts and the court, but the retailer is in a far stronger position than one with no written programme. The example is illustrative only and does not predict any outcome.
The choice of implementation group is where your reasoning is most visible. Implementation Group 1 is aimed at organisations with limited IT resources and moderate data sensitivity. Group 2 adds safeguards for organisations with more complex environments and more sensitive data. Group 3 suits organisations that face sophisticated attackers and hold data whose loss would be severe. Match the group to your facts: headcount, systems, data types, regulatory exposure and past incidents. Write one page that sets out the facts and the conclusion, have management approve it and revisit it when the facts change. If a court is deciding whether your programme was reasonable for an organisation of your kind, that page is the best evidence you can offer.
Organisations trip over the same points. They claim to follow the CIS Controls but have no assessment. They adopt the framework on paper and let controls lapse. They assume one state’s law covers operations in others. They copy the framework text into a policy and never assign owners. Or they treat the safe harbor as a substitute for insurance and incident response. The remedy is a live programme, reviewed at least yearly, with an accountable executive and a clear record of what was done.
The documents involved are consistent and repeatable: a programme charter, a framework decision memo, safeguard assessment sheets, policies by control, an evidence register and a gap tracker. The CIS Controls Toolkit provides templates for these, which you can adapt to your environment. For a state-by-state summary to discuss with counsel, see this overview of cybersecurity safe harbor laws, then read the statute text itself.
No. Safe harbor statutes exist only in some states, each has conditions, and courts decide whether your programme reasonably conformed to the framework.
Ohio, Utah and Connecticut were early adopters, and other states have added laws since, so check a current list and the statute for each state you operate in.
Not necessarily. The statutes scale expectations to size, complexity and data sensitivity, so document why your chosen group is reasonable.
No. The statutes address private civil claims and do not shield you from regulators or from your own direct losses.
September 30, 2026
