In effect since September 2025. It will not stop a lawsuit and it does nothing about what someone can recover for the harm itself. What it can block is the punishment award on top, and only if you can prove the program was already running.
Chapter 542 of the Business and Commerce Code took effect on September 1, 2025. In a lawsuit arising from a breach of system security, which the statute defines rather than leaves loose, a person harmed by it cannot recover exemplary damages from a covered business. That is on condition the business demonstrates it had implemented and maintained a complying program at the time of the breach.
Exemplary damages are the ones awarded as a penalty or punishment rather than to compensate anyone. Texas law says the term includes punitive damages.
Four things have to line up. You qualify, the program complies, it was running at the time of the breach, and you are the one who has to prove it.
It is not immunity and it does not stop a lawsuit. Only exemplary damages are barred. It does not bar what someone recovers for the harm itself, economic or otherwise. The statute says outright that it creates no cause of action and changes no duty you already had.
There is no express protection in it from a regulator, so do not count on it for that. And it reaches only a cause of action that accrues on or after that September date. The statute does not say when a cause of action accrues, which is one to put to your attorney rather than assume.
The test has three parts. A business entity in this state, fewer than 250 employees, and it owns or licenses computerized data that includes sensitive personal information.
That last term is defined in statute, and the definition is fussy in ways that matter. In outline, one branch is a person's first name or initial plus last name, together with a Social Security number, a driver's license or other government-issued ID number, or an account or card number along with the security code, access code or password that would open that financial account.
That branch applies only where the name and the items are not encrypted. The other branch is information that identifies a person and relates to their physical or mental health or condition, to health care provided to them, or to payment for that care.
One more carve-out worth knowing before you assume the worst about what you hold: the statute does not count information as sensitive if it is publicly available and lawfully made available to the public from a federal, state or local government. The exclusion applies only when the information was lawfully made available to the public by that government. Government possession by itself is not enough.
Encryption is doing real work in that first branch. Whether you are covered at all can turn on it.
We can tell you exactly what you hold and where it sits. Whether it meets the statutory definition is a question for your attorney, and it is worth asking rather than assuming either way.
Four requirements, and the statute applies them to the program as a whole.
Administrative, technical and physical. Note that they have to protect personal identifying information as well as the sensitive kind, which is a wider net than the one that decides whether you qualify.
Current versions from the statute's list, singly or in combination, and the list closes with an open category for other similar industry standards.
Protect the security of that information, protect against any threat or hazard to its integrity, and protect against unauthorized access to it or acquisition of it that would result in a material risk of identity theft or other fraud.
How much is expected of the program moves with headcount, in three bands.
Fewer than 20 employees gets simplified requirements, and the statute names password policies and appropriate employee cybersecurity training among them. Twenty to 99 gets moderate requirements, naming the Center for Internet Security Controls Implementation Group 1 requirements among those. From 100 to 249, the statute calls for compliance with the framework subsection itself.
The trap is the word including. At the smaller sizes those named items are part of what the program contains, not the whole of it.
There is a wrinkle worth knowing about, but it is not the one it looks like. For a business this chapter already covers, the framework requirement appears separately in its own paragraph, with no additional headcount threshold. It therefore applies to every qualifying safe-harbor program, including one maintained by a shop of twelve. The statute refers to that same framework subsection again in the 100 to 249 employee band, which reads like a second, bigger-business-only requirement. It is not one; that repetition does not limit the separate requirement already stated. Framework conformance remains a condition for this safe harbor, not a general duty Chapter 542 creates. The statute says elsewhere that it does not create a private right to sue or change any duty you already had.
You can conform to current versions of the named standards, alone or combined: the NIST cybersecurity framework, NIST 800-171, 800-53 and 800-53a, FedRAMP, the CIS Critical Security Controls, the ISO 27000 series, HITRUST CSF, the Secure Controls Framework, SOC 2, or another similar industry standard. No product is named anywhere in it, so nobody can wave the statute at you and sell you something.
What is not a choice: if your business is subject to HIPAA, Gramm-Leach-Bliley, FISMA or HITECH, those current requirements form part of the same test. The same goes for PCI DSS where it applies to you. You do not get to pick something off the list instead of those.
In practice the useful question is not which framework is best. It is which one matches how you already work, because that is the one that will still be running in two years.
This part gets described wrongly a lot, so it is worth being exact. Your program continues to qualify only if you update it to meet the revised standard, and you have until the later of the implementation date published in that revision or the first anniversary of its publication. Nothing about it is automatic. Something has to actually be done.
That allowance attaches to the standards on the framework list. It does not, on the face of it, extend to the federal requirements or to PCI.
Implemented and maintained, at the time of the breach, demonstrated by you.
Buying a product, drafting a policy, or meaning to get to it does not establish any of that on its own. The moment being tested is the breach, not the day you found out and not the day you were sued.
The burden sits with the business claiming the protection, which is the whole argument for starting early. There is no way to go back afterwards and have maintained something.
Which systems hold what, where it goes, and who can reach it today.
The standard we picked, control by control, against what you actually run.
What is missing, what it takes to close, and what we would do first.
The actual work on the actual systems, not a report telling you to do it.
Named in the statute at the smallest size. We keep the attendance and the content, because you are the one who has to demonstrate it later.
What was in place and from when, because the statute puts the demonstrating on you.
We do the technical and administrative work, and we keep the record of it. What we will not do is tell you your program satisfies the statute, and you should be wary of anyone who does.
Whether you qualify, how the statute reads, when a cause of action accrued, and whether it holds up in front of a judge are legal questions. Those belong to your attorney, and we are glad to hand them a written account of what is actually in place.
An inventory of the data, the systems holding it and who can reach it, mapped against what the statute asks for, and a written gap list you can put in front of your attorney.
Start a Conversation