Shared-Tenant PaaS Compliance Gaps for HIPAA and SOC 2 Startups

Shared-tenant PaaS creates compliance exposure for HIPAA and SOC 2 startups that no BAA or checklist can fully fix. The gaps trace back to multi-tenancy itself, an architectural reason.

Most founders believe that signing a Business Associate Agreement with their cloud host, then turning on encryption, transfers responsibility for compliance to the provider. That belief is wrong, and it's wrong in a specific, costly way. A signed BAA covers only the provider's share of the work. Everything else, misconfigured services, access controls that are too loose, storage left unencrypted, logging that doesn't capture what an auditor needs, stays the customer's responsibility no matter what the contract says. Call it the cloud provider fallacy: the provider secures the cloud itself, and the customer secures what runs on top of it.

This gap exists at the architectural level and can't be closed by changing a setting. On shared-tenant infrastructure, the database layer is shared, the control plane is shared, the update schedule is shared, and, for AI workloads, the GPU memory is shared. Every one of those is a single architectural decision made upstream of anything the tenant configures. Isolation failures, paths for lateral movement between tenants, and update windows that hit every customer at once all live at a layer the tenant can't reach, so you can't fix them with a config change. That's the frame for everything that follows: the problem sits in the architecture, and architecture is what has to change to solve it.

2026 HIPAA Security Rule infrastructure requirements

The regulatory bar has moved, and it has moved toward the controls that shared-tenant platforms handle worst. The proposed 2026 HIPAA Security Rule update (still an NPRM, not yet finalized or enforced) sets a strong preference for phishing-resistant hardware keys and biometrics as the authentication method of choice. SMS-based MFA gets reclassified as a "restricted authenticator," the weakest option HHS will still accept.

System restoration gets harder to fudge, too. A BAA can no longer just reference a 72-hour restoration target on paper. It has to commit to demonstrating that restoration actually works within that window. The infrastructure underneath has to support a real test, not a policy document sitting in a shared drive.

CI/CD controls are moving the same way, even if the proposed rule doesn't name them. Questions auditors increasingly ask: who can push to production, whether the pipeline runs with least privilege, whether secrets live in a proper secrets manager instead of an environment variable, whether a change to a workflow file gets the same peer review as a change to application code. None of this is explicitly mandated by the 2026 rule as written. It's becoming the practical bar startups get held to anyway.

The clearest signal of where enforcement already lands: the HHS Risk Analysis requirement is the most frequently cited violation in 2026 enforcement actions. The proposed rule would tighten this further, requiring a written risk analysis built on an actual technology asset inventory and network map, with specific threat-vulnerability pairs identified rather than general language about "appropriate safeguards." None of this is finalized yet. All of it points the same direction: toward infrastructure that can produce real evidence.

The four structural vectors where shared tenancy undermines isolation

Shared-tenant PaaS can fail compliance in four distinct ways, and no per-tenant configuration closes any of them, because all four sit at the infrastructure layer the tenant never touches.

The first is the shared database and storage layer. If logical separation between tenants isn't airtight, a query error can hand back another customer's data instead of an access-denied response. Row-level security and schema isolation have to be implemented correctly at every single layer for this not to happen, and the tenant has no way to verify that it was. The Meltdown and Spectre vulnerabilities showed the same problem one level deeper: shared CPU caches could be read across tenant boundaries. Software fixes like KPTI and Retpoline closed most of that gap, though not every variant, every time.

The second vector is overlapping permissions. Shared platforms run complex permission structures, with role definitions that don't match cleanly across tenants and inheritance rules that can grant more access than intended. A flaw in a shared authentication service doesn't stay contained to one customer. It hits every customer running through that service, all at once.

The third vector is supply chain exposure and lateral movement. In a shared environment, the least secure tenant becomes the entry point for everyone else. A compromised shared library, a vulnerable third-party API integration, a backdoored dependency, any of these affects every tenant running on that shared runtime, not just the one that got targeted.

The fourth vector is the synchronized update window. Platform-wide updates roll out to every tenant at once, so an undiscovered flaw in that update exposes every customer simultaneously. An organization with dedicated infrastructure can control the timing of its own updates and stagger rollouts to limit blast radius. Shared PaaS removes that option by design: the update applies to everyone, on the platform's schedule, whether a given tenant is ready or not.

The BAA chain problem: why contracting cannot substitute for architecture

A BAA is a legal acknowledgment that responsibility exists. It leaves the infrastructure that created the risk in the first place unchanged.

The chain of agreements has to reach every sub-processor touching patient data, with no exceptions. HHS treats any cloud service provider that collects, receives, maintains, or transmits PHI as having persistent access to that data, even under a zero-knowledge architecture the provider claims limits its own visibility. A BAA is required regardless of what the provider says about its own access. If an AI API is processing patient notes and that vendor hasn't signed a BAA, ePHI has already been disclosed to an unauthorized third party. The exposure for most health-tech startups right now sits in that downstream gap.

The Change Healthcare ransomware attack put a number on what vendor-level risk actually costs: over a hundred million individuals affected. The breach vector there was a Citrix remote-access portal running without multi-factor authentication, and that's a failure at the platform's own security layer. It's a case study in how a single weak point in vendor infrastructure can cascade into a breach of national scale.

Modern BAAs now have to commit to demonstrable 72-hour restoration, a capability that depends on how the infrastructure is built.

This is where the chain breaks for a SaaS company built on shared-tenant PaaS. That company cannot independently verify or demonstrate isolation to its own enterprise customers. It can only repeat whatever claims the PaaS vendor makes about its own environment. Enterprise buyers increasingly want proof, not a pass-through claim, and a startup standing on borrowed infrastructure has nothing else to hand them.

