SOC 2 Compliance Gaps on Shared PaaS Platforms

Shared PaaS platforms carry real SOC 2 Type II attestations, and that single fact misleads more engineering and compliance teams than almost anything else in the audit preparation space. The attestation covers the vendor's infrastructure — full stop — like a lease that only covers the building, not what you do inside your unit. It does not cover what you built on top of it, how you provisioned access, or whether your incident response process would survive scrutiny. When your auditor arrives, the evidence gap between what the platform's report proves and what your SOC 2 report requires is almost entirely yours to fill. Most teams discover this far too late.

Fewer teams have actually traced the shared responsibility model's implications through the Common Criteria, control by control, to see where the evidence burden lands. So here is where it lands.

Access control. CC6 requires documented evidence of access reviews: who can deploy, who can read production logs, who can touch customer data, who reviewed those permissions, and when. The PaaS manages its own platform-level authentication. Your IAM is yours. No shared platform generates access review evidence on your behalf, because it has no visibility into your organizational structure or your authorization policy.

Logical access and network topology. CC6.1 through CC6.6 require evidence of network segmentation, private networking architecture, and egress controls. On a shared platform, that infrastructure is opaque by design. You cannot produce a diagram of network boundaries you do not control, and the auditor will notice that you are trying to.

System monitoring and audit trails. CC7 requires more than application logs. Auditors want a complete audit trail: who changed which configuration, when, under what authorization, whether that change was reviewed. PaaS platforms surface application-level output. The change history of the environment itself, including who modified environment variables, scaling settings, or access credentials, typically falls outside the vendor's logging scope entirely. That is a gap you cannot paper over.

Change management. Shared PaaS platforms are fast precisely because they do not enforce change approval workflows. That speed is the product. But CC8 requires documented evidence that production changes went through an approval gate before deployment. The platform generates none of that evidence. Your process has to, and the process has to be real rather than reconstructed after the fact.

Incident response. The vendor's status page documents the vendor's incidents. CC7 and A1 require you to evidence your own detection, escalation, and remediation procedures, including how you communicate with affected customers. Pointing an auditor to a vendor's incident history does not satisfy that requirement. These are distinct documents, distinct processes, and distinct evidence categories — and any auditor worth their rate knows the difference immediately.

Vendor governance. CC9.2 requires you to treat the PaaS itself as a third-party vendor in scope: document their controls, monitor for material changes to their attestation, maintain that inventory on an ongoing basis. Most teams build this control exactly once, during their first audit preparation cycle, and never revisit it. Auditors find this reliably.

Why Multi-Tenancy Makes These Gaps Structurally Harder to Close

Tenant isolation is not a trivial control. It is foundational to every CC6 finding in a shared infrastructure environment, and the problem is that on a shared PaaS, you cannot independently verify it. You are trusting the vendor's attestation, which may not map to your specific workload configuration, your data classification, or the network paths your application actually traverses. That is a faith-based compliance posture, and faith does not hold up well under operating effectiveness testing.

Authentication misrouting and shared token reuse fail quietly. Trust boundary violations in a multi-tenant environment do not always produce loud errors; they can cross before logging captures them, which is precisely the failure mode auditors probe when they test CC6.

Configuration drift compounds this. On a shared PaaS, customers often lack the instrumentation to detect drift in the first place, because the platform abstracts the configuration layer away from them. That abstraction is the feature they paid for. It is also the audit liability, because you cannot document infrastructure you cannot see, let alone control.

Enterprise procurement teams have started encoding this problem in their vendor questionnaires. Automated evidence of tenant isolation and logical separation is increasingly a procurement requirement, not just an audit expectation. Manual documentation that asserts isolation by reference to a vendor's attestation is becoming insufficient for the buyers that matter most, and that shift is moving faster than most compliance programs are.

What Auditors Actually Flag When They Examine PaaS-Hosted Environments

These findings are not edge cases. They are predictable, which is almost worse, because they appear across audit cycles when evidence collection gets treated as a documentation exercise rather than a real-time operational discipline.

The most common CC6 finding has nothing to do with infrastructure at all. It is customer PII appearing in non-compliant systems: Slack messages, Jira tickets, support email threads. Compliance tooling monitors infrastructure. It does not scan content. The data that ends up in your ticketing system because an engineer copied a customer error message is invisible to your monitoring stack. It is also, under current guidance, a compliance finding.

Stale access reviews keep surfacing. Quarterly reviews that nominally occurred, with calendar invites and completed checkbox fields, but with no evidence of which permissions were reviewed or whether any access was actually revoked. The form of the control exists; the substance does not. Auditors have seen this particular theater before, and they are never fooled by it.

AI tool scope creep has become a named finding category in AICPA guidance, and this one catches teams off guard more than almost anything else right now. Engineers pasting customer data into AI assistants to summarize support issues or debug production errors is explicitly in CC6 scope when those systems handle customer data. This is happening on engineering teams everywhere. Most compliance programs have not caught up, and the gap between the behavior and the policy is widening.

