HITRUST vs. SOC 2 Type II for Digital Health Founders: When Each One Matters

In September 2022, a Boston-based digital health startup, Series B, $34M raised, building a population health analytics platform, sent me a message at 11 PM IST. They had been in a health system enterprise procurement process for six months. The contract was $1.8M/year. The health system’s vendor security team had just sent a final questionnaire.

The questionnaire had one relevant line: “Please provide your HITRUST CSF Certification letter.”

Not SOC 2. HITRUST.

The startup had SOC 2 Type II. They had spent eight months and $87,000 getting it. Their SOC 2 report was 140 pages of carefully documented security controls. It was excellent work.

The health system did not want it. The health system’s enterprise procurement policy required HITRUST CSF Certification for any vendor handling patient data at population scale. SOC 2 was listed as “acceptable for vendors under 50,000 patient lives covered.” This vendor was being considered for a program covering 340,000 patient lives.

The contract was delayed fourteen months while they pursued HITRUST certification. They got the contract eventually. But fourteen months of delay on an $1.8M contract, with a sales team that had been working the account for six months, is an expensive sequencing mistake.

When I tell this story to digital health founders, and I tell it often, the reaction is almost always the same: “How do I know which one I need?”

The answer is not complicated. It is just not well-explained in most places. This guide is the explanation.

Eight Things Digital Health Founders Get Wrong About Compliance Certifications

• Wrong #1: “SOC 2 means we’re HIPAA compliant.”

SOC 2 Type II and HIPAA compliance are different things that overlap but do not substitute for each other. HIPAA is a federal law with specific requirements for Protected Health Information. SOC 2 is a voluntary auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates security controls against the Trust Services Criteria. A company can have SOC 2 Type II and still have significant HIPAA gaps. A company can be HIPAA compliant without having SOC 2. They measure different things.

• Wrong #2: “HITRUST is just a stricter version of SOC 2.”

HITRUST CSF is not a stricter version of SOC 2. It is a different framework, a comprehensive control framework that maps to 50+ regulatory requirements including HIPAA, NIST, ISO 27001, PCI-DSS, CIS, and others. HITRUST certification demonstrates control compliance across this multi-regulatory framework. SOC 2 evaluates controls against the AICPA’s Trust Services Criteria. The two certifications measure different control sets against different frameworks, with different audit processes and different market perceptions.

• Wrong #3: “We’ll get SOC 2 now and HITRUST later when we need it.”

This sequencing is correct for most early-stage digital health companies, but “when we need it” must be defined precisely. You need HITRUST when your enterprise customer’s procurement policy requires it, and you should know that policy before you start the sales cycle, not after you have invested six months of sales effort. Research your target buyers’ compliance requirements before deciding on sequencing.

• Wrong #4: “SOC 2 Type I is sufficient for enterprise sales.”

SOC 2 Type I is a point-in-time evaluation that assesses whether your controls are suitably designed. SOC 2 Type II is an evaluation over an observation period (minimum six months) that assesses whether your controls operated effectively. Enterprise health system procurement teams, health plans, and sophisticated healthcare buyers almost universally require SOC 2 Type II, not Type I. Type I is useful for demonstrating readiness. It is not sufficient for enterprise procurement.

• Wrong #5: “The SOC 2 audit starts when we engage the auditor.”

The SOC 2 Type II observation period, the period during which the auditor evaluates whether your controls operated effectively, must run before the auditor can issue the report. If you engage an auditor today and want a SOC 2 Type II report, you need at least six months of evidence of controls operating effectively. The observation period starts when your controls are in place and functioning, not when you engage the auditor. Start the observation period as early as possible.

• Wrong #6: “HITRUST takes too long for us to pursue.”

HITRUST Essentials (e1), the entry-level HITRUST certification, takes 3–6 months. HITRUST Implemented (i1) takes 6–9 months. HITRUST Comprehensive (r2) takes 12–18 months. The r2 is the full HITRUST CSF certification that large health systems require. It takes longer than SOC 2, but “too long” depends entirely on when you need it. If you are targeting large health system enterprise contracts twelve months from now, starting HITRUST today is not too long. Waiting until you are in the sales cycle is too late.

• Wrong #7: “Compliance automation tools do the work for us.”

Vanta, Drata, and Secureframe automate evidence collection, policy templates, and continuous control monitoring. They reduce the manual labor of compliance by 60–70%. They do not eliminate the need for actual security controls, documented policies, trained staff, or auditor engagement. A company that signs up for Vanta and expects to have SOC 2 in 90 days without implementing actual security controls will fail the audit.

• Wrong #8: “Our engineers can handle compliance.”

Security controls, policy documentation, risk assessments, and audit preparation require specific expertise that most engineering teams do not have. A compliance automation platform helps. A qualified security consultant or fractional CISO guides the implementation. Your engineering team implements the technical controls. All three are needed, one does not substitute for the others.

What SOC 2 Type II Actually Is, And What It Is Not

SOC 2 (Service Organization Control 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). It evaluates a service organization’s controls related to security, availability, processing integrity, confidentiality, and privacy, collectively called the Trust Services Criteria (TSC).

The five Trust Services Criteria:

• Security (CC, Common Criteria): Required for every SOC 2 report. Evaluates controls protecting the system against unauthorized access, both physical and logical. This is the foundation of SOC 2, every SOC 2 report must include the Security criteria.
• Availability (A): Optional. Evaluates controls ensuring the system is available for operation as committed. Relevant for digital health products where system availability affects patient care continuity.
• Processing Integrity (PI): Optional. Evaluates controls ensuring system processing is complete, valid, accurate, timely, and authorized. Relevant for digital health products that process clinical data where processing errors could affect patient outcomes.
• Confidentiality (C): Optional. Evaluates controls protecting confidential information, information designated as confidential by the organization or by agreement with customers. Relevant for digital health products handling proprietary health information.
• Privacy (P): Optional. Evaluates controls related to the collection, use, retention, disclosure, and disposal of personal information in conformity with the organization’s privacy notice and with criteria established by the AICPA. Relevant for patient data handling.

Most digital health companies pursue SOC 2 Type II covering Security + Availability + Confidentiality. The three-criteria combination is the most common for health tech B2B products and covers the core concerns of enterprise health system buyers.

SOC 2 Type I vs. Type II:

• SOC 2 Type I: Point-in-time evaluation. The auditor evaluates whether your security controls are suitably designed as of a specific date. Takes 2–4 months from control implementation to report issuance. Useful for demonstrating early-stage compliance readiness. Not sufficient for enterprise procurement.
• SOC 2 Type II: Period-of-time evaluation. The auditor evaluates whether your security controls operated effectively over an observation period, minimum six months, typically six to twelve months. The six-month observation period must run before the auditor can issue the Type II report. Required by enterprise health system buyers, health plans, and sophisticated healthcare buyers.

What SOC 2 evaluates:

The AICPA’s Trust Services Criteria are organized around control environment, risk assessment, control activities, monitoring, and logical access. For digital health companies, the controls that are most scrutinized in a SOC 2 audit:

• Logical access controls: how does the organization control who can access systems and data? Multi-factor authentication, access provisioning and deprovisioning, privileged access management, quarterly access reviews.
• Change management: how does the organization manage changes to systems and software? Change request and approval process, testing before production deployment, emergency change procedures.
• Risk assessment: how does the organization identify and manage security risks? Annual risk assessment, vulnerability management, penetration testing.
• Incident response: how does the organization respond to security incidents? Incident response plan, incident detection, incident response and communication procedures, post-incident review.
• Vendor management: how does the organization manage third-party service providers that handle customer data? Vendor risk assessments, contractual controls (BAAs, DPAs), ongoing vendor monitoring.
• Monitoring and alerting: how does the organization detect and respond to security events? Security event monitoring, alert configuration, log management and retention.

What SOC 2 does not evaluate:

SOC 2 does not evaluate specific HIPAA requirements, it does not assess whether you have a Business Associate Agreement process, whether you have completed a HIPAA risk analysis, or whether your ePHI is encrypted to HIPAA specifications. A SOC 2 audit evaluates your general security controls, which overlap significantly with HIPAA Security Rule requirements, but are not the same as HIPAA compliance.

