SOC 2 for Healthcare Companies: Type 2 Guide (2026)

A SOC 2 Type 2 report gives a healthcare customer independent evidence that your controls operated throughout a defined period. HIPAA sets legal duties for covered entities and business associates; SOC 2 tests the service organization controls behind the product you sell. Healthcare SaaS companies often need both.

The distinction is easy to blur. Not every company that handles health-related data is regulated by HIPAA, and a SOC 2 report does not certify HIPAA compliance. Start with your legal status, contracts, PHI flows, and buyer requirements. Then build one evidence system that supports both programs without pretending they are interchangeable.

This guide focuses on the work healthcare SaaS teams must get right: the PHI boundary, EHR and API integrations, Trust Services Criteria, third-party dependencies, and the recurring evidence a Type 2 auditor can sample.

Does a healthcare company need SOC 2 if it already follows HIPAA?

A healthcare company needs SOC 2 when customers require independent assurance over its service controls; HIPAA compliance alone does not provide a CPA opinion on control design and operation. HIPAA remains the legal obligation for regulated entities, while SOC 2 is usually contractual.

The current HIPAA Security Rule applies to covered entities and business associates. It protects electronic protected health information (ePHI) through administrative, physical, and technical safeguards. A consumer health app outside those categories may handle sensitive health data without falling under HIPAA, although other laws and contracts can still apply.

SOC 2 has a different boundary. An independent CPA firm examines the controls in a service organization’s system against the AICPA Trust Services Criteria. A Type 1 report addresses control design at a point in time. A Type 2 report also addresses whether controls operated over a specified period.

Healthcare buyers use that report to test claims that a policy cannot settle:

• Were privileged and support accounts reviewed on schedule?
• Did production changes receive approval and testing?
• Were security alerts investigated and documented?
• Did backups restore successfully?
• Were subprocessors assessed before they received access to customer data?

On July 31, 2025, Change Healthcare told the HHS Office for Civil Rights that its breach had affected approximately 192.7 million individuals. The HHS incident FAQ also shows how one business associate can create notification and continuity dependencies across many covered entities. Healthcare SaaS system boundaries must include material third-party dependencies.

For the general framework before the healthcare overlay, use the SOC 2 compliance overview.

How do HIPAA and SOC 2 overlap without replacing each other?

HIPAA and SOC 2 share evidence for access, audit logging, incident response, risk management, and continuity. The overlap reduces duplicate collection, but SOC 2 does not close HIPAA-specific duties such as legal applicability, Business Associate Agreements, breach notification, or required documentation.

There is no definitive one-to-one mapping. HIPAA is a federal regulatory framework for PHI. SOC 2 is a CPA attestation against criteria that management applies to a described system. The same control can support both, but each program asks a different question.

Question	HIPAA Security Rule	SOC 2 Type 2	Planning implication
Who is covered?	Covered entities and business associates	Service organizations that choose or contract to undergo an examination	Confirm HIPAA status separately from the SOC 2 project
What is protected?	ePHI created, received, maintained, or transmitted by a regulated entity	Information and systems inside the management-defined service boundary	Reconcile the PHI data flow with the SOC 2 system description
What is the test?	Compliance with applicable legal requirements	Suitability of design and operating effectiveness over the review period	Reuse evidence, but keep conclusions separate
Who issues the result?	HHS does not issue a federal HIPAA certificate	An independent licensed CPA firm issues the SOC 2 report	Do not market the SOC 2 opinion as HIPAA certification
What remains outside the overlap?	BAAs, breach duties, regulatory documentation, and other HIPAA obligations	Criteria and controls selected for the described service	Maintain a HIPAA obligations register beside the SOC 2 control matrix

The strongest shared evidence usually appears in these areas:

HIPAA safeguard area	SOC 2 evidence that can support it	HIPAA work that still needs a separate check
Access control and authentication	Role matrix, approvals, MFA configuration, periodic reviews, deprovisioning records	Minimum-necessary decisions and access to ePHI across the regulated entity
Audit controls	Log configuration, alert rules, review records, investigation tickets	Coverage of every information system that contains or uses ePHI
Integrity and transmission security	Change approvals, validation tests, encryption settings, key-management records	HIPAA-specific analysis of ePHI integrity and transmission risk
Incident procedures	Response plan, exercises, incident tickets, lessons learned	Breach assessment and notification duties
Contingency planning	Backup monitoring, restore tests, recovery exercises	HIPAA emergency-mode and ePHI recovery requirements
Business associates	Vendor inventory, due diligence, monitoring, contract ownership	Required BAAs and downstream business-associate arrangements

