HITRUST vs SOC 2: Which Does a HealthTech Company Need?

SOC 2 is an attestation report on controls your organization defines, while HITRUST is a certification against a prescriptive, HIPAA-mapped framework, and your buyer's named requirement should decide which one you pursue first. The popular advice to pick the stronger badge gets this backward. Buyers don't accept badges in the abstract. They accept a specific report or certification, covering a specific production boundary, by a specific date.

HITRUST vs SOC 2 at a glance

A SOC 2 engagement is an examination by an independent licensed CPA under AICPA attestation standards. The AICPA SOC suite of services describes SOC 2 as evaluating controls relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy, with no universal control catalog or pass score. HITRUST issues certifications against the HITRUST CSF after a validated assessment, while the AICPA sets the attestation standards on the SOC 2 side.

The table below compares how each program is built, issued, scoped, judged, and kept current. The rows that carry the most weight are control basis, control set, and validity, because together they determine how much of your production environment, and which ePHI flows, land inside the assessed boundary. That boundary is the groundwork for healthcare compliance engineering decisions.

Dimension	SOC 2	HITRUST
Assurance model	Attestation report containing an auditor opinion	Certification issued after a validated assessment
Issuer	Independent licensed CPA under AICPA attestation standards	HITRUST, with an external assessor testing the controls
Control basis	Trust Services Criteria. Security, plus optional Availability, Processing Integrity, Confidentiality and Privacy	HITRUST CSF, mapped to HIPAA, NIST, ISO and other frameworks
Control set	Defined by the organization's system description and selected criteria	Generated from a risk-based questionnaire covering the organization's profile
Pass criteria	No universal pass score. The auditor reports exceptions	Required maturity rating met in each assessed domain, subject to limited exceptions
Output	Report with system description, testing period, exceptions and complementary user entity controls	Certification at e1, i1 or r2
Validity	Point in time (Type 1) or across an observation period (Type 2)	1 year for e1 and i1. 2 years for r2, with interim obligations
Typical request	Early-stage SaaS vendors and general enterprise security reviews	Large health systems and payers, often at r2

The short answer is sequencing. In Ekipa's view, SOC 2 is usually the earlier, narrower step, and HITRUST r2 is what large health systems and payers often request. Treat HITRUST vs SOC 2 as a sequencing question tied to named buyers and to which production systems carry ePHI into scope.

What each framework certifies and who issues it

How a SOC 2 report is built

Your organization writes the system description first. It defines the services, boundaries, infrastructure, software, people, and data in scope, and selects which Trust Services Criteria apply. Security, covered by the Common Criteria, is required in every report, and the other four categories are optional depending on what you commit to customers.

A Type 1 report gives the CPA's opinion on whether controls are suitably designed at a point in time. A Type 2 report adds operating effectiveness across an observation period. When the report arrives, buyers read the opinion, the system description, the tests and results, exceptions, subservice organizations, and complementary user entity controls your customer must operate. A clean opinion over a narrow system tells a buyer little about an EHR integration service that sits outside that description.

How a HITRUST certification is built

The introduction to HITRUST CSF v11.9.0 describes 14 control categories, 49 control objectives, and 156 control specifications, with each requirement mapped to a related framework, standard, or regulation. You don't copy a fixed checklist. HITRUST generates a requirement set after you complete a risk-based questionnaire covering your organizational, regulatory, and system profile.

In an r2 assessment, evidence has to address each generated requirement across five PRISMA-based maturity levels, from whether a policy and procedure exist to whether the control is implemented, measured, and managed. The e1 and i1 assessments focus on whether controls are implemented. Either way, architecture diagrams, IAM configuration exports, access reviews, and operating records must line up with the profile you submitted.

The same production environment can sit inside your SOC 2 description and outside your HITRUST boundary, or the reverse. Scope documents decide what either artifact proves.

The output also looks different. A vendor gives you a CPA report you read and challenge. HITRUST gives you a certification decision after central review of a validated assessment. For SaMD teams, that scoping work overlaps with the secure architecture and threat modeling expected in regulated software, which we cover under our SaMD engineering approach. Ekipa AI's SaMD cybersecurity work includes secure architecture design, data privacy practices, threat modeling, risk mitigation, and compliance with healthcare cybersecurity standards. Request the full report or certification scope statement. A summary letter alone doesn't show the boundary.

HITRUST assessment levels e1, i1 and r2

HITRUST offers three validated assessment levels, and the HITRUST Assurance Program Requirements set out each level's scope, requirement counts, and validity period.

Level	Requirements (approximate)	Validity	What it signals	Typical use
e1	About 44	1 year	Essentials baseline for the organization's cybersecurity practices	Early-stage vendors with a limited environment
i1	About 182	1 year	Implemented controls with evidence of current practices	Vendors with an established baseline moving into healthcare buyers
r2	Several hundred, matched to your profile	2 years, conditional on interim assessments	Risk-based assessment generated from your profile, with the largest requirement set	Large health systems and payers

