Your SOC2 auditor asks a simple question: "Who has access to your production database?" The answer you give depends entirely on how you architected your infrastructure. If you run on a managed PaaS, the honest answer is: "We do, and our vendor does, and we trust their attestation that they have appropriate controls." If you run in your own cloud account, the answer is cleaner: "We do. Here are the IAM policies. Here are the CloudTrail logs showing every access event for the past year."
That difference in answers represents a fundamental shift in compliance posture. The first answer introduces what auditors call a "compliance dependency." The second answer demonstrates what they prefer: direct control verification. For healthtech and fintech startups preparing for SOC2 Type II or HIPAA audits, understanding this distinction can mean the difference between a straightforward audit and weeks of back-and-forth gathering vendor documentation.
Compliance inheritance is the transfer of compliance burden that occurs when you run workloads on infrastructure you do not control. When your database runs on a vendor's servers, your compliance posture becomes partially dependent on their compliance posture. If your PaaS vendor experiences a breach, fails an audit, or changes their security practices, you inherit that risk whether you knew about it or not.
This is not a theoretical concern. When a major managed service provider experiences a security incident, every customer running on that infrastructure must assess their exposure, update their risk assessments, and potentially notify their own customers. The vendor's problem becomes your problem because their infrastructure is your infrastructure.
Compliance inheritance manifests in audit conversations as questions you cannot fully answer. "Show me your encryption key rotation logs." If your vendor manages the keys, you show their attestation letter. "Demonstrate your access control audit trail." If your vendor controls the infrastructure, you show their SOC2 report. Each of these responses introduces a layer of indirection between your auditor and the actual evidence.
There are two fundamentally different ways to demonstrate compliance to an auditor. The first is attestation-based compliance: you trust that a third party has implemented appropriate controls, and you provide their attestation (typically a SOC2 report or similar certification) as evidence. The second is evidence-based compliance: you show the auditor direct evidence of controls you own and operate.
Attestation-based compliance is not invalid. Auditors accept vendor SOC2 reports as evidence of controls. But attestation introduces several complications that evidence does not:
Evidence-based compliance eliminates these complications. When you control the infrastructure, you show the auditor the CloudTrail logs, the IAM policies, the KMS key configurations, and the VPC flow logs. The evidence is current, complete, and directly verifiable. There is no trust chain because there is no intermediary.
When you deploy on a managed PaaS, your workloads run on infrastructure the vendor owns and operates. The vendor provisions the compute, manages the network, controls access to the underlying systems, and handles encryption key management. This creates a structural compliance dependency: you cannot prove controls you do not own.
Consider what happens during a SOC2 audit when you run on managed infrastructure. Your auditor asks for evidence of logical access controls. You can show them your application-level access controls, but the infrastructure-level controls belong to your vendor. You provide their SOC2 report. Your auditor asks for evidence of encryption at rest. You can confirm that encryption is enabled in your vendor's dashboard, but the key management, rotation schedule, and access audit trail are all managed by the vendor. You provide their attestation.
This pattern repeats for every infrastructure-level control: network segmentation, audit logging, incident response, backup integrity, and disaster recovery. Each time, you provide vendor attestations rather than direct evidence. Each attestation is a place where your auditor must trust rather than verify.
For HIPAA covered entities, this dependency becomes more acute. The HIPAA Security Rule requires covered entities to have specific technical safeguards in place. If your electronic protected health information (ePHI) resides on vendor infrastructure, you must ensure your vendor's controls satisfy HIPAA requirements. This typically means executing a Business Associate Agreement (BAA) with the vendor and relying on their compliance program. If the vendor's controls are inadequate, you bear the regulatory risk.
Bring Your Own Cloud (BYOC) is an infrastructure model where your deployment platform installs into your own cloud account rather than running workloads on the vendor's infrastructure. With BYOC, you own the VPC, the Kubernetes cluster, the IAM roles, the encryption keys, and the audit logs. The platform vendor provides the deployment automation and developer experience, but the infrastructure belongs to you.
This ownership model transforms compliance conversations. When your auditor asks who has access to your production database, you can answer definitively: "Only IAM principals with these specific roles, and here is the CloudTrail log showing every authentication event." When they ask about encryption key management, you show them your AWS KMS configuration and key policy. When they ask about network segmentation, you show them your VPC architecture and security group rules.
Direct control verification means your auditor can examine the actual controls rather than trusting attestations about controls. This is faster, more thorough, and leaves less room for misunderstanding. Your auditor does not need to assess a vendor's compliance program because the vendor is not in the data path.
Convox Rack deploys directly into your AWS, GCP, or Azure account. When you install a Rack, Convox creates an EKS cluster (on AWS), networking infrastructure, IAM roles, and supporting resources, all within your cloud account using your credentials. After installation, Convox has no runtime access to your infrastructure. The Rack runs autonomously in your account.
This architecture means several things for compliance:
Your data never leaves your account. Application data, database contents, secrets, and logs all reside in infrastructure you control. Convox does not operate servers that touch your data. There is no Convox-hosted control plane that your workloads connect to at runtime.
You own the audit trail. AWS CloudTrail logs every API call in your account, including all operations performed by your Rack. When your auditor asks for access logs, you export them from your CloudTrail. When they ask about configuration changes, you show them your CloudTrail event history.
You control encryption keys. Convox Rack uses AWS KMS for encryption. The keys exist in your AWS account, governed by key policies you define. You control who can use the keys, and AWS logs every key usage event.
You define IAM policies. The IAM roles that Convox creates during installation exist in your account. You can review, modify, and restrict these roles. You can implement additional controls like SCPs (Service Control Policies) at the organization level.
With a Convox Rack running in your AWS account, you can provide auditors with direct evidence of infrastructure controls:
Access Control Evidence: IAM policies attached to the Rack's service roles show exactly what permissions the infrastructure has. IAM users and roles in your account show who can access what. CloudTrail logs demonstrate that access controls are enforced, showing successful and denied access attempts.
Encryption Evidence: KMS key configurations show encryption algorithms and key rotation status. Key policies demonstrate who can use encryption keys. CloudTrail logs show every encrypt and decrypt operation, proving encryption is actually in use.
Network Segmentation Evidence: VPC configurations show network architecture. Security group rules demonstrate ingress and egress controls. VPC Flow Logs (if enabled) show actual network traffic patterns.
Audit Logging Evidence: CloudTrail logs provide a complete record of API activity. CloudWatch Logs contain application and system logs. S3 bucket policies on log storage demonstrate log integrity controls.
For organizations with stringent compliance requirements, Convox Rack supports deployment into AWS GovCloud regions. GovCloud provides infrastructure that meets FedRAMP High baseline requirements and supports ITAR-controlled workloads. Because Convox Rack deploys into your account, you can use GovCloud simply by installing the Rack in a GovCloud region.
For HIPAA compliance, the BYOC model means your ePHI never transits Convox infrastructure. Your Business Associate Agreement obligations are with AWS (or your chosen cloud provider), not with Convox. This simplifies your compliance posture: you have one BAA with your cloud provider rather than BAAs with both your cloud provider and your PaaS vendor.
The difference is significant during audits. When auditors ask about your ePHI processing environment, you can demonstrate that all processing occurs within your AWS account, governed by your IAM policies, encrypted with your KMS keys, and logged to your CloudTrail. There is no managed service provider in the data path that requires separate compliance verification.
The following table illustrates how auditor questions are answered differently under managed PaaS versus BYOC architectures:
| Auditor Question | Managed PaaS Response | Convox BYOC Response |
|---|---|---|
| Who can access production data? | Our team plus the vendor's operations team per their SOC2 report | Only IAM principals in our account. Here are the policies and CloudTrail logs. |
| Show encryption key rotation logs | Here is the vendor's attestation that keys are rotated annually | Here is our KMS key configuration showing automatic rotation, plus CloudTrail events |
| Demonstrate network segmentation | The vendor's documentation states workloads are isolated | Here is our VPC architecture and security group configurations |
| What happens if the vendor is breached? | We rely on their incident response and will be notified per our contract | Convox has no access to our running infrastructure. A Convox breach does not expose our data. |
| Compliance Dependency | Vendor's compliance is your compliance dependency | No platform vendor in the compliance scope |
When explaining your infrastructure choices to auditors, focus on the evidence chain. Auditors care about whether controls exist, whether they are implemented correctly, and whether you can demonstrate their operation. With BYOC, you can address all three points directly:
Controls exist: "Our infrastructure runs in our AWS account. Here are the IAM policies, security group rules, and KMS key configurations that implement our access controls."
Controls are implemented correctly: "AWS manages the underlying implementation. We configure the controls through AWS APIs, and AWS enforces them."
Controls operate as intended: "CloudTrail logs every API call. CloudWatch logs application events. We can show you historical evidence of control operation for any period you need."
This framing removes the vendor from the conversation. You are not asking your auditor to evaluate Convox's compliance program because Convox is not in your compliance scope. Convox provides deployment tooling that runs in your account. The infrastructure, the data, and the audit trail all belong to you.
For your next SOC2 or HIPAA audit, prepare the following documentation from your AWS account:
Because all of this documentation comes from your own AWS account, you can generate it on demand. There is no waiting for a vendor to provide attestations or answer questionnaires.
If you currently run on a managed PaaS, ask yourself these questions:
Can you show your auditor direct evidence of infrastructure access controls, or do you rely on vendor attestations? Can you demonstrate encryption key ownership and rotation, or do you trust your vendor's SOC2 scope includes key management? If your vendor experiences a breach, what is your exposure?
For organizations in regulated industries, the compliance inheritance model of managed PaaS creates ongoing audit complexity. Every audit cycle requires gathering vendor documentation, verifying scope alignment, and explaining trust chains to auditors. With BYOC, you show your own logs, your own configurations, and your own evidence. The infrastructure audit becomes a straightforward demonstration of controls you own.
Convox Rack gives you the developer experience of a managed PaaS without the compliance dependency. You get simple deployments with convox deploy, automatic HTTPS with Let's Encrypt certificates, managed databases via AWS RDS, and horizontal scaling through Kubernetes. But all of this runs in your account, using your IAM roles, encrypted with your KMS keys, and logged to your CloudTrail.
The Getting Started Guide walks through Rack installation in about 10 minutes. Once installed, the Rack operates autonomously. Convox support can help with configuration questions, but we have no runtime access to your infrastructure. Your compliance posture is determined by your AWS account configuration, not by trusting a vendor's attestation.
If you are preparing for a SOC2 or HIPAA audit and want to eliminate managed service compliance risk from your infrastructure layer, Convox Rack provides a path forward. Deploy into your own AWS account, including GovCloud regions, and answer auditor questions with direct evidence rather than vendor attestations.
Create a free account and install a Rack in your AWS account. The infrastructure will be yours from day one. For organizations with specific compliance requirements or questions about HIPAA and GovCloud deployments, reach out to our team.
See the AWS Rack Parameters documentation for the full range of configuration options, including private networking, encryption settings, and compliance-relevant infrastructure controls.