SOC 2 auditors' expanded scope: infrastructure and CI/CD pipelines

SOC 2 has become the price of entry for enterprise SaaS sales, and auditors have widened what counts as in-scope infrastructure well past the application layer.

The CI/CD pipeline is now part of that audit surface. Auditors check who holds push access to production repositories, whether the pipeline operates with least privilege, whether secrets sit in a dedicated secrets manager instead of code or environment variables, and whether a change to a workflow file goes through the same review as a change to the application itself. On shared-tenant PaaS, the tenant usually has no control over the CI/CD runner environment. The isolation and access controls around that runner belong to the platform, and the customer has no way to independently attest to them in an audit.

Granola, an AI note-taking company, made SOC 2 certification a founding priority for its operations lead, because it wanted to reassure enterprise customers early, well before the company reached any scale that would force the issue. That's the pattern across fast-moving product startups now: the audit pressure arrives early, not later.

SOC 2 Type I checks controls at a single point in time. Type II requires an extended observation window and is what enterprise procurement and regulated-industry buyers actually ask for. That distinction decides how early a startup needs to start building an infrastructure record it can actually produce when asked, rather than scrambling to construct one retroactively.

The GPU VRAM problem: why AI workloads on shared clusters create a compliance gap no BAA can address

AI workloads running on shared GPU clusters create an exposure that has no software fix. When an inference job runs on shared hardware, its inputs can end up sharing VRAM, caches, or processing pipelines with another organization's data while both jobs are actively computing.

The attack path here sits below every layer a startup normally secures. A privileged process on the host, a hypervisor, a management daemon, or an administrator with the wrong level of access, can read model weights and inference inputs straight out of GPU VRAM while the GPU is mid-computation. TLS doesn't reach that layer. Disk encryption doesn't reach it. A network firewall doesn't reach it either. The data is exposed in memory, in use, on hardware shared with other tenants.

NVIDIA's Confidential Computing mode closes this gap, and it closes it in hardware, not software. It encrypts VRAM using a key generated inside the GPU's own security processor, and that key is never exposed to the host software running alongside it. It encrypts the PCIe bus, so traffic moving between CPU and GPU is ciphertext the whole way across. And it adds cryptographic attestation, letting the workload owner check the GPU's firmware and security state before trusting it with anything sensitive.

This isn't available on every GPU. Confidential Computing mode works on H100 SXM5 and PCIe (Hopper architecture), H200 SXM5, B200 SXM6 (Blackwell, with encrypted PCIe 5.0 and NVLink), and GB200 (Grace-Blackwell). The A100 and older Ampere-generation chips don't support it at all, and A100s are still common on commodity GPU clouds that plenty of startups use by default.

For healthcare or any regulated AI inference workload, compliant operation requires GPU resources dedicated to a single organization. That requirement conflicts directly with how commodity shared GPU clouds are built, and no contract changes that fact.

What "logically isolated" means in a shared-tenant audit

The claim that shared-tenant infrastructure is automatically non-compliant doesn't hold up. HIPAA does not require physical, dedicated servers. Logical separation can satisfy the standard when it's built correctly.

Built correctly means a specific set of things, all present at once. Each tenant's data needs unique encryption keys. Data needs identifiers tying it to a single tenant with no query path that crosses into another tenant's records. Network traffic needs separation even when it's running across shared physical hardware. And the Security Risk Analysis has to actually evaluate multi-tenancy risk directly, covering data residency, API security, and third-party integrations, with evidence behind the claim rather than a general assertion that isolation exists.

That last piece is where even a well-built shared-tenant environment runs into trouble. The tenant itself cannot independently verify that every one of those controls was implemented the way the platform says it was. It depends entirely on the platform's own attestation. Sophisticated auditors now probe exactly that second-order gap, asking not "does the platform claim isolation" but "can you prove it independently."

So saying shared tenancy is inherently non-compliant doesn't hold up as well as this does. Even in the best case, where the technical isolation is genuinely sound, the startup still can't produce the evidence on its own. Enterprise buyers increasingly require vendors to demonstrate control over their own environment, not assert it, and a startup running on someone else's shared platform has no independent way to meet that bar.

Compliance posture in your own cloud account

When infrastructure runs inside a customer's own AWS, GCP, or Azure account, the compliance posture shifts at the architectural level. The customer now controls the isolation boundary directly, can produce audit evidence without asking anyone's permission, and doesn't depend on a shared platform's say-so for a single control an auditor might ask about.

A few things become possible that weren't before. Audit trails are native to the account: CloudTrail, Cloud Audit Logs, or Azure Monitor logs belong to the customer and can be handed to an auditor directly, with no platform standing in the middle translating or withholding. Encryption keys stay with the customer instead of being generated and managed by a platform serving other tenants alongside them. Network isolation, VPCs, private subnets, VPC Service Controls, is something the customer configures and verifies on their own, not something they take on faith. The CI/CD pipeline runs inside that same account, so access controls, secrets management, and runner isolation are the customer's to set up and the customer's to attest to when an auditor asks.

All three major cloud providers, AWS, Azure, and Google Cloud, sign HIPAA BAAs and offer HIPAA-eligible infrastructure, each with healthcare-specific compliance tooling and audit logging built in. The foundation for compliant infrastructure already exists on all three. What changes the outcome is whether a startup builds on top of that foundation inside its own account, where it can prove every control directly, or rents a shared slice of someone else's account and hopes the platform's claims hold up when an enterprise buyer or a federal auditor asks for proof instead of a promise.