SOC 2 does not evaluate clinical safety controls, it does not assess whether your AI product has hallucination guardrails, whether your clinical workflow has appropriate review steps, or whether your product is designed to support patient safety.

SOC 2 does not evaluate regulatory compliance, it does not assess FDA SaMD compliance, FTC compliance, or state health privacy law compliance.

From a US founder call: “I went into my first enterprise health system sale with our SOC 2 Type II report. I was confident. The health system’s CISO asked two questions in the first meeting: ‘Does your SOC 2 cover HIPAA-specific controls?’ and ‘Do you have a HITRUST certification or are you pursuing one?’ The SOC 2 covered our general security posture.

It did not specifically address HIPAA technical safeguards. And we had no HITRUST. We still got the contract, but we had to provide a HIPAA-specific security questionnaire response that took three weeks to prepare, and we committed to HITRUST within 18 months as a contract condition.

Know what your SOC 2 covers and what it does not before you walk into the enterprise sales room.”, Series A population health founder, NYC.

What HITRUST Actually Is, And What It Is Not

HITRUST (Health Information Trust Alliance) is a healthcare-specific security and privacy framework that was developed in 2007 specifically to address the compliance complexity facing healthcare organizations and their technology vendors.

The HITRUST CSF (Common Security Framework) is a comprehensive, prescriptive control framework that maps to over 50 regulatory and industry requirements including HIPAA, NIST SP 800-53, ISO 27001, PCI-DSS, GDPR, CIS Controls, and others.

• The three HITRUST certification tiers:

HITRUST Essentials (e1), Entry-Level: 19 control requirements. Focused on the most fundamental cybersecurity hygiene controls. Takes 3–6 months. Cost: $20,000–$50,000 in assessment fees plus internal preparation costs.

e1 is appropriate for: small digital health vendors in early-stage enterprise sales who need to demonstrate baseline cybersecurity posture. It is not the HITRUST certification that large health systems and payers require for PHI-handling vendors, that is r2.

HITRUST Implemented (i1), Moderate: Approximately 180 control requirements. Focuses on the most critical cybersecurity practices. Takes 6–9 months. Cost: $50,000–$120,000 in assessment fees plus internal costs.

i1 is appropriate for: mid-size digital health vendors in enterprise sales who need to demonstrate implemented security controls. Some mid-market health systems accept i1. Most large health systems require r2.

HITRUST Comprehensive (r2), Full Certification: Up to 375 control requirements (the specific number depends on the organization’s scope and risk factors, HITRUST’s scoping methodology adjusts the required controls based on organizational characteristics). Takes 12–18 months for first-time organizations. Cost: $80,000–$200,000+ in external assessment fees plus significant internal costs.

r2 is the certification that large health systems, large payers, and enterprise healthcare organizations require when they require HITRUST. When a procurement email says “HITRUST CSF Certification,” they mean r2 unless specifically stated otherwise.

• What HITRUST evaluates that SOC 2 does not:

HITRUST’s control framework maps specifically to healthcare regulatory requirements, HIPAA Privacy Rule, HIPAA Security Rule, HITECH, and others. The r2 assessment evaluates:

HIPAA-specific controls: workforce training and awareness, risk analysis and risk management, business associate agreements, incident response specific to ePHI breaches, audit controls and logging, encryption of ePHI at rest and in transit.

Physical safeguards: facility access controls, workstation security, device and media controls, evaluated in more detail than SOC 2.

Organizational controls: policies and procedures, security governance, security program management, evaluated with healthcare-specific content requirements.

Control maturity scoring: HITRUST does not just evaluate whether a control is present, it evaluates the maturity of control implementation on a five-level maturity scale. A control can exist (Level 1) but be poorly implemented (not Level 3) or inconsistently applied (not Level 4). The maturity scoring creates a richer picture of security program quality than SOC 2’s binary pass/fail evaluation.

• The HITRUST assessment process:

Unlike SOC 2, HITRUST uses a validated assessment approach with two parties: the organization undergoing assessment (the “assessed entity”) and a HITRUST-authorized external assessor. The process:

1. Scoping: HITRUST’s scoping tool generates the specific control requirements applicable to your organization based on organizational factors (size, system type, regulatory environment, etc.) 
2. Self-assessment: the organization completes a detailed self-assessment in HITRUST’s MyCSF platform, documenting evidence for each required control 
3. External assessor validation: a HITRUST-authorized assessor validates the self-assessment, testing controls, reviewing evidence, and identifying gaps 
4. HITRUST quality review: HITRUST’s own quality assurance team reviews the assessor’s validated assessment before certification is issued 
5. Certification (or corrective action): HITRUST issues the certification letter if all required controls meet the minimum maturity threshold, or issues a corrective action plan if controls fall below threshold

The HITRUST quality review step, unique to HITRUST among major compliance certifications, adds 4–8 weeks to the timeline but provides a level of third-party validation rigor that SOC 2 audits do not include.

• HITRUST inheritance:

A distinctive feature of the HITRUST framework is inheritance, the ability to inherit control validation from your cloud infrastructure provider or from other shared service providers that are HITRUST-certified.

AWS, Azure, and Google Cloud are all HITRUST-certified. When you build on their infrastructure, you can inherit their HITRUST control validations for infrastructure-level controls rather than re-validating them from scratch.

Inheritance reduces the number of controls you must independently validate, which reduces the time and cost of your own HITRUST assessment. For digital health companies on AWS, inheritance can reduce the assessed control count significantly for infrastructure-related domains.

Red flag: Any HITRUST assessor who does not mention inheritance as part of their scoping engagement is leaving significant cost savings on the table. AWS’s HITRUST-certified infrastructure covers a meaningful portion of the infrastructure controls in an r2 assessment. Understand your inheritance options before scoping your assessment effort.

The 14-Question Compliance Readiness Audit

• Who are your target enterprise customers, and what compliance certifications do they require?

Research your specific target buyers before deciding on certification sequencing. A community hospital system may accept SOC 2. A Blue Cross Blue Shield plan may require HITRUST. A large academic medical center may require both. Know before you decide.

• How many patient lives will your product cover at your target customers?

Many health system HITRUST requirements are triggered by scale, vendors covering over 50,000 or 100,000 patient lives in enterprise programs are more frequently required to have HITRUST. Know the patient population thresholds in your target buyer’s vendor risk policy.

• What is your current security posture, do you have the foundational controls in place?

SOC 2 and HITRUST both require that security controls are actually implemented, not just documented. Assess your current posture: MFA everywhere, access controls, change management, incident response, vulnerability management, vendor management. Gaps must be closed before the observation period or assessment, not during it.

• What is your compliance automation platform?

Vanta, Drata, or Secureframe for SOC 2. HITRUST requires MyCSF (HITRUST’s own platform) for the assessment, compliance automation tools can support preparation but not replace MyCSF for the HITRUST assessment itself.

• Do you have a qualified auditor engaged?

SOC 2: a licensed CPA firm with SOC 2 experience in healthcare technology. HITRUST: a HITRUST-authorized external assessor. Both require early engagement, auditors have scheduling queues, and the best healthcare-specialist auditors book 3–6 months in advance.

• What is your SOC 2 observation period start date?

If you have not started your SOC 2 observation period, your Type II report date is at least six months away regardless of when you engage an auditor. Start the clock as soon as your controls are in place.

• Do you have documented policies for all SOC 2/HITRUST required domains?

Policy documentation is the foundation of both certifications. The required policies: information security policy, access control policy, change management policy, incident response policy, risk assessment policy, vendor management policy, acceptable use policy, data classification policy, business continuity and disaster recovery policy. These must be written, reviewed, approved, and actively followed, not filed away.

• Do you have a completed risk assessment?

Both SOC 2 and HITRUST require a formal risk assessment. For SOC 2: the risk assessment must demonstrate that you have identified risks to the systems in scope and implemented controls to address them. For HITRUST: risk analysis is a specific control domain with detailed requirements aligned to HIPAA’s risk analysis requirement.

• Do you have a penetration test from the last 12 months?

Annual penetration tests by a qualified third-party firm are expected by both SOC 2 auditors and HITRUST assessors. The penetration test report is evidence, it demonstrates that you have tested your controls against real attack scenarios and remediated findings.

• What is your vendor management program?

