A practitioner's perspective on SOC 2, HITRUST, HIPAA, enterprise security reviews, and building durable security programs at healthcare startups.
Nobody starts a company because they're excited about audits. You start a company because you're building something you believe in. Then one day, growth arrives — and it comes holding a 300-question security questionnaire.
Read any GRC job description. You'll see the frameworks: HITRUST, SOC 2, ISO 27001. You'll see "risk management," "policy development," "audit support." You know what you'll never see listed as a core competency? Managing other people's chaos.
A healthcare AI startup can do everything a traditional security program asks for — SOC 2, HIPAA, tight access controls, encryption everywhere — and still have a serious compliance gap. Because the model itself introduces risks that classic security programs were never built to catch.
"AI got us compliant." I've started hearing this, and it makes me wince — not because AI has no place in compliance, but because of what that sentence usually means.
I've led multiple HITRUST certifications over the past decade — from full r2 implementations across 19 control domains to recertifications under aggressive timelines. So believe me when I say: most companies pursuing HITRUST shouldn't be.
When "where can we trim?" comes up, DevOps engineers are often among the first names on the list. From the compliance seat, that's one of the most self-defeating cuts a company can make.
Founders say "we finally hired someone to own security" like it's a milestone. Sometimes it is. Often it's an expensive problem wearing the costume of a solution.
A lot of early-stage founders think their next security move is hiring a CISO. Usually, it isn't. What they actually need is governance — and those are very different purchases.
Let me describe a compliance program I meet all the time. It lives entirely in Google Drive. There's a folder called "Policies (FINAL)." Right next to it, "Policies (FINAL v2)." Somewhere nearby, "Policies_USE_THIS_ONE."
There's a tempting line of reasoning I hear every cost-cutting season: "Can't we just fold compliance into engineering? Or legal? Or have the ops person pick it up?" I get the impulse. I also think it's one of the more expensive mistakes a growing company can make.
It's Wednesday afternoon. Someone from sales pings you: "Hey, quick one — a prospect sent over a security questionnaire. Who should fill this out?" You open it. It's 300 questions.
When I start with a healthcare startup, I don't open with frameworks. I open with the same short list of controls — because they tell me almost everything about how seriously a company takes security before anyone says a word.
I built an AI/LLM governance framework for a health-tech company. I also use AI tools in my own compliance practice every week. So this isn't an anti-AI post. It's a "here's where AI will quietly wreck your audit" post.
A company tells me they've "handled AI governance." I ask to see it. They send me a two-page AI policy. That's not governance. That's a document about governance — a very different thing, and the gap between the two is exactly where the risk lives.
Strip away the frameworks and the acronyms, and an audit is asking a surprisingly human question: can you be trusted to do the right thing when no one's watching?