The detailed auditor-side structure belongs in the guide to SOC 2 + HIPAA overlay engagements. This page stays on the buyer’s control and evidence plan.

Which HIPAA Security Rule applies in 2026?

The existing HIPAA Security Rule remains in effect. HHS proposed a major cybersecurity update on December 27, 2024, but the proposal is not final law. Healthcare teams should comply with the current rule and track the proposal separately.

The HHS proposed-rule fact sheet would add or tighten requirements for asset inventories, network maps, multi-factor authentication, encryption, vulnerability scanning, penetration testing, annual compliance audits, backup recovery, and business-associate verification. HHS explicitly states that the current Security Rule remains in effect during rulemaking. Map each applicable current safeguard to a control owner and evidence source; use the proposal only to see where the existing SOC 2 program already produces evidence a future rule might ask for. Keep the crosswalk versioned and assign counsel or compliance ownership, because requirements and dates may still change before finalization.

The proposal is useful as a planning signal, not a compliance checklist. A healthcare SaaS team already maintaining a technology inventory, ePHI network map, MFA evidence, vulnerability scans, penetration tests, and tested recovery records will be better prepared for buyer diligence regardless of the final text.

What does SOC 2 Type 2 require from healthcare SaaS?

SOC 2 Type 2 requires healthcare SaaS controls to operate and generate evidence throughout the review period. The critical proof sits in PHI-aware access, EHR and API changes, audit logging, incident handling, availability, and oversight of subprocessors that support the service.

Healthcare workflows add evidence populations to the generic SaaS baseline. The system description and evidence population must include the real path data takes — from customer authentication through integrations, support tools, analytics, backups, and deletion.

Healthcare SaaS workflow	Control the auditor needs to understand	Evidence that should exist before fieldwork
EHR, FHIR, HL7, lab, or claims integration	Authentication, secret management, input validation, error handling, and interface change approval	Data-flow diagram, secret inventory, failed-message queue review, mapping tests, approved change tickets
Support access to production	Time-bounded privileged access, approval, monitoring, and revocation	Access requests, session or admin logs, periodic review, break-glass records
Patient or clinician messaging	Identity, authorization, delivery, retention, and audit logging	Role tests, message-access logs, alert reviews, retention configuration
Multi-tenant data storage	Tenant isolation, encryption, backup protection, and deletion	Architecture diagram, configuration evidence, isolation tests, restore results, deletion tickets
Clinical or financial processing	Completeness, accuracy, timeliness, and authorized processing	Reconciliation results, exception queues, validation tests, defect and release records
Cloud and SaaS subprocessors	Due diligence, contract ownership, access boundaries, and ongoing monitoring	Vendor inventory, risk reviews, SOC reports, BAA status, renewal decisions
Connected device, kiosk, tablet, or clinic-side agent	Provisioning, unique identity, update/patch channel, physical handling, and service-account restrictions	Device inventory, provisioning record, update log, access review including device identities, incident path
Service availability	Capacity, monitoring, incident response, backup, and recovery	Uptime evidence, incident timeline, recovery exercise, restore test, corrective actions

This workflow matrix is the core difference between a generic SOC 2 project and a healthcare SaaS Type 2 project. The auditor samples controls; the team must first define complete populations. If emergency changes, support sessions, integration failures, or vendor reviews are missing from those populations, the evidence can look clean while the system boundary is wrong.

For the report mechanics and the fact that the AICPA sets no universal minimum observation period, see what a SOC 2 Type 2 report contains.

Which Trust Services Criteria should a healthtech company include?

Every SOC 2 examination includes Security. Healthcare SaaS teams should add Availability, Confidentiality, Processing Integrity, or Privacy only when the service, contract, risk assessment, or buyer requirement makes that criterion relevant. Handling PHI does not automatically require all five criteria.

Trust Services Criterion	Include it when	Healthcare evidence examples
Security	Always	Access control, vulnerability management, monitoring, incident response, change management
Availability	Contracts or clinical operations depend on uptime and recovery commitments	Capacity reviews, uptime monitoring, backup results, recovery exercises
Confidentiality	The service promises to protect PHI or other designated confidential information	Classification, encryption, support-access restrictions, disposal records
Processing Integrity	Customers depend on complete, valid, accurate, timely, and authorized processing	Claims reconciliation, lab-result validation, interface error queues, correction workflows
Privacy	The service makes privacy commitments covered by the AICPA privacy criteria	Notices, consent, use, retention, disclosure, access, correction, and disposal processes

