The first email from your QSA is not a philosophical discussion about security posture. It is an evidence request: log samples from the systems that handle payment traffic, the IAM policies attached to the workloads that touch cardholder data, proof that your log retention matches your written policy, and a diagram of where the data actually flows. If answering that email means your team spends weeks exporting logs, scrubbing sensitive values out of them by hand, and reverse-engineering which IAM permissions your services actually use, the assessment has already slipped before it formally started.
That slip is expensive in the way that matters most to a company between $2M and $50M ARR: it is revenue-shaped. A failed or delayed PCI assessment triggers a remediation cycle, and remediation cycles stall the payment-processing deals that are gated on your attestation. The engineers who should be shipping the roadmap are instead assembling evidence packets. The fix is not heroic audit prep. It is a platform that produces the hosting-layer artifacts by default, inside infrastructure you own, so audit prep becomes a checklist instead of a project. That is the argument this post makes, and the checklist is below so you can run it against your current platform today.
Here is the distinction that trips up most teams on their first assessment: there is no such thing as a hosting platform that makes you PCI compliant by itself. PCI DSS assesses your cardholder data environment as a whole, which spans your application code, your data stores, your policies, your people, and your infrastructure. The hosting layer is one slice of that scope. What a QSA wants from the hosting layer is not a badge; it is evidence that specific controls exist, are enforced by configuration rather than good intentions, and can be demonstrated on request.
This is the shared responsibility model in practice, and it cuts both ways. Your cloud provider's own compliance program covers the physical data centers, the hypervisors, and the managed services underneath you. It does not cover what you build on top. AWS being assessed does not mean your deployment is assessed, any more than renting an office in a building with a fire suppression system means your tenant space passes inspection. We have written about the same distinction in the HIPAA context in whether Azure alone makes you HIPAA compliant, and the logic transfers directly to PCI: the provider's attestation is the floor you inherit, not the ceiling you get credit for.
So when we talk about PCI compliant hosting in this post, we mean hosting that is compliance ready: a platform whose default behavior generates the artifacts the assessor will request, running in an account you own so the evidence is yours to produce. The assessment scope is your infrastructure. The platform's job is to make the infrastructure side of that scope boring.
Every assessment is scoped individually and your QSA's full request list will be longer than this. But the hosting-layer artifacts below show up in nearly every engagement, and they are the ones that consume the most engineer time when the platform does not produce them by default. This is not the complete PCI DSS requirement set; it is the subset where your hosting platform either saves you weeks or costs you weeks.
| Artifact | What the QSA is looking for | The failure mode without a platform |
|---|---|---|
| Redacted log samples | Request logs from the traffic path that demonstrably contain no card numbers, CVVs, or session tokens | Manual scrubbing of exported logs, and a finding if one sensitive value slipped through |
| Retention configuration | Proof that logs are kept as long as your audit log policy says, enforced by the system rather than by a document | A written policy with no enforcement behind it, which an assessor will test |
| IAM policy documents | The exact AWS permissions each workload carries, demonstrating least privilege per service | A shared node role every container inherits, which is the opposite of least privilege |
| Access control records | Who can deploy, who can read environment secrets, who changed what and when | Shared credentials and no attributable change history |
| Infrastructure diagram | A current picture of network boundaries, load balancers, and where cardholder data transits | A diagram drawn for the last audit that no longer matches reality |
| Vendor and subprocessor list | Every third party whose infrastructure cardholder data touches, each of which widens scope | A managed PaaS vendor whose own environment now needs assessing in your scope |
Lift that table into your audit prep document and score your current platform against it honestly. Each row where the answer is "an engineer does that by hand" is a week of prep and a candidate finding. The rest of this post walks through how Convox Rack handles each one.
Convox Rack is a self-hosted platform that installs into the AWS account you already own. That architectural choice is doing most of the compliance work before any feature enters the picture: every log line, every IAM role, and every network boundary lives in your account, under your organization's controls, producible by you on demand. The features below turn the artifacts from the checklist into configuration you declare once and export forever. The platform's inherited-controls model is documented on the Convox compliance page; here is how it maps to the checklist, artifact by artifact.
The worst way to produce a redacted log sample is to export raw logs and have an engineer scrub them. It is slow, it does not scale across the sampling window an assessor picks, and one missed card number in a query string becomes a finding about your logging practices. The right way is for the sensitive values never to land in the logs at all.
Convox handles this at the router layer with the router_log_redact_params rack parameter. You name the request parameters that must never be logged, and the router redacts them before the log line is written:
$ convox rack params set router_log_redact_params=card_number,cvv,session_tokenThe evidence this produces is twofold. The log sample itself is clean, from any date in the retention window, with zero manual work. And the parameter setting is itself an artifact: convox rack params lists the stored configuration, so you can hand the assessor both the sample and the control that guarantees the sample, which is a much stronger position than a sample alone. Rack parameters are managed through the CLI and documented in CLI Rack Management.
Assessors distinguish between a retention policy and retention enforcement, and they test for the gap. A document that says "we retain audit logs for one year" is a claim; a CloudWatch log group with a declared retention period is proof. On Convox, retention is declared configuration at two levels. Rack-wide, the cloudwatch_retention_in_days parameter sets the default for application log groups:
$ convox rack params set cloudwatch_retention_in_days=365Per application, the appSettings block in convox.yml overrides the default, so an app in your cardholder data environment can carry a longer retention than internal tooling:
appSettings:
awsLogs:
cwRetention: 365Because the setting lives in convox.yml, it is version controlled alongside your application. The git history of that file is the change record for your retention control, and the CloudWatch console in your own AWS account shows the enforcement. Many organizations set retention to at least a year to match the audit log expectations in their PCI policy; whatever period your policy names, the configuration and the policy now say the same thing, and you can prove it in one screenshot.
The IAM conversation is where generic container platforms hurt most. If every workload on a node inherits the node's IAM role, your payment service carries the same AWS permissions as your marketing site, and no amount of documentation makes that look like least privilege. What the assessor wants is per-workload policy, and ideally wants it as a short list of policy ARNs they can open and read.
Convox attaches IAM at the service level through accessControl.awsPodIdentity.policyArns. You write the least-privilege policies in your own AWS account, and each service declares exactly the ones it carries:
services:
payments:
build: .
port: 3000
accessControl:
awsPodIdentity:
policyArns:
- arn:aws:iam::123456789012:policy/payments-sqs-consume
- arn:aws:iam::123456789012:policy/payments-kms-decrypt
web:
build: .
port: 3000This requires the pod_identity_agent_enable rack parameter to be set, documented in the AWS Rack installation reference. The evidence value here is unusually direct: the policy ARNs in your manifest are the audit artifact. The assessor asks what the payments workload can do in AWS; you hand over two policy documents from your own IAM console and the convox.yml diff that attached them. The web service above carries no payment-related permissions at all, and the manifest proves that too.
Access control evidence is about people: who can deploy to the cardholder data environment, who can read its secrets, and whether every change traces to an individual. Convox covers this with role-based access control operating on a zero-trust model, where access not explicitly granted is denied, and with the Console's audit log, which records every action with the acting user, the target resource, and the timestamp. CI systems authenticate with deploy keys that are deliberately restricted from reading release environments, which closes the common finding where a CI credential doubles as a secrets dump. Sensitive environment values are managed through environment variables scoped to the app and masked in the Console by default.
Notice what every artifact in this section has in common: none of it is exported from Convox-operated infrastructure, because there is none in the data path. The Rack runs in your AWS account. CloudWatch log groups, IAM policies, VPC configuration, and load balancers are all yours, visible in your own AWS console, covered by your existing AWS agreements. You also pay AWS directly for that infrastructure, with no Convox markup on it, which keeps the finance conversation as short as the compliance one.
The ownership model also answers the vendor-risk question before the assessor asks it. A managed PaaS that terminates your TLS and routes your payment traffic through its own infrastructure is a new party in your cardholder data flow, and your QSA will treat it accordingly: questionnaires, attestation review, and scope discussion. With a self-hosted Rack, cardholder data never transits Convox-operated infrastructure. Convox is software running in your account, not a processor in your data path, so the subprocessor conversation is short. The same architecture serves teams facing HIPAA and SOC 2 alongside PCI, because the artifact-production model is identical across frameworks; if you are juggling more than one assessment, the HIPAA-focused overview of the BYOC model covers how the inherited-controls argument plays out there.
Now the honest boundary, because a post that claims a platform takes the assessment for you deserves your distrust. Convox produces infrastructure-level evidence. It does not and cannot produce the application-level controls that make up the rest of your scope. Encrypting cardholder data at rest in your schema is your work. Key management decisions, including whether KMS policies like the ones attached above are scoped correctly, are your work. The cardholder data flow diagram, the written security policies, the quarterly access reviews, the vulnerability management program, and the decision about whether to tokenize and shrink scope in the first place are all yours. A good QSA will spend most of the engagement there.
That is the trade-off stated plainly: the platform converts the hosting-layer rows of the evidence request from a project into configuration exports, and leaves the application and policy rows untouched. For most engineering leaders that is exactly the right division, because the hosting rows are the ones that were consuming engineer weeks without making the product any safer.
Run this against your current platform before the assessor's first email arrives, while there is still time to fix the answers:
If more than a couple of those answers involve manual work, you have found your audit slip before the assessor did. The fix is cheap to evaluate: install a Rack into a sandbox AWS account, set the three parameters covered above, deploy a representative service, and try to produce each artifact. That exercise takes an afternoon and tells you more than any vendor call.
No, and that is the point of the architecture. Convox Rack is compliance ready: it runs inside your own AWS account and inherits the controls there, so the assessment scope is your infrastructure rather than a Convox-operated service. Your QSA assesses your environment, with evidence you generate yourself, instead of reviewing a third-party platform's attestation.
Commonly requested items include request log samples from the traffic path showing no cardholder data is written to logs, the retention configuration on those log groups, and the access controls governing who can read or alter them. Assessors generally want enforcement shown in the system itself, not just a written policy describing intent.
Set the router_log_redact_params rack parameter with the parameter names to redact, for example convox rack params set router_log_redact_params=card_number,cvv. The router redacts those values before log lines are written, so every sample in your retention window is clean by configuration, and the parameter setting itself serves as evidence of the control.
Declare retention as configuration: set cloudwatch_retention_in_days rack-wide, or set cwRetention in the appSettings.awsLogs block of an app's convox.yml. The setting is version controlled, and the CloudWatch log groups in your own AWS account show the enforced retention period, which together prove policy and enforcement match.
A managed PaaS that routes payment traffic through vendor-operated infrastructure generally does, which means questionnaires and scope discussion with your assessor. A self-hosted Convox Rack runs entirely in your AWS account, so cardholder data never transits Convox-operated infrastructure and no new subprocessor enters your data flow.
Run the checklist above against your current platform this week. If the artifacts require manual assembly, stand up a Convox Rack in a sandbox AWS account and test whether each one falls out of configuration instead. The Getting Started Guide walks through installation and your first deployment.
See how Convox supports compliance-ready infrastructure, or talk to our team about your PCI assessment timeline. Bring your compliance owner to that conversation; the evidence model lands fastest when the person who answers the QSA is in the room.
