After SOC 2: The Compliance Roadmap for HealthTech Companies

Photo: Unsplash

Short answer: After SOC 2, most HealthTech companies should close their HIPAA gaps next: complete a HIPAA risk analysis, sign business associate agreements with customers and PHI vendors, and add breach notification procedures. Then pursue HITRUST if US health systems or payers require it, or ISO 27001 if you sell internationally, reusing your existing SOC 2 controls.

Related guides:

• HIPAA for HealthTech: a complete guide to compliance
• HITRUST vs SOC 2
• SOC 2 Type 2

Key takeaways

• A SOC 2 report proves your security program works. It does not prove you meet HIPAA, and healthcare buyers will ask about both.
• The next step for most HealthTech companies is a HIPAA gap assessment on top of SOC 2, followed by a documented HIPAA risk analysis and signed business associate agreements (BAAs).
• HITRUST is usually driven by health system and payer procurement. ISO 27001 is usually driven by international or enterprise buyers. Pick the one your pipeline is asking for.
• Most of your SOC 2 controls carry over. Treat every new framework as a mapping exercise, not a new program.

---

Is SOC 2 enough for healthcare customers?

No. SOC 2 is a strong foundation, but healthcare customers also expect HIPAA compliance and sometimes HITRUST. Getting a clean SOC 2 report is still a real milestone. It shows that an independent CPA firm tested your controls for security, and possibly availability, confidentiality, processing integrity and privacy, and found them designed and (for Type 2) operating effectively.

Healthcare buyers, however, are regulated in ways that SOC 2 was never designed to address:

• HIPAA is a law, not a framework. If you create, receive, maintain or transmit protected health information (PHI) for a covered entity, you are a business associate and the HIPAA Security Rule applies to you directly. A SOC 2 report is useful evidence, but it is not a HIPAA attestation.
• Hospital security questionnaires are PHI-specific. Expect questions about minimum necessary access, breach notification timelines, PHI in logs and backups, and whether your subprocessors have signed BAAs.
• Some buyers mandate a specific certification. Many health systems and payers now require HITRUST for vendors that touch large volumes of PHI.

The good news is that SOC 2 gives you the foundation: policies, access reviews, change management, vendor management, incident response and a habit of collecting evidence. The roadmap below builds on that foundation instead of starting over.

Step 1: What HIPAA gaps remain after SOC 2?

The most common gaps are the HIPAA risk analysis, business associate agreements, breach notification, PHI-specific access and audit logging, and HIPAA training. Start with a gap assessment that compares your current SOC 2 controls to the HIPAA Security Rule, Privacy Rule (to the extent it applies to you as a business associate) and Breach Notification Rule. The areas where SOC 2 programs most often fall short are:

HIPAA requirement	Typical gap after SOC 2	What to add
Security risk analysis	SOC 2 risk assessment does not specifically inventory ePHI	A documented risk analysis covering every system that stores or transmits ePHI
Minimum necessary	Access is role based but not scoped to PHI	PHI-specific access rules and reviews
Breach notification	Incident response plan has no HIPAA timelines	Breach assessment steps and notification to covered entities without unreasonable delay
Business associate agreements	Vendor reviews exist but BAAs are missing	Signed BAAs with customers and PHI subprocessors
Workforce training	General security awareness only	HIPAA-specific training with completion records
Audit controls	Logs exist but PHI access is not traceable	Audit logging of access to ePHI records

The risk analysis deserves special attention. It is the requirement the HHS Office for Civil Rights cites most often in enforcement actions, and a SOC 2 risk register rarely covers it on its own. Our HIPAA risk assessment guide walks through the method.

Also keep an eye on regulatory change. HHS has proposed significant updates to the HIPAA Security Rule, including more prescriptive requirements for asset inventories, encryption and multi-factor authentication. Building those controls now is sensible even before a final rule is published.

Step 2: Which business associate agreements do you need?

You need a BAA with every customer that shares PHI with you and with every vendor that handles PHI on your behalf. A BAA is the contract that lets a covered entity share PHI with you. Without one, a hospital cannot legally send you PHI, no matter how strong your SOC 2 report is.

Work through three layers:

1. Customer BAAs. Have a standard BAA template ready so sales cycles do not stall in legal review. Know which clauses you will negotiate and which you will not.
2. Downstream BAAs. Every subprocessor that touches PHI on your behalf, such as your cloud provider, email service or support tool, needs a BAA with you. Many SaaS tools only offer a BAA on specific plans, so check before you route PHI through them.
3. A living subprocessor list. Keep a current list of PHI subprocessors, what data each one receives and when its BAA was signed. Buyers will ask for it.

