PCI DSS v4.0 Readiness.

Payment Card Industry Data Security Standard for any platform storing, processing, or transmitting cardholder data

Readiness guide

PCI DSS is a set of security requirements published by the Payment Card Industry Security Standards Council (PCI SSC), a body founded by the major card brands (Visa, Mastercard, American Express, Discover, JCB). It applies to any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD).

PCI DSS is contractually enforced — not legally required by US federal law (some US states are different) but mandated by acquiring banks and card networks. Non-compliance can mean fines, loss of card processing privileges, and increased liability for breaches.

PCI DSS v4.0 was released in 2022 and supersedes v3.2.1. The mandatory transition deadline was March 2024 for new requirements; some “future-dated” requirements became effective March 2025. v4.0 emphasizes risk-based decision making, customized validation paths, and expanded authentication requirements (MFA on more interfaces).

Source: PCI DSS v4.0 standard · PCI SSC Document Library

Any merchant or service provider that touches cardholder data is in scope. Validation level depends on transaction volume and business model:

Merchant Level 1 (>6M Visa/Mastercard transactions/year): annual on-site audit by Qualified Security Assessor (QSA), Report on Compliance (RoC).

Merchant Level 2-4 (<6M transactions): typically Self-Assessment Questionnaire (SAQ) — the SAQ type depends on how the merchant handles card data. SAQ A is the lightest (cards never touch your systems, fully outsourced); SAQ D is the heaviest (you store, process, or transmit card data directly).

Service providers (anyone processing card data on behalf of merchants): more stringent — typically Level 1 RoC even at lower transaction volumes.

You probably need PCI DSS if: you accept payment cards directly OR you provide a service that processes/stores/transmits card data on behalf of merchants.

You probably do NOT need PCI DSS if: you fully outsource payment processing (Stripe Checkout hosted, PayPal redirect) and card data never touches your servers — you may still need SAQ A, but the work is minimal.

Three concrete outputs:

  • Output A

    Defined cardholder data environment (CDE) scope

    Network diagram showing CDE boundary, data flow diagram showing where CHD enters/transits/exits, connected systems inventory. Scoping is the most consequential decision — small CDE = manageable audit; sprawling CDE = expensive nightmare.

  • Output B

    Compensating controls + customized validation

    For each PCI DSS requirement that cannot be met as written, a documented compensating control or customized approach (v4.0 introduced customized validation as a formal path). Each customized control needs a Targeted Risk Analysis.

  • Output C

    Audit-ready posture (RoC or SAQ)

    Evidence collected per requirement. Scoping documentation current. Quarterly ASV scans completed. Penetration tests current (annual + after significant change). Annual review of policies signed.

For service providers: Attestation of Compliance (AoC) signed by QSA. For merchants: SAQ submitted to acquiring bank, or RoC if Level 1. Cloud Upload is not a QSA — we prepare the environment and evidence; the formal validation comes from a QSA firm.

PCI DSS v4.0 has 12 requirements (R1-R12) organized into 6 control objectives. Most map cleanly to CC360° categories.

Section Title CC360° category
R1 Network security controls §2 Network
R2 Apply secure configurations §7 Workload Security
R3 Protect stored account data §3 Data
R4 Protect card data with strong cryptography during transmission §2 Network · §3 Data
R5 Protect against malicious software §7 Workload Security
R6 Develop secure systems and software §7 Workload Security
R7 Restrict access to system components §1 IAM
R8 Identify users and authenticate access §1 IAM
R9 Restrict physical access Inherited from cloud provider
R10 Log and monitor all access §4 Logging & Detection
R11 Test security of systems and networks §4 Logging & Detection · §7 Workload Security · External quarterly ASV scans (separate vendor)
R12 Support information security with policies Cross-cutting (policies, training — outside CC360°)

R11 specifically requires annual penetration testing — this is where Cloud Upload's Pen Test tier integrates with PCI DSS readiness. Quarterly external ASV scans are typically run by a separate Approved Scanning Vendor (we do not currently hold ASV status).