Both certifications require documented vendor risk management, inventorying third-party vendors that handle customer data, conducting risk assessments of those vendors, ensuring contractual controls (BAAs, DPAs, security addendums), and monitoring vendor security posture on an ongoing basis. Many digital health companies have weak vendor management programs, this is a common audit finding.

• What is your access review cadence?

Quarterly access reviews, systematic review of who has access to which systems, removal of access for departed employees or changed roles, are expected by both SOC 2 auditors and HITRUST assessors. Ad-hoc access reviews that happen when someone leaves are insufficient.

• What is your security training program?

Annual security awareness training for all employees is expected by both certifications. For HITRUST, healthcare-specific training, HIPAA awareness, handling of ePHI, is required. Training completion must be tracked and documented.

• What is your incident response program?

A documented incident response plan, regular tabletop exercises, and documented incident response records (even for minor incidents) are expected by both certifications. An incident response plan that exists in a document but has never been tested is a finding.

• Have you scoped your certification boundary correctly?

The certification scope defines which systems, services, and organizational units are in scope for the certification. A scope that is too broad is expensive, you must validate controls for everything in scope. A scope that is too narrow is commercially problematic, enterprise customers want to know your production systems are in scope, not just your internal IT. Define scope with your auditor or assessor before beginning preparation.

SOC 2 Type II, The Complete Playbook for Digital Health

• The SOC 2 Trust Services Criteria most relevant to digital health:

The Security (Common Criteria) category, required in every SOC 2, is organized into nine control categories (CC1 through CC9). The controls most scrutinized in digital health SOC 2 audits:

CC6, Logical and Physical Access Controls: The highest-scrutiny category for digital health SOC 2. Controls evaluated: user authentication (MFA required for all systems with access to customer data), access provisioning (formal process for granting access), access deprovisioning (timely removal when employees leave or change roles), privileged access management (elevated access with additional controls), access reviews (quarterly at minimum), and physical access controls.

The most common findings in digital health SOC 2 audits are in CC6: terminated employees with active system access discovered during audit, shared accounts (violating the unique user identification requirement), or inadequate evidence of quarterly access reviews.

CC7, System Operations: Monitoring and detecting security events. Controls evaluated: security event monitoring and alerting, vulnerability management (regular scanning, timely remediation), malware protection, change management (formal process for system changes), and backup and recovery testing.

CC8, Change Management: Controls over software development and infrastructure changes. For digital health SaaS products, change management is typically evaluated through CI/CD pipeline controls, required code review, automated testing, staging environment testing, and documented approval before production deployment.

CC9, Risk Mitigation: Vendor risk management and business interruption risk management. The vendor management program is evaluated here, how you identify, assess, and monitor third-party service providers that handle customer data.

• The SOC 2 auditor selection for digital health:

Not all SOC 2 auditors have healthcare experience. For a digital health SOC 2, you want an auditor who:

• Has audited other digital health or healthcare technology companies
• Understands HIPAA requirements and how they relate to SOC 2 controls
• Knows the common control gaps in digital health products (HIPAA BAA programs, ePHI handling, audit trail requirements)
• Can provide healthcare-specific guidance on control design, not just generic SOC 2 guidance

Healthcare-experienced SOC 2 auditors we have worked with or whose work we have seen in client engagements: A-LIGN, Schellman, Prescient Assurance, Coalfire, Johanson Group. These firms have healthcare practices with auditors who have seen hundreds of digital health SOC 2 audits and know where the bodies are buried.

• The compliance automation platform decision:

Vanta, Drata, and Secureframe are the three dominant SOC 2 compliance automation platforms in 2026. All three provide: automated evidence collection from cloud providers and SaaS tools, policy templates, control monitoring, and auditor-ready reports.

For early-stage digital health companies (under $20M ARR): Vanta is our most common recommendation, strong integrations with AWS, GCP, Azure, GitHub, Google Workspace, and the SaaS tools most digital health startups use. Pricing: $12,000–$25,000/year depending on employee count and integrations.

For Series B+ digital health companies with more complex environments: Drata offers more customization and has stronger enterprise features. Pricing: $20,000–$50,000/year.

For companies that already have Salesforce or ServiceNow in their stack: Secureframe has stronger integrations with enterprise tooling.

None of these platforms replace the auditor. They reduce the evidence collection burden and organize the audit process. The auditor still conducts independent testing and issues the report.

• The SOC 2 observation period strategy:

The six-month observation period is the single biggest timeline driver for SOC 2 Type II. Every month you delay starting the observation period is a month you push out your Type II report date.

Start the observation period the moment your controls are in place, do not wait for the auditor to be engaged, do not wait for the compliance automation platform to be fully configured, do not wait for all policies to be perfectly written. Get your controls to a functional state and start the clock.

Common mistakes that restart the observation period clock: a control goes down (MFA is disabled for a period, an access review is missed, a terminated employee retains access for more than a defined period), depending on the severity and duration, the auditor may extend the required observation period or qualify the report.

• The SOC 2 Type II report structure:

The SOC 2 Type II report has four sections:

Section 1, Auditor’s opinion: the auditor’s assessment of whether controls were suitably designed and operated effectively over the period. This is the section your customers care about most, a qualified opinion (controls were not suitably designed or did not operate effectively) is damaging commercially.

Section 2, Management’s description of the system: your own description of your product, your security controls, and your compliance program. This section is written by you and reviewed by the auditor.

Section 3, Control criteria and controls: the Trust Services Criteria being evaluated and the specific controls you have implemented to address each criterion.

Section 4, Tests of controls and results: the auditor’s description of the tests performed and the results. Exceptions (controls that did not operate effectively for specific test instances) are listed here. A small number of minor exceptions with adequate explanation is generally acceptable. A large number of exceptions or exceptions in critical controls is commercially problematic.

• The management letter vs. the full report:

Enterprise customers typically request your SOC 2 Type II report under a Non-Disclosure Agreement (NDA). Some customers request the full report, all four sections. Some request a summary letter that confirms certification without the full control detail.

Prepare both. Have a summary letter template ready that confirms your SOC 2 Type II certification, scope, and period, that you can send to customers who prefer the abbreviated version without the full control detail.

HITRUST CSF, The Complete Playbook for Digital Health

• The HITRUST r2 assessment process in detail:

Step 1: Scoping (Month 1)

HITRUST’s MyCSF platform generates the list of required controls based on your organization’s scoping factors, system type (SaaS, cloud, desktop), number of individuals whose data is processed, regulatory environments (HIPAA, PCI, state laws), and other organizational characteristics.

For a typical digital health SaaS company processing ePHI for enterprise health system customers: the r2 scoping results in approximately 250–375 required controls across 19 control domains.

Scoping is not a one-time activity, changes to your product, your customer base, or your regulatory environment can change the required controls. Scope annually or when significant organizational changes occur.

Step 2: Gap Assessment (Months 1–3)

Before beginning the formal self-assessment, conduct a gap assessment, comparing your current security controls against the HITRUST required controls to identify where you are compliant, where you have partial compliance, and where you have gaps.

The gap assessment drives your remediation roadmap. Gaps in required controls must be remediated before you can achieve a passing score in the formal assessment.

Many organizations engage their HITRUST-authorized assessor for the gap assessment, the assessor who will conduct the formal validation is also the one who identifies the gaps to be closed. This creates efficiency: the assessor understands your environment before the validation begins, and you know what you need to fix before you commit the full assessment fee.

Step 3: Remediation (Months 2–8)

Closing the gaps identified in the gap assessment. Remediation is where the actual security control implementation work happens, or where controls that exist but are poorly documented are properly documented.

Common remediation activities for digital health companies:

Workforce training enhancement: HITRUST requires healthcare-specific security training, HIPAA awareness, ePHI handling, social engineering defense. Many companies have generic security training but not healthcare-specific content.

Policy updates: HITRUST’s policy requirements are more specific than SOC 2’s. Each control domain has specific policy content requirements. Existing policies often need to be updated to address HITRUST-specific requirements.

Technical control implementation: vulnerability management processes often need enhancement, HITRUST has specific requirements around scanning frequency, remediation timelines by severity, and documentation. Change management processes may need formalization. Logging and monitoring may need to be enhanced to meet HITRUST’s specific evidence requirements.