Treat the counts as planning ranges, since the risk questionnaire that generates your requirement set can shift the final list.

Our view at Ekipa AI: the e1-to-i1 jump is where vendors underestimate the work. e1 checks that foundational practices exist, while i1 demands evidence that controls are implemented and operating. Every practice that passed on policy alone now needs records, a named owner, and walkthrough readiness, so budget for the evidence build, not just the assessor's fee.

The bar a validated assessment has to clear

Certification requires meeting the applicable CSF controls and reaching the domain rating threshold described in the comparison table, subject to limited exceptions and corrective-action requirements. The Assurance Program Requirements also require the assessor's submission to include a completed assessment object and a work plan identifying documentation reviewed, interviews conducted, technical configuration testing, results, and prior assessments used.

Assessors interview control owners directly and run walkthroughs with them. They don't accept a consultant or internal auditor as a proxy. Every requirement therefore needs a named person who can explain the control and produce records.

Keeping an r2 certification in force across its two years depends on interim-assessment and continuous-monitoring obligations. Let those lapse and the validity claim fails.

Moving from i1 to r2 changes the work materially. You get a larger requirement set generated from your environment, more evidence per requirement, more maturity levels to support, and more owners who must sit for interviews. Budget for evidence production and remediation, not only for the assessor.

Where SOC 2 and HITRUST overlap

Both programs examine logical access, change management, audit logging, incident response, risk assessment, and third-party management. If you build those controls well once, with records that name the system, owner, and date, you can present the same evidence in both programs with different mappings.

HIPAA sets the legal baseline underneath. The HIPAA Security Rule sits in 45 CFR Part 160 and Part 164, Subparts A and C, and 45 CFR 164.312 requires access controls that restrict ePHI-system access to authorized persons or software programs, plus audit controls that record and examine activity in systems containing or using ePHI. HITRUST CSF maps HIPAA requirements directly. A SOC 2 report doesn't establish HIPAA compliance by itself.

A hypothetical worked example

Say a hypothetical clinical SaaS vendor exchanges FHIR R4 Patient and Observation resources with a health system through a SMART on FHIR backend app.

• Step 1: A backend service account with a scoped IAM role calls the FHIR API. Engineering owns the role definition and credential rotation.

• Step 2: The audit log records each read and write with the client identifier, user context, resource type, and timestamp. Engineering owns logging configuration and retention.

• Step 3: A quarterly access review removes unused credentials and stale scopes. Compliance owns the review record and policy.

• Step 4: The health system owns its own user provisioning in the EHR. That's a complementary user entity control, stated in writing.

Those same records serve as SOC 2 Security evidence and as evidence for a HITRUST requirement mapped to HIPAA. One control, two mappings, no duplicate implementation.

The overlap stops at the boundary. If your analytics store, AI inference endpoint, or a Kubernetes cluster handling ePHI sits outside the described system, neither artifact says anything about it. Buyers who read scope statements will find that gap.

What hospital buyers ask for

Procurement packages follow a predictable pattern. Expect requests for a current SOC 2 Type II report or a HITRUST certification letter showing level, scope statement, and expiry date, plus a security questionnaire, a signed Business Associate Agreement, and penetration test summaries.

What buyers check in a SOC 2 report

• System boundary: Which production services, cloud accounts, and data stores the description covers.

• Subservice organizations: Which vendors are carved out, and whether their own reports are available.

• Testing period: How long the observation period ran and whether it covers current operations.

• Exceptions: What failed, how often, and what remediation followed.

• Complementary user entity controls: What the hospital must operate itself, such as user provisioning and access reviews on its side.

• PHI relevance: Whether protected health information sits inside the described system at all.

What buyers check in a HITRUST certification

Buyers confirm the assessment scope covers the production environment that handles ePHI, the certification is within its validity period, and interim assessments are current. An r2 certificate scoped to a corporate network doesn't answer questions about a clinical SaaS platform hosted elsewhere.

A buyer accepts either artifact only when its boundary includes the systems where ePHI actually flows.

That includes EHR integration services, HL7 v2 and FHIR interfaces, AI inference endpoints, analytics stores, and the cloud accounts hosting them. That is where healthcare integration and compliance work meets procurement reality. Apply one boundary test to every system. If ePHI enters it, it's in scope or you have a documented reason a buyer will accept.

Sequencing certification by company stage

Sequence it this way: each stage below produces evidence the next stage consumes, so a later program builds on records you already keep rather than restarting the audit. The trigger for each move is a named buyer asking for the next level. The scope follows whichever production systems carry ePHI. This is Ekipa's view, not a regulatory requirement.

1. Pilot or first design partner. Define the system description, data flows, and ePHI boundary. Document which HIPAA safeguards apply and run a readiness review against the Security criteria. The CTO owns the architecture and data flow diagram; the compliance lead owns the safeguard register. The deliverable is a boundary document both an assessor and a buyer's review team can read.

