How-To12 May 2026 13 min read

SOC 2 for Healthtech: HIPAA Overlap and What to Automate

Q: Does Telehealth add any unique SOC 2 controls?

Telehealth adds: video call recording storage (if sessions are recorded, they are ePHI requiring encryption and access controls), real-time communication security (WebRTC DTLS-SRTP for encrypted video/audio), consent management (HIPAA requires patient authorization for certain PHI uses — track consent with timestamps), and multi-state licensure data (if clinicians practice across states). These data types need to appear in your data map and be covered by your encryption and access control policies.

SOC 2 for healthtech companies — covering HIPAA technical safeguards, PHI encryption, audit controls, business associate agreements, and how to automate controls that satisfy both frameworks.

Key Takeaways

HIPAA technical safeguards and SOC 2 Security criteria overlap by approximately 70% — implement together.
PHI encryption at rest (AES-256) and in transit (TLS 1.2+) satisfies both HIPAA and SOC 2 C1.1.
HIPAA audit controls (§164.312(b)) map directly to SOC 2 CC7.2 logging and monitoring requirements.
Business Associate Agreements are required for all vendors that process PHI, aligning with SOC 2 CC9.2.
AWS HIPAA-eligible services include RDS, S3, CloudTrail, and Lambda — use these for PHI processing.
Automatic logoff and unique user identification are HIPAA technical safeguards that also satisfy SOC 2 CC6.

In this guide

HIPAA and SOC 2 for Healthtech
PHI Classification and Data Mapping
HIPAA Technical Safeguards = SOC 2 CC6
PHI Encryption (C1.1)
Audit Controls and Logging (CC7.2)
Business Associate Agreements (CC9.2)
AWS HIPAA-Eligible Services
What to Automate for Dual Compliance

HIPAA and SOC 2 for Healthtech

Healthtech companies — clinical software, telehealth platforms, digital health apps processing patient data — face both HIPAA compliance obligations (if they are a Covered Entity or Business Associate under US law) and SOC 2 requirements from enterprise healthcare system customers. The good news is that these frameworks overlap significantly, and a well-designed compliance program addresses both simultaneously.

HIPAA has three sets of rules: Privacy Rule (patient rights and PHI use), Security Rule (technical and administrative safeguards for ePHI), and Breach Notification Rule (incident response and reporting). SOC 2's Security criteria map most closely to the HIPAA Security Rule technical safeguards. Building SOC 2 controls with HIPAA security requirements in mind from the start avoids the need to retrofit HIPAA-specific controls later.

For Indian healthtech companies targeting US healthcare customers: HIPAA jurisdiction applies when you process ePHI for a US Covered Entity (hospital, health plan, healthcare clearinghouse) or another Business Associate. If your customers are Indian healthcare systems, the relevant Indian framework is the Digital Information Security in Healthcare Act (DISHA, pending enactment) and the DPDP Act for health data. SOC 2 still serves as a useful sales enablement tool for enterprise Indian healthcare customers.

PHI Classification and Data Mapping

Protected Health Information (PHI) under HIPAA is any individually identifiable health information: patient names, dates of service, geographic identifiers, phone numbers, email addresses, medical record numbers, health plan beneficiary numbers, social security numbers, IP addresses, and biometric identifiers — when linked to health or payment information. ePHI is PHI in electronic form.

Create a PHI data map: which databases store ePHI, which S3 buckets, which message queues, which third-party systems. This data map is the foundation of your HIPAA and SOC 2 C1.1 compliance — you cannot protect what you have not found. Use AWS Macie to automatically discover PHI in S3 (Macie has built-in patterns for US healthcare identifiers). For databases, use a data classification tool or manual review of schema and sample data.

Classify data by PHI sensitivity: Direct PHI (name + health condition together), Indirect PHI (identifiers that could be linked to PHI), De-identified data (safe harbor de-identification under HIPAA removes 18 specific identifiers). Track which data processing activities touch PHI and ensure those systems are in scope for both your HIPAA security program and your SOC 2 audit.

HIPAA Technical Safeguards = SOC 2 CC6