Security, Availability, and Confidentiality are a common healthcare SaaS scope, but “common” is not a reason to buy them. Read the customer contract, security questionnaire, service-level commitment, and data-flow diagram. Add a criterion when the report must answer a real reliance question.

Processing Integrity deserves a closer look for claims, eligibility, lab routing, clinical decision support, and other systems where a technically secure error can still harm downstream operations. Privacy also needs a deliberate scoping decision; HIPAA obligations do not automatically prove that the AICPA Privacy criterion belongs in the report.

How should a healthcare company define the SOC 2 system boundary?

A healthcare SOC 2 boundary should follow the service and its data flows, not the organization chart. Scope every system, person, process, and subprocessor that materially supports the customer-facing service or its commitments, including PHI integrations and production support paths.

Use this sequence before the readiness assessment:

1. Name the service customers rely on. Define the product, deployment model, locations, and customer population covered by the report.
2. Trace regulated and confidential data. Record where ePHI and other sensitive data are created, received, transmitted, viewed, exported, backed up, and destroyed.
3. Map every integration and support path. Include EHR interfaces, identity providers, messaging, analytics, ticketing, observability, remote support, and manual exports.
4. Identify people and vendors with material control responsibility. Include employees, contractors, cloud providers, managed services, and subprocessors.
5. Reconcile the boundary with contracts. The system description, BAAs, privacy commitments, uptime terms, and customer questionnaires should describe the same operating reality.
6. Review exclusions with the auditor. Document why a system or process does not affect the in-scope service before the observation period starts.

Excluding a support tool that contains screenshots of PHI or an integration service that transforms clinical data creates a gap buyers can spot in the report. Documented exclusions keep the scope narrow without hiding a material dependency.

What evidence must run throughout the Type 2 observation period?

A Type 2 program needs dated evidence from every recurring control population, plus records for event-driven controls such as hires, terminations, incidents, and production changes. Each control needs an owner, cadence, source system, exception path, and retention rule before testing begins.

Control population	Cadence to define before the period	Healthcare-specific evidence
User and privileged-access reviews	Monthly, quarterly, or another risk-based interval	PHI repositories, EHR consoles, support impersonation, cloud admins
Joiner, mover, and leaver events	Every applicable workforce event	Approval, role change, revocation time, exception record
Production and integration changes	Every release and emergency change	Code review, test result, deployment approval, interface mapping validation
Security monitoring	Continuous collection with defined review and escalation intervals	ePHI access anomalies, integration failures, privileged actions
Vulnerability management	Scanning and remediation intervals set by policy and risk	Scan result, risk acceptance, ticket, closure evidence
Vendor oversight	Before onboarding and on a defined review cycle	Data access, BAA status, assurance report, renewal decision
Backup and recovery	Backup monitoring plus scheduled restore or recovery tests	Success logs, restored sample, recovery timing, lessons learned
Incident response	Every incident plus scheduled exercises	Timeline, containment, breach assessment, communications, corrective action

The written cadence defines the population the auditor may sample. A quarterly access review completed once during a six-month period produces two expected instances; a missed quarter is visible. An event-driven termination control needs a complete list of departures, not a folder containing selected screenshots.

Keep exceptions in the same evidence system. An overdue patch with a documented risk decision is easier to audit than a silent gap. The auditor needs to see what happened, who approved the response, when the issue closed, and whether the control design changed.

Control gaps that derail healthcare Type 2 readiness

Healthcare Type 2 readiness usually fails at the boundaries: an incomplete PHI flow, ungoverned support access, missing integration-change evidence, weak subprocessor oversight, or recovery plans that have never been tested. A buyer will not reject you because a policy is missing one sentence. They will reject you when the PHI path, a support console, or a clinic-side device is missing from the evidence.

EHR and API controls stop at the application

The team scopes the web application but omits interface engines, transformation logic, failed-message queues, integration secrets, and manual replay procedures. The fix is one integration inventory tied to change, access, logging, and incident controls.

Support access is broader than the policy admits

Engineers or customer-support staff can view production records through admin consoles, database tools, observability platforms, or exported tickets. Record each path, restrict it, log it, and include it in the access-review population.

Vendor files omit the contractual PHI boundary

A security review without the vendor’s data role, BAA status, services used, and downstream dependencies cannot answer the healthcare question. Keep those attributes in the vendor inventory and verify them before renewal.

Logs exist without an accountable review

Collecting logs is not the control if the narrative says alerts are triaged. Preserve the alert, investigation, disposition, and escalation decision. Test whether high-risk ePHI or privileged events reach the right reviewer.

Recovery evidence proves backup, not restoration

A successful backup job does not prove that the service can restore the data and dependencies customers rely on. Run a restore or recovery exercise, record the result, and feed failures into corrective work.

