PCI DSS Readiness,
v4.0.1 is the current standard. Scope your Cardholder Data Environment first, then prepare the 12 requirements against a cloud architecture.
Readiness guide
01 Background
What PCI DSS actually is
+
Background
What PCI DSS actually is
The Payment Card Industry Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council, a body formed by the major card brands. It is not a law — it is a contractual standard that every merchant, service provider, or processor handling card data agrees to when they sign with an acquirer. Non-compliance risk is commercial (fines, loss of processing rights, indemnity for breaches), not regulatory.
The current version is PCI DSS v4.0.1, mandatory from March 2025. Organized into 6 control objectives and 12 requirements.
02 Audience
Who needs to comply
+
Audience
Who needs to comply
Anything that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD) is in scope. That includes the obvious — payment gateways, checkout pages, virtual terminals — and the less obvious — backend reconciliation systems, CRM records, support tickets that include card numbers, call-center recordings, log lines that accidentally capture a PAN.
PCI DSS distinguishes between merchants (accept cards as payment) and service providers (process or store card data on behalf of others). Both must comply.
Validation path depends on volume: a small merchant using a third-party payment processor can often validate via a Self-Assessment Questionnaire (SAQ); a larger merchant or any service provider typically requires a Report on Compliance (ROC) signed by a Qualified Security Assessor (QSA).
03 Scope
What readiness means
+
Scope
What readiness means
PCI DSS readiness is mostly about scope reduction. The controls are demanding; the demanding controls only apply to the Cardholder Data Environment (CDE). The smaller the CDE, the smaller the compliance surface.
Modern cloud architectures can aggressively reduce CDE through:
Scope reduction A
Tokenization
Replace PAN with a token at the earliest possible point. The PAN leaves the CDE; tokens are out of scope.
Scope reduction B
iframe to certified processor
The checkout form is hosted by the processor, not you. Your servers never see the card data.
Scope reduction C
Point-to-point encryption
Hardware terminals encrypt at swipe and decrypt only at the processor.
Scope reduction D
Network segmentation
The CDE is its own VPC, subscription, or project with strict ingress/egress; outside systems cannot reach in.
Readiness produces the scoping document, a network and data-flow diagram, a gap assessment against the 12 requirements, a remediation roadmap, and either a SAQ ready for sign-off or an evidence package for a QSA-led ROC engagement.
04 Mapping
How CloudCheck 360° maps to PCI DSS
+
Mapping
How CloudCheck 360° maps to PCI DSS
| Req. | Focus | CC360° |
|---|---|---|
| 1 | Network security | §2 Network |
| 2 | Secure configurations | §4 Workload (CIS Benchmarks) |
| 3 | Stored account data | §3 Data (encryption, key mgmt) |
| 4 | Transmission | §2 Network · §3 Data (TLS) |
| 5 | Malware protection | §4 Workload (EDR) |
| 6 | Secure systems & software | §4 Workload (SDLC, scans, pentest) |
| 7 | Access by business need | §1 Identity (least privilege) |
| 8 | Authentication | §1 Identity (MFA on all CDE access, v4) |
| 9 | Physical access | Inherited from cloud provider |
| 10 | Log & monitor | §5 Logging (1-year retention) |
| 11 | Test security | §4 Workload · §5 Logging (scans, pentests) |
| 12 | Policies & programs | §7 Compliance posture |
v4 introduced the customized approach — organizations may design their own controls as long as those controls meet the stated objective and are formally assessed. Most clients use the defined approach for most requirements and reserve the customized approach for specific architectural choices.
05 Engagement
How an engagement runs
+
Engagement
How an engagement runs
Typically 10 to 16 weeks, driven by the CDE size and the starting architecture.
Weeks 1–3
Scope & data-flow mapping
Identify every system, process, and person that touches CHD or SAD. Produce data-flow diagrams. Identify scope-reduction opportunities (tokenization, iframes, P2PE).
Weeks 3–8
Gap assessment
Each of the 12 requirements assessed against the CDE. Output: prioritized remediation backlog plus SAQ-type recommendation or ROC-prep plan.
Weeks 6–14
Remediation
Technical gaps fixed. Policies drafted and signed. Quarterly scan and annual penetration-test processes set up with ASV-approved vendors where the scans are required to be ASV-led.
Weeks 14–16
QSA or SAQ
If SAQ, the form is completed and signed. If ROC, we support the QSA engagement by providing evidence, answering technical questions, and responding to findings.
06 Patterns
Common gaps we see
+
Patterns
Common gaps we see
PAN leaks in logs.
Application logs, error-reporting tools, and customer-support integrations frequently capture the PAN — especially in backtraces. Requirement 3.3 requires PAN to be rendered unreadable anywhere it is stored. Fix: logging-pipeline masking at the producer side, not the consumer side.
CDE boundary is larger than intended.
The original intent was "the CDE is this one EKS cluster." In practice, every Kubernetes admin has console access to other clusters, the same IAM role is used for CDE and non-CDE workloads, and the monitoring tooling reaches into the CDE without a clear trust boundary.
Quarterly scans are not being run.
The organization bought scanner licenses and never scheduled the scans. Requirement 11.3.2 requires quarterly internal vulnerability scans and ASV-approved external scans; missing them is a straightforward finding.
07 FAQ
Questions we get asked
+
FAQ
Questions we get asked
What's new in v4.0.1? +
Compared to v3.2.1: MFA required for all access into the CDE, stronger password requirements, expanded logging, explicit anti-phishing controls, customized approach option, new requirements for anti-malware on removable media and for e-commerce script protection (Req. 6.4.3). The customized approach is the biggest architectural change.
SAQ or ROC? +
Depends on validation level. Levels are set by the acquirer based on transaction volume. Small e-commerce merchants with fully outsourced card processing often qualify for SAQ A; organizations that touch PAN at any point usually cannot. A service provider almost always requires a ROC.
Can we use serverless or Kubernetes in the CDE? +
Yes. v4 explicitly acknowledges cloud architectures. Requirements map cleanly, but some requirements (especially around segmentation and access controls) need specific cloud-native implementations we help design.
How often does validation happen? +
Annually for the SAQ or ROC, plus quarterly external vulnerability scans. A service provider must also produce a quarterly attestation to compliance for customers.
What happens if we fail? +
Acquirer-imposed fines, increased transaction fees, liability for breach-related costs, and in extreme cases loss of processing privileges. The card brands publish standard penalty frameworks but individual acquirer contracts govern.
Primary source
PCI Security Standards Council — Document Library (PCI DSS v4.0.1). See also the CloudCheck 360° methodology and related frameworks SOC 2 and ISO 27001.
Start with a free Cloud Health Check.
A scoped-down CloudCheck 360° of your current environment. Delivered in five business days, no commitment.