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

Key Points

• You do not inherit a cloud provider's PCI DSS compliance. AWS, Google Cloud, Azure, and Scaleway hold provider-level attestations covering their own infrastructure and a named, region-specific list of in-scope services. Everything you deploy on top is your cardholder data environment (CDE), assessed separately at least every 12 months.
• PCI DSS v4.0.1 is the only active version. v3.2.1 retired on 31 March 2024, and the future-dated v4.x requirements became mandatory on 31 March 2025, so any migration assessed in 2026 faces the full standard with zero transition relief.
• The controls that drive the most work: a written service-by-service responsibility matrix (12.8.5), scope confirmed every 12 months and every 6 months for service providers (12.5.2, 12.5.2.1), segmentation penetration testing every 6 months for service providers (11.4.6), PAN unreadable at rest (3.5.1), strong cryptography in transit (4.2.1), MFA for all CDE access (8.4.2), audit logs kept 12 months with 3 immediately available (10.5.1), and internal plus external ASV scans every 3 months (11.3.1, 11.3.2).
• Scope reduction beats control hardening on cost and timeline. Push PAN capture to a PCI-validated payment provider or token vault and most of your services never touch account data.
• Where the workload physically runs decides who holds the evidence. A fully hosted PaaS runs your workload in the vendor's account, making it a third-party service provider you must inventory and monitor under Req 12.8. Qovery keeps the CDE inside your own cloud account. Qovery is not a PCI DSS certification and does not make anyone compliant.

The migration day a QSA finds your analytics warehouse full of PANs

I have talked to a lot of fintech teams over the years, and the same scene keeps repeating. A team moves card processing to the cloud, feels good about it, and then a Qualified Security Assessor (QSA) walks in and asks two questions that unravel the whole project. Which systems can touch cardholder data? And where are your logs, keys, and segmentation evidence?

The answers are usually worse than anyone expected. One shared Kubernetes cluster, separated only by namespaces, drags every service into scope. An analytics warehouse turns out to hold full Primary Account Numbers (PANs) copied from a production dump nobody cleaned. Application logs captured card numbers in request bodies for a year.

None of that is a cloud problem. It is a scoping and ownership problem, and PCI DSS v4.0.1 is specific about who owns what. Here is what the standard actually requires when you move cardholder data to AWS, Google Cloud, Azure, Scaleway, or your own Kubernetes cluster, with the real requirement numbers and the dates that now bite.

Does moving to AWS, GCP, Azure, or Scaleway make my fintech PCI DSS compliant?

No. A hyperscaler's PCI DSS Attestation of Compliance (AOC) covers that provider's own infrastructure and a published, region-specific list of in-scope services. It attests to nothing about the applications, containers, databases, IAM roles, and access paths you build on top, which are assessed as your own cardholder data environment at least every 12 months.

AWS is assessed as a Level 1 PCI DSS Service Provider, re-assessed twice a year, with more than 120 services in scope on its published Services in Scope page. Google Cloud is a Level 1 PCI DSS 4.0.1 service provider and publishes a shared responsibility matrix. Azure is certified at Service Provider Level 1 under PCI DSS v4.0.1 with its own responsibility matrix. Scaleway publishes its certifications and security documentation in its Trust Center, and you should confirm the exact PCI scope for the specific Scaleway services you use. The in-scope list differs per provider, per service, and per region. A service your provider has not had assessed is one you cannot rely on inside your CDE.

The PCI shared responsibility model splits every requirement three ways: provider-responsible, customer-responsible, and shared. The "shared" rows are where assessments fail, because both sides assume the other produced the evidence and nobody did. The PCI SSC says this plainly in its Cloud Computing Guidelines Information Supplement: a cloud customer cannot inherit a provider's compliance and must obtain a documented, service-by-service responsibility matrix.

That matrix is not optional paperwork. Requirement 12.8 spells out the chain: inventory your third-party service providers (12.8.1), hold written agreements where they acknowledge responsibility for cardholder data (12.8.2), do due diligence before engaging them (12.8.3), monitor their compliance status at least every 12 months (12.8.4), and maintain the requirement-by-requirement matrix of who manages what (12.8.5). And if your fintech is itself a service provider to your customers, which most fintechs are whether they have realized it or not, Req 12.9 is the mirror obligation you owe them.

The dates leave no room to stall. PCI DSS v3.2.1 retired on 31 March 2024, v4.0.1 was published in June 2024 as a limited revision with no new or removed requirements, and the future-dated v4.x requirements became mandatory on 31 March 2025. A migration assessed in 2026 is a full v4.0.1 assessment. And the final word on whether your evidence is sufficient comes from your acquirer or card brand, not your cloud provider.