Step 4: Self-Assessment in MyCSF (Months 6–9)

The formal self-assessment is completed in HITRUST’s MyCSF platform. For each required control, you document: the implemented control, the maturity level (1–5), and the evidence supporting your maturity claim.

The self-assessment is time-intensive, a typical r2 self-assessment takes 200–400 hours of internal staff time. Compliance automation tools can reduce this effort by organizing evidence before it goes into MyCSF, but the MyCSF data entry and documentation work is significant.

Step 5: External Assessor Validation (Months 9–12)

The HITRUST-authorized external assessor validates your self-assessment. Validation involves: document review, evidence testing, and interviews with control owners. The assessor submits their validated assessment to HITRUST.

Step 6: HITRUST Quality Review (Months 12–14)

HITRUST’s quality assurance team reviews the validated assessment. This is the step that distinguishes HITRUST from SOC 2, HITRUST itself reviews the assessor’s work before certification is issued. The quality review takes 4–8 weeks.

Step 7: Certification or Corrective Action Plan

HITRUST issues either:

• A HITRUST CSF Certification letter (valid for two years, with an interim assessment at 12 months)
• A Corrective Action Plan (CAP) if controls do not meet the required maturity threshold, the organization must remediate and resubmit

HITRUST certification is valid for two years. At 12 months, an interim assessment must be conducted to confirm controls remain in place. At 24 months, a full r2 assessment must be completed for recertification.

• The 19 HITRUST CSF control domains:

The r2 assessment covers all 19 control domains. The domains most relevant to digital health companies:

Domain 01, Information Protection Program: security governance, risk management, compliance management

Domain 02, Endpoint Protection: malware protection, configuration management, mobile device management

Domain 03, Portable Media Security: encryption of portable media, removable device controls

Domain 05, Mobile Device Security: mobile app management, mobile data protection

Domain 06, Wireless Protection: wireless network security

Domain 07, Configuration Management: system hardening, baseline configurations, change management

Domain 08, Vulnerability Management: vulnerability scanning, penetration testing, patch management

Domain 09, Network Protection: network segmentation, firewall management, intrusion detection

Domain 10, Transmission Protection: encryption in transit, secure email, certificate management

Domain 11, Password Management: password complexity, MFA, privileged account management

Domain 12, Access Control: user access management, access reviews, least privilege

Domain 13, Audit Logging and Monitoring: log management, security event monitoring, audit log retention

Domain 14, Education, Training, and Awareness: security training program, role-specific training, HIPAA awareness

Domain 15, Third-Party Assurance: vendor risk management, Business Associate Agreement management, supplier assessments

Domain 16, Incident Management: incident response planning, incident detection and response, breach notification

Domain 17, Business Continuity and Disaster Recovery: BCP/DRP planning, testing, and maintenance

Domain 18, Risk Management: risk assessment methodology, risk treatment, risk monitoring

Domain 19, Physical and Environmental Security: facility access controls, environmental controls, equipment security

• HITRUST and AWS inheritance:

AWS has achieved HITRUST r2 certification for its cloud services. For digital health companies on AWS, you can inherit HITRUST control validations for AWS-managed infrastructure controls, reducing the number of controls you must independently validate.

The controls available for inheritance from AWS: infrastructure-level controls in domains 02 (endpoint protection for AWS-managed endpoints), 06 (wireless protection at AWS facilities), 09 (network protection for AWS network infrastructure), 10 (transmission protection for AWS network layer encryption), 17 (business continuity and disaster recovery for AWS infrastructure), and 19 (physical and environmental security at AWS data centers).

Inheritance does not eliminate your responsibility for controls, it means you can rely on AWS’s validated controls for the infrastructure layer without re-testing them. You still own the controls at the application layer.

How to use inheritance: AWS provides a HITRUST Inheritance Package through the AWS Artifact portal. Your HITRUST-authorized assessor configures the inheritance in MyCSF. The AWS-validated controls are reflected in your assessment without requiring your own evidence.

SOC 2 vs. HITRUST, The Direct Comparison

Dimension	SOC 2 Type II	HITRUST r2
Issuing body	AICPA (American Institute of CPAs)	HITRUST Alliance
Framework basis	Trust Services Criteria (AICPA)	HITRUST CSF (maps to 50+ regulations including HIPAA)
Healthcare-specific?	No, general security framework	Yes, designed specifically for healthcare
HIPAA-specific controls?	Partial overlap, not HIPAA-specific	Explicit HIPAA control mapping
Control count	~60–100 controls depending on criteria selected	250–375 controls (r2, scope-dependent)
Audit type	External auditor opinion	External assessor validation + HITRUST QA review
Observation period	6–12 months (Type II)	Not applicable (point-in-time with ongoing requirements)
Certification validity	Annual renewal	2 years (with 12-month interim assessment)
Time to first certification	9–15 months (Type II)	12–18 months (r2)
First-time cost (external)	$30,000–$80,000 auditor fees	$80,000–$200,000 assessor fees
Annual maintenance cost	$20,000–$45,000	$40,000–$80,000
Compliance automation tools	Vanta, Drata, Secureframe	MyCSF (required) + supporting tools
Market recognition	Universal, accepted by all enterprise buyers	Required by large health systems and payers
When enterprise buyers require it	Always required; baseline expectation	Required for high-volume PHI vendors; large health system procurement
Inheritance from cloud providers	Limited (auditor evaluates your controls)	Significant (AWS/Azure/GCP HITRUST inheritance available)
Maturity scoring	Pass/fail per control	1–5 maturity level per control
Report format	Auditor’s report (sharable under NDA)	Certification letter + validated assessment report

The Sequencing Decision, Which One First, When, and Why

The sequencing decision is the most practically important decision in this guide. Here is the framework I give every digital health founder.

• Start with SOC 2 Type II if:

Your first enterprise customers are: mid-market health systems (under 200 beds), independent physician groups, digital health companies, employer health plans, or value-based care organizations. These buyers almost universally accept SOC 2 Type II as their primary compliance requirement.

Your product covers fewer than 50,000 patient lives per customer. At this scale, most enterprise buyers’ vendor risk policies require SOC 2, not HITRUST.

You have less than 18 months of runway. HITRUST r2 takes 12–18 months. If you need compliance credentialing within 9–12 months to close enterprise deals, SOC 2 is the realistic option.

You are pre-Series A or early Series A. The $30,000–$80,000 external cost for SOC 2 is manageable. The $80,000–$200,000+ external cost for HITRUST r2 requires Series A funding and beyond.

You are building compliance infrastructure for the first time. SOC 2 builds the compliance foundation, policies, controls, vendor management, access reviews, that HITRUST builds on. Doing HITRUST without the SOC 2 foundation is like building the second floor before the first.

• Start with HITRUST if:

Your target customers are: large health systems (300+ beds), large regional Blue Cross Blue Shield plans, large national payers (Aetna, UnitedHealth, Cigna, Humana), or federal healthcare programs. These buyers frequently require HITRUST for vendors handling population-scale ePHI.

Your product covers 100,000+ patient lives per customer at target enterprise customers. At this scale, HITRUST is frequently required by buyer procurement policy.

You are directly targeting health system enterprise sales and the health systems in your pipeline have told you HITRUST is required. Do not assume, ask early in the sales process.

You have 18+ months of runway and Series A or B funding. HITRUST is a well-funded compliance investment, not an early-stage expense.

You are in a specific high-sensitivity clinical AI or population health category where the largest buyers consistently require HITRUST regardless of patient lives covered.

• The most common sequence for digital health startups:

Phase 1 (months 1–12): SOC 2 Type II Build the compliance foundation. Implement security controls. Start the observation period. Get the SOC 2 Type II report. Use it to close early enterprise deals and build the compliance credibility for Series A.

Phase 2 (months 12–30): HITRUST r2 With Series A or B funding, begin the HITRUST r2 journey. The SOC 2 controls provide 60–70% of the HITRUST control foundation. Gap assessment identifies what additional controls are needed. Assessment conducted, certification achieved. Required for the largest health system and payer enterprise deals.

Ongoing: Maintain both SOC 2 Type II annual renewal and HITRUST biennial renewal with 12-month interim assessment. Both are maintained as complementary credentials for the full range of enterprise buyers.