Vendor scope drift haunts second-cycle audits specifically. The compliance inventory was accurate at initial certification. Two years later, a new payment processor has been added, logs are flowing to a new destination, and the scope boundary has never been updated. The inventory says data flows one way. The actual data flows another. That discrepancy is not easy to explain.

The penalty against Healthplex is worth sitting with. It was issued for failing to implement multi-factor authentication following a platform migration. The control did not fail dramatically; it simply was not carried through the transition, and no one noticed until enforcement arrived.

The Gap Between Compliance Tooling and Actual Control Effectiveness

Traditional compliance automation was built to prove that a control exists. The 2022 update to the Trust Services Criteria shifted the auditor's mandate toward testing operating effectiveness, not just control presence, and that shift exposed a real ceiling in what evidence-collection tooling can actually demonstrate. The tools did not change. The standard did.

The commercial pressure for SOC 2 reports is real. A substantial majority of enterprise buyers require SOC 2 compliance before vendor onboarding. The pressure to have a report is high. The bar for what the report needs to contain is rising simultaneously, and those two forces are not moving at the same speed.

On a shared PaaS, compliance tooling can confirm that a deployment happened. It cannot confirm that the deployment went through an approved change process, that access was provisioned within policy, or that the resulting configuration matches the approved baseline. The tooling surfaces what the platform exposes. It cannot surface what the platform deliberately conceals because abstraction is the product.

No amount of tooling investment closes that gap while the infrastructure remains opaque. Compliance software running on a shared PaaS can automate evidence for the controls the platform surfaces. It cannot manufacture evidence for controls the platform structurally prevents. That ceiling is not a product limitation; it is an architectural one, and spending more on tooling does not change the architecture.

How Infrastructure Ownership Closes the Gaps That Shared Tenancy Keeps Open

When infrastructure runs in your own cloud account, the audit trail is yours to produce. IAM changes, network configuration changes, deployment approvals, log retention policies: all of it lives in your account, under your control, and is producible on demand. You are not waiting for a vendor to include something in their report or hoping their logging scope happened to cover the event you need to evidence.

Private networking, static IP allocation, and VPC configuration become customer-controlled artifacts rather than claims made by reference to someone else's attestation. Network segmentation is something you can document and demonstrate because you created it. When you built the control, you own the evidence.

Automated CVE patching and cluster-level configuration management, handled at the infrastructure layer, address configuration drift directly. When the platform is yours to configure, you can instrument it to detect and remediate drift continuously rather than discovering it during an audit cycle. That is a fundamentally different operational posture, and the difference shows up in findings.

Compliance scaffolding for frameworks like SOC 2 and HIPAA becomes a matter of platform configuration rather than a multi-month engineering project. The controls are enforceable because you control the plane where enforcement happens. That is not a subtle distinction.

Heroku's move to a sustaining engineering model, following a significant outage, has sharpened the migration calculus for teams that need compliance posture and product infrastructure to grow together. That conversation is happening now across a lot of engineering organizations, and it is not really a technical conversation anymore; it is a business risk conversation.

What a Compliance-Aware Migration From Shared PaaS Actually Requires

Migration is itself a high-risk compliance moment. The Healthplex situation is the clearest illustration of what that risk looks like in practice: a control that existed on the old platform simply did not exist on the new one, and nobody noticed until enforcement arrived.

Before cutover, re-examine CORS policies, rate limits, WAF rules, and secret management on the new platform. These are the controls most likely to regress silently during a move, because they are rarely the focus of migration checklists. Checklists tend to prioritize application behavior. Security configuration is almost always secondary, and that ordering is exactly backwards from a compliance standpoint. Fix the ordering.

Access reviews must be triggered by migration, not deferred to the next quarterly cycle. Provisioning on the new platform needs to be scoped correctly from day one. Cleaning up access after an audit observation is a remediation story, the kind you end up explaining. Getting it right before cutover is a compliance story. Those are not equivalent situations.

Observability must be confirmed before cutover, not retrofitted afterward. Logs, metrics, and tracing need to be flowing and verified before the first production request lands on the new infrastructure. Teams that assume observability will carry over and do not verify it end up spending months accounting for why their audit trail has a gap in it.

The compliance inventory must be updated at the moment of cutover. The old vendor out, the new infrastructure configuration in. Scope drift in the inventory is a disproportionate source of second-cycle audit findings precisely because teams update the application and defer the paperwork. The paperwork catches up eventually, usually in front of an auditor who wants to know why it took so long.

Teams running infrastructure in their own cloud account carry their compliance posture through a migration. The evidence trail is continuous and accountable. Teams moving between shared PaaS platforms often find themselves rebuilding audit trail coverage from zero and explaining a gap to an auditor who is not particularly interested in why it exists. That is a solvable problem. It just needs to be solved before the migration, not after.