A first-time PCI DSS readiness engagement is typically 10 to 16 weeks. The biggest variable is CDE scope size.

  1. Weeks 1-3

    CDE scoping + segmentation review

    Identify every system touching cardholder data. Map data flows. Document CDE boundary. Where possible, recommend segmentation changes that shrink the CDE — every system removed from CDE is a system removed from audit scope.

  2. Weeks 3-8

    Gap assessment + remediation

    Assess current state against the 12 requirements (or applicable SAQ). CloudCheck 360° pass surfaces technical gaps. Remediate identified gaps with priority on R3 (encryption), R7-R8 (access control), R10 (logging).

  3. Weeks 6-12

    Documentation + compensating controls

    Policies and procedures documented. Compensating controls drafted for any requirement not met as written (with v4.0 emphasis on customized approach + targeted risk analysis). Network and data flow diagrams finalized.

  4. Weeks 12-16

    QSA selection + pre-audit walkthrough

    Cloud Upload introduces 2-3 vetted QSA firms. Pre-audit walkthrough surfaces remaining gaps. Audit kicks off (RoC for Level 1) or SAQ submitted (lower levels). Cloud Upload remains available for QSA questions during the audit.

Annual recertification cycle: quarterly ASV scans (external), annual penetration test (Cloud Upload Pen Test tier), annual RoC or SAQ refresh.

  • CDE scope too large.

    Companies underestimate which systems are “connected to” the CDE. PCI DSS scope includes any system that could affect CDE security, not just systems touching CHD. The fix is rigorous segmentation review — most companies can shrink the CDE 50-70% with VPC, security group, and routing changes.

  • Logs collected but never reviewed.

    R10.4 requires daily review of security events. Most companies collect logs and never look at them between audits. The fix is automated alerting on security-relevant events (failed authentication, privilege escalation, log clearing) with documented review evidence.

  • Quarterly ASV scans skipped.

    R11.3.2 requires quarterly external ASV scans by an Approved Scanning Vendor. Companies that fail one quarter must rescan and pass before the next quarter; many skip and accumulate failures. The fix is auto-scheduled scans with remediation SLA.

  • Annual pen test not performed.

    R11.4 requires annual penetration testing AND after any significant change. Many companies do one pen test in year 1 and never repeat. The fix is annual scheduled engagement (Cloud Upload Pen Test tier) plus automatic kickoff after significant infrastructure change.

  • Compensating controls without targeted risk analysis.

    v4.0 requires Targeted Risk Analysis (TRA) for any compensating control or customized approach. Companies use compensating controls but do not document the TRA. The fix is templated TRA per compensating control with annual refresh.

  • Do I need PCI DSS if I use Stripe Checkout?

    Probably SAQ A only — the lightest validation path. Stripe Checkout hosts the payment form on Stripe domains, so your servers never touch card data. You still attest to SAQ A annually but the requirements are minimal (~20 questions vs SAQ D's ~300+).

  • What changed in v4.0?

    Major changes: customized validation path (alternative to compensating controls), expanded MFA requirements (now required on all access into the CDE, not just admin), targeted risk analysis required for many controls, and stronger emphasis on continuous validation rather than point-in-time. Future-dated requirements became effective March 2025.

  • How much does PCI DSS validation cost?

    SAQ A: minimal direct cost (the SAQ is free; readiness work varies). SAQ D + RoC: $25,000-$100,000+ from a QSA depending on CDE complexity. ASV quarterly scans: $5,000-$15,000/year. Annual pen test: $3,499-$15,000+ (Cloud Upload Pen Test pricing). Readiness work separate.

  • What about Stripe / Braintree / Adyen as payment processors?

    All major processors maintain their own PCI DSS Level 1 validation. Using them shifts a lot of scope off your environment, but you are still a merchant or service provider with your own compliance obligation. The lighter your direct card data handling, the lighter your SAQ.

  • Cloud-hosted PCI environment?

    AWS, GCP, and Azure all offer PCI DSS-compliant infrastructure for in-scope services. You inherit the provider's PCI compliance for the underlying infrastructure but must validate your own configuration. Provider AoCs are available (look for “Shared Responsibility” documentation).

  • When should we start?

    When your business model requires processing card data, OR when you are about to launch a feature that will touch CHD. Going through PCI DSS for a single payment integration is rarely worth it if a hosted alternative exists. Cloud Upload helps you scope this decision.

Primary sources: PCI SSC Document Library · CloudCheck 360° methodology · Pen Test scope and methodology · Reading a pentest report your board will act on · SOC 2 readiness guide

Get started

Run a free audit to see your PCI DSS posture.

The patterns in this guide come from real engagements. To see how your environment compares — and which gaps would land in your readiness report — start with a free scan or talk to us about a manual engagement.

Start your free audit → Talk to the team →