SOC 2 for Healthcare: What HealthTech Vendors Need to Scope Their First Audit

Short answer: SOC 2 is not legally required for healthcare vendors, but health systems and payers routinely ask for it during vendor security reviews. For a HealthTech company handling PHI, scope Security plus Confidentiality and usually Availability, map controls to the HIPAA Security Rule, and treat SOC 2 as evidence alongside HIPAA, never a substitute for it.

Related guides:

• What is SOC 2?
• HITRUST vs SOC 2
• After SOC 2: the compliance roadmap for HealthTech

Key takeaways

• SOC 2 is a buyer expectation, not a law. HIPAA applies to you as a business associate. SOC 2 is how many healthcare customers prefer to check that your controls actually work.
• Scope follows your PHI. Every system that stores, processes or transmits PHI belongs in scope. Leaving it out makes the report less useful to the buyer reading it.
• Pick criteria deliberately. Security is the baseline. Confidentiality and Availability usually match what health systems care about. Privacy is worth adding only when you deal with patients directly.
• SOC 2 and HIPAA can share one report. Your auditor can address HIPAA Security Rule requirements as additional criteria in the same SOC 2 examination, but that is still not an HHS certification.
• Start small and honest. A tight first scope with a Type 1 report, followed by a Type 2, usually beats an ambitious scope that slips.

---

Do healthcare companies need SOC 2?

No law requires a healthcare vendor to have SOC 2, but in our experience most mid-size and large health systems ask for a SOC 2 report, or an equivalent such as HITRUST, before they share PHI with a SaaS vendor.

The reason is structural. A hospital that hands patient data to you stays accountable for it. HHS guidance on cloud services notes that the HIPAA Rules do not expressly require a vendor to provide documentation of its security practices or allow customers to audit them, but customers may require that through the business associate agreement or service contract based on their own risk analysis. A SOC 2 report is the most common way to satisfy that request without letting every customer run their own audit of your environment.

SOC 2 tends to matter most when:

• You sell to health systems, payers, pharmacy benefit managers or large provider groups with formal third-party risk programs.
• Your product stores or processes PHI at scale, such as an EHR integration, a remote patient monitoring platform or a revenue cycle tool.
• You also sell outside healthcare, where SOC 2 is the default ask, so one report serves both markets.

It matters less if you sell only to small practices that never send a questionnaire, or if your product never touches PHI.

Does SOC 2 make a HealthTech vendor HIPAA compliant?

No. SOC 2 is an attestation against AICPA criteria, while HIPAA is federal law that applies to you directly once you handle PHI for a covered entity.

HHS states that business associates are subject to the same Security Rule requirements as covered entities, including an accurate and thorough risk analysis and administrative, physical and technical safeguards for electronic PHI. HHS also says it does not endorse or otherwise recognize private organizations' "certifications" regarding the Security Rule. A clean SOC 2 report is strong evidence of good controls, but it does not discharge your HIPAA obligations.

The overlap is still large, which is why the two programs work well together:

HIPAA Security Rule area	Where SOC 2 usually covers it	What SOC 2 alone tends to miss
Risk analysis	Annual risk assessment	An inventory of every system holding ePHI and threats specific to it
Access control and audit controls	Logical access, MFA, logging	Tracing who viewed which patient record
Security incident procedures	Incident response plan	Breach risk assessment and notification to covered entities
Workforce training	Security awareness training	HIPAA-specific content and sanctions policy
Business associate contracts	Vendor management	Signed BAAs with customers and PHI subprocessors
Contingency planning	Backups and disaster recovery	Emergency mode operation for ePHI

For a full side-by-side comparison, see HIPAA vs SOC 2. For the contract side, see our guide to the HIPAA business associate agreement.

Which Trust Services Criteria should a healthcare vendor scope?

Scope Security in every case, add Confidentiality and Availability for most PHI-handling products, and add Privacy only when you collect personal information directly from patients.

The AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) define five categories: security, availability, processing integrity, confidentiality and privacy. In practice, every SOC 2 report covers Security, and the rest are optional. Here is how they line up for healthcare vendors:

Criteria	Include it when	Healthcare angle
Security (common criteria)	Always	Covers access, change management, monitoring and vendor risk around PHI systems
Confidentiality	You hold PHI or other data customers designate as confidential	Shows how PHI is identified, protected, retained and disposed of
Availability	Clinicians or patients depend on your uptime	Backs up uptime commitments in contracts, important for clinical workflows
Processing integrity	Your outputs drive clinical or financial decisions	Relevant for claims, billing, lab results or dosing calculations
Privacy	You collect personal information directly from patients or consumers	Covers notice, consent and data subject requests for patient-facing apps

A few scoping notes specific to healthcare:

1. Confidentiality versus Privacy. If you are a B2B vendor processing PHI on behalf of hospitals, the hospital owns the patient relationship. Confidentiality usually fits better than Privacy, because the Privacy criteria focus on commitments made to the individuals whose data you collect.
2. Patient-facing apps are different. If patients sign up with you directly, such as a consumer telehealth or wellness app, Privacy criteria may reflect real commitments in your privacy notice.
3. Do not add criteria you cannot evidence. Every extra category adds controls your auditor will test.

What is a SOC 2 report with HIPAA criteria?