Connected devices and clinical-edge hardware sit outside the cloud boundary

Healthcare SaaS that talks to connected devices, remote-monitoring hardware, clinic kiosks, or clinician tablets often has strong cloud controls and weak edge controls. Device provisioning, update management, physical handling, and service-account restrictions get left out of the system description.

FDA treats cybersecurity as a lifecycle obligation for networked medical devices — authentication, authorization, confidentiality, and the ability to update and patch the device and related systems (FDA postmarket cybersecurity guidance). HIPAA already requires workstation and device/media safeguards for ePHI; the current Security Rule is the in-force legal baseline, and the 2024 cybersecurity proposal would add asset inventories and network maps that make those edge components visible.

If the product touches a device, kiosk, tablet, or clinic-side agent, put it in the boundary, the access-review population, and the change-management evidence. A SOC 2 report that only covers the cloud console will not answer a hospital’s question about how that device was provisioned or patched.

A healthcare SaaS Type 2 readiness plan

Healthcare SaaS teams should complete six stages: confirm obligations, define the service boundary, choose criteria, assess gaps, remediate controls, and run the Type 2 evidence period. Auditor selection should happen before the period so scope and testing expectations are settled.

1. Confirm the legal and buyer requirements. Document covered-entity or business-associate status, BAAs, customer security terms, requested report type, and any HITRUST requirement.
2. Approve the system and PHI boundary. Finish the service description, data-flow diagram, integration inventory, vendor inventory, and exclusions.
3. Choose the Trust Services Criteria. Tie each optional criterion to a contract, service commitment, risk, or procurement request.
4. Run a control and evidence gap assessment. Test real samples from access, changes, monitoring, vendors, incidents, and recovery — not policy presence alone.
5. Remediate and dry-run the populations. Assign owners, set cadences, configure evidence sources, close gaps, and test the exception workflow.
6. Start the observation period only when controls operate. Monitor missed instances and changes in scope throughout the period, then support fieldwork with complete populations.

Compliance software can centralize evidence, but the PHI and contract boundary matters more than the feature list. Compare the documented BAA and support evidence in the HIPAA compliance software directory, then use the healthcare SOC 2 software comparison for buyer-fit analysis.

If a hospital or payer names HITRUST in writing, treat that as a separate decision. The SOC 2 vs HITRUST guide owns the assessment-tier, scope, cost, and sequencing comparison.

Healthcare Type 2 timing and cost drivers

Healthcare Type 2 timing and cost depend on readiness, observation-period length, criteria, system complexity, locations, and integration scope. AICPA standards do not set a universal minimum observation period; buyer expectations and the evidence needed to support the opinion should drive the window.

First-time teams often use a three-, six-, or twelve-month observation period in practice. A short period can meet an immediate deadline, but a healthcare buyer may ask why the window is narrow or request a bridge letter sooner. Confirm acceptance before trading assurance depth for speed.

Budget separately for:

• CPA firm fees for the examination
• readiness support that remains independent from the auditor’s opinion
• compliance software or evidence infrastructure
• penetration testing and other specialist work
• remediation by engineering, IT, security, legal, HR, and operations
• HIPAA or HITRUST work outside the SOC 2 opinion

The broadest cost driver is the boundary. Multiple products, integrations, criteria, locations, and subprocessors create more control populations and more testing. Use the SOC 2 audit cost guide for current planning ranges rather than a single healthcare price that hides those variables.

Choosing a healthcare SOC 2 auditor

Choose a licensed CPA firm that can explain your healthcare system boundary, Type 2 populations, EHR integration risks, PHI-related confidentiality controls, and subprocessor evidence before quoting. Healthcare listed as an industry is weaker evidence than a specific scoping and testing method.

Ask each firm the same five questions:

1. Which healthcare SaaS systems and integrations would you include in our service boundary?
2. How will you test production support access and ePHI-related audit logs?
3. Which Trust Services Criteria fit our contracts, and which would you leave out?
4. How do you keep HIPAA assessment work separate from the SOC 2 opinion while reusing evidence?
5. Who performs fieldwork, and what population files must we produce?

Compare firms, pricing, and timelines in the healthcare SOC 2 auditor directory. If the engagement must include separate HIPAA work, use the narrower list of SOC 2 and HIPAA auditors.

A useful healthcare SOC 2 Type 2 report starts before fieldwork. Define the service honestly, map the PHI and integration boundary, choose criteria that match customer reliance, and make every recurring control produce evidence on schedule. The CPA opinion should describe the system buyers use, including its integration and support paths.