From Zero Security to Enterprise-Ready: A Healthcare SaaS Story
A 20-person B2B SaaS company had built something genuinely useful: a workflow automation platform for outpatient clinics that reduced administrative overhead by roughly 40%. They had paying customers, strong retention, and a pipeline full of larger health systems that wanted to buy.
The problem was predictable. Every deal above $30K required HIPAA attestation. Every hospital system required SOC2. Their existing security posture — functional but undocumented, with controls that had grown organically alongside the product — would not survive either audit.
They had limited budget. They couldn't afford to run two parallel compliance programs. And they had two LOIs from hospital systems that would expire in 90 days if they couldn't demonstrate compliance.
We built a unified program that satisfied both frameworks simultaneously.
Why HIPAA and SOC2 Together Makes More Sense Than Either Alone
The instinct is to treat these as separate projects. That instinct is wrong and expensive.
SOC2 and HIPAA overlap substantially. Both require access controls, audit logging, incident response, risk assessments, and vendor management. The difference is emphasis: HIPAA focuses specifically on Protected Health Information (PHI) and requires specific technical safeguards, while SOC2 is a broader security framework that covers the five Trust Services Criteria.
Our approach was to build controls to the higher bar of the two frameworks in each area — typically HIPAA's specific PHI requirements — and document them in a way that satisfies SOC2 evidence requirements simultaneously. One control set, two compliance mappings, one evidence collection process.
This isn't creative accounting. It's how mature compliance programs are run. The overhead is in the documentation and evidence, not in building duplicate systems.
The Technical Baseline: What Had to Change
Before writing a compliance mapping, we needed to understand what we were actually working with. The company ran on AWS, used PostgreSQL on RDS, had a Rails monolith, and had several years of organic technical decisions that made sense at the time but created compliance gaps.
The critical findings from our initial assessment:
PHI was not consistently encrypted at rest. Their primary database had encryption enabled at the RDS level, but several S3 buckets storing document attachments — some of which contained scanned forms with patient information — had encryption disabled. One bucket had public read access enabled, a legacy setting from a demo environment that was never cleaned up.
Audit logging was insufficient for HIPAA. HIPAA requires the ability to audit who accessed PHI, when, and from where. Their application had no PHI-specific audit trail. They could reconstruct some events from application logs, but not reliably, and there was no way to produce the "who accessed patient record X" report that a covered entity would require in a breach investigation.
Business Associate Agreements were missing or outdated. HIPAA requires a signed BAA with every vendor who handles PHI on your behalf. They had BAAs with their cloud provider and their payment processor, but not with their email service provider (which sent automated messages that sometimes included appointment details — PHI), their analytics platform, or their customer support tool.
No formal risk assessment had ever been conducted. HIPAA requires a documented risk analysis. They had never done one.
Phase 1: Encryption and Data Isolation
The S3 situation was the most urgent remediation. We audited every bucket, enabled server-side encryption with AWS KMS-managed keys on all buckets containing or potentially containing PHI, and removed the public access configuration from the legacy bucket. We also implemented S3 Block Public Access at the account level to prevent this class of misconfiguration from recurring.
For the database, RDS encryption was already in place, but we hardened the key management: created a dedicated KMS key for PHI data with a key policy that restricted usage to specific IAM roles, and documented the rotation schedule (annual, automated).
We also implemented encryption in transit enforcement — a HTTPS-only policy on all load balancers and an SSL-required flag on the RDS parameter group. Both were already largely in place, but the documentation was missing and one staging environment had HTTP allowed.
Finally, we segregated PHI storage from non-PHI data at the infrastructure level: a dedicated RDS instance for PHI-containing tables with its own security group, subnet placement, and IAM policy. This made future audits simpler and reduced the scope of HIPAA applicability for their non-PHI product features.
Phase 2: Audit Logging Infrastructure
We built a PHI access audit trail directly into the application layer using a combination of database triggers and application middleware.
For the database layer: PostgreSQL's pgAudit extension was enabled with logging configured to capture all SELECT, INSERT, UPDATE, and DELETE operations on tables containing PHI. These logs were shipped to CloudWatch Logs and then to S3 with object-lock enabled (WORM storage, 7-year retention to satisfy HIPAA's 6-year minimum with margin).
For the application layer: a Rails middleware module was added that logs authenticated user identity, the specific PHI record accessed, the action taken, the source IP, and a timestamp for every request touching PHI. Logs are structured JSON for easy querying. Sensitive field values are not logged — just record identifiers — to avoid the audit log itself becoming a PHI management problem.
We also built a lightweight admin interface that allows their compliance officer to run the standard HIPAA access reports: "Who accessed patient record X?", "What did user Y access in the last 30 days?", and "Show me all access events from IP address Z." These reports were demonstrated to the auditor as part of the SOC2 evidence.
Phase 3: BAAs, Vendor Risk, and Policy Documentation
The BAA remediation was more involved than it sounds. For each vendor handling PHI:
- Email service provider: Updated to use a HIPAA-eligible plan tier, executed BAA, audited which email templates included PHI and stripped non-essential PHI from automated message content where possible.
- Analytics platform: PHI was being sent to their analytics tool via event tracking. We implemented a PHI-scrubbing layer in the event pipeline that strips or hashes any fields that could identify patients before events leave the application boundary. Executed BAA as a belt-and-suspenders measure.
- Customer support tool: Support tickets sometimes included PHI pasted by users. We executed a BAA and implemented a data retention policy (30-day auto-deletion of closed tickets) aligned with their minimum necessary principle.
The HIPAA risk assessment was conducted as a structured process: asset inventory, threat identification, likelihood and impact scoring, existing control mapping, residual risk rating. The output was a risk register that became the foundation for their ongoing compliance program and directly satisfied one of the SOC2 risk management criteria.
Phase 4: Penetration Testing
Both frameworks benefit from third-party validation. We coordinated a penetration test scoped to the PHI-handling portions of the application and the underlying infrastructure.
The test identified four findings: one medium (missing Content Security Policy headers allowing potential XSS in the admin panel), two low (verbose error messages exposing stack traces, missing rate limiting on a non-auth endpoint), and one informational (outdated TLS cipher list including some weak ciphers that modern clients wouldn't negotiate but older clients could).
All findings were remediated and re-tested. The clean report was included in both the HIPAA risk assessment documentation and the SOC2 audit evidence package.
Frameworks and Standards Referenced
Healthcare SaaS compliance sits at the intersection of regulatory requirement (HIPAA) and market-driven standard (SOC 2). We layer established security frameworks over both:
- OWASP Top 10 — The penetration test was scoped against OWASP Top 10 risks. The Content Security Policy gap (potential XSS vector) maps to OWASP A03 (Injection) and A05 (Security Misconfiguration). Verbose error messages map to OWASP A09 (Security Logging and Monitoring Failures). Every healthcare SaaS application handling PHI should have OWASP Top 10 as a baseline design constraint, not an afterthought audit item.
- NIST Cybersecurity Framework (CSF) — NIST CSF is increasingly referenced in healthcare enterprise vendor questionnaires, and it maps cleanly to HIPAA's required and addressable safeguards. We used NIST CSF as the organizational spine for the risk assessment — the asset inventory, threat modeling, and control mapping all follow the NIST Identify → Protect → Detect → Respond → Recover structure.
- SANS/CWE Top 25 — CWE Top 25 rulesets were integrated into the CI/CD pipeline via static analysis to flag dangerous code patterns in the PHI-handling codebase. This is particularly important for Rails applications where object relational mapping can obscure SQL injection vulnerabilities (CWE-89) from developers who don't think in raw SQL.
SOC 1 and SOC 2 in healthcare: Healthcare companies primarily face SOC 2 requirements, but hospital systems with financial systems integration sometimes require SOC 1 (SSAE 18) as well — particularly if the platform interfaces with revenue cycle management or billing systems. Scope this early. Our Security & SOC 2 Compliance Engineering team can determine which audit types your specific prospect base requires before you commit to an observation period.
VAPT for HIPAA compliance: HIPAA's technical safeguard requirements include evaluation (§164.308(a)(8)), which most qualified assessors interpret as requiring periodic technical and non-technical evaluations including penetration testing. Manual annual pen tests satisfy the letter of the requirement; automated VAPT integrated into the development pipeline satisfies the spirit — and surfaces findings between annual tests. See our VAPT automation workflows for how we implement this for healthcare SaaS clients.
The Result
The compliance program took eight weeks end-to-end — longer than a pure SOC2 sprint because HIPAA's specific technical requirements added implementation work. Both the HIPAA attestation letter (prepared by a qualified compliance professional who reviewed our implementation) and the SOC2 Type II report were available when the two hospital LOIs converted to contracts.
The combined contract value was $380K in ARR. The compliance investment — our engagement plus the penetration test and the SOC2 audit firm fees — was a rounding error in comparison.
The company also reported that the compliance program had an internal benefit they hadn't anticipated: the audit logging infrastructure surfaced several instances of unusual data access patterns that turned out to be a misconfigured integration, not a breach. They caught it in the first month of monitoring. Without the controls, they might not have noticed for quarters.
What Makes Healthcare Compliance Hard
The hardest part of HIPAA + SOC2 isn't the technical implementation. It's the operational discipline: maintaining BAAs as vendors change, keeping the risk assessment current, running access reviews quarterly, and ensuring that PHI handling policies are actually followed by the people in the company who don't think of themselves as working in "security."
That last part — culture and operationalization — is what separates companies that pass an audit once from companies that maintain compliance as a durable capability. If you're building a product that handles PHI, we can help you get there.
Related Resources
More articles:
- Pre-Launch SOC 2 Foundation for AI Startups
- Fintech SOC 2 Type II in 3 Weeks
- How to Pass Your SOC 2 Audit
- VAPT Automation Workflows
Our solution: Security & SOC 2 Compliance Engineering
Glossary:
Comparisons:
Free Tool: Get our 30-item security checklist covering infrastructure, access control, monitoring, and compliance. → Security Compliance Checklist