Texas added 1,099 group-affiliated dental locations over three years, the largest absolute growth of any state. More than one in four dentists within ten years of graduation were DSO-affiliated in 2024. A group that started with four offices in Fort Worth now has locations in Oklahoma City, Denver, Nashville, and Tampa.
Somewhere in that expansion, someone asks the question that stalls the IT roadmap: does each state need its own security policy? It does not. The reason has less to do with state privacy statutes than most operators assume, and getting the reason right changes what you actually build.
State Privacy Laws Do Not Stack the Way You Think
The common framing is that every new state adds a privacy layer on top of HIPAA. For dental practices, that framing is mostly wrong.
Texas, Tennessee, and Florida each exempt HIPAA covered entities from their comprehensive privacy laws at the entity level, which means the law does not reach the practice at all. Florida's is narrower still. It reaches only controllers above $1 billion in global annual revenue that also sell online advertising at scale, operate a smart speaker, or run an app store, which describes no dental group anywhere.
Oklahoma just joined the club and changed nothing. SB 546, signed March 20, 2026 and effective January 1, 2027, gives the state its first comprehensive privacy law, and it carries the same entity-level HIPAA exemption. A DSO that spent 2026 planning for a new Oklahoma privacy regime spent 2026 planning for nothing.
Four of the five states add nothing to how you handle a patient chart. The divergence lives somewhere else:
Breach notification deadlines, which apply regardless of any privacy law exemption and run shorter than HIPAA's.
Texas's own medical records statute, which is stricter than HIPAA in ways that have nothing to do with the TDPSA.
Colorado, the one state in this footprint without an entity-level exemption.
Everything that is not protected health information: marketing lists, website trackers, prospective patient records, employee files.
That is a smaller problem than five policies. It is also a different problem, which is why multi-state groups keep building the wrong control set.
Where the Five States Actually Diverge
HIPAA gives you 60 days to notify patients of a breach. Colorado and Florida give you 30. Tennessee gives you 45, and asks nothing of its attorney general. Texas requires attorney general notice within 30 days once 250 Texas residents are affected, the lowest threshold in the group. Oklahoma's attorney general trigger is new, added by SB 626 and effective January 1, 2026, so guidance written before this year misses it.
One detail decides how much this matters. Notification duty follows the patient's state of residence, not the office's. A Fort Worth practice that treats commuters and retirees from across the Red River can trip Oklahoma's attorney general threshold without operating a single Oklahoma location. If your incident response plan sorts affected patients by clinic, it is sorting on the wrong field.
Set One Breach Clock at Thirty Days
Pick 30 days and apply it in every state. It is the shortest deadline in the footprint, it satisfies the other four by definition, and it removes the argument about which clock governs while an investigation is still running. The same logic applies in states Techvera serves outside this set, which we walked through for New York's SHIELD Act reporting rules.
Decide this before an incident, because multi-location counts take a long time to finalize. Absolute Dental Group, a dental group with more than 50 locations, discovered unauthorized access on February 26, 2025 and did not complete its investigation until July 28. Its initial report to HHS listed 501 individuals. The final count was 1,223,635. Affected patients spanned clinics in Nevada, California, and Texas, and the group later agreed to a proposed $3.3 million class action settlement. Five months to a defensible number is ordinary when records sit across dozens of sites and several acquired IT environments.
A 30-day clock only works if two things are already true. You need a patient-residency report you can run on day one, broken out by state rather than by location. And you need a network where an intrusion at one clinic does not force you to assume every clinic was reached, which is the practical case for network segmentation in multi-site groups.
Train to the Texas Standard Everywhere
Texas HB 300, codified at Health and Safety Code chapter 181, requires covered entities to train employees within 90 days of hire, collect a signed statement verifying completion, and retain that statement for six years. HIPAA requires training but sets no deadline for new hires.
Texas also defines covered entity far more broadly than HIPAA does, reaching any person who assembles, collects, analyzes, uses, evaluates, stores, or transmits protected health information, or who simply comes into possession of it. Penalties run to $5,000 per negligent violation, $25,000 for a knowing violation, $250,000 where protected health information is used for financial gain, and up to $1.5 million annually for a pattern or practice. We covered the full delta in Texas HB300 vs. HIPAA: Where Texas Goes Further.
Adopting the 90-day clock in all five states costs you a calendar rule in your HR system. Running two onboarding tracks, one for Texas and one for everyone else, costs more to configure than it saves in training seats, and it breaks the first time a hygienist transfers from Tulsa to Plano.
Treat the Marketing Stack as a Separate Data Domain
Colorado is the exception in this group. The Colorado Privacy Act exempts protected health information but not the entity holding it. The chart is carved out. The practice is not.
Everything else you hold about a person stays in scope: website analytics, advertising pixels, prospective patient inquiry forms, review request lists, and the clinical photography sitting in a marketing folder rather than the EHR. Colorado requires affirmative opt-in consent before processing sensitive data, a category that includes data revealing physical or mental health conditions, and controllers have had to honor universal opt-out signals since July 1, 2024.
The law applies at 100,000 Colorado residents in a calendar year, or 25,000 if you derive revenue from selling personal data. A single Denver office will not reach that. A forty-location operator across the Mountain West will, and the marketing database grows faster than the patient roster because it includes everyone who never booked. The same question applies to the AI tools now writing into that stack, which we sized up in Is AI Charting and Imaging Actually Paying for Itself?.
Keep the marketing stack in its own data domain, with its own consent record and its own retention rule, separate from the EHR. At five locations that is a configuration decision. At forty it is a migration.
Write the Program Down Against One Named Framework
Tennessee gives controllers an affirmative defense against TIPA claims if they maintain a written privacy program that reasonably conforms to the NIST Privacy Framework. No other state in this footprint offers that trade.
Take it. Pick NIST, document the program once, and apply it in all five states. The defense operates only in Tennessee, but the document is the asset everywhere. A dated, version-controlled policy set is the first thing the Office for Civil Rights asks for in an investigation, and the thing most multi-location groups cannot produce, because each acquired practice arrived with its own binder and its own idea of what a policy is.
Build Against the Proposed HIPAA Security Rule Anyway
The Office for Civil Rights published a notice of proposed rulemaking on January 6, 2025 that would rewrite the Security Rule. The proposal drops the addressable and required distinction and mandates an annually updated technology asset inventory and network map, multi-factor authentication, encryption of electronic protected health information at rest and in transit, vulnerability scanning every six months, annual penetration testing, network segmentation, and restoration of critical systems within 72 hours.
Then it slipped. Final action was originally targeted for May 2026. The regulatory agenda now projects July 2027 and has reclassified the rulemaking as a long-term action. Expect the final rule to be narrower than the proposal.
Treat that as runway, not as a reprieve. The proposal gives covered entities 180 days after the rule takes effect to reach full compliance. Six months is workable for one practice. It is not workable for a DSO deploying multi-factor authentication across five states, multiple EHR tenants, and a set of practices acquired with whatever infrastructure they happened to have. The asset inventory is the harder half, because a group that has absorbed eight practices in three years usually cannot say with confidence how many endpoints it owns. Our breakdown of the 18 technical safeguards in the current Security Rule is the right baseline to build from.
Build to the proposal across 2026 and finalization becomes a documentation exercise. Read the delay as permission to wait and you will do the same work in 2027, with less time and more locations.
The One Thing You Should Not Standardize
Record retention. Dental record retention periods are set by state law and state dental board rules, and they do not line up. Keep that rule per state, and enforce it in the EHR's retention configuration rather than in a policy document nobody opens after onboarding. Standardizing on the longest period in your footprint looks tidy and quietly creates discovery exposure you did not have to carry.
What to Do Before the Next Location Opens
Run a patient-residency report by state. That is your regulatory footprint, and it is almost always wider than your location map.
Set one incident response clock at 30 days, with a state notification matrix keyed to residency rather than clinic.
Move new-hire privacy training to a 90-day service level with signed attestations retained six years, in every state.
Inventory the marketing stack separately from the EHR, including pixels, forms, review platforms, and photo storage.
Pick one framework, write the program down, and put it under version control.
Start the asset inventory and multi-factor rollout now, on the assumption the Security Rule finalizes in 2027 with a six-month compliance window.
Techvera builds and maintains single-standard security programs for multi-location healthcare groups across Dallas-Fort Worth and New York City. Our Compliance Readiness team starts with a free gap assessment that maps your current controls against HIPAA, the proposed Security Rule, and the requirements in every state where you actually treat patients. Schedule your gap assessment.
This article is general information about IT and security policy design, not legal advice. Confirm state-specific obligations with counsel before adopting a policy.
Frequently Asked Questions about DSO Compliance
Do state privacy laws apply to dental practices that already comply with HIPAA?
Usually not, though it depends on the state. Texas, Tennessee, and Florida exempt HIPAA covered entities from their comprehensive privacy laws at the entity level, so a dental practice sits outside those laws entirely. Colorado exempts protected health information but not the entity that holds it, so a dental group that meets Colorado's thresholds must comply for any personal data that is not protected health information, including marketing and website data. Oklahoma's first comprehensive privacy law, SB 546, takes effect January 1, 2027 and carries an entity-level HIPAA exemption as well. State breach notification laws apply in all five states regardless of any of these exemptions.
What is the shortest breach notification deadline a multi-state DSO has to meet?
Thirty days, in both Colorado and Florida. HIPAA allows 60 days, Tennessee allows 45, and Oklahoma requires notice without unreasonable delay. Texas requires attorney general notice within 30 days once 250 Texas residents are affected. A DSO operating in several states should set a single 30-day internal deadline, because notification obligations follow each patient's state of residence rather than the location that treated them.
Does a DSO need a separate IT security policy for each state?
No. One policy written to the strictest requirement in the footprint satisfies every state, and it is far easier to audit than a base policy carrying per-location exceptions. The exception is record retention, which is set by state law and state dental board rules and should stay configured per state in the EHR.
About the Author
Team Techvera
Techvera Team
Articles written collaboratively by the Techvera team, combining expertise across cybersecurity, managed services, and digital transformation.