Shared-Tenant PaaS Compliance Gaps for HIPAA and SOC 2 Startups
Shared-tenant PaaS platforms run your workload next to other people's workloads on the same hardware, same network, same control plane, same storage. That setup creates three specific compliance gaps for HIPAA and SOC 2 startups: auditability, isolation guarantees, and control plane visibility. You can't configure your way out of any of them, and as the HIPAA Security Rule tightens over 2025 and 2026, the gap between what shared PaaS offers and what regulators expect is only going to widen.
Here's the split that matters: you control your application, while the platform controls everything underneath it, and every gap in this piece traces back to that line. The settings you can touch, environment variables, app-level access controls, deploy configs, sit above the layer where most HIPAA and SOC 2 evidence actually needs to come from. And when the platform pushes an update, a bug or a vulnerability hits every tenant on that infrastructure at the same time, so you can't audit it beforehand, delay it, or scope your exposure to it. These vendors aren't being careless; the exposure is baked into how shared infrastructure works.
The three compliance gaps that shared tenancy produces: auditability, isolation guarantees, and control plane visibility
Auditability first. PHI moves through load balancers, storage systems, and internal networking that belong to the platform, not to you. The audit trail splits across layers you can't reach or export on your own, and HIPAA wants complete, tamper-evident logs, kept for six years, ready to hand over on demand. Most shared PaaS platforms don't give you that kind of control at the infrastructure layer. And it gets worse: application logs often capture more than anyone intended, including request parameters, error messages, and debug output. If PHI ends up in a log that flows to a service without a signed BAA, that's already a violation, whether or not anyone meant for it to happen. I've seen teams build what I'd call a paper program: all their audit evidence sits at the application layer, and it looks fine on paper. Then an auditor asks about the infrastructure layer, and there's nothing there. That gap doesn't stay hidden for long once someone starts asking real questions.
Second, isolation. Weak tenant isolation is the core risk in any shared environment, and the platform tells you it's isolated, but you have no way to check that yourself. Dev and staging environments make this worse: they almost never carry the same controls as production, and once PHI touches a staging environment, your compliance scope just grew in a way that's genuinely hard to document or defend later. AI APIs are the newest version of this problem. If patient data passes through a third-party AI API that hasn't signed a BAA, that's an unauthorized disclosure, regardless of how carefully you configured the PaaS platform around it.
Third, control plane visibility. You have no window into who at the provider can touch your running workload, under what conditions, or with what logging attached to that access. HIPAA's minimum-necessary rule applies to the infrastructure operator too, not just to you, but shared PaaS customers have no way to audit or enforce that at the layer where it counts. And the newer HIPAA rulemaking asks for something specific: a continuously updated inventory of every system that touches ePHI, cloud workloads included. On shared infrastructure, you don't fully see or control that inventory. Meeting this requirement means either heavy manual documentation or provider cooperation that most platforms simply don't offer as a standard feature.
What a BAA actually covers — and what it leaves entirely to you
A BAA is a legal document that sets accountability and splits up responsibility between you and the vendor, but a signed BAA doesn't guarantee the vendor has already built the safeguards you need. A provider can sign a BAA with you and still leave nearly all the real security work on your plate: encryption key management, whether your audit logs are actually complete, access controls, breach detection. The BAA is the floor. The ceiling is much higher, and reaching it is on you.
There's no such thing as official "HIPAA certification" for a hosting provider, and none exists. So when a vendor says their infrastructure is "HIPAA-eligible," what they mean is: their environment can support compliance, and they'll sign a BAA with you. Whether your system is actually compliant depends entirely on how you set it up and run it from there.
A few things worth doing before you sign anything: ask for the provider's written shared responsibility model, confirm the BAA actually covers your specific plan and the services you're using (not just "the platform" in general), and get a breach notification SLA in writing. A lot of providers only hand over SOC 2 Type II reports and BAAs once you're on a higher-tier plan, which means the documentation you need to check their controls often requires an enterprise contract you weren't planning to sign yet. A signed BAA paired with a current SOC 2 Type II report is meaningfully stronger evidence of a vendor's security posture than a BAA on its own. But neither one closes the structural gaps if the infrastructure underneath is still shared-tenant.
How each major shared PaaS platform handles HIPAA and SOC 2 in practice
Heroku requires Heroku Shield, an enterprise add-on, for HIPAA-eligible workloads. It brings network isolation, hardened runtime controls, and managed data services. Shield builds the guardrails: encryption, private networking, operational separation. But your application-layer safeguards, your policy documentation, and your BAA with Salesforce are still on you. BAA access is gated to enterprise contracts, which puts early-stage teams in an awkward spot: run without a BAA, or pay enterprise pricing well before you need enterprise scale. The SOC 2 report is current, but teams aiming for HITRUST or continuous compliance evidence may find the platform's posture falls short, not because Heroku regressed, but because the bar around them keeps rising.
Render rolled out HIPAA-enabled workspaces in 2025, available on Organization and Enterprise plans with a real monthly floor plus usage pricing on top. You get SOC 2 Type II, audit logs, and role-based access control. But getting the actual SOC report means a higher-tier plan and an NDA, which adds friction right at the point where you're trying to do due diligence.
Vercel holds SOC 2 Type II attestation for Security, Confidentiality, and Availability. The HIPAA report is Enterprise-only. HIPAA-adjacent work can use Vercel Secure Compute, also Enterprise, for VPC peering and VPN support, and standard pricing tiers don't get access to any of it.
Railway is SOC 2 Type II certified, with a HIPAA BAA available on Enterprise plans once you clear a paid monthly spend threshold. Their shared responsibility model has one detail worth calling out: once a BAA is active, the Railway team can't directly access your running workload. That's a real isolation commitment, though it also means more of the operational support burden shifts back onto you.
Fly.io is SOC 2 Type II certified, and its HIPAA BAA comes as a paid monthly add-on at a price that's genuinely more accessible than most enterprise-tier alternatives. Worth knowing: Fly.io has racked up a fair number of tracked platform incidents since launch, which matters for regulated production workloads where uptime itself is part of your compliance story.
The pattern holds across all of them, with compliance features sitting behind higher plan tiers every time. For a startup facing HIPAA requirements well before it has enterprise-level budget, that's a structural mismatch, not a one-off inconvenience.
Why the 2025–2026 HIPAA Security Rule update raises the bar precisely where shared PaaS is weakest
HHS put out proposed rulemaking in late 2024 that would make encryption at rest a required specification instead of an addressable one. That flexibility organizations used to lean on, to defer it or scope around it, goes away.
The proposed rule also asks for something shared PaaS is bad at by design: an accurate, continuously updated inventory of every system touching ePHI. Endpoints, mobile devices, cloud workloads, third-party SaaS, customer portals, all of it. On shared infrastructure, you don't fully control or see the underlying system inventory. Satisfying this means either a lot of manual documentation work or provider cooperation most platforms don't offer out of the box.
The encryption language points toward customer-managed keys stored in hardware-backed HSMs, a control that shared-tenant platforms typically don't offer to standard-tier customers at the infrastructure layer. And the audit log retention requirements, complete, tamper-evident, six years, exportable, run straight into the same auditability gap from earlier: you can't guarantee log completeness at layers you don't control.
Every direction this rule is heading points the same way: more specificity, more documentation, more evidence that the customer, not the platform, has to own. Architectures where you actually control and can see your own infrastructure are built for this reality. Shared-tenant PaaS was built for a different set of priorities.
How SOC 2 requirements compound the HIPAA gaps for startups selling to enterprise buyers
SOC 2 and HIPAA aren't competing frameworks, they work together, and a lot of healthcare tech companies carry both. Enterprise health systems and payers increasingly want SOC 2 Type II as a condition of even talking to you, regardless of your HIPAA status. SOC 2 audits check the same underlying controls HIPAA cares about: access management, encryption, monitoring, incident response. So a gap in your shared PaaS setup doesn't just show up once; it shows up in both audits.
First-year SOC 2 costs range from manageable for a small team to a real line item for a bigger one, and that's before counting the security tooling, internal team hours, and readiness work layered on top of the audit fee itself. Compliance automation tools can cut a good chunk of that cost through automated evidence collection and ongoing monitoring. And realistically, one solid enterprise contract usually covers the entire cost of a Type II audit, which makes the investment make sense even for an early-stage company.
Control inheritance is the part people underrate. If your infrastructure provider already holds SOC 2 Type II and HITRUST certification, you inherit part of their control set, which shrinks your own audit scope, cost, and timeline. But shared PaaS platforms only pass along inheritance for the specific controls they've attested to, and that list usually stops well short of the infrastructure layers where the real gaps live. HITRUST R2 is the top of the mountain here; enterprise health systems and payers increasingly treat it as a prerequisite for bigger deals, and building on infrastructure that's already HITRUST certified gives you inheritance that speeds up your own path there considerably. Meanwhile, doing compliance yourself on shared PaaS eats a real chunk of engineering time every month, time spent on infrastructure maintenance instead of product.
What single-tenant infrastructure actually changes about the compliance picture
Single-tenant means your workloads run on dedicated infrastructure inside your own cloud account, AWS, GCP, or Azure, instead of on the provider's shared substrate. The isolation guarantee stops being something you take on faith. It's enforced by the cloud provider's account boundary itself, not by a PaaS vendor's internal promises.
The auditability gap closes here. You get direct access to native logging and monitoring: CloudTrail, Cloud Audit Logs, Azure Monitor. Logs are complete, exportable, and under your control from the infrastructure layer on up. Control plane visibility closes too, since you own the control plane, cluster management, networking, IAM, and you can document it, lock it down, and audit access to it yourself.
Encryption key management becomes something you can actually do at the infrastructure layer, customer-managed keys in hardware-backed HSMs, which lines up with exactly where the proposed HIPAA rule is heading. And the system inventory requirement stops being a nightmare, because you own the cloud account and can list out every resource touching ePHI yourself.
The usual objection to single-tenant is operational complexity: you'd need a dedicated DevOps team to run it. That objection made sense a few years back, but it doesn't hold the same weight anymore. Platforms built on a bring-your-own-cloud model, where the provider handles cluster operations, upgrades, CVE patching, and autoscaling inside your own cloud account, Porter, which deploys into customers' own AWS, GCP, or Azure accounts, is one example of this approach, close that gap. You get single-tenant isolation while a much smaller team handles the operational load. Some platforms in this space deploy production-ready environments straight into a customer's AWS, GCP, or Azure account and cover the full lifecycle: VPC setup, CI/CD, autoscaling, and compliance-oriented configuration. The operational weight of running single-tenant infrastructure stays with the platform layer instead of landing on your product team's desk.
Practical steps a startup can take now to assess and close its compliance exposure
Start by mapping your data flows: every system that touches PHI or ePHI, including application logs, staging environments, and any third-party API, AI APIs especially, processing patient data.
Then audit what your BAA actually covers. Confirm it applies to your specific plan and services, not just "the platform" as a whole, and get the written shared responsibility model and a documented breach notification SLA, in writing, not in a sales call.
Ask every vendor in your stack for their SOC 2 Type II report, not Type I, and note which ones make you sign into a higher tier just to see it. That friction is itself a finding worth writing down.
Check whether you can actually produce a tamper-evident, exportable log from the infrastructure layer for a six-year window. If the honest answer depends on your PaaS provider cooperating, write that dependency down explicitly, don't let it stay implicit.
Look hard at your dev and staging environments, since PHI touching those environments expands your compliance scope quietly, and those environments should either match production controls or exclude PHI entirely.
If you're pre-Series A and already facing HIPAA requirements, the pattern of gating BAAs behind enterprise tiers means your infrastructure choice is also a business model choice. Factor compliance access into how you evaluate a platform, the same way you'd factor in features or pricing.
And if you're weighing a move off shared PaaS: the path involves mapping out infrastructure isolation, planning database export and restore, cutting over endpoints and DNS, and validating the audit trail before and after cutover. With the right platform handling the operational lift, that migration is a lot more manageable than most teams assume going in.
