%20(39)%20(1).png)
Key takeaways:
- HIPAA is a federal law, but it doesn’t have a proper certification. Every healthtech that touches Protected Health Information (PHI) has to comply with it.
- SOC 2 is usually the first framework enterprise healthcare buyers ask for, even before HIPAA comes up in the conversation.
- HITRUST is a private certification that layers HIPAA, NIST, and ISO 27001 into one framework. It matters mainly if your buyers are hospital systems or large payers.
- If you're building medical device software (SaMD), FDA regulatory pathways and ISO 13485 apply, and that's a completely different track from data security frameworks.
Healthcare compliance sits at the intersection of federal law, industry-driven certifications, and, increasingly, AI regulation.
This post maps the frameworks that actually apply to healthtech startups, in the order you're likely to need them, and where each one stops mattering.
An important note: none of these frameworks are interchangeable, and none of them substitute for another. A common assumption we hear is that having SOC 2has you covered, but SOC 2 doesn't touch HIPAA's legal requirements, and HIPAA doesn't touch what an enterprise buyer's procurement team will ask to see.
Treating them as one undifferentiated compliance project is how startups end up spending budget on certifications no buyer asked for yet, while the legal baseline goes unaddressed.
Frameworks overview
HIPAA: the baseline
HIPAA is a federal law, and it applies the moment your product touches Protected Health Information (PHI). Whether you're a covered entity (a provider, insurer, or clearinghouse) or a business associate (a vendor handling PHI on someone else's behalf), it applies to you.
Here's the part that trips people up: there's no HIPAA certificate. No government body audits you and hands you a badge. What you actually need is a documented risk analysis, a signed Business Associate Agreement (BAA) with every vendor that touches PHI, and technical safeguards (such as encryption at rest and in transit, access controls, and audit logging) that hold up if the Office for Civil Rights (OCR) ever comes asking.
That last point is more important than founders assume early on, because OCR doesn't run scheduled audits of every healthtech. It typically investigates after a complaint or a reported breach. That doesn't make HIPAA optional in the meantime, though. It means the risk is asymmetric: you can operate for years without anyone checking your safeguards, right up until an incident forces the question, and by then it's too late to build the risk analysis and documentation you should have had from day one.
To find out exactly what a HIPAA compliance assessment verifies, and why the absence of a certificate doesn't mean the absence of a standard, check our HIPAA compliance assessment guide.
SOC 2: what enterprise buyers ask for first
Here's a pattern we see constantly with healthtech clients: HIPAA is the legal requirement, but SOC 2 is the first thing that shows up in a vendor security questionnaire.
Enterprise healthcare buyers, like hospital systems, payers, and health system IT, are used to asking for a SOC 2 report as their opening move, because it's a standardized, third-party-audited artifact they can evaluate quickly. HIPAA compliance, by contrast, is harder for a buyer to verify from the outside, since there's no report to request.
SOC 2 isn't legally required, but if your growth plan includes enterprise healthcare deals, you'll likely need it regardless of what HIPAA already requires you to do. The good news is that the two overlap significantly on access control, encryption, and incident response. Build your HIPAA safeguards with SOC 2's Trust Services Criteria in mind from the start, and you'll avoid rebuilding the same controls twice under two different names.
The typical sequence we see with healthtech clients: start with SOC 2 Type I to prove controls are designed correctly, then move to Type II once they have an operating history to demonstrate those controls work over time, which is usually the report enterprise buyers actually want to see.
We break down exactly where HIPAA and SOC 2 diverge, and where a single control satisfies both. Check SOC 2 vs HIPAA: Which Compliance Does Your Startup Need?
HITRUST: beyond HIPAA and SOC 2
HITRUST is where healthtech compliance starts to diverge from general SaaS compliance. It's a private certification, not a law or something OCR enforces, built on the HITRUST Common Security Framework (CSF), which incorporates HIPAA, NIST, and ISO 27001 requirements into a single control set with a third-party assessment.
The truth is, you should worry about HITRUST mainly when a buyer specifically requires it. Large health systems and payers increasingly ask for HITRUST as a condition of vendor approval, particularly once you're past early-stage sales into smaller practices or digital health platforms. It's a heavier lift than SOC 2, with broader scope, more controls, and longer assessment, so we don't recommend pursuing it speculatively. Sequence it after SOC 2, and only once a real deal is asking for it.
Because HITRUST already maps to HIPAA, NIST, and ISO 27001 controls, the SOC 2 and ISO 27001 work you've already done isn't wasted if you eventually need it.
A well-run compliance program can reuse a meaningful share of existing evidence rather than starting the HITRUST assessment from a blank slate. That's a strong argument for building your control documentation with cross-framework mapping in mind, even before HITRUST is on the table.
ISO 27001: the framework for international buyers
If your healthtech is outside of the US, has European or global ambitions, or European buyers are already asking questions, ISO 27001 is relevant to you (or will be faster than you'd expect).
It's the information security standard most commonly required by international enterprise buyers, and it overlaps meaningfully with GDPR's technical and organizational requirements, which matters if you're processing health data for EU patients or users. We map exactly where that overlap sits in GDPR and ISO 27001: how they overlap for European startups.
For a full breakdown of what ISO 27001 actually requires and how it compares to the US-centric SOC 2, check What Is ISO 27001? Why European Enterprise Buyers Require It.
If you're building a medical device: FDA and ISO 13485
Everything above applies to healthtechs handling patient data. It's a different conversation entirely if your product is a Software as a Medical Device (SaMD), which is software intended to diagnose, treat, or monitor a medical condition, rather than just manage or store health information.
If that's you, HIPAA and SOC 2 don't disappear, but they're joined by an FDA regulatory pathway (the specific one depends on your device's risk classification) and, frequently, ISO 13485, the quality management system standard for medical device manufacturers.
This is a specialized regulatory track that runs in parallel to data security compliance, and it's worth engaging regulatory counsel early if there's any chance your product crosses the line from health data software into an actual medical device.
GDPR and the EU AI Act: if you have European users or AI features
Two more frameworks are worth flagging even for startups that don't think of themselves as international yet:
- GDPR applies the moment you have EU patients or users in your system, regardless of where your company is incorporated. If you already need ISO 27001 for enterprise sales, you're most of the way to GDPR's technical requirements, but GDPR also has legal requirements (lawful basis for processing, data subject rights, and breach notification timelines) that security certifications don't cover on their own.
- The EU AI Act matters if your product includes AI features, such as diagnostic support, clinical decision support, triage, or any AI system making or informing a decision about a patient. Healthcare AI is explicitly called out as a potential high-risk category under the Act, which brings conformity assessments, technical documentation, and human oversight requirements. We cover the EU AI Act alongside ISO 42001 and the NIST AI RMF in our AI Compliance for Startups post.
What's changing in 2026
The HIPAA Security Rule, unchanged in its core structure for years, is in the middle of its first major update. The Office for Civil Rights (OCR) proposed a rule in January 2025 that would tighten security requirements significantly, effectively moving from a "reasonable and appropriate" standard toward more prescriptive, mandatory safeguards. Finalization is expected sometime in 2026.
It’s worth keeping an eye on this. But if you're building towards HIPAA right now, keep going with the current requirements.
Want to know more? Check here.
How to sequence these frameworks without burning your budget
The mistake we see most often is treating every framework as a parallel, equally urgent project. Here's a suggested and efficient sequence:
- HIPAA fundamentals first: encrypted storage and transmission, access controls, audit logging, and signed BAAs. HIPAA isn't optional, and it's the foundation of everything you’ll build later on.
- SOC 2 Type II once you're in enterprise sales conversations and buyers start asking for a report.
- ISO 27001 if international buyers enter the picture, or HITRUST if a specific large health system or payer requires it. Pursue them based on actual buyer demand.
- GDPR and the EU AI Act layer in as soon as EU users or AI features are part of the product, regardless of the company stage.
If you're mapping this out for the first time, our guide to first-time compliance walks through when to start and how to budget for it, check First-Time Compliance. Check Compliance on a Startup Budget for a breakdown of realistic cost planning across SOC 2, ISO 27001, and beyond, with current figures.
FAQ: Frequently asked questions
What is healthcare compliance for a healthtech startup?
It's the combination of a legal baseline (HIPAA and GDPR if you have EU users) and buyer-driven certifications (SOC 2, HITRUST, and ISO 27001) that enterprise healthcare customers require before signing. The legal requirements aren't optional, and the certifications are typically driven by who you're selling to.
Is HIPAA compliance legally required, or just a best practice?
Legally required. If your product touches PHI, HIPAA applies regardless of company size or stage. There's no certificate, but there is enforcement, because OCR investigates complaints and breaches, and penalties apply for non-compliance.
Do we need HITRUST if we already have SOC 2?
Not automatically. HITRUST becomes relevant when a specific buyer, typically a hospital system or large payer, requires it as part of vendor approval. Many healthtechs operate on SOC 2 alone until that specific demand appears.
When should a healthtech choose ISO 27001 over, or in addition to, SOC 2?
ISO 27001 becomes relevant when international buyers, particularly in Europe, are part of your pipeline. Many growing healthtechs end up pursuing both, since they serve different buyer expectations rather than replacing each other.
Does the EU AI Act apply to our healthtech product?
It applies if your product includes AI systems that diagnose, triage, or otherwise inform decisions about patient care, because these can fall into the Act's high-risk category. It doesn't apply if your AI use is limited to non-clinical functions like scheduling or administrative automation.
%20(38)%20(1).png)
%20(29)%20(1).avif)
%20(30)%20(1).avif)