What counts as the cardholder data environment (CDE) in a cloud account?

The CDE is every system component that stores, processes, or transmits account data, plus every system connected to those components or able to affect their security. In a cloud account that definition pulls in your CI/CD runners, container registry, secrets manager, bastion, observability stack, IAM and SSO, and Kubernetes control plane, not just the service that touches the PAN.

Start with the data itself. Account data means the PAN, cardholder name, expiry, and service code. Sensitive authentication data (SAD) means full track data, CVV or CVC2, and PIN or PIN block. SAD must not be retained after authorization (3.3.1), and any SAD stored before authorization must be encrypted (3.3.2). Those two rules alone catch a lot of teams whose logs or message queues quietly persist CVVs.

The "connected-to or security-impacting" category is what expands scope in the cloud. Your CI/CD pipeline deploys into the CDE, so it is in scope. So are the container registry it pushes to, the secrets manager that injects credentials, the bastion that reaches production, the log aggregator that receives CDE events, the IAM or SSO provider that grants access, DNS, and the Kubernetes API server. A namespace boundary alone is not accepted as segmentation. If you want non-CDE systems out of scope, the segmentation has to be real and validated by penetration testing.

Scope is also a dated obligation, not a one-time diagram. Requirement 12.5.1 wants an inventory of in-scope system components with each component's function. Requirement 12.5.2 requires scope to be documented and confirmed at least every 12 months and after any significant change. For service providers, 12.5.2.1 pulls that cadence to at least every 6 months. The data-flow diagrams covering all account data flows (12.5.1) and current network diagrams (1.2.4) are the first artifacts a QSA asks for, and the most common thing teams cannot produce.

The failure modes worth naming: the analytics warehouse holding full PANs from a production dump, and application logs capturing PANs in request bodies. And cloud-native does not shrink scope by itself. A serverless function that receives a PAN is as in-scope as a VM that does.

Which PCI DSS v4.0.1 requirements bite hardest on a cloud migration?

Seven areas account for nearly all the engineering work in a cloud migration: segmentation (Req 1 and 11.4), encryption and key management (Req 3 and 4), access control and MFA (Req 7 and 8), logging (Req 10), vulnerability management and testing (Req 6 and 11), change control (6.5), and the service-provider-only requirements that carry 6-month rather than 12-month cadences.

Segmentation is the one that decides your assessment size. Req 1 governs network security controls between CDE and non-CDE, and the proof is penetration testing: at least every 12 months for merchants (11.4.5) and at least every 6 months for service providers (11.4.6). On encryption, Req 3.5.1 requires PAN rendered unreadable wherever stored through one-way hashing with salt, truncation, tokens, or strong cryptography, with the v4 clarifications that keyed hashing strength matters (3.5.1.1) and that disk-level encryption alone is insufficient on non-removable media (3.5.1.2). Key management under 3.6 and 3.7 brings split knowledge and dual control for clear-text key operations. Req 4.2.1 demands strong cryptography for PAN in transit over open public networks, and 4.2.1.1 adds an inventory of trusted keys and certificates.

Access control is where the future-dated requirements land hardest. Least privilege needs documented approval (7.2.1 to 7.2.3), and all user accounts and access privileges must be reviewed at least every 6 months (7.2.4). Accounts must be unique with no shared logins (8.2.2). MFA is now required for all access into the CDE (8.4.2) and for all remote network access (8.4.3), the MFA system must resist replay and not be bypassable (8.5.1), and passwords have a 12-character minimum (8.3.6). This is not box-ticking: in the 2025 Verizon DBIR, stolen credentials were the single most common initial access vector, used in 22% of breaches.

Logging and testing round it out. Audit logs must be centralized and tamper-protected (10.3.3, 10.3.4), retained for 12 months with the most recent 3 months immediately available (10.5.1), reviewed by automated mechanisms (10.4.1.1), and monitored for log failures with alerting (10.7.2, 10.7.3). Internal vulnerability scans run at least every 3 months with authenticated scanning (11.3.1, 11.3.1.2), external scans run at least every 3 months by a PCI SSC Approved Scanning Vendor (11.3.2), and penetration testing runs annually internally and externally (11.4.2, 11.4.3). Add secure SDLC and code review (6.2), change control for significant changes (6.5.1), and change-and-tamper detection on payment pages (11.6.1).

How do I reduce PCI DSS scope instead of hardening every system?

Scope reduction is the cheapest compliance lever available, and it is an architectural decision, not a control. Keep the PAN out of your systems entirely through a PCI-validated payment provider, a hosted payment page or iframe, or tokenisation, and most of your services fall out of the CDE and the assessment collapses to a thin, segmented service.

