HIPAA overhaul, AI Governance and How To Be A Secure Healthcare Company

People always ask me questions about what they need to do for HIPAA or how they should handle data. If you are asking me those questions, you’ve made a wrong turn at some fork in the road of your life.

So I decided to team up with Faisal Khan at Vanta to talk about some of the things they’re seeing trendwise in security land + ask them some questions people building products should know. We go through:

• Proposed changes to HIPAA
• What are enterprises asking about AI tools + governance
• Mistakes healthcare startups should watch out for when building
• And more.

This is a sponsored post. You can read more about my rules/thoughts on sponsored posts here. If you're interested in having a sponsored post done, we’re sold out this year but can chat for 2027.

A 5-person team just signed their first hospital pilot and needs to get HIPAA-compliant A$AP. Realistically what's the timeline and cost for getting there?

I’ll start by saying “it depends” and primarily because, regardless of team size, both time and cost are relative to the scope of the environment that needs to be protected, including how much knowledge, process, and tooling the team already has in place.

At a high level, and assuming no GRC platform, getting to a defensible compliance baseline could take 5-6 months or more. With a platform like Vanta, it's closer to 2-3 months. The reason it takes this long is that HIPAA doesn't prescribe specific controls, where organizations have to interpret the regulatory requirements and design their own controls to address them.

For example, take the audit-controls requirement (45 CFR §164.312(b)), which says to implement mechanisms that "record and examine activity" in systems containing ePHI. But it never says what to log, how long to keep it, or when something should trigger an alert versus just sit in a file. Two teams reading that same line can build very different setups and both be defensible: a typical interpretation lands on centralized logging of authentication and PHI-access events, retention ranging from several months to a year or more, automated alerts on anomalies like failed-login spikes, and someone actually reviewing the logs on a set cadence rather than just collecting them.

Cost is even more situational, since it depends entirely on where you are in your operations today. While I can't give specific numbers, a few cost areas to plan for include:

• Personnel or consulting resources to perform a HIPAA risk analysis, develop policies and procedures, and implement the necessary administrative, technical, and physical safeguards.
• System/tooling costs where you need to stand up a process you don't yet have a way to perform or enforce
• Third-party costs where depending on the services you rely on, you may need to pay a premium for HIPAA-managed tiers, and you'll need BAAs in place with any vendor that touches PHI. Those vendor premiums can add up depending on the tools you’re using.

HIPAA is getting a big overhaul now. What's actually changing in the new rule? Why is it important?

Disclaimer: The rule is still in the proposed state, so nothing here is final yet. That said, the main uplift we’re expecting is to the Security Rule, which is becoming more prescriptive about the safeguards expected of in-scope organizations and about how specific requirements are classified and approached. A few of the noteworthy proposed changes:

• No more "addressable" vs. "required." Nearly all implementation specifications become mandatory, removing the flexibility that produced uneven security across the industry.

• Encryption of all ePHI, both at rest and in transit, becomes mandatory.
• Mandatory multi-factor authentication for systems accessing ePHI (and for privilege changes), with limited exceptions such as legacy systems with a transition plan.
• Tighter business associate oversight where covered entities must obtain annual written verification that BAs have the required controls in place, and BAs must notify on activation of any contingency plans.
• A new mandatory compliance audit where regulated entities would have to audit their own compliance with the Security Rule at least once every 12 months.

The reason it is important is two-fold from my perspective:

First, It's the first major revision to the Security Rule in over a decade; the last significant update came with the 2013 Omnibus Rule

And second, It reflects the need to raise the regulation's bar relative to the threat landscape the industry now faces much like ISO 27001:2013 was modernized into ISO 27001:2022 after nearly a decade.

The EU AI Act classifies anything processing PHI as high-risk. Is something equivalent forming in the US?

The EU AI Act comes into scope because of what an AI system does and who/what it affects. The regulation classifies AI by risk level, from banned uses (like social scoring) up to "high-risk" systems touching things like hiring, credit, or healthcare, which carry the heaviest obligations. The majority of rules of the AI Act come into force and enforcement starts for applicable rules in August 2026.

Colorado went through a similar arc but landed somewhere lighter. The original 2024 law was built like a mini version of the EU's risk-based approach including duty of care, impact assessments, risk management programs for AI used in employment, housing, healthcare, and credit decisions. Industry pushback was strong enough that the legislature didn't just delay it, they repealed and rewrote it as SB 189.

Given the recent events in how Colorado Artificial Intelligence Act was repealed and reenacted by SB 189, it's possible that we’ll see more top level law start to form as opposed to individual US state law initiatives over AI.

Health tech founders get told they need HIPAA, then SOC 2, then HITRUST, then NIST, then ISO. What’s the catalyzing event for a company to finally get each?