2. First paying health system. Complete a SOC 2 Type I, then a Type II over an observation period the buyer's review team will accept. Engineering owns logs and access records. Compliance owns policies, vendor reviews, and evidence collection. Keep every record in a form you can hand directly to an assessor, because the same evidence feeds a later HITRUST scoping exercise.

3. Repeated enterprise requests. Add HITRUST e1 or i1 where buyers ask for healthcare-specific assurance. Map each existing SOC 2 control to the HITRUST requirement it satisfies, which is the point of treating this as compliance engineering instead of a second audit project. On clinical software such as an AI assistant for clinic operations, that trail exists because the security work was built in: secure software architecture design, threat modeling, and risk mitigation from the start.

4. Large health system or payer requiring r2. Scope the assessment against the full production boundary, plan interim assessments across the two-year cycle, and assign an owner to each requirement area. The CTO owns configuration evidence. The compliance lead owns the assessment schedule and the assessor relationship.

Timing rules that set your schedule

Under HITRUST's assurance program requirements, testing for a validated assessment should occur within 90 days before submission, and controls, configurations, tools, policies, and procedures should generally have been operating or established for at least 90 days. A logging service you deploy this month, or an access policy you approved last week, may not produce usable evidence until that operating period passes.

Work backward from the buyer's contracting date. Add the operating period, the testing window, and remediation time. If the dates don't fit, tell the buyer early and offer the artifact you can deliver, with a dated plan for the next level.

Confirm the order with buyers before you commit

The order is set by two inputs: which assurance your named buyers ask for, and which production systems carry ePHI into scope. Run these six checks before anyone commits budget.

Check	Owner	Evidence
Confirm the assurance required	Founder or sales lead	Written procurement requirements
Map ePHI systems and vendors	CTO	Data flow diagram and subservice organization list
Confirm scope and boundary	Engineering lead	Signed scope document
Check windows and deadlines	Compliance lead	Dated timeline
Assign owners and evidence	CTO and compliance lead	Owner register
Budget renewals and remediation	CEO and CFO	Approved budget line

"Written procurement requirements" means a contract clause, an RFP line, or an email that names the assurance and the level. A verbal yes from a champion does not count. The subservice organization list matters because a SOC 2 report inherits carve-outs for your cloud and hosted vendors; if a vendor that touches ePHI sits outside the system description, the boundary is wrong before the assessment starts. The signed scope document freezes which products, environments, and data flows the assessment covers while engineering keeps shipping. The dated timeline lets you test the buyer's contracting date against your control operating period and the assessor's testing window before either side signs. The owner register and the budget line decide whether the program holds: every control carries a name, and renewal and remediation spend is approved before the cycle begins rather than discovered inside it.

Ekipa's view: choose SOC 2 for an early, narrowly scoped product whose buyers accept it. Choose HITRUST e1 or i1 when healthcare buyers name a standard healthcare assurance. Choose HITRUST r2 when large health systems or payers require it. Committing to r2 before any buyer asks for it, while your production boundary is still changing, usually wastes the assessment.

This article is general information, not legal or regulatory advice.

Conclusion

The sequence is correct when every artifact names the same target: the procurement requirement, the signed boundary, the dated timeline, the owner register, and the approved budget all point to one assurance for one defined production system. When they disagree, change the plan before an assessor tests a scope your buyers never asked for.

If you want help scoping the boundary or sequencing the work, book a consultation with Ekipa's HealthTech engineers.

For the steps to a first report, see our SOC 2 roadmap for HealthTech startups. For the HIPAA side of a hospital review, see the HIPAA compliant app development checklist and our guide to the business associate agreement for software vendors.

Frequently asked questions

Is HITRUST better than SOC 2?

Neither is better in the abstract. SOC 2 is a CPA attestation on controls you define, while HITRUST is a certification against a prescriptive framework mapped to HIPAA and other standards. The right first step is the one your named buyers ask for, covering the systems where ePHI flows.

Can SOC 2 controls be reused for HITRUST?

Yes, where the programs overlap. Access control, change management, audit logging, incident response, risk assessment, and vendor management records can support both, as long as each record names the system, the owner, and the date. HITRUST will still add requirements that SOC 2 does not cover.

How long is a HITRUST certification valid?

The e1 and i1 certifications are valid for one year. An r2 certification is valid for two years, provided the interim assessment and continuous monitoring obligations are met.

Does SOC 2 or HITRUST make a company HIPAA compliant?

No. HITRUST maps HIPAA requirements into its framework and a SOC 2 report can supply control evidence, but neither replaces your HIPAA obligations, such as the risk analysis, workforce training, breach notification duties, and business associate agreements.

What is the difference between HITRUST e1, i1, and r2?

They are increasing levels of assurance. e1 covers about 44 essential requirements, i1 about 182 implemented controls, and r2 a larger, risk-based set generated from your profile. Large health systems and payers most often ask for r2.