See our guide to the HIPAA Privacy Rule for how permitted uses and disclosures shape what you can do with PHI under a BAA.

Step 3: Should you get HITRUST or ISO 27001 next?

Choose HITRUST if US health systems and payers are asking for it, and ISO 27001 if you are selling internationally or to general enterprise buyers. Once HIPAA is covered, the next framework should follow your pipeline. The two common options answer different buyer questions.

	HITRUST	ISO 27001
Who asks for it	US health systems, payers, large healthcare enterprises	International buyers, enterprise procurement, EU customers
What it proves	Controls mapped to HIPAA, NIST and other sources, validated by a HITRUST assessor	A certified information security management system (ISMS)
Options	e1, i1 and r2 assessments with increasing rigor	Single certification with surveillance audits
Effort	Moderate for e1 and i1, high for r2	Moderate if SOC 2 is already in place
Best fit	Selling PHI-heavy products into US healthcare	Expanding outside the US or into non-healthcare enterprise

A simple rule of thumb: if lost deals cite HITRUST, start with the HITRUST e1 or i1 assessment and move to r2 only if buyers require it. If you are expanding into Europe or the UK, ISO 27001 certification usually opens more doors. Read our full comparison of HITRUST vs SOC 2 for more detail.

What does a 12-month post-SOC 2 roadmap look like?

Every company is different, but this sequence works for most Series A and Series B HealthTech teams that already hold a SOC 2 Type 1 or Type 2 report.

• Months 0 to 2: HIPAA gap assessment, ePHI data flow map, HIPAA risk analysis, BAA template and subprocessor BAAs.
• Months 2 to 4: Remediate gaps. Add PHI access controls, audit logging, breach notification procedures and HIPAA training.
• Months 4 to 6: Keep the SOC 2 Type 2 observation window running. Consider adding HIPAA criteria to your SOC 2 examination so one report covers both.
• Months 6 to 12: Start HITRUST or ISO 27001, depending on pipeline demand, using the same control library.

Run this alongside your normal SOC 2 cadence so the renewal audit is not a separate project.

How do you avoid duplicate work across frameworks?

Build one control library, collect evidence once and map it to every framework. The biggest cost of multi-framework compliance is duplicated effort: two policy sets, two risk registers, two evidence folders. Avoid it with three habits:

• One control library. Write each control once and map it to SOC 2 criteria, HIPAA safeguards, HITRUST requirements and ISO 27001 Annex A controls. Access reviews, for example, satisfy all four.
• One evidence stream. Collect evidence continuously and tag it to controls, not to frameworks. The same MFA screenshot serves every audit.
• One owner per control. Named owners keep controls running between audits, which is what Type 2, HITRUST r2 and ISO surveillance audits all test.

How SecureSlate helps

SecureSlate is built for SMBs and HealthTech teams that need SOC 2, HIPAA, ISO 27001 and related frameworks without a large compliance team. You get a single control library mapped across frameworks, automated evidence collection from your cloud and SaaS stack, HIPAA risk assessment workflows, vendor and BAA tracking, and audit-ready exports for your auditor.

Start your free SecureSlate trial

FAQ

Does a SOC 2 report make us HIPAA compliant?

No. SOC 2 and HIPAA overlap heavily, but HIPAA has specific requirements such as a documented risk analysis, business associate agreements and breach notification procedures that a standard SOC 2 examination does not cover. Many companies add HIPAA criteria to their SOC 2 examination so a single report addresses both.

Is there an official HIPAA certification?

No. HHS does not certify organizations as HIPAA compliant. Companies demonstrate HIPAA compliance through documented policies, a risk analysis, signed BAAs and third-party assessments such as SOC 2 with HIPAA criteria or HITRUST.

Should a HealthTech startup do HITRUST or ISO 27001 after SOC 2?

Follow your buyers. HITRUST is most often required by US health systems and payers, while ISO 27001 is more valuable for international and general enterprise sales. If neither is being requested yet, focus on HIPAA and keep your SOC 2 current.

How long does it take to add HIPAA to an existing SOC 2 program?

Teams with a mature SOC 2 program often close HIPAA gaps in two to four months. The timeline depends mostly on how quickly you can complete the risk analysis, sign BAAs with subprocessors and add PHI-specific logging and access controls.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.