PaaS Platform Compliance Shared Responsibility Models

One-click SOC 2 and HIPAA configuration can reduce infrastructure work for startups on AWS or GCP, but it cannot make an application compliant by itself. PaaS platform compliance shared responsibility models leave application code, access controls, encryption keys, and data handling with the customer. A practical compliance program starts by identifying that boundary, then covering the controls that automation does not own.

Why PaaS compliance feels complete but isn't

Onboarding to a HIPAA-eligible PaaS can feel like finishing compliance work. The business associate agreement, or BAA, is signed, the platform has its certification, and the infrastructure is managed. For an engineering team, those are concrete signs of progress. The mistake is treating them as proof that the product running on that infrastructure is covered too. Operational relief is easy to see, while the obligations left behind are less visible.

A provider takes over work that previously demanded engineering attention, so it seems reasonable that compliance work moves with it. Some of it does, but the transfer stops short of the application and its use of sensitive data. The HHS Office for Civil Rights makes the governing principle clear that outsourcing infrastructure does not outsource liability. A BAA defines a relationship.

The provider can demonstrate control over its environment without demonstrating how an application handles protected health information, or PHI. If a team treats the former as proof of the latter, the gap remains unowned. That is where an apparently finished compliance effort can leave room for a breach or audit failure.

How the shared responsibility line moves depending on service model

AWS describes the split as “Security of the Cloud” and “Security in the Cloud.” The first is the provider’s domain, and the second is the customer’s. Azure and Google Cloud use the same broad idea but describe it in different terms. The provider’s responsibility has a boundary in the software stack. That boundary moves with the service model.

With infrastructure as a service, or IaaS, the provider owns physical facilities, hardware, networking, and the hypervisor. The customer owns the layers above them, including the operating system, network configuration, identity, and data.

With PaaS, the provider additionally absorbs the operating system and runtime. That removes substantial patching and maintenance work, but application code, IAM configuration, encryption key management, and data handling remain with the customer. At the PaaS layer, a platform like Porter handles infrastructure-layer compliance tooling and control while customers remain responsible for how they configure and operate those tools in their own cloud accounts. Runtime ownership is the seam that often gets misread. Managing the environment that executes code is not the same as securing what that code does.

With software as a service, or SaaS, the provider also absorbs the application layer. The customer is then left with data governance and access permissions. PaaS stops before that point. Borrowing assumptions from SaaS leads to an incomplete control plan. Moving from IaaS to PaaS transfers operating system maintenance to the provider while the customer continues to decide which application users can reach patient data.

What PaaS providers actually own under HIPAA and SOC 2

The provider side of the boundary contains substantial work. Physical security includes controls on who can enter a facility, surveillance, and biometric entry. Hardware security covers compute, storage, and networking equipment, as well as how old drives are safely disposed of. Hypervisor isolation keeps customers’ workloads separated on shared physical hardware, while infrastructure-level network segmentation adds another boundary. Host operating system and runtime patching address the software underneath the customer’s application.

These controls form the foundation on which application controls depend, and a managed platform takes meaningful operational work away from the customer. Porter handles runtime patching, network-layer security, and infrastructure isolation, so the application team does not have to do all that work itself. The limit is that infrastructure controls cannot decide whether application access is appropriate or whether PHI is being handled correctly.

A provider’s SOC 2 Type 2 report describes the controls in place in the provider’s own environment. Supabase’s SOC 2 documentation states the limit explicitly in the following sentence. “Supabase's SOC 2 compliance does not transfer to environments outside of the Supabase product or Supabase's control”. Customers must read the provider’s report to see whether its controls meet their needs.

HIPAA eligibility has a similar boundary. AWS, Azure, and Google Cloud offer HIPAA-eligible services and will sign a BAA, but not every service on those platforms qualifies. Even an eligible service still requires an appropriate configuration. Providers contribute encryption tools, audit log infrastructure, IAM frameworks, and compliance monitoring services. Those are instruments customers can use to meet their obligations, rather than outcomes delivered simply by opening an account.

The customer-retained layer: where the actual risk lives

The controls left with customers govern what the application does, who can use it, and what happens to sensitive data. A patched runtime does not correct a logic error, secure an improperly exposed API endpoint, or repair improper PHI handling in application code. Those remain the customer’s responsibility.

Identity and access management, or IAM, makes the distinction concrete. HIPAA requires each user to have a unique identifier, so shared credentials are not acceptable simply because the platform is secure. Giving every developer global admin rights conflicts with the HIPAA Privacy Rule’s “Minimum Necessary” standard. Customers must configure Multi-factor authentication and role-based access controls and regularly check for and deactivate inactive accounts. The infrastructure can enforce permissions, but the customer must decide which permissions belong to which people.

