SOC 2 by industry

SOC 2 for healthtech: one report, drawn around the health data.

Q: Do we need Privacy in our report because we hold health data?

Not automatically. The Privacy category tests your privacy notice and commitments to individuals. If you process data only on behalf of a provider, under their notice, Confidentiality and Security often fit better. Patient-facing products with their own notice are the usual case for adding Privacy.

Hospitals, clinics and health plans review vendors carefully because a breach at a vendor is still their problem. A SOC 2 report lets them see your controls tested by an independent CPA firm. It does not tell them you comply with HIPAA, and it should not be presented that way. This guide shows how the two fit together and where healthtech scoping goes wrong.

Back to SOC 2 services

01 · Who asks

Who asks healthtech companies for a SOC 2 report

The buyer decides the scope and the weight of the report, so start with who is asking.

Asked by	What they want to see
Hospital and health-system security offices	A Type 2 report alongside a signed business associate agreement and answers to their own risk questionnaire.
Health plans and payers	Access controls over member data, audit logging and how quickly incidents reach them.
Digital health partners and EHR marketplaces	How your integration authenticates and what data it pulls from their platform.
Clinical research sponsors	Confidentiality of study data and, sometimes, controls that support their own regulatory obligations.

02 · What is in scope

What sits inside the system boundary

The report covers one system. In this sector the boundary usually takes in:

Clinical and member data stores: Where health records, claims, images or device readings are kept, including backups and analytics copies.
EHR and clearinghouse integrations: Interfaces that exchange records with electronic health record systems and payers.
Clinician and patient applications: The portals and apps where care teams and patients see data, and their sign-in.
Audit logging of record access: The trail of who viewed or changed which record, and how it is reviewed.
Support and clinical operations staff: People who handle health data in the course of support, onboarding or care coordination.

03 · Categories

Which Trust Services Categories matter here

Security is always in. The rest depend on what you promise customers.

Category	Weight in this sector	Why
Security	Core	Always included. Record-level access and logging are what reviewers read first.
Confidentiality	Core	Health information is the most sensitive thing most customers hand over. Retention and disposal matter when contracts end.
Privacy	Often	Fits when you deal with patients directly, under your own privacy notice. Less so when you act only for a covered entity.
Availability	Often	Clinical workflows stop when the tool stops. Buyers ask about recovery and downtime procedures.
Processing Integrity	Situational	Relevant for claims, billing or results-delivery products where an altered or dropped record harms a patient or payment.

04 · Vendors in the report

The vendors that appear in your report

Each one is a subservice organization or a carve-out, and the report has to say which.

HIPAA-eligible cloud services: Carved out, with the provider's business associate agreement and report on file. Only the services it lists as eligible should hold health data.
Messaging and telehealth providers: Subservice organizations when appointment reminders or video carry health information.
Clearinghouses and EHR vendors: Usually outside your boundary as separate systems, but the interface you run to them is inside.
Transcription or coding contractors: People outside the company seeing health data. They need agreements, access controls and periodic review.

05 · Sector controls

Controls that this sector makes necessary

Examples only. Your own wording is what the auditor tests.

S.1
Record access is logged and reviewedEvery view of a patient record is logged. Unusual access patterns are reviewed on a set schedule.
S.2
Break-glass access is rare and recordedEmergency access beyond a role is possible, needs a reason and triggers review the next business day.
S.3
Business associate agreements before data flowsNo vendor receives health data until an agreement is signed and recorded in the vendor register.
S.4
Minimum necessary in support toolingSupport staff see masked fields by default and unmask only for a ticket.
S.5
De-identified datasets checked before useData used for analytics or product work is de-identified by a defined method and approved.
S.6
Incident path includes customer noticeThe incident procedure names the point at which covered-entity customers are told, matching contract terms.

06 · Traps

Where companies in this sector slip

Predictable, and cheaper to fix before fieldwork.

Calling the SOC 2 'HIPAA certified'. There is no such certification, and a SOC 2 is not a HIPAA opinion. Say what the report covers and leave HIPAA claims to your own program.
Health data in a non-eligible service. A product analytics tool or error tracker receives health data in event payloads. Both the BAA story and the boundary break.
Scoping the app but not the data warehouse. Analytics copies of clinical data are often less protected than production. They hold the same information.
A risk assessment that ignores HIPAA's. Running two separate risk assessments that disagree is avoidable. One assessment can serve both purposes if it is thorough.
Patient-facing and clinician-facing apps treated as one. They have different users, different sign-in and different privacy notices. Describe both.

07 · SOC 2 and HIPAA

Where SOC 2 and the HIPAA Security Rule meet

They overlap a lot and still answer different questions.

SOC 2

An attestation report

A CPA firm's opinion on your controls against the Trust Services Criteria
Scope is the system you describe
Read by customers under restricted use
Says nothing about legal compliance

HIPAA

A legal obligation

Applies to covered entities and business associates by law
Security Rule safeguards: administrative, physical, technical
Enforced by the regulator, not by a report
No official certification exists

One set of controls can serve both. Many teams keep a mapping from each SOC 2 control to the Security Rule safeguard it also supports.

Shared groundRisk assessment, access control, audit logging, encryption, incident response and workforce training appear in both.
HIPAA-only groundBusiness associate agreements, breach notification duties and the specific required and addressable safeguards.
SOC 2-only groundThe system description, independent testing over a period and the structure of the Trust Services Criteria.

08 · Evidence

Evidence to have ready

What an auditor will ask for, in the order they usually ask.

The register of business associate agreements, matched to vendors receiving health data
Record-access logs and evidence of their review
Break-glass events for the period and their follow-up
The risk assessment, showing health data flows
Workforce training records, including contractors
Backup and restore tests covering clinical data
Incident records and customer notifications, if any occurred

The HIPAA Security Rule stands on its own

If you create, receive, keep or send protected health information for a covered entity, you are likely a business associate under HIPAA, with duties set out in 45 CFR Part 164, Subpart C, and in your agreements. A SOC 2 report can describe controls that support those duties. It is not evidence of HIPAA compliance, and no SOC 2 should be labelled that way.

Sources: AICPA Trust Services Criteria (TSP section 100); AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization (additional subject matter and criteria); HIPAA Security Rule, 45 CFR Part 160 and Part 164, Subparts A and C; HHS guidance on de-identification under the Privacy Rule.

More about SOC 2 for healthtech

Can we add HIPAA to our SOC 2 report?

Some auditors can report against both. It is a scoping choice.

Some CPA firms offer an examination that reports on the Trust Services Criteria and additional criteria drawn from the HIPAA Security Rule in one engagement. Whether that suits you depends on what buyers request. Ask the firm what opinion it will actually give.

We only store de-identified data. Is healthtech scoping still needed?

Check how it was de-identified.

If data meets a recognised de-identification method, HIPAA may not apply to it. Your SOC 2 still covers the system, and the de-identification step itself becomes a control buyers will want to see.

Hospitals send us their own questionnaire anyway. Why bother with a report?

It shortens the questionnaire and adds independence.

A questionnaire is your own account. A Type 2 report is a CPA firm's tested account. Reviewers often accept the report for large parts of their survey and focus their questions on what it does not cover.

Do we need Privacy in our report because we hold health data?

Not automatically.

The Privacy category tests your privacy notice and commitments to individuals. If you process data only on behalf of a provider, under their notice, Confidentiality and Security often fit better. Patient-facing products with their own notice are the usual case for adding Privacy.

Scope your healthtech SOC 2 around what buyers ask.

A readiness assessment turns this into your boundary, your categories and your gaps.

Get a SOC 2 readiness assessment Book a free consultation Back to SOC 2 services