HIPAA Security Rule Technical Safeguards (§164.312) map directly to SOC 2 CC6 controls. Access Control (§164.312(a)(1)) requires unique user identification, automatic logoff, and encryption/decryption — these are the same controls as SOC 2 CC6.1 and CC6.2. Audit Controls (§164.312(b)) require recording and examining system activity — directly equivalent to SOC 2 CC7.2 logging.

Person or Entity Authentication (§164.312(d)) requires verifying the identity of users accessing ePHI — implemented via MFA, satisfying both frameworks with one control. Transmission Security (§164.312(e)(1)) requires protecting ePHI during transmission — implemented via TLS 1.2+ on all API endpoints, satisfying both. Automatic Logoff (§164.312(a)(2)(iii)) requires terminating sessions after inactivity — implemented via Okta session timeout settings.

By documenting each HIPAA safeguard implementation alongside the corresponding SOC 2 criterion, you create a dual-mapped control matrix that satisfies both frameworks' evidence requirements. For example: "MFA enforced via Okta for all users with access to ePHI (HIPAA §164.312(a)(2)(i) Unique User Identification; HIPAA §164.312(d) Person Authentication; SOC 2 CC6.1; SOC 2 CC6.2)."

PHI Encryption (C1.1)

Encrypt all ePHI at rest with AES-256. For AWS: enable KMS encryption on all RDS instances storing PHI, S3 buckets with PHI (use bucket keys for performance), DynamoDB tables, and EBS volumes. Use separate KMS keys for different PHI data stores — this limits the blast radius if one key is compromised. Enable automatic KMS key rotation annually.

Encrypt all ePHI in transit with TLS 1.2+. Do not use HTTP for any endpoint that could transmit PHI, including internal API calls. Enable `aws:SecureTransport` condition in all S3 bucket policies to deny HTTP access. For your web application, set HSTS headers with max-age of at least 1 year and include subdomains. Test TLS configuration with SSL Labs and target Grade A or A+.

Mobile app PHI requires additional controls. Encrypt local storage of ePHI using the platform secure enclave (iOS Keychain, Android Keystore). Require device-level encryption (enforced via MDM). Implement certificate pinning on mobile API calls to prevent man-in-the-middle attacks. Document mobile PHI handling in your Privacy Notice and data classification policy.

Audit Controls and Logging (CC7.2)

HIPAA §164.312(b) requires implementing "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." This is identical to SOC 2 CC7.2. Implement centralized logging with 7-year retention for PHI-related logs (HIPAA requires 6 years retention; HITECH extends this).

Log every access to PHI: who accessed it, when, from where, and what action was taken (view, edit, delete, export). For a web application, this means application-level logging of API calls that return PHI, not just infrastructure logs. Use a structured log format: `{"timestamp": "2026-04-26T10:30:00Z", "userId": "usr_123", "action": "patient_record_view", "patientId": "pt_456", "ipAddress": "203.0.113.5"}`. Ship to Datadog or Elasticsearch with PHI fields masked (replace patient IDs with anonymized identifiers in the log).

Configure CloudWatch alarms for unusual PHI access patterns: bulk exports of PHI records, access at unusual hours (2am–5am), access from unknown IP addresses. Route these alarms to your security team. Review PHI access logs monthly for anomalies. Include the monthly review evidence in your SOC 2 CC7.2 audit package.

Business Associate Agreements (CC9.2)

