HIPAA + SOC2 Without Doing It Twice: A Healthcare SaaS Compliance Story
Twenty people. A B2B SaaS platform that had been live for two years, doing well with mid-market healthcare clinics. A growing pipeline of hospital systems — IDNs, regional health networks, academic medical centers — that kept stalling at the same point in procurement: "We need HIPAA compliance attestation and a SOC2 report before we can advance to contract review."
The company handled Protected Health Information (PHI): patient appointment data, clinical intake forms, provider notes, billing codes. Not incidentally — PHI was core to the product's value. Every hospital prospect was asking the same questions: How do you encrypt data? How do you audit access? Who are your Business Associates? What happens in a breach?
They had partial answers to all of these. They had TLS in transit and AES-256 at rest. They had some logging. But they had no formal HIPAA compliance program, no signed BAAs with their cloud providers, no documented audit trail process, and no SOC2 report. Every hospital deal was dying in legal review.
We designed a unified compliance program that addressed HIPAA's Security Rule and SOC2's Trust Services Criteria simultaneously — because about 70% of the controls overlap if you structure the work correctly.
SOC1 vs SOC2 in healthcare: Some hospital procurement teams, particularly those evaluating vendors that touch revenue cycle or billing workflows, may request a SOC 1 report alongside SOC 2. This client's product was clinical workflow software — SOC 2 was the correct framework. If your healthcare SaaS product directly interfaces with billing or payment processing systems, confirm with procurement whether SOC 1 Type II is additionally required.
The Unified Compliance Approach
The mistake most teams make is treating HIPAA and SOC2 as separate projects. HIPAA has a prescriptive regulatory structure (45 CFR Parts 160 and 164). SOC2 is a framework for demonstrating controls to customers. They cover much of the same ground differently.
Our approach: build the control set once, document it for both frameworks in parallel. We anchored the unified program to the NIST Cybersecurity Framework (NIST CSF) — Identify, Protect, Detect, Respond, Recover — as a common language that maps naturally to both HIPAA Security Rule Safeguards and SOC 2 Trust Services Criteria. This gave the client a framework-level story they could articulate to hospital security teams, not just a list of completed audit checkboxes. One encryption implementation, two documentation artifacts. One audit logging pipeline, two control narratives. One penetration test, evidence used in both contexts.
The starting baseline for this company was better than most:
- Encryption in transit (TLS 1.2+) and at rest (AES-256) were already implemented
- AWS was the infrastructure provider — a HIPAA-eligible BAA was available but hadn't been executed
- Some application-level logging existed but wasn't structured, centralized, or tamper-evident
- No Business Associate Agreements with downstream vendors (their transactional email provider, their analytics tool, and their support platform all touched PHI)
- No documented Risk Analysis (required under HIPAA Security Rule §164.308(a)(1))
- No Workforce Training records
Phase 1: HIPAA Security Rule Foundations
The HIPAA Security Rule has three categories of safeguards: Administrative, Physical, and Technical. Technical controls were the most mature; administrative was almost entirely missing.
Risk Analysis and Risk Management. The HIPAA Security Rule mandates a documented risk analysis — an assessment of potential risks to the confidentiality, integrity, and availability of ePHI. We ran a structured risk analysis across their data flows: where PHI enters the system, how it moves between components, where it rests, and who accesses it. Output: a risk register with 34 identified risks, each with likelihood and impact ratings and a documented mitigation or acceptance decision.
This document is simultaneously the foundation of HIPAA compliance and the risk assessment artifact SOC2 auditors want to see.
Business Associate Agreements. A Business Associate is any vendor that creates, receives, maintains, or transmits PHI on your behalf. Failure to have executed BAAs is one of the most common HIPAA enforcement findings — and it's entirely administrative.
We identified 7 vendors that qualified as Business Associates:
- AWS (executed via the standard AWS HIPAA BAA — covers EC2, RDS, S3, and other eligible services)
- Transactional email provider (patient appointment reminders contained PHI)
- Customer support platform (support tickets included clinical intake data)
- Analytics platform (session recordings captured form fields containing PHI)
- PDF generation service used for clinical summaries
- SMS notification provider
- Cloud backup vendor
BAAs were executed with all 7. Two vendors required switching to enterprise tiers to access their HIPAA BAA program. One vendor (the analytics platform) offered no HIPAA BAA at any tier — we scoped PHI out of their data collection rather than replace the tool, which was the right cost-benefit decision.
Workforce Training. Every member of the team with PHI access received formal HIPAA security awareness training. We used a configurable LMS module covering the Security Rule, Breach Notification Rule, employee obligations, and incident reporting. Completion certificates logged per-employee with date and version. This is required under HIPAA and expected by SOC2 auditors.
Policies. HIPAA requires documented policies for every Safeguard category. We produced a policy set covering:
- Information Security and PHI Handling Policy
- Access Control Policy (including minimum necessary standard)
- Workforce Clearance and Sanctions Policy
- Audit Controls Policy
- Incident Response and Breach Notification Policy (incorporating HIPAA's 60-day notification requirement)
- Contingency Plan (BC/DR) with defined procedures for ePHI backup and emergency access
Phase 2: Technical Controls — Encryption, Access, and Audit Logging
The existing encryption was sound at the transport and storage layer. We hardened the gaps and built the audit infrastructure that neither HIPAA nor SOC2 can be demonstrated without.
Encryption hardening:
- Enforced TLS 1.2 minimum across all endpoints; deprecated TLS 1.0/1.1 explicitly in ALB policies
- Verified AES-256 encryption on all RDS instances and S3 buckets containing PHI — found two S3 buckets that had been created without encryption enabled (non-PHI buckets, but the inconsistency is an audit finding)
- Enabled RDS encryption for one database instance that had been created before encryption was a standard (required a snapshot-and-restore operation during a maintenance window)
- Implemented KMS key rotation (annual, automatic) for all CMKs used with PHI data
- Verified TDE was configured on database backups and verified backup restores actually worked (two backup sets had never been tested)
Access controls:
- Implemented role-based access control at the application layer — previously any authenticated user could access any patient record in the same practice; access was scoped to practice ID with explicit audit logging on cross-practice access attempts
- Enforced MFA for all workforce members with PHI access
- Created break-glass procedures for emergency access with automatic alerting and mandatory post-access review
- Quarterly access review process implemented: automated script generates an access report for each PHI-touching system; team lead reviews and certifies or revokes
Audit logging. HIPAA requires audit controls that "record and examine activity in information systems that contain or use ePHI." SOC2 auditors want to see evidence that you're monitoring your own controls. These requirements converge on a comprehensive, tamper-evident audit trail.
We built a centralized audit logging pipeline:
- Application-level PHI access events: every read, write, update, or delete on PHI-tagged records logged with user ID, timestamp, patient record ID, action type, and source IP
- PostgreSQL pgAudit for database-layer logging of all DML operations on PHI tables
- AWS CloudTrail for infrastructure-level events
- All logs forwarded to S3 with Object Lock (7-year retention for HIPAA; 90-day minimum for SOC2 evidence — the longer retention satisfies both)
- Splunk Cloud for log search, dashboarding, and anomaly detection with pre-built HIPAA compliance dashboards
- Automated daily integrity checks on the audit log pipeline — any gap in log volume triggers a P1 alert
Anomaly detection and alerting:
- Bulk PHI access (>500 records in a single session) triggers an immediate P1 page
- Off-hours access by workforce members creates a P2 ticket for next-day review
- Failed authentication threshold alerting
- Geographic anomaly detection on administrative accounts
Phase 3: Penetration Testing and Audit Preparation
Hospital procurement teams don't just want a SOC2 report. They want a penetration test report. Both documents came out of a single coordinated engagement.
Penetration test scope: web application, API layer, and network perimeter, structured against the OWASP Top 10 (with extra emphasis on A01 Broken Access Control and A02 Cryptographic Failures given the PHI context). The test team was briefed on the PHI data model so they could prioritize high-value targets. We also set up an automated VAPT workflow — OWASP ZAP in CI/CD for continuous DAST coverage, Snyk for dependency scanning — so that between annual manual pentests, the attack surface remains monitored. This VAPT pipeline aligns to NIST CSF Detect and Respond functions and directly satisfied the "continuous vulnerability monitoring" inquiry from hospital IT security reviewers. Findings:
- High: Insecure Direct Object Reference in the patient record API — an authenticated user from Practice A could access patient records from Practice B by manipulating record IDs. This was a HIPAA Security Rule violation in production. Patched within 24 hours via server-side authorization enforcement.
- Medium: Missing rate limiting on the bulk export endpoint — potential for automated PHI exfiltration. Resolved with rate limiting and anomaly alerting.
- Medium: One legacy API endpoint still accepted TLS 1.0 connections. Deprecated.
- Low: Several informational findings (missing security headers, verbose error messages in development-mode responses).
All findings remediated and re-tested. The re-test report and remediation documentation became central evidence artifacts for both HIPAA risk management and SOC2 risk assessment documentation.
Pre-audit evidence review: We walked every SOC2 criterion and every HIPAA control requirement against the evidence package before the auditor engaged. The shared evidence structure meant that most items appeared once with dual annotations.
The Outcome
SOC2 Type II audit completed without qualified findings or exceptions. The HIPAA compliance attestation package (risk analysis, policies, BAA documentation, training records, audit logging architecture, penetration test report) was compiled and formatted for hospital procurement review.
Within 90 days of the compliance program completion:
- Two regional hospital systems that had previously stalled in procurement signed contracts
- One IDN added them to their approved vendor list — a status that unlocks introductions to every department within the network
- Their enterprise sales cycle shortened measurably: procurement review dropped from an average of 4 months to 6 weeks for new hospital prospects, because the evidence package answered questions proactively
The IDOR finding from the penetration test was the most significant moment of the engagement. It was a real vulnerability that could have resulted in a HIPAA breach. The penetration test found it before any patient data was accessed improperly. Documentation of the finding, the patch, and the timeline became a point of trust in hospital procurement conversations rather than a liability.
The Core Lesson
HIPAA and SOC2 are not the same framework, but for a company handling PHI in a cloud environment, they share an 80% control overlap. The teams that treat them as separate compliance projects end up with two gap assessments, two policy libraries, two audit prep timelines, and twice the engineering work.
Building them together isn't just more efficient — it produces a tighter, more coherent control environment. When your encryption policy, your audit logging implementation, your risk analysis, and your penetration test are all designed as parts of a unified program, they reinforce each other instead of creating gaps at the boundaries.
If you're building healthcare SaaS and hospital contracts are in your growth plan, compliance is the unlock — not a checkbox. Talk to us about how to build it right.
Related Resources
More articles:
- Pre-Launch SOC 2 Foundation for AI Startups
- Fintech SOC 2 Type II in 3 Weeks
- Healthcare SaaS: HIPAA + SOC 2 Compliance
Our solution: Security & SOC 2 Compliance Engineering
Glossary:
Comparisons:
- In-House vs Agency AI Development
- Build vs Buy AI MVP
- Vanta vs Drata vs 100x.ai: Which Compliance Approach is Right?
Free Tool: Get your SOC2 readiness score and see if you can match this timeline. → SOC2 Readiness Assessment