It comes down to a company's obligations relative to what it does for its clients and as a business:

HIPAA comes into scope because of the processing, storage, or transmission of protected health information (PHI). If a business does any of that, HIPAA is non-negotiable and you're typically asked to sign a BAA contractually attesting that you're compliant.

From there you have industry frameworks and standards such as SOC 2, NIST frameworks such as NIST CSF, and management-system standards like ISO 27001, that help establish strong safeguards and a broader data-protection foundation.

The catalyzing event is usually customer or market demand for independent assurance where SOC 2 and ISO 27001 in particular can be third-party audited and are the ones prospects most often ask for to prove it.

This also applies to HITRUST as well, though the level of HITRUST that organizations pursue and address tends to be a broader maturity conversation where the framework provides excellent mechanisms to enhance security practices while also operationalizing and certifying HIPAA compliance more rigorously (especially once you get into the r2 assessments).

How are enterprise health systems actually vetting AI vendors on security today? What's in their questionnaires specifically for AI? How do you evaluate security for non-deterministic products?

Enterprise health systems are vetting AI vendors by adding an AI-specific review layer on top of standard vendor security diligence. AI-specific layer focuses on whether the product is safe, controllable, monitorable, and appropriate for the intended healthcare use case.

Some common AI-specific questionnaire areas include:

• AI use case and scope: What the AI does, whether it is clinical or administrative, whether it is patient-facing, or if it recommends, automates, or triggers decisions autonomously.
• PHI and data use: Whether prompts, outputs, files, feedback, or patient data are stored, retained, or used for training
• Model provenance and validation: What model is used, what data it was trained or validated on, whether performance was tested in healthcare settings, and whether model cards or validation reports are available.
• Human oversight: Whether humans review outputs or override decisions.

For non-deterministic AI products, health systems are evaluating whether the system is bounded, tested, monitored, and governable. This generally includes reviewing the approved use case, data security safeguards, AI threat models, output guardrails, audit logs, and incident response measures.

The default answer to “how do you use LLMs with PHI” is “sign a BAA with the foundation model provider.” What's the real answer?

I feel like it’s more complicated when you’re dealing with things like LLMs embedded in other applications you’re using + the surrounding stack you’re using around the foundation model.

Better framing is that you can use LLMs with PHI only when the entire workflow is designed for PHI, not only when the foundation model vendor signs a BAA.

That means confirming the BAA, the HIPAA-eligible services, the configuration requirements, every vendor and subprocessor in the data path, and the controls around prompts, outputs, and human review. It’s also a balance of being intentional about using PHI with specific AI systems and why you are using it - this roots the conversion in data governance and management practices needing to be much stronger for healthcare companies.

How many companies have internal governance policies around AI tools? What are the typical things they include?

We’ve done some surveys and found that only 36% have an AI policy in place, but 72% of organizations have conducted a formal AI risk assessment in the past 12 months (at the time of surveying).

Some characteristics we see in these AI policies

• AI Use Governance: Defines approved AI use cases, prohibited uses, shadow AI expectations, and when AI use requires review or approval.
• AI Risk Management: Requires AI risks to be identified, assessed, documented, treated, and monitored across the AI system lifecycle.
• Human Oversight: Defines where human review, approval, intervention, or accountability is required for AI-assisted decisions or outputs.
• Data Use in AI: Sets rules for using personal, confidential, customer, regulated, or sensitive data with AI systems.
• AI System Transparency and Documentation: Requires documentation of AI system purpose, ownership, intended use, limitations, assumptions, and decision logic where applicable.
• Responsible AI Requirements: Covers fairness, bias, explainability, ethical use, safety, misuse prevention, and impact on individuals or groups.

For startups reading this - what’s a common mistake they should avoid from the beginning that commonly causes big issues later?

Understand the scope of your environment involved in PHI related activities and be very intentional about what protections you put where.

For example, if you assume PHI is only in a production database but it also gets written into application logs or copied into a support tool, you may end up leaving major parts of your environment outside the HIPAA risk analysis, access controls, retention rules, monitoring, and vendor review process.

A good third-party vendor example would be Supabase because it shows how startups can accidentally scope HIPAA too narrowly.

A common mistake is assuming, “We use Supabase, and Supabase is HIPAA compliant, so we’re covered.” That is not enough as Supabase says organizations must have a signed BAA and the HIPAA add-on enabled before using Supabase to store or process PHI.

Thanks again to Faisal Khan for chatting with me about this, and you can talk to the Vanta team about this stuff/see a demo of what their product does here.

Thinkboi out,

Nikhil aka. “SOC 0 the way I’m not secure” aka. “Jack the Hipaa”

Twitter: @nikillinit

IG: @outofpockethealth

Other posts: outofpocket.health/posts