If you run payment workloads on cloud infrastructure and your QSA (Qualified Security Assessor) is scheduled for 2026, you already know the feeling: a spreadsheet full of controls, a stack that was never designed with PCI DSS in mind, and a deadline that does not move. PCI DSS 4.0.1 became fully mandatory in March 2025, replacing version 3.2.1 entirely. The changes are not cosmetic. Stricter penetration-testing timelines, a new 30-day critical-patch rule, tighter log-retention requirements, and expanded Web Application Firewall (WAF) obligations have caught more than a few engineering teams off guard.
This guide walks CTOs, DevSecOps engineers, and IT managers through every cloud infrastructure control that directly affects PCI DSS 4.0.1 compliance: firewalls, WAF configuration, network segmentation, automated backups, vulnerability scanning, and the shared-responsibility boundary between you and your cloud provider.
Key Takeaways
- PCI DSS 4.0.1 has been fully mandatory since March 2025. Version 3.2.1 is no longer accepted.
- WAF deployment in front of all public-facing web applications is now an explicit hard requirement under Requirement 6.4.2.
- Critical vulnerabilities (CVSS 9.0+) must be patched within 30 days; high-severity (CVSS 7.0-8.9) within 90 days.
- Audit logs must be retained for 12 months, with at least 3 months immediately queryable without a restore operation.
- Network segmentation is not mandatory but is the most effective way to reduce CDE scope and assessment cost.
- A shared responsibility matrix mapping every PCI DSS requirement to a named owner is expected by QSAs before the assessment starts.
Table of Contents
- Why PCI DSS 4.0.1 Is Different: What Changed in 2025 and What It Means for Your Cloud Stack
- The 12 Requirements and Which Ones Directly Govern Your Cloud Servers, Storage, and Backups
- Network Segmentation: How to Isolate Your Cardholder Data Environment Using Public, Private, DMZ, and VPN Zones
- Stateful Firewall and WAF Controls: Mapping OWASP Top 10 Coverage to PCI DSS Requirements 6 and 10
- Automated Backup and Log Retention: Meeting the 90-Day Minimum Monitoring Window and RPO/RTO Targets
- Vulnerability Scanning and Patching: Quarterly ASV Scans and the New 30-Day Critical-Patch Rule
- Shared Responsibility in Practice: What Your Cloud Provider Must Document vs. What You Own
- A Practical PCI DSS Readiness Checklist for Cloud-Hosted Payment Workloads
- Building a PCI-Ready Cloud Stack Without Starting Over
Why PCI DSS 4.0.1 Is Different: What Changed in 2025 and What It Means for Your Cloud Stack
Version 4.0.1 is not a minor revision. The Payment Card Industry Security Standards Council (PCI SSC) released it to close gaps that became obvious as workloads moved to cloud-native and containerized environments. Three changes matter most for cloud-hosted payment systems.
Customized implementation is now a first-class path. Previously, organisations either met a defined requirement or they did not. Version 4.0.1 formalizes a "customized approach" that lets you demonstrate equivalent security through compensating controls, as long as you document the objective and your QSA agrees. For cloud teams, this matters because many hyperscaler-native controls (AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall Rules) do not map cleanly to the traditional requirement language.
WAF coverage is now explicit and mandatory. Requirement 6.4.2 now requires a WAF (or similar technical control) to be deployed in front of all public-facing web applications in scope. Previously, a WAF was strongly recommended; now it is a hard requirement. If your payment page sits behind a CDN without WAF capability, that is a finding.
Log retention and monitoring windows tightened. Requirement 10.5.1 mandates that audit logs be retained for at least 12 months, with at least 3 months immediately available for analysis. The "immediately available" clause is what trips cloud teams: logs sitting in cold storage do not satisfy this requirement unless you can query them in real time.
Beyond those three, the standard now explicitly addresses cloud environments in a way that earlier versions did not. Sysdig's PCI compliance guidance for cloud-native workloads notes that container orchestration layers, ephemeral compute, and shared tenancy all create scope questions that your QSA will ask about directly.
The 12 Requirements and Which Ones Directly Govern Your Cloud Servers, Storage, and Backups
PCI DSS organises its controls into 12 requirements. Not all 12 touch cloud infrastructure equally. The ones that generate the most findings during cloud assessments are:
- Requirement 1 (Network Security Controls): Firewall rules, default-deny policies, and documentation of all traffic flows into and out of the Cardholder Data Environment (CDE).
- Requirement 2 (Secure Configurations): No vendor-supplied defaults, hardened OS images, documented configuration baselines for every server in scope.
- Requirement 6 (Secure Systems and Software): WAF deployment, vulnerability management, and the new 30-day critical-patch rule.
- Requirement 10 (Logging and Monitoring): Audit log generation, tamper-evident storage, and the 90-day immediate-availability window.
- Requirement 11 (Security Testing): Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV), annual penetration tests, and internal scans after any significant change.
- Requirement 12 (Policies and Procedures): Documented shared-responsibility matrix with your cloud provider.
Requirements 3 and 4 govern cardholder data at rest and in transit, which affects your storage and encryption choices. Requirements 7, 8, and 9 cover access control, authentication, and physical security. Physical security is handled by your cloud provider for colocation-style deployments, but you must hold their Attestation of Compliance (AOC) or equivalent as evidence.
For cloud-hosted workloads, Requirements 1, 6, 10, and 11 are where most organisations accumulate findings. The rest of this guide focuses on the infrastructure controls that address those four.
Network Segmentation: How to Isolate Your Cardholder Data Environment Using Public, Private, DMZ, and VPN Zones
Network segmentation is not technically required by PCI DSS, but it is the single most effective way to reduce scope. Without segmentation, every system on your network that can communicate with a CDE component is potentially in scope. With proper segmentation, you can draw a tight boundary around the systems that actually store, process, or transmit cardholder data and assess only those.
The standard model for a cloud-hosted CDE uses four network zones:
- Public zone: Internet-facing load balancers and WAF endpoints. No cardholder data lives here. Traffic is inspected before it crosses into the DMZ.
- DMZ: Application servers that receive payment requests. These systems process data but do not store Primary Account Numbers (PANs). Strict egress rules prevent them from initiating outbound connections except to the private zone.
- Private zone: Databases, encryption key management, and any system that stores PANs or sensitive authentication data. No direct inbound access from the public zone. All access routes through the DMZ or a dedicated management network.
- VPN/Management zone: Administrative access for engineers and monitoring systems. Separate from all data-plane traffic. Multi-factor authentication (MFA) required on every entry point.
In practice, you implement this with separate Virtual Private Cloud (VPC) segments or equivalent constructs (AWS VPC, Azure Virtual Network, Google Cloud VPC), with firewall rules enforcing the boundaries. Every rule must be documented, and every rule that is not explicitly required must be removed. "Permit any any" rules anywhere in the CDE boundary are an automatic finding.
PlusClouds Networking and Load Balancers provides exactly these five network types, including public, private, VPN, management, and DMZ, all configurable from a single control plane. That makes the segmentation architecture above deployable without stitching together multiple products or writing custom routing logic.
One practical note: document your network topology before your QSA engagement, not during it. A diagram showing every data flow between zones, with firewall rule references mapped to each flow, cuts assessment time significantly and demonstrates the kind of control maturity that QSAs look for.
Stateful Firewall and WAF Controls: Mapping OWASP Top 10 Coverage to PCI DSS Requirements 6 and 10
Requirement 1 demands stateful inspection at every CDE boundary. A stateful firewall tracks the state of active connections and allows return traffic only for sessions it initiated. Stateless Access Control Lists (ACLs) do not satisfy this requirement.
Requirement 6.4.2 goes further: all public-facing web applications in scope must be protected by a WAF configured to detect and block attacks. The requirement specifically references the OWASP Top 10 as a baseline. Your WAF must, at minimum, address:
- SQL injection (OWASP A03)
- Cross-site scripting, or XSS (OWASP A03)
- Broken access control (OWASP A01)
- Security misconfiguration (OWASP A05)
- Injection attacks broadly (OWASP A03)
Requirement 10 adds a logging obligation on top of the WAF control: every blocked and permitted request must generate a log entry, and those logs must be tamper-evident and retained for 12 months with 3 months immediately queryable.
This is where many teams underestimate the effort. A WAF that blocks attacks but does not produce structured, queryable logs fails Requirement 10 even if it satisfies Requirement 6. You need both.
PlusClouds Cloud Security combines a stateful firewall with a WAF covering the OWASP Top 10, plus always-on DDoS mitigation at 1 Tbps and above. The platform holds ISO 27001, SOC 2, and GDPR certifications, which simplifies the documentation burden when your QSA asks for evidence of the provider's own security posture.
For logging, pipe WAF events to a centralized Security Information and Event Management (SIEM) system with immutable log storage. AWS CloudWatch Logs with Object Lock, or an equivalent immutable-write storage tier, satisfies the tamper-evident requirement. On-premises SIEM solutions work too, but they add operational overhead that cloud-native options avoid.
Automated Backup and Log Retention: Meeting the 90-Day Minimum Monitoring Window and RPO/RTO Targets
Two distinct backup obligations exist under PCI DSS 4.0.1, and teams often conflate them.
The first is data backup for recovery purposes, governed by Requirement 12.3.4 and your business continuity obligations. Your Recovery Point Objective (RPO) and Recovery Time Objective (RTO) must be documented, tested, and achievable. For payment systems, RPO is typically measured in hours at most; RTO in single-digit hours for critical paths.
The second is log backup for audit purposes, governed by Requirement 10.5.1. Logs must be retained for 12 months. At least 3 months of logs must be immediately available, meaning queryable without a restore operation. This is a separate requirement from your application data backup, and it needs its own retention policy and storage tier.
Practical implementation looks like this:
Application data:
- Daily incremental snapshots retained for 30 days
- Weekly full snapshots retained for 90 days
- Monthly archives retained for 12 months
- Offsite or cross-region copy of all snapshots
Audit logs:
- Streamed in real time to immutable log storage
- Hot tier: 90 days (immediately queryable)
- Cold tier: months 4-12 (restorable within defined SLA)
- Integrity verification: cryptographic hash on each log batchTesting matters as much as the backup itself. Requirement 12.3.4 requires you to test backup restoration at least annually. Document the test, the result, and the actual RTO achieved. QSAs ask for this evidence, and "we have backups" without a tested restore is not sufficient.
PlusClouds Automated Backup provides automated backup and recovery with explicit RPO/RTO targets, SLA tracking, and remote restore capabilities. For teams building a broader ransomware-resilient architecture, the 3-2-1-1 backup rule guide covers how to layer offsite and immutable copies to satisfy both PCI DSS and ransomware recovery requirements simultaneously.
Vulnerability Scanning and Patching: Quarterly ASV Scans and the New 30-Day Critical-Patch Rule
Requirement 11.3.2 mandates external vulnerability scans by a PCI SSC-approved ASV at least once every three months, and after any significant change to the CDE. "Significant change" is defined broadly: new systems, modified firewall rules, software version upgrades. If you deploy continuously, you may need to trigger scans more frequently than quarterly.
The new 30-day critical-patch rule under Requirement 6.3.3 is where teams building on fast-moving cloud infrastructure feel the most pressure. Critical vulnerabilities (CVSS score 9.0 or above) must be addressed within one month of release. High-severity vulnerabilities (CVSS 7.0-8.9) must be addressed within three months. This applies to every system in CDE scope, including base OS images, container runtimes, and third-party libraries.
In practice, this means:
- Automated OS patching must be enabled and monitored for all CDE servers.
- Container base images must be rebuilt and redeployed within the patch window, not just flagged in a backlog.
- A documented change management process must exist so that emergency patches can be applied without a full change-advisory-board cycle.
PlusClouds Cloud Servers run on AMD EPYC hardware with NVMe storage and support full root access, which gives your team the control needed to apply patches on your schedule rather than waiting for a provider's maintenance window. The 99.98% uptime SLA means patching with rolling restarts does not require a maintenance blackout.
For internal scanning, tools like OpenVAS or Nessus can be deployed within the private zone to scan CDE components without exposing scan traffic to the public internet. External ASV scans must come from an approved vendor. A list of approved ASVs is maintained by the PCI Security Standards Council.
Shared Responsibility in Practice: What Your Cloud Provider Must Document vs. What You Own
The shared responsibility model is well understood in principle and frequently misapplied in practice. For PCI DSS, the question is not just "who is responsible for what" but "who can produce evidence of what" when a QSA asks.
Your cloud provider is responsible for the physical security of the data center (Requirement 9), the hypervisor layer's integrity, and the network hardware underlying your virtual infrastructure. They must provide documentation of their own compliance posture, typically in the form of an Attestation of Compliance (AOC) or a SOC 2 Type II report.
You are responsible for everything above the hypervisor: OS configuration, application code, firewall rules, WAF policies, encryption key management, access control, and log retention. Even if your cloud provider offers a managed WAF service, you own the WAF configuration and must demonstrate that it covers the required OWASP Top 10 categories.
The practical output of this analysis is a shared responsibility matrix: a document listing every PCI DSS requirement, which party owns it, and what evidence exists. Your QSA will expect this document. Build it before the assessment, not during it.
For teams evaluating isolation models, the multi-tenant cloud vs. single-tenant bare metal guide covers how tenancy architecture affects your scope boundary and what documentation each model requires from the provider.
PlusClouds operates Tier 3 data centers with N+1 redundancy and a 40 Gbps backbone, and holds ISO 27001 certification. That certification covers the physical and network layers and can be referenced directly in your shared responsibility matrix to close Requirement 9 and the physical-security portions of Requirement 12.
A Practical PCI DSS Readiness Checklist for Cloud-Hosted Payment Workloads
Use this checklist as a starting point for your pre-assessment gap analysis. It is not exhaustive, but it covers the controls most commonly found deficient in cloud environments.
Network and Segmentation
- CDE is isolated in a dedicated private network zone with no direct public internet access
- DMZ exists between public-facing components and the private CDE
- All firewall rules are documented with business justification
- Default-deny inbound and outbound rules are in place at every CDE boundary
- VPN or management network is separate from data-plane traffic
- Network topology diagram is current and maps to actual firewall rule sets
Firewall and WAF
- Stateful firewall is deployed at every CDE ingress and egress point
- WAF is deployed in front of all public-facing web applications in scope
- WAF policy covers OWASP Top 10 categories with block mode enabled (not just detection)
- WAF logs are streamed to a centralized, tamper-evident log store
- Firewall and WAF rules are reviewed at least every six months
Backup and Log Retention
- Application data backup schedule is documented with RPO and RTO targets
- Backup restoration is tested at least annually with results documented
- Audit logs are retained for 12 months minimum
- At least 90 days of logs are immediately queryable without a restore operation
- Log integrity is verified with cryptographic hashing or equivalent
Vulnerability Management
- Quarterly ASV scans are scheduled with an approved vendor
- Internal vulnerability scans run after every significant change
- Critical patches (CVSS 9.0+) are applied within 30 days of release
- High-severity patches (CVSS 7.0-8.9) are applied within 90 days
- Container base images are included in the patch scope
Shared Responsibility
- Cloud provider AOC or SOC 2 Type II report is on file
- Shared responsibility matrix maps every PCI DSS requirement to an owner
- Provider's ISO 27001 or equivalent certification covers physical and network layers
- Penetration test scope includes cloud-specific attack surfaces (metadata APIs, IAM misconfigurations)
Building a PCI-Ready Cloud Stack Without Starting Over
PCI DSS 4.0.1 compliance on cloud infrastructure is achievable without a complete re-architecture, but it does require deliberate choices about where your CDE boundary sits, how traffic crosses that boundary, and how evidence is collected and retained. The organisations that struggle most in assessments are not the ones with the weakest security; they are the ones with the weakest documentation. Controls that exist but cannot be demonstrated do not count.
The infrastructure controls covered here, stateful firewalls, WAF with OWASP Top 10 coverage, five-zone network segmentation, automated backups with tested restore, and quarterly ASV scanning, form the technical foundation. The shared responsibility matrix and the pre-assessment gap analysis are the operational foundation. Both are required.
If you are evaluating cloud infrastructure for a payment workload and want a provider whose security posture is already documented against ISO 27001, SOC 2, and GDPR, the PlusClouds platform covers the full stack: Cloud Security for firewall and WAF, Networking and Load Balancers for segmentation, Automated Backup for recovery and log retention, and Cloud Servers for the compute layer. Start with a scope-reduction conversation: define your CDE boundary first, then build the controls around it. That order of operations saves more assessment time than any individual tool.