• The “both simultaneously” option:

For well-funded Series B+ companies with a CISO and a compliance team, pursuing SOC 2 and HITRUST simultaneously is possible. The controls overlap significantly, building the SOC 2 control framework and extending it to meet HITRUST requirements in parallel saves time compared to sequential certification.

This requires: a compliance-experienced CISO or fractional CISO, a HITRUST-authorized assessor engaged from the beginning, Vanta or Drata for SOC 2 evidence collection alongside MyCSF for HITRUST, and 18+ months of focused organizational effort.

For most startups below Series B: do not attempt both simultaneously without dedicated compliance leadership. The parallel effort is organizationally demanding and the cost is high.

From a US founder call: “I asked every health system in my Series A pipeline whether they required HITRUST. Eight out of ten said SOC 2 was sufficient for initial vendor approval. The two that required HITRUST were both systems over 500 beds, one regional Blue Cross Blue Shield and one large academic medical center. I got SOC 2 first.

Closed the eight deals. Used the revenue to fund the HITRUST journey. Closed the two HITRUST-required deals eighteen months later. Sequencing based on actual buyer requirements, not theoretical compliance aspiration, was the right call.”, Series B population health analytics founder, Boston.

The Architecture That Supports Both

The security controls that support SOC 2 and HITRUST overlap significantly. Building the architecture correctly from Day 1, so that the controls you implement for SOC 2 are also HITRUST-compatible, reduces the incremental cost and effort of the HITRUST certification.

• The shared control foundation:

Multi-factor authentication everywhere: Required by both SOC 2 (CC6.1) and HITRUST (Domain 11). MFA must be enforced for all administrative access, all access to systems containing customer data, and all remote access. Enforcement means technical enforcement, not policy-only. Users cannot disable MFA. Cloud console access, SSH access, VPN access, SaaS application access, all require MFA.

Quarterly access reviews: Required by both SOC 2 (CC6.2) and HITRUST (Domain 12). Every user’s access to every system containing customer data is reviewed quarterly. Access that is no longer needed is revoked within a defined SLA. Review is documented, who reviewed, when, what access was confirmed or revoked.

Encryption at rest and in transit: Required by both SOC 2 (CC6.7) and HITRUST (Domain 10). AES-256 for all data at rest. TLS 1.2+ for all data in transit. For digital health companies handling ePHI: this is also a HIPAA technical safeguard requirement (§164.312(a)(2)(iv) and §164.312(e)(2)(ii)).

Vulnerability management: Required by both SOC 2 (CC7.1) and HITRUST (Domain 08). Regular vulnerability scans (weekly or monthly depending on system criticality), penetration test annually, documented remediation timelines by vulnerability severity, evidence of remediation.

Change management: Required by both SOC 2 (CC8.1) and HITRUST (Domain 07). Formal change request and approval process, testing before production, code review requirements, emergency change procedures. For digital health SaaS: implemented through CI/CD pipeline controls.

Incident response: Required by both SOC 2 (CC7.3) and HITRUST (Domain 16). Documented incident response plan, regular tabletop exercises, documented incident records. For digital health companies: HIPAA breach notification procedures must be integrated into the incident response plan.

Vendor management: Required by both SOC 2 (CC9.2) and HITRUST (Domain 15). Vendor inventory, risk assessments, contractual controls (BAAs, security addendums), ongoing monitoring. For digital health companies: the BAA registry from HIPAA compliance is the foundation of the vendor management program.

Security awareness training: Required by both SOC 2 and HITRUST (Domain 14). Annual training for all employees. For HITRUST: healthcare-specific content required, HIPAA awareness, ePHI handling, social engineering targeting healthcare organizations.

• The HITRUST-specific controls that SOC 2 does not cover:

Mobile device management: HITRUST Domain 05 requires formal mobile device management, MDM policy, device enrollment, remote wipe capability, screen lock enforcement. SOC 2 covers endpoint protection generally but not MDM specifically.

Portable media security: HITRUST Domain 03 requires encryption of removable media and portable devices. SOC 2 covers data protection generally.

Physical security documentation: HITRUST requires more detailed physical security documentation than SOC 2, facility access controls, visitor logs, physical security assessment. For cloud-native companies, much of this is inherited from the cloud provider.

HIPAA-specific risk analysis: HITRUST Domain 18 requires a risk analysis that specifically addresses HIPAA threats and vulnerabilities. SOC 2 requires a general risk assessment.

Healthcare-specific training content: HITRUST Domain 14 requires training that explicitly covers HIPAA, ePHI handling, and healthcare-specific threats. Generic security awareness training is insufficient.

• Building for both from Day 1:

When implementing the security controls for SOC 2, implement them at the level of specificity that will also satisfy HITRUST:

Write your access control policy to HITRUST’s specificity requirements, not just SOC 2’s. Include mobile device management policy from the beginning. Include HIPAA-specific content in your security training from the beginning.

Build your vendor management program to include BAA tracking and healthcare-specific risk assessments from the beginning. Implement HITRUST’s more specific logging and monitoring requirements rather than SOC 2’s minimum.

The incremental cost of implementing HITRUST-compatible controls versus SOC 2-minimum controls is modest, perhaps 20–30% more effort in the initial implementation. The alternative is rebuilding your control framework when you start the HITRUST journey, which costs 60–80% more effort.

The Real Cost Stack in 2026

• SOC 2 Type II costs:

Compliance automation platform: Vant$12,000–$25,000/year Drat$20,000–$50,000/year Secureframe: $15,000–$35,000/year

External auditor fees: Early-stage (under 50 employees, limited scope): $18,000–$35,000 Mid-size (50–150 employees, moderate scope): $35,000–$60,000 Larger (150+ employees, broad scope): $60,000–$100,000

Healthcare-specialist auditors (A-LIGN, Schellman, Prescient Assurance) typically charge 15–25% more than generalist auditors, but the healthcare-specific experience is worth the premium for digital health companies.

Preparation consulting (fractional CISO or compliance consultant): $3,000–$8,000/month for 4–6 months of preparation: $12,000–$48,000

Penetration test: $8,000–$22,000 (annual; required for both SOC 2 and HITRUST)

Policy documentation (if starting from scratch): $5,000–$15,000 with a compliance consultant

Internal staff time: 50–150 hours of engineering and operations staff time for control implementation and evidence preparation

Annual renewal: Auditor fees: $15,000–$40,000 Compliance platform: $12,000–$50,000/year ongoing Penetration test: $8,000–$22,000 annually

Total SOC 2 Type II first-year cost: $65,000–$200,000 depending on company size, auditor selection, and baseline security posture.

• HITRUST r2 costs:

HITRUST MyCSF subscription: $10,000–$25,000/year depending on organization size

External assessor fees (r2): Small organization (under 100 employees): $60,000–$100,000 Mid-size organization (100–500 employees): $100,000–$160,000 Larger organization (500+ employees): $150,000–$250,000+

Gap assessment (pre-assessment): $15,000–$35,000 (often conducted by the assessor as a separate engagement before the formal assessment)

Remediation consulting: $6,000–$15,000/month for 6–12 months of remediation support: $36,000–$180,000

Penetration test: $15,000–$40,000 (HITRUST requires a more comprehensive pen test than SOC 2, medical device-grade pen testing for some product types)

Internal staff time: 300–600 hours of staff time across all 19 control domains

12-month interim assessment: $25,000–$60,000

24-month recertification (r2): Similar to first-time assessment costs

Total HITRUST r2 first-time cost: $200,000–$500,000 depending on company size, baseline posture, assessor selection, and remediation requirements.

EB Index 2026: The median total first-year cost for a digital health company achieving SOC 2 Type II was $118,000. The median time from compliance program initiation to SOC 2 Type II report issuance was 13 months (including the six-month observation period). The median total first-time cost for HITRUST r2 was $340,000. The median time from HITRUST program initiation to certification letter was 16 months.

What we’d cut: For a digital health startup with under $5M raised pursuing its first enterprise customers: do not engage a Big Four accounting firm for your SOC 2 audit. The Big Four firms are excellent, and priced for enterprise clients.