Encryption presents the same division of labor. Providers supply encryption tools and key management infrastructure, but customers must configure protection at rest and in transit and manage their keys. An unencrypted storage bucket is not fixed by the provider’s certification. The S3 misconfiguration example shows the liability boundary sharply when a customer’s bucket configuration exposes PHI. The customer organization is responsible for the breach, even though the storage runs on a provider’s infrastructure.

Logging can leave a quieter gap because having the facility is not the same as collecting the required evidence. Supabase’s SOC 2 documentation notes that Postgres connection logging is off by default for new projects, leaving customers to enable it. The retention requirements also differ, with six years for HIPAA audit logs and typically one year for SOC 2. A default that does not meet the applicable retention requirement leaves the customer short, regardless of whether the provider offers logging infrastructure. The control requires customers to turn on logging, keep the records they need, and review them.

Every sub-processor that handles PHI needs a signed BAA, so a service without one can break the chain even when the main cloud agreement is in place. If the provider suffers a breach, it notifies the customer. The customer then carries responsibility for notifying affected individuals, the HHS Secretary, and potentially the media. The product company cannot hand off that obligation, or the reputational consequences, with its infrastructure.

How compliance gaps widen when teams scale rapidly or handle AI workloads

A configuration that covers the initial product does not automatically cover its expansion. Rapid deployment of new virtual machines, storage systems, or databases creates more settings for teams to manage, and security configuration can be overlooked. The same risk appears when a new feature changes how sensitive data is handled. A baseline assessment loses value if it no longer describes the running system.

Each platform implements its own security and access controls, so a consistent policy does not necessarily mean a consistent configuration. When PHI is distributed across providers, data residency and regional compliance also become harder to audit. The team must be able to account for the controls and obligations attached to each part of the environment.

AI workloads touching patient data extend the same responsibilities into infrastructure that may offer less mature compliance tooling. Most GPU-specialized infrastructure was not built with healthcare compliance in mind, and support for IAM, encryption, and audit logging can be less mature on GPU-focused platforms. Training or inference does not remove any of the customer’s PHI obligations. Teams must verify that the GPU infrastructure provider will sign a BAA and support the required controls. Compute suitability and compliance suitability are different questions.

Across these cases, the trigger is operational change. A new region, product feature, or sub-processor can expand the compliance boundary without changing the team’s original assumptions about it. Organizations that covered their baseline can therefore fail an audit after growth if they do not reassess the customer-retained layer. To keep up with these changes, the cloud compliance program needs continuous monitoring and disaster recovery planning. The program must describe the environment as it changes.

How to get HIPAA and SOC 2 ready on a PaaS without a dedicated compliance team

A practical program starts with the full BAA chain, including the primary provider’s agreement. Every sub-processor handling PHI needs documented coverage before the team assumes that coverage exists. This establishes which services can participate in the system and where contractual gaps remain. The provider’s SOC 2 Type 2 report then helps show which controls it has attested to and which the customer must put in place.

MFA and role-based access controls need to be in place from day one, and only roles that need electronic PHI should have access to it. Shared credentials have no place in accounts that can reach PHI. Checking for and deactivating inactive accounts on a set schedule keeps permissions in line with what people need now. Encryption at rest and in transit also needs explicit configuration, with encryption keys managed and documented.

Audit logging needs the same deliberate treatment. PHI access logging must be enabled and actively monitored, and retention defaults must be overridden where they fall short of HIPAA’s six-year requirement. The broader assessment should include both the cloud environment and on-premises systems. Conducting and documenting a Security Risk Analysis at least annually and after major changes gives the program a review rhythm. Annual assessment is strongly recommended by OCR and proposed for formal codification, while the current rule requires periodic reassessment without specifying an exact interval.

Treating infrastructure changes as Git commits creates an audit trail with an author, timestamp, and review history, giving GitOps evidence of control over change. That matters when a growing team needs to show how its current environment came to be. The record supports the assessment instead of leaving reviewers with only the final configuration.

Through deployment into a customer’s own AWS, GCP, or Azure account, Porter combines cloud ownership with automation for work such as CVE patching and infrastructure-level SOC 2 and HIPAA configuration. For a startup without a dedicated compliance team, the meaningful criteria are supported controls, clear ownership, and evidence that those controls are operating. Compliance on a PaaS is a maintained program.