What PCI DSS Actually Requires When a Fintech Moves Cardholder Data to a Hyperscaler Cloud

PCI DSS v4.0.1 requires fintechs moving cardholder-data processing to AWS, Google Cloud, Azure, Scaleway, or Kubernetes to treat their deployed workloads as a separately assessed cardholder data environment rather than inheriting cloud-provider compliance. Providers’ attestations cover only specified infrastructure services and regions, while the fintech must document shared responsibilities, inventory and monitor third parties, maintain current data-flow and network diagrams, and prove scope and segmentation, with service providers facing several six-month review and testing cycles. Core obligations include making stored PAN unreadable, encrypting data in transit, prohibiting post-authorization storage of sensitive authentication data, enforcing MFA and least-privilege access, retaining protected audit logs for 12 months with recent logs readily accessible, and conducting quarterly vulnerability scans alongside regular penetration and segmentation tests. The article emphasizes reducing scope by using hosted payment pages, tokenization, and strong isolation rather than attempting to harden an entire shared environment, especially because Kubernetes namespaces alone are not considered sufficient segmentation. It also explains that platforms such as Qovery may operate Kubernetes in a customer’s own cloud account, preserving customer control over logs, keys, and network boundaries, but do not confer PCI compliance, which remains subject to assessment by a QSA, acquirer, or card brand.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.