A Business Associate Agreement (BAA) is a HIPAA-required contract between a Covered Entity/BA and any vendor that accesses or processes ePHI on their behalf. Execute BAAs with: your cloud provider (AWS BAA covers HIPAA-eligible services), your SaaS infrastructure vendors (Datadog, Okta, GitHub — check each vendor's BAA availability), and your customers who are Covered Entities.

For AWS: execute the AWS BAA via your account health dashboard or through your AWS account manager. The AWS BAA covers a specific list of HIPAA-eligible services — only use those services for PHI processing. Non-eligible services (some AI services, some older region services) must not handle PHI. For Datadog: sign the Datadog BAA to enable PHI handling in logs and metrics. For Okta: Okta offers a BAA for Workforce Identity customers.

Maintain a BAA register: list every vendor, their BAA execution date, expiry or renewal date, and whether they process PHI directly. Review the BAA register quarterly alongside your SOC 2 vendor register — any new vendor that processes PHI must have a BAA before they are onboarded. Auditors will ask for BAA evidence for key vendors; have the signed agreements readily accessible.

AWS HIPAA-Eligible Services

AWS HIPAA-eligible services are those covered by the AWS BAA and suitable for PHI storage and processing. As of 2026, this includes over 150 services. Key ones for healthtech: Amazon RDS (all engines), Amazon Aurora, Amazon S3, Amazon EC2, AWS Lambda, Amazon EKS, Amazon ECS, AWS KMS, Amazon CloudWatch, AWS CloudTrail, Amazon Macie, AWS WAF, Elastic Load Balancing, Amazon SQS, Amazon SNS, Amazon Cognito, and Amazon SageMaker.

Non-HIPAA-eligible services to avoid for PHI: Amazon Rekognition (image analysis), Amazon Transcribe (audio transcription using PHI audio would require off-list approval), and some AI services in their standard forms. If you need to use a non-eligible service for PHI processing, consult AWS and your legal team. Using non-eligible services for PHI processing violates the AWS BAA and creates HIPAA liability.

What to Automate for Dual Compliance

The highest-value automation for HIPAA + SOC 2 dual compliance: (1) AWS Config rules for PHI-related infrastructure: s3-bucket-server-side-encryption-enabled, rds-instance-default-subnet-group, rds-instance-public-access-check, cloudtrail-enabled, guardduty-enabled-centralized. These rules continuously verify PHI-touching infrastructure meets both frameworks' requirements. (2) Macie automated PHI discovery: run monthly Macie discovery jobs across all S3 buckets and route findings to your security team for remediation.

(3) Access review automation via Okta Lifecycle Management: automatically provision/de-provision PHI system access based on HRIS role data. No manual steps means no orphaned PHI access after role changes. (4) Log management with Datadog: set retention to 7 years for PHI access logs, create a saved search for PHI access anomalies, export monthly reports as audit evidence. These four automation investments cover the bulk of both HIPAA technical safeguard and SOC 2 CC6–CC7 evidence requirements with minimal ongoing manual effort.

Frequently Asked Questions

Do Indian healthtech companies need HIPAA compliance?

HIPAA applies when you process ePHI for US Covered Entities or Business Associates, regardless of where your company is based. An Indian health IT company that builds software used by US hospitals, or that processes data from US patients, must comply with HIPAA. If all your customers are Indian, HIPAA does not apply, but the DPDP Act's provisions for health data (a sensitive personal data category) do.

Can we get SOC 2 Type II and then add HIPAA BAA without repeating the audit?

SOC 2 and HIPAA BAA are separate attestations. Your SOC 2 Type II report does not automatically satisfy HIPAA requirements, but it demonstrates strong foundational security controls that make HIPAA compliance easier. Some auditors offer combined SOC 2 + HIPAA security assessment engagements. You execute the BAA with vendors separately from the audit process.

What is de-identification and can it exempt us from SOC 2 scope?

HIPAA allows two de-identification methods: Expert Determination and Safe Harbor (remove 18 specific identifiers). Truly de-identified data is no longer PHI and no longer subject to HIPAA. However, de-identification is difficult to maintain correctly, and re-identification risk remains. De-identified data may still contain personal data under DPDP Act and GDPR definitions. Consult legal counsel before relying on de-identification as a compliance strategy.

What is the Breach Notification Rule and how does it affect our incident response?

The HIPAA Breach Notification Rule requires notifying affected individuals within 60 days of discovering a PHI breach, notifying HHS annually (for breaches < 500 individuals) or within 60 days (for breaches ≥ 500 individuals), and notifying prominent media for breaches affecting ≥ 500 individuals in a state. Your SOC 2 incident response policy should include HIPAA breach notification timelines and procedures. The PagerDuty incident record and postmortem serve as evidence of breach handling under both frameworks.

Does Telehealth add any unique SOC 2 controls?

Telehealth adds: video call recording storage (if sessions are recorded, they are ePHI requiring encryption and access controls), real-time communication security (WebRTC DTLS-SRTP for encrypted video/audio), consent management (HIPAA requires patient authorization for certain PHI uses — track consent with timestamps), and multi-state licensure data (if clinicians practice across states). These data types need to appear in your data map and be covered by your encryption and access control policies.