A healthcare-specialist regional or boutique CPA firm with SOC 2 expertise (A-LIGN, Johanson Group, Prescient Assurance) delivers equivalent audit quality for your first SOC 2 at 40–60% lower cost. Save the Big Four relationship for when your Series B investors require a Big Four audit.

The 16-Week SOC 2 Readiness Sprint

This is our timeline for taking a digital health company from baseline security posture to SOC 2 Type II audit-ready, with the observation period running in parallel. The observation period starts in Week 3 and runs for six months after Week 3, meaning the SOC 2 Type II report can be issued approximately 28–30 weeks from project start if the audit runs immediately after the observation period.

Week 1: Scoping, Gap Assessment, and Program Foundation

SOC 2 scope defined: which systems, services, and infrastructure are in scope. Which Trust Services Criteria will be included (Security required; Availability, Confidentiality, and Privacy to be added based on customer requirements).

Gap assessment: current controls assessed against all SOC 2 required controls for the selected criteria. Gaps documented and prioritized. Compliance automation platform selected and onboarded (Vanta recommended). Auditor engaged, healthcare-specialist CPA firm with SOC 2 experience.

Week 2: Policy Framework

All required policies drafted, reviewed, and approved: information security policy, access control policy, change management policy, incident response policy, risk assessment policy, vendor management policy, acceptable use policy, data classification policy, business continuity and disaster recovery policy, encryption policy. Policies stored in the compliance automation platform. Policy acknowledgment collected from all employees.

Week 3: Technical Control Implementation, Access Controls

MFA enforced on all systems with customer data access, cloud consoles (AWS IAM, GCP, Azure), GitHub/GitLab, production infrastructure access, SaaS applications (Google Workspace, Slack, etc.). Shared accounts eliminated. Service accounts inventoried and restricted to minimum necessary permissions. Access deprovisioning SLA defined and process implemented. First quarterly access review conducted and documented. Observation period starts.

Week 4: Technical Control Implementation, Endpoint and Network

Endpoint detection and response (EDR) deployed on all employee devices (CrowdStrike Falcon, SentinelOne, or equivalent). Disk encryption verified on all employee devices. Screen lock enforced. Mobile device management policy implemented. Firewall rules reviewed and hardened. VPN required for all remote administrative access.

Week 5: Technical Control Implementation, Change Management

CI/CD pipeline controls implemented: required code review (minimum one approver other than the author), automated testing gate (build fails if tests fail), staging environment testing required before production deployment, production deployment approval documented. Change management policy applied to infrastructure changes: Terraform or equivalent infrastructure-as-code with peer review.

Week 6: Technical Control Implementation, Monitoring and Alerting

Security event monitoring configured: CloudTrail (AWS) or equivalent for all infrastructure events. Security Information and Event Management (SIEM) platform configured (Datadog, Splunk, or AWS Security Hub). Alert rules configured for: unauthorized access attempts, privilege escalation, unusual data access volumes, production configuration changes. Log retention configured for 12 months minimum (SOC 2), 6 years minimum if HIPAA also applies. Incident response runbook updated with alert response procedures.

Week 7: Vulnerability Management Program

Vulnerability scanner deployed (Qualys, Tenable, or AWS Inspector). First vulnerability scan conducted. Remediation SLAs defined by severity: Critical, 7 days; High, 30 days; Medium, 90 days; Low, 180 days. Patch management process documented and first patching cycle documented. Penetration test engagement initiated with third-party firm, scheduled for Week 12.

Week 8: Vendor Management Program

Third-party vendor inventory completed: all SaaS tools, cloud services, and service providers with access to customer data or production systems. Risk assessment conducted for each vendor (vendor security questionnaire or review of their SOC 2 report). BAA registry updated: all vendors handling ePHI confirmed to have executed BAAs. Security addendums executed where BAAs are not applicable. Vendor management policy applied.

Week 9: Risk Assessment

Formal risk assessment conducted: identifying threats to systems in scope, estimating likelihood and impact, identifying existing controls and residual risk, documenting risk treatment decisions (accept, mitigate, transfer, avoid). Risk register created and documented in compliance automation platform. Risk assessment reviewed and approved by leadership.

Week 10: Security Awareness Training

Security awareness training deployed to all employees: annual training covering phishing, social engineering, password security, data handling, incident reporting. For digital health companies: HIPAA awareness training included. Training completion tracked and documented. Phishing simulation conducted (Knowbe4, Proofpoint Security Awareness Training, or equivalent).

Week 11: Business Continuity and Disaster Recovery

BCP/DRP policy documented. Recovery time objective (RTO) and recovery point objective (RPO) defined for production systems. Backup procedures documented and verified: daily backups, encrypted, tested quarterly. Disaster recovery runbook written. BCP/DRP tabletop exercise conducted and documented. DR test (failover to backup environment) planned and scheduled.

Week 12: Penetration Test

Third-party penetration test conducted: web application testing (OWASP Top 10), API testing, network and infrastructure testing (if in scope), social engineering (if in scope). Penetration test report received. Critical and high findings remediated. Penetration test completion documented in compliance platform.

Week 13: Pre-Audit Review with Compliance Platform

Vanta/Drata/Secureframe readiness report reviewed: all controls showing compliant status. Any failing controls investigated and remediated. Evidence collection confirmed complete for all in-scope controls. Auditor provided pre-audit documentation package: system description, policies, risk assessment, penetration test report, vendor inventory.

Week 14: Auditor Kickoff and Initial Evidence Review

Auditor kickoff meeting. System description walkthrough. Initial evidence review by auditor, identifying any gaps in documentation before the formal testing phase. Any gaps identified by auditor addressed before Week 15.

Weeks 15–16: Auditor Testing Phase

Auditor conducts control testing: sample-based testing of access reviews (auditor will sample access review evidence from multiple quarters), change management testing (auditor will sample production deployments and verify review/approval evidence), incident response testing (auditor will review incident records and verify response procedures were followed), vendor management testing (auditor will sample vendor risk assessments and BAA evidence), monitoring and alerting testing (auditor will review alert configuration and incident response records).

Any exceptions identified during testing: provide additional evidence or acknowledge the exception with management response.

Post-Week 16: Report Issuance

Auditor drafts the SOC 2 Type II report. Management letter of assertion reviewed and approved. Final report issued, typically 4–6 weeks after the testing phase ends.

Observation period conclusion: The observation period started in Week 3. For a six-month observation period, the earliest the Type II report can cover is Week 3 through Week 29 (six months later). If the audit testing is conducted in Weeks 15–16, and the observation period ends at Week 29, the earliest Type II report issuance is approximately Week 33–35 (7–9 months after project start).

Common Failure Modes, Why Digital Health Companies Fail Their Audits

• Failure mode 1: Terminated employee access not removed

The single most common SOC 2 finding for digital health companies. An employee leaves. Their access to production systems, cloud consoles, code repositories, or SaaS tools is not removed within the policy’s defined SLA (typically 24 hours for privileged access, 48 hours for standard access). The auditor samples terminated employees and finds active accounts.

Prevention: automated deprovisioning tied to HR offboarding. Every user access managed through a directory service (Okta, Azure AD) with automated deprovisioning. Quarterly access reviews that specifically include cross-referencing HR records against active accounts.

• Failure mode 2: Access reviews not conducted quarterly

The policy says quarterly access reviews. The evidence shows access reviews were conducted in Q1 and Q3 but skipped in Q2 and Q4. The auditor finds the gaps. The control is flagged as not operating effectively for the full observation period.

Prevention: calendar-scheduled access reviews with designated owners. Compliance platform reminders. Evidence collected automatically through the compliance platform.

• Failure mode 3: Change management bypasses for emergency changes

The change management policy requires code review and staging testing before production deployment. An urgent bug fix is pushed directly to production without following the process. The CI/CD logs show the bypass. The auditor finds it.

Prevention: technical enforcement of change management controls, branch protection rules that cannot be bypassed without explicit override. Emergency change procedure documented (with the override requiring documented approval from CTO or equivalent). Emergency changes are exceptions that are documented, not uncontrolled bypasses.

• Failure mode 4: Penetration test findings not remediated

The penetration test identified three High-severity findings. Two were remediated within the 30-day SLA. One was acknowledged as a risk acceptance. The auditor asks for the risk acceptance documentation, it does not exist. The finding is open without documented disposition.