The cleanest move is to never capture the PAN yourself. A hosted payment page or iframe from a PCI-validated provider like Stripe, Adyen, or Checkout.com means your application only ever handles tokens. That can put you on an SAQ A path, where the card data functions are fully outsourced, rather than SAQ A-EP, which applies when your site does not receive card data but can still affect the security of the payment page. Either way the v4 payment-page controls still apply to you: script management (6.4.3) and change-and-tamper detection (11.6.1). If you build and operate your own token vault instead, it stays firmly in scope and usually pushes you toward a full Report on Compliance.

Segmentation is the other lever. In the cloud that means a dedicated account, project, or subscription for the CDE; a dedicated VPC with private subnets; dedicated node pools or a dedicated Kubernetes cluster; mTLS through a service mesh; and strict egress allowlists. The single most common scope explosion I see is "everything in one Kubernetes cluster, separated by namespace." A namespace is not a segmentation boundary a QSA will accept on faith. The claim has to survive the 6-month segmentation penetration test (11.4.6), which means network policy, identity, and egress controls that an attacker in one namespace cannot cross.

Be honest about the trade-off: less in-scope infrastructure usually means more integration work with the payment provider and less control over the checkout experience and chargeback data. And do not forget non-production. Req 6.5.5 forbids live PANs in test and development, so preview environments must be seeded with synthetic card data, and idle non-production environments must not quietly become unmonitored in-scope systems. The reason this matters so much: the Red Hat State of Kubernetes Security report found that 45% of Kubernetes security incidents stem from misconfigurations, and the median financial-sector data breach cost 5.56 million dollars in IBM's 2025 report, well above the 4.44 million global average. Getting scope wrong is expensive in both directions.

Who is responsible for what between my fintech, the cloud provider, and the platform layer?

PCI DSS Req 12.8.5 requires a written, service-by-service matrix of which requirements each party manages, and a cloud migration has three parties, not two: the hyperscaler, any platform or managed-service layer, and your own engineering team. Any requirement nobody explicitly owns becomes your finding at assessment time.

Build the matrix the way a QSA reads it: one row per requirement, per service, with the "shared" rows spelled out down to who produces the evidence and how often. The hyperscaler covers physical security, the hypervisor, host patching for managed services, and its own AOC for named in-scope services. It covers nothing about your images, IAM policy, data model, or application logs. A platform layer can cover more or less depending on one thing: where the workload physically runs. That location decides who holds the logs, the encryption keys, the network boundary, and data residency.

This is the structural fork. A fully hosted PaaS runs your workload in the vendor's account, which makes that vendor a third-party service provider you must inventory (12.8.1), contract with (12.8.2), and monitor (12.8.4). In a bring-your-own-cloud model, the CDE never leaves your account and your QSA assesses infrastructure you already control. Neither is automatically "more compliant." Heroku Shield and Platform.sh genuinely offer PCI-oriented hosted options with their own attestations, and for some teams that is the right trade. The real difference is assessment burden, evidence custody, and control.

This is where Qovery fits, and it is worth being precise about what it does and does not do. Qovery provisions and operates Kubernetes inside your own AWS, Google Cloud, Azure, Scaleway, or existing cluster, with per-environment RBAC, managed cluster upgrades, git-push deployments, preview environments per pull request, environment auto-stop for non-production, and databases backed by managed cloud services. Because the workload runs in your account, the logs, keys, segmentation, and data residency stay in your name, so your QSA assesses infrastructure you already own rather than a vendor you now have to monitor as a TPSP. Qovery is not a PCI DSS certification and does not make anyone compliant. Only a QSA or your acquirer validates that.

What does a PCI-ready cloud architecture actually look like?

The pattern that survives assessment is a thin, isolated CDE: one small segmented service that touches tokens or PANs, in its own cloud account, project, or cluster, with centralized write-once logging and customer-managed encryption keys held by you. Everything else stays outside the boundary by design.

The reference layout is boring on purpose. A separate cloud account, project, or subscription for the CDE. Private subnets only. No public ingress except through a WAF and load balancer. An explicit egress allowlist. Managed databases encrypted at rest with customer-managed keys in AWS KMS, Google Cloud KMS, Azure Key Vault, or Scaleway Key Manager, with documented rotation and split knowledge and dual control for key custodians (3.6, 3.7). Immutable, scanned container images and signed deployments. No interactive SSH into production; break-glass access only, behind MFA (8.4.2) with full session recording.

