2026 HIPAA Security Rule Update
medcurity.com
medcurity.com
As a government regime, do you want to build an effective surveillance system where health data on large numbers of suspects can be pulled into a data fusion system at the push of a button, once a judicial framework for rubber-stamping is in place? And do you want to be able to pressure vendors into not supporting certain types of research/analysis and even direct patient care that could be construed/presented as counter to the regime's goals?
Both of these are easier when smaller vendors are forced out and larger vendors are the only ones left standing. As such, regulatory capture becomes a mutually beneficial tool to dominant vendors and regulators alike.
There are few coincidences when lobbying is involved. Which is not to say that cybersecurity improvements aren't a good thing! But speed and mechanisms of required rollout need to be balanced. And with the numerous signatories of [0] opposing the rule and describing "unreasonable implementation timelines," it's hard to say that this is entirely done in the interest of patients.
[0] https://assets.ctfassets.net/opszt4tga0mx/4QrJlGP2EkCiZjgvGx... (2025)
> As a government regime, do you want to build an effective surveillance system where health data on large numbers of suspects can be pulled into a data fusion system at the push of a button, once a judicial framework for rubber-stamping is in place?
Sure, and I'm right there with you that people should protest frameworks for judicial rubber-stamping. But HIPAA is like the only privacy law in America, basically, and having it mandate that medical data is encrypted can be good on its own.
While there are standardized formats for medical data, many are so ill-adopted that building some sort of surveillance system would be a monumental task; the bulk of data I've worked with has been in poorly documented, non-standard formats.
> Both of these are easier when smaller vendors are forced out and larger vendors are the only ones left standing
Clearer regulations and standardized, interoperable data formats benefit smaller players.
1. Do good security and operations.
2. Overlap the minimum subset of your existing good security and operations as evidence for whatever compliance regimes help you get paid.
3. Get paid.
Nobody is suggesting that you bullshit the auditors. They’re suggesting not letting the auditors accidentally trick you into letting step 2 get in front of step 1.
They also asked for proof of system-enforced processes (e.g. GitHub branch protection rules and the setting for enforcing peer review for each change) which were basically proof of consistency.
That's what we're talking about when we say virtually any tool you can come up with will satisfy "vulnerability scans". For Cloudflare, it was nmap. I think they're right about this.
1. You write a DRL that says “we do a disaster recovery test annually to ensure that we can restore a production backup”.
2. It takes you 20 tries in 2026 to do a successful restore because your find out the first 19 times that your backup is broken and incomplete.
3. You never have to mention the first 19 tries to the auditors when you prove you did do a successful DR restore.
But the far more likely thing is that a medium SOC auditor, upon being told “we do our vulnerability scanning with nmap”, would say “I haven’t heard of nmap. You should use Tenable,” and if you’re letting SOC auditor drive your engineering you’d make a mistake and accidentally think that meant you needed to change your answer for SOC2 and go buy Tenable licenses.
My experience is that no, SOC2 auditors won’t consider literally any automated process of that sort as compliant. Which in no way implies the auditors are forcing you to use a licensed tool or driving your engineering.
I will stop that thread here, I don’t think that exchange is productive
Indian companies open up shell businesses in Wyoming and elsewhere, get "certified", and offer rubber stamp auditing services. Few ever check if you actually have SOC2, or what auditor you used (since, by definition, they need to be "legit").
By the way, the AICPA website was recently throwing https expired cert errors. Their solution after weeks of me pointing it out on twitter, was to take down the entire website.
Maybe there's some kind of third party certification system to support signing information sharing agreements ("BAAs") with other health information systems. I worked at CMS on first-party stuff so I'm not really familiar with how it works in the private sector.
Compliance and security are entirely different practices in a well-run firm. Security can inform compliance. Compliance should not inform security engineering.
If you search my name and "SOC2" in the search bar below, I've expanded on this quite a bit.
This is ignorance at best. No one who has ever actually had to do SOC2 compliance legitimately has just run nmap and been done with that.
To satisfy the audit they looked at an app that was installed on a laptop that was not part of our base image from the previous 6 months and a screenshot of the message where the user “asked” to install it.
You can literally get a soc auditor to write up whatever you want as a control and if they don’t explain that and encourage it you should find a new auditor.
I can see that my experience was in putting actual effort into things.
We could have codified some more complicated approval process for apps on laptops. That could involve tickets and strenuous review and making everyone spend tremendous resources trying to keep an endpoint secured that way.
But we didn’t believe that was the right way to do it. Instead we assumed no matter what we did laptops were going to get owned up. So we focused on blast radius, detection, forensics and time to remediation. We’d need all those things even if we believed in a pre approval process.
But we didn’t document most of those things in audit scoped controls, because that would have ossified them. If we wanted to improve our detection regime we didn’t want audit ceremony to get in the way.
I’m comfortable with those decisions and would make them again. We worked very hard to make sure our endpoint security was as good as we could make it.
A specialist accountant certainly would not have improved the process.
So no, I don’t think the solution we came up with was not putting effort into the problem, it was thinking very hard about it and not letting a checkbox audit cause us to make bad decisions.
Cloudflare continues to prove it's a shit service, too.
while i find tptacek's opinions very strong on the subject, you would be extremely mistaken to think those opinions were formed without experience
PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks. The notion that your system might become "in-scope" is one of the scariest things you have to deal with. Avoiding this designation is almost always easier than satisfying all the controls they prescribe. Stripe & friends have it really good. I don't know who their equivalents are in the health care industry but I am certain they exist.
My personally most hated compliance ruleset. I've been in Healthcare for over a decade, I'm a HIPAA/data security expert, and PCI compliance is genuinely harder and more nonsensical than HIPAA.
And to be honest, for every ONE healthcare place I've seen that would fail a HIPAA audit, I've seen 20 companies that would fail PCI compliance and by a wider margin. The number one PCI issue I've seen *literally* everywhere is recording/writing down card numbers with CVV. It's strictly forbidden by the rules, and every snall and medium business breaks that rule constantly.
Online payments (e.g. e-commerce) usually send such data directly to the PSP, or encrypt it with a PSP controlled key.
And in person payments (e.g. stores and restaurants) use a payment terminal/device, which is presumably PCI DSS compliant and doesn't store such information.
Basically, Visa and friends externalized their own shitty security and made every other company in the land responsible for wrapping their janky hardware in electronic bubble wrap. A real security framework would’ve said “don’t make a credit card scanner so weak that it can’t survive being on the same LAN as a printer”. Instead, the whole country has to waste billions of dollars mitigating that risk for them.
Given that downgrade attacks are a massive category of attacks for network protocols, and in fact modern protocols go to great lengths to make them impossible, that doesn’t sound very bullshit at all.
But in reality, why’s that a problem? Is the credit card scanner so tacitly busted that it can’t coexist with other hosts? Does it not use TLS? Doesn’t it pin TLS certs so that it’s not subject to MITM? Is it listening on ports with vulnerable services? There’s no excuse for the scanner being that delicate. It should be able to service an office LAN. And yet, the PCI-DSS group managed to push the responsibility for their hardware onto the network owners rather than making their own hardware robust. That’s nuts.
Context is everything. Here, the context is that within this scan environment, it was, in fact, a bullshit finding.
And yes, there is plenty of incentive to keep things out of PCI scope. I'd say that is PCI working as intended. Why would you want a larger attack surface that touches your credit card data?
You lose all your customer's data to a darknet leak? We should be taking a huge chunk out of your balance sheet.
My insurer has disclosed names, social security numbers, and ENTIRE MEDICAL CASEFILES for their entire client base more than once at this point in overlapping data breaches. Why exactly don't they owe me $10k for my trouble, or N% shares of the company? If that's too much, why do these penalties exist for knowing disclosure, if incompetence is so tolerated that knowing disclosure does no damage?
[0] https://www.ama-assn.org/practice-management/hipaa/hipaa-vio...
You're describing willful leaks by an employee, I'm condemning insufficiently competent / insufficiently conservative data security. A data security breach should incur significant penalties to the corporate entity, and those penalties should be multiplied by the number of records compromised.
These penalties should be high enough to minimize the number of records actually retained outside of cold storage, among other things.
When Equifax's breach leaks their entire database, massive social losses are occurring. We should have collectively seized that company from its shareholders for spying on us and leaking all our shit, not settled for "a year of free credit monitoring".
So when I get a letter telling me that an old insurer has had all of their patient data, names, DOB, SSN, health conditions, leaked to the darknet... and then I look it up and see it's the second time in a couple years? This is data that is in theory heavily protected. I'm out for blood.
I completely agree that the offers of credit monitoring are completely insufficient. Mixing that with feelings about the credit system muddles things a bit but I'm no fan of the incompetence of that system either even though there is some social good in the underlying provision.
I'm not telling you not to be angry. You have every right to be. I would suggest noting that at some level you can end up maximizing the damage it does to you.
To tie back into the original discussion on HIPAA, I had a collection agency sending mail addressed to a previous resident to my address once. The return address was the clinic of the patient. I was dutifully writing RTS on every letter and putting it back in the mail, but they would not take me off their nastygram list. That was until I wrote "You know, it's a felony HIPAA violation to be leaking this patient's name and clinic to me after you've been notified of the incorrect address." The collection letters immediately stopped after I did that.
[1] - https://www.amazon.com/Three-Felonies-Day-Target-Innocent/dp...
Still, I was hoping for examples.
The problem is that without having some kind of enforcement, businesses will decide that it is cheaper to not worry at all about security and thus their customers will have their data leaked/shared etc.
There's a world of difference between a company that puts effort into security and one that doesn't.
A cryptocurrency business or a diamond business, by contrast, has very strict security protocols, because if they don't, all the value gets wiped out very quickly. The rules basically absolve the healthcare company of fiscal responsibility.
This update OP is posting about may require jumping through certain hoops, but it does not require functionality of those measures.
AI writing makes somewhat more sense on tech blogs. Where a business' value proposition is "We are knowledgeable and reliable about computer security", it seems unwise.
It's getting absurd with how many different compliance regimes a modern research university will have to follow simultaneously, if they do a broad set of defense, energy, basic sciences, and health research as well as having an attached medical school and teaching hospital.
rules for thee but not for me
This doesn’t get you much in terms of security. The IRIS system itself is an OLTP so it’s going to need to constantly pass around the encryption key and use it constantly, and if an attacker gets disk access they also will have access to the keys.
So this is a big waste of everyone’s time and money.