AI in Healthcare
HITRUST vs SOC 2: Which Does a HealthTech Company Need?
HITRUST vs SOC 2 for healthtech: assurance model, HITRUST e1, i1 and r2 levels, hospital buyer demands and the order to pursue them.
November 04, 2026Read more
Healthcare breaches took 279 days to identify and contain, compared with a 241 day global average, according to IBM's 2025 Cost of a Data Breach report. The engineering problem for SOC 2 for healthtech startups is proving, with records from production systems, that access, change, monitoring, and recovery controls work every week. This article compares Type I and Type II, sets out an ordered roadmap, helps you choose criteria, and maps the overlap with HIPAA.
Type I and Type II Reports Compared
SOC 2 is an attestation framework from the American Institute of Certified Public Accountants. The AICPA's 2017 Trust Services Criteria, revised in 2022, cover security, availability, processing integrity, confidentiality, and privacy for systems used to deliver services. A CPA examines your controls and issues a report, and the report's weight comes from that independent examination rather than a badge you display.
SOC 2 doesn't certify HIPAA compliance, and there's no official HIPAA certification. When a hospital or payer procurement team reviews a healthtech vendor, expect two items near the top of the checklist: a SOC 2 Type II report and a signed BAA. The BAA allocates HIPAA responsibilities, while the report gives independently evaluated evidence about controls. Building both into delivery from the start is part of compliance-ready software engineering, especially where your product touches protected health information, EHR integrations, claims data, or AI outputs used in clinical workflows.
What each report proves and when to use it
| Attribute | Type I | Type II |
|---|---|---|
| What it tests | Design of controls at a specific date | Design and operating effectiveness across an observation period |
| Observation window | Point in time | A typical window runs 3 to 12 months, agreed with the auditor |
| Evidence the auditor samples | Policies, system descriptions, configuration as of the review date | Recurring evidence such as access reviews, change approvals, backup restore tests and incident records |
| When buyers usually request it | Early evidence that controls exist | Hospital and enterprise procurement and security reviews |
| What must be ready first | Readiness work and closed design gaps | Controls running for the full observation window |
The row that decides a hospital review is the second one. Type II shows the control ran repeatedly during the window, so the sampled records need to span it: quarterly access reviews on systems storing PHI, change approvals on EHR and HL7/FHIR interface code, restore tests on databases holding patient data, incident tickets closed with root cause. If those records only exist for the month before the audit, the window isn't covered.
The typical path is readiness assessment, closing gaps, collecting evidence, Type I, then Type II. We recommend treating Type I as an interim marker only. A hospital reviewer who asked for Type II won't accept Type I as proof controls operated consistently, so use it to confirm the design holds before the observation window begins.
Step-by-Step Roadmap from Scoping to Type II
Start when a trigger makes the work unavoidable. Common triggers are a hospital or payer security questionnaire asking for SOC 2, a pilot that needs production access to PHI or clinical data, or a second EHR integration that widens your attack surface. Starting at that point still leaves time pressure, because Type II needs an observation window. Plan backward from the buyer's date.
Eight steps with owners and deliverables
Define the system boundary. The CTO and engineering lead list production applications, cloud accounts, EHR and payer interfaces, data stores, CI/CD pipelines, identity providers, support tooling, personnel, and subprocessors. The deliverable is a system description that names what's in scope and what's out. The AICPA Trust Services Criteria download describes the examination scope across security, availability, processing integrity, confidentiality, or privacy.
Select Trust Services Criteria. The CTO, working with compliance, starts with Security and adds other criteria only where customer commitments and data flows justify them. The deliverable is a signed scoping decision tied to contracts and questionnaires.
Build the control matrix. The compliance lead and engineering record each control's owner, frequency, population, evidence source, reviewer, exception process, and retention period. If any field is blank, the control isn't ready to operate.
Run a readiness assessment. An external reviewer or internal compliance lead tests design against the criteria in scope and produces a gap list ordered by risk. Don't let the same people who built a control grade it without challenge.
Remediate design gaps. Control owners close missing policies, broken access paths, unlogged interfaces, and untested restores, and they document controls that aren't running yet. The deliverable is evidence that each gap is closed: a resolved finding, a merged fix, or a restore test that passed.
Collect operating evidence. Control owners produce records on schedule during the window. Missing weeks can't be reconstructed credibly afterward.
Engage an independent CPA firm for Type I. Confirm its independence, ask which SaaS and healthcare clients it has examined, and agree the sampling approach before fieldwork. Management still owns control design and operation.
Operate through the Type II window. Controls run for the full period, commonly 3 to 12 months under standard attestation practice, while owners resolve exceptions as they occur. The deliverable is a complete, reviewable population for every sampled control.
The most common scoping failure is drawing the boundary around the application and leaving out systems that can reach PHI. Identity providers, cloud infrastructure, analytics platforms, support tools, AI APIs, and EHR connectors all need an explicit in or out decision, with a reason. A narrow scope that excludes the HL7 v2 interface engine or the FHIR API gateway will not survive a hospital review, because those components move the data buyers care about.
Controls to build first, with owners and audit evidence
| Control area | What to build | Owner | Evidence sampled |
|---|---|---|---|
| Identity and access | SSO, MFA, least privilege, access reviews pulled from the identity provider | Engineering lead with IT | Access review exports and approval records |
| Change management | Protected branches, pull request approval, deployment logs | Engineering lead | Approved pull requests and deployment records |
| Logging and monitoring | Centralized immutable logs and alerts that open tickets | Platform or SRE lead | Log retention settings and alert tickets |
| Backup and restore | Automated restore tests with recorded results | Infrastructure owner | Restore test reports |
| Incident response | Runbook, tabletop exercise, postmortems | CTO with security lead | Exercise reports and postmortems |
| Vendor risk | Subprocessor inventory, BAA status, review of vendor SOC reports | Operations or compliance lead | Vendor review records |
| Interface integrity | Mapping change control, reconciliation reports, rollback for HL7 v2 and FHIR changes | Integration engineering lead | Interface change tickets and reconciliation output |
| Encryption and key management | TLS for APIs, key rotation policy, KMS configuration | Platform lead | Configuration exports and key policy |
For interface integrity, treat an HL7 v2 ADT or ORU mapping change like a production code change. It needs review, a test against sample messages, reconciliation counts after deployment, and a rollback path. The same applies to FHIR R4 resource mappings, value set changes, and SMART on FHIR scope changes, where a wider scope can expose more patient data than the integration needs. Auditors sample these tickets because they show whether change control covers clinical data flows, not just application releases.
The evidence test
Apply one test to every record. Each sampled event should be attributable, time-stamped, reviewable, and linked to an approved policy or ticket. The AICPA page on description criteria for a SOC 2 report supports building that discipline into the system description. We recommend letting controls run for 90 to 180 days after remediation before you rely on the evidence for Type II. That range is a practical benchmark rather than an AICPA rule, and it prevents a window full of controls that started the week before fieldwork.
System-generated evidence beats screenshots. Pull access review populations directly from the identity provider, require pull request approval on protected branches, export immutable audit logs to centralized storage, and test backup restoration automatically rather than recording that a backup job finished. Population gaps, inconsistent review cadence, and undocumented exceptions cause more audit findings than missing policies do.
Third parties need the same treatment. A vendor's SOC 2 report doesn't show that you configured the vendor correctly, restricted its API keys, or limited the PHI you send it. Review cloud accounts, AI APIs, EHR vendors, observability platforms, and contractors against your own configuration evidence. If you evaluate tooling to collect this evidence, check that its exports match what your CPA firm will sample.
Where the product is SaMD, keep SOC 2 evidence separate from design and quality records, even when the same change tickets support both. Ekipa AI's SaMD technology and engineering support covers secure software architecture, threat modeling, risk mitigation, and regulatory compliance enablement for Software as a Medical Device products. For the wider method, see our post on compliance engineering.
A control that produces no record at the moment it runs will be hard to defend months later.
Use a simple go or no-go check before fieldwork. You want zero unresolved high-risk findings, full completion of scheduled control activities during the window, and a named owner for every in-scope control. These benchmarks sit with management rather than the auditor, and they're useful precisely because they're stricter than hoping sampling misses a gap.
Choosing Trust Services Criteria for Your Product
Security is the only mandatory criterion. It's also called the common criteria, and it covers control environment, risk assessment, logical access, system operations, change management, and monitoring. Every SOC 2 for healthtech startups program starts there. The other four add cost and evidence, so each one needs a reason rooted in your commitments. The AICPA publishes the criteria and related SOC 2 guidance.
Availability fits platforms clinicians depend on during care, such as scheduling, results delivery, or messaging tied to response times. It brings capacity planning, failover, backup, and recovery testing into scope. Don't select it if you can't show tested restores and a failover record.
Processing Integrity fits HL7 v2 and FHIR transformation layers. Mapping accuracy, schema changes, reconciliation, duplicate handling, and alert delivery determine whether records arrive complete and correct. If your product transforms clinical data, buyers will ask about this even if you leave the criterion out.
Confidentiality fits PHI and proprietary clinical or commercial data that contracts designate as confidential. It pushes you to classify data, control disclosure, and prove encryption and access limits follow that classification.
Privacy fits direct-to-patient products that collect health data from consumers. It needs documented purpose limitation, retention, deletion, consent, and data-subject request workflows. Selecting Privacy without those workflows operating is a predictable finding. A patient-facing product such as a clinic AI assistant is the kind of case where you'd test that decision carefully.
Choose criteria from customer commitments in contracts and security questionnaires, then check them against data flows inside your system boundary.
How SOC 2 Overlaps with HIPAA Technical Safeguards
One control matrix can satisfy both SOC 2 and HIPAA reviewers when every row names an owner, a population, and the record the system writes when the control runs. The HIPAA Security Rule technical safeguards in 45 CFR 164.312 require access control, audit controls, integrity protections, person or entity authentication, and transmission security for electronic PHI. The HHS page on HIPAA security laws and regulations states that access control allows access only for authorized people or software programs, and that audit controls record and examine activity in systems containing or using ePHI.
HIPAA technical safeguards mapped to SOC 2 evidence
| HIPAA safeguard | SOC 2 control area | Evidence to keep |
|---|---|---|
| Access control, 45 CFR 164.312(a)(1) | Logical access (CC6) | Quarterly access review exports, unique service accounts, role definitions |
| Audit controls, 45 CFR 164.312(b) | System monitoring (CC7) | Centralized, immutable application and database logs with retention settings |
| Integrity, 45 CFR 164.312(c)(1) | Change management (CC8) and processing integrity | Pull request approvals, deployment records, integrity monitoring alerts |
| Person or entity authentication, 45 CFR 164.312(d) | Logical access (CC6) | MFA enforcement reports and identity provider configuration |
| Transmission security, 45 CFR 164.312(e)(1) | Confidentiality and transmission controls | TLS configuration scans for APIs, HL7 v2 and FHIR endpoints, encryption decision records |
Encryption needs a documented decision either way. It is an addressable implementation specification, which means you assess whether it fits each data store and transmission path and write down the outcome. An undocumented addressable decision reads as a gap to both reviewers. The practical default for a healthtech startup: encrypt every backup volume and every API endpoint, put TLS on all HL7 v2 and FHIR traffic, and keep the KMS and TLS configuration exports that prove it. Where a legacy interface cannot be encrypted, document the compensating control and revisit that decision at each risk analysis.
Auditors sample interface evidence directly. Expect a request for an HL7 v2 message log, a FHIR API access trail, or the TLS scan output for the endpoint that carried the data. Ekipa AI works as a HealthTech engineering partner on EHR/EMR integrations and compliance-ready scaling, the category of work where this interface evidence sits inside the system boundary.
SOC 2 leaves real HIPAA obligations untouched: your risk analysis under 45 CFR 164.308, workforce training, breach notification duties, and the BAA you need with each business associate. A clean report supplies tested control evidence for a HIPAA program, and a hospital's privacy and legal reviewers will still ask for those items separately.
Conclusion
A buyer's procurement request, a pilot that needs production PHI, or a new EHR integration will set your start date. The roadmap puts scoping first either way, so begin there rather than with the audit calendar.
SOC 2 is an evidence system for production controls. Every control needs an owner, a defined population, and a record the system generates when the control runs. A control without that record is a policy statement. Auditors sample what the system produced, so build the discipline into identity, CI/CD, logging, and interface change control early, and the observation window becomes routine work instead of a separate project.
If you formalize one control this month, make it the access review. Export the user list from your identity provider, have each system owner confirm their team's accounts, and store the signed export with the review date. It is cheap to run, auditors sample it in nearly every engagement, and a clean first cycle shows the rest of the program what evidence is supposed to look like. We recommend starting there because it forces the owner, population, and record decisions every other control depends on.
Ekipa AI works with early-stage startups, scale-ups, and established healthcare technology companies on this kind of work, supporting SaMD teams from MVP development through interoperability and compliance-ready scaling.
For the HIPAA side of a hospital review, see our HIPAA compliant app development checklist, our guide to the business associate agreement for software vendors, and the HIPAA compliance audit guide. To build SOC 2 and HIPAA evidence into your product from the start, explore Ekipa's HealthTech engineering or book a consultation.
This article is general information, not legal or regulatory advice.
Frequently asked questions
Is SOC 2 a HIPAA certification?
No. HIPAA has no official certification, and SOC 2 is an AICPA attestation on controls. HIPAA technical safeguards sit in 45 CFR 164.312, and a clean report does not transfer risk analysis, workforce training, breach notification, or BAA duties to the auditor.
Can a startup sign a hospital contract with only a Type I report?
Sometimes. Treat Type I as a bridge toward a scheduled Type II: send it with a cover note that states scope, criteria covered, issue date, the exact Type II observation start and end dates, remediation status, and the owner for each open item. Do not promise a Type II date until fieldwork is scheduled.
How long must controls run before a Type II report?
There is no single fixed minimum. Observation windows commonly run 3 to 12 months and are agreed with your CPA firm. Whatever the length, each sampled control needs an owner, a defined population, and records produced on schedule for the full window.
Does SOC 2 cover FDA requirements for SaMD?
No. SOC 2 does not replace FDA quality system or software lifecycle obligations for SaMD. Keep design, verification, and postmarket evidence in your quality records, even where change tickets support both programs.
Which Trust Services Criteria are mandatory?
Only Security, the common criteria, is required in every SOC 2 report. Availability, Processing Integrity, Confidentiality, and Privacy are optional, so add them only when customer commitments or your data flows call for them, for example Availability for uptime commitments or Processing Integrity for clinical data transformations.