Logging is a pipeline, not an afterthought: centralized, write-once, 12 months total with 3 months immediately searchable (10.5.1), plus alerting on audit log failures (10.7). Non-production gets its own discipline. Ephemeral preview environments per pull request, seeded with synthetic card data only (6.5.5), and auto-stop so idle environments do not become unmonitored in-scope systems.

Then map the calendar before you migrate, because the 6-month service-provider cadences are what teams miss. On day one a QSA asks for data-flow diagrams, the system component inventory, the responsibility matrix, change records, the segmentation test report, quarterly ASV scan reports, penetration test reports, targeted risk analyses, and the TPSP register. Have them ready.

How do I set this up with Qovery from Claude Code or Cursor?

If your team works inside a coding agent, install the Qovery Agent Skills and the agent can provision and deploy into your own cloud account, with every action proposed for your approval and MCP access read-only by default.

Install the Agent Skills globally to make qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, and qovery-terraform available to Claude Code, Cursor, Codex, OpenCode, and Gemini CLI:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope the install to a single repository when you want the skills committed with the project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code. It uses OAuth and is read-only by default, so the agent can inspect but not change anything:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want the agent to make changes, which also requires write access enabled in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Then ask in plain language, for example "provision a dedicated cluster in my AWS account and deploy the payments service into an isolated environment." The agent proposes the plan and you approve each step.

For regulated teams, keep the MCP Server read-only by default and route every agent-proposed change to CDE infrastructure through your normal change control process (6.5.1), keeping the approval trail as evidence. The reference pages are the AI agent quickstart and the Claude Code integration page.

Frequently asked questions

What does PCI DSS require when a fintech moves cardholder data processing to a hyperscaler cloud?

It requires you to treat everything you deploy as your own cardholder data environment, separate from the provider's AOC. In practice that means a documented service-by-service responsibility matrix (12.8.5), scope confirmed at least every 12 months and every 6 months for service providers (12.5.2, 12.5.2.1), segmentation proven by penetration testing, PAN unreadable at rest (3.5.1) and in transit (4.2.1), MFA for all CDE access (8.4.2), 12-month log retention (10.5.1), and quarterly internal and external scans (11.3.1, 11.3.2). The cloud provider's compliance covers its infrastructure, not your workloads.

Are AWS, Google Cloud, Azure, and Scaleway PCI DSS compliant out of the box?

Their infrastructure and a named list of services are assessed, but you are not compliant just by running on them. AWS, Google Cloud, and Azure are Level 1 PCI DSS Service Providers for specific in-scope services, and Scaleway publishes its certifications in its Trust Center. Everything you build on top is assessed as your own CDE, and the "shared" responsibility rows are yours to evidence.

Which PCI DSS version applies in 2026, and what changed in v4.0.1?

PCI DSS v4.0.1 is the only active version. v3.2.1 retired on 31 March 2024, v4.0.1 was published in June 2024 as a limited revision with no new or removed requirements, and the future-dated v4.x requirements became mandatory on 31 March 2025. A 2026 assessment is a full v4.0.1 assessment with no transition relief.

Can I run a PCI DSS cardholder data environment on Kubernetes?

Yes, but a shared cluster separated only by namespaces will not pass as segmented. You need isolation that survives a penetration test, whether through a dedicated cluster, dedicated node pools, strict network policy, mTLS, and egress controls. Service providers must repeat that segmentation penetration test at least every 6 months (11.4.6), so the isolation has to be real and continuously verified.

How often do I need segmentation testing, ASV scans, penetration tests, and access reviews?

Internal and external ASV scans run at least every 3 months (11.3.1, 11.3.2). Penetration tests run at least annually (11.4.2, 11.4.3). Segmentation penetration testing runs every 12 months for merchants and every 6 months for service providers (11.4.5, 11.4.6). User access reviews and scope confirmation run every 6 months for service providers (7.2.4, 12.5.2.1).

What is a PCI DSS responsibility matrix and who has to produce one?

It is the documented, requirement-by-requirement record of which party manages each PCI DSS requirement, mandated by Req 12.8.5. You, the entity being assessed, have to produce and maintain it, even though your cloud provider and any platform vendor contribute their parts. Any requirement left unassigned becomes your finding at assessment time.

Does using an internal developer platform like Qovery change my PCI DSS scope or make me compliant?

No platform makes you compliant; only a QSA or your acquirer validates that. What a platform changes is where the workload runs and therefore who holds the evidence. Qovery provisions and operates Kubernetes inside your own AWS, Google Cloud, Azure, or Scaleway account, so logs, keys, segmentation, and data residency stay in your name rather than moving to a vendor you would then have to monitor as a third-party service provider under Req 12.8.