It is a SOC 2 examination in which the auditor also reports on your controls against HIPAA Security Rule requirements, sometimes described as a "SOC 2+ HIPAA" report.

AICPA guidance allows a service organization to engage its service auditor to examine and report on additional subject matter and criteria beyond the standard trust services criteria. Healthcare vendors use this to put HIPAA mapping into the same report their buyers already request.

When it makes sense:

• Your buyers ask about HIPAA in every review. One report answers both questions and reduces follow-up questionnaires.
• You already run a HIPAA program. The extra criteria test controls you should already have, such as the risk analysis and breach procedures.
• You want to defer HITRUST. For some buyers, a SOC 2 report with HIPAA criteria is acceptable in place of HITRUST. Others insist on HITRUST, so check before you commit.

What it is not: a HIPAA certification. As noted above, HHS does not recognize private certifications of Security Rule compliance. Present the report as independent evidence of your controls, not as proof of compliance.

What do health system security reviews ask for?

Most health system reviews ask for a current SOC 2 Type 2 report (or HITRUST), a signed BAA, and answers to a security questionnaire focused on PHI handling.

In our experience, the requests cluster into a predictable list. Having these ready before the first sales call shortens reviews noticeably:

• Current SOC 2 report, ideally Type 2, plus a bridge letter if the period ended more than a few months ago
• Your standard BAA and a list of subprocessors that touch PHI, each with a BAA in place
• Data flow diagram showing where PHI enters, is stored and leaves your system
• Encryption details for data in transit and at rest, including key management
• Access control and MFA approach for your workforce and for customer users
• Incident response plan with breach notification steps toward the covered entity
• Recent penetration test summary and how findings were remediated
• Business continuity and disaster recovery plan with tested recovery objectives
• HIPAA risk analysis summary and training records

Expect the bar to keep rising. HHS published a proposed rule to strengthen the HIPAA Security Rule on January 6, 2025, which would, among other things, make multi-factor authentication and encryption of ePHI standard requirements and require a technology asset inventory. As of October 2026, HHS lists it as a proposed rule on its regulatory initiatives page, so treat the details as subject to change. Building MFA, encryption and an asset inventory into your SOC 2 scope now is sensible either way.

How do you scope your first SOC 2 audit?

Define the system around your PHI, choose criteria your buyers need, and start with a Type 1 report so you can fix gaps before a Type 2 observation period begins.

1. Map where PHI lives. List every application, database, cloud account, backup, log pipeline and third-party tool that stores or transmits PHI. This becomes your system boundary.
2. Decide what is out of scope, and say why. Marketing sites and internal tools without PHI can usually stay out. Document the reasoning, because buyers will ask.
3. Identify subservice organizations. Your cloud provider and other critical vendors are usually carved out and covered by their own SOC reports. List the complementary controls you rely on them for.
4. Choose criteria. Security plus the categories from the table above that match your contracts.
5. Run a readiness assessment. Compare current controls to the criteria and to the HIPAA Security Rule at the same time, so remediation covers both.
6. Remediate the usual gaps. These are often access reviews, offboarding, change approval, vendor reviews and logging of PHI access.
7. Get a Type 1, then start the Type 2 window. A Type 1 tests design at a point in time. A SOC 2 Type 2 tests whether controls operated over a period, and it is what most health systems ultimately want.
8. Decide on HIPAA criteria early. If you want a report that includes HIPAA criteria, tell your auditor before fieldwork so it can be planned into the engagement.

Keep the first scope tight. Adding a product line later is easier than explaining exceptions on systems you were not ready to cover.

How SecureSlate helps

SecureSlate gives HealthTech teams one control library mapped across SOC 2 and HIPAA, with HITRUST and ISO 27001 built in for when buyers ask for them. Agentless, read-only cloud integrations and a device agent for endpoint checks such as disk encryption keep evidence current. Access reviews pull accounts from connected integrations, and vendor risk management creates vendor entries from those integrations so you can track PHI subprocessors. Risk management supports your risk assessment, and audit management gives your auditor a workspace with an evidence tracker. When health systems send questionnaires, security questionnaire automation drafts answers from your own documents for review, and a trust center shares your SOC 2 report and policies with per-item public or restricted access and document request approval.

Start your free SecureSlate trial

FAQ

Is SOC 2 required for HIPAA compliance?

No. HIPAA does not require a SOC 2 report, and a SOC 2 report does not make you HIPAA compliant. Many healthcare buyers request SOC 2 through contracts as evidence that a vendor's controls work, so the two are often pursued together.

Should a HealthTech startup get SOC 2 or HITRUST first?

Follow what your buyers request. SOC 2 is generally a lighter first step and serves non-healthcare customers too. Some health systems and payers require HITRUST, so check their vendor requirements before you choose.

Does SOC 2 for healthcare need the Privacy criteria?

Not usually. B2B vendors processing PHI for hospitals typically scope Security and Confidentiality, often with Availability. Privacy criteria fit best when you collect personal information directly from patients.

How long does a first SOC 2 audit take for a healthcare company?

It depends on your starting point and report type. A Type 1 reflects a single point in time, while a Type 2 covers an observation period that you and your auditor agree on. Readiness and remediation usually take the most time.

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.