Prevention: every penetration test finding has a documented disposition, remediated (with evidence) or risk-accepted (with documented rationale and leadership approval). No finding is left undocumented.

• Failure mode 5: Vendor inventory incomplete

The vendor management program has 12 vendors documented. The auditor identifies a SaaS tool in use that handles customer data and is not on the vendor inventory. The tool has no BAA and no security review.

Prevention: software inventory management (running discovery against all SaaS tools in use across the organization). Shadow IT elimination, enforce that all SaaS tools used by employees must be approved through a security review process before use.

• Failure mode 6: Log retention gaps

The monitoring policy requires 12 months of log retention. The CloudTrail logs are configured to retain for 90 days before deletion. The auditor reviews log retention configuration and finds the gap.

Prevention: log retention configuration explicitly mapped to policy requirements. Compliance platform monitoring of log retention configuration. Annual review of log retention settings against policy.

• Failure mode 7: HITRUST maturity scoring too optimistic

In a HITRUST self-assessment, the organization rates itself at maturity level 4 or 5 for controls where the actual implemented maturity is level 2 or 3. The external assessor validates and downgrades the maturity scores. The corrected scores fall below the required threshold in several domains. A Corrective Action Plan is issued instead of certification.

Prevention: conservative self-assessment. The HITRUST maturity model is specific about what each maturity level requires. Level 3 (defined and implemented) requires documented procedures with evidence that they are actually followed, not just that the procedure exists in a document. Self-assess to the level you can actually evidence, not to the level you aspire to.

The Evidence Collection Playbook

Evidence is the currency of compliance audits. An auditor cannot accept a control based on your description of it, they need evidence that the control exists and operated effectively during the observation period.

The evidence categories and what they look like:

Access control evidence:

• Screenshots of MFA enforcement settings in your identity provider (Okta, Azure AD), taken at the start and end of the observation period
• Quarterly access review documentation, spreadsheet or ticketing system records showing who reviewed, what access was reviewed, and any access removed
• Offboarding checklist records, evidence that departing employees had access removed within the policy SLA
• Privileged access management records, who has privileged access, what approvals were required

Change management evidence:

• CI/CD pipeline configuration, branch protection settings, required reviewers, automated testing gates
• Production deployment records from GitHub/GitLab, pull requests with reviewer approvals and merge timestamps
• Change request records for infrastructure changes, ticket system records with approval documentation

Incident response evidence:

• Incident response plan (current version, with version history)
• Incident records, any security events or incidents during the observation period, documented with discovery date, investigation, response, and resolution
• Tabletop exercise records, attendees, scenarios, findings, follow-up actions
• Alert acknowledgment records from the SIEM platform

Vulnerability management evidence:

• Vulnerability scan reports from each scan cycle during the observation period
• Remediation tracking records, when each finding was identified, its severity, and when it was remediated
• Penetration test report with remediation evidence
• Patch management records, system patch status reports

Vendor management evidence:

• Vendor inventory with risk tier classifications
• Vendor risk assessment records (security questionnaires or review of vendor SOC 2 reports)
• BAA registry with execution dates

Training evidence:

• Security awareness training completion records, all employees, training date, training content
• New hire training records, security training completed within defined onboarding window

The evidence collection discipline:

Start collecting evidence from Day 1 of the observation period. Do not try to reconstruct evidence for the observation period during the audit. Evidence that was created contemporaneously with the control execution is far more credible than evidence assembled retrospectively.

Compliance automation platforms automate evidence collection for technical controls, they pull MFA status, access logs, and vulnerability scan results directly from your cloud and SaaS tools. For process-based controls, access reviews, training completions, vendor assessments, the evidence is created by the process itself. Run the process, save the record, upload to the compliance platform.

Post-Certification: Maintenance, Renewal, and Expansion

• SOC 2 Type II annual renewal:

SOC 2 Type II must be renewed annually. The renewal covers a new 12-month observation period (some companies do rolling 12-month reports; some do annual point-in-time). The renewal audit is shorter than the first audit if controls are stable, 6–8 weeks versus the initial 14–16 week sprint.

Renewal cost: $15,000–$40,000 auditor fees depending on scope changes.

What triggers scope expansion in renewal: adding new product features that change the systems in scope, adding new Trust Services Criteria (adding Availability if you previously only had Security), or adding new customer data processing that expands the data environment in scope.

Adding criteria over time:

Most digital health companies start with SOC 2 Security only. As the product matures and enterprise customers become more sophisticated, adding Availability and Confidentiality criteria adds credibility. Availability is particularly important for digital health products where system downtime affects clinical care. Confidentiality is important when customers want explicit audit evidence of how their PHI is protected beyond general security controls.

• HITRUST interim assessment (12 months):

HITRUST certification is valid for two years, with a required interim assessment at 12 months. The interim assessment validates that controls remain in place and that any changes to the organization’s environment have not introduced new gaps.

Interim assessment cost: $25,000–$60,000 in assessor fees.

Common triggers for interim assessment issues: significant organizational changes (acquisition, major product expansion, new geographic operations), changes to the systems in scope, or control failures identified in incident response or internal audit.

• HITRUST recertification (24 months):

At 24 months, a full r2 assessment must be completed for recertification. The recertification is similar in scope to the initial certification but typically faster because the organization has mature controls and established evidence collection processes.

Recertification cost: similar to first-time assessment, often 15–25% lower due to assessor familiarity with the organization.

Adding SOC 2 to a HITRUST-certified organization:

Some digital health companies pursue HITRUST before SOC 2, typically because their first enterprise customers required HITRUST. When these companies subsequently need SOC 2 for a different buyer segment, the HITRUST controls provide significant SOC 2 coverage. The SOC 2 audit is faster and cheaper for a HITRUST-certified organization than for a company starting from scratch.

When an Indian Engineering Partner Is Wrong for Your Compliance Build

An Indian engineering partner is the wrong call for your SOC 2 or HITRUST compliance build if: your enterprise customers have data residency requirements that restrict where compliance-related data (audit logs, access control records, compliance platform data) can be stored or processed, some federal health programs and some state Medicaid programs include data residency specifications that may restrict offshore access.

If your customer contracts include specific requirements about the geographic location of staff with administrative access to production systems, some federal healthcare contracts and some large health system contracts include this requirement.

If your HITRUST assessor has expressed concern about offshore access to the systems being assessed, uncommon, but something to clarify early with your assessor.

For the vast majority of digital health companies pursuing SOC 2 Type II and HITRUST r2: the technical control implementation work, MFA deployment, CI/CD pipeline controls, SIEM configuration, vulnerability management tooling, compliance automation platform configuration, is engineering work that is well-suited to remote collaboration.

The policy documentation, risk assessment, and auditor/assessor interactions are primarily US-side activities led by your CISO, compliance consultant, or the regulatory attorney on your team.

We have supported SOC 2 and HITRUST compliance builds from Indore for US digital health clients. The engineering controls are deployed from Indore. The compliance strategy and auditor relationships are managed from the US side. The division of labor is clean and works well.

The Compliance Certification Scorecard™

Score each row 0 (absent), 1 (partial), or 2 (fully present). Maximum score: 70.

#	Criterion	Weight	Your Score
1	SOC 2 Trust Services Criteria selected based on customer requirements (not defaults)	1×	/2
2	SOC 2 observation period started, controls operational and documented	2×	/4
3	MFA enforced technically on all systems with customer data access	2×	/4
4	Quarterly access reviews conducted with documented evidence	2×	/4
5	Automated deprovisioning or SLA-enforced manual deprovisioning for departing employees	2×	/4
6	CI/CD pipeline with enforced code review and automated testing gate	2×	/4
7	Annual penetration test by qualified third-party firm	2×	/4
8	Penetration test findings with documented disposition (remediated or risk-accepted)	2×	/4
9	Vulnerability scanning with documented remediation SLAs by severity	1×	/2
10	Vendor inventory complete with risk assessments and contractual controls	2×	/4
11	BAA registry current for all ePHI-handling vendors	2×	/4
12	Security awareness training documented for all employees (including HIPAA content)	1×	/2
13	Incident response plan documented and tabletop exercise conducted	1×	/2
14	Security event monitoring with SIEM and documented alert response	1×	/2
15	Log retention configured at 12 months minimum (6 years if HIPAA applies)	1×	/2
16	Risk assessment completed and risk register maintained	1×	/2
17	HITRUST target buyers researched, compliance requirement confirmed before sequencing decision	2×	/4
18	HITRUST MyCSF subscription and gap assessment initiated (if HITRUST in roadmap)	1×	/2
19	HITRUST-authorized assessor engaged (if HITRUST in roadmap)	1×	/2
20	AWS/Azure/GCP HITRUST inheritance configured (if HITRUST in progress)	1×	/2
21	Healthcare-specialist auditor/assessor engaged (not a generalist firm)	1×	/2
22	Compliance automation platform deployed and evidence collection automated	1×	/2
23	SOC 2 report summary letter prepared for customer sharing	1×	/2
24	Compliance renewal calendar with observation period and assessment dates tracked	1×	/2
25	Both certifications in roadmap with funding and timeline planned	1×	/2

Score interpretation:

• 55–70: Strong compliance posture, SOC 2 Type II audit-ready or HITRUST assessment-ready
• 40–54: Proceed with identified gaps remediated, technical control 2× items are audit-critical
• Under 40: Significant compliance gaps, not ready for enterprise procurement that requires SOC 2 or HITRUST

Conclusion

SOC 2 Type II is the floor. HITRUST is the ceiling. Between them, they cover every enterprise buyer in the digital health market, from the mid-market health system that needs SOC 2 to close the $200,000 contract, to the large integrated delivery network that needs HITRUST r2 to approve the $1.8M population health program.

The sequencing mistake, pursuing HITRUST when your buyers need SOC 2, or pursuing only SOC 2 when your buyers need HITRUST, costs more in lost deals and delayed revenue than both certifications combined.

The architecture mistake, building minimum-viable SOC 2 controls that must be rebuilt for HITRUST, costs more in remediation than building HITRUST-compatible controls from the beginning.

And the timing mistake, starting the SOC 2 observation period six months after you needed the report, is the most expensive mistake of all, because it is measured in closed doors rather than dollars.

I have been on this call with enough digital health founders to know that the compliance conversation is the one most people defer. Not because it is unimportant, every founder I have spoken to knows it matters. But because it feels like a detour from the product. It is not a detour. It is the gate your enterprise customers are standing behind.

If you want 30 minutes to talk through your compliance roadmap, what your target buyers require, what your current posture is, what the right sequencing looks like for where you are, book a call with me or Aditi. No slides. No pitch. Just the compliance conversation.

FAQ

• What is the difference between SOC 2 Type I and SOC 2 Type II?

SOC 2 Type I is a point-in-time evaluation assessing whether your security controls are suitably designed as of a specific date. SOC 2 Type II is an evaluation over a period of time, minimum six months, assessing whether your controls operated effectively throughout that period. Enterprise health system buyers, health plans, and sophisticated healthcare buyers require SOC 2 Type II. Type I is a useful interim credential while the Type II observation period is running but is not sufficient for enterprise procurement.

• How long does it take to get SOC 2 Type II?

From compliance program initiation to SOC 2 Type II report issuance: typically 13–18 months. The observation period alone is 6–12 months. Add 2–4 months for initial control implementation before the observation period starts, and 2–3 months for the audit and report issuance after the observation period ends. The timeline can be compressed to 9–12 months if you start with a strong security foundation, but the six-month minimum observation period cannot be compressed.

• How long does HITRUST r2 certification take?

HITRUST r2 certification takes 12–18 months for first-time organizations, from program initiation through certification letter issuance. The timeline includes: gap assessment (1–3 months), remediation (3–8 months), self-assessment in MyCSF (2–4 months), external assessor validation (2–3 months), and HITRUST quality review (1–2 months). Organizations with mature security programs and experienced HITRUST assessors can complete the process in 12 months. First-time organizations with significant control gaps should plan for 18 months.

• Which large health systems require HITRUST?

Large health systems that have published or communicated HITRUST requirements for vendors handling population-scale PHI include many of the largest integrated delivery networks, Ascension, CommonSpirit, HCA Healthcare, Kaiser Permanente, Mayo Clinic, and others. Large regional payers (Blue Cross Blue Shield affiliates, regional Medicaid managed care organizations) frequently require HITRUST for vendors managing more than 50,000 or 100,000 member lives. The specific requirement varies by organization and by contract scope. Ask your target buyer directly: “What are your compliance certification requirements for vendors handling PHI at this scale?”

• Can I use my SOC 2 Type II report to satisfy HIPAA compliance requirements?

No, SOC 2 Type II and HIPAA compliance are different things. SOC 2 evaluates your security controls against the AICPA’s Trust Services Criteria. HIPAA compliance requires: a completed risk analysis, documented risk management, a Business Associate Agreement process, workforce training, specific technical safeguards (encryption, audit controls, access controls), and breach notification procedures. A SOC 2 Type II report demonstrates that your general security controls operated effectively. It does not demonstrate HIPAA-specific compliance. Both are needed for a digital health enterprise sale.

• What is the HITRUST inheritance program for AWS?

AWS has achieved HITRUST r2 certification for its cloud services. Digital health companies building on AWS can inherit HITRUST control validations for AWS-managed infrastructure controls rather than re-validating them from scratch. Inheritance is configured in HITRUST’s MyCSF platform using AWS’s HITRUST Inheritance Package (available through AWS Artifact). Inheritance reduces the number of controls you must independently validate, typically covering a significant portion of infrastructure-related domains (physical security, network infrastructure, environmental controls) without requiring your own evidence.

• Do I need both SOC 2 and HITRUST?

For most digital health companies targeting the full enterprise market, including large health systems and large payers, yes, eventually. The sequencing is typically SOC 2 first (9–15 months, required by all enterprise buyers) followed by HITRUST r2 (12–18 months additional, required by the largest health system and payer enterprise buyers). The controls overlap significantly, your SOC 2 program builds 60–70% of the HITRUST foundation. The incremental cost of HITRUST after SOC 2 is lower than building HITRUST from scratch.

• What compliance automation platforms work best for digital health SOC 2?

Vanta is the most common choice for early-stage to mid-size digital health companies. Its integrations with AWS, GCP, Azure, GitHub, Google Workspace, and common SaaS tools automate evidence collection effectively. Pricing: $12,000–$25,000/year. Drata offers more customization and stronger enterprise features for larger organizations at $20,000–$50,000/year. Secureframe is a strong option for companies with Salesforce or ServiceNow in their stack. All three reduce the manual evidence collection burden by 60–70%, but none eliminates the need for actual security controls, policy documentation, or auditor engagement.

• What is the HITRUST maturity scoring model?

HITRUST evaluates controls on a five-level maturity scale: Level 1 (policy exists), Level 2 (procedures are documented), Level 3 (procedures are implemented), Level 4 (controls are tested), Level 5 (controls are managed and continuously improved). The minimum required maturity level for HITRUST r2 certification varies by control, most controls require Level 3 (defined and implemented) at minimum. Self-assessing too optimistically, rating yourself Level 4 when your actual implemented maturity is Level 2, results in assessor downgrade, which can push your scores below the certification threshold.

• How much does annual compliance maintenance cost after achieving certifications?

SOC 2 Type II annual maintenance: $35,000–$90,000 (auditor fees $15,000–$40,000 + compliance platform $12,000–$50,000 + annual penetration test $8,000–$22,000). HITRUST annual maintenance: $65,000–$140,000 (12-month interim assessment $25,000–$60,000 + HITRUST MyCSF subscription $10,000–$25,000 + penetration test $15,000–$40,000 + ongoing staff time). Combined annual maintenance for both certifications: $100,000–$230,000 for mid-size digital health companies.

• What is the right first step if we need SOC 2 in 12 months?

Start today with four simultaneous actions: (1) engage a healthcare-specialist SOC 2 auditor and schedule your audit window, (2) deploy a compliance automation platform (Vanta recommended for most digital health companies), (3) implement the technical controls that require the longest lead time, MFA everywhere, access deprovisioning automation, CI/CD pipeline controls, vulnerability scanning, (4) write the core policies, information security, access control, change management, incident response. The observation period clock starts when controls are operational. Every week of delay in starting is